Keeping it simple…?

To-be or not to-be; as-is the question

I did a quick survey of the software architecture literature on my book shelf (physical and virtual) this rainy Easter weekend for guidance on how to model a “transition” or “interim” architecture. As there was almost nothing on the topic, the next stop was Google – only to re-affirm my growing suspicion that book authors perceived “software architecture” as something that could only exist before (as-is) and after a project (to-be).

My second suspicion was that they either ignored or didn’t know about the idea of multiple releases (seemed ridiculous). If they did know then did they view those releases as either not having an architecture (seemed even more ridiculous) or just as multiple iterations of the above diagram (more reasonable).

However, I think the second diagram looks more like reality. We start with a current (as-is) architecture. We then seek to change it through a number of project releases only to find by release 2 that we need a release 2.1 which splits from release 3. Release 4 is subsequently cancelled, but the political environment demands release 5. Meanwhile the old “as-is” architecture still lingers as a ghost. End result, we never got to the defined “to-be” (utopian) architecture, because the delivered “to-be” architecture is the sum of release 2.1, 5 and the old “as-is”.

This then begs the question: did the “as-is” really exist (as documented), because  our “to-be” is after all the next project’s “as-is”? The most obvious answer is that our beloved architecture never actually is in a known “as-is state” and only exists in a permanent “interim state” haphazardly moving towards an ever-changing target architecture.

And sadly based on my limited literature review, our modelling tools aren’t really designed to support this?

Note: I did find one reference provided by Avolution. They have defined five stages of architecture: 1) Historical, 2) Current, 3) Soon-to-be, 4) Transition or maybe, and 5) target (to-be). But they want you to buy their tool before saying how you’d model the relationships between each of five.