Todd Biske: Outside the Box

I finally decided to post regarding the Nucleus Research/KnowledgeStorm study that many of the SOA bloggers have been commenting about. In the InfoWorld article by Paul Krill, David O’Connell, senior analyst at Nucleus, is quoted as saying, “Only a minority of companies are getting a return on investment of SOA.”

Like many others, I don’t put a lot of faith in anything that tries to associate ROI and SOA. ROI should be addressed at the business initiative level, i.e. something with quantifiable business benefit. Opening up a new store location has quantifiable business benefits. The elimination of certain paperwork associated with an employee hiring process can have quantifiable business benefits. SOA isn’t a project, but rather it’s a way of approaching the technical solutions within a project. I can apply the principles of SOA to the automation of employee hiring processes. I can apply the principles of SOA to the technology pieces associated with opening a new store.

If we want to narrow the discussion to something more closer to where SOA can have an impact, we can look at development costs. As has been stated by others, however, this really only deals with the area of reuse. How do you capture the ability of IT to work closely with the business and save time on analysis because of the better mutual understanding of how technology and business come together? It should be reflected in lower development costs/quicker time to market. At this level, however, things get fuzzy. Ultimately, however, the more important point is whether or not business value is being produced. The development cost of the technology is just one piece of the puzzle in implementing a business solution. IT should always be striving to improve itself and continue to bring those costs down. Do you even know what these costs are? Are you collecting metrics about your development processes to know whether things are getting better or worse? Even if you want to attach ROI to SOA, if you don’t have the before and after numbers, all you’re getting is someone’s gut feeling.

This entry isn’t meant to say that we should simply ignore ROI and just do SOA because it’s the right thing to do. That sort of blind adoption can be just as damaging as not doing anything. The point is that discussions around ROI at the executive level should be about business benefits. You can’t just define and run an SOA project. You run business projects, and apply SOA within it. The ROI for the executives is based upon the ROI of the business project, of which SOA is just one piece.

2 Responses to “SOA and ROI”