Architecting while Agile? Yes, you can.

If you’d been in one of my trainings a while ago, you’d have heard someone ask me this question. “You Agile evangelists are always talking about these new roles: Product Owner. Development Team. Release Train Engineer. This, that and the other. Fine and good — but where does my work fit in? I’m an architect. And I can see my role is changing, but I’m not sure how exactly. Why is it changing, and more importantly what can I change to stay onboard?”

Memory lane

The question triggered a flood of competing thoughts. Mainly it brought me to go back several years in memory, to review some talks I listened to, books that I’ve read, conferences I attended. Because this person had a very interesting point. And I realized: we don’t talk that much about architecture in the Agile discourse, do we?

Architecture overlooked

With the relentless focus on customer-valuable increments that Agile preaches, most of the time we are discussing new releasable functionalities, their UX, their built-in quality controls and other end-game variables. What about the architecture to support all of this though? What about the roles that lay the groundwork that enables customer value to flow through the systems?

I came back from the short mental detour and calmly wrote the gentleman’s remark down on a sticky post: “I need to park your question for now. By the end of our two-day of training, if I haven’t answered it yet, it will be first on the list.”

Structure vs agency

The core of his dilemma is this.

Ideally, Agile Development Teams — while doing their autonomous work in splendid isolation from everyone else, each one developing its own elegant piece of the product range — are supposed to have the mandate to decide how and what to improve on the architecture. As features develop by order of highest demand, so each team should grow the architecture needed to support them. This is often paraphrased under the concept of ‘emergent design’, and it follows from Agile principle number 11.

Complexity brings risk

That is fine for the low complexity of a start-up, though it presents the architect with a challenge to let go of the desire to exert too much control.

In a scaled environment however, with many tens of teams developing products at the same time, whose products are getting more and more complex, with several layers of communication within and externally, extracting data from many different sources… emergent design is a recipe for instability at the structural level. It isn’t enough to just ‘KISS’, because “For every complex problem there is an answer that is clear, simple and wrong,” as Henry Mencken once supposedly said.

So how do we define architecture in a complex context? To simplify isn’t even always a possibility, the same way as down-scaling isn’t always the right thing to do. Instead, we have to work with complexity and try to organize as much as possible. One possible answer for that is the Intentional Architecture as designed and executed by the architects at the System, Solution and Enterprise levels.

An intentional frame for emergent details

Whether you’re a System, a Solution or an Enterprise Architect in a Lean-Agile enterprise, you are in charge of defining the strategy and vision to improve the architecture incrementally, leaving enough room for a coordinated emergent design effort brought on by the Development teams. You provide the powerful and coordinated base for Agile teams to keep focusing on delivering value to end customers. It’s up to you to build the right amount of architecture that will enable this value to be implemented and potentially delivered.

Interpreting the roles of System, Solution and Enterprise Architect in this way makes them even more interesting and full of challenge! They have a responsibility to help teams coordinate, define and share information at the appropriate levels; to understand the underlying purpose and also to be influential enough to direct the fitting amount of funding to the technical aspects and evolutions, to ensure it will get done.

The key is in the balancing act

Balancing sensibly between intentional architecture and emergent design, supported by techniques such as Model-Based Systems Engineering and Set-Based design, will give such roles even more purpose.

By the end of the second day of the training course, I had delivered this answer in bits and pieces here and there. I hadn’t condensed it all into the observation above yet, but I looked at the ‘parking lot’ for questions on hold — and my fellow architect had apparently taken down his note.

I asked if he had found a fitting answer in the training, to which he said: “Yes, definitely. I can now see myself, my role and what I’m going to be busy with during the years to come.” What a relief for me — but even more for him, I’m sure! He has rediscovered a major sense of purpose and has an amazing mission for the future!