Archive

Posts Tagged ‘SOA’

Eight things that changed since we wrote Cloud Computing for Dummies

October 8, 2010 3 comments

I admit that I haven’t written a blog in more than three months — but I do have a good reason. I just finished writing my latest book — not a Dummies book this time. It will be my first business book based on almost three decades in the computer industry. Once I know the publication date I will tell you a lot more about it. But as I was finishing this book I was thinking about my last book, Cloud Computing for Dummies that was published almost two years ago.  As this anniversary approaches I thought it was appropriate to take a look back at what has changed.  I could probably go on for quite a while talking about how little information was available at that point and how few CIOs were willing to talk about or even consider cloud computing as a strategy. But that’s old news.  I decided that it would be most interesting to focus on eight of the changes that I have seen in this fast-moving market over the past two years.

Change One: IT is now on board with cloud computing. Cloud Computing has moved from a reaction to sluggish IT departments to a business strategy involving both business and technology leaders.  A few years ago, business leaders were reading about Amazon and Google in business magazines. They knew little about what was behind the hype. They focused on the fact that these early cloud pioneers seemed to be efficient at making cloud capability available on demand. No paperwork and no waiting for the procurement department to process an order. Two years ago IT leaders tried to pretend that cloud computing was  passing fad that would disappear.  Now I am finding that IT is treating cloud computing as a center piece of their future strategies — even if they are only testing the waters.

Change Two: enterprise computing vendors are all in with both private and public cloud offerings. Two years ago most traditional IT vendors did not pay too much attention to the cloud.  Today, most hardware, software, and services vendors have jumped on the bandwagon. They all have cloud computing strategies.  Most of these vendors are clearly focused on a private cloud strategy. However, many are beginning to offer specialized public cloud services with a focus on security and manageability. These vendors are melding all types of cloud services — public, private, and hybrid into interesting and sometimes compelling offerings.

Change Three: Service Orientation will make cloud computing successful. Service Orientation was hot two years ago. The huge hype behind cloud computing led many pundits to proclaim that Service Oriented Architectures was dead and gone. In fact, cloud vendors that are succeeding are those that are building true business services without dependencies that can migrate between public, private and hybrid clouds have a competitive advantage.

Change Four: System Vendors are banking on integration. Does a cloud really need hardware? The dialog only two years ago surrounded the contention that clouds meant no hardware would be necessary. What a difference a few years can make. The emphasis coming primarily from the major systems vendors is that hardware indeed matters. These vendors are integrating cloud infrastructure services with their hardware.

Change Five: Cloud Security takes center stage. Yes, cloud security was a huge topic two years ago but the dialog is beginning to change. There are three conversations that I am hearing. First, cloud security is a huge issue that is holding back widespread adoption. Second, there are well designed software and hardware offerings that can make cloud computing safe. Third, public clouds are just as secure as a an internal data center because these vendors have more security experts than any traditional data center. In addition, a large number of venture backed cloud security companies are entering the market with new and quite compelling value propositions.

Change Six: Cloud Service Level Management is a  primary customer concern. Two years ago no one our team interviewed for Cloud Computing for Dummies connected service level management with cloud computing.   Now that customers are seriously planning for wide spread adoption of cloud computing they are seriously examining their required level of service for cloud computing. IT managers are reading the service level agreements from public cloud vendors and Software as a Service vendors carefully. They are looking beyond the service level for a single service and beginning to think about the overall service level across their own data centers as well as the other cloud services they intend to use.

Change Seven: IT cares most about service automation. No, automation in the data center is not new; it has been an important consideration for years. However, what is new is that IT management is looking at the cloud not just to avoid the costs of purchasing hardware. They are automation of both routine functions as well as business processes as the primary benefit of cloud computing. In the long run, IT management intends to focus on automation and reduce hardware to interchanagable commodities.

Change Eight: Cloud computing moves to the front office. Two years ago IT and business leaders saw cloud computing as a way to improve back office efficiency. This is beginning to change. With the flexibility of cloud computing, management is now looking at the potential for to quickly innovate business processes that touch partners and customers.

