Welcome to the digest #5 of my "Technical Leadership and Architecture insights" (or TLA_insights for short).


Very excited to share this digest. It has three very entries on a topic I am calling: "Architecture Topologies and Scopes". These are the three entries:

  • one based on an article by Alberto Brandolini, discussing the relation between Context Maps and Team Topologies;
  • one based on an article from from Ruth Malan and Dana Bredemeyer on architecture scopes and key elements to achieve a minimalistic approach to architecture;
  • and finally one inspired by a great post by Gregor Hohpe on approaches to team scope architecture, which I ended up extending and introducing the idea of "Architecture Topologies" and furthermore discussing an example of a topology I am very fond of: "Architecture as Enabling Team".

Over the last years I have been thinking and exploring these topics extensively. I see them as foundational elements to approach Sociotechnical Architecture design and evolution (which as you may have noticed from my articles and notes is a topic I consider key to unlocking new levels of performance in modern organizations). On this digest topic, and in a nutshell: we must have sound and suitable strategies to approach architecture (and how to evolve it) in organizations to truly maximize their potential. This is not a trivial discussion and depends on a lot of factors, such as: the state of the architecture and its practice in the organization; the maturity of teams and their practices; the nature of the products the organization is developing, etc. Nonetheless, what is clear is that all those factors and the organization "scopes" of architecture (shaped by the sociotechnical systems and architecture in place) are key to shaping the organization's approach to architecture. The three articles of this digest explore different elements of this.

