The confusion surrounding the role of architecture when aiming for agility isn’t simply a labored talking point — it’s part of the reason Agile initiatives fail and architecture teams are losing influence. As it stands, it appears Agile and architecture are struggling to find a fit. This Advisor considers the possible effects of a third way: agility through “antifragility.” Rather than aiming to control, or to remove control, we should seek to build systems, both technical and business, that aim to be antifragile to change. This allows the production of business and technical architectures that enable agility through design rather than process or mindset.
In an environment where both inflexible and unstable software can lead to business failure, modern businesses need both the flexibility espoused by Agile practitioners and the rigor of more structured systems engineering methodologies. This contention is the source of much debate and confusion between the Agile and architecture camps and requires an alternative architectural approach. Thus, we propose that by architecting for antifragility, businesses can gain real agility and deliver systems with a higher level of quality. NYU Distinguished Professor Nassim Nicholas Taleb describes an antifragile system as one that gains from disorder; a system that becomes stronger when exposed to stressors (even unpredictable or unknown stressors). An antifragile system is by definition agile and resilient.
Antifragility in Software
Due to extensive research being carried out on the subject of computational antifragility, many solutions to this kind of problem will emerge in the future. It is important to realize that the degree of fragility of a system is often a function of its internal structure. The ability of a system to change under stress is governed by the interconnectedness of its parts, how strongly they are tied to each other, and how much change ripples through the system. Therefore, there is a need to ensure that we match the level of interconnectedness of a system’s components with the effort required to reorganize them in the face of change. This is something that architects are well qualified to do.
For many years, the decomposition of software systems has been held captive by the latest technological trends, vendor interests, and a slow-shifting mindscape. Many students of software engineering still hold fast to ideas of elegance and reuse, often making software unnecessarily complex in the process. There has, however, been a broad library of dissent against these methods, dating back to 1972. Software engineering pioneer David Parnas’s ideas on nonconventional decomposition tell us that we can build better systems by focusing on what will change rather than what will happen functionally, while software architect Juval Löwy’s important distinction between functional- and volatility-based decomposition via the IDesign Method provides some ideas and techniques that make this easier.
Each of these methods relies on focusing on the elements that can change, rather than on concrete requirements. By building a system where the primary requirement is the ability to handle change, a very different piece of software is constructed than would happen otherwise. This need for change in design philosophy — away from building to specific requirements and toward building systems that are antifragile — has been expressed elsewhere, including at NASA. Kjell Jørgen Hole’s book Anti-Fragile ICT Systems illustrates that systems demonstrating high levels of antifragility have the following four properties:
-
Modularity (consisting of separate, linked components)
-
Weak links (a low level of interconnectedness between components)
-
Redundancy (the presence of more than one component to cope with failure)
-
Diversity (the ability to solve a problem in more than one way with different components)
Antifragile Systems Design
The Antifragile Systems Design process guides the architect to optimize and balance the four antifragile properties mentioned above with the VUCA (volatility, uncertainty, complexity, ambiguity) elements present in a project. With a few days of analysis and design work, we can shift any project in the direction of antifragility, without incurring a great deal of overhead. The Antifragile Systems Design process mixes ideas from complexity science and systems engineering to create a method to guide the design effort.
This process embraces the complexity in building dynamic systems. Following the advice of Taleb, Parnas, Löwy, and others, we need to focus on what we do not know before focusing on what we do know — accepting our limitations and our inability to predict the future. Indeed, the Antifragile Systems Design process is not fixed but can grow and change with every project. With this new architectural approach, the intention is not to create yet another framework or silver bullet, but to provide a starting point for a new type of design process. This process follows several simple steps and requires no more tooling than an Excel spreadsheet.
Who Takes This On?
The Antifragile Systems Design process requires a mix of skills within business, business architecture, and software engineering. However, this is not simply a business activity or a software design activity and cannot be divided into different tasks for different silos; each step in the process creates feedback loops to ensure that answers arrived at are coherent. Antifragile Systems Design requires an organization to move as one toward solving the problem of complexity, which means changing the perspective from “us versus them” (IT versus business) to simply “us” (business). Business leaders, business/enterprise architects, and software architects all need to engage with the process to make it work. This requires a new approach from both architects and business leaders.
Architects need to work with the business to describe the VUCA environment, translate the impacts on the software decomposition, and even assist in business-level mitigations. Currently, few architects span this range; therefore, a business architect and a software architect often must work together to guide the process. However, it is possible for a single architect (business/architecture-focused or software-focused) who combines business understanding and software engineering knowledge to guide the process.
Business leadership plays an important role in enabling the architects and the project to embrace this approach. By employing Antifragile Systems Design at a high level, business leaders can learn to ask the right questions of their software teams and quickly assess the stability of an initiative.
[For more from the authors on the Antifragile Systems Design process, see “No More Snake Oil: Architecting Agility in a Complex Environment.”]
