In “Quo vadis SOA“, Matthias Steiner has written a very readable blog post about where SOA is today, in SAP and beyond, casting a critical but balanced eye on what the service orientation approach has delivered. In the section “Did SOA deliver on its promise?”, the words (some quoted) that stand out are “critics”, “disillusionment”, “dead” and “reality”. I think to some extent these words are justified, but not necessarily for the obvious reasons. Service Orientation as an architectural approach is certainly valid and one cannot argue that the theory is unsound, or that it has no place in enterprise computing.

The biggest problem, and the biggest enemy of SOA, appears to have sprung from within the SOA bubble itself. Hordes of cargo-cult ridden ERP architects and consultants have swept into organisations, egged on by respected analyst firms, and declared “SOA is the answer! Now, what is the question?” Before detailed analysis of the challenge at hand, they appear, armed to the teeth with SOA white papers and acronyms, and plonk down their SOA scaffolding superstructure, proudly stating “Whatever solution we end up with must fit in that framework”. And so implementations get off on the wrong foot, noses are put out of joint, integrations are brittle by design, and costs shoot way past the budget, like an HTTP request tunneling to a solitary, unidentifable endpoint forever out of reach.

What’s the answer? In my humble opinion, it’s the **re-**coupling of archtecture with development. In a comment to Matthias’s post, Matt Harding mentions the concept of a “Development Architect”. This resonates with me tremendously; I set my title on LinkedIn to include “Coding Architect”, which tries to convey a similar concept. Get the people who are thinking hard about architecture to think hard about development, and vice versa, and the correct and appropriate strategies will emerge.