SOA is about Architecture

Blogger: Anne Thomas Manes

Thanks to Jeff Schneider for pointing this article out to me.

It's been more than 7 months since I published the "SOA is Dead" post, but responses are still coming in. Most recently (yesterday), Dan Woods published an article on Forbes.com entitled "Reviving SOA". I'm pleased to see that Dan read beyond the first paragraph, and he understands the core message of my post (i.e., "SOA has been disappointing and that services should be a key focus"), he nonetheless fell into a common trap of misinterpretation, as I described in my follow-up post, "SOA Obituary: Misinterpretations and Perceptive Enrichment."

Dan falls into the first and largest camp, "Big SOA is dead, but little SOA will survive." He also has a touch of Camp 2, "REST will fix everything." He claims that "REST" is now more popular than SOAP. By "REST" I can only assume that he means plain old XML (POX) over HTTP, because I can assure you that the REST architectural style is much less understood than SOA. And a recent survey of Burton Group clients (mostly F500 companies) clearly indicates that REST is not yet a popular topic among large enterprises -- as much as I try to promote it.

Dan recommends an incremental approach to SOA: Just build services as you need them on a project-by-project basis, and at some point in the future you can go back and consolidate the services you've built and somehow derive some architectural consistency. Unfortunately, this strategy invariably leads to Just a Bunch of Web Services (JABOWS) because the future consolidation step almost never happens. The result is too many services, too many moving parts, and too many brittle connections. Systems wind up being more expensive and more fragile than ever before. #FAIL

I've only encountered one company to date that has succeeding using this method -- and I must point out that they maintained strong architectural governance of all services as they were built.

In particular, Dan misinterpreted my comment, "If you want spectacular gains, then you need to make a spectacular commitment to change." He took this as a recommendation, when it was really intended as a warning.

One of the biggest reasons that SOA "died" is due to unrealistic expectations. The hype has suggested that all you had to do was deploy an ESB and use web services and miraculously you would gain reduced costs and increased agility. The truth, though, is that architectural improvement does not come for free. It requires a concerted effort to improve the application architecture. If you aren't willing to make that concerted effort, you won't gain spectacular results. 

The Bottom Line:

The highly-touted benefits of SOA derive from architectural improvement, not from any particular technology. But architecture is hard. And it requires a fair amount of organizational maturity to accomplish. Organizational maturity is a function of five organizational dynamics:

• Governance: Establishing policies, guidelines, and decision-making authority
• Management: Enforcing policies and directing day-to-day operations
• Leadership: Inspiring people to perform
• Skills: Ensuring people know how to do what they need to do
• Practices: Establishing structure that helps people do what they need to do

Attempting to do SOA without also attempting to strengthen these five organizational pillars will invariably result in failure. Hence my warning: If you want a spectacularly successful SOA initiative, you must first address these organizational and cultural issues. Strengthening these organizational dynamics invariably requires a spectacular commitment to change.

Comments

[Rotkapchen]

Yes, but the answer is a bit deeper than that. It starts with this...Bill Buxton (Microsoft) reiterates what I've been blabbing for a while -- IT doesn't know how to hire REAL architects. It starts with their job descriptions. They hire for tool jockeys, bit twiddlers. Buxton calls them "structural engineers", I call them "drafters". Typically they're just 'old coders'.

[Ed Horst]

We continue to see customers succeed with a blended approach of both:

1) A overview/"roadmap"/concensus of where their overall SOA inititive is taking them -- enough, but not too much analysis of the overall picture of the common services they are moving toward.
2) Combined with a few projects with deadlines where they gain practical experience to feed #1, above.

[Anne Thomas Manes]

Ed: I agree with you that a blended approach is typically the right model for most organizations to get started with SOA. Let me clarify: We don't recommend an autocratic, centrally managed, tightly governed, "BIG" SOA initiative. Too much central management and control typically results in analysis paralysis and the ivory tower syndrome.

When we talk about strengthening the organization's pillars (governance, management, leadership, skills, and practices), we aren't recommending central command and control. Strong organizational pillars enables more delegation of responsibility. It relies on good communication to ensure that people understand governance policies and guidelines so that you can trust them to make good decisions.

[Bernard Manouvrier]

I think Anne mentioned the main problem in her "SOA is Dead" post: "SOA needs to be part of something bigger. If it isn't, then you need to ask yourself why you've been doing it."

That's perfectly true. In order to succeed with SOA, the story must begin at the business level. Companies need to create innovative models and processes in order to produce at the lowest cost and sell better, and to quickly create new products and services and offer them to the market before their competitors do. To achieve this goal, companies need to transform themselves internally and externally. They must adapt their organization and clearly define the interaction models between their different business units, their IT department and their partners. As part of this transformation, each business unit must take into account the internal and external ecosystems in which it performs and then express its needs as business services required to achieve their goal.

This will require business units to work closely with IT and, consequently, demand an important interaction model to be well defined. SOA is only a part and a mean for this evolution. That's why instead of having the "A" in SOA representing "architecture," I would personally prefer having it represent "approach." And the final target of this evolution will be the "disintegration" of the famous spaghetti architecture that exists today in most of the big companies' IT. SOA (Service Oriented Approach) is just a natural offspring of the more global IT city-planning approach starting at the business level and resulting in the disintegration of the IT spaghetti architecture. Yes, that's "something bigger," and SOA must be part of it in order to be successful.

Bernard Manouvrier
Chief Architect
Axway