SOA as a Corporate Responsibility

David Linthicum of ZapThink wrote a short article recently on SOA as a Corporate Responsibility.  While I enjoy reading David's writings, there were a few things in this article that made the hair on the back of my neck stand up.  The article ended with the advice to:

"resist the temptation to redirect resources toward tactical business needs"

If I were a CFO and someone in IT told me, "We want to embark on a significant change to our environment.  It's extremely important and strategic. It's going to cost a lot of money. We won't see any measurable business benefit for a long time.  Can we get your OK?" I'd tell them to stick their proposal where the sun doesn't shine.  Any responsible CFO would do the same (though perhaps a bit more tactfully).

It's just a fact of modern business that you have to demonstrate business benefit (i.e. ROI) quickly.  In a CFO's mind, anything which cannot be measured doesn't exist as far as budget allocation goes.  Your SOA infrastructure strategy must show tactical business benefit.  So even if you must direct budget towards achieving that benefit it's in your best interest to do so because if you don't, you won't get the chance to see your strategy out to is completion.

Backtracking a bit in the article, though, David says:

"the reality is that many of these enterprise architects simply don’t have the political or budgetary authority within their companies or government agencies to make much of a difference"

To me this sounds very self defeatist - it's an excuse someone uses when their SOA strategy fails: "The man never gave me what I needed to succeed."  The reality is that you don't need budgetary authority and you can create political clout (certainly no one can give you political authority - it's not a transferable commodity).

SOA What? Ok, let's break this down then:

• Why don't you need budgetary authority?  The reason is, is that if you do SOA right, projects should be able to be done more quickly with fewer resources.  What CFO is going to turn down demonstrable proof of lower costs and better results?  Easier said than done? Well, yes.  SOA gradually results in economies of scale so once your SOA initiative is well entrenched, the faster-better-cheaper should be obvious - if you're not achieving this over time then you've got something seriously wrong.

  The real trick is achieving these benefits on the first project.  At the outset of a SOA initiative, not every project will show measurable benefit of using SOA... but some will.  The key is to choose the right projects. You, as an enterprise architect, need to learn to say, "no."  "No, this project shouldn't use SOA techniques yet."  "Yes, this other project should."

• Look for the projects which most benefit from SOA infrastructure.  Typically these are customer facing projects (for example creating a common customer portal).  Most importantly, you must devote some of your time to help make the first projects successful.  These are new technologies and techniques - all with learning curves.  But, there's a more subtle reason as well -- putting more smart minds on the project (even if you maintain the status quo on technology) should produce better results.  That's right, by spending your time (not budget) on helping a project be successful, you're stacking the deck in your favor.  You can chock it up as a SOA initiative victory even if the only reason it succeeded was by the personal assistance you provided the project team.  No one will know the difference but it's in your best interest (now we're talking politics) to say it wasn't your help that made it succeed, it was the ingenuity of the project team who deployed the SOA that made it successful.
• Now, onto the question of political capital.  If you don't have it, how do you create it?  You can see from the above, you already have.  You made the project team successful.  You made them the heros.  You've built the political capital you need.  More generally though, there's a simple recipe to building political capital - make people's lives easier.  If you can make the lives of a project team easier, I guarantee you the word will spread and you will build up that political capital that you need.

  Now, you won't make people's lives easier by trying to introduce draconian rules, policies, SOA governance infrastructure, etc.  You will make their lives easier by understanding what makes it hard and actively looking at ways to get rid of that complexity.  If they are struggling with creating security code in their application, give them tools that offload security for them - it will make their lives easier, they will be more productive, and project costs will go down (even if they need to buy additional software the productivity costs should be able to pay for it if you choose the right infrastructure).  This will build up your political capital.

In the end, don't let anyone tell you that "all you need is X" to make SOA successful.  Whether that's a vendor hocking their products, consultants hocking their services, or analysts hocking their methodologies.  You can make SOA successful if you tackle it one step at a time - delivering measurable business benefit at every stage.  Just call me the Tony Robbins of SOA.  :-)