Todd Biske: Outside the Box

Two recent posts by Jeff Schneider and Nick Malik, recently brought some attention to a very important aspect of SOA, which is funding it.

Jeff’s post, entitled “Budgeting for SOA” gives a great breakdown of all aspects of adopting SOA, which based on my experience, would certainly be a multi-year effort. He begins with establishing the SOA Foundation, which includes establishing a strategy, roadmap, reference architecture, and governance strategy, continues on with SOA Infrastructure Realization, establishing a SOA Governance Team, performing architectural analysis, training the staff, and then building the services and their consumers. Jeff articulates the costs associated with each of these for a typical organization based upon his experience.

Nick’s post, address the other side of this, which is where to find the money. In his post, SOA Economic Model: Avoiding Chargeback with Transaction Ration Funding, Nick calls out his disdain for chargeback models, and instead presents an alternate view whereby shared resources are funded out of a fixed operating budget that is funded through some form of flat tax. The teams that are funded by this pool are then allocated funds based upon the amount of transactions they process. While Nick presents a very simple model based upon the number of transactions, I’m sure other funding models could be used since a simple request count doesn’t take into account the complexity of the services, but his model is accurate in that it properly incents the service development teams. The teams that use the services are going to pay the tax no matter what, so they’re also now incented to make use of the services being provided, unlike a chargeback model whereby they pass less if they don’t use the shared services.

I think both of these posts do an excellent job of laying out the possibilities. Unfortunately, I wish more organizations were at the state where they have to worry about these factors. It seems that the vast majority of organizations are simply trying to build services out of existing efforts. Unless those efforts are sufficiently broad in scope (and surprisingly, many organizations I’ve seen do have at least one major initiative that typically qualifies), it’s unlikely that services will be created that will have broader applicability. Now I consider myself an optimistic person, but I also recognize that this is not an easy challenge. To get to what I envision and what Jeff and Nick describe represent fundamental changes in the way software development takes place. To do this will mean leveraging staff that already operates out of a shared funding model, such as enterprise architecture, since their efforts merely need to be assigned by the EA manager. If the EA group establishes the appropriate strategic models, smaller projects with limited scope can now demonstrate how the will contribute to broader strategic goals, thus warranting funding of shared services, versus doing things they way they’ve always been done. All of this comes back to something that I frequently bring up in discussions around SOA adoption. If the only thing that’s changed within IT is that the same old projects that we’ve been doing for years now are creating services within them, do we really expect to see any kind of dramatic change within IT, or will it just be chalked up as another overhyped trend? I, as an EA, certainly plan on doing everything I can to make sure that’s not the case. We have to be careful not to bite off more than the organization can chew at any given time, but we also need to make sure that we are the impetus for change.

One Response to “$OA”