Now this may or may not be rocket science, but introducing a systematic architecture approach has turned out rather tricky in the past.

What I’m doing now is working with the Architecture Challenges paper by Charlie Alfred.

In an environment where nobody has the time to “sharpen the saw”, introducing this as a mindset was tricky – and then again, eventually it worked out.

I’d like to thank the colleague in question to keep an open mind and, “despite” 20 years of industry experience, still experiment with a newbie program lead on such questions.What did work was first of all to frame the discussion as a challenge, not the type of challenge every boss talks about (and which is synonymous to “problem”) but to appeal to the sports spirit of the architect. In a first discussion, I essentially introduced the ideas as a way for me (the newbie program lead) to understand how the architecture “ticks” and why it is the way it is. No slides, no presentations, just chit-chat. The essential “method” I sketched out fit on the proverbial back of an envelope:

• Architecture is driven by non-functional requirements (yes I know… quality attribute scenarios… one innovation at a time…)
• Identify non-functional requirements
• See which ones of these conflict
• Prioritize and resolve the conflicts

We concluded by “let’s see what the most important non-functionals are, set up a follow-up meeting and see where this took us. (In the follow-up, I sent the reference to the paper).

In a next discussion, I got presented a nice mind-map with headlines of the various “non-functional requirements” (and on top of it, a couple of “universal constants” – they turned out to be essentially the External Forces). The approach had clearly tickled the professional enthusiasm. We discussed the headlines and went into a few examples of conflicts or tensions, and concluded that, for our next discussion, we need to have a matrix for these.

In the third discussion, we reviewed the matrix. We even had a first set of descriptions matching the headlines. So we discussed the tensions and quickly concluded that the descriptions needed more detail: different headlines mean different things to different people. Here, I introduced the quality attribute scenario “template”: Source, Stimulus, Artifact, Response and Response Measure. “Let’s try that”. After drafting the QAS for the first two or three challenges and discussing on that basis, the method had proven itself.

After three hours of discussions and a little bit of homework in between, we had substantial architecture discussions between an architect with 20+years experience under his belt, and me, the newbie program lead. And meanwhile, we are working on efficient ways to detail out only what is really needed. Read on!