After I spoke to the Dutch SAP User Group last week one of the delegates made some interesting comments about the Maturity Model that I had presented. The first point he made was that the Maturity Levels were not part of a common set. His comment was that Early Learning, Applied and Integrated represent states whereas Enterprise and Ecosystem are scopes. I responded that actually apart from Early Learning, all the levels relate to the scope of the SOA. However I accepted that it might not be entirely obvious!
The second question related to the scope of the SOA maturity model. My questioner’s assertion was that the scope of SOA was synonymous with BPM. I disagree with this latter point rather profoundly. BPM is an important driver and consumer of SOA capability, but it’s only one of many, which include business capability development, application rationalization programs, data rationalization and more.
But to return to the maturity level comment this did get me thinking. If I wanted to rationalize the maturity levels to be more consistent with a scope perspective I could do as follows:
But to return to the maturity level comment this did get me thinking. If I wanted to rationalize the maturity levels to be more consistent with a scope perspective I could do as follows:
OLD | Early Learning | Applied | Integrated | Enterprise | Ecosystem |
NEW | Fragment, Pilot or PoC | Project or Business Process | Domains | Enterprise | Ecosystem |
Early Learning is at face value very different from the other levels. It suggests a lower level of discipline, repeatability and indeed scope. To bring it into line I will suggest at this stage SOA activity is focused on fragments, pilots or proof of concepts. Bear in mind that Early Learning is about the maturity of architecture and architecture led activity, and focus on fragments seems to be entirely applicable.
The use of the term Applied was always intended to mean “specific to purpose”. I think Project or Business Process is an improvement.
Note I am using the term Domain in this context to mean multiple clusters. The concept of the Integrated level was always that diverse and highly separate parts of the business are integrated in a systematic manner using service architecture, but at a level that is not addressing the entire enterprise.
So by slight of hand, prompted by a good question I feel this approach strengthens the focus on scope without losing the original meaning of the maturity levels that have worked so well in many client engagements.
There are other dimensions to SOA Maturity. In our work we always break out the maturity across streams (organizationally neutral clusters of capability):
· Architecture (the instance architecture governing the portfolio)
· Life cycle and operational infrastructure (supporting technology)
· Process and framework (what to do and how)
· Organization (roles and responsibilities)
· Projects and programs (profiles of work split by provider/consumer)
· Management. (vision, investment, change management, measurement and monitoring)
Time and again we recognize that a scope based approach to maturity is the most useful determinant of maturity that decomposes well to each of the stream views because services are increasingly useful as they are used more widely, and conversely expanding the SOA scope beyond traditional organizational boundaries is without question the hardest thing to achieve.
