The answer is obvious

My “old” research supervisor once told me (slightly paraphrased): “Once you know the right question, then the answer is obvious”. Of course, the real trick is to find the questions that you can answer with very limited resources – without limiting yourself to what you already know; or think you know.

And therein lies the all to common trap – focus only what you know and you’ll ask the wrong questions leading to poor conclusions and rework. The goal of questioning must also be clear.

This is also why issue based consulting methodologies like “The Pyramid Principle” by Barbara Minto become problematic. Under the usual cost and schedule pressures, progress and deliverables are easier to reach through clarifying questions – they get a tick for successful engagement; but miss the bigger, more important questions. They fail their clients by not acting as a change facilitator. As one of my clients once said: “Request a consultant to tell you the time, they’ll grab your wrist and look at your watch”.

References:
[1] Tom Pohlmann & Neethi Mary Thomas, “Relearning the Art of Asking Questions”, https://hbr.org/2015/03/relearning-the-art-of-asking-questions
[2] Barbara Minto, “The Minto Pyramid Principle Concept”, http://www.barbaraminto.com/concept.html

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).As-is and 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).

Reality

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.