Many software architects work in an environment where they are not leading a single software development team but instead are responsible for the overall design and technical integrity of a multisystem environment which supports the operations of part of an organization, or perhaps is a large software-intensive product. Each of the teams working on the individual systems that make up the whole will work fairly independently, and in many cases, some of the teams are likely to adopt an “agile” approach to software development.
Software architects in this position sometimes find it difficult to work effectively with their development teams, even though everyone wants to deliver a great system for the stakeholders. The reasons for this can be complex, but this article outlines some of the ways in which software architects can direct their efforts to overcome these problems. First though, let’s consider why there can be tensions between software architects and agile teams.
While architects and agile teams both want to deliver good systems in a timely manner, they tend to disagree about the best way to achieve this. Some of the reasons for this are:
- When to design - Architects tend to want make the big decisions as early as possible. Agile teams often want to do it later and let the design emerge. The software architect’s approach is driven by the desire to avoid risk and rework and to ensure a degree of commonality right across the environment. The agile teams are driven by a desire to deliver the simplest system possible and so to avoid design work that isn’t immediately required.
- Design artifacts - By the very nature of their work, software architects tend to produce documents and prototype implementations, whereas agile teams want to focus almost entirely on running production code and may not value architecture deliverables that take other forms. Architects must make sure that their work is packaged and presented in ways that the development teams will find immediately valuable, rather than expecting them to accept long abstract documents containing their words of wisdom.
- Development process - Some architects favor high(er) ceremony processes because they feel that gives them better visibility over the software being developed, whereas agile teams prefer simpler processes that are often less formally defined and are specific to the individual development team.
- Time horizon - Architects typically design with a view to the long term and think about return on investment over a multiyear time horizon, whereas agile teams tend to focus on the current iteration and what will provide immediate value to the end users of the system. A balance needs to be struck between the proverbial “five-year plan” that becomes irrelevant two years later and a very short-term approach that ignores obvious needs in the near future.
- Breadth of focus - Part of the role of an architect is to be aware of a wide range of stakeholders across the organization and to make sure that the needs of those with a valid interest in the system are met. On the other hand, agile teams stress the need to focus on the “customer” of their system which is typically interpreted to be the end user. However, end users often don’t value factors such as disaster recovery, regulatory compliance or ease of inter-system integration, which are important to other groups of people. So when the architect is accused of introducing unnecessary complexity they are often simply responding to requirements from outside the end-user community.
- Large programs versus single system - architects in a multisystem environment are concerned with changes across multiple systems, whereas a development team understandably wants to focus on their system and its regular iterative release cycle. However, the realities of a large change programs mean that some give-and-take is required to ensure that the deliveries from the individual system development teams line up to deliver a useful whole.
Can we bridge the gap between these two sets of different priorities? Agile teams aim to organize their work using the principles of the Agile Manifesto. Can these principles help architects to organize their work too? The principles are:
