Creating More Capability: The Emergence of Service-Oriented Architectures1
By John Hagel, III and John Seely Brown – 10/20/2003
Traditional IT Architecture as a Barrier to Flexibility
This new strategic architecture is very difficult to implement in companies operating with traditional hard-wired IT architectures. The emphasis on aggressive waves of near-term operational and organizational initiatives places enormous strain on IT architectures that assume a more stable business context. It is not impossible to adopt this kind of strategic architecture – witness the examples of WalMart, Dell and Schwab – but it is certainly not easy. Given the constraints of these architectures, it is remarkable that even a few companies were able to overcome these obstacles and pursue more dynamic approaches to business innovation. Yet, it is revealing that the same few companies are always cited when looking for examples of continuous business innovation. Most companies have simply had too much organizational inertia to overcome, and hard-wired IT architectures have been a major impediment to rapid movement.
These hard-wired IT architectures make it expensive and difficult to support smaller, incremental modifications to business practices. As a result, these architectures paradoxically encourage executives to support "big bang" approaches to IT spending for many of the same reasons that these architectures encouraged hard-wired five-year strategy approaches. Small changes to the IT architecture are so challenging that it was difficult to justify these efforts. On the other hand, major business initiatives with very large pay-offs often could overcome the significant organizational inertia created by these IT architectures. There was only one problem: "big bang" approaches to IT spending rarely deliver on their expected pay-offs. Companies poured billions of dollars into ERP projects and Internet initiatives designed to transform the business, discovering to their dismay that the returns were smaller, longer in coming and far more uncertain than they had anticipated.
Large-scale transformational projects require massive resources to execute, but the returns are usually so far down the road that it is difficult to sustain the organizational commitment and momentum necessary to deliver the returns. Even where this commitment and momentum can be sustained, these projects often founder in terms of lack of adequate understanding of how work really gets done or inability to adapt rapidly to changing market conditions. Rapid incremental waves of business innovation, shaped by clear near-term operational performance milestones, are generally much more effective in delivering real business value from IT investments.
IT architecture has become a choke point for operational and organizational initiatives. If we want to implement more agile strategies, we need to confront this choke-point head on. Let's look at a specific illustration. Imagine a company producing and selling farm machinery. The senior management team of the company has looked ahead five to ten years. They have determined that the best way to continue to create economic value is to evolve into a customer relationship business, deepening relationships with large agribusiness customers and serving a broader range of customer needs based on a better understanding of the customer's business.
That's an ambitious longer-term direction for the company. What can the company do operationally over the next six to twelve months to accelerate movement in this direction? Let's say it focuses on two initiatives. First, it wants to provide its customers with better visibility on product order status, both as a way of reducing its operating costs (the company maintains a larger order processing staff that consumes much time answering customer inquiries about order status) and to improve customer service. Second, it wants to expand the range of products it sells by sourcing some complementary products from third party product manufacturers and re-selling these products.
These aggressive operating initiatives run into a formidable obstacle known as IT architecture. It turns out that three different plants in the U.S. make the farm machinery produced by this company and two of the plants were acquired from other companies. As a result, the plants use different application software to run their operations. If you wanted to check on order status, you would have to access one of three different applications with very different application interfaces and ways of presenting product information. In fact, this is why the order entry staff spends so much time on order status queries, but at least they have developed the expertise required to handle the three systems. What would be required to make this information directly accessible to the purchasing systems of customers? The company would have to implement custom designed connections between each of the customers and the three manufacturing plants. Designing each of these connections would require a deep understanding of the applications at either end and the functionality would be specific to these applications.
And that's just for the first operational initiative. If we also want to re-sell products from third party manufacturers and provide the same level of order status information to customers, we would also need to create custom-designed connections between each customer and each of the supply chain applications run by our product suppliers.
The complexity, cost and lead-times mount – and we're still only talking about the initial deployment. Let's say we decide later that we want to add some functionality to these connections – perhaps giving customers some limited ability to modify orders before they are shipped. That functionality would have to be coded into each of these connections. While there might be some common code that could be leveraged across all these connections, each enhancement would need to be tailored to meet the custom design of the connection. Let's also imagine that some of the first wave of product suppliers don't work out and we have to drop them and add some others. It is unlikely that we will be able to leverage much of the initial effort to connect the initial suppliers because each connection is custom designed. So, complexity, cost and lead-times continue to mount.
Is it any wonder that business executives become discouraged? If you want to implement anything, it will be very expensive and take a long time. If you then want to change anything, the complexity and expense escalates. In fact, complexity and expense increases exponentially as the number of applications and databases grows. The more complex the connections, the harder it is to add functionality over time.
The problem is with the IT architecture. IT architecture refers to the way technology resources are organized in order to perform tasks – much in the same way that businesses are organized in terms of definition of roles and relationships. Because IT was expensive in the early days of computing and delivered relatively limited performance, efficiency was the primary objective shaping the definition of IT architectures. Roles and relationships were very tightly defined to optimize use of scarce and expensive technology resources. Flexibility was very expensive.
The word "architecture" is generally quite misleading for what most companies have today. Architecture calls forth images of the neat schematics of an architect, carefully thinking through in advance all the needs of the occupants of a building and designing a structure that optimally meets these needs. Today's IT "architectures" are far better described with a geological metaphor – imagine geological sediments accumulating, one on top of the other, in different continents. In this case, the sediments are the various generations of information technology that have been deployed in large enterprises – mainframes, minicomputers, desktop computers, servers and mobile access devices in terms of computing power and equivalent generations of electronic networks. Rather than ripping out previous generations of technology and designing a greenfield architecture to more effectively exploit the capabilities of new technology, companies deployed new technology next to existing platforms. Where necessary, they implemented custom-designed connections to create a semblance of integration. These custom-designed connections were also necessary to bridge across departmental silos and enterprise firewalls – the equivalent of continents in the geological metaphor. Geological time is also a better way to capture the lead-times required to move across these sediments and continents, especially as the complexity of the connections increased.
As the above description suggests, traditional IT architectures are a problem for business because of their way of coping with diversity and the growing need to connect IT resources to support business operations. Custom designed connections are very efficient in their use of IT resources, but they are expensive to implement and even more expensive to modify over time. These custom designed connections are aptly described as "hard-wired" because of their lack of flexibility.
Shifting to the Next Generation of IT Architecture
The Service Concept
We are on the cusp of a major shift in IT architecture, enabled by further price performance improvement of processing, storage and networking technology. The new IT architecture that is just beginning to emerge goes by the name of "service oriented architecture" (SOA). The name focuses on a significant shift in the view of software resources. Software has traditionally been viewed as functionality designed to support a specific business context and installed at the site where it will be used. In contrast, services are designed without knowing in advance the exact uses and tasks they will be called upon to support and are accessed when needed from wherever they reside. The location of the software becomes largely irrelevant from the user perspective.
This service concept represents a profound shift in the mindset of technologists. Rather than operating at a much more granular level of individual actions performed upon data, the services concept's power is best realized when it affords opportunities for technologists to operate at a higher level, viewing the building blocks of the architecture in terms that much more closely mirror the way business executives would describe their business. In effect, the service-oriented architecture could be viewed as a business operating system, generating new services from pre-existing building blocks and then orchestrating these services to support changing business needs. In this way, the SOA becomes a perfect complement to more flexible strategy architecture, with their emphasis on rapid, near-term waves of business initiatives.
This service approach is especially helpful as companies wrestle with the challenges of coordinating activities within an extended supply chain or a diverse set of distribution channels, requiring technology resources to be connected across multiple enterprises. Our traditional IT architectures have tended to be enterprise-centric – they assume that the relevant technology resources are all located within a single enterprise. Some of the greatest challenges in automating business activities in the past occurred when multiple business partners were involved. The automated connections, if they existed at all, tended to be very expensive, complex and difficult to modify.
If services can be accessed when needed from wherever they reside, this reduces the need for users to specify functionality in advance, since the functionality can now be accessed on demand. This has profound implications in terms of enhancing flexibility. Of course, it assumes that a broad range of highly specialized services can be quickly accessed and brought together to address a specific business need. Price performance of technology is essential to deliver this capability. For example, relatively inexpensive, high bandwidth communication networks are necessary to provide reliable and quick delivery of required software functionality.
Flexibility does not necessarily mean that companies will abandon all relationships and resort instead to transaction specific deals with the "best" (or cheapest) business partner of the moment. For many good reasons, much of business activity is likely to be conducted in the context of long-term trust-based relationships. The flexibility provided by service oriented architectures is much more likely to be valuable in broadening the number of business partners and making it easier to access specialized capability as required within established process networks.
Creating New Kinds of Connections
For this service approach to deliver real flexibility, traditional approaches to connecting technology resources also need to be re-thought. In the past, we relied on hard-wired connections. Since all the functionality required for the business needed to be defined well in advance, it made sense to design connections across technology components based on a deep understanding of the underlying functionality in each component. This makes the connection more computationally efficient since each connection was designed specifically for the task at hand and the performance of the connection could be optimized to use as little resource as possible. But there was a catch. If the functionality at either end of the connection changed, the connection itself had to be redesigned. In the 1950's and 1960's when industries and markets were more stable, this was not a high price to pay in return for improved efficiency. As industries and markets became more dynamic, this represented a more significant barrier. Companies today consume large portions of their IT budgets on integration activities – establishing new connections and redesigning old ones to keep up with changing times.
Service oriented architectures rely upon a different approach to establishing connections. They favor loosely coupled connections. In this approach, all the information required to establish a connection – what outputs the software can deliver, how those outputs need to be accessed and who is authorized to access these outputs – is described in the interface of the service. In the example of the farm machinery company cited earlier, the interface to the manufacturing application might specify that it can provide certain information about the manufacturing status of a product and indicate what protocols and standards the user of the service would need to use in order to access this information. The interface however would not go into detail regarding how this information is generated – all the user of the service really cares about is understanding what information can be accessed. More traditional hard-wired connections require the designer of the connections to understand in detail how the information is generated in order to be able to efficiently access the information.
Of course, the information provided in the interface needs to be presented in a way that is broadly understandable. This is the key role for standards and protocols in supporting loosely coupled connections. Unless standards and protocols are widely adopted, the range of feasible connections becomes very limited, just as someone who speaks only Turkish would have a hard time delivering services to businesses around the world. The rapid spread of eXtensible Markup Language (XML) as a foundation standard, and a whole series of other standards and protocols derived from XML help to provide an effective framework for creating broadly understandable, and accessible, interfaces.
If these standards and protocols are in place, however, a much more flexible set of connections can now be established. Since these standards and protocols can be "read" and understood by computers, connections can be automatically created as the need arises (1). The connection focuses on understanding the output of the service rather than the fine-grained methods used to generate that output. This means connections can be established much more quickly without requiring deep understanding of the underlying functionality at each end of the connection. In effect, a service-oriented architecture represents a modular approach to organizing IT resources. As with all modular approaches, the key requirement is standardized definition of interfaces so that modules can be quickly and easily mixed and matched to meet the requirements of the moment.
This approach to loose coupling is critical to enabling more flexible delivery of services. As the recent McKinsey Quarterly article "Designing IT for Business" suggests, many companies are carving out IT resources to be delivered as shared services, either within a single company or across multiple companies. Sharing resources is often more efficient than proliferating resources that perform the same function. The challenge is how to connect to these shared services. If traditional hard-wired connections are employed, rigidity begins to set in and the ability to adapt to changing business needs may be compromised. The only way to make shared services truly supportive of rapidly evolving businesses is to deliver them with loosely coupled connections.
Once again, though, loose coupling does not imply short-term relationships. Even in long-term relationships, both parties are rapidly evolving and the relationship itself needs to evolve. Hard-wired connections tend to make relationships brittle – they often break down because the relationship cannot adapt rapidly enough to the changing needs of the partners. Loose coupling can help to build more robust relationships by providing enhanced ability to adapt to new requirements.
Loosely Coupled Services in Action
Let's turn back to our example of the farm machinery manufacturer to illustrate the benefits of an SOA. Recall the mounting complexity of proliferating hard-wired connections that created such an obstacle in implementing operational initiatives. How would an SOA support these initiatives?
An SOA would begin by "exposing" the necessary functionality in each of the supply chain management applications through the creation of a standardized interface, providing the information necessary for other applications to understand what functionality is available and how to access it. In this way, the relevant functionality regarding order status would be available as a service that could be shared by any other application needing to access this functionality and using the same standards and protocols.
This service would be accessed through a loosely coupled connection, meaning that the connection would only be established "on the fly" when needed because all the information required to establish the connection would already be represented in the service interfaces. If the consuming application (in this case, the customer's procurement software) did not already know which manufacturing plant to query for the order status, a directory service could help the consuming application identify the appropriate services to access. A variety of enabling services like the directory services and security services to support the connections could also be delivered as loosely coupled services and shared across all connections, rather than designed into each of the connections in advance.
The advantages of this approach are significant. The traditional approach required a new connection to be custom-designed in advance for each pair of resources that might need to interact with each other. The SOA approach requires a single investment to "expose" (in other words, to describe, register and provide pointers) the resource as a service. Once that investment is made, the service can be accessed by any other application with an interface adhering to the same widely available standards and protocols. That initial investment is amortized further each time a new connection is created to that service, in contrast to traditional hard-wired connections where there is less reusable code and each new connection represents a significant programming effort. Because of the significant effort required to create these hard-wired connections in traditional IT architectures, any operating initiative involving new connections requires significant lead-time. With the loosely coupled connections of SOA's, new business partners and customers can be added quickly and efficiently, especially if these entities have already exposed their resources as services.
Requirements for Broader Adoption
To avoid misunderstanding, these service oriented architectures are only now in the earliest stages of emergence. The current deployment of Web services technology represents a promising early initiative in the direction of service-oriented architectures. Web services technology – in particular, the foundation standard of eXtensible Markup Language (XML) – provides a major advance in terms of creating ubiquitous standards to use in presenting data and defining the interfaces required for loosely coupled connections. However, even for companies like General Motors, Merrill Lynch and Eastman Chemical that have started to focus on the implications of service oriented architectures, these architectures remain largely conceptual drawings rather than broad-based implementations. Early implementations of Web services technology tend to be very limited in scope and targeted on a specific area of the business.
Far from being a cause for skepticism about the potential of these broader architectures, these early implementations actually create optimism about the business appeal of this architecture. Not only can it provide much more flexibility in supporting business operations, but service oriented architectures can also be implemented in a more incremental fashion than previous generations of IT architectures. Each stage of implementation can be geared to specific business initiatives and, with relatively modest investments and short lead-times, deliver tangible business value. In other words, these SOA's can be deployed in a manner very consistent with the strategic approach outlined above. In one respect, this is what makes these SOA's so powerful: they represent a true inflection point in terms of enhanced flexibility, but they can be implemented incrementally, leveraging vast resources that are already in place by exposing these resources and making them accessible as services.
Again, to use the example of the farm machinery manufacturer, this company does not need to shift its entire IT architecture to enjoy the business benefits of SOA capability. It can begin with a focused effort to support the specific operating initiatives discussed earlier. Relatively few IT resources will be accessible in this company's SOA at first – they will be the supply chain applications in the manufacturing plants – but they will be the IT resources most relevant to near-term operating initiatives. The business benefits – in this case, the operating savings from direct customer access to order status data and revenue benefits from enhanced customer satisfaction – will help to fund this first stage in the transition to an SOA.
The shift to this architecture is pragmatic in another sense as well. SOA's do not require removal of existing IT resources. In fact, they were developed specifically to help businesses to get more value from the IT resources already in place. Over time, SOA design principles will lead to the development of entirely new services but, in the early stages of deployment, the bulk of service creation will focus on exposing existing resources and making them more accessible through an SOA.
To be sure, many obstacles will need to be overcome before these architectures become pervasive in the business world. Web services standards like XML provide only a framework for developing shared meaning regarding the content of business tasks. Much hard work will be required for businesses to develop and refine this shared meaning over time.
SOA standards and protocols will need to become much more robust before they can effectively support the full functionality required to support mission-critical, long-lived transactions. Today, the first generation of Web services standards and protocols are used largely to automate publishing and distribution of business information, rather than automating business processes like the complex and lengthy series of interactions required to execute and to close a securities transaction or a travel itinerary involving multiple travel providers.
Broadly distributed service oriented architectures also demand new trust frameworks – both at the level of technology, as in the use of robust authentication techniques, and at the business level, focusing on shared meaning, incentive structures and use of risk management programs like performance bonds. These trust frameworks will be required to support effective sharing of technology resources, especially as we move across enterprise boundaries. We are just beginning to understand how these trust frameworks must be designed and managed.
The Business Significance of SOA's
SOA's will represent a true inflection point in the capacity for business innovation. With more tightly coupled architectures, the business context had to be specified in advance and subsequent modifications to the software were expensive and difficult to make. With services designed to be context-free, companies can move more quickly because they can mobilize services that are already available and deploy them in new business contexts.
Loose coupling makes it easier to experiment with new ways of doing things at the local level. It reduces the risk that changes in practices at the local level will ripple through business processes and create unintended consequences in other areas. This will enhance the ability to rapidly prototype new products, business process redesigns and even new business models because it reduces concerns about potential disruption of existing business activities.
In the case of the farm machinery manufacturer, once the hard-wired connections are deployed, executives must move very cautiously before implementing any changes in the resources being connected together. Let's say the farm machinery company wants to streamline its manufacturing operations in one plant and makes some corresponding modifications to the manufacturing application used in that plant. Each custom-designed connection between that manufacturing application and each of the customers would need to be re-tested and possibly reconfigured because the proper functioning of the connection depends on assumptions regarding how the information is actually being generated. Where hard-wired connections have proliferated, business managers are reluctant to modify anything. Rather than freeing business managers, these connections begin to resemble prison bars, making it harder and harder to move in any direction. Of course, the manufacturer could reduce complexity by creating a shared portal enabling customers to connect to the manufacturing plant operations through a common platform. Without a service oriented architecture, though, any changes to the applications running in one of the plants will still likely require expensive and time consuming changes in the connections to the customer portal.
Loose coupling can be enormously liberating for business managers in the farm machinery company. They can try out a new business process in one of the manufacturing plants without worrying about unanticipated disruptions in the functions of customer IT systems.
Loose coupling also supports business innovation beyond the boundaries of the enterprise. This method of connecting technology resources can be very helpful in automating business connections with other enterprises, making it easier to add value to customers by accessing resources owned by other companies. As we saw in the example of the farm machinery manufacturer, the task of implementing custom-designed connections with customers and business partners can become overwhelming in its complexity, especially since the diversity of technology platforms multiplies and a deep understanding of each technology platform is required to build efficient custom-designed connections. SOA's are particularly valuable where there is not a single decision-maker (as in the case of a strong CIO within a company or a company with significant buying power in dealing with its suppliers) who can enforce a common set of platforms on participants. Diversity of platforms in these situations is a given. This diversity demands an SOA that embraces diversity in resources and concentrates on implementing appropriate standards for the interfaces to connect to each other.
In parallel, this loose coupling capability will also accelerate a more fundamental unbundling of the enterprise, allowing companies to focus more tightly on the activities that they are distinctive in. Companies will use loosely coupled SOA's to rebundle the assets and capabilities required from a broader range of companies. In the example of the farm machinery manufacturer, the enhanced ability of SOA's to quickly and cost-effectively establish automated connections with other product manufacturers will accelerate the movement of this company towards its goal of focusing on its core strength – the customer relationship business. At the same time, the SOA can help in offloading more and more of the product manufacturing activities to more specialized companies with distinctive advantages in this area since the automated connections will provide more visibility and coordination capability in dealing with contract manufacturers.
But their impact does not stop here. Loose coupling makes it easier to automate connections across business activities. This in turn automatically generates rich information about the performance of the connections and the outputs at each end, simply as a by-product of managing the connection. In contrast, if the connections are maintained manually, capturing the information requires an additional, time-consuming step. The automation of these connections provides business decision-makers with much better information about overall IT and business performance, including systematic identification of the exception conditions that drive a lot of the inefficiency of business processes. For example, the farm machinery manufacturer would generate detailed information about customer inquiries into order status as a by-product of its automated connections. This information could help the manufacturer to further improve customer service by systematically cataloguing the information regarding order status sought by customers and providing a basis for designing proactive order status reports for certain types of customers and types of orders.
The flexibility of SOA's also makes it easier to mobilize appropriate stakeholders and to equip them with timely information and other resources required to address mundane (and not so mundane) breakdowns and exception conditions. These architectures similarly help to capture the learning from these experiences and to quickly modify the practices necessary to support smoother operations. Rapid performance improvement based on continual refinement of business practices and processes becomes possible with tighter performance feedback loops, more effective mobilization of appropriate stakeholders and enhanced capacity for specialization and local experimentation.
Earlier, we made the case that new strategic architectures will focus on near-term business initiatives against the background of a compelling long-term direction that helps to provide orientation for, and make sense of, the choices required today. SOA's enable this strategic architecture by providing more flexibility for the near-term business initiatives but also creating the flexibility required to support much more radical long-term outcomes. The power of these SOA's is hard to ignore. Even companies like Dell, WalMart and Schwab that managed to deploy new strategic architectures successfully in spite of the constraints of traditional IT architectures are moving rapidly to implement these SOA's.
Footnote
1) Indeed, they can be dynamically created at run time – at the time one uses the service – or they can be implemented through design tools that dramatically simplify the job of the programmer at the time the connections are built. In this latter case, tremendous utility is still realized since either end of the connection can be changed without requiring reprogramming at the other end.
Authors
John Hagel, III is an independent management consultant whose work focuses on the intersection of business strategy and technology. His most recent book, Out of the Box: Strategies for Achieving Profits Today and Growth Tomorrow, was published by Harvard Business School Press. He can be reached through his website www.johnhagel.com or by e-mail at john@johnhagel.com.
John Seely Brown was the director of Xerox PARC until 2000. He continues his personal research into digital culture, learning and Web services. His most recent book (co-authored with Paul Duguid) is The Social Life of Information. He can be reached at jsb@johnseelybrown.com.
