Funding SOA
Most entrepreneurs and salespeople know that in order to make a sale, a deal needs three key ingredients: need, urgency, and budget. It’s hard to sell anything if the prospect doesn’t have a need for it, and it’s likewise hard to encourage a short-term purchase if there’s little urgency to implement the solution today versus a few years from now. Most importantly, it’s impossible to sell any sort of solution if there simply isn’t any budget to make the purchase happen — even if the prospect needs the solution urgently. Given that ZapThink spends much of our time discussing the need and urgency for implementing SOA projects, we’d be negligent if we didn’t discuss the third key ingredient to making SOA happen — funding. Simply put, where is the money going to come from to pay for SOA projects?
The first challenge that any architectural initiative faces is that architecture itself doesn’t have any features. Business executives generally seek specific capabilities, features, and functions from IT initiatives that address tactical business problems. They require that the solutions they buy address immediate business imperatives such as reducing expenditures, increasing sales opportunities, improving customer satisfaction, enabling new channels for interacting with customers or partners, or allowing their companies to gain greater insight or control over their daily operations.
Architecture initiatives, however, tend to be more strategic than tactical. Since architecture is essentially a discipline and set of approaches for designing complex systems, it doesn’t provide by itself any of the tactical benefits that business executives typically budget for, although specific implementations of the architecture might in fact do so.
SOA initiatives are even less likely to provide specific tactical benefits than other architectural projects, because the core of an SOA project consists of building the Services abstraction layer, and abstraction layers themselves don’t have features. As a result, one of the greatest challenges for those selling or seeking funding for SOA solutions is identifying a specific business imperative that depends on SOA yet promises low cost and risk, and also the greatest return. The challenge organizations face, therefore, is in identifying the places in the organization where there is sufficient budget for SOA projects.
Funding Enterprise-wide vs. Departmental Projects
One of the universal rules of project funding is that it’s always easier to fund a smaller, more tightly scoped project than a larger, broadly scoped one. While ZapThink has seen a handful of enterprise-wide SOA initiatives of significant scope and size, these projects are a rarity simply because of the amount of time, risk, and cost involved in implementing them. 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. Without their support, such projects rarely get off the ground.
It’s no wonder, then, that most successful SOA projects to date are at the departmental or pilot level. Starting small not only gives a project a greater chance of success, but also enables incremental funding by mid-level managers who can use their discretionary budget to make things happen. While small projects won’t have the strategic benefits of enterprise-wide SOA initiatives, they often solve more tactical problems, such as the reduction of integration costs or enabling Service reuse for a particular, well-defined set of business Services. These projects typically have manageable budgets and can take a few months or less to implement. Furthermore, they can have an immediate return on investment within a few months of their implementation.
However, selling SOA at the departmental level is not trivial. SOA champions should focus on short-term, tactical goals that solve immediate problems and enable the department to learn how to apply SOA for incremental returns. It’s often best to concentrate on one to two quarters’ business goals, and then seek to incrementally implement SOA to meet longer term goals while lowering cost and risk and providing greater agility. Simply put, departments require solutions that solve today’s problems with today’s budgets, but must also introduce an architecture that can solve tomorrow’s problems as well without requiring any significant additional investment.
IT vs. Line-of-Business vs. Architecture Group Funding
Even at the departmental level, it is not entirely clear who should be paying for SOA. One could argue that since SOA is primarily a technical concept that leverages IT to solve business problems, the IT department should fund and continually manage the solution. Today’s IT budgets, however, face a daunting roadblock. Most IT departments find that the bulk of their budgetary dollar goes toward maintenance expenses, with only a small percentage left over to devote to new innovations. New SOA projects typically come from that new innovation sliver of the budget, which puts IT executives in the difficult position of balancing their SOA projects with all their other strategic IT initiatives.
As a result, many companies are looking to fund SOA projects not from IT budget dollars, but rather from the line-of-business (LOB). Most coarse-grained Services should map directly to business imperatives, such as customer support, back-end operations, or reporting capabilities, after all. As such, the sales, marketing, customer support, or operations groups should directly contribute their dollars to make those Services happen. As we discussed in our ROI of SOA ZapFlash, the LOB should consider the IT department to be a third-party service provider to their organization, supplying the infrastructure and know-how to build the Services, but funded from the LOB. In fact, by applying this logic, companies can easily build an abstracted Service model that represents the business needs for Services independent of the IT department’s tactical needs. The IT department can then recoup any of their costs using charge-backs or other means for charging the LOB for the use of their resources.
A third, more innovative answer to the SOA project funding conundrum is for enterprise architecture to be neither the responsibility of the IT department nor the LOB, but rather funded as a strategic department itself as part of the office of the CFO or CIO. Forward-looking companies are coming to realize that enterprise architecture is a strategically important capability that requires its own funding, line of control, and business metrics — in other words, enterprise architecture can be a separate LOB in its own right. As such, it makes no sense to separate this capability without giving the architecture group its own budget.Enterprise architecture as a separate LOB is a new and potentially risky concept, but ZapThink 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.
Robbing Peter to Pay Paul
What happens when there is no separately funded architecture group, and neither the IT nor LOBs have any budget to fund SOA projects, in spite of any need and urgency? In that case, companies should be looking to recover costs from existing IT projects to fund incremental SOA projects. In other words, IT executives should fund SOA initiatives out of the maintenance portion of their budget, rather than the innovation portion.
In particular, companies should be looking to recover the wasteful expenditure on tightly-coupled integration projects that should go by the wayside in any case in order to implement Service-oriented initiatives. It simply doesn’t make sense for companies to complain of a lack of money for sub-$100k SOA projects, while they spend millions on maintaining brittle, tightly-coupled integration projects that do nothing to advance their architectural goals. After all, the best way to get out of a hole is to stop digging.
In this case, the best way to both advance SOA initiatives and obtain budget for those projects is to reduce the expenditure on EAI maintenance. Companies can stop throwing money into the bottomless pit of IT spending by taking the first step on the SOA implementation roadmap — replacing proprietary interfaces with Service interfaces, thus taking the first step on the path away from tightly-coupled integration to the benefits of agility, Service reuse, composition, and less expensive integration overall.
ZapThink Take
No executive will fund an SOA initiative by reducing EAI maintenance costs unless they have a clear picture of the ROI they can achieve by making such a choice. Fortunately, ZapThink not only expounds on the problem, but offers a solution — we now offer an SOA ROI analysis service that quantifies this forward-looking ROI. After all, one of the core business benefits of SOA is in leveraging the reuse of IT assets to improve efficiency and reduce the maintenance expense that sucks dollars out of too many IT budgets today.
It’s important to keep in mind, however, that every emerging technology or approach faces the challenge of entering a market where companies have no established line-item in their budgets for the new innovation. Many technologies fail because they simply do not provide sufficient business justification for creative funding approaches. To avoid this trap with SOA, companies must focus on the here-and-now of business issues, applying Service-oriented techniques to derive ongoing business value, and leverage incremental success to ensure continued funding for greater reward.