Ten things I learned while writing Cloud Computing for Dummies

I haven’t written a blog post in quite a while. Yes, I feel bad about that but I think I have a good excuse. I have been hard at work (along with my colleagues Marcia Kaufman, Robin Bloor, and Fern Halper) on Cloud Computing for Dummies. I will admit that we underestimated the effort. We thought that since we had already written Service Oriented Architectures for Dummies — twice; and Service Management for Dummies that Cloud Computing would be relatively easy. It wasn’t. Over the past six months we have learned a lot about the cloud and where it is headed. I thought that rather than try to rewrite the entire book right here I would give you a sense of some of the important things that I have learned. I will hold myself to 10 so that I don’t go overboard!

1. The cloud is both old and new at the same time. It is build on the knowledge and experience of timesharing, Internet services, Application Service Providers, hosting, and managed services. So, it is an evolution, not a revolution.

2. There are lots of shades of gray with cloud segmentation. Yes, there are three buckets that we put clouds into: infrastructure as a service, platform as a service, and software as a service. Now, that’s nice and simple. However, it isn’t because all of these areas are starting to blurr into each other. And, it is even more complicated because there is also business process as a service. This is not a distinct market unto itself – rather it is an important component in the cloud in general.

3. Market leadership is in flux. Six months ago the market place for cloud was fairly easy to figure out. There were companies like Amazon and Google and an assortment of other pure play companies. That landscape is shifting as we speak. The big guns like IBM, HP, EMC, VMware, Microsoft, and others are running in. They would like to control the cloud. It is indeed a market where big players will have a strategic advantage.

4. The cloud is an economic and business model. Business management wants the data center to be easily scalable and predictable and affordable. As it becomes clear that IT is the business, the industrialization of the data center follows. The economics of the cloud are complicated because so many factors are important: the cost of power; the cost of space; the existing resources — hardware, software, and personnel (and the status of utilization). Determining the most economical approach is harder than it might appear.

5. The private cloud is real.  For a while there was a raging debate: is there such a thing as a private cloud? It has become clear to me that there is indeed a private cloud. A private cloud is the transformation of the data center into a modular, service oriented environment that makes the process of enabling users to safely procure infrastructure, platform and software services in a self-service manner.  This may not be a replacement for an entire data center – a private cloud might be a portion of the data center dedicated to certain business units or certain tasks.

6. The hybrid cloud is the future. The future of the cloud is a combination of private, traditional data centers, hosting, and public clouds. Of course, there will be companies that will only use public cloud services for everything but the majority of companies will have a combination of cloud services.

7. Managing the cloud is complicated. This is not just a problem for the vendors providing cloud services. Any company using cloud services needs to be able to monitor service levels across the services they use. This will only get more complicated over time.

8. Security is king in the cloud. Many of the customers we talked to are scared about the security implications of putting their valuable data into a public cloud. Is it safe? Will my data cross country boarders? How strong is the vendor? What if it goes out of business? This issue is causing many customers to either only consider a private cloud or to hold back. The vendors who succeed in the cloud will have to have a strong brand that customers will trust. Security will always be a concern but it will be addressed by smart vendors.

9. Interoperability between clouds is the next frontier. In these early days customers tend to buy one service at a time for a single purpose — Salesforce.com for CRM, some compute services from Amazon, etc. However, over time, customers will want to have more interoperability across these platforms. They will want to be able to move their data and their code from one enviornment to another. There is some forward movement in this area but it is early. There are few standards for the cloud and little agreement.

10. The cloud in a box. There is a lot of packaging going on out there and it comes in two forms. Companies are creating appliance based environments for managing virtual images. Other vendors (especially the big ones like HP and IBM) are packaging their cloud offerings with their hardware for companies that want Private clouds.

I have only scratched the surface of this emerging market. What makes it so interesting and so important is that it actually is the coalescing of computing. It incorporates everything from hardware, management software, service orientation, security, software development, information management,  the Internet, service managment, interoperability, and probably a dozen other components that I haven’t mentioned. It is truly the way we will achieve the industrialization of software.

