Lately, and primarily among government users, I’ve been hearing about a potential clash of bureaucracy meets technology when it comes to funding shared services.  It seems that the current government procurement and funding processes do not favor strategic sharing of software services as an outgrowth of a single development effort.  I imagine that this issue might also arise in some large organizations where the business units are funding development using a self-funded IT organization, but I have yet to hear any specific stories coming from the private sector regarding this issue.

While there seems to be a number of workarounds to this problem, the basic issue still remains.  If one government customer funds the development of an application out of their budget, and in developing that application, it is decided that one or more services could be of use to other government customers, there may be budgetary concerns for actually developing, hosting and maintaining those services for those that are not the original funding customer.  Moreover, it becomes questionable how to go about adding features to those services when the requests are not coming from the original funding customer.

With all these government agencies pushing SOA in their IT strategies, one has to wonder, what exactly are they asking for?  If the goal is not to remove redundancy within a single department and within a single agency–we’re not even focusing on cross-agency here–as a means of reducing costs and providing a single means of delivering a business function in a non-ambiguous manner, then what is the goal?

From my own personal experiences, I believe certain agencies do desire to achieve the benefits of SOA, while others are simply seeking the benefits of component-based architecture, which is flexibility and agility in application design to lower costs of maintenance.  However, due to “management by magazine” approaches in IT coupled with the “slap SOA on everything” mandates, agencies that are capable of only benefiting from component-based architecture–because of the procurement and funding issues or just basic needs–are now requesting SOA and ending up spending a lot more to develop a simple application than they should have in the first place and getting a lot more complexity and reliance on middleware infrastructure that is, at best, using a sledgehammer to kill a flea.

Now, most of this entry discusses the issue with regard to SOA, since this is where the problem has really become apparent recently.  However, it’s not too far of a leap to envision that Cloud Computing, that bastion of shared compute power, is going to have similar and more complex hurdles to overcome with regard to maintenance and operations of applications running in the Cloud.  At the end of the day, someone responsible for budgeting today is going to have to figure out how much is required to support and maintain one of their applications next year.  That may not be too difficult a task when they are the only  group consuming that application, but the budgeting process is far more difficult when that agency accidentally becomes a SaaS provider to other agencies and departments interested in using that application.

Got any private or public sector stories regarding how the budgeting and procurement processes are hindering the strategic value SOA?   Please share them with me as I am really interested in understanding the full boundaries of this issue.

2 thoughts on “The SOA (& Cloud) Funding Dilemma”
  1. Great observations and already being addressed well like in this presentation by Dave Mayo, at the 7th SOA for e-Gov, this past April (see slide 25).

    Service Oriented Government

    The Historical Approach – Agency Focused…
    Citizen Service: Many agencies and offices; not one government
    Performance: No common framework for performance measurement across agencies; minimal budget-performance integration
    IT & Services: Redundancy within and across agencies
    Budget Allocation: Allocation of funds by Agency; minimal cross-Agency analysis

    The Future Approach – Mission and Service Focused…
    Citizen Service: One government
    Performance: Common performance measurement framework for OMB and all agencies; robust budget-performance integration
    IT & Services: Minimal redundancy in IT spending; component-based architecture promotes reuse
    Budget Allocation: Budget analyses take business lines into consideration; funds allocated to support cross-agency collaboration

    Source: Dick Burk, 2005

    It is truly going to take a cultural transformation in the way government works in funding and providing services to their many consumers.

  2. Hi all,

    I just sat through a presentation from the Australian Bureau of Statistics. They appear to not have the cloud dilemma. I heard that they insourced in an SOA manner (the wider meaning of SOA – offer IT as a service). They provide an internal cloud for all business units with a cost recovery model, based on 12 months demand planning.

    At least the Cloud appears to not be so much of a dilemma for them after all.


Leave a Reply

Your email address will not be published. Required fields are marked *