Architectural governance tends to be associated with frameworks such as TOGAF or Zachman, with its bewildering array of tools, documents, reviews and plans. These heavily structured approaches can have a place in terms of helping large, chaotic enterprises to develop a (illusionary) sense of order, but they are not known for encouraging agility.

Agile and lean rhetoric supports a team's right to decide on their own architectures, tools and techniques. Although this should be honoured, in larger enterprise you will still need some mechanism for achieving consensus around the strategies and protocols that are in use.

Less can be more

It's natural for larger organisations to try and realise economies of scale by building shared expertise in a set of core technologies. This needs to be traded off against a desire to give teams some latitude in choosing their own weapons and it's important to know where to draw the line.

Standardisation efforts are often better off focusing on “big ticket” items such as databases or API gateways, where significant investment is required to learn how to support and scale them. The more powerful a technology, the more important it is that a team knows how to use it properly. Individual teams are unlikely to be able to reach the same kind of depth of understanding that can be accumulated through enterprise-wide adoption.

The desire for economies of scale can also give rise to the development of engineering standards to help teams avoid wasting effort in “re-inventing the wheel”. After all, there are some problems that you really don't need to solve more than once.

This kind of standardisation effort can easily tip over into restrictive bureaucracy. It can be useful to have a channel that allows teams to share ideas that have worked for them, but this should stop short of trying to make teams adopt cookie cutter solutions. A team won't feel ownership of a template, no matter how good the original solution was.

It can be surprising just how open you can leave things. There is a kind of evolutionary convergence that happens with system architecture. In most cases teams will naturally gravitate towards similar set of solutions and approaches, purely because they are all solving similar challenges. Given this, they should only need a gentle nudge to go in the “right” direction.

Managing change rather than defining standards

If teams should be trusted to make their own decisions, there should still be scope for peer reviewing these decisions. Team dynamics can be a strange thing and it's always worth validating decisions against the wider context of the organisation as a whole.

For example, if a team wants to adopt a new technology then you need to make sure that a team really understand the implications of the technology they have chosen. For example, will it limit any technology choices they might make in the future? What are the security implications? Is there any expertise in the technology in other teams?

This kind of intervention should be less about restraining teams from making bad choices and more about providing a clear path to permission. It does not have to involve a tortuous vendor comparison matrix or scoring mechanism, but it should be enough to ensure that they have taken a full range of considerations into account.

In this, more agile sense, architectural governance should be focused on managing change rather than trying to maintain lists of rules and standards. It should be a force for encouraging innovation and enabling the adoption of new technologies.

Enter the architecture board

This style governance can be driven by the type of cross-organisation architecture board more commonly found in enterprise architectures. TOGAF defines these groups more in terms of their role in compliance and enforcement, but in a more decentralised, agile environment the focus should be more on enabling change.

An architecture board can also provide some much-needed visibility over technical decision making. Michael Nygard's idea of using Architecture Decision Records is a useful example of how you can capture the context, status and consequences of decisions in a lightweight format that can be easily digested by teams.

It's easy for teams to get stuck in their current development stack. A lot of the time they just don't know that whether they are allowed to change. By spreading the word about the kinds of solutions that are being used around the organisation you can inspire teams to break out of their silos and try something new.

Filed under Agile, Architecture and Development process.