IT as a Catalyst for Optimal Business Outcomes

In the spirit of full disclosure, I've been spending the better part of the last five years immersed in the primordial IT ooze known as SOA. Over the past year, however, it's been a turbulent place to exist as we have faced the barrage of blogs and articles asking "Is SOA Dead?" or "Is SOA doomed to fail?"

I'd like to address these questions right off the bat so we can move on to how to leverage SOA for business results. The first question "Is SOA dead?" or, to paraphrase "Is SOA yesterday's technology fad?" is quick to address. First the facts: SOA is an architectural pattern or best practice being adopted by a large percentage of companies today. I've heard quotes ranging from 50-80% adoption depending on how you segment. So if this is true, why are we still hearing that SOA projects lack support? If architects are keeping their focus on architecture as a foundation for IT innovation with an end-goal to respond to the needs of the business, and one of the proposed architectural approaches is SOA, then I think the intentions are in the right place. Most likely, these architecture teams will continue to garner support for their architectural adoption of SOA.

By the way, for an interesting perspective on whether architecture is the enemy of innovation read this article by Jon Ayer on the Enterprising Architect. The litmus test is to make sure the SOA effort addresses a true business need or innovation, and is not just for the sake of having a better gadget.

We've all heard that it is a fool's errand to try to justify a SOA project because it's the best technological approach. We've seen success when an IT organization can align its SOA initiatives with its company's strategic business objectives (see my initial blog) and show specific proof points as to why adoption of SOA is foundational to the desired innovation (i.e. to speed delivery of new mobile services, accelerate data integration for multi-channel customer care or rapidly integrate several internal and partner systems to support a converged order management billing platform). In these cases, the architecture team knows why it is doing SOA -- to support clearly defined business goals.

So why is SOA failing? In my opinion, it's too early to ask why SOA fails. I think a timelier question may be "Why do projects based on the principles of SOA fail?" Here's a quick metaphor: my first round of golf was a complete failure. Did that make me a failure as a golfer? I don't think I could say that. I realized what I lacked were skills, education, practice and discipline. I'm now taking lessons. It is conceivable that I may turn out to be a failure as a golfer, but one round is too early to tell.

I think many have made initial attempts to deliver projects based on SOA, but they are finding out that adopting SOA is not that easy, and SOA doesn't just happen. We are now in the phase that I would like to call the "SOA school of hard knocks," where we are learning what it takes to effectively infiltrate SOA into the IT consciousness as an architectural approach and methodology to more easily modernize applications for clearly defined business outcomes. Initial projects may fail based on some well proven reasons. Here are a few examples:

-- Lack of investment in attaining SOA skills and education

-- Lack of a definition of SOA project objectives and measurements -- how do we define and evaluate success?
-- Lack of integration of the SOA effort with the rest of IT and the application lifecycle

But this doesn't make SOA a failure if an organization has the ability to learn from its mistakes and the intestinal fortitude to continue the effort, keeping the business goals in mind. The benefits of taking the SOA journey will come for the organizations that have the patience to build the foundations for success -- skills, education, cultural change, clearly defined measures of success, governance, linkages with the rest of the application lifecycle, and alignment with the business.

Back to the golf lessons.