Three “-tures”: architecture, infrastructure, and team structure
At a recent workshop, at XP 2014, we looked into practices that support scaling up agile, and in particular the role of architecture.
One conjecture we arrived at is that architects typically work on three distinct but interdependent structures:
- The Architecture (A) of the system under design, development, or refinement, what we have called the traditional system or software architecture.
- The Structure (S) of the organization: teams, partners, subcontractors, and others.
- The Production infrastructure (P) used to develop and deploy the system, especially important in contexts where the development and operations are combined and the system is deployed more or less continuously.
System architecture (A), Organizational structure (S), and Production infrastructure (P)
These three structures must be kept aligned over time, especially to support an agile development style. We can examine the alignment of these structures from the perspective of A and the role of the architect in an agile software-development organization.
The relationship of A to S is also known as (socio-technical) congruence and has been extensively studied, especially in the context of global, distributed software development. It is akin to the good old Conway’s law. It is very pertinent at the level of the static architectural structure (development view), where a development team wants to avoid conflicts of access to the code between teams and between individuals, while having clear ownership or responsibility over large chunks of code. When A is lagging, we face a situation of technical debt; when S is lagging, we have a phenomenon called “social debt” akin to technical debt, which slows down development. See what Ruth Malan wrote on the topic; in particular: “”if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins”.
The alignment of A with P is seeing renewed interest with increased focus on continuous integration and deployment and the concept of “DevOps” combining the development organization with the operations organization, and having the tools in place to ensure continuous delivery or deployment, even in the case of very large on-line, mission-critical systems (e.g., Netflix, Facebook, Amazon). When P is lagging, we witness a case of “infrastructure debt” as described by Shafer in the Cutter IT journal, which is another source of friction. It is also explored by M. Erder and P. Pureur’s Continuous Architecture.
A, S, and P must be “refactored” regularly to be kept in sync so that they can keep supporting each other. Too much early design in any of the three will potentially result in excessive delays, which will increase friction (by increased debt), reduce quality, and lead to overall product delivery delays.
Congruence, DevOps
With my colleagues I. Ozakaya and R. Nord from the SEI, we’ve examined some of this conjecture in a paper to be published by Springer-Verlag later in the fall. I’ll add a DOI when it happens.
Philippe Kruchten 
Nice insight. In DevOps, is there still a real difference between A and P, or is the production infrastructure becoming “just another module of the System”, with the DevOps team “just another class of end-users”? See the pic at the bottom of this blog post: http://eltjopoort.blogspot.nl/2014/08/how-devops-impacts-architecture.html. If there still is a difference, what is the defining property that separates them?
Agree. Apart from the fact that A, S and P are distinct specialties with their own concepts, languages and best practices, there is no question that the separation of concerns is not and cannot be complete. A+S+P while having different responsibilities have many interaction effects. Decisions made in one area impact the others, and often each area will have its own agendas, and the most influential way is often not the best.
Successful architects must keep the whole in mind,and must have the systems thinking skills to understand the risks and tradeoffs of decisions. However, I think that even more importantly, communication skills are critical: listening and reading for comprehension and speaking and communicating for action. In my experience, this latter area is the most important. The ability to diagnose a problem and analyze the impact of alternatives is of little value if the ability to persuade for change is not in sufficient supply.
Valuable insights. It also makes clear that these insight need to be levelled with existing concepts from management science, like the 7s model from McKinsey, maturity models and EFQM Model. This is required to match two different viewpoints (business and IT a.k.a. demand and supply).
There are also models that guides architects to choose explicitly to focus on the quality of architecture as a dimension or on business goals as another dimension.