What should architects focus on - and what should be delegated to teams?
Most organisations want to encourage autonomous engineering teams who can design their own solutions, choose their own tools, and make their own decisions. They also want to achieve some economies of scale, ensure proper use of technology, and deliver ambitious solutions that are implemented by multiple teams.
This implies a role for design co-ordination, which is where architects come in. They can bring a wider perspective to bear that compliments the more focused horizon of engineering teams. If we’re serious about autonomous engineering teams, then there should be a clear separation of concerns between architects and engineering teams. The problem is that it’s not always clear where this boundary is. When should teams be talking to the architects?
A specialism, not an exclusive club
Architects are not “elders” with a natural right to direct engineering teams. Architecture is not a hallowed rank that engineers can ascend to once they reach a certain standard. It’s a specialism.
This specialism tends to vary between different individuals, job titles, and organisations. There are “enterprise” architects who are concerned with how technology, business process, and data are used across an organisation. The “solution” architects are more interested in how systems are built, while “data” architects focus on how data is managed and arranged. Some organisations dispense with the role altogether, though in practice they tend to wind up giving it another name (e.g. “staff engineer”).
“Architecture” is such a wide term that it can be difficult to nail down exactly what architects should focus on. Something to do with fundamentals and principles? Working on those problems that are too big for any one team to solve? Supporting those areas that are the most obvious broken? Looking at the stuff that’s just important?
Architecture is about the important stuff. Whatever that is.
(Ralph Johnson via Martin Fowler)
Eltjo Poorta suggested that this “important” stuff really equates to those areas that have the most impact on cost and risk. These twin concerns can help architects to focus on their attention more effectively – i.e. the higher risk and potentially expensive areas.
This can be a useful perspective as it allows for an objective and measurable approach to prioritisation. It also helps to position architecture firmly in a business context that less technical stakeholders can identify with.
Risk is a great driver for architecture. George Fairbanks suggested in “Just Enough Software Architecture” that architecture decisions and system design should be driven by a keen understanding of risk. Whether you are taking a planned, evolutionary or minimal approach to architecture design, architecture should be focused on those areas where the risk of failure is highest. This should be an iterative process where a prioritised risk register guides the ongoing priority for architecture work.
However, a focus on cost and risk is a little reductive. There is more to architecture than averting disaster and managing budgets. Most architects take risk and cost into account when working out what to focus, whether they do so consciously or not. These are not the only concerns that architects should use when deciding what to focus on.
What should architects focus on?
If cost and risk isn’t enough to define “the important stuff” then what should architects be focused on? In broad terms they should be putting in place the conditions that help delivery teams to be successful. They should not be serving as heroes that help to fix the most broken stuff or underwrite the biggest risks. There are a series of more strategic imperatives that they should be focusing on – while delegating system design and delivery decisions to teams.
1. Defining the strategy and vision
There needs to be a “direction of travel”, or a “north star” that helps teams to understand where the organisation is heading. This is the meta-guidance that helps teams to ensure that their work is aligned with wider objectives of the business.
This kind of technology strategy shouldn’t stand on its own. Ideally, this should be derived from a clear product strategy that in turn has been derived from a well-defined business strategy. Developing, articulating and socialising this strategic view of technology is an iterative process that should be an on-going pre-occupation for architects.
2. Guidance for engineering decision making.
Engineering teams make architecture decisions all the time. Most architects lack the detailed domain knowledge needed for contributing to most of these decisions. What architects can do is provide guidance around how these decisions are made.
This guidance can take different forms. A robust set of architecture principles can help an organisation to express what it values in good technology design. Standards and policies can help to define the red lines or things that teams must do. More informal guidance and best practices can influence teams towards things they should do. Reference architectures can provide teams with maps that help them to build better solutions based on more appropriate technologies.
All these initiatives combine to create a set of “guard rails” for engineering teams, defining a clear boundary within which teams are free to make their own decisions. Restricting the decision space in this way can help to provide focus for teams, so they don’t waste time re-inventing the wheel.
3. The spaces between the teams
You can’t solve every problem with an autonomous engineering team. Some problems are just too big for any one team to address on their own, such as single sign-on. Others require more specialist knowledge which is unlikely to be found in normal engineering teams. You also need some sense of shared “rules of the road” that determine how systems talk to each other.
There’s no reason why groups of engineering teams can’t collaborate to eventually solve these problems. It’s just that architects with their wider, less domain-specific perspective are often better placed to address concerns that fall between teams.
4. The landscape
Even if you’re not running a full-blown enterprise architecture, there does need to be a mechanism for mapping out the technology landscape. An application catalogue or system inventory allows you to reason about technology in a more consistent way. It provides a foundation that allows you to consider how systems are connected to each other, work out the scope for reuse, understand technical debt, identify gaps, and plan future improvements.
It’s surprising how few organisations even have an authoritative, canonical list of all the systems in play and who is responsible for them. These organisations tend not to have an architecture practice…
5. Whatever people ask you for
In many cases, it’s up to the individual engineering teams to decide what Architecture should be focusing on. Architecture practices often have a mechanism that allows teams to request architecture engagement, such as an Office Hour style session that teams can bring problems to or TOGAF’s more formal request for architecture work process.
In this sense, architecture can act as a service provider to the wider technology community, where their areas of focus are defined in part by the demand from other teams. This implies a high degree of trust with teams – they are left to get on with work within the boundary that has been created for them and do not have to endure architects checking up on them.