Yes, Virginia, there is a SOA!

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

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.

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

It 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.

Packaging SOA: What serves the customer?

I was talking to a CIO the other day about the whole area of Service Oriented Architectures. It was one of those interesting probing discussions around key players, emerging technologies and the like. One of the interesting topics that came up was around packaged software. This CIO was confused about a major issue. What is the benefit and danger of implementing a package software offering that has all the industry best practices, business process, and middleware integrated together. What are the opportunities and risks of this approach? Likewise, what are the risks of buying piece parts and integrating them together?

This is an important question and one that I have obvious opinions about. I think that it can be dangerous for companies to buy a too well integrated SOA environment from a single vendor. While it might seem like the path of least resistance might be to just buy an entire software suite from a company like SAP or Oracle and be done with it. While this may seem like a pretty straight forward question it actually is much more complicated. On the plus side, a customer could get a head start by using a SOA model where everything is designed to work together. On the other hand, I would submit that this approach is antithetical to the reason companies are approaching SOA in the first place. Companies are moving to SOA in order to create a flexible, modular environment where it is easier to add or subtract components based on either a new business initiative or a new innovative technology. If the SOA platform is too well integrated, change becomes hard.

So, what did I suggest to my CIO friend? I told him that it is better to look at packaged software as components in an overall SOA strategy rather than the lynch pin of that strategy. It is better to begin with the overall business strategy and an Enterprise Architecture and select technologies that are designed with standardized interfaces. The foundation should be based on loose coupling of services.

A packaged offering can work if customers finds a package that is standards based and extensible does not lock them into one perspective on the world. I think we’d all like to have a world where you just buy what you need off the shelf and life is good. But unless you are buying a commodity, I think the world is still too complicated for packaged SOA. Are there SOA commodities? Of course, for example, a set of best practices that are well understood across a broad spectrum of customers can be packaged as a business service and used broadly. Even a large service such as those offered by ADP is an example of a service offering that is well understood and not differentiated. Who would want to write their own service for managing payroll.

I do think that there will be a time when the SOA software market has matured to the point where building blocks are mature and well structured enough to be able to link together services smoothly and easily. But I don’t think we are there yet…do you? Let me know what you think.

How does SAP turn 250 million lines of code into modular services?

I didn’t attend the SAP Sapphire conference this year. I simply had too much going on so I gave myself a pass. But that doesn’t mean I wasn’t paying attention. I am thinking about the fact that SAP’s application environment has more than 250 million lines of code. I would guess that this is probably the biggest application suite on the face of the planet. If I am wrong, let me know. In that context, I was thinking about what does it mean to position the company for a Service Oriented Architecture. In fact, can you credibly claim to be service oriented with that much code in one environment? Now, I suspect that if I were having this discussion with the software gurus at SAP they would claim that they have restructured that code to create a modular architecture. Now I wouldn’t dispute the possibility that a lot has happened since the company first brought R/3 to market as a client/server application environment. But I am wondering how far they have been able to take this. I would suggest that even under the best of circumstances that it would super human effort to turn 250 million lines of code into a set of business service modules. I have one other question for SAP software architectural gurus…how do you turn NetWeaver into an open middleware platform independent of 250 million lines of application code?

And then I thought about Oracle’s approac to business process management.
So, what about Oracle? Are they really very different from its arch rival SAP? I would say yes and no. No, in that if you add up all of the code from all of the packaged applications it has purchased over the past five or six years, it would probably have as many lines of code. The difference might well be that Oracle ends up with a series of applications that are integrated in name only. They are stuck with customers who simply have no interest in oracle’s grand vision for a single applications environment. They just want to continue using the JD Edwards or Siebel application that they have come to depend on and that has been customized for their requirements. The typical customer has no interest in retraining hundreds of employees on something new. So, I thought that Oracle was very pragmatic in coming out with a set of process templates that can create business process orchestrations leveraging existing applications as they are. It will be interesting to watch how this works and the impact on Oracle’s elaborate Fusion middleware strategy.

 

Trolling through SOA land — not a straight line

