By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Why do enterprise architects run into trouble convincing business executives to fund SOA projects?
There are a lot of reasons for that. But one of the primary ones we find is they try to justify SOA primarily on the promise of productivity tomorrow. They say something like: "I'm going to build a bunch of services today and I'm going to charge you more to do that Mister Business Unit and it will take you longer to figure out all the new technology, but, trust me, two years from now everything will be great." The ability for the business to stomach that proposition is thin. Do you have a strategy for how to tell a business unit what SOA can do to help them?
The strategy is to figure out what are the benefits of SOA that can be turned into numbers. What you're trying to do is decompose your SOA program. Forget about the technology. Forget about the architecture. Break it down and say if you could wave a magic wand and SOA existed what would be the result that would work into a business case. How would it affect the numbers of the business? What kinds of cases can you build with numbers?
One is what we call IT leverage. That's the concept of reuse and being more productive with SOA. Basically, I'm going to build things today that are going to make me more productive tomorrow. That's the most common strategy. The good news about that one is you can track it out. If it costs me $100 to build a service and it's going to cost me $20 to reuse that service, then every time I reuse it, it saves me $80. I can do the same thing with time to market. If it took me 100 hours to build a service, and I can reuse it in 20 hours, then every time I reuse it I save 80 hours. That saves IT time and also speeds up business projects. So those are techniques for quantifying the leverage you get from SOA on the IT side. You can prove that out in terms of cost avoidance or cost reduction or improved time to market. So IT leverage is the one most people are trying to build a business case around. The problem with this category of benefits is that for the most part the business doesn't really care. It's kind of a nice-to-have. And even if they do care, this case is built on futures. It's pay me now and I'll save you later. So what do you do about that?
You can do a thing we call "look forward and look back." For look forward, you say, "Okay, if I build this service, it's going to save me X dollars over a year." Then you point out how many projects you have in a year and how much that will save. But you have trouble getting business people to buy into the idea that you have all these projects in the future and you're going to save all this money in the future. So we recommend looking backward. You say, "If I'd had SOA a year ago, how would it have affected last year's budget." That makes it a little more concrete and a little more real. It's a little more of a sanity check. You say, "Last year I would have saved $100,000 and this year I'm saying we'll save $150,000." Clearly that's not out of the realm of possibility. Since it's last year's budget, you can actually point to projects that people actually know and have already scoped. The problem with pay-me-now-I'll-save-you-later is you're trying to predict what projects are going to come. In many cases, the business itself hasn't scoped them out to that level yet. So it makes it harder to validate that.
There are different variables or statistics you can pick depending on the culture of your company and what will be the most resonating. Some companies are focused on time to market. It's all about how fast can I get stuff out the door. Other companies are cost conscious. How can I do more with less? So you build your business case in the areas that will be more powerful for your company. So it's important to put numbers on the SOA value chart?
Absolutely. SOA, even the name of it ends in this word "architecture." Architecture is an abstract thing. It's very difficult for business people who get measured on profit and loss to believe that this abstract architecture is going to help them. The whole key to getting funding is translating SOA into the language of business funding.