The Importance Of “Being Mature”
Figuring out what architecture style you are ready to move to is very important before jumping around and adopting the great ideas vendors are selling you. Yes, those ideas are likely very good and the vendors may be right that you need those features, forms, concepts, etc. But, the question to ask will be… “Is your organization ready enough to adopt these service models?” This article seeks to explore this question and provide some answers for the reader.
Moving into architecture service models require a greater level of maturity as you add more responsibility to the team supporting it. As the IT architect, you are responsible for providing the required service level to employees. And if the system is not up and running, then management would reset employee expectations during those periods. This is much different than current web applications calling those systems 24/7/365 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 you are responsible to a service level of users you do not manage That means resetting expectations during downtime or slow periods is very, very difficult.
So What?
Having an understanding of your maturity in a service arena can let you know how much you need to invest in business, governance, methods, applications, architecture, information and infrastructure to reach your goal.
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 and 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 the maturity model concepts as seen below.
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 has componentized and modularized 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 ecosystem. Services form a contract among suppliers, consumers, and brokers who can build their own ecosystem 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 services, 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 (ecosystem integration) | Level Seven: The organization now has a dynamically reconfigurable software architecture. It can compose services at run-time using externalized policy descriptions, management, and monitoring. |
Open Group Summary
Each level of Open Group’s maturity model 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. Take this information, and use it to figure out just how mature your service architecture really is.