The lock-in risks of Software as a Service

May 3, 2010 3 comments

I started thinking a lot about software as a service environments and what this really means to customers.  I was talking to a CIO of a medium sized company the other day. His company is a customer of a major SaaS vendor (he didn’t want me to name the company). In the beginning things were quite good. The application is relatively easy to navigate and sales people were satisfied with the functionality. However, there was a problem. The use of this SaaS application was actually getting more complicated than the CIO had anticipated.  First, the company had discovered that they were locked into a three-year contract to support 450 sales people.  In addition, over the first several years of use, the company had hired a consultant to customize the workflow within the application.

So, what was the problem?  The CIO was increasingly alarmed about three issues:

  • The lack of elasticity. If the company suddenly had a bad quarter and wanted to reduce the number of licenses supported, they would be out of luck. One of the key promises of cloud computing and SaaS just went out the window.
  • High costs of the services model. It occurred to the CIO that the company was paying a lot more to support the SaaS application than it would have cost to buy an on premise CRM application. While there were many benefits to the reduced hardware and support requirements, the CIO was starting to wonder if the costs were justified.  Did the company really do the analysis to determine the long-term cost/benefit of cloud?  How would he be able to explain the long- term ramifications of budget increases that he expects will come to the CFO? It is not a conversation that he is looking forward to having.
  • No exit strategy. Given the amount of customization that the company has invested in, it is becoming increasingly clear that there is no easy answer – and no free lunch. One of the reasons that the company had decided to implement SaaS was the assumption that it would be possible to migrate from one SaaS application to another.  However, while it might be possible to migrate basic data from a SaaS application, it is almost impossible to migrate the process information. Shouldn’t there be a different approach to integration in clouds than for on premise?

The bottom line is that Software as a Service has many benefits in terms of more rapid deployment, initial savings in hardware and support services, and ease of access for a highly distributed workforce.  However, there are complications that are important to take into account.  Many SaaS vendors, like their counterparts in the on-premise world, are looking for long-term agreements and lock-in with customers.  These vendors expect and even encourage customers to customize their implication based on their specific business processes.  There is nothing wrong with this – to make applications like CRM and HR productive they need to reflect a company’s own methods of doing business. However, companies need to understand what they are getting into. It is easy to get caught in the hype of the magic land of SaaS.  As more and more SaaS companies are funded by venture capitalists, it is clear that they will not all survive. What happens to your customized processes and data if the company goes out of business?

It is becoming increasingly clear to me that we need a different approach to integration in the cloud than for on premise. It needs to leverage looser coupling, configurations rather than programmatic integration. We have the opportunity to rethink integration altogether – even for on premise applications.

There is no simple answer to the quandary.  Companies looking to deploy a SaaS application need to do their homework before barreling in.  Understand the risks and rewards. Can you separate out the business process from the basic SaaS application? Do you really want to lock yourself into a vendor you don’t know well? It may not be so easy to free your company, your processes, or your data.

What are the Unanticipated consequences of the cloud – part II

October 29, 2009 9 comments

As I was pointing out yesterday, there are many unintended consequences from any emerging technology platform — the cloud will be no exception. So, here are my next three picks for unintended consequences from the evolution of cloud computing:

4. The cloud will disrupt traditional computing sales models. I think that Larry Ellison is right to rant about Cloud Computing. He is clearly aware that if cloud computing becomes the preferred way for customers to purchase software the traditional model of paying maintenance on applications will change dramatically.  Clearly,  vendors can simply roll in the maintenance stream into the per user per month pricing. However, as I pointed out in Part I, prices will inevitably go down as competition for customers expands. There there will come a time when the vast sums of money collected to maintain software versions will seem a bit old fashioned. old fashioned wagonIn fact, that will be one of the most important unintended consequences and will have a very disruptive effect on the economic models of computing. It has the potential to change the power dynamics of the entire hardware and software industries.The winners will be the customers and smart vendors who figure out how to make money without direct maintenance revenue. Like every other unintended consequence there will be new models emerging that will emerge that will make some really cleaver vendors very successful. But don’t ask me what they are. It is just too early to know.

