light My Insights: this entry explores several insights and ideas sparked by a very interesting article by Gregor Hohpe on typical forms (“topologies”) to approach architecture in teams within an organization (i.e.: “team scope architecture”). The article triggered several interesting conversations, which showcase that we still don’t have a good common shared language to talk about this topic (even though it is unquestionably important). Nevertheless, I think this article (and efforts like this) are key to having relevant conversations that can shape our understanding and language on this topic. In fact, while reading the article and participating in the conversations I started seeing a lot of parallels between this discussion and the ones we see in the book Team Topologies: a language to discuss teams’ design and evolution. These efforts enable the shaping of a language to discuss how to approach architecture in an organization (maybe we can call it “Architecture Teams Topologies”, “Architecture Discipline Topologies” or simply “Architecture Topologies”). In this entry I also develop further on a topic that is not really part of the scope of the article but is rather related, namely: when we talk about approaches to architecture in a team’s context it is rather essential to also consider the scopes surrounding them. Why? Because every team and their systems are part of a surrounding system that will inevitably influence each other, so are the architecture approaches we take. I reflect a bit on that in the last section of the text but will detail this further in a separate article.

Update 2021-07-03: Architecture Topologies Repo - given all the enthusiasm around the “Architecture Topologies” idea and opportunities, I have created a GitHub repo where we will be able to collect and consolidate ideas and topologies. It is still being setup, but hopefully soon ready for contributions.

Analysis & Summary

The insights and notes in this entry are driven by an article from Gregor Hohpe (a reference on architecture strategy, with many writings and books on this topic). In this article Gregor touches on an incredibly important topic: the topologies (models/forms) that we can adopt to approach architecture in the teams of our organizations. This is a rather relevant topic since whether one likes it or not every system has an architecture. It may be explicitly or implicitly addressed, however saying we have no time for it (or doing it “is not agile”, as many falsely claim!) is a trap and recipe for “messy situations”.

This is a topic that many organizations mishandle or take a static/extreme approach, namely: in one extreme have Ivory Tower Architects, who command-and-control all “important decisions” in and around teams (“Benevolent Dictator” in Gregor’s model); or the other extreme, no architects (“because we are agile”) and as such we don’t care for the architecture discipline in our teams (“implicit architecture” in Gregor’s model). However, and fortunately these are not the only options, there are other approaches we can take. Furthemore, and very importantly, the way we approach architecture in a team is also something we will be evolving as the team and surrounding context changes. To address this we need to have an “Architecture Topologies” book (inspired by the ideas and goals of the book Team Topologies and how it provides a clear language to describe the types of teams and their interactions and evolution). This “Architecture Topologies” book should describe the forms/types of approaches we take to architecture in our organizations, and furthermore the types of interactions those have and promote, and very importantly patterns of evolution (i.e.: how they evolve in time). To me we really need to write and talk about these aspects more openly and in a language that promotes its understanding and adoption (as Team Topologies do for teams). (From my side I will for sure do some follow-up writings on this topic).

In the following I share some notes and insights on the model shared by Gregor; the topologies to approach architecture; the evolution patterns; and then some insights and notes on scopes of architecture, a topic that was not emphasized in this article but to me is key to shape some interesting topologies that enable to scale architecture in an organization.

The Model

The model that Gregor shares has a particular emphasis on “team scope architecture”, i.e.: how is architecture approached in the systems that a team owns. The model presented has four basic topologies. There may be variations and combinations, but I think these four topologies provide a great base. You can check those forms in the figure below.

Architecture Topologies


(Image Credits: Grego Hohpe. Note: these were inspired by materials from Michael Ploed).)

