In a recent article, Martin Fowler is trying to explore the applicability of evolutionary design - a practice commonly used in Extreme Programming (XP) - to SOA implementations. He starts by discussing two common design paradigms, planned and evolutionary:
Planned design works out the design of software in one phase and builds (programs) it afterwards. In this case changing the design is hard once you've begun construction. Evolutionary design assumes regular change of the design even once you've done significant programming. I concluded that the practices of XP provided a disciplined approach to evolutionary design, thus making it much more practical than people had realized. This change did not remove software design (it is not dead) but did significantly change how we think about design.
The main argument for supporting planned design in the case of SOA is that it is creating an architectural blueprint of the enterprise IT systems in the form of reusable interconnected services exposing their published interfaces to the enterprise. According to Martin:
Published interfaces are hard to change, therefore you need planned design to get them right so you don't have to change them. Planned design is also a reaction to the chaotic system interconnections that people see in most organizations. This chaos is the result of poor design, so the feeling is that better planned design will prevent this happening in future.
But that prompts the question about true stability of a SOA implementation:
So as I look at SOA, or any other design context, the fundamental question I ask "is change predictable?" Only if change is predictable is a planned design approach valid. My sense is that if predictability is hard within the context of a single application, it's doubly hard across an enterprise. If we use planned design in a unpredictable context we find that however good the plans are, they will be undermined by the unpredictable changes, leading to the same mess we are currently in. Usually, however, the mess is worse because a there is significant sunk cost in a planned design, this can easily reduce the business value that an SOA effort is intended to produce, particularly if time-to-market is important.
As a result, one of the fundamental aspects of a SOA implementation should be the ability to evolve services contracts as the overall requirements to implementation change. Martin completes this mini article by proposing incremental SOA implementation producing business value along every implementation step:
Can evolutionary design scale to SOA sizes? In my view, we have an existence proof at a much larger scale than even a big SOA effort - the web itself. The web is built on very loose coupling and lots of unpredictable changes. It is, in many ways, a mess - but it's a mess that works, delivering real value t o lots of people every day.
There is nothing wrong with the usage of evolutionary design for SOA implementation. The issue here is to be able to strike a proper balance between planned and evolutionary portions. Pure evolutionary bottom-up approaches typically lead to SOA-based integrations and often fails to deliver true value for a long term. A planned approach with the eye for evolution can lead to a much greater success.
