How many hammer strokes does it take to shape a rock?

We are all aware that any IT project is full of challenges. The ones that involve changing strategy are even tougher. But those related to SOA adoption are perhaps in a class of their own.

Enterprise architects in a company find it difficult to get the IT community rallied around SOA Strategy and Adoption programs. An EA manager recently lamented that as far as SOA is concerned, he would need to start looking at the calendar and "throw that watch away!" Sadly, he is not alone. Many strategist-practitioners have expressed dismay over how long it takes to move even an inch with SOA projects. One always wonders “Can’t we do it faster? Why can’t we just bring all people and all apps to SOA Wonderland in one go?”

The problem lies not quite with people resisting change, but more with people’s understanding of SOA. Some people simply want to put a SOAP façade in front of every application. These people consider SOA adoption as tactical issue not fitting in the strategy domain -– “Just create a timeline to add SOAP interfaces to all applications in the company”. Others ridicule the idea of finding a service on-the-fly and simply start using it -- “Companies would never do business like that!!!” Yes, those are things you hear when you ask about SOA, but that’s not exactly it. It’s not that straightforward or ridiculous. And this is not the complete list of misconceptions people have regarding SOA (another one: “I don’t want others to use my Web service until I can charge their location code).

In comes an SOA Strategist whose primary job is to do away with such misconceptions and apprehensions. Yes, SOAP interfaces, service discovery, reuse will all be involved in SOA adoption. However, a workable SOA adoption strategy involves creating (or adopting) a place for all of these, a context in which they are applicable and a process to do so. And this takes time. It involves qualifying service-worthy resources, creating service registration and governance processes, and a resource sharing and cost sharing agreements. Of course, not all such aspects are applicable in every SOA strategy. Nonetheless, these measures will ensure that the SOA adoption goals are not marginalized and people understand what it is and what it takes to make it happen. Taken together, each such step is building a robust SOA for the company.

Recently, while working with a client on SOA adoption, I discovered an excellent analogy for that. I’ve been working with an enterprise architecture group in a company that is putting forth a roadmap for IT to adopt SOA. Despite several slides, documents, POCs and use cases, there seemed little movement in an SOA direction. But just when everybody thought we should give up, a series of Aha’s led to the first ever SOA-based project to be implemented for the company. The IT director with the group shared a childhood story; one day he was watching his grandfather, a mason, shaping a rock by moving a big chunk off it. After that was removed, the grandfather asked, “So which stroke shook away the stone piece?”. “The last one of course” answered the young grandson. “Nope”, replied the grandfather “Every single stroke did it – a little every time.” What are your experiences with implementing SOA strategies? Is the mason right?