ServiceTechMag.com > Archive > Issue XXII; September 2008 > The Economics of Service-Orientation: Leveraging the Emerging Services Marketplace
Enrique Castro-Leon

Enrique Castro-Leon

Biography

Enrique Castro-Leon is an enterprise architect and technology strategist with Intel Corporation working on technology integration for highly efficient virtualized cloud data centers to emerging usage models for cloud computing.

He is the lead author of two books, The Business Value of Virtual Service Grids: Strategic Insights for Enterprise Decision Makers and Creating the Infrastructure for Cloud Computing: An Essential Handbook for IT Professionals.

He holds a BSEE degree from the University of Costa Rica, and M.S. degrees in Electrical Engineering and Computer Science, and a Ph.D. in Electrical Engineering from Purdue University.

Contributions

rss  subscribe to this author

Bookmarks



The Economics of Service-Orientation:
Leveraging the Emerging Services Marketplace

Published: September 22, 2008 • SOA Magazine Issue XXII
 

Abstract: One of the primary goals of service-orientation is to attain a structural cost reduction in the delivery of IT services through reuse and standardization. The transition from a traditional system to a service-oriented system requires breaking monolithic applications into standard services, often with Web front ends to facilitate reuse not only within, but also "without." In keeping with this approach, many services can become outsourced, which in turn may lead to lower operating costs but at the expense of downsizing. In this article we will explore structural economic changes brought upon by service-orientation and we will highlight how the emerging services marketplace will make SOA in general more accessible to small-to-medium sized organizations.


Introduction

Most IT organizations today are under enormous pressure to keep their budgets in check. While costs associated with maintaining legacy environments go up, budgets are often flat or even decreasing (Figure 1). The restructuring brought about by the concept of services and reuse at the service level promises long lasting relief from the cost treadmill.



Figure 1: The overwhelming cost of living with legacy applications.

In a certain sense, service-orientation does not really bring new capabilities, yet it has the potential to bring about profound changes. From an economic perspective, for example, service-orientation can radically reduce the cost to developing new solutions. We illustrate some of these cost dynamics in next the four diagrams.


Options for Reducing IT Costs

In most enterprises, 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 many cases, 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; a situation obviously not sustainable.

A number of strategies have been used in to keep KTBR growth in check. Let's take outsourcing for instance (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 the problem of sustainability still persists. (Another issue is that costs are growing faster in countries providing services, so in a few years these countries will reach parity.)



Figure 2: The effects of outsourcing.

Another alternative is relying on the introduction of a new technology to lower the cost of doing business (Figure 3). Costs can be managed through an aggressive "treadmill" of technology adoption, but this does not fix the general uptrend, and few organizations are willing or even capable of sustaining a technology innovation schedule.



Figure 3: The effects of introducing new technology.

Finally, Figure 4 illustrates how service-orientation eventually leads to a structural and sustainable cost reduction based on the synergies of reuse. As with the outsourcing option, there is an initial bump in cost due to the upfront investment needed and this transformation may further take years to accomplish and can introduce difficult cultural and organizational adjustments.



Figure 4: The structural cost reduction attained through the adoption of service-orientation.

Service-orientation emphasizes the "discipline of modularity." Though well-known in the software engineering community for more than 30 years, this practice has, until now, been little applied.

As previously mentioned, a 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.

Outside-In vs. Inside-Out

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 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 of relieving regulatory pressures.

The conversion of legacy applications to service-oriented solutions is attained through a process of creative destruction whereby portions of the application are decomposed into services, usually with standardized Web services-based 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 service-oriented applications has occurred mostly in large enterprises. Smaller-sized companies have largely been left out of the SOA transformation even though SOA concepts and principles are equally applicable to small and medium businesses (SMBs).

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 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. This is the outside-in pattern for SOA adoption in contrast to the conventional inside-out pattern used at larger enterprises.

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 marketplace 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. This outside-in view of business-oriented services could become the guidepost for pervasive SOA adoption and transform how small businesses use computer technology.