5. The market for managing cloud services will boom. While service management vendors do pretty well today managing data center based systems, the cloud environment will make these vendors king of the hill.  Think about it like this. You are a company that is moving to the cloud. You have seven different software as a service offerings from seven different vendors. You also have a small private cloud that you use to provision critical customer data. You also use a public cloud for some large scale testing. In addition, any new software development is done with a public cloud and then moved into the private cloud when it is completed. Existing workloads like ERP systems and legacy systems of record remain in the data center. All of these components put together are the enterprise computing environment. So, what is the service level of this composite environment? How do you ensure that you are compliant across these environment? Can you ensure security and performance standards? A new generation of products and maybe a new generation of vendors will rake in a lot of cash solving this one. cash-wad

6. What will processes look like in the cloud. Like data, processes will have to be decoupled from the applications that they are an integral part of the applications of record. Now I don’t expect that we will rip processes out of every system of record. In fact, static systems such as ERP, HR, etc. will have tightly integrated processes. However, the dynamic processes that need to change as the business changes will have to be designed without these constraints. They will become trusted processes — sort of like business services that are codified but can be reconfigured when the business model changes.  This will probably happen anyway with the emergence of Service Oriented Architectures. However, with the flexibility of cloud environment, this trend will accelerate. The need to have independent process and process models may have the potential of creating a brand new market.

I am happy to add more unintended consequences to my top six. Send me your comments and we can start a part III reflecting your ideas.

What are the unanticipated consequences of Cloud Computing- Part I

October 28, 2009 4 comments

Maybe I am just obsessed with cloud computing these days. I guess that after spending more than 18 months researching the topic for our forthcoming book, Cloud Computing for Dummies, cloud_streetsI can be excused for my obsession.  Now that I am able to take a step back from the noise of the market, I have been thinking about what this will mean in the next ten years. Consequences of technology adoption are never what we expect. For example, in the late 1970s and early 1980s no one could imagine why anyone would want a personal computer. In fact, the only application people could imagine for a PC was a way to store recipes (I am not making this up). Keep in mind that this was before the first PC-based spreadsheet was designed by Dan Bricklin and Bob Franston(That’s them in the picture)bricklinfrankston . No one in those days could have predicted that everyone from a CEO to a three year old child would own a personal computer and its use would change the way we conduct business.  (I never did find a recipe storing application).

The same logic can be applied to the Internet. While the Internet has been used 40 years ago by researchers, it was not a commercially viable option until the mid-1990s. In the early days of the Internet it was a sophisticated communications technology with a command line interface. Once the browser came along, businesses tended to use it to share price lists, marketing materials, and job postings. There were certainly message boards but only for the real techies. There were environments such as The Well which was the first online community used primarily by academics and wild-eyed researchers.

In that context, I was thinking about what we might expect to happen with cloud computing? There is a lot to say, so I decided to break this into two parts — each one will have three consequences. Here are today’s top three:

1. Cloud computing will begin to change the way we think of an application. To be truly useful to large groups of individuals and businesses requires economies of scale in terms of massively scaled workloads. The only way to accomplish this is either to cherry pick a few big workloads (like email) or to branch out. That branching out is inevitable and will mean that vendors with cloud offerings with componentize their software offerings into modular services that can be mixed and matched with other services.

2. The prices that vendors will charge for cloud computing services will drop dramatically over the next few years. As prices drop it will become a lot more economically viable to substitute on premise environment for the cloud environment. Today this is not the case; large companies supporting thousands of users in an application environment cannot justify the movement to a cloud platform. What if the costs drop to the point where the economics (with the right workloads) favor cloud based services? When this happens there will be a tipping point that we might not even notice for a few years. But I predict that it will happen. We are already seeing Amazon dropping prices for its EC2 environment based on the competitive threat from Microsoft Azure services announcement.

