wagnerblog.com

I liked his blog entry so much, I just copied the whole thing…

“….2004 Nov. 15 10:01 PM
Service-Oriented Architectures

I’ve back from travel again, this time from trips to New York City and Chicago where I’ve been working with a number of clients on their emerging enterprise architectures. The common theme I’ve encountered is that large enterprises are beginning to see their way out of the global economic slump and so are turning their attention to what they can do to extract value from their legacy systems by unifying the artifacts and activities that reside across existing silos and by unifying their customer experience.

Speaking of legacy systems, one gentleman introduced me to the new phrase heritage software as a euphemism for old, tired software. A nobel concept, but a rose by any other name is still a rose. It reminds me of phrases such as pre-owned vehicle and arbitrary termination of life.

Service-oriented architectures (SOA) are on the mind of all such enterprises - and rightly so - for services do offer a mechanism for transcending the multiplatform, multilingual, multisemantic underpinnings of most enterprises, which typically have grown organically and opportunistically over the years. That being said, I need to voice the dark side of SOA, the same things I’ve told these and other customers. First, services are just a mechanism, a specific mechanism for allowing communication across standard Web protocols. As such, the best service-oriented architectures seem to come from good component-oriented architectures, meaning that the mere imposition of services does not an architecture make. Second, services are a useful but insufficient mechanism for interconnection among systems of systems. It’s a gross simplification, but services are most applicable to large grained/low frequency interactions, and one typically needs other mechanisms for fine-grained/high frequency flows. It’s also the case that many legacy - sorry, heritage - systems are not already Web-centric, and thus using a services mechanism which assumes Web-centric transport introduces an impedence mismatch. Third, simply defining services is only one part of establishing a unified architecture: one also needs shared semantics of messages and behavioral patterns for common synchronous and asynchronous messaging across services.

In short, SOA is just one part of establishing an enterprise architecture, and those organizations who think that imposing an SOA alone will bring order out of chaos are sadly misguided. As I’ve said many times before and will say again, solid software engineering practices never go out of style (crisp abstractions, clear separation of concerns, balanced distribution of responsibilties) and while SOA supports such practices, SOA is not a sufficient architectural practice.

One more thing before I go. If I were a betting man, I imagine my ability to predict the future success of many of these organizations would be quite high (and I don’t mean their technical success, I mean the very life of the company itself). There are some organizations I encounter in which there’s a tight connection between the CEO and CTO/CIO (and development teams) - these are the companies I expect will flourish, for at the highest levels of the company they understand the strategic weapon that lives in software, and the importance in building a development organization that’s able to exceute predictably and with agility. Sadly, there are too many organizations where the highest level of the company simply goes not grok the value of software - and these are the organization that will be overtaken. …..”