Abstract
The goal of service orientation is to attain a structural cost reduction in the delivery of IT services through reuse and standardization. However, the transition from a traditional system to one based on services requires breaking monolithic applications into standard services, often with Web front ends to facilitate reuse not only within, but also without. It is important to keep in mind, though, that in keeping with this approach, often many services become outsourced, which in turn may lead to lower operating costs but at the expense of employees. Also, transition to an SOA business model is not limited to large businesses, but is equally open to small and medium businesses too.
Virtualization and grid computing bring costs down by enabling the reuse and sharing of a physical resource, leading to a more efficient and higher degree of utilization for that particular resource, whether a computer or a network. In this section we will explore structural economic changes brought up by service orientation. Most IT organizations today are under enormous pressure to keep their budgets in check. Their costs are going up, but their budgets are flat to decreasing as illustrated in Figure 1. The restructuring brought about by the concept of services and the reuse at the service level promises long lasting relief from the cost treadmill. 
Figure 1 - The Overwhelming Cost of Legacy.
In a certain sense, service orientation does not really bring new capabilities. Yet it has the potential to bring about profound changes because of the economics involved. Service orientation radically reduces the cost to bring in certain capabilities. We illustrate some of the cost dynamics in the four diagrams. Conceptually, a portion of IT budgets is used to maintain existing projects. This portion is important because it is the part that “keeps the business running” (KTBR). In most IT organizations, the KTBR portion takes the lion’s share of the budget. The downside is that the KTBR is backward looking, and it’s only the leftover portion that can be applied to grow the business. There is another problem: the KTBR portion left unchecked tends to grow faster than IT budgets overall, and the situation is obviously not sustainable.
A number of strategies have been used in IT organizations to keep the KTBR growth in check. Let’s take outsourcing for instance as shown in Figure 2. When outsourcing (and perhaps off-shoring) is brought in, costs actually go up a notch as reorganizations take place and contracts are negotiated. Once the outsourcing plans are implemented costs may go down, but still have the problem of sustainability. Another issue is that costs are growing faster in countries providing services, so in a few years these countries will reach parity.
Figure 2 - Effect of Outsourcing.
Figure 3 - Effect of Introducing New Technology.
A third alternative is illustrated in Figure 3: The introduction of a new technology, such as Intel® vPro™ processor technology, lowers the cost of doing business, seen as a cost dip. Costs can be managed through aggressive “treadmill” of technology adoption, but this does not fix the general uptrend, and not many organizations are willing or even capable of sustaining this technology innovation schedule.
Finally, Figure 4 illustrates how service orientation eventually leads to a structural and sustainable cost reduction to the synergies of reuse. As in the outsourcing case, there is an initial bump in cost due to the upfront investment needed. Note that this transformation may take years to accomplish and will require difficult cultural and organizational adjustments.
Figure 4 - Structural Cost Reduction Attained through the Adoption of Service Orientation.
Service orientation brings a discipline of modularity that has been well known in the software engineering community for more than 30 years, but had been little applied in corporate-wide IT projects. As previously mentioned, the goal of service orientation is to attain a structural cost reduction in the delivery of IT services through reuse and standardization. There may be more upfront costs for architecture and planning as well as consideration for interoperability and security. However the benefits of modularity and interoperability will pay back as more and more services are developed and reused to attain the same results as we have seen in software engineering today.
In the end, aligning IT with business at a reasonable and predictable cost is a challenging problem. The best solution is attained through an integrated strategy that includes business process improvement (in the form of service orientation), technology, and an appropriate business strategy.
Scalability of Service Oriented Architecture
In this section we investigate topics of scalability and patterns of adoption for SOAs. The discussion in this section is forward looking, about events and processes that have not yet occurred or are in mid-flight, and hence the content should be viewed more as a thought provoking exercise than as a statement of fact.
The increasing adoption of SOA in the industry brings the promise of significant cost reduction in the planning, deployment, and operation of IT projects. This trend has been partly fueled by the near-death experiences of many IT organizations after the dot-com crash at the turn of the millennium and the increasing pressure of aligning IT with business, lest these organizations become a casualty of the next budget cut. The added regulatory compliance characteristic of this period has brought additional incentives to explore means to bring in relief from regulatory pressures.
The conversion to SOA for legacy applications is attained through a process of creative destruction whereby portions of the application are decomposed into services with Web services based standardized interfaces. These services can then be reused to support other applications. Conversely, new applications can be built by composing these services through their standardized interfaces.
The adoption of SOA in business computing environments is growing due to the promise of significant cost reduction in the planning, deployment, and operation of IT projects through reuse. However, the organic transformation from legacy enterprise applications to SOA applications has occurred mostly in large enterprises. Small businesses have largely been left out of the SOA transformation. We will see that an SOA approach is equally applicable to small and medium businesses (SMBs.)
We describe a new pattern for the adoption of SOA and service delivery beyond the better known role of SOA in large enterprise transformation.
Through business-oriented services developed and delivered by independent service providers outside of corporate firewalls, small business can pick and choose the services they deem valuable. They can “mash up” these services to best serve their business needs following the SOA service integration concepts much in the same way it’s done at large enterprises. Hence, for small businesses, SOA will no longer be an abstract concept and the exclusive game of large enterprises anymore. This is the outside-in pattern for adoption for SOA in contrast to the better known, conventional inside-out pattern seen at large enterprises.
To summarize, under the conventional inside-out approach services are built by composing simpler services from within the organization, whereas the outside-in approach assumes that smaller organizations will be able to build services from service components available in the ecosystem and offered by service integrators. Service integrators in turn may choose to build their offerings by using service components from other vendors. There is a potential for a rich and diverse ecosystem to develop.
The impact on SMBs is noteworthy due to the large potential audience: according to the US Small Business Administration, in the United States small businesses represent 99.7 percent of all employer firms and employ half of all private sector employees (http://www.sba.gov/advo/stats/sbfaq.txt).
This outside-in view of business-oriented service could become the guidepost for pervasive SOA adoption and transform how small businesses use computer technology.
We also realize that the outside-in SOA model may take a while to develop. Several significant technical barriers must be overcome requiring a concerted effort from industry players. The technical challenges are small compared to changes to business processes and social behaviors of people involved in business transactions of small business operations.
However, just as we witnessed in the adoption of the Internet and Web 2.0 for the consumer market, as long as we can deliver compelling benefits and lower barriers of entry, such an adoption can and will happen.
An awareness of this dynamic will help players identify opportunities for value added, service consumers and suppliers alike.
The Initial Siloed State
Following the familiar evolutionary pattern described earlier, corporate applications have been deployed as stovepipes, as illustrated in Figure 5, one application per server or server tier hosting a complete solution stack. Ironically, this trend was facilitated by the availability of low-cost Intel-based servers fifteen years ago that encouraged using the physical server as the unit of deployment.
Under this system physical servers are procured, in a process that takes anywhere from two weeks to six months. When the servers become available, they are provisioned with an operating system, database software, middleware, and the application. Multiple pipes are actually needed to support a running business. Some IT organizations use as many as 15 staging stovepipes to phase in an upgrade for the Enterprise Resource Planning (ERP) SAP application.
A first step toward an SOA transformation is to break some of the silos into smaller logical components and add Web services front ends to make these components available to other present and future applications. At this stage redundant components are identified and retired.
Hence, with SOA, monolithic applications are broken into standardized services. Installing Web services front ends represent an extra development cost whose payoff is not immediate. In the beginning implementation teams may find the extra work to enable future re-use under an SOA discipline disruptive. Cultural and behavioral aspects need to be addressed to ensure the extra work for the greater good of the organization gets done even though it is not directly aligned with the immediate goals of the project. A significant amount of evangelizing and awareness campaigns will be necessary, and even then, the cultural shift will be slow and arduous.
Eventually a break even point is reached where the extra implementation cost of a given project is balanced by the global savings from reusing past projects. The end goal is to attain a positive balance sheet. This is not the time to give up on evangelizing, because the savings may not be visible to individual organizations, only to organizations that can observe multiple projects.
Figure 5 - Traditional Application Stovepipes
Inside-out or Conventional SOA
Figure 6 illustrates the transition to SOA for a large organization. Stack layers have been replaced by service components and there is so much reuse that the stacks have all but disappeared.
Enterprise architects may find that some of the functions are generic and can be replaced by offerings from third party vendors. Note, however, that the consideration of “generic” is a function of the state of technology and the ecosystem. For some organizations it might be HR applications; for others it could be mailbox services or even a whole ERP implementation.
Even if the transformation is executed flawlessly from a technical perspective it may still cause disruption and pain: the original portfolio of internal services shrinks into a smaller and smaller core. If internal services are replaced with outsourced services at a lower cost, costs overall will go down. The smaller core will almost certainly lead to staff reductions and skills rebalancing. There will be less application development in house and a need for people with business and technical skills managing service vendor relationships.
The SOA transformation process may start small where services that are not mission critical are targeted first for substitution, while the IT internal development teams focus on core, complicated, mission critical services.
The services in the core may represent intellectual property (IP) critical to the business. Some companies may have few restrictions in this area, and eventually the core simply becomes so small that it’s indistinguishable from other outsourced services. The attainment of this state completes the inside-out transition.
Figure 6 - SOA in the Large Organization
Outside-in SOA: SOA for Small and Medium Businesses
In the previous section, we witnessed the transformation from inside-out to outside-in in large companies. In this section we will see that the same evolutionary process can be naturally extended to small and medium businesses (SMBs.) The difference is that the processes take place on whole ecosystems instead of a single large company.
By their very nature, SMBs do not usually have the luxury of a large IT budget, or a large IT department. Many of these companies have only a few IT literate employees acting as part time IT support. They would not be able to afford the “internal-only” SOA adoption model. Hence SMBs do not have the critical mass to establish the internal services portfolio for the inside-out process.
However, if we assume that large enterprises become first adopters for SOA, and in so doing a market for services gets created, SMBs can leapfrog the whole inside-out process. SMBs can start purchasing services from the outset. In fact once the ecosystem matures the inside-out model will become as obsolete as it is building in-house applications from the ground up today.
In a mature SOA environment, SOA compound applications will be built out of predominantly outsourced services. Figure 7 illustrates the concept. A well defined business process (such as purchase order creation and processing or a bank transaction) is represented by a set of SOA services instantiated by different users and integrated into a user solution supporting and driven by business need. In essence, the process of picking and choosing the right pieces for their businesses by SMB owners would look very much like a mash-up in the Web 2.0 world today.
Figure 7 - For the SMB Environment, the Enterprise Core Becomes Arbitrarily Small to the Extent that It Is No Longer Distinguishable.
Such an approach to adopt SOA could lead to a surprising result: the experience from the efforts in building strategies for instituting SOA in large organizations suggests that at some point in the maturation of the SOA market, large organizations will not be a precondition for SOA adoption. SOA can flourish in a small organization environment as well. This conclusion is also aligned with the very concept of openness and standardization of Web services. The processes are architecturally sound and technically feasible, even though there are technical and social behavior hurdles to overcome.
The adoption of SOA in SMB space will take place under a different dynamic: instead of reuse from within, or across organizations in a large enterprise, considered a necessary condition for critical mass, we will see the same critical mass, but with reuse now happening across whole economic ecosystems.
In other words, we are proposing a model for SOA deployment that depends on multiple ecosystem players providing composite applications that are used to build more complex SOA-style composite applications. Under this environment we can expect a degree of specialization where the individual services are provided by smaller players with the appropriate expertise. This situation is illustrated in Figure 8. To distinguish this approach from the traditional “internal only” or “inside-out” approach to SOA specific to large enterprises, we call it outside-in SOA. The outside-in approach is not exclusive domain of SMBs; it can also take place in large enterprises as described in the previous section.
Figure 8 - The End State Is a Rich, Diverse Economic Ecosystem with an Excellent Impedance Match between Technology and Business Needs
Who has a vested interest in making the transformation to outside-in SOA take place? It is a truism in an economic ecosystem that the cost equation for some players translates into an identical revenue consideration for another player. The whole ecosystem benefits when the value received greatly exceeds the cost expended for purchasers, and when sellers realize additional demand for products and services because of this value.
Consumers of services stand to gain because of the lower cost overall for procuring application capabilities via compound applications through compound services. Software tools vendors will benefit through offerings that target an outside-in SOA environment, and likewise vendors of technology building blocks. These building blocks must have SOI capabilities that support automated provisioning and the concept of virtualized appliances.
Relationships among services providers will grow in fairly complex ways. Services providers will become both providers and consumers of services. Even companies that are not traditionally services providers like Amazon.com are beginning to develop a surplus service capability. These companies will start selling these services to create additional revenue streams. Actually Amazon.com is not a good example because it is not really a small company. This model can scale down to 10–100 employee value-added reseller (VAR) type of companies.
Canonical service components, that is, services designed as services from the ground up, are not essential to make this scheme work. The traditional stovepiped applications in Figure 5 can be retrofitted through middleware shims to behave as composable services in a manner not unlike screen scraping programs are used to extend the life and usefulness of legacy mainframe applications. The barriers to the outside-in model are lower than they appear at first analysis because the industry does not need to wait until a large portfolio of reusable services becomes available.
As service technology matures and more players partake of the market we can expect a rich cottage industry for services to develop with offering available to build most any application imaginable. This market will be highly diversified across geographic regions driven by local needs and regulations. In this environment it simply will be cheaper to build specific functionality by contracting out constituent components in the marketplace rather than building the same functionality wholly in house.
The paradigm of the automobile or the aircraft industry, with a huge supply network, will also apply to software applications.
The outside-in approach differs from traditional outsourced arrangements: the negotiation of an outsourced payroll function may involve months and real people at the table. On the other hand, outside-in transactions will be eminently automated and highly dynamic through automated registries and discovery services and using open standards. One such transaction might take from a fraction of a second to no more than a few seconds.
For more information about the economics of service orientation, please refer to the book The Business Value of Virtual Service-Oriented Grids by Enrique Castro-leon, Jackson He, Mark Chang and Parviz.
About the Authors
Enrique Castro-Leon is an enterprise and data center architect and technology strategist for Intel Digital Enterprise Group working in OS design and architecture, software engineering, high-performance computing, platform definition, and business development. His work involves matching emerging technologies with innovative business models in developed and emerging markets. In this capacity he has served as a consultant for corporations large and small, nonprofits and governmental organizations on issues of technology and data center planning.
He has taken roles as visionary, solution architect, project manager, and has undertaken the technical execution in advanced proof of concept projects with corporate end users and inside Intel illustrating the use of emerging technologies. He has published over 40 articles, conference papers and white papers on technology strategy and management as well as SOA and Web services. He holds PhD and MS degrees in Electrical Engineering and Computer Science from Purdue University.
Jackson He is a lead architect in Intel's Digital Enterprise Group, specializing in manageability usages and enterprise solutions. He holds PhD and MBA degrees from the University of Hawaii. Jackson has overall 20 years of IT experience and has worked in many disciplines from teaching, to programming, engineering management, datacenter operations, architecture designs, and industry standard definitions. Jackson was Intel’s representative at OASIS, RosettaNet, and Distributed Management Task Force. He also served on the OASIS Technical Advisory Board from 2002–2004. In recent years, Jackson has focused on enterprise infrastructure manageability and platform energy efficiency in dynamic IT environment. His research interest covers broad topics of virtualization, Web services, and distributed computing. Jackson has published over 20 papers at Intel Technology Journal and IEEE Conferences.
Mark Chang is a principal strategist in the Intel Technology Sales group specializing in Service-Oriented Enterprise and advanced client system business and technology strategies worldwide. Mark has more than 20 years of industry experience including software product development, data center modernization and virtualization, unified messaging service deployment, and wireless services management. He participated in several industry standard organizations to define the standards in CIM virtualization models and related Web services protocols. Additionally, Mark has a strong relationship with the system integration and IT outsourcing community. He holds an MS degree from the University of Texas at Austin.
Parviz Peiravi is a principal architect with Intel Corporation responsible for enterprise worldwide solutions and design; he has been with the company for more than 11 years. He is primarily responsible for designing and driving development of service oriented.
This article is based on material found in book The Business Value of Virtual Service-Oriented Grids by Enrique Castro-leon, Jackson He, Mark Chang and Parviz Peiravi. Visit the Intel Press web site to learn more about this book: www.intel.com/intelpress/sum_grid.htm.
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4744. Requests to the Publisher for permission should be addressed to the Publisher, Intel Press, Intel Corporation, 2111 NE 25 Avenue, JF3-330, Hillsboro, OR 97124-5961. E-mail: intelpress@intel.com.