#1: The Benevolent Dictator”: Architect “tells the team what to do” (unidirectional interaction with the team). This is a rather classical architect definition/archetype (I would even say one of the most common associations I hear from people when talking about architects). As Gregor says “this model should be used with caution” and most likely only meaningful for short periods of time on teams and organizations with low maturity in doing architecture. Even if it is really needed, I would say to keep this topology for the minimal amount of time possible. Then set elements in place to move to approach #2 (and when/if possible to #3). When this topology is used with another purpose (e.g.: hold control of the important decision), this will lead to some outcomes that most organizations should (most likely) not be striving for if they want to be high-performing organizations, namely: teams will never take true ownership of their scope of work and they will be “slow” (i.e.: wait for the Architect to tell them what to do).

#2: Primus inter pares (Architect - as function - in the team): Architects become another team member - peer - in the team. This model fixes the unidirectional interaction mode that exists in model #1. This enables architecture activities to be more explicit in the team. This means that teams will have more ability to react and address “important decisions” they face on their day to day activities, which should result in higher agility and adaptability (or as Michael Nygard says “higher maneuverability”) to react to their environment. Although this model makes sure that architecture is explicitly addressed in the team, it still defines that only a person within the team is focusing on architecture (there will be grey areas here - as most times people are involved in architecture, but this model defines an architect function in the team, which creates certain dynamics, such as having a single gatekeeper of architecture decision making in the team). As such, we may also not want to stay in this mode “forever”.

#3: Architecture without Architects (Architect role by one of multiple/all team members): no one has the function of architect and multiple people (or even everyone in the team) plays the role of architect. This model mitigates the “centralization bottlenecks” that model #2 may have. This is a powerful place to be, as the team can scale how they approach architecture. I have talked before about this and called it “Everyone Architects”, and although this is a difficult model to implement, the pure effort of striving for it (and making sure that everyone cares about the “important decisions”) enables to create strong teams that end up having shared ownership of architecture.

#4 “Implicit Architecture” (no one has the Architect function nor plays the role of architect): this is a dangerous terrain as no one is looking at architecture (even though there is evidently one). This (and models that mix model #1) is a rather common model, especially on teams and organizations that miss-interpret the principles of Agile.

Evolution Patterns

The other part that I really like about this article is the fact that Gregor goes into “evolution patterns”. Acknowledging this is crucial since our approach to architecture depends on so many factors (team maturity, organization culture, surrounding systems, etc.), which are changing continuously. This is crucial to also make sure our approach to architecture evolves to better support the new conditions in the team and its surroundings (i.e.: our approach to architecture is not at odds with other dynamics that are changing in the organization).

Gregor shares two common patterns (but there may be others):

  • Shift to Right: this happens when we start with an Architect (e.g.: Chief Architect) outside team(s), if for example architecture has been neglected for long time; but then we take steps to integrate Architect (function) in the team; and once the team matures and multiple people can play the role of architect in the team. In this pattern Gregor proposes to stop at model #3, i.e.: do not go so far as to not explicitly approach architecture in the team.
  • Bounce Back: this happens when the “Shift to Right” pattern is not successful, i.e.: We try to have an Architect in the team, or even further have multiple people in the team playing the role of architect, but it is not working well. On those moments, we may “revert” to having an external experienced architect explicitly addressing architecture for/with the team. This may again be a temporary activity, to address the points that did not work on previous iteration. It may sound like a step backwards, but in a complex system you don’t know how the system is going to react, so you must act to learn (as Cynefin framework promotes).

There are other models of evolution, and this becomes even more explicit if we consider the scopes around the team. It is not only important to observe those patterns of evolution, as it also is to “connect scopes” in the systems that the team is part of - which is key for architecture. In the next section I provide some input on this particular topic.

Scopes of Architecture

This article provides a great insight as to the forms we can approach “team scope architecture”. However, to me it is key to look at the scopes around the team scope to comprehensively address and connect the team scope to the surrounding scopes (and systems). In fact this is extensively developed by Gregor in other articles on his “Architects Elevator” metaphor - i.e.: “connecting the penthouse with the engine room”. This is a topic that I also cover extensively in another TLA_insights entry from Ruth Malan and Dana Bredemeyer on “Minimalistic Architecture”. In the figure you can see one of the key visualizations that Ruth and Dana share in their article on the different architecture scopes you may have on an organization.