3. The cloud will change the way we manage data. The traditional way we think about data neatly stored in specific databases to handle a specific business problem will inevitably change.  This won’t be an overnight change but it will happen. Data will increasingly be seen as a reusable resource that can be used in lots of different situations. There will continue to be strategic line of business applications but they will be more systems of record that keep track of the final result of actions that take place dynamically in the cloud. The value of data is not in its tight packaging as we have been used to for decades but it the flexibility to move, transform, and leverage data. The watch word for data in this new model will be Trusted Data in the Cloud.

I would love to know what you think of my top three choices; send me your comments and I will add them to my list for tomorrow.

As we deal with the cloud hype it is too easy to be dismissive and cynical. But we always treat complicated new trends that way — until one day they become the normal way of business and life.

Can we free process and data?

October 27, 2009 1 comment

I am still at IBM’s Information on Demand conference here in Las Vegas (not my favorite place..but what can you do). In listening to a lot of discussions around strategy and products I started thinking about one of the key problems that customers are facing around business process and managing increasingly complex data. What companies really want to do is to have the flexibility and freedom to leverage their critical data across applications and situations. They also want to be able to change processes based on changing business models.

This is the core issue that companies will be facing in the coming decade and will be the difference between success and failure for many  businesses.  Here’s an example of what I mean. Let’s take the example of a retailer in a competitive market. Let’s say our retailer had five or six applications: Accounting, Human Resources, supply chain management, a customer support system, and a customer facing e-commerce system. Each of these systems has an underlying database; each one manages this data based on the business process that is the foundation of the best practices that is the value of these packages. Even if each of the packages are the best in their markets there is a core problem since each solution is a silo. Processes that move between these systems tend to fall through the cracks.  This is why we, as customers of such retailers, are often frustrated when we call about a product that wasn’t delivered, doesn’t work, or requires a change only to discover that one department has no ability to know what is happening in another area. For most companies the dream of single view of the customer is aspirational but not practical right now. In reality, it is hard for companies to mess with their existing applications. These solutions are customized for their business environment; they were expensive and complicated to implement — and change is hard. In fact, companies only change when it is more painful to stay with the status quo than it is to change. In a retail scenario, companies change their approach to process and data management when they must change their business model because the current processes will lead to failure. Retailers are currently faced with emerging approaches to selling and managing customer relationships that are challenging traditional selling models.  Look what a company like Amazon.com or Netflex have done to their slower moving competitors.

A number of customers I have spoken with understand this very well. They are looking at ways to separate their core data assets from the underlying applications. Many of these customers are at the forefront of implementing a service oriented architecture (SOA) approach to managing their software assets. They are increasingly understanding that the secret to their future success is the knowledge they have about their customers, their needs and future requirements within their own set of offerings and those from partners. These companies are setting a priority of making this data independent, secure, and accurate. These business leaders are preparing for inevitable change.  At the same time, I have seen these customers creating SOA business services that are, in essence, codified business processes. For example, a business service could be a process that checks the credit of a potential partner or links a new customer request for service to the set of applications that confirms the request, orders the part, and notifies a partner.

So, here is the problem. These customers are implementing this new model of abstracting data and process based on specific projects or business initiatives.  These projects have gotten the attention of the C-team because of the impact on revenue. But, in reality, the real breakthrough will happen when the separation of data and process are the rule, not the exception.

This is going to be the overriding challenge for the next decade because it is so hard. There is inertia to move away from the predictable packaged applications that companies have implemented for more than 30 years. But I suggest that it will be inevitable that companies will begin to understand that if they are going to remain agile and change processes when they anticipate a competitive threat. These same companies will understand that their data is too important to leave it locked inside an application linked tightly to a process.

I don’t have the answers about what the tipping point will be when this starts to become a wide spread strategy. I think that the cloud will became a forcing action that will accelerate this trend. I would love to start a dialog. Send me your thoughts and I promise to post them.

Does IT see the writing on the cloud wall?

April 15, 2009 5 comments

