Adoption of SOA is a gradual process. While some organizations are dabbling into Web Services wrappering of applications as a means of exploring the world of SOA and deciding how to proceed, others are engaging in enterprise wide business transformation. Others are in between, and have defined their roadmaps, vision, strategy and criteria for assessment and governance. They are embarking on this journey by integrating application using Service-orientation. This latter is called service-oriented integration (SOI). This is the intermediate stage in which a lot of projects find themselves.
I have described this process and some patterns for embarking on this transformation to SOA using SOI .
Inside IBM, we have been developing and leveraging a Maturity Model and Process for SOA called the Service Integration Maturity Model (SIMM). This is designed to achieve desirable stages of maturity.
We have found it convenient to define seven levels of maturity that are defined by the level of de-coupling and flexiblity achievable at that stage of maturity:
1. Silo (data integration)
2. Integrated (application integration)
3. Componentized (functional integration)
4. Simple Services (process integration)
5. Composite Services (supply-chain integration)
6. Virtualized Services ( virtual infrastructure and integration through virtualization)
7. Dynamically Reconfigurable Services (eco-system integration)
Each have a detailed set of characteristics and criteria for assessment.
Here is an informal description of the highlights.
Level One. Organization start from proprietary and quite ad-hoc integration rendering their architecture brittle in the face of change.
Level Two. Organizations have moved towards some form of EAI (Enterprise Application Integration), albeit with proprietary connections and integration points. The approaches used have been to look at legacy systems and attempt to dissect and refactor through data integration.
Level Three. At this level, companies have componentized and modularized major or critical parts of their application portfolio. They have used legacy transformation and renovation methods to refactor legacy, expose functionality in a more modular fashion, built J2EE, or .NET based systems with clear component boundaries and scope.
The integration between components, is through their interfaces and the contracts between them.
Level Four. The company has embarked into the early phases of SOA by defining and exposing services for comsumption internally or externally for business partners; not quite on a large scale but acts as a Service provider none-the-less.
Level Five. Now the company has extended it's influence into the value chain and into the service eco-system. Services form a contract between suppliers, consumers and brokers that can build their own eco-system for on-demand interaction.
Level Six The company has now created a virtualized infrastructure to run applications. This is another level of decoupling achieved after the decoupled of the application, its servcies, components and flows. Now the infrastruture can be tuned and made agile through the notions of the grid and the grid service. Monitoring, management and events (e.g., common event infrastructure) have been externalized.
Level Seven This is a dynamically re-configurable software architecture. Services can be composed at run-time using externalized policy descriptions, externalized management and monitoring.
A simplified version of this has been discussed in 2003 in the Introduction I gave as guest editor of the Communications of the ACM on Enterprise Components and Services. Also, the four simplified levels have been discussed elsewhere as four adoption levels taken from SIMM .
Mappings to CMMI have also been done and 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 Defined, Repeatable or Optimizing, for example. This is often easy to do, due to the open and interpretable nature of the descriptions of each maturity level of CMMI.
The mapping to SIMM to CMMI is also quite straightforward; but the perceived value of this mapping seems distant other than the bandwagon factor of 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:
4. Quantitatively Managed
Each capability level consists of related specific and generic practices for a process area that can improve the organization 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 can be facilitated 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.
Here is a developerworks article that provides more elaboration on this topic.
BPM, APIs & Service-oriented Architecture: Insights and Best Practices
From archive: September 2005 X
Ali_Arsanjani 120000D8QB 1,001 Views
Of course with the current hype around Web services and SOA, there are a number of events hovering around this topic.
IBM is holding a series of SOA Days . The main SOA page for IBM products and trends can be found here .
Another event is the 2nd SOA and Web Services Best-practices conference in Chicago, and another is a workshop we are holding around the same topic at OOPSLA 2005, for the third year.
One of the main attractions of these and similar events are the battle stories we can exchange around SOA, which in the final analysis makes all the difference: what works in practice is the more important aspect of software engineering for clients.[Read More]