Architecture enabling business

I believe every developer and architect should keep track of their personal "lessons learned" for software/process/organization design and, broadly, how they practice as a software professional. Further, I expect that I’m like a lot of other architects in doing so somewhat irregularly, and therefore almost certainly retreading and relearning more than necessary. So what better place to capture my lessons learned than here?

I actually made a first pass at this, somewhat sideways, as part of a talk called "An Architecture Journey" I gave at the SATURN conference at the Software Engineering Institute in 2007. The abstract and slides are posted. The gist of the talk was to share lessons I had learned during my various jobs as a developer and architect, along with some observations on how my definition and practice of software architecture evolved over that time. I gave a slightly perturbed version of this talk at Google Canada in Waterloo, where my good friend Steve Woods is the site director. Below are some of the lessons I came up with, paraphrased, and in chronological order.  Sure, these don’t really stand on their own (and some may be downright cryptic), so the more interesting ones will likely become posts of their own.

Nortel

• Big systems are tough to get right; thinking about “architecture stuff” up front is required for success (like avoiding measuring time-to-dialtone in minutes after a major system reengineering effort).

SEI

• Architecture is the bearer of quality, but reasoning about architecture is reasoning about potential.

Quack/AOL

• Enabling autonomy of organizations and systems is the way you scale.

Microsoft

• You don’t need to choose between reasoning top-down and bottom-up: do spiral.
• You’ll rarely (never?) know in advance if a decision is right, but make sure you know afterward.
• Technology doesn’t matter (much); it’s about the people, the process, and the consistency of practice.

Fidelity

• Figure out who defines goodness of your work and make them happy.
• Don’t let “pragmatism” become a disguise for shortsightedness.
• Communication and understanding trump every technical problem.
• Plan for technology retirement, not just adoption.

VistaPrint

• Don’t boil the frog with standards. (As the most cryptic, there will definitely be a post coming on this one.)
• Be dumb. Ask smart questions.
• Don’t undervalue slack.
• Don’t forget your lesson about autonomy: define boundaries and common language when crossing them.

I’m currently particularly excited about the autonomy and slack lessons (not coincidentally the last two on the list), so expect posts on them before too long.