There are many ways of applying architectural governance to an organisation. Much depends on the kind of engineering culture that you want to support. There is a spectrum of different governance postures and decision-making models you can adopt, from tightly structured frameworks, through to the deliberate absence of governance.

Enterprise frameworks (e.g. TOGAF)

Architectural decisions happen in every engineering team regardless of whether the organisation formally recognises this. Many organisations struggle with clear decision making and follow ambiguous, sometimes informal, and often quite politically driven patterns. As companies grow, they often start adopting clearer rules to enable coordination and drive something approaching economies of scale.

Enterprise architecture frameworks such as TOGAF give formal structure to this decision making. The intention is to bring consistency, rigor, and visibility to the process of evolving an organisation's capabilities.

They have also been given quite a bad rap in recent years. They have a reputation for being overly abstracted and too long-winded. They have suffered in the face of agile\lean practitioners who stress the supremacy of the team and seek to sweep away any impediments - including anything that smacks of corporate bureaucracy.

The idea that there is a tension between enterprise architecture frameworks and agile practice is a fallacy. Teams can focus on delivering iterative value within the framework of an architectural roadmap that lays down a strategic direction of travel. TOGAF itself is an iterative process where you are invited to pick and choose those aspects that work for your organisation. It can be used to provide some simple guardrails within which agile teams are free to execute.

That said, enterprise architecture frameworks are more appropriate as a scaling tactic for large organisations. You need considerable determination to implement any framework-based approach, rock solid support among senior stakeholders, and no small amount of manpower.

Portfolio frameworks (e.g. SAFe, LeSS)

Agile development approaches such as Scrum and Kanban are very much focused on individual development teams and how they execute. By their nature, they don't have much to say about how a larger-scale portfolio of work is managed across an enterprise.

Portfolio management frameworks such as the Scaled Agile Framework (SAFe) and Large-Scale Scrum (LeSS) have emerged to try to address this gap. They may take a certain amount of flak for being "fake" or "branded" agile, but they do serve a genuine purpose, i.e. how does an organisation define and prioritise the strategic themes that will eventually be broken down into backlogs?

Many of these frameworks don't have a huge amount to say about architecture. They may either be too wedded to evolutionary design (LeSS) or too concerned with "agile washing" venerable project management processes (Prince II Agile) to talk about how technology decisions are made. That said, they do create some visibility around the process of planning and prioritising work. This gives architecture something to hook into.

SAFe does at least propose the metaphor of the "architectural runway", though it doesn't go into much detail around what this includes. The aim should be to provide a "safe landing" for development by augmenting the emergent architecture of team-based development with more intentional architecture-driven initiatives. This could be interpreted as a framework of conventions, technologies, and strategies that define the boundaries within which teams can work. How this is developed, implemented, and governed is open to interpretation.

Voluntary (e.g. "paved road")

One challenge for delivery teams is the growing complexity involved in deploying "cloud native" solutions. You will need to solve problems such as elastic scaling, fault tolerance, rolling deployment, service discovery, and monitoring. This can eat into a lot of productive time that might otherwise be spent delivering features. If an organisation wants to achieve any economies of scale, then it may want to address these concerns on a systematic, organisation-wide basis.

Many organisations solve this problem through internal developer platform initiatives, where platform teams are responsible for providing a mixture of shared infrastructure, managed templates, and common tooling. These platforms are necessarily quite opinionated and involve making numerous decisions on behalf of teams. The hope is that by adopting product-based thinking and treating engineering teams as customers, any platform will be compelling enough for teams to want to adopt them.

For the most part, these platforms are seen as optional, at least on paper. Netflix coined the term "paved road" to describe a culture where teams are free to implement alternative solutions but are responsible for maintaining any infrastructure that goes with them. The idea is to encourage a culture of freedom and responsibility while reconciling it with organisational goals of velocity and reliability.

Trust is a major component of this more voluntary approach, but so is the exercise of soft power by platform teams. As a "paved road" builds momentum it can be difficult to resist. You've got to be brave to go your own way when there's so much investment being put into a preferred solution.

Decentralised (e.g. "well-architected framework")

The problem with centralised platform teams is that they can become an inflexible bottleneck. Solutions tend to be defined by the capabilities offered by the platform (e.g. containers running in Kubernetes) when teams should really be designing solutions that are tailored to their unique workloads.

An alternative approach is to distribute capabilities between teams and make them responsible for running their entire stacks in production. Amazon is known for a "you build it, you run it" approach. This is built on the assumption that teams are equipped with the capabilities and expertise they need to build solutions that meet internal standards.

This autonomous model doesn't necessarily mean an absence of governance. Amazon's "well architected framework" lays down a series of best practices that are enforced through automated mechanisms and a lightweight review process. Architecture becomes a collective concern where each member of the team is expected to take ownership. Best practices tend to be identified by a community of principal engineers, there is still a role for technical leaders in conducting reviews and setting overall strategy.

This is very much the product of a specific engineering culture. Many organisations simply do not have the resources to fill every team with experts on every aspect of cloud native development. Some kind of centralised provision becomes necessary to ration scarce resources. The more expensive engineers you have at your disposal, the easier it is to build a decentralised organisation.

No architecture (e.g. "stream aligned")

There is a corner of agile dogma that regards separate architecture governance as unnecessary. Any problem can be solved by autonomous engineering teams so long as they are blessed with the right skills and experience. Teams should be optimised for delivery "flow" by organising them along product or platform lines.

There is some wisdom in this as architecture decision making capability should be embedded in engineering teams. Ideally, engineering teams should be able to execute day-to-day development without having to refer to an external team or architecture guru. This means optimising teams against your desired outcomes, be it product delivery, shared capabilities, or engineering enablement.

In this approach architecture concerns become an engineering specialism. You can do away with the notion of an "architect" job title and rely on a community of more specialised "staff engineers" to drive your technology evolution. This can work for a small set of teams, but beyond a certain point it is wishful thinking.

The problem here is one of perspective. Engineers in flow-oriented teams will inevitably specialise along their narrow remit. If you want to scale decision making, align technology strategy with the wider business, encourage economies of scale, ensure best practice, or drive standardisation then you need to organise for it.

A holistic view of technology strategy will not emerge as a natural by-product of autonomous engineering teams. It requires a specialist function with a specific responsibility for aligning technology and business strategy. The only question is which style of architecture function to adopt. A more framework-driven approach, adapt the looser structures of portfolio management process, or build a trust-based environment based on a more decentralised or voluntary approach.

 

Filed under Architecture, Agile, Strategy, Development Process and Governance.