The centralized design and decision making associated with traditional software architects has, most righteously, been questioned by the agile community. It goes against the very core of Lean and Agile – empowerment. As a consequence, the role of the architect has been eliminated, but not just its traditional manifestation. This has in turn led to the devaluation of both architecture and, even more so, of software architects.
The question should not be if we should get rid of the centralized design and planning, because that we should. Instead we ought to ask: what should we replace it with? The agile lack of response obviously provides no guidance.
The misconception of self-organizing teams
The underestimation of architects and architecture is in addition caused by another agile misconception; that of self-organizing teams. I usually refer to it as the agile myth of Apollo 13. Apollo 13 mission control, lead by Gean Kranz, successfully brought the flight crew members back to earth after an explosion which caused a loss of electrical power and failure of oxygen tanks. The mission control team solved numerous problems, acting as a self-organizing team rather than according to the traditional Command n’ Control management paradigm. This “successful failure” is often used as an argument for the superiority of self-organizing teams. And yes, so far, it’s all true. But the conclusion within the agile community has often been: Just turn everything into self-organizing teams, and the rest will just magically sort it self out. The mistake here, is the assumption that self-organization is something that you just decide or choose. But, it’s not. Self-organized teams are not created, they occur. And self-organization can be nothing more then anarchy, unless we create the right conditions, and provide the right leadership.
Creating the proper conditions
A real self-organized team will only occur when three prerequisites are met: a purpose (a common goal), ability (craftsmanship, or domain expertise) and a supportive culture (a culture that promotes involvement, responsibility and team spirit).
All these components are apparent in the Apollo 13 example: astronauts lost in space (defining a common team purpose), ability (highly skilled and experienced staff), a supportive culture (through management and team member mindset).
We have to create the environment and conditions that allow individuals and teams to succeed. And here lies the purpose of architecture, and of architects. It is not to control and structure, it is to empower. The purpose of architects is to provide leadership, a leadership necessary and complementary to traditional management.
Underestimated by the agile community
These aspects are not completely neglected by the agile community, but their importance is greatly underestimated. To me, this is one important reason to go “Lean” rather than “Agile”; in Lean, with its “management by means” philosophy and focus on mindset, attention is inevitably shifted from form and formulas, to people and underlying principles.
This view of the architect becomes especially important with the evolutionary approach to development given by the continuous improvement paradigm of Lean. As Gordon Pask puts it: “The role of architect […] is not so much to design a building or a city as to catalyse them: act that they may evolve”. This summons up the “new” role of architects in a good way: being the enabler of evolution, act to create room for opportunity.
Architects have traditionally been taking responsibility away from developers. In Lean product development, architecting is a process in the opposite direction, handing power to developers. This process is not accidental, it has to be enforced.
Visualizing cross-functional dependencies
At Scania, as cross-functional architects, our objective is to remove cross-functional barriers, and facilitate cross-functional work. Our job is not primarily to make designs. It is to understand when design is needed, and ensure design is being made. To do this, we need to make cross-functional dependencies apparent, make them comprehensible and visualized, so that individual developers can understand their detailing of design from the perspective of the whole. The architect, in this perspective, is someone who understands the consequences of change, understands and explains dependencies, and involves the right people in defining the solution. For example, architects facilitate crossfunctional workshops allowing architecture to be defined rather then defining it themselves.
One consequence of this is that we need products and systems that can be grasped by “the many developers” (to paraphrase the IKEA founder Ingvar Kamprad). This, if anything, is a job for the cross-functional architects; how can we make the over-all system layout simple enough for every one to understand it, so that everyone can alter it? That, for sure, doesn’t happen by chance. The architecture describes the system or product at hand, defines it. To a large extent, it sets the way we think about our product; it defines how we approach it. This can empower, but it can also be a straitjacket. In the end, the architecture defines our mindset.
Customer focus
How we divide the whole into parts control how efficiently we can organorganize and work in parallel. Interfaces within the product define interfaces within the organization. The purpose of a component sets the purpose of the team developing the component. Here, architecture can be used to do good. For example, by deconstructing the product primarily in customer oriented functions, rather than tiers and reusable components, we can put each development team in control of a complete development-flow, beginning and ending with the customer. After the agile movement eliminated the architects, turning to Lean, the first thing we probably ought to do is to replace those architects with – architects. Just a very different kind.