In our family we often talk about straight lines in the context of getting to an outcome. So, when you are looking at a teenager, it is natural to hope that he or she becomes a responsible citizen with a good job and a nice family. But it doesn’t happen over night. In some cases the kid does exactly what you expect and the results are easy to predict. But, in most cases, your kid takes two steps forward and one step back – and might even go sideways for a period of time. Eventually, things have a way of working out. This is the way I am looking at SOA – it isn’t going to happen in a straight line. Organizations are going to zig and zag. They are going to take a few positive steps and do great things and they are going to fumble and have problems. But, in the end, I do believe that most companies will get there.

 

I get frustrated with the implication that there is a straight line to implementing SOA. It is not straight at all. First, there are still many pieces that will have to be developed before organizations are ready for wide adoption of SOA on an enterprise basis. For example, there needs to be a mechanism to manage the SOA components from a performance, security, and quality perspective. There has to be what we at Hurwitz & Associates are calling the SOA Supervisor. It’s a necessary software component, a control mechanism that allows organizations to cleanly join and loosely couple services together and have them act as a virtual system. That does not exist today, except when a company hires an experienced team to do the work. Even then I think it would take years. to arrive at a full solution.

But as we wait, I think that you will see SOA move to a line-of-business focus. This is the only way in the short term that organizations will be able to successfully implement SOA in a scalable manner. This has already started to happen and will pick up speed this year. I am expecting that the major vendors will start delivering SOA stacks that are customized for specific industry sectors. Some of these sectors will be broad, such as insurance while others may be very specific to a submarket – paper process manufacturing, for example. So, is this a packaged software or SOA infrastructure? The answer is yes.

 

Do you have a Chief Software Quality Officer?

Software quality has moved out of the back office to center stage as software becomes the personification of business. Do you have the position of the chief quality officer within your IT organization? I would guess that this is not a position that appears on anyone’s organizational chart. Typically, the QA department has been one of the least visible parts of most IT organizations. In many instances, QA experts are brought in at the last stage of bringing a project to fruition. No one really looks forward to the lone voice pointing out that something doesn’t seem quite right. After all, there are smaller staffs to do an increasingly large list of projects. At the same time, I don’t know any CIO who would say that quality isn’t extremely important.

I contend that as organizations increasingly embrace service oriented architectures and web services interfaces, they will have to put as much attention on quality assurance as they do development. It will come as no surprise to anyone that applications that used to be hidden neatly behind firewalls are exposed to customers, partners, and suppliers. Companies have been forced to expose applications to their constituents in order to be dynamically responsive. To be dynamically responsive, organizations need to be able to leverage their computing resources to respond in real time to opportunities and threats. Insightful organizations are making the transition to Dynamic Response through the adoption of Service Oriented Architectures (SOA) and Web Services interfaces.

How does quality change with this technology innovation? When organizations begin to move from traditional applications development techniques to SOA, they are focused on creating components of software that can be reused in many different situations. For example, a financial services company might create a “service” or component that handles order processing. This service has been designed to be used in every application where an order process is required rather than having developers write a program from scratch each time. In addition, the order processing service has been so well designed so that the company can offer order processing as a service – and a revenue source – to other companies. In other cases, this service will be a critical part of a partnership. For example, companies like Federal Express have partnerships with thousands of companies who need package delivery services for products they sell online. Therefore, Federal Express needs to have an application that can sit on all of their partners online sites. If the shipping business service that Federal Express places on all its partner sites suffers from bugs or performance abnormalities, business is at risk. This is where quality comes in.

