Using IT Backlogs as Metrics for SOA

Joe McKendrick does a good job in highlighting a new notion: “How do you measure SOA success? Try IT backlogs.” This was from a Podcast posted by Hub Vandervoort, CTO of Progress Software. Clearly, that’s the case, but just looking at IT backlogs could be a bit too rudimentary when considering SOA.

“In companies implementing SOA, the overall backlog of IT requests is starting to shrink, Hub pointed out. Companies are seeing drastic reductions in project cycle times and consolidation in purchasing across the enterprise.”

The fact of the matter is that the core benefit of SOA is agility. If you have agility, then you have the ability to change the architecture as the business needs changes. Thus, if you have IT backlogs, naturally they will decrease because it’s easier to make these changes. Seems logical to me.

The trouble with using IT backlogs as a core metric is that it’s after the fact. Thus, we can measure ROI after we’ve implemented our SOA, which is great; however the rubber meets the road in determining the ROI before you fund your SOA. Indeed, most business leaders are going to demand a business plan before they will provide funding, and you’ll need clear ROI for the business plan. Just promising reduced IT backlog won’t be enough, you need to define the increased efficiencies at all levels, including business and IT. SOA is promising much more than just reduced backlogs, at the end of the day. That’s just one benefit.

In thinking about the ROI around SOA we need to think at a bit more sophisticated level. While positive outcomes such as reduced backlogs will indeed be a result, there are many other things to consider as well, and they need to be considered before, and after the projects. Measuring afterwards means that we’re being reactive, rather than proactive. That’s not good.