As enterprise architects, we’re often confronted with the question: how can we embed an agile way of working in our practice? Or even in a waterfall and agile hybrid? We’re not here to write another article about roles and responsibilities – these are defined by the different methodologies. And we’re not here for a high-level vision, either. We’re here to share our pragmatic thoughts and observations about the Enterprise Architect role within an agile context.
Admittedly, we sometimes feel lost in a desert city full of straight shooters – the squad masters – with one esoteric sheriff, the tribe lead… We have therefore classified our observations into three categories: the Good, the Bad, and the Ugly. We do not pretend to be exhaustive and welcome any observations to enrich the debate.
Adding, adjusting, grooming and prioritising architectural work items in an architecture backlog has been elaborated upon by Eltjo Poort [1] and Gerben Wierda [2] . In essence it’s about considering architectural decisions as deliverables in themselves. We should be able to build a decision plan for these decisions: without this decision, at that time, we’ll start getting into trouble…
Gerben Wierda’s Enterprise Chess style of managing Architecture Backlog and Solution Backlog
Architects must follow and contribute to the increment, while also being able to position this increment in the overall vision. We therefore need to excel in delivering the narrative about the relationship between the current increment and the overall delivery scope.
Incremental value delivery – from Henrik Kniberg’s article [3]
Endless deliveries are difficult to follow. In agile, it’s tempting but dangerous to end up with an unclear definition of done and therefore have everlasting architecture tracks. Architecture governance should contribute to measuring and visualising potential deviations at key points in the delivery process.
Checking for course deviations
Enterprise architecture is a relatively young discipline with tangible variations across organisations. We often confuse the level of granularity, mistaking architectural decisions as design decisions or vice versa. By clearly separating the design authority function from the architectural decision, we enforce the right level of decision to the appropriate audience/board, avoiding useless meetings for a tribe lead and frustration at squad master level. The right decision, at the right place.
Distinguishing between architecture and design
How do we present a complete vision when we want to be iterative? At first glance it seems schizophrenic. It’s not. A vision must be formed, with acceptable levels of risk and assumptions. Clarify iterations and validate or invalidate these assumptions. Experienced architects will limit failed iterations but, by definition, we should be realistic and accept that we will also make mistakes at enterprise architecture level.
Fail fast, iterate and pivot [4]
We need to share terminology, also on roles and responsibilities. Be clear about confusing terms such as solution architect and feature architect, even if it’s not 100% backed by a strong theoretical background. We are not in avionics or core science. IT is one of the youngest and fastest changing industries, so nothing is set in stone. We must remain pragmatic and adapt to new situations.
Roles are defined in context of other roles
EA is not dead – but it needs more focus on business architecture and customer journeys. The enterprise architects of tomorrow must be increasingly able to talk with business. Execution is gaining autonomy. Instead of fighting to preserve any prerogative, we should adapt and stay in control of the big picture more than ever.
Sense-making and storytelling as key qualities
Detailed RFPs, documents of 50 pages or more, or long lists of cryptic principles are a thing of the past. Instead, we have to try to work with one-pagers and references cards that are printable, readable, actionable and pragmatic for a broad audience. When a document is used, understood, shared and endorsed, it’s a win.
Margaret Hamilton, lead software engineer of the Apollo Project, stands next to a huge stack of code written by her and her team, in 1969 [5].
Having a target is important. It’s a starting point. But the focus must be on stable intermediate steps. It’s typically far more difficult to achieve than we initially assumed. The beauty of an architecture in IT is not to build a cathedral, but rather to build a tent and turn it into a cathedral step by step (I can’t remember whose sentence this, but he or she deserves the credit.
Again, it’s impossible. Learn to control and mitigate risks instead.
Value is delivered through interactions between people. The same applies to delivering architecture value. A good collaboration model between enterprise architects and solution architects is essential. This should include face-to-face sessions where architecturally significant observations can be introduced and/or bubble up.
Two forms of the Architect as the navigator: (i) the cartographer mapping/guiding; and (ii) the scout exploring. A good collaborative model between them is essential. [6]
Accept to work with identified risks and assumptions and measure the deviations over the time. Work within the limitations. We have seen enterprise architects become the unique point of reference when it comes to integration, communication, etc. In the beginning, such a role is rewarding but it turns hellish over time. Try to explain the principles, the concepts and the big picture to ALL members. Their autonomy will save your life. A good enterprise architect distributes the information and makes sure everyone understands the rationale.
Attend the different ceremonies and participate. The ivory tower must be destroyed, now more than ever.
Our Business and IT Architects empower you to implement structural change and achieve lasting results with proven methods and tools adapted to your organization.
