SOA doesn’t just automatically proliferate across organizations – it often requires a great deal of selling and evangelizing. That’s because SOA is a cross-enterprise effort, requiring active support from various constituencies. Whether it’s projects involving data integration or enhanced security, SOA proponents need to document benefits that will be seen across the business.
There’s been quite a bit of trepidation lately as to whether SOA projects can deliver their promised results. And, ironically, even if SOA is a raging success, many organizations may not even be aware of this success, because they’re not measuring it. The bottom line is that SOA initiatives need the metrics or key performance indicators tying business success to their efforts, and many organizations simply don’t know what business fruit their SOAs are bearing.
CIOs or IT managers I have spoken with know instinctively that they’re seeing increased business user satisfaction and better integration, but few have been able to supply actual metrics to document these trends.
Metrics are an important part of building and reporting a solid business case for SOA, in language the business understands. And nothing gets the message across better for business than measuring the costs and results of a service-oriented implementation. Measure, measure, and measure some more.
Here are some key considerations in determining the viability of SOA:
Return on investment (ROI) per service and revenue per service: ROI is the holy grail of projects, but it’s important to remember that all services will not be ROI generators. Knowing how much time and resources are put into a service helps provide a clear picture, as pointed out by Mark Little, CTO for Red Hat/JBoss in a recent post. Little also advocates measurement of revenue per service, which is tied directly in to the ROI metric. Tracking revenue per service can also be extremely important in other business decisions, “including determining whether the service investment was worthwhile or if it requires more resources for peak demands that may otherwise encourage customers to go elsewhere,” Mark points out.
Service growth rate/reuse: Service reuse rates are an area that demands a lot of attention. In a survey I helped conduct for SAP last year, we found that only 17 percent of enterprises have even the most fundamental foundational metric – enterprise reuse rates – to help gauge the success of their SOA efforts. It’s important to spot which services are sitting idle and not being adopted, but it’s even more important to track services that are getting greater-than-expected usage. This has service availability and systems management implications.
As Mark Little observes, tracking service reuse rates “can also be useful in determining the ROI for a service, since one that is reused significantly may help reduce the development costs of other services and applications.”
Business agility: As SOA expands across the enterprise, the business advantage may gradually shift from IT and development efficiencies (such as those gained through service reuse) to larger business advantages, such as ability to rapidly change product lines as the market demands. Measuring business agility – a squishy concept – has always been a difficult challenge. SOA proponents need to establish key performance indicators tied to key business metrics, and establish baseline data before the SOA project commences. For example, did upselling within a particular call center increase as a result of better data access made possible by SOA-enabled integration?
An equally important consideration for building the SOA business case – and the subject of future posts – is the need to sell projects that address business pain points, rather than selling SOA itself. For example, the business will understand the savings and agility that may stem from integrating the systems and data stores of multiple call centers, a project that is made possible through SOA.
