|
Last year I posted an item at the Xebia blog about the three C’s of architecture. Connection (with business goals), Cohesion (of solutions and implementations) and Changeability (of the system and value delivered to the customer) have proven to be very useful in defining the primate of architecture and of the role of an agile architect. After working over a year with these ideas this is a good moment to evaluate and sharpen these ideas What I experienced is that changeability stands out from the other two aspects, and is the most pivotal and fundamental concept of the three. Changeability is both a static and a dynamic quality.
Architecture in an agile world, it is a much debated item. A couple months ago I wrote a article about it with former coworker Nikolas Odding. That we need architecture is clear, but the role of architects changes when doing agile. The objective of architecture is to add value to IT systems beyond: it works (so don’t touch it). So what are we looking for?
Connection
IT systems have a purpose and function that reach beyond the systems functionality. It is about what an organization wants to achieve and how IT systems fit in. There are, for instance, numerous enterprise content management systems, but how an organization wants to interact with its customers is of great influence on the choice for a platform. Or maybe there is a need to adapt to customer demand and open platforms are more suited than closed variants. Architectural choices can only add to connection if they are based on a deep understanding of business goals.
Cohesion
Great systems are built around just a set of good ideas that are well chosen and consistently applied. I remember an internal system developed at the consultancy firm I worked for. It had been created by just about any developer in the organization that was available in between assignments. And it showed: everyone had used his own style and favorite framework. It was a disaster to maintain and eventually had to thrown out because nobody really understood how it worked any longer. If by contrast we build systems consistently on a set of well chosen solutions to recurring problems, we created consistency in a system. This creates simple and cohesive designs that can easily be understood. And: understanding a system is a first prerequisite for successful change.
Courtesy of Pansonaut: http://www.flickr.com/photos/pansonaut/
Changeability
Change happens, whether we like it or not. Sometime we deliberately choose it, often it is inevitable. Changeability is a quality of systems that determines how much effort is needed to adept a system to changing requirements and circumstances. Changeability is a multifaceted attribute of systems. What makes changeability interesting is its interaction with the other two architectural pillars: If we cannot easily change a system, we will soon lose connection with business goals. High cohesiveness and consistency are enable changeable systems. Yet, low quality obscure good solutions, it evokes haphazard change thereby reducing both cohesion and changeability.
Changeability has a much wider impact than cohesion and connection. It goes beyond systems quality and extends into organizational capabilities, process dynamics and even long term business evolution. Changeability of IT systems is at the heart of systems quality. With the growing interlocking of business and IT capabilities, no one can ignore changeability. That is why it needs proper attention when designing systems and developing business requirements.
Roughly a year after posting my original blog, the three C’s of architecture have proven valuable and usable. Especially changeability has been getting more meaning and dept. It is a useful perspective for evaluation and constructing IT systems.
Only registered users can write comments.
Please login or register. |