However, 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 minor compared to changes to business processes and social behaviors of people involved in business transactions of small business operations.

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, the adoption of SOA within SMBs will continue to happen. An awareness of this dynamic will help players identify opportunities for value added service consumers and suppliers alike.

To better understand these two approaches, let's first revisit the age-old issues caused by silo-based application development and then delve deeper into the outside-in and inside-out SOA adoption models.


The Siloed State

Following the familiar evolutionary pattern described earlier, corporate applications have been deployed as stovepipes (Figure 5) with one application per server or server tier hosting a complete solution stack. Ironically, this trend was facilitated by the availability of low-cost 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. For example, some IT organizations use as many as 15 staging stovepipes to upgrade an ERP 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 service front ends represents an extra development cost with a payoff that is not immediate. In the beginning, implementation teams may find the extra work to enable future reuse under an SOA discipline disruptive. Cultural and behavioral aspects need to be addressed to ensure this effort continues to support the greater good of the organization even though it is not directly aligned with the immediate goals of a given project. Awareness campaigns and a significant amount of evangelizing will be necessary, and even then, the cultural shift can be slow and arduous.

Eventually a break even point is reached where the extra implementation cost of a project is balanced by the global savings from reusing services from 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 this "generic" consideration 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 internal IT development teams focus on core 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 a large organization.


Outside-in SOA: SOA for Small and Medium-sized Businesses

In the previous section, we witnessed the transformation from inside-out to outside-in in large companies. Now we will take a look at how the same evolutionary process can be naturally extended to 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 are therefore not able to afford the "internal-only" SOA adoption model, which is why SMBs do not usually attain the critical mass required to establish the internal services portfolio for the inside-out process.

However, because large enterprises become early adopters for SOA, they help establish a global services marketplace. The availability of these services can help SMBs leapfrog the whole inside-out process because SMBs can purchase the already-developed services from the outset. In fact, once the overall SOA ecosystem matures, the inside-out model could very well become obsolete.

In a mature service-oriented enterprise, compound applications (comprised of composed services) could be built predominantly from outsourced services, as shown in Figure 7. For example, a well-defined business process (such as purchase order creation and processing or a bank transaction) could be represented by a set of services instantiated by different users and integrated into a user solution supporting and driving by overall business. In essence, the process of picking and choosing the right pieces 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.

As a result of this approach, SOA can flourish in a smaller organizations, which represents a target state very much aligned with the original vision of openness and standardization that inspired the Web services platform. The adoption of SOA by SMBs will allow for reuse to occur across whole economic ecosystems. In other words, we are proposing a model for SOA deployment that depends on multiple ecosystem players providing composite solutions that are used to build more and more complex service compositions.

Within such an environment we can expect a degree of specialization where particular services are provided by smaller players with the appropriate expertise (Figure 8). Note also that this approach is not exclusive to the domain of SMBs; it can just as easily be applied to larger enterprises.



Figure 8: The end state is a rich, diverse economic ecosystem with an impressive impedance match between technology and business needs.


Conclusion: The Effects of Outside-In SOA Adoption

Who has a vested interest in realizing the transformation to outside-in SOA? It is a truism in an economic ecosystem that the cost equation for some players translates into an identical revenue consideration for others.

Here are some examples:

  • The 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 of procuring application capabilities through composable services.
  • Software tool 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.

It is also worth noting that relationships among service providers will evolve in potentially complex ways. Service providers will become both providers and consumers of services. Even companies that are not traditionally service providers, like Amazon.com, are beginning to develop a surplus of service capabilities. These companies will have the option to start selling these services to create additional revenue streams. (Actually Amazon.com is not a good example because it is not really a small organization. This model can scale down to 10–100 employee VAR-type 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 from Figure 5 can be retrofitted through middleware shims to behave as composable services not unlike the manner in which screen scraping programs are used to extend the life of legacy 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 in the market, we can expect a rich cottage industry for services to develop. This market will be highly diversified across geographic regions driven by local needs and regulations.

 

This article is based on material found in book "The Business Value of Virtual Service-Oriented Grids" (October, 2008) by Enrique Castro-leon, Jackson He, Mark Chang and Parviz Peiravi. 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.