SOA needs a funding model

Who's going to pay for this SOA? Please don't all jump up at once. In my last post, I quote Gartner's Joanne Correia, who made the observation that obtaining funding for projects that promise to "reduce complexity" is one of the biggest roadblocks to SOA.

One of the biggest questions around SOA, which is designed to be shared across the enterprise, is: who in the enterprise is going to put up the money to get it all started?

I pondered this question a couple of months back in a write-up posted at Webservices.Org, and here's the gist of it:

A little while back, I had the chance to chat with Michael Liebow, vice president of SOA and Web Services, IBM Business Consulting Services, who said that there hasn’t been a whole lot mentioned about the financial side of governance of SOA projects, namely that the costs of SOA projects should be shared by various parts of the enterprise.

“Today IT projects are funded on a project level with strict ROI,” he pointed out. This is, essentially a non-starter for conversations about SOA, he added. “You can't go to that business owner, and say, 'hey listen, we're going to create a set of services that can be reused across the enterprise, and it's going to cost you more than if I did it the normal way.'”

“You can imagine that conversation. No one wants to foot the bill, and be that magnanimous. They've got businesses to run; let somebody else pay for it.”

SOA is a cross-enterprise initiative that can benefit all business units that come into contact with it. The question is, who’s going to foot the initial bill to help out the rest of the organization?

IT is a logical place to start, but IT departments are famously strapped with tight budgets and ongoing maintenance expenses. Line of business? Sure, which ones will open their wallets first? If the marketing department absorbs the costs of developing and maintaining that customer name and address lookup service, how will they feel if finance and customer service gets to use it for "free"?

Attend enough conferences and read enough articles, and you'll hear plenty of stock phrases about ‘business and IT alignment.’ But the bottom line of all this utopian thinking is the bottom line: who’s going to ante up the funds to get this project rolling?

It used to all be so simple. The call center was billed for the call center application, human resources was billed for time and materials related to HR management systems, and so forth. But when you’re talking about building an inventory of components that will be made available to any business unit that needs it, how will that business unit be made to pay for the service? Who will pay for its creation in the first place?

In a recent analysis of this very same question, ZapThink concludes the issue is that SOA tends to be a ‘feature-less’ architecture, versus a specific solution for a specific problem. Thus, SOA ventures tend to start as “smaller, more tightly scoped projects,” funded by mid-level managers’ discretionary budgets.

This becomes problematic if a service begins to cross departmental boundaries. “The larger the project, the more levels of management must participate, stretching out the sales cycle and raising the stakes for everyone involved. For enterprise-wide SOA projects like those that corporate governance or regulatory compliance motivations drive, obtaining funding is a matter of getting buy-in at the very highest levels in the organization, often the CIO or CFO.”

The SOA library of components could be regarded as a separate 'line of business' in its own right, administered through the CIO's office. Even at the departmental level, it is not entirely clear who should be paying for SOA, ZapThink adds. ZapThink proposes that the SOA library of components could be regarded as a separate "line of business" in its own right, administered through the CIO’s office. The effort can be started gradually, rolling out a few services at a time, versus a more big-bang approach. ZapThink observes that it “has already seen some companies take the bold step of creating such a separately funded architecture group that has control over SOA projects across the enterprise.”

“Governance” brings to mind images of repositories and registries. That’s part of the picture, of course, but governance also has a very high-level place in moving projects forward as well. Namely, who gets how much, to do what, for whom, and where the support for the effort is going to come from.

SOA is a never-ending process of adding new functionality, users, and tools. It isn’t built with a single project, but rather, through an ongoing series of projects. An effective good governance structure may help answer the question of who pays the first bill, and how the organization should prioritize, validate, and manage this ongoing series of projects we call SOA.