This approach towards reusable components or services changes what quality assurance is all about. In traditional method of testing for quality and reliability assumes that you can develop once, test once, and move on. With new generation component or service based applications, development cycles are cyclical requiring an iterative testing process. Clearly, the environment for quality in application code is changing requiring a new approach to quality assurance. How should you approach this area? Below are some of the best practices for Quality Assurance in the Dynamic Response era: Create a cross-functional task force that focuses on the role of QA software development. This insures that quality is discussed with members of the business unit, not just the development team. Educate the application development and deployment teams on the role of QA in their success. With sufficient education, QA members will be consulted early and often. Insure that QA management is part of the team determining the new vision of applications. When QA management is part of development, the resulting applications are easier to fix and test. Educate business management on the importance of quality testing. Business management can become a key ally in assuring software quality To impress upon the business the importance of quality, tie quality initiatives into corporate imperatives such as Sarbanes Oxley and HIPPA. As software continues to expand in importance to corporations, quality will continue to move out of the shadows into the forefront of the IT organization. Innovative CIOs understand that the additional leverage and benefit they are beginning to achieve through Service Oriented Architectures and online partnerships are only as good as the quality of those components. As these set of software components are reused in many different situations, a single error can cascade to impact quality across a vast value chain. With this in mind, it might be a good idea to appoint a chief software quality officer.

Creating containers for Service Oriented Architectures

In the old days when we built applications, it was  from the perspective of the specific problem they solved.  An application might be built to enable a company to bill its customers and pass payment on to suppliers; an application would be created to capture credit information or to create a supply chain. In each of these instances, the application was built as a standalone entity contained within an architected application. In most cases today, this hasn’t changed. What is starting to change is the nature of what an application is and how it works.As businesses start to move away from this conventional programming model of creating self-contained applications, they start to build business components or services. This is an exciting trend that will ultimately offer a much higher level of predictability in the development process. Developers will use predefined business components that have been tested and contain the approved corporate policies. In order to make these business components usable, the developer knits them together with industry standard web services linking technologies. So far, this is simply an evolution of what we have been experiencing for decades. However, the similarities end here. We are about to embark on a new era where we have to think differently about the nature of an application. Many companies that are starting to plan for service oriented architectures haven’t come to terms with the redefinition of the application.

This became apparent to me the other day when I had a meeting with the CIO of an insurance company. We had been talking about service oriented architectures and web services and new models of creating this predictable value. While he has already started helping his organization move in this direction, he was confused. What is the container? Into what do you put this set of linked business services? It isn’t simply a piece of code, and it isn’t a traditional application with a beginning, middle and an end.so, what is it? Does it simply float in space? And just as important, how will we manage this composite environment so that its performance is predictable? These are excellent questions and ones that I believe is being asked silently across our industry. It is not being articulated very often because no one wants to be the first to say that ‘the emperor has no clothes’, so to speak.

The reality is that the next innovation that will happen in the evolution of true dynamic response environments is the creation of the container model. So, what IS a container? A container is the composite entity where the components needed to create a virtual application exists. The container understands both the context of how the pieces relate to each other and how they must act in order to be manageable. Unlike traditional application environments, a container does not assume that the pieces inside are permanent. What can we expect to see? We will see vendors come up with constructs that will begin with something like a portal and move it to a much more component-like approach and with much more visual context. We will look back at what we call “portals” today and see that they are static and inflexible, albeit a good start down the road. In other instances, software companies are positioning messaging buses as foundational pieces. Still other vendors are positioning the vertical application as the foundational environment of the future.

However, none of these are true containers. Yet, it is only a matter of time before companies that are creating service oriented architectures and associated products will design containers that put their fingerprint on SOA and composite applications.

So, what should you do about containers for SOA? Wait until vendors get their act together and develop products? Continue to create stove pipe applications until there are some containers you can use? Should you simply use portals to get the job done? My answer is ‘no’ to all of the above.

This is a time for management to take the lead and provide vendors with a specification. Containers should be designed so that they can project the business value of the composite of a group of business services. When looking at a container like this, business management will understand what the composite does and can easily access the goals and underlying business rules and processes. Containers can be linked together with a visualization of what it means to link two business containers together. In effect, I am describing how applications of the future will be designed. This increased level of visualization will make the dream of component architectures and service oriented architectures come true: first, developers will create modular business services; then, business management will take the right services, apply the right business policies to these services, and then link them together to make the business work. Add to this the necessity of applications management so that the pieces that are placed into containers can withstand the inevitable scaling when business services are linked together. So, join me in helping to push the market forward. It is incumbent for CIOs to push their vendors to create containers and container management so that Service Oriented Architectures promise can be realized.