WICSA 2005:OnTheGreatDebate
From WICSA Conference Wiki
Contents |
Which matters more: the architecture as designed,
or the one the running system happens to have?
What is Architecture? (Noooo, not yet again :-)
First of all, I'm not sure whether you can speak of the architecture of an implementation. For me, an architecture is two things:
- an abstraction of an implementation, but also more specifically:
- a specification of this abstraction.
I'm sure everyone will agree with the first item. We create an abstraction of a system in order to reason about it without having to know the 12 million lines of code (quoting I think Grady Booch) in detail. The abstraction is in terms of layers, components, scenarios, tasks, et cetera. Usually the model is so complicated that we need multiple views to understand it.
But, you can make more than one abstraction of a system. For instance, if a system is layered and components only use components in the layer below, than opaque layering would be a valid abstraction, but transparent layering would also (formally) be a valid abstraction, and a fully connected set of layers also. Retrieving the abstraction from of the implementation is an inductive process, and as everyone knows, this is never unambiguously defined (althoug heuristics may help a lot to come up with 'minimal' abstractions (opaque layering in the example above)).
Another example, if a product works at 20 degrees Centigrade, what is it's 'architecture'? Is it supposed to work from 0-40 degrees? What if it happens to work at 50 degrees (go to Death Valley to check this :-)? Is it then designed to work at 50 degrees, or does it just happen to work at 50 degrees?
You may want to have a look at Johan Muskens' paper on checking consistency between views, where he distinguishes between may and must relationships. His formulas typically have less than rather than equals.
Anyway, you may find this discussion academic, so in the rest of this note I will assume that the architecture of an implementation actually exists :-). You may want to read the second chapter of my thesis if you want more information on my views here...
Intended versus Actual
A lot of people have been working on the relation between the intended architecture as compared to the actual architecture. This may have started as reverse architecting or architecture recovery, but in my view the consistency between intended and actual architecture forms an essential part of architecting. I used to call the combination of forward and reverse architecting mature architecting. Round-trip architecting may be a more convenient or modern term here.
Among the people who have been working on this are Bob Schwanke (1989), Myself (1993) and some of my collegues (read Rene Krikhaar's PhD thesis), and Ric Holt (1994). I'm sure there are many others that I don't know of, but I 'left' this field some time ago :-)
What happens if there is a discrepancy?
- the implementation may be (really) wrong. Then, the implementation must be adapted to confom to the architecture.
- the implementation may be justifiably wrong, because of details not relevant to the architecture. Don't fix it if it ain't broken :-)
- the implementation may be right, and the (intended) architecture may be wrong. Then fix the (intended) architecture, since what good is an architecture if the implementation is different?
Remember that the main use of an architecture is to reason about a system without having to know the 12,000,000 lines of code in detail (this is getting a proverbial statement :-). Therefore, consistency between (intended) architecture and implementation definitely is a helpful feature :-)
And What If They Are Different?
Well, an intended architecture that differs from the actual is not always a bad thing to have. The architecture may show the initial intentions of the architects, and thus serve as a nice introduction into the architecture. Remember Knuth's book on TeX, with the single and double bend markers in the page margins? He intentionely explained items in a not-fully correct way, adding the full (and sometimes hairy) details in smaller print that you should not read on your first pass of the book.
Concluding Remarks
So my view is actually quite simple:
- if they are consistent, there is no problem
- if they are inconsististent, then you can still use the intended architecture, but you must be very aware of its validity.
It goes without saying that I think that we should have tools that force consistency upon us. Bob Schwanke mentioned a project where he redesigned a system into DLLs, one per subsystem, restructured directories to reflect the subsystem structure, and defined public and private header files to make sure (in the build system) that developers followed the architectural rules. I am very much in favour of this! Rene Krikhaar mentioned a similar approach in Philips. And of course, this should go beyond modular views... :-)
- Rob.van.ommering 10:56, 10 November 2005 (EST)
