The Making of an Architect

Hold Up. Do We Need Architects?

A system has an architecture. The shape its in, and its ability to evolve and sustain evolution? There's the rub. So, do we need architects? Of that title? With that focus of systems design experience and responsibility? It depends? We discussed this question in Software Architects: Do We Need 'em? The comments add useful perspective and nuance to the debate, like this from Mark Mullins: "A loss of focus on the system, as a system" comes at a price -- "the price of that is always a slide into the abyss, the only variables being the resources expended to slow the slide off the edge."

Can Architects Be Made?

Only if they're willing. Well, that's Dana Bredemeyer's joking response when asked by managers or even aspiring architects. Okay, so if not "made," then how at least do we develop ourselves in this direction – in the direction of system design leadership, and system design excellence?

We don’t have 7+ year degree programs, like building architects, or specialists in other areas such as medicine. However, we build up a lot of this expertise working on complex systems. For years! (We come by our SCARS the hard way.) Our way is arguably better, given that our systems are unique to their purpose and context (that's differentiation for you), and we're continually pushing the boundaries into "the adjacent possible." Still a guide, some classes and focused attention on system design skills, helps contextualize and draw out what we've learned, as well as add insights, perspective, heuristics and techniques.

What Would Such A Class Look Like?

So glad you asked! This is the overview slideset for our Software Architecture Workshop. The first 39 of those slides are annotated in Software Architecture and Related Concerns -- that discussion ranges over the core concerns addressed by software architecture.

Our approach emphasizes visual modeling. We can't see the structure of complex systems -- though we might try to, in our mind's eye. But our mental models are idiosyncratic and prone to blind-spots. So we need to draw out the structures and relationships, and visualize how the system, and its key mechanisms, works, to analyze responses under dynamic load, and identify and design the flows and transformations, and understand and feed back in the implications for the system structure(s).

We also emphasize designing across boundaries. Not just the boundaries within the system, but an active interplay between design of what the system is and is becoming (its capabilities and properties) and how it is built (its architecture and more detailed internal design, where this latter is mostly done in the medium of code). With systems under evolution, much is in flux. The system, and its containing systems are co-learning (symmathesy), co-adapting. By actively designing across, we allow a more rich co-learning between what the system is and how it is used and how it changes its context (the social and sociotechnical systems using and interacting with our system under designed evolution) and how the system is built and evolved.

Now, some systems are more stable, in more mature and understood industries, or just have greater constraints on getting it "right" the first time. You don't want to be learning all the lessons about what it takes to land a Mars Rover, and adjusting its system code, while landing it. So one of the key exhortations is to consider, early and then often, "what at this moment is the most important thing for us to be thinking about?" and how best do we do that thinking, rethinking, and assessing.

Further, architectural decisions inherently entail trade-offs. They address cross-cutting concerns and significant strategic or structural challenges. We need to understand the context, with its preference profiles, constraints and shaping forces. We seek best fit to purpose and to context, even as contexts shift.

Our workshop-as-design-studio approach, creates an immersive system design experience. It's both design lab and leader lab – while working on draft architecture views (from context/strategy, to API design), we're working on our leadership and design skills. We experience how the multiplex of challenges facing architects play out, discovering the demands, forces and constraints impinging on the design, and shaping responses to them. This provides the situated learning context for heuristics, techniques, and stories that nuance our perspective on the challenges and approaches of architecture and technical leadership.

That's a Nice Class You Have There, But What Else?

Whoo! That's a lot to ask. Too many books to list in this moment. But here are some:

• Thinking in Systems: A Primer, by Donella H. Meadows
• Systems Architecting: Creating & Building Complex Systems, by Eberhardt Rechtin
• Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives, by Nick Rozanski and Eóin Woods
• Software Architecture for Developers, by Simon Brown
• Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis, by Adam Tornhill

Now, I specifically said design leadership, and to prompt some of the implications to view, I recommend

• On Being A Senior Engineer, by John Allspaw

Update: Phillip Johnston wrote up observations and insights from a recent workshop: What I Learned at Bredemeyer Consulting's Software Architecture Workshop