How mature is your service architecture

Figuring out what architecture style you are ready to move to is very important before jumping around great ideas vendors are selling you. Yes, the ideas are likely very good and the vendors may be right that you NEED those features, forms, concepts, etc. But, the question is your organization ready enough to adopt these service models.

Moving into service models require a greater level of maturity as you add more responsibility. An internal standalone system or even enterprise integrated systems are used by trained users 9-5. You are responsible to the service level to employees, and if it isnt up, then management would reset employee expectations during those periods. This is much different than web applications calling those systems 24/7 to untrained users with access from anywhere. More so, if the services supporting the web application could be called by other ecosystems, people could now harvest and build many other interfaces for their own community. Now your are responsible to a service level of users you do not manage – which means re-setting expectations during downtime or slow periods is very, very difficult.

By having a view of your readiness to maturity into the service arena, this can let you know how much you need to invest in business, governance, methods, applications, architecture, information and infrastructure to get there.

The Service Integration Maturity Model (SIMM) 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. (Wikipedia)

IBM and The Open Group have adopted and expanded upon these concepts. 

IBM Summary

Silo (data integration)

Level One: The organization starts from proprietary and quite ad-hoc integration, rendering the architecture brittle in the face of change.

Integrated (application integration)

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.

Componentized (functional 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.

Simple services (process integration)

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.

Composite services (supply-chain integration)

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.

Virtualized services ( virtual infrastructure)

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

Dynamically reconfigurable services (eco-system integration)

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.

Open Group Summary

Each level has a detailed set of characteristics and criteria for assessment.

The Open Group has a nice matrix that shows not only the 7 levels, but how it impacts business, governance, methods, applications, architecture, information and infrastructure.