When I published the entry on "Architecture Topologies" I got many interesting reactions and discussions. Those led me to start a GitHub repo (Architecture Topologies) to collect knowledge on this topic and hopefully capture interesting patterns for architecture topologies. The goal is not to create a solution, but to capture this knowledge and try to shape a better "language" to drive meaningful discussions on how to approach architecture in organizations. Because, whether we like it or not: every organization and system has an architecture... ignoring that is a recipe for issues. However, the uniqueness of each organization also means that we cannot use the same approach (topology) to architecture in every organization (there is no silver bullet). This is why I consider that it is more interesting to focus on shaping a "base language" that enables us to discuss how we approach architecture can be a powerful tool: each organization can shape (and evolve) the "architecture topology" that enables them the most. In some organizations it will be possible to have teams owning the "team scope" architecture, with some people or way-of-aligning the surrounding system scope architecture; in some other organizations we may need an explicit Architect (function) working in the teams... and many other flavors. (This idea is highly inspired by the great work and approach of Team Topologies, which as I mentioned a while ago "provide a DSL for Org Design and Evolution).

On a personal note, and since the last digest: I have also published a new original article called Sociotechnical Architecture as Enabler of Product Thinking. The article is a continuation (and deep dive) on my talk from DevOps Lisbon Meetup ("Evolving Tech-enabled Orgs Using Sociotechnical Architecture") and follow-up interview I had an Manuel Pais (co-author from Team Topologies) - DevOps is Not Enough for Scaling and Evolving Tech-Driven Organizations. This is a topic I am rather active lately (including first-hand experiences on bol.com's product-led organization developments). This article, among other things, touches key elements and traits that I think we need to consider to truly empower tech-enabled product-led organizations. (Spoiler alert: it is not just product thinking, nor DevOps, each on their own silo). This topic also relates closely with the topic of this TLA_insights digest, namely the ideas of having structures and dynamics that holistically empower product development (from all the key perspectives needed, e.g.: value, people and technical). The article raised quite some interesting discussions and sparks, and there will be new articles on this topic in the near future.

I hope you enjoy these four entries! If you found this issue interesting or useful make sure to subscribe to the newsletter or follow-me on twitter so you get notified of new records in these and other topics. I hope you have fun and find some interesting insights here. Don't hesitate to contact me if you have questions or want to chat about these topics.

TLA_insights digest #5 - Architecture Topologies and Scopes

light About Team Topologies and Context Mapping, Alberto Brandolini

Review of article by Alberto Brandolini on on the core ideas, parallels, connections and complementary points of Team Topologies and Context Mapping (and in general Strategic Domain-Driven Design (DDD) aspects). Alberto explores these ideas and presents several interesting insights that I am sure will increasingly gain more traction - as these two approaches really complement and enrich each other on a lot of aspects to approach sociotechnical architecture evolution.

Organizations need to start "speaking" a clear language for understanding and driving organization's sociotechnical architecture evolution. Team Topologies and DDD Context Mapping offer many elements for that language.

record overview | đź”— record

light My Insights: In this article Alberto Brandolini (inventor of EventStorming) goes over the parallels, connections and complementary points of Team Topologies and Context Mapping (and in general Strategic Domain-Driven Design (DDD) aspects). Although DDD tends to be associated with the "technical and functional aspect" of software architecture (the "models"), the reality is that all of the aspects of DDD are equally applicable (and relate) to organizational architecture aspects (ones that are very explicitly covered in Team Topologies book). Alberto explores the core ideas of each approach and presents several interesting insights on where these approaches complement each other and address issues that are still rather neglected and may benefit from applying this “combo” (namely "organic growth of our organizations" without explicit design and strategy). I am seeing these two approaches being picked up a lot, most of the time in separation, but some people are bringing them together. I see a lot of value in their combination and think their combined usage will be gaining more traction, as they provide a lot of interesting elements to address sociotechnical architecture evolution in a more robust manner.

(Subscribe here or follow me on Twitter to get notified about new TLA_insights)

Analysis & Summary

The insights and notes of this record are inspired and driven by an article from Alberto Brandolini (inventor of EventStorming) on the core ideas, parallels, connections and complementary points of Team Topologies and Context Mapping (and in general Strategic Domain-Driven Design (DDD) aspects). Alberto explores these ideas and presents several interesting insights that I am sure will increasingly gain more traction - as these two approaches really complement and enrich each other on a lot of aspects to approach sociotechnical architecture evolution.

The problem Space (of proper organizational design and evolution) is largely uncharted territory

Most organizations grow organically and without clear strategies or people owning and explicitly looking at this essential element of an organization's effectiveness.

Note: I find myself repeating this a lot lately: "to address sociotechnical architecture challenges, organizations can't just do a transformation project and be done; organizations are (& should accept that they are) continuously evolving". As Matthew Reinbold recently also said: "you are only done when there's no more organization". So, it is key to empower people and systems that cater for organization sociotechnical evolution. These shouldn't "control evolution", but foster understanding and enable conditions that support the "best evolution" (given all the understanding we have - which changes as we learn more things).

This lack of approaches and "ownership" and strategy for organization evolution leads to people taking the (what seems) “easy road” and go for adopting "successful models" that work in other organizations and contexts. Best examples here are the Spotify Model or Lean from Toyota. However, when these models are used without a clear understanding of our own organization challenges and context they tend to cause more harm than good. This is why Team Topologies and DDD Context Mapping (patterns) - among other techniques - can help a lot: they offer a rich vocabulary and semantics (“language”) for understanding and discussing organization’s sociotechnical architecture evolution.

Team Topologies & Context Mapping Basic Ideas

Alberto presents Team Topologies key concepts (the Four Types of Teams & Three Interaction Modes). Then he establishes a parallel with Strategic DDD Context Mapping. Context Mapping basically covers the same problem space (as Team Topologies), however uses different (and much more semantically fine grained) constructs. Example: Context Mapping Patterns offer many different types of "Collaboration" (as in Team Topologies).

He gives an overview on the mapping of teams and DDD "Bounded Contexts" (which defines a "logical and language boundary" for the “parts”/models of the architecture), and show several types of topologies for these two (e.g.: one team owning multiple Bounded Contexts; multiple teams on Bounded Context, and the "ideal setup" of One Team per Bounded Context), depicting properties and challenges on each. This is a very important clarification, as many people still think that a Team always maps into a Bounded Context (or even worse a "Microservice"). These vary a lot as a function of the state of the sociotechnical architecture and the types of Bounded Contexts we are in (i.e.: core, supporting or generic). It is key to have this in mind when approaching organizational design and evolution. Alberto touches a few interesting "drivers for evolution", e.g.: the number of Bounded Contexts, which may be a lot and may not enable to have the "ideal" one per team; another very interesting one is the nature and required speed of evolution of different Bounded Contexts: some may be very stable and others may change very often - which impose different types of dynamics and risks, and consequently also may affect the strategy we have for the teams setup.

Notes: although Alberto does not touch on this in this article, an interesting dimension of team and Bounded Context setup design is the nature of the (sub)domain where the Bounded Context lies. DDD defines three major types of (sub)domains: "core" (the differentiating domains of the business/product); "supporting" (supporting to the "core" domains) or "generic" (these are generic elements that we need to run our business and product). This nature can also be mapped into the ideas from Simon Wardley and his Wardley Maps, namely: products go through an evolution, it is a natural thing. This means different Bounded Contexts will be in different phases of evolution (and that will change in time). This is key to define the type of team or approach for that particular Bounded Context, e.g.: a non-core and commoditized Bounded Context may be "outsourced" or replaced with a cloud managed service, while core Bounded Contexts tend to be better served by in-house teams with a lot of available capacity (“cognitive load”) to develop those key differentiating elements of the product.

Comparing Both Approaches

This section has a nice reflection on the differences and similarities between the approaches, e.g.: Context Mapping doesn't talk about teams (explicitly) but models. Nevertheless all its patterns can pretty much be applied to the notion of teams and their collaborations too. I really found the following remark very insightful and interesting: "Team Topologies provides a reference towards a desirable to-be state, while DDD context mapping provides more fine-grained patterns for assessing the current state."

Notes: I agree with this remark, although we could argue that Team Topologies can provide a lot of value on assessing the "as-is" state. That will help in deciding on interesting steps of evolution. But I agree with Alberto, using (complementing it with) the richer language of DDD Context Mapping can help a lot in understanding challenges in more detail, and then be able to define conditions and strategies to evolve into a more desirable "to-be" situation.

Alberto finishes the article by making a great remark on organization evolution: "every solution will be ephemeral by design". All the elements that Team Topologies and DDD Context Mapping enable and make explicit should be done in a continuous conversation (again, these two approaches provide organizations a language to discuss sociotechnical architecture evolution!). Organizations should pay attention to the context changes in order to again iterate and act on the elements that need attention. This is a continuous process, and “will never end” - and that is just how it should be. Failing to embrace and acknowledge this is a recipe for remaining on the old fashioned "organic growth", which we know is not a great place to be in our ever increasingly competitive landscape.


light Less is More with Minimalist Architecture, Ruth Malan and Dana Bredemeyer

Article from two current thought leaders on (Sociotechnical & Software) Architecture developments: Ruth Malan and Dana Bredemeyer. It presents several interesting insights on how to approach architecture, namely take a "minimalistic approach" to architecture: "sort out your highest-priority architecture requirements, and then do the least you possibly can do to achieve them".

System-level architecture (decisions) should be enabling for "autonomous teams" owning the more narrowly scoped parts of the system. Striking the right balance, and take a minimalistic architecture approach is key to achieve that end goal (& maximize the overall system properties).

record overview | đź”— record

light My Insights: This short article Ruth Malan and Dana Bredemeyer is packed with insights on how to approach and balance architecture activities in tech-enabled organizations. I resonate a lot with the proposed ideas, especially the striving for a minimalistic architecture approach: "doing just enough" (i.e.: no more, no less). What does that mean? Architects (and/or whoever drives architecture decisions) should focus on addressing the system priorities so that the teams working on those particular elements of the system can maximize their effectiveness for the overall system (instead of a “local optimization”). This approach also strives for leaving the maximum amount of room on decision making for teams working on the "more narrowly scoped" elements of the system, instead of overdoing those decisions from the higher-level system perspective.

(Subscribe here or follow me on Twitter to get notified about new TLA_insights)

Analysis & Summary

The insights and notes of this record are inspired and driven by an article from two current thought leaders on (Sociotechnical & Software) Architecture developments: Ruth Malan and Dana Bredemeyer. This short article shares several insights they have on how to approach architecture. The article is from 2002, but it is as up-to-date and relevant as it can get. They propose a "minimalistic approach" to architecture, namely: "sort out your highest-priority architecture requirements, and then do the least you possibly can do to achieve them".

The article has the following structure: what are Architecture Decisions; then go into the challenges on Limiting Architecture Control and Insisting on Architecture Control; and finally discuss how to Empower with Scope. In the following I will go over these elements, highlight several quotes and elaborate on them, adding my own insights and reflections.

Architecture Decisions

"Architectural decisions are those that must be made from an overall system perspective."

This is a great quote, which in my view emphasizes why having architects (or people that take explicit care of architecture decisions) are key to enable organizations to operate effectively. The reason comes from the fact this “overall system perspective” type of work we do to support building out software products (in smaller parts / teams) tends to have unclear ownership. It defines the "bigger system" where normally teams work falls into (these are key ideas of Systems Thinking). If we don't have anyone able (or ways to capture) that holistic understanding, we will not be able to have the necessary context when working on the different parts of the system (i.e.: on the parts that are owned and built by different teams). This is why it is key to have proper ownership of a system's architecture.

"Essential decisions identify the system's key structural elements, the externally visible properties of those elements and their relations."

These system-level essential architecture decisions tend to focus on key structural elements (e.g.: how do different teams and parts of the system are evolving) and their external visible properties and relations.

"If you can defer the decisions to a more narrowly scoped part of the system, it is not significant to the system level architecture.” ("more narrowly scoped" wording is a 2021 update suggested by Ruth Malan to previously "lower level" term previously used.)

"The only justifiable reason for restricting intellectual freedom of designers and implementers is demonstrable contribution to strategic system properties that the organization could not otherwise achieve."

However it is key to not overdo Architecture decisions. As the two previous quotes emphasize, whenever we can defer a decision to a more narrowly scoped part of the system, we should do it. Teams have ownership of decision making on this. It becomes part of the internal application architecture, which must deliver the expected interface behavior or "visible properties" and relation with other related parts of the system.

Figure 1 provides a nice overview on typical levels of scope within an organization. I think nowadays we may use slightly different terminology (remember the article is from 2002), however the core idea is pretty much to the point: there are scopes of decision making, which enable clear boundaries of decision making. This fosters autonomy while providing a connecting structure from more narrowly scoped parts of the system to the externally visible properties of the system we want to build in the organization.

Minimal Architecture

Limiting Architecture Control

"Lack of visibility into other parts of the system, schedule crunch, and communication overload—many factors cause developers to make decisions optimized for a local scope and often suboptimal for the overall system."

Nowadays there is some reluctance on having Architects doing architecture outside the scope of a team. There may be some good reasons for this - like “not doing good architecture” (too much, and centralized, up-front-architecture) or the so-called “ivory tower” architect. Those are definitely things we want to avoid while doing architecture! However, the solution should not be “not doing architecture”, since then we fall into the “local optimization” trap.

This is why it is key to have systems-level architecture, which focuses on understanding and decision making and enables the more narrowly scoped parts of the system to have more context and better decision making. That will enable us to achieve our goal: "improve the overall system" properties and not just have local-optimizations. I often use my restaurant system metaphor to emphasize this: "you want to serve the best dish the chef can cook with the best wine we have in the restaurant without understanding if they are the best combination... they are (most of the times) not the best combination".

"So, in addition to every other tough job you have as an architect, you must figure out the right balance of architecture and anarchy for your organization."

"It is key to keep in mind that Architecture changes the way people must work, so don't try to do too much too quickly!"

Being an architect (or anyone handling architecture decisions) can be tricky at times. Nevertheless, it is key finding the balance of decision making. It is also extremely important to be aware of how everyone (people) are being (or will be) affected by those architecture decisions. Sometimes (what looks like) "anarchy" is fine in certain organizations, especially organizations with stronger culture of enablement. However, in many other organizations that is just not always possible. Having that awareness is also key for approaching the evolution of the (sociotechnical) architecture of the system(s).

Insisting on Architecture Control

“If you take the other extreme: The Architect as a Governance Organization that avoids setting clear direction and decisions…”

This is the other extreme side of architecture control, which may overdo and end-up micromanaging the governance of all decisions at all scopes and system levels. This is what I mentioned earlier as the modes that created a "bad reputation" for architecture. Such an approach is definitely not desired as it limits the flow of decision making and overall effectiveness of the different parts of the systems.

"Keep your architecture decision set to the minimum needed to achieve the most strategic architectural goals. Then work with all levels of management to ensure that these decisions stick."

To avoid the trap of "too much control", we must strive for "minimum decision making" at each scope/system level to enable achieving the “end goals” we have for the system. I really like how Ruth and Dana state that "all levels of management" should focus on ensuring those "minimal decisions" stick and as such enable people working within those systems to take the reminder set of decisions (while relying on those higher level decisions made). In a nutshell, this is what Netflix calls Highly aligned and loosely coupled on their culture document. Their goal is to “spend time debating strategy together, and then trust each other to execute on tactics” to achieve those aligned goals.

Empower with Scope

"You might already be fighting the notion that architecture disempowers. To some extent, it is a hard truth that architecture does place limits and take away some autonomy... But the alternative is chaotic development that, frankly, is even more disempowering."

The balancing act of doing "good architecture" is difficult, but when we strike the balance it enables achieving the "system properties" we are striving for. It does that by providing "enabling direction", or "limits", for the designers and implementers of the different elements of the system. I want again to raise the fact that the level of "constraints" imposed and "who does architecture" is something that will vary from organization to organization (as a function of their culture and maturity of their practices). However, I couldn't agree more with the statement above: the system is made of parts and is the result of their interactions, and having a "chaotic development" approach where parts are evolving in complete isolation is "disempowering" (as the properties we want to see on the system will most likely not happen).

"One of the benefits of a good architecture is that structural elements with well-designed interfaces become the focus for design and implementation. This lets work progress on the structural units with greater autonomy—and small teams with strong ownership are the font of innovation and productivity."

In my view this is the key element to strive for in good architecture: enabling teams with the context and elements that provide them with alignment with the overall desired system properties. With that “context” teams can take full autonomy and "creativity" to best architect the internal elements of those structural units of the system. It is important to note that this does not mean that teams may not participate in system-level discussions, quite the contrary, that is totally possible. The element key is that those system-level discussions must take place - independently of whom is leading/driving them. This is a point that many organizations still misinterpret, namely: that by having "architects" or discussions at systems-level scope jeopardizes teams autonomy, when it is exactly the other way around. This systems-level alignment enables teams to best own and evolve the system elements that they are responsible for!


light Architecture Topologies & Architecture as Enabling Team

This article started as an quick analysis of a great article by Gregor Hohpe on "ways of approach architecture in teams", but as I was writing those a lot of insights and ideas were sparked and it evolved into a sort of "first brainstorm" of something that I ended up called "Architecture Topologies" (inspired by the great work and model of Team Topologies). I also explore the need to look at wider architecture scopes (not only team scope) to have a comprehensive overview of "topologies" to approach architecture in organizations. Finally, and related with multiple scopes of architecture, I share some ideas on "Architecture as Enabling Team", which I consider a key shift on how we can approach architecture in modern / forward-looking organizations.

In this article I play with the idea of "Architecture Topologies", sparked by a great article of Gregor Hohpe on "approaches to architecture in teams". I ended up also looking at "architecture scopes" and topologies we can adopt, namely one I am very excited about "architecture as enabling team".

record overview | đź”— record

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.

(Subscribe here or follow me on Twitter to get notified about new TLA_insights)

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 Architecture 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).