For the last six months or so I have been researching cloud computing. More recently, our team has started writing our next Dummies Book on Cloud Computing. Typically when we start a book we talk to everyone in the ecosystem — vendors big and small and lots of customers.  For example, when we started working on SOA for Dummies almost three years ago we found a lot of customers who could talk about their early experience. Not all of these companies had done things right. They had made lots of mistakes and started over. Many of them didn’t necessarily want their mistakes put into a book but they were willing to talk and share.  As I have mentioned in earlier writings, when we wrote the second edition of SOA for Dummies we had a huge number of customers that we could talk to. A lot of them have made tremendous progress in transforming not just their IT organization but the business as well.

We had a similar experience with Service Management for Dummies which comes out in June. Customers were eager to explain what they had learned about managing their increasingly complex computing and business infrastructures.  But something interesting in happening with the Cloud book. The experience feels very different and I think this is significant.

Our team has been talking to a lot of the vendors — big and small about their products and strategies around the cloud. Some of these vendors focused on some really important problems. Others are simply tacking the word cloud in front of their offerings hoping to get swept up in the excitment. But there is something missing. I think there are two things: there is a lack of clarity about what a cloud really is and what the component parts are. Is it simply Software as a Service? Is it an outsourced infrastructure? Is it storage capacity to supplement existing data centers? Is it a management platform that supports Software as a service? Does cloud require a massive ecosystem of partners? Is it a data center with APIs? Now, I am not going to answer these questions now (I’ll leave some of these to future writings).

What I wanted to talk about was what I see happening with customers.  I see customers being both confused and very wary. In fact, the other day I tried to set up a call with a senior executive from a large financial services company that I have spoken to about other emerging areas. This company always likes to be on the forefront of important technology trends. To my surprise, the executive was not willing to talk about clouds at all.  Other customers are putting their toes in the cloud (pun intended) by using some extra compute cycles from Amazon or by using Software as a Service offerings like SalesForce.com. Some customers are looking to implement a cloud-like capability within their own data center. Could it be there they are afraid that if they don’t offer something like Amazon’s EC2 cloud that they will be put out of business? Just as likely they are worried about the security of their intellectual property and their data.

I predict that the data center is about to go through a radical transformation that will forever change the landscape of corporate computing. Companies have recognized for a long time that data centers are very inefficient. They have tried clustering servers and virtualizing their servers with some level of success.  But the reality is that in time there will be a systematic approach to scalable computing based on the cloud.  It will not be a simple outsourced data center because of the transition to a new generation of software that is component based and service oriented. There is a new generation of service management technologies that makes the management of highly distributed environments much more seamless. The combination of service oriententation, service managment, and cloud will be the future of computing.

The bottom line is that while the vendor community sees dollar signs in this emerging cloud based world, the customers are afraid. The data center management team does not understand what this will mean for their future. If everything is tucked away in a cloud what is my job? Will we still have a data center? I suspect that it will not be that simple. At some point down the line we will actually move to utility computing where computing assets will all be based on a consistent set of standards so that customers will be able to mix and match the services they need in real time. We clearly are not there yet. Today there will be many data center activities that either cannot or will not be put into a cloud. Internal politics will keep this trend towards clouds moving slowly.

Yes, Virginia, there is a SOA!

February 9, 2009 9 comments

It has been only a few weeks since Ann Thomas Manes wrote her blog stating that SOA is dead.  Since then there has been a lot of chatter about whether this is indeed true and if SOA vendors should find a new line of work.  So, I thought I would add my two cents to the conversation.

