Yesterday, I spoke at SHARE in Tampa. This was the first of (hopefully) many talks on service-orienteering. I'm at the airport gate now, but wanted to post the slides as promised. The PDF conversion isn't the greatest, and the backpack picture didn't come through, but here is the deck.
More on service-orienteering soon (I hope).
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.
Recent Comments