Monday, March 23, 2009

SOA Funding Models

One of the primary reasons SOA efforts fail in many companies is simply due to inadequate or inappropriate funding models. Costs are typically at the core of every problem and SOA programs are not exempt. We hear horror stories all the time – the initial investment to establish an SOA environment was too high, so the effort was cancelled; there are many services created in the company but they are hardly reused; etc. Establishing a funding model that is right for your company is the key to moving the SOA program forward.

Any SOA initiative is comprised of two parts – infrastructure and services. Both need to have a separate funding model established in order to successfully support SOA program’s goals.

SOA Infrastructure Funding

Infrastructure funding requires a pretty straight forward approach. When discussing SOA infrastructure, I am referring to shared platforms that are used by a number of services across the organization. Some companies host services on the same platforms whose functionality is being exposed. However, even if this is the case, some shared infrastructure components like ESBs, service management technology, Registry/Repository, etc. must exist to support SOA program’s needs. Thus, it is safe to assume that some form of shared SOA infrastructure exists. There are two possible ways to provide effective funding to build it out.
  1. Fund all the SOA infrastructure centrally
  2. Identify appropriate projects to acquire / extend new / existing SOA infrastructure
Central funding is probably the easiest and most effective approach. It allows the organizations to establish an independent roadmap for introducing and upgrading SOA infrastructure. It also makes the SOA program operate more efficiently as the cost, scaling, and availability issues will no longer be relevant to individual projects. If central funding option is selected, several approaches for recouping the initial and ongoing investment can be utilized.
  • Do not recoup the investment
  • Place an entry fee to use any SOA infrastructure component
  • Charge a small fee for each usage instance

Since all the SOA infrastructure is provided centrally, not recouping the initial investment is a real option. If the organization’s fiscal model does not call for IT recouping all its costs from the business groups using their products, this option works well. If this is not the case, however, you have a choice between placing a predefined entry fee that each application / project must pay to use the specific SOA infrastructure platform and charging end users based on the total usage.

The per-use-fee scenario is a little tricky as each SOA infrastructure component needs to define what a transactional unit is and how much to charge for it. Transactional units can be different for each SOA platform. For example, an ESB transactional unit can be a service call, Registry/Repository – an individual user and/or a UDDI request, etc. In this case, total usage amount based on predefined transactional units would be calculated, multiplied by the unit cost, and charged to the business units. The most effective way to determine a unit cost is to divide the total investment made in the platform by the total transactional units being consumed. The obvious effect is that unit costs would decrease with increased usage. Here are all the formulae discussed above.

Usage charges per platform:
Unit = Different per Platform
Unit Cost = Total Platform Investment / Total Amount of Units Consumed
Line of Business Usage = Units Used by Line of Business * Unit Cost

Some companies have chosen to grow their SOA infrastructure gradually, without a central program or funding. A typical approach in this scenario has been to attach SOA spending to the most appropriate projects. Thus, the projects would purchase new SOA infrastructure platforms or upgrade existing ones to suit their needs. There are several problems with this approach.

  1. Typically, the projects purchasing the infrastructure don’t want to share it with other potential consumers unless there is significant pressure from above. The platforms don’t end up being reused or, if so, only minimally. The projects do not have any incentive to sharing their investments with anyone else, especially since they are seen as critical to projects’ success.
  2. Projects often get cancelled due to over-inflated budgets. SOA infrastructure is expensive and cost conscious enterprises do not want to invest into what looks like excessive infrastructure for project’s needs.
  3. Demand to extend a platform based on project’s needs typically comes without enough lead time to accommodate project’s timelines. Thus, projects face a tough decision – to extend their delivery date or use alternative infrastructure.

Funding the SOA infrastructure centrally is more effective in delivering service-oriented solutions faster, moving the enterprise more efficiently towards a higher level of SOA maturity, and addressing the project needs. Project-based funding will most likely spell doom to the SOA program as a whole.

Service Funding

As discussed earlier, funding for the SOA infrastructure should come from a central source. Where the money comes to build individual services, however, presents a bigger challenge. Since projects are the primary drivers behind demand for services, special consideration should be given to project needs and budgets. However, service design and implementation can incorporate additional requirements that fall outside of the project scope. Another typical project-related problem stems from the shared nature of services. It is unfair to burden a project with the full cost of a service that will be utilized by a number of other consumers.

There are three possible ways to address the service funding concerns.

  1. Make the first project to build a service provide the complete funding
  2. Establish a central funding source that will cover all service design and construction expenses
  3. Provide supplementary funding to projects building services

If option1 is selected, several strategies for recouping the initial investment can be used.

  • Do not recoup the investment
  • Place a surcharge on each instance of service leverage
  • Charge a small fee for each service call