Architecture Scopes


(Image Credits Ruth Malan and Dana Bredemeyer)

In a nutshell: architecture discussions and alignment should consider the scope of the systems around the team (e.g.: to have a good discussion on application architecture, we consider the domain scope, in the figure above - neglecting to do so will most likely lead to suboptimal or even harmful designs for the overall system performance). This is important because the teams owning these systems don’t live in isolation, and so doesn’t their architecture. In fact, as Ruth and Dana say: “architectural decisions are those that must be made from an overall system perspective.”, i.e.: most important decisions are made with the perspective of the surrounding system, so it is always key to consider that boundary.

With this consideration, I think it is key to consider the scopes we have within our organization when defining how we “approach architecture”. Teams and their systems (team scope architecture) are part of a bigger surrounding system, which will affect and be affected by the team and their systems. That surrounding scope will also need an approach to architecture - so any other ones around it. To me that is an important consideration when talking about forms of approaching architecture, as it unveils new forms to approach architecture at these different scopes. Classically this has been approached with Enterprise Architecture, and more recently I am noticing several interesting trends such as “Architecture as Enabling Team”. This is especially visible in organizations that are shifting to empower their teams with maximal abilities to move with clear purpose and at high-velocity. In the following I share some insights on this form and how it opens doors to some interesting variations of the topologies shared by Gregor.

Architecture as Enabling Team (“Enabling Architect”)

“Architecture as Enabling Team” is a term I have been using (and heard already other people mentioning) since I read the book Team Topologies. In fact I even define this speficic team as “structural enabling team”. The reason comes from the fact that in general this is an enabling team (by the book definition) exist for a limited period of time. On the other hand architecture teams tend to exist for an indefinite amount of time. Nevertheless, this shares the other core ideas of the book definition: a team that exists to enable the “stream aligned teams” (or product teams) in the organization and maximize their cognitive load to operate at flow. This positioning is very interesting and opens doors for very interesting developments and novel topologies to approach architecture. For example, a person may have the Architect function, working across multiple related teams that together build a product or contribute to a common value stream to the customer (e.g.: a product from the product portfolio of the company). figure below depicts this idea (note: this is a simplified representation, aiming at showing a possible way of positioning of Architects in this topology).

Architecture as Enabling Team


As we can see in the Figure, this person (in this case I am calling her “Product Architect”) works at the “product scope” (which is the system that surrounds the team scope). She will be aligning on the product-wide architecture with teams (and with domain - the following scope). Furthermore, she may also play a role in coaching and enabling each team to approach architecture within the team scope (where different applications exist). So, this becomes a sort of upgrade on the version of topology #1 shared by Gregor (with bi-directional interaction), but also at the same time the team is (should be) responsible for the team scope architecture (i.e.: using topology #3, or in some cases #2). This combination enables approaching the different scopes required to address architecture, and furthermore having a model where Architects are enablers for teams on decision making (e.g.: facilitate architecture workshops, assist in improving documentation, and other elements).

This “Architecture as Enabling Team” positioning also means that we have a network of Architects in the organization with a clear mission (enable teams), which can collaborate on domain knowledge but also exchanging knowledge doing architecture, and with that, nurturing the craft of doing architecture in the organization (between Architects, but also with the teams they collaborate with). This will mean that the way we approach architecture will also continuously evolve (e.g.: new people join, new challenges arise, etc.) and we have explicit attention to cater for architecture (even if at a given moment we have a less explicit Architect function - e.g.: if this becomes just part of culture and we need formal architect presence).

This section is “WIP” (Work-In-Progress). I am working on and developing several articles on this topic. Some on the positioning on Architecture (and other Structural functions) as Enabling Team, but also connected to my Introduction to Sociotechnical Systems Evolution and Architecture series where I am trying to write down some ideas on “Who does and drives the evolution of Sociotechnical Architecture” (where this topic - approaches to architecture - are coming back, with the several extra dimensions, required to address the different perspectives of Sociotechnical systems).

InsighTweet