There are several schools of thought around what enterprise architecture really does. From a software development perspective, its main purpose is to guide development and ensure that it is aligned with business objectives.

Enterprise architecture does have a relevance problem. No architect would ever self-identify as an “ivory tower” practitioner, but this is precisely what enterprise architecture encourages. The typical outputs of enterprise architecture aren't always relevant to the problems that engineers are trying to solve on a day-to-day basis.

The enterprise architecture playbook

Enterprise architects have no shortage of models and frameworks to draw on. What these have in common is a tendency to set architects as leaders of design, arbitrators of change and the key conduit between the "business" and "IT".

In terms of outputs, there's usually a future state architecture to aspire to, maybe even a reference architecture to provide a playbook for solution design. There will be standards and principles that can guide engineers and solution designers. There will also be a process of governance and oversight to ensure all this guidance is being followed.

The problem is that none of these outputs are relevant to self-managing engineering teams in a modern, agile development culture.

A future state architecture tends to suffer from the same problems as waterfall-style development. It tends to be made obsolete long before it can be achieved by the change and uncertainty that is a normal part of any organisation. The problems you think you want to solve now are not the same as the problems you'll want to solve in a few years' time.

Reference architectures and architectural principals tend to suffer from a problem of relevance. Enterprise architecture sees itself as above design and tends not to engage with detail. The problem here is that details matter. You need deep domain knowledge to be able to lead design or you are in danger of making simplistic interventions that miss the nuance that should define most decisions.

A future state and set of principles can be seductive as they provide a neat, goal-orientated approach to the difficulties of development. People want to believe that you can express an organisation's problems into a clean and simplified architecture. This creates a false impression that complexity can somehow be abstracted away. It can't. You need to engage with it directly.

The top-down governance implicit in enterprise architecture can be constricting and even damaging. Architecture boards are given the right of approval over distant projects that they barely understand. They can force standards to be followed dogmatically regardless of whether they are adding value.

Organisations have been trying to solve the challenges of large-scale development with these centralised governance mechanisms for thirty years. It hasn't really worked. Perhaps there's another way of approaching this?

What should we be doing instead?

Architecture should be a collaborative discipline, not one that is set apart from engineering teams. The basic playbook for enterprise architecture is still valid, it just needs to be reinterpreted in a more collaborative context.

You do need to set a direction of travel. This doesn't have to define some unachievable future state, but it should describe the landscape and set some hard boundaries that teams should operate in. For example, you might want to mandate the use of containers as this is your best bet for guaranteeing some level of portability in the future. What happens inside the containers might be a concern for engineering teams.

There is a place for principles, guidelines and standards, but these should be descriptive rather than proscriptive. They should assist in making decisions rather than defining them. A proscriptive approach tends to leech away team autonomy by implying that they can't go wrong by following a set of rules. It undermines the quality of decision-making by encouraging blind acceptance.

There's also an opportunity to use principles and standards to educate less experienced developers. After all, some decisions are always objectively bad. They might not be obvious to engineers who have never experienced the inevitable outcomes before. This knowledge doesn't always come from architects, but they can lead in a process of understanding and collating the collective wisdom of the entire engineering organisation.

There is a role for governance in all of this, but it needs to support a consensus culture and decentralised approach to decision making. Architects should work directly with engineering teams to ensure that decisions are informed by a wider range of concerns. Architectural guidance should be part of the fabric of everyday, pragmatic decision-making rather than a compliance framework.

Even a TOGAF-style architecture board can have a role to play here. It can be a useful means of including stakeholders, building consensus and providing visibility. It's about fostering discussion rather than handing down decisions. The business of design and decision-making should be something that happens in collaboration with teams.

What sort of architects do we need?

This all amounts to a very different set of demands on architects from the more abstracted, framework-orientated discipline of enterprise architecture.

Collaborating with engineering teams makes both domain expertise and hands-on technical knowledge more important. Architects need an awareness of the capabilities of technologies within their domain and how to leverage these for the wider business. They will need to be comfortable with operating at pace, living with ambiguity, working iteratively and leaving decisions until the “last responsible moment”.

In this sense the distinction between engineers and architects can become a little more blurred. What architects bring to the party is a different perspective. They may have skills and experience that cannot be found in engineering teams. They might be better placed to build relationships outside the immediate confines of technology delivery. They can understand opportunities or traps that might not be immediately obvious to engineering teams. They can also help to identify and solve problems that are too big for any engineering team to solve on their own.

The discipline of architecture is an important part of any efficient engineering organisation. It just needs to adapt its game from the process-orientated "Enterprise Architecture" of old to something more collaborative.

Filed under Agile, Architecture, Strategy and Governance.