Creating Containers for Service Oriented Architectures

May 25, 2004

Creating Containers for Service Oriented Architectures

by Judith S. Hurwitz

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

Judith Hurwitz is the President of Hurwitz & Associates, a consulting, research, and analyst firm focused on emerging software markets. She can be reached at

Newsletters 2004
About Judith Hurwitz

Judith Hurwitz is an author, speaker and business technology consultant with decades of experience.

Leave a Reply

Your email address will not be published.