We spend a considerable amount of time flying around the country for various SOA-based projects, and we’ve had the opportunity to learn about not only the recurring client pain points and value propositions around SOA, but also a tiny bit about flying. Pilots are given landing patterns when they approach an airport; air-traffic control gives them these directions, approaches, and coordinates in order to accommodate the complexity of moment to moment changes in events that are occurring around the airport: other planes, wind direction, airpressure, and a host of other factors.
In a similar way, the path to SOA must consider several typical approaches, which we address here.
SOA adoption is a gradual process. While some organizations dabble with Web services by wrapping applications as a means of exploring the world of SOA and deciding how to proceed, others engage in enterprise-wide business transformation. Others are in between, and have defined their roadmaps, vision, strategy, and criteria for assessment and governance. They embark on this journey by integrating applications using service-orientation. This latter is called service-oriented integration (SOI) and is the intermediate stage in which many people find their projects (see Resources for more information on the SOI process).
At IBM, we have been working on a maturity model and process for achieving desirable stages of maturity, a model called the Service Integration Maturity Model (SIMM). The level of de-coupling and amount of flexibility achievable at each stage of maturity are what make up the following seven levels of maturity:
- Silo (data integration)
- Integrated (application integration)
- Componentized (functional integration)
- Simple services (process integration)
- Composite services (supply-chain integration)
- Virtualized services ( virtual infrastructure)
- Dynamically reconfigurable services (eco-system integration)
Each level has a detailed set of characteristics and criteria for assessment, and what follows is a brief description of the highlights of each level:
Level One: The organization starts from proprietary and quite ad-hoc integration, rendering the architecture brittle in the face of change.
Level Two: The organization moves toward some form of EAI (Enterprise Application Integration), albeit with proprietary connections and integration points. The approaches it uses are tailored to use legacy systems and attempt to dissect and re-factor through data integration.
Level Three: At this level, the organization componentizes and modularizes major or critical parts of its application portfolio. It uses legacy transformation and renovation methods to re-factor legacy J2EE or .NET-based systems with clear component boundaries and scope, exposing functionality in a more modular fashion. The integration between components is through their interfaces and the contracts between them.
Level Four: The organization embarks on the early phases of SOA by defining and exposing services for consumption internally or externally for business partners -- not quite on a large scale -- but it acts as a service provider, nonetheless.
Level Five: Now the organization extends its influence into the value chain and into the service eco-system. Services form a contract among suppliers, consumers, and brokers who can build their own eco-system for on-demand interaction.
Level Six: The organization now creates a virtualized infrastructure to run applications. It achieves this level after decoupling the application, its servcies, components, and flows. Now the infrastructure is more finely tuned, and the notions of the grid and the grid service render it more agile. It externalizes its monitoring, management, and events (common event infrastructure).
Level Seven: The organization now has a dynamically re-configurable software architecture. It can compose services at run-time using externalized policy descriptions, management, and monitoring.
I discussed a simplified version of this in 2003 in the introduction I gave as guest editor of the Communications of the ACM on Enterprise Components and Services; you can also read about it in the paper, "Toward a pattern language for Service-Oriented Architecture and Integration" (see Resources).
Some have also created mappings to Capability Maturity Model Integration (CMMI -- see Resources), which are a natural way to try and understand maturity. The main challenge in a few of these efforts has been to be more than just a categorization according to some semblence of CMMI, and to justify why something is, for example, defined, repeatable, or optimized. This is often easy to do, due to the open and interpretable nature of the descriptions for each CMMI maturity level.
The mapping to SIMM to CMMI is also quite straightforward, but the perceived value of this mapping seems distant when considered independently of the bandwagon factor for the success of CMMI. Service maturity relates to integration capabilities at various levels of business, methods, applications architecture, and infrastructure.
CMMI deals with six levels of capability:
- Quantitatively managed
Each capability level consists of related, specific, and generic practices for a process area that can improve the organizational processes associated with that process area. Forrester has been discussing various notions of maturity, although from a different perspective. Zapthink and other analysts have discussed SOA roadmaps, which you can facilitate using SIMM.
Elements affecting maturity include coupling, standards usage, service identification that supports business needs, business models, goals, and metrics that need to be supported by services, technologies, governance, infrastructure, tooling, skills and deployment capabilities.
The process of adopting Web services and SOA starts in many cases at the ad hoc stage on projects. This gradually evolves into a general technology adoption within a group that is engaging in that style of projects, using tools, technologies, standards, methods, and patterns that enable the creation of proofs of concept.
Assessments and planning can be done at this stage of adoption. The functionality of the proposed services needs to be verified and validated. The operational side of using run-time tools (monitoring, management, security, registry, and so on) needs to be tested and prototyped.
Once the technology adoption stage achieves some level of maturity, the results start trickling into the lines of business. They see the value in sharing services across lines of business to eliminate redundancy and having a single point of access to existing functionality that reduces complexity and cost and increases flexibility.
The business begins using services to access common functionality, often starting at a technology level and then moving on to the business level, which can provide greater value. Businesses can start to partition the functionality they leverage so as to eliminate redundancy.
As the lines of business start using these services, they partition functionality versus being redundant about that piece of functionality. With this comes a certain degree of business buy-in as the services start to percolate toward consolidation of business function across lines of business.
At the enterprise adoption level, standards, governance, and institutionalization of IT occur, and this involves SOA, including the protocols, tools, standards, and service models that will be used in this context. Also, the funding models like shared funding, common pool, and one-sided business line can be employed to handle the issues with service implementation efforts.
Figure 1. Scopes of adoption
Value-net adoption implies the extension of the services across organizational boundaries into the service or SOA eco-system. This implies business institutionalization, which includes business process and organizational transformation necessary to accomplish this.
The notions of reuse are related to this incremental model. In Figure 1 above, you have services and levels of reuse mapped to the scopes of adoption. Legacy Applications tend to be primarily technology focused; they can be wrapped to expose services that are specific to projects as you move from left to right. Then, you have a set of common services starting with a few that can span lines of business, often with a bit of customization through externalization of attributes, so as to keep the main code and functionality intact across usage contexts.
As you move toward enterprise adoption scope, you see the emergence of a greater number of common enterprise-wide services. The common services are then matured in terms of scope to be offered to business partners and clients in a value-chain and the SOA eco-system.
Underneath this scope and reuse, you have the general placement of current architecture being used at the project level and gradually moving into the definition of a more strategic service-oriented enterprise architecture (SOEA). The structure of the value-net requires a common understanding of an underlying set of architectural principles that allow partners to participate within the eco-system.
To achieve an optimal level of flexibility when architecting a service-oriented infrastructure, it's wise to adhere to the seven steps of maturity that we've discussed. Doing this, combined with attention to the capabilities described in the Capability Maturity Model Integration, will enable you to develop a well-defined and usable architecture.
Toward a pattern language for Service-Oriented Architecture and integration -- Solve commonly encountered problems in the migration, modeling, design, and implementation of SOA and SOI with these helpful patterns (developerWorks, July 2005).
Service-oriented modeling and architecture -- Learn about the key activities that you need for the analysis and design required to build a Service-Oriented Architecture (SOA) (developerWorks, November 2004).
Communications of the ACM on Enterprise Components and Services -- Learn more about research findings and ideas in the computing field.
Capability Maturity Model Integration (CMMI) -- Browse the CMMI mappings.
Migrating to a Service-Oriented Architecture -- Develop a realistic plan for evaluating your current infrastructure and migrating it to a true SOA (developerWorks, December 2003).
SOA and Web services -- hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
developerWorks blogs -- Get involved in
the developerWorks community.
Dr. Ali Arsanjani is a Senior Technical Staff Member who is Chief Architect of the SOA and Web Services Center of Excellence in IBM Global Services. He has 21 years experience in the IT industry, designing and delivering distributed software architectures for larger systems. His research interests and publications include software design patterns, software architecture, component-based and service-oriented architectures, and grammar-oriented object design. He specializes in building dynamically reconfigurable software systems. You can contact him at arsanjan at us.ibm.com.
Kerrie Holley received a Bachelor of Arts degree in Mathematics and a Juris Doctorate in law degree from DePaul University. He is currently a Distinguished Engineer in IBM Global Services and a Chief Architect in the e-business Integration Solutions where he provides thought leadership for the Web services practice. His current focus is in software engineering best practices, end-to-end advanced Web development, adaptive enterprise architecture, conducting architecture reviews, Web services, and service-oriented architecture. You can contact Kerrie at klholley at us.ibm.com.