Study: Only one out of five SOA efforts bearing fruit

Study: Only one out of five SOA efforts bearing fruit

Summary: 'Many SOA attempts amount only to a less efficient method of doing EAI'

SHARE:

SearchSOA's Michael Meehan reported on the latest findings coming out of the recent Burton Group confab, and things aren't looking pretty for SOA. And it may even take outside intervention to set an SOA back on track.

'Many SOA attempts amount only to a less efficient method of doing EAI.' Ouch.

Anne Thomas Manes, who delivered the bad news (followed by some good news), said that the consultancy's in-depth study of 20 companies found a "50% complete failure rate," while another "30% were considered neither successful nor wholly failed." Yikes -- what's going on here?

As Anne put it:

"Many of them had deployed multiple successful projects, but most of those projects were focused on just one integration problem," Manes said. "It was just a bunch of Web services. … The service is only built for one application and it's never going to be used again."

She added that such JBOWS projects amount only to a less efficient method of doing enterprise application integration, or EAI. Ouch, that's a pretty stinging indictment of something that was supposed to go far beyond EAI.

Don't blame the implementers, though. It seems many of these efforts were akin to running the engine room flawlessly on the HMS Titanic. Their SOA efforts were superb, but the people on the upper decks had other concerns.

What about that 20% (presumably four companies) that saw success with SOA? The Burton Group found that success came to SOA proponents who pay attention to the cultural shift that needs to take place within the business, cemented by good governance. The successful businesses had what Anne called "incredibly inspiring" stories to tell.

Here are the common denominators Burton Group found within the successful efforts:

  • Business and IT reorganization, usually with a new CIO coming on board
  • Sponsorship at the C-level or by the Board of Directors
  • Agile/iterative development methodologies put into place
  • Projects tied to and measured by business goals, not IT drivers
  • Well-defined funding and maintenance models that balance the needs of service providers and consumers
  • A simplified architecture, making it easier to access and manage quality data
  • A culture of trust between business and IT

The SOA-is-about-the-business aspect is something we discuss quite often at this blogsite, but the occurrence of a "new CIO coming on board" is kind of an eye opener. Does the catalyst for SOA come from outside the organization? Does it usually take an outsider with a fresh perspective to kick-start service oriented architecture? Do insiders get too comfortable with the established way of doing things? This also points to the vital role of an SOA evangelist (often the CIO, but it doesn't have to be) who can sell the business on what SOA can deliver.

One new CIO looked at a failed SOA attempt and knew instinctively that it was too siloed within the IT department. Chad Roberts, architecture director at Cigna Group Insurance (presumably one of Burton's four success stories) was on hand at the conference to explain how the company's original SOA effort, launched in 2004 with a technical integration focus, was canned in 2006 due to lack of interest.

Roberts re-started the initiative, recognizing that SOA needed to be positioned as a business transformation, not an IT project as it was before. The result "has been a full slate of SOA projects rolling into production with real business gains attached to them."

UPDATE: Lorraine Lawson provides additional insights on how CIOs can make the difference between JBOWS and SOA.

Topics: Software Development, Browser, Enterprise Software, Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

8 comments
Log in or register to join the discussion
  • SO at AA level is still SOA

    I fully appreciate Burton Group's view that SO is best applied to business/enterprise architecture. That's where the biggest payoff is (ostensibly) to be found.

    "The service is only built for one application and it?s never going to be used again.?

    Applying SO to an application architecture is less compelling but it is still SOA. SOA does not presume a particular level--although Burton posits that it does.
    reamon@...
    • A matter of SO scope at AA Level

      Hi Rob,
      I think you may be reading Anne's quoted statements out of context. Anne is stating a bunch of web services, built for a single application project, will most likely not result in a simpler portfolio and a rationalized application architecture. A silo project mentality using web services will result in cheaper integration. A silo project mentality will not result in enough re-use and sharing to reach touted goals of flexibility, agility, and business transformation. The scope and level must match expectations promoted to stakeholders.

      Burton Group has <A href='http://www.burtongroup.com/Research/DocumentList.aspx?cid=21'>published multiple reports</A> promoting how service-orientation can be successfully applied to application architecture. Specifically, our 'Application Rationalization' and 'Application Portfolio Management' reports detail application architecture best practices.

      best regards,

      /Chris Haddad
      Vice President, Application Platform Strategies
      Burton Group
      http://apsblog.burtongroup.com
      cobiacomm
  • SO at AA level is more modest in its goals

    "I think you may be reading Anne's quoted statements out of context. Anne is stating a bunch of web services, built for a single application project..."

    Perhaps. Joe quoted Anne: "?It was just a bunch of Web services. ? The service is only built for one application and it?s never going to be used again.?"

    I wonder if, because the service was app-centric (SO at the AA level), that it was labelled dismissively as JBOWS because it wasn't SO at the EA level? Is this our fundamental disagreement, where Burton feels SOA is only an EA concept but I feel it can be applied at any level?

    " built for a single application project, will most likely not result in a simpler portfolio and a rationalized application architecture. A silo project mentality using web services will result in cheaper integration. "

    I don't disagree.

    " A silo project mentality will not result in enough re-use and sharing to reach touted goals of flexibility, agility, and business transformation."

    Applied at the application level, SO is not likely to achieve much "business transformation." Why would SO at the AA level have that as a goal?

    Blind reuse and sharing can be counter to the goals of flexibility and agility--indeed, sharing is often a primary reason for inflexibility.

    "The scope and level must match expectations promoted to stakeholders."

    Here again, I don't disagree. SO applied to an application architecture has a different set of stakeholders and a different set of goals than SO applied to higher architectural levels.

    "Specifically, our 'Application Rationalization' and 'Application Portfolio Management' reports detail application architecture best practices."

    I can't review those as I'm not a Burton client, but the summaries look good. And those would be good for pursuing SOA in the large--transitioning from application-centric to SO across the enterprise. And this would go beyond the AA level, correct?

    I do agree that SO at the AA level looks an awful lot like mere integration. Maybe cheaper. Maybe less efficient (per info in Joe's article). But it is still SOA--it just has more modest goals than SO applied to higher levels.
    reamon@...
  • The emperor's new clothes

    This category of SOA is worse than useless. Essentially they were IT projects and most of them failed. Big surprise.
    tonymcs@...
  • RE: Study: Only one out of five SOA efforts bearing fruit

    There is no reason to implement SOA if the company doesnt need it. Too often this kind of project is forced on an unwilling company or department by a new manager who wants to put his or her stamp on the department. This is a sure sign of a bad manager. The only reason to to implement this kind of huge change, especially in the big bang approach so many people seem to favor is if the current methods aren't working. The new method cant just be better, it has to replace a non-working method in order to get buy in. And too many people dont realize that buy in doestn come from the managers saying ok, it comes from the users actually liking the software, not just being forced to use it.
    abear4562
  • RE: Study: Only one out of five SOA efforts bearing fruit

    I think it's important to bring some perspective to this
    analysis to determine whether the conclusions drawn are
    statistically significant. It can be misleading for readers if
    conclusions are drawn based only on a study of 20
    companies (which aren't proven to be statistically
    representative of the market).


    SOA is, by most industry surveys, more successful than not
    (Amberpoint, 2008). That does not mean that some
    companies are failing at both the implementation activity
    or in achieving business results, because they do.
    However, in excess of 60% of companies in one study
    found that enterprise SOA projects where meeting their
    SOA goals. This success rate is far from the 1out of 5
    selectively reported on by this group.


    Statistics aside, the author does raise some very valid
    modes of failures to watchful over. Lack of defined
    services, governance, roadmaps, and maturity models are
    all "necessary" characteristics of successful SOA
    implementations. Necessary? meaning that without them
    you fail (e.g., oxygen is a necessary characteristic for life).
    But the study of failure alone is insufficient for truly
    migrating to SOA at the enterprise level, one needs to also
    look into sufficient characteristics; that is, those
    things that lead to success. This is the more interesting
    list, as Jack Welch would say.


    Dr. Jerry A. Smith, jsmith@symphonysv.com
    jsmith@...
    • SOA Success Factors

      Hi Jerry,

      Amberpoint's survey question asked if the survey participant experienced a successful SOA <b>project</b> and only 41% had services deployed in production. A 98.5% self-reporting success rate is suspect in it's own right, however Burton Group's findings don't conflict with Amberpoints survey because we analyzed SOA as an <b>initiative</b> comprised of multiple projects. In fact, we found most organizations are initially successful, then stall after about 18 months.


      Anne Thomas Manes' presentation at <A href='http://catalyst.burtongroup.com'>Catalyst</A> also outlined critical success factors required to gain and sustain adoption and momentum.

      Critical success factors include:

      * Trust relationship between IT and business

      * Strong leadership

      * Getting people on the same page (coordinated effort)

      * Frequent and regular deliverables

      * Tying activities/deliverables to business goals and value



      /Chris
      cobiacomm
      • Great list of CSFs

        (Though I have heartburn with "...between IT and business" but that's another topic.)

        None of which have anything to do with SOA, per se. These factors are important to be successful with just about anything.
        reamon@...