Viewpoint: June 25, 2002
Confusion reigns supreme in the Web services world (for a brief, business-oriented view of Web services technology, see my article “Your Next IT Strategy” in Harvard Business Review). Technologists unwittingly contribute to this confusion. Let’s take two examples. Read the technology press and you hear two themes. First, Web services are about the dynamic composition of applications from many micro-services. Second, Web services will be deployed first within the enterprise and then migrate beyond the firewall.
Start with this notion of dynamic composition. The average non-technology executive hearing this scratches his/her head and says, “Great, but where are all the micro-services to be knit together?” We’ve got the proverbial chicken and egg problem. We can’t compose, if we don’t have micro-services. We won’t have micro-services unless there’s a lot of composition going on.
Dynamic composition is a great vision of a distant future. But what are we going to do with Web services today? The answer is pretty boring, at least for the technology visionary. We’re going to use the technology in a very mundane way, to build low-cost and flexible connections across very large and diverse applications already installed in companies. While mundane from a technology perspective, this capability gets a business executive’s juices going. “You mean I can take 15% out of my operating budget with modest investment and short lead-times by eliminating the swivel chair connections I now use to connect major applications?” Yup.
In these economic times, that’s a compelling value proposition (for more on early experience with this value proposition, see my article “Your Next IT Strategy” in Harvard Business Review) Equally importantly, it gets us out of the chicken and egg problem. The applications are already in place. All we’re doing is automating connections. This process will start to build necessary skills and experience, and then the light will go on. Other uses of this technology start to come into focus.
To the dismay of the technology visionary, these uses of Web services still involve large legacy applications. The next stage will enhance the functionality of these legacy applications. Today, the big frustration is that these mega-applications (e.g., procurement, inventory management, order entry, billing) are solid like the Rock of Gibraltar. That’s the bad news. Try adding a new feature – let’s say you have a great new product you’d like to introduce to your customer and you need to modify your order entry system. Stand in line – the queue begins way over the horizon and maybe by the time you retire you might actually get near the front of the queue.
Web services technology will help to more quickly add functionality to existing applications. Rather than implementing new functionality as part of the core application itself, new modules can be developed on the side and accessed by the core application through Web services interfaces (see the example of CommerceOne using Citibank’s payment processing engine as a way to enhance its electronic marketplace platform discussed in my “Break on Through to the Other Side: A Missing Link in Redefining the Enterprise” working paper. This expands the range of programming resource that can be mobilized and the queue begins to shrink to a more manageable size. Once again, the chicken and egg problem is minimized. More skill and experience accumulates around this new technology.
Now we’re ready for a third stage. Sorry, it still doesn’t involve dynamic composition of major new applications. It does involve development of major new applications using Web services technology. Application developers will start to have enough skill and experience to begin to attempt the design and implementation of major new applications with this new technology. They will also see the advantages of employing this new technology in terms of flexibility to incorporate new features over time. While these applications will be designed around major components or modules, these components or modules will be largely fixed, at least at the outset. We won’t be dynamically composing these modules – they’ll already be in place.
The fourth stage begins to introduce dynamic composition, but it won’t involve micro-services. Instead, we will be working to dynamically bring together larger application services in process networks (for more on process networks, see my working paper on “Orchestrating Loosely Coupled Business Processes: The Secret to Successful Collaboration”). The goal here will be to access and mobilize very large applications of business partners to tailor broader business processes to meet the needs of specific customers or products.
Finally, after much effort, we may eventually reach the fifth stage where we see the full unbundling of larger applications and the ability to compose applications on the fly from micro-services. By then, there will be lots of micro-services around in the form of elements of legacy applications that have been exposed using Web services interfaces, plug-ins operating around larger legacy applications and components from major new applications designed with Web services technology. More importantly, we might actually have a critical mass of skills and enabling services to help us manage dynamic composition of applications in ways that support, rather than jeopardize, mission critical activities and processes.
Now, by describing this progression as a series of stages, I don’t want to imply that these are completely sequential phases. We can see examples of all five stages in play today in one form or another. The real question is “where is the bulk of economic activity concentrated at any point in time?’ In answering this question, it is helpful to think of the five stages as overlapping waves of activity.
I know that the technologists will quarrel with me. They will rightly assert that even the mundane connections I talk about in the first stage are examples, although admittedly modest, of dynamic composition of applications. Technically, they are of course correct. My concern is much more with understanding, especially by non-technology business executives. The words and examples used by technologists used to describe dynamic composition of applications are rarely geared to the more mundane examples of the first stage. Instead, they rapidly and eloquently paint grand visions of micro-services floating in the ether and knit together to create entirely new applications on the fly.
Yes, dynamic composition of applications is a marvelous vision of the future . . . the distant future. Executives want to know where the economic value is today. By focusing on dynamic composition of applications, technologists obscure the real opportunity today. They also under-estimate the challenges in realizing this longer-term vision. The migration path may be less exciting for the technology visionary but, by understanding it, we might actually make the distant future a more plausible vision.
No, I haven’t forgotten about the second source of confusion – the view that Web services implementation will start within the enterprise and then move beyond the firewall. I’ve just run out of time, so I’ll hold that thought until next time.
