During the ICSM presentation of Eric Bouwers about criteria for assessing implemented architectures I asked a question that raised a discussion that was proposed by Yuanfang Cai to be taken off-line. Since I already left Edmonton, I’m taking it on-line instead. There is no doubt Eric has made considerable contribution by analysing SIG expert opinions, reports and interviews, my question was more about the relation between architecture evaluation and architecture evolution and his proposal to integrate regular architecture re-evaluation into maintenance activities.
One of the definition of architecture that I remember from the time working in the same department with Hans van Vliet is that it comprises those components, dependencies, properties, configuration elements, etc—in other words, those parts of a system design that do not change with time or are the most reluctant to change with time. I.e., the easier it is to discard or to change something, the less place it deserves in the architecture. If you think the problem is purely terminological, please direct me to a perfect definition, and I will shut up. However, I believe there are some deeper issues here.
Can architecture re-evaluation be used as a system analysis tool that can deliver useful and non-trivial results?
So far I can imagine three scenarios: (1) the software system evolves without changing its architecture; hence, re-evaluation is redundant since it will provide the same results we already obtained; (2) the software system is redesigned in the meantime in such a way that its architecture changes as well; hence, re-evaluation is needed since we can no longer rely on the outdated data; (3) the software system evolves in such a way that the properties of its architecture can shift without noticing; hence, the answer to the question from the previous paragraph is definitely "YES". The first two scenarios are trivial, the third one is not, and I call for examples. So far I can think of only external ones, like when a new technology is introduced and makes parts of the existing system outdated/obsolete/incompatible/… Are there internal ones?
Subscribe to:
Post Comments (Atom)
You can see architecture from two directions, views if you like ;-) One is the goal of architecture, i.e. to establish indeed the difference between artifacts that do change and the ones that don't. The other is the reality of a current system's architecture. In that view, things that should not change may have changed, and thing that were intended to be variable may have remained the same. You might say that architecture evolution is the study of the difference between the two views, and causality, consequences and remedies thereof.
ReplyDeleteAs for your question about examples. The third internal kind of evolution is the most prevalent one as far as I have seen.
First reason for change: features. After the initial release of a system, little new features come creeping in. Without changing the global architecture, which is a hard thing to do, engineers will need to make changes that make the new feature work. Either under time pressure, or without architectural means to "do it right", the engineer will find reasonable ways to implement the new feature. That reasoning is often local to the current new functionality and not to the rest of the system. Or, she will reason to not mess up the rest of the system by changing its architecture, but rather make a local non-architectural change.
The second reason is that many engineers do make architectural changes. I.e. they actually refactor the system to improve flexibility and maintainability. This can change the architecture of the system drastically, nevertheless initial documentation may not be updated. You might put this into your second category, but such architectural changes due to refactoring can be "emerging" instead of intentional.
So, both internal architectural degrading, as well as improvements can increase the distance between the intended architecture and the real architecture of a software system.
with "non-architectural change", I meant a change that is not according to the initial architecture but nevertheless may cross architectural boundaries (skip a layer, use a utility from a different pillar, add a 'call back' method, ...)
ReplyDeleteGood idea to bring the discussing back online! I think Jurgen already explained it quite well, but here is how I see it.
ReplyDeleteThe most important thing to keep in mind is that we are looking at the implemented architecture of a project. In an ideal world, the implemented architecture is equal to the one that is designed. Unfortunately, this is not always the case.
As Jurgen pointed out, software engineers sometimes change properties of the implemented architecture. Add a call that skips a layer, adding a AWK-script to quickly import same data, moving code into a common module, etc. These changes are not always reported back to the people that manage the software project. Maybe because the engineer is unaware of his change (the layer-violation), or because the change is only temporarily (the AWK script).
In both cases, some property of the implemented architecture has been changed and the person that manages the project is unaware of it. I think this describes the third scenario.
That is why I believe that re-evaluating the implemented architecture of a system can provide non-trivial and useful results. It has a documenting value and it makes sure that all stakeholders are aware of the changes to the implemented architecture.
However, during the ICSM more people notified me of the fact that the term 'architecture' might not be appropriate for what we try to describe. A more fitting term might be something like 'detailed design', but I will have to give this some more thought.