As mentioned above, it is unfair for the project to carry the complete costs of the service build-out, especially if it includes additional requirements. Thus, unless the project implements one of the options to recoup its initial investment, funding option #1 is not going to be viable. Not recovering the funds is not a realistic option either as it does not incent the projects to build truly reusable services. The other cost recovery strategies may work but require detailed metrics to be captured on the service leverage and/or transactional volume.

Establishing a central funding source for all projects to use when building reusable services is probably the ideal approach. Few companies, however, would be willing to write what in essence would be a blank check for the projects to use in their service delivery efforts. The opportunity for abuse and misappropriations would be too tempting. Unless strong governance and control mechanisms are in place, this funding method will most likely end up costing the company more money and provide unrealistically small return on investment.

Providing supplementary funding to projects building services is probably the most realistic approach. A central fund needs to be established to cover the efforts falling outside of the project scope. Since shared services would typically incorporate other projects’ and enterprise requirements, the actual cost ends up being higher than what projects budgeted for their needs. Thus, the easiest way to distribute supplementary funding is to allow the projects to pay for functionality already included in their budgets and cover all the additional costs through the central fund.

Whatever the funding approach is used, it needs to be carefully administered. A party not involved in day-to-day project work is best suited to play the administrative role. There could be a couple different groups managing the infrastructure and service funding and chargeback mechanisms. Overall, however, this should fall under the SOA Governance umbrella and managed centrally as part of the SOA Program.

7 comments:

djbressler said...

Leo,

Nice post. Good detail.

As I read, what came to my mind is that the funding model needs to be driven by the organization culture. What's more important is affecting that culture so it can be successful in deploying an SOA.

A great book that covers this topic (that of the making SOA a success from a cultural perspective), and jumped into my head when I read your post, is Todd Biske's book on SOA Governance.

One really important thing to keep in mind, again from an implementation perspective, is that the services deployed really need to be treated like a product, and have a lifecycle with long-term ownership, care, and love. This, I think, is a little unusual for many companies who look at things from a project perspective.

Finally, I'm really glad to see that you guys don't consumer external services directly, but only do so through your ESB (that's what you said on LinkedIn). I think that's one of the magic secrets to success... though, personally, I'm not a fan of ESB anymore than any other mediation layer technology. Mediation is critical.

Good luck,

David Bressler
Progress Software, Actional
My blog @ davidbressler.com

Leo Shuster said...

David,

thank you for the feedback. I completely agree with you that services need to be treated like products. I address this topic in my Project-Oriented SOA article (http://www.soamag.com/I21/0808-2.asp). This is actually where one half of this blog post came from.

Thanks for the pointer to Todd's book. I have seen it but have not read it yet.

Yes, we have established a pattern to never call any external or third-party services hosted internally directly. I will expand on this point in a next blog post since this seemed to generate a lot of interest.

Leo

Ronen Lewit said...

Leo,
Interesting and well stated.
I believe the funding and pricing of services is critical for SOA success though seems to be pretty immature.
From what I see over our customers, they're far from achieving methodology to handle this.

Leo Shuster said...

Ronen,

SOA funding issue needs to be tackled as part of the larger SOA governance initiative. I have seen very little maturity in this space, which is reflective in your comments as well.

LeO_o said...

Great post!! TNX!! I'm impressed. In turn I'd like to suggest you reading this article on software architecture: http://techzone.enterra-inc.com/architecture/algorythm-of-defining-plain-polygon-signature-point/

Herb said...

Nice post Leo. There is another funding model that I have been tossing around and would like to hear your comments on.

A modification of the centrally funded model would be to use a Skype style model that would encourage the move to SOA. In this model the central governance body would impose a charge for all integrations implemented on legacy technologies. That funding would then be used to pay for the SOA infrastructure.

The deal is that parties that move to the SOA model are charged a much lower transaction cost than those running on legacy technology, thus encouraging the move and lowering their costs while simultaneously lowering the costs to the enterprise as a whole.

Thoughts?

amita jadhav said...

Hi Leo,
Great post.
I also came across your below article ”Driving SOA Governance: Part III” and it was quite enlightening.

http://www.servicetechmag.com/system/application/views/I52/0711-2.pdf

I am looking for options of how we can incentivize service reuse/creation(i.e. encouraging service providers to create more and more services which can be consumed by multiple groups).
1)One of the option my team was exploring is probably charging transaction fee/service request(whoever wants to consume the service will provide service provided transaction fee. This may increase the motivation
of service providers because now they have additional revenue stream).
2)Publishing quarterly newsletter which will highlight how many services were newly created/org. This can generate competition amongst all other orgs and help service creation increase.

I have been trying to research what mechanisms/options other companies have adopted for similar purpose. Would like to hear what your thoughts are.

Thanks in advance for your time.
Regards,
Amita Jadhav