Dienstag, 12. Juni 2007
One, to rule them all

Align the architecture and the configurationmangement

During the years I have seen a decent amount of projects. Some had a really great architecture and some not. However all projects which went successfully in production had at least an acceptable architecture at the point of time when they went into production.
And the same is true for easy maintainable systems from my experience. All systems, which are easily maintainable, have managed to preserve good or acceptable architecture and a few even managed it to be refactored into a good architecture. All systems, which changed from beautiful crafted systems into maintenance nightmare systems, had a fast eroding architecture.
Some of these systems will be reengineered or rebuild over the time, and for the rest a reengineering debate starts on a regular basis.
I recognised a common property of the good systems, which all the maintenance nightmare systems where missing:

The system architecture is reflected in the configuration management structure and its compliance is checked by the system build.

In other words:

architecture compliance is constantly verified and tested during the configuration management and during the build.
(I blogged some weeks ago, how you could use AspectJ to simplify the checking of some coding guidelines automatically. in eliminating awfull API calls)

I recognized also that the architecture of a system tend to morph into the architecture of the configuration management structure.
So these simple observations have some strong consequences:

  • If you change the architecture of your application, e.g. from a historical grown monolith, you should change your configuration management and build process, too. Otherwise you risk a fast eroding architecture or much work to fight against this entropy.
  • If you want to change the architecture you can enforce this by setting up a strict build management.
I also use my observation as a reliable form of architectural smoke detection. Whenever a system has obscure configuration management processes, then there is something wrong with the architecture or the architecture changed recently and the configuration and build management did not catch up.

When somebody uses something like component based architecture, maybe even based on OSGI and maven, he should strongly consider arranging his configuration management layout in a similar way.

When a project is regularly branching like mad, the project should seriously consider rearchitecting or refactoring its application or its applications.
Normally these applications have lots of dependency cycles and other unwanted dependencies. Form my point of view you need not more than these regular development streams.
  • The development stream
  • Maximum, One stream for each test stage (integration, user test, pre production)
    The production stream.
That’s all. Fullstop.

The argument, you need more regular development streams for concurrent development of features is IMHO just rubbish. If you need regular concurrent development of different features by different teams, then its up to the architecture to support this. And this is nowadays easily possible. You can choose from a bunch of different approaches, like the use basic patterns, (like observer, strategy, factories, etc.), component extension approaches (like the eclipse/OSGI extension point mechanism), IoC (Inversion of Control) and Dependency Injection frameworks like Spring, AOP, etc. James Noble and David Pearce demonstrated at AOSD 2006 and at Europlop 2006 that even relationships from one class to other classes can be an additional feature, which can be easily added with the external help from some aspects. You don´t believe me? Show me a concrete counterexample and let’s discuss it!

... link (0 Kommentare)   ... comment