Sunday, April 13, 2008

Design before Technology

Design patterns for the most part are technology agnostic. They capture a best of breed approach for solving a problem in a particular context. Technology is an enabler of these design patterns. We use technology to implement the solutions the design of which is based on design patterns.

Design patterns evolve must more slowly than technology, and are rarely made obsolete. New design patterns arise to face new design challenges and to better manage complexity, whereas new technology arises to make the implementation of these designs easier such that they can be done at lower cost.

Technology led architecture is a recipe for failure. In this situation we see architects designing solutions around some new technology being pushed by some vendor. Where we tend to see this most is ESB driven architecture. Businesses are told they must have some expensive piece of middleware to make their SOA reality, but then the implementation fails due to a lack of proper planning and design.

This is why it is so vitally important for SOA practitioners to be well versed in the theory and best practice of SOA rather than simply being trained in the use of one or more middleware products. A middleware product in the hands of an architect without proper understanding of the guiding principals of SOA is very dangerous indeed.

The architecture must come first and be based on the business requirements and business context, guided by design patterns. The technology must then be selected to support the architecture. This way we ensure that the selected technology is appropriate for the solution.

1 comment:

Andreas Öhlund said...

Spot on!

A while ago I helped a customer who believed that buying an ESB automagicailly would solve their synq. reg/reply spagetti without them doing anything. You have to credit the vendors who over and over again manage to sell their "silver bullets" :) I wrote a post about this a while ago: