JP Morgenthal

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.