03.31.08
SOA Revisionism
Dana Gardner today gave what seemed to us as a SOA valedictory, in a post with the rambling but apt title, “We know SOA depends on cultural shifts, but — like the weather — we still don’t do much about it.” He provided an interesting coda to an online dialog that involved a bunch of us over why SOA adoption at an enterprise architectural level has either grown, sputtered, or has taken a detour for recession. Gardner summarizes the litany that has to some, sounded more like a broken record. “The acknowledgment that SOA requires top-down, bottom-up, organizational and behavioral, ie “cultural,” change to proceed to its potential is well documented and debated. We have come back to this topic again and again,” he wrote.
Here’s the factoid: a Forrester Research study as reported by TechTarget’s Rich Seeley showed that SOA as an enterprise-level architectural initiative grew to 26% in 2007, up 4% from a year earlier. You can interpret that in one of two ways:
1. Enterprise SOA adoption continues making impressive gains.
2. After 5 or 6 years, enterprise SOA adoption is still an exception to the rule.
Here’s a related tidbit of trivia: our first mention of SOA goes back five years, while our first mention of web services dates way back to 2001. So it would be understandable to ask, what’s taken SOA so long?
Gardner put the answer in perspective: “Let’s recognize that a higher purpose is at work here, and that SOA is a subset — not even a leading driver, perhaps — of the end-game,” taking its place in line with other megatrends of the moment like SaaS, cloud computing, BPO, ITIL and so on. As he stated, a means, not the end. He jumps to the root cause for what really drives adoption: culture and politics, which in large organizations, “remains a mystical, quizzical patchwork of leaps, lunges and stumbles…Looking to SOA to change cultures seems to be a moot expectation.”
Whether you take a fill-in-the-boxes approach to enterprise architecture like the Zachman Framework, or you tout visions of a service-oriented enterprise, at the end of the day, you must have the right mix of players in place who can either leverage an organizational culture that already accepts change, or who are able to effectively sell the concept in spite of an entrenched culture of inertia.
It takes more than pure architectural or technical skills to pull it off. For instance, the Open Group’s emerging IT Specialist program -– which mirrors the internal certification programs that already exist in consulting firms like IBM Global Services, EDS, and Cap Gemini -– is predicated on the fact that being a successful technologist also requires distinctly non-technical skills. In his book Dealing with Darwin, Geoffrey Moore referred to the cast of characters necessary to shepherd innovation through its lifecycle: often, informal alliances of inventors and optimizers can overcome the natural gatekeeping tendencies of managers and deployers.
We don’t only say “amen” to what Gardner’s said, we should also say “mea culpa.”
All too often we fall in love with the perfection, simplicity, or elegance of an architectural solution while forgetting how it would work on the ground, or what it would take to sell the vision. In other words, we forget the people side of the story, or the reality that in most organizations, it’s easier to sell something akin to the old Holiday Inn slogan, that “the best surprise is no surprise,” as opposed to, “Change will increase your competitive edge.” All too often, change is bought only when survival is at stake, which sometimes is too late to make a difference.
Fear of change pervades any major IT initiative, just think of all those ERP projects that encountered unexpected complications. Specific to SOA, there’s the need to think about the ramifications of baseline concepts like loose coupling as far down as the job description level. And, borrowing some ideas from Moore, it wouldn’t hurt to find out from the folks who tweak or expedite things as to how to make service implementations more than one-shot deals.
David Mitchell said,
April 1, 2008 at 3:36 am
I’ve always said that is 10% software and 90% other stuff – mostly complicated stuff to do with people. The lack of re-use that happens is almost always down to factors in that 90% category. Project failures around SOA are mostly due to the 90% factors too.