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