I’m working on a for public consumption project that I call "service-orienteering". I’m borrowing a trail system metaphor to show the numerous trails and stops to reach a final destination of SOA-based business value. Because let’s face it, while achieving a mature SOA is a journey, delivering business value is the ultimate destination.
That said. I got to thinking about SOA maturity and SOA maturity models. The current SOA maturity models focus on technology adoption, scope of integration, and service interaction. While (as friends politely pointed out to me) there is nothing wrong with these models, they tend to have a narrow focus — the technology of SOA.
Because I tend to see things through business-driven goggles, I’m thinking the maturity of an SOA should be measured by:
– adherence to the architectural tenets (loose coupling, cohesion, sharing, and perhaps semantic interoperability)
– the organization’s capability to share (people, process, tools)
– the breadth and depth of the service catalog as compared to the business architecture – services might be in house, from partners, or SaaS
– the business criticality of the SOA solutions
– the business complexity of the SOA solutions
I’m curious, what do readers think? Shouldn’t we measure SOA maturity in terms of the capability to deliver business value? Am I in left field?
If you’re intrigued to see how this "service-orienteering" project is shaping up, I’ll be giving an "alpha version" talk at SHARE in Tampa in February.
Neil Ward-Dutton says
I absolutely agree with you Brenda – a perspective on SOA maturity which focuses solely on your ability to wrangle tools is myopic at best. It’s an important facet of the whole equation but a holistic consideration of maturity has to also factor in organisation, culture, and governance processes and structures.
At MWD we’re currently working on an interactive strategy planning tool for enterprises working with SOA, based on this broad framework.
Eric Roch says
See this post by Dr. Ali Arsanjani who is Chief Architect of the SOA and Web Services Center of Excellence in IBM Global Services.
I have also mapped SOA maturity to CMM see this post (mine)
Neil- MWD’s strategy planning tool sounds like a great idea. I’d love to get a glimpse when you are done.
Eric – As I was thinking about SOA Maturity, I did think of CMM(I) because it has a process, rather than technology, focus. I think this comes into play in understanding “the organization’s capability to share”. The development of a true (fully described) SOA Maturity model is probably a ton of work, given the dimensions Neil mentioned in his comment and the elements on my short list. Perhaps there’s an opportunity to mix and mash-up concepts from several existing maturity models…
The business metrics you refer to do exist however they are implicit. The issue may result in junk drawer filling as richness of service catalog says that I will publish lots of them to make the numbers look good.
James – That’s specifically why I said “the breadth and depth of the service catalog as compared to the business architecture” rather than number of services.
I have seen organizations measure solely on the number of services, which results in “extra” cohesively incorrect and/or unused services. I have also seen organizations measure solely on reuse, which results in a small number of monolithic (cohesively incorrect) services.
I think measuring based on depth and breadth as matching your business, plus adherence to the tenet of sharing, plus solving real business problems gets around the metric manipulation.
Of course my larger point was a slick technology implementation alone doesn’t indicate a mature SOA.
Considering how much most SOA solutions consider security, I’d say we have a long way to go before any of them can be considered, “mature.”
Curtis Johnson says
I think maturity models for SOA must not consider technology the main factor as the techology is just a means of supporting SOA. The maturity levels for SOA should concentrate on the Business structures, teams, policies, process, management and, ofcourse governance… only once these factors have been assessed, can a drill down of the technology that supports these factors, be assessed to determine the whole environment (Business and Technology).
We’re at a risk of loosing the benefits of SOA by placing a technology focus on it, yes we can say we are reusing web services or automating business process… but these alone are not providing the environment that SOA can accomplish, and that is the business working as a whole to provide agility and collaboration of their operations.
Sam Lowe says
Brenda, it’s a great point. Most of the models available are very technology-focused, presumably because of the software-marketing machines.
When working on SOA adoption in an organisation, one of the first things I look to do is to explicitly break the transformation up into 4 or 5 separate work-streams, only 1 of which is SOA technology. This can really help bring some business change perspective to technology hubris.
For example, the workstreams on the roadmap could be:-
1)technology platform (inc. integration) changes
2)service, application and information portfolio changes
3)organisation, roles, and skillset changes
4)engagement, governance, and operating processes changes
5)All underpinned by the business case, stakeholder management and executive mandate that any business change needs (sometimes as a separate workstream, sometimes just a set of deliverables/milestones from the others).
The SOA maturity models that are out there about technology, or worse about things like governance as if they were technology issues, are at best only partially helpful. I look forward to reading your service-orienteering material, it’s a great title.