There is often pressure for large organisations to adopt some of the muscular slogans associated with start-up culture. We need to be lean and disruptive, move fast and break things, and discover solutions through experiments and pivots.

The problem is that we also need to manage legacy estates, achieve economies of scale, and accommodate multiple teams collaborating on large-scale processes. This implies that there may be a tension between the lean, experimental nature of agile development and the more deliberate, planned demands of a large organisation. In this context, any architectural governance can be dismissed as an intrusive drag on a more free-wheeling style of agile development.

It does not really have to be like this.

Teams should choose their own tools

Much has been written about the importance of giving self-organising teams the autonomy to make their own decisions. This makes a lot of sense as engineering teams will be better placed to choose tools and design solutions than a distant design authority. A loosely coupled architecture can reinforce this autonomy by allowing teams to build solutions without any dependencies on other teams.

This does need a little qualification. If teams are to be autonomous then they need the necessary skills, knowledge, and perspective to make effective decisions. Not every team is composed of highly paid engineers who can be relied on to make balanced judgements.

In many cases, the choices of tools and technologies affect more than just the development team. For example, if a team is not directly responsible for running systems in production then it is reasonable to set some operational expectations around the way solutions are built, deployed and monitored.

Some choices are also too big for any one team to make. Technologies such as data warehousing or container orchestration require specialised skills and knowledge that are unlikely to be found in every development team. These require a shared approach that needs some form of collective decision-making.

The case for standardisation

Applications are rarely completely self-contained. They are often part of a wider set of collaborating processes that need to support a seamless and friction-free customer experience. You need some commonality in the way that processes monitored so you can trouble-shoot issues. The business also needs to be able to consolidate data provided from numerous sources to guide decision making.

Standardization gets a bad rap, sometimes deservedly so. It is primarily used as a means of driving cost efficiency, but often becomes an instrument of control that creates bureaucratic waste. A huge amount of effort is expended on defining standards, ensuring compliance, and considering exceptions.

This can be limiting for development teams, but there are benefits to standards. They can help to an organisation to focus on building expertise in specific technologies. They also prevent teams from wasting time on repetitive debates that reinvent the wheel. Standards can be seen in terms of a contract with development teams that defines a clear boundary for solution design.

This often needs a “goldilocks” approach where you balance governance with flexibility. For example, Go might be mandated for lightweight services, Node for web applications and Python in more general-purpose development. This still creates a boundary, but one that tries to balance economies of scale with team autonomy.

Implicit here is a strong culture based on shared values where trust is the norm. Individual initiative and critical thinking should be encouraged as the preferred way of making decisions. You need to trust your development teams to do the right thing and make responsible decisions.

Heavy standardisation regimes are based on the fear that engineers can run amok and waste the company’s money on novelty technology. In fact. the opposition is often true. Many teams are held back by an innately conservative outlook, often reinforced by uncertainty about whether they have permission to innovate. In this case, governance can serve to encourage innovation by giving clear approval for new tools and technologies.

Which decisions should be left to teams?

There does need to be some alignment mechanism, but the command-and-control approach of yore is not effective in a world of autonomous teams and iterative development. Enterprise architects are regarded as too distant, too high level and just too out-of-touch to be able to support a more devolved model of decision making.

In practical terms this means giving teams freedom to design solutions without fear of architectural review meetings. What possible value can architects bring to solution design unless they are closely engaged in the domain? Some problems require specialised architectural skills, but in this case the architect should be engaged with teams on a day-to-day basis rather than being parachuted in from on high.

Some decisions are what Jeff Bezos called “consequential and irreversible… one-way doors” that deserve a more considered process around them. Most decisions are not like this and you do not have to live with the consequences for very long. It is this latter, more reversible decision that should be left to development teams.

The difficulty is in distinguishing which decisions are genuinely “consequential and irreversible”. There can be a tendency to apply heavy-weight processes to decisions that really do not deserve it. This causes drag and undermines experimentation.

As a rule of thumb, a decision should only need wider consultation if there is a significant budgetary angle, a technical commitment that will last beyond the current application scope, or an impact that will be felt beyond the development team. This can be facilitated by architectural governance, but the focus here should be on collaboration and consensus.

Return of the architecture board

How to build this consensus? This is where a re-vamped version of our old friend, the Architecture Board can add value. This is a concept rooted in TOGAF, where top-down governance is manifested in a committee of the great and good, drafting policies, approving solutions, and dispensing exceptions. As you might expect, this kind of governance council is not normally associated with team autonomy and development agility.

In an agile world an architecture board can become a mechanism to build a coalition and drive consensus. It should include key stakeholders, influencers, and representatives from across the engineering organisation who can help to obtain buy-in for any technical decisions.

It's in this collective where boundaries can be set and "consequential and irreversible" decisions made as a part of a consultative and inclusive process. This collaborative take on a formal governance structure can make decisions easier to propagate without creating friction or undermining team performance.

Filed under Agile, Architecture, Strategy and Governance.