Let me start by saying, I told you so.  Last year I wrote in a blog that we would know when SOA had become mainstream when the enormous hype cycle ended. Alas that has happened. What does this mean? Let’s keep this in perspective. Every technology that comes along and generates a lot of hype follows this same pattern. Why? I’ll make it simple. The hype machine is powerful. It goes like this. There is a new technology trend with thousands of new companies on the scene.  All of them vie for dominance and a strong position on someone’s magic universe.  They are able to gain attention in the market. Then the market takes on its own momentum.  The technology moves from being a set of products focused on solving a business problem to the solution to any problem.  We saw this with object orientation, open systems, and Enterprise Applications Integration – to name but a few.  Smart entrepreneurs, sensing opportunity, stormed onto the market, promising huge promises of salvation for IT. Now, if I wanted to write a book I think I could come up with 100 different scenarios to prove my point but I will spare you the pain since the outcome is always the same.
So, what happens when each of these technology approaches moves from hype heaven to the dead zone? In some cases, the technology actually goes away because it simply doesn’t work – despite all of the hype.  But in many situations an interesting thing happens – the technology evolves into something mainstream. It gets incorporated and sometimes buried into emerging products and implementation plans of companies. It becomes mainstream.  I’ll just give you a few examples to support this premise:
•    Remember open systems? In the early 1990s it was the biggest trend around. There were thousands of products that were released onto the market. There were hundreds of companies that renamed themselves open something or other.  So, what happened? Open became mainstream and the idea of designing proprietary technologies without open interfaces and standards support became unpopular. No one creates a magic quadrant based on open systems but I don’t know many companies who can ignore standards and survive.

•    Object orientation was as big a rage as open systems – maybe even bigger. There were conferences, publications, magic quandrants and lots and lots of products ranging from operating systems to databases to development environments.  It was a hot, hot market.  What happened? The idea of creating modular components that could be reused turned out to be a great idea. But the original purity and concepts needed to evolve into something more pragmatic and in fact they did.  The concepts of object orientation changed the nature of how developers created software.  It moved from the idea of creating small granular pieces of code that could be used in lots of different ways to larger grain pieces of code that could create composites.  Object orientation is the foundation that most modern software sits on top of.

•    Enterprise Applications Integration probably had even more companies than either open systems or object orientation combined.  The idea that a company could buy technology that would allow their packaged software elements to talk to each other and pass data was revolutionary at the time.  This trend was focused on providing packaged solutions to a nasty problem. If vendors could find a way to provide solutions that allowed customers to avoid resorting to massive coding, it would result in a big market opportunity. Vendors in this market promised to provide solutions that allowed the general ledger module to send data to and from the sales force application. What happened? There were hundreds of vendors telling into this market.  However, it was a stopping off point.  There are newer products that do a better job of integration based on a service oriented approach to integration and data management.  In addition, this market evolved into technologies such as Enterprise Service Buses that did a better job of abstraction. There are plenty of Enterprise Application Integration technologies out there but they have emerged as a part of a loosely coupled environment where components are designed to send messages between them.
Now, I could go on for a long time with plenty more examples. But I think I have made my point. Technology innovation just works this way. The products that took the market by storm one year become stale the next. But the lessons learned and the innovation does not die. These lessons are used by a new generation of smart technologists to support the new generation of products.
So, Virginia, Service Oriented Architectures will do the same thing.  But it is also a little different.  It is not the same as a lot of other technology shiny toys because so much of SOA is actually about business practices – not technology.  Sure when SOA started out a few years ago it was about specific products – hundreds of them. These products were eagerly adopted by developers who used them to created service interfaces and business services.
Today, business leaders are taking charge of their SOA initiatives. The innovative business leaders are using business focused templates to move more quickly. They are creating business services – code plus process. They are creating business services such as Order-to-Cash services that in the long run will be mandated as the way everyone across the company will implement a process according to corporate practices.  Some of these companies would like to rid themselves of huge, complicated and expensive packaged software and replace them with these business services.
Today these products are becoming part of the fabric of the companies that use them. They are enablers of consistent and vetted business processes. They are the foundation of establishing good governance so that everyone in the organization uses a consistent set of rules, data, and processes. This is not glamorous.  It is hard work that starts from a business planning cycle.  It is the type of hard work where teams of technologist and business leaders determine what is the best way to satisfy the company’s need to implement order to cash processes across business units.
And yes, Virginia SOA is not stagnant.  It is evolving because it offers business value to companies.  There are new initiatives and new architectural principles that have value within this service orientation approach.  There are architectures such as REST that helps make interaction within a business services approach more interactive.  There are emerging standards that enable companies using SOA to be able to exchange information without massive coding. There are information services and security services evolving for the same reason. There are new approaches to make SOA environments more manageable based on the emerging idea that, in fact, everything we do with the world is a service of some type that needs to work with other services.  The physical and virtual words are starting to blend – which makes service orientation even more important.
Maybe ten years from now, we won’t use the word Service Oriented Architecture because it won’t be seen as a market segment or a quadrant – it will be just the way things are done.  So, stop worrying about whether SOA is alive, dead, or comatose – I have. So, relax Virginia, and get back to work!

Why its hard to build great software companies

January 30, 2009 4 comments

I went to Progress Software’s  industry/financial analyst meeting this week.  I have known Progress Software since the 1990s as it migrated from the 4GL database development market to client/server and then to SOA and Software as a Service.  Unlike some of its peers in the 4GL space, Progress has managed to change with the times and evolve.  What I like about Progress is that it had the ability to move to new generations of software.  In addition, Progress had the good fortune of moving early into the OEM business. It has a large base of packaged software vendors that use its OpenEdge application development and database as part of their solutions.  This solid business provides a good cash flow to support the business. In fact, OpenEdge represents almost about 60% of the company’s revenue. Since it is a mature product, it provides nice cash flow for the company.

Now, I didn’t intend to write an entire report on Progress and its financial performance, although it would be a fascinating exercise. What I wanted to talk about is the issue of what makes a great software company.  I think that Progress is a good software company.  They do a lot of  things right.  What do they do well? Well, here is my list:

1. They have a great OEM base that embeds its technology into packaged software and therefore provides a predictable revenue stream.

2. Progress has used its cash wisely to purchase complementary software companies that already had a good revenue stream in secure markets.

3. The company has a good and predictable process for integrating acquisitions into the company while keeping the revenue stream growing.

4. Progress knows how to sell its newly acquired products to the installed base.

All of this is good. In the end, Progress has established itself as a good software company with predictable revenue that has been growing at a steady pace over the years. Today has revenues of around $540 million with more than $100 million in cash.

But is Progress a great software company? It is interesting to think about what might have been. Progress at this year’s meeting stated that it was going to start providing solutions to its customers. Good idea, in fact this is the trend among many software companies (I have always like solutions more than tools).  And Progress has a handful of offerings for the financial industry based primarily on its Complex Event Processing engine (Apama).  But here is an interesting observation. Progress has many successful ISV/OEM partners that sell solutions in various markets.  During the meeting management mentioned that some of these partners have bought other partners that also leverage Progress’s software (Sonic ESB, appserver, OpenEdge, etc.).  Now, I was just thinking, what would have happened if Progress had started buying some vertical solutions software companies that had been built on their technology? Could they have become that elusive $1 billion software company?

So, what do I think makes a great software company rather than a good one?  Here are my top five recommendations:

1. Great companies start with a predictable business model and turn the model upside down. They look three years ahead and experiment with innovation. They have to have a combination of intuition, risk, and innovation. These companies are willing to take enough risk to win big but smart enough to know the difference between great opportunities and pipe dreams.

2. Great companies find new areas to position themselves for leadership. This is very tough to pull off. The area has to be important enough for the market to pay attention to but not too big that they look silly.  Great companies never try to take a big existing market with established leaders and try to claim primacy.

3. Great companies build great relationships. Management at these companies builds an ecosystem of influencers including great customers who will talk about the value, press, analysts, and partners who together help the company create a persona of innovation and greatness while the company is still building.

Great software companies are complicated to build.   The software business a complicated and brutal with  lots of failures at every turn.  It is therefore proper to admire what Progress Software has done in building a sustainable business model. It isn’t easy. Great software companies are even more difficult and scary to build.

Making sense of REST in context with SOA

January 19, 2009 2 comments

I continue to spend a lot of time thinking and researching REST — REpresentational State Transfer. Yes, REST is a set of architectural guidelines introduced by Roy Fielding in his dissertation where he defined HTTP. While I couldn’t find a link to Fielding’s disseration, I did find a very good blog entry written by Fielding.

Given its origins, REST follows the philosophy of HTTP. In other words, you give everything an ID, you link these services or components together though some standards methods.  These services communicate in a stateless manner.  In addition, these resources can be used in many different contexts.  What is very important about rest is this idea of linking resources based on self-describing interaction where there is no state between requests. Therefore, from a customer perspective it offers the fast, effective model for development that is fundamental to being able to make organizations more fluid and effective.

As part of my research, I had an interesting conversation with Martin Nally,  IBM Rational’s CTO  about REST, its value and its relationship to SOA. From his perspective, REST looks like a data set that is exposed with Internet protocols.  And if you look at the way REST is described in terms of GET, PUT, POST, and DELETE.  In Nally view, REST provides “a simple style of using HTTP if you can look at your problem set as a web of interconnected hyperlinked resources.”  I thought that Nally put it very well, “In the old days we would create a data model with a representation of department, employee, etc. to create the data in a database. Then we would write two styles of applications: one that was basically to conduct simple data based operations (Create, Read, Update, Delete) and a second to type of application that would apply that information to business process — how do you rate a customer’s credit worthiness?”  In other words, it is necessary to intermix web based services that are stateless and can link data together across a distributed computing environment combined with well defined business services that encapsulate business rules and process. In the operational environment based on business services — based on a Service Oriented Architecture — there are many resources provided based on components that require a lot more structuring of process and more overall governance.  For many types of implementations, there needs to be the foundation of technology concepts such as a registry/repository for both management and governance.  There needs to be a transport mechanism for guarenteed transactions.

I think that we need to look at both two world views — REST to support the web, data oriented linkage style with the structured world of  a services and process based approach.  Let’s leave the religious wars to someone else and recognize that there is room in our complicated software world for both.

What’s different about SOA two years later? Why we wrote a second edition of SOA for Dummies

December 8, 2008 4 comments

soafd2It seems like just the other day that our team was busily finishing the first edition of SOA for Dummies. But it was two years ago since that book came out. A lot has change in that time. When we first wrote the book, we heard from lots of people that they really didn’t know what SOA was and were happy to have a book that would explain it to them in easy to understand language.

Because so much has changed, we were asked to write a second edition of SOA for Dummies which is coming out on December 19th.    What has changed in those two years?  Well, first of all, there have been a lot more implementations of SOA. In fact, in that edition, we were happy to have gotten 7 case studies.  Many of the customers that we talked (both that were featured in the book and those who took the time to speak with us without attribution) were just getting started. They were forming centers of excellence. They were beginning to form partnerships between the business and technical sides of their companies. They were implementing a service bus or were building their first sets of services.

In this second edition, we were fortunate to find 24 companies across 9 different verticals willing and able to talk on the record about their experiences implementing SOA.  What did we learn? While there is a lot I could say, I’d like to net it out to 5 things we learned:

1. Successful companies have spent the time starting with the both the key business services and business process before even thinking about implementation.

2. Companies have learned a lot since their initial pilots. They are now focused on how they can increase revenue for their companies through innovation using a service oriented approach.

3. Many companies have a strategic roadmap that they are focused on and therefore are implementing a plan in an incremental fashion.

4. A few companies are creating business services extracted from aging applications. Once this is done, they are mandating the use of these services across the company.

5. Companies that have been working on SOA for the last few years have learned to create modular business services that can have multiple uses. This was much harder than it appeared at first.

There are many other best practices and lessons learned in the case studies.  It is interesting to note just as many companies that said yes also were not able to participate because management felt that they didn’t want competitors to know what they were doing.

The bottom line is that SOA is beginning to mature. Companies are not just focused on backbone services such as service buses but on making their SOA services reach out to consumers and their business partners.

We have also added a bunch of new chapters to the book. For example, we have new chapters on SOA service management; SOA software development, software quality, component applications, and collaboration within the business process lifecycle.  Of course, we have updated all existing chapters based on the changes we have seen over the last few years.

We are very excited that we had the opportunity to update the book and look forward to continuing the dialog.