What is Service Integration Maturity Model?

Well, SIMM stands for Service Integration Maturity Model, and it is a standardized model for organizations to guide their SOA transformation journey. By having a standard maturity model, it becomes possible for the organizations or industry to benchmark their SOA levels, to have a roadmap for transformation to assist their planning and for vendors to offer services and software against these benchmarks. SIMM may also serve as a framework for the transformation process that can be customized to suit the specific needs of organizations and assessments. This process is a simple sequence of steps: configure the assessment framework, determine the initial level of maturity, and determine the target level of maturity and a transformation path from initial to target level.
The Service Integration Maturity Model (SIMM) helps an organization create a roadmap for the incremental transformation of that organisation towards more mature levels of service integration in order to achieve increasing business benefits associated with higher levels of maturity. SIMM is used to determine which organisational characteristics are desirable in order to attain a new level of maturity. This will determine whether problems occurring at the current level can be solved by evolving to a higher level of service integration maturity.

There are seven levels of maturity in SIMM;

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)
7. Dynamically reconfigurable services (eco-system integration)

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.

source: IBM DeveloperWorks