• Blog
  • About
  • Archives

elemental links

brenda michelson's technology advisory practice

Thinking Out Loud: SOA Maturity

January 28, 2007 By brenda michelson

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.

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)
  • Click to email this to a friend (Opens in new window)

Filed Under: business-driven architecture, services architecture, soa

Comments

  1. Neil Ward-Dutton says

    January 30, 2007 at 5:06 pm

    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.

  2. Eric Roch says

    January 30, 2007 at 7:10 pm

    Interesting topic
    See this post by Dr. Ali Arsanjani who is Chief Architect of the SOA and Web Services Center of Excellence in IBM Global Services.
    http://www-128.ibm.com/developerworks/webservices/library/ws-soa-simm/
    I have also mapped SOA maturity to CMM see this post (mine)
    http://blogs.ittoolbox.com/eai/business/archives/mapping-soa-maturity-to-the-capability-maturity-model-8300

  3. brenda says

    January 31, 2007 at 8:57 am

    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…

  4. James says

    February 8, 2007 at 7:34 pm

    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.

  5. brenda says

    February 9, 2007 at 8:27 am

    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.

  6. Alex says

    February 14, 2007 at 1:00 pm

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

  7. Curtis Johnson says

    February 14, 2007 at 5:35 pm

    I agree…
    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.

  8. Sam Lowe says

    February 25, 2007 at 9:43 am

    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.
    Regards,
    Sam.

Brenda M. Michelson

Brenda Michelson

Technology Architect.

Trusted Advisor.

(BIO)

  • Email
  • LinkedIn
  • RSS
  • Twitter

Recent Posts

  • Experts Sketch
  • PEW Research: Tech Saturation, Well-Being and (my) Remedies
  • technology knowledge premise
  • The Curse of Knowledge
  • better problems and technology knowledge transfer

Recent Tweets

  • Harshest editorial feedback I ever received “stultified and like death”… (wildly popular paper, as it turned out):… https://t.co/qWNwBCOS5i February 28, 2023 2:16 pm
  • “…where the process of drawing itself can take us. We can follow a suggestion, a squiggle, shadow, or smudge, and s… https://t.co/oRg0x2LoXG November 30, 2022 5:05 pm
  • On the waiting list for Post, join me (on the waitlist) via https://t.co/U8wYK707f6 November 24, 2022 4:17 pm
© 2004-2022 Elemental Links, Inc.
loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.