Gartner: Nine ways to measure SOA success

Gartner: Nine ways to measure SOA success

Summary: Why do we do SOA?My pal Steve Swoyer just published a piece over at Visual Studio surfacing a Gartner observation that many companies may have fallen into a "herd mentality" when it comes to SOA.


Why do we do SOA?

My pal Steve Swoyer just published a piece over at Visual Studio surfacing a Gartner observation that many companies may have fallen into a "herd mentality" when it comes to SOA. That is, they do SOA because everyone else seems to be doing it.

As explored here on this blogsite a couple of weeks back, Gartner found that 40% of companies with SOA projects don't bother to measure the results or ROI. (Is that good or bad compared with other initiatives? They didn't say.)  But the takeaway is that there are a lot of SOA efforts going on out there, but with no sense if they're delivering or not.

Gartner's advice: start small, identify specific business benefits, and focus on achieving them.

Here are some points that can be measured to determine if service orientation is delivering, courtesy of Gartner:

  1. Improved efficiency, particularly with respect to business processes execution
  2. Lower process administrative costs
  3. Higher visibility on existing/running business processes
  4. Reduced number of manual, paper-based steps
  5. Better service-level effectiveness
  6. Quicker implementation of processes
  7. Quicker time to market
  8. Shorter (overall) project cycles
  9. Overall reduction in the total cost of application development and maintenance

Steve also relays this bit of advice: avoid reflexive thinking -- either pro or con. "If implementing SOA for the sake of implementing SOA isn't a viable strategy, neither for that matter is a knee-jerk dismissal of the benefits of SOA as ambiguous or unattainable." Get the numbers to back up the argument either way.

Topics: Software Development, Browser, CXO, Enterprise Software, IT Priorities, Software

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


Log in or register to join the discussion
  • Internal view opposite external view

    In my experience SOA is a matter of faster integration, specifically when optimizing chains of companies within the same industry like the food and feed chain. It is easier to move to SOA then adapting your EDI-exchange net putting new laws in place.
  • RE: Gartner: Nine ways to measure SOA success

    are these not very general measure which should be present in any IT initiative?

  • RE: Gartner: Nine ways to measure SOA success

    We had a customer who did a very simple ROI calculation on his SOA initiative - this is one of the world's largest distillers - they began with a small project involving using Fiorano SOA Platform in their SAP environment - In SAP, the 'standard' invoicing process takes 5 steps and 9 screens, requiring 12 mins to complete typically. With the Fiorano flow, this changes to 1 step and 2 screens, requiring just 2 mins to complete. That's a savings of over 10 mins on each invoice creation. With over 5000 invoices per month, there is a saving of over 100,000 minutes of time per month (over 1600 man-hours) just based on invoicing.

    In addition since SAP clients (cost about $2000 per client) were not required any more (since they connect through the Fiorano ESB), cost of SAP clients was reduced by over 50 x $2000.

    Reduced training and personnel costs: Operators are remote sites could now just enter invoices on an html page and required no training on SAP. The Fiorano SOA Platform seamlessly updates the SAP system. Multiply difference betweeen average salary for an unskilled operator vs. SAP trained times the number of remote operators to get the savings.

    All in all the project had a 250 % + ROI.

    SOA benefits are easily measurable, on a project basis. Overall efficiencies obviously simply compound the benefits. For example in this case an 18% increase in sales in the following year was seamlessly handled without a problem and with no additional outlays on SAP either.
    • Can you share what was SO about this?

      The use of an ESB is interesting but doesn't indicate that SO principles were followed. Instead, this sounds very much like a classic integration project between a new web app and SAP. SOA != ESB.

      Obviously due to the nature of the forum here you can't share too much detail here but it would be great if you could share some info about the SO principles followed, the business-level services created (WS != service) and the interfaces of those services.
      • Can using the ESB be "Service oriented"

        It is true that SOA != ESB in most cases.

        Fundamentally, Service Orientation refers to the composition of solutions using pre-built components. The Fiorano soltion was created using pre-built, pre-tested coarse-grained components (Services), which communicate with each other either via messages (event driven architecture) or via request/reply (the more classic way of programming). The Fiorano ESB supports a component model that enables the development of Services in multiple programming languages. These services are then wired together on a screen, with the 'wires'automatically mapping to underlying topics and queues as required, without any user intervention. Using this technique, even non-programmers and business analysts can compose service-oriented solutions without any programming.

        It should be noted that the fact that an ESB is used for the solution is not the reason that makes it 'service oriented'. What makes it 'serivce oriented' is the fact that the solution was composed entirely from pre-built,
        coarse-grained services.

        If you are interested in the detail of this particular example, you can view the case study at this link -