Enterprise architecture anti-patterns
Every organisation tends to organise technology decision making differently. Some form a centralised enterprise architecture practice, while others prefer to maintain a more informal community of senior technologists. Much depends on the individuals involved, the technology challenges, and the wider organisational context.
Despite this varied practice, there are some common anti-patterns that seem to cut across the various different ways of organising architecture...
1. Conference-driven, Google driven, etc
Engineering teams can be like flocking birds. It's only natural for them to want to work with emerging technologies and novel techniques, but this can create a tendency to ape larger, forward-facing technology companies such as Google and Amazon. Engineers have their heads turned at conferences where consultancies and corporations brag about their successes in leveraging emerging trends. They come back determined to apply them to their own environments.
This can lead to inappropriate technology choices and misaligned initiatives. "If it's good enough for Google, it's good enough for us" is a poor guiding principle. Solutions that address Google levels of scale don't always translate well for small and mid-size development shops. This probably applies to more than 90% of organisations currently labouring with Kubernetes clusters.
Some solutions will only be available to larger organisations with the deep pockets required to hire the best engineers and experiment at scale. The rest of us are stuck with constraints such as scarce resources, manual process, decades of irreversible decisions, and legacy technology stacks. The future-facing dream offered in technology conferences does not always speak to these problems.
2. "Ivory Tower" architecture
This pejorative term is based on the accusation that architecture is too far removed from the day-to-day business of building and maintaining systems. Architecture can lose relevance by spending too much time on high strategy and abstract guidance, none of which speaks to the problems that people are grappling with in delivery.
Many people claim to have worked with "ivory tower" architects but very few ever admit to being one. This suggests that architects may lack a certain self-awareness. This doesn't necessarily mean that architecture is failing to do relevant work – it could be a problem of communication, where architecture is failing to demonstrate value. There can also be nuanced issues around ownership that are expressed as accusations of irrelevance.
It is up to architecture to manage perceptions and demonstrate relevance. They should be aware of any disconnect between the business strategy and what is happening on the ground. It's their job to identify any disconnect, come down from that "ivory tower", and make any strategy both relevant and actionable for engineering teams.
3. PowerPoint architecture
See "ivory tower". I love a bit of PowerPoint and sharp visual presentation is one of my most proudly worn skills. However, there is a risk of becoming overly abstracted away from the reality of the work. Do those fancy slides and diagrams convey anything meaningful? Do they reflect the reality of what's really happening on the ground?
There is no single representation of an architecture or strategy that will speak to everybody. You should expect to adjust the techniques, formats, and level of detail that you present to suit the interests and attention spans of each audience. Highly visual presentations can really work for some audiences but come over as facile to others.
Remember that no amount of fancy PowerPoint can make up for an anaemic strategy that fails to translate into a meaningful direction of travel...
4. Architecture as career progression for engineers
Architecture is often perceived as a high-status role that attracts a better salary than engineering. A common and potentially corrosive organisational anti-pattern is to position architecture as something you are promoted to from a senior engineering role.
Although most people become architects after a stint in engineering, this should be seen as a tangential move to a different specialism rather than a promotion. Architecture is concerned with a wider, more holistic view of technology based on a deep understanding of how the business works as opposed to the more focused, delivery-oriented concerns of engineering.
It should be possible for organisation to decouple seniority from specialism so that engineers and architects can be regarded as peers. There should also be a blurred boundary between the two disciplines as engineers shouldn't be denied the opportunity to do architecture work or make architecture decisions.
5. "Parking lot" architecture teams
Some architecture teams end up attracting clever people who don't really fit in anywhere else. They get "parked" in an architecture team because the organisation doesn't want to lose them but can't think of what else to do with them. These people often have long tenure in the organisation and a wealth of domain knowledge – but very little experience of architecture.
In some cases, architecture can be a natural career progression and they will become very successful after a period of adjustment. There are other options though, such as working as technical mentors or subject matter experts. It is a mistake to treat architecture as a default option unless people have the right strategic and collaborative mindset.
6. Building Utopia
All organisations are constrained in some way, but most are restrained by budgets and available skills. This means that architecture choices should be aligned with the capabilities of the teams that will be implementing them. Sometimes it's worth sacrificing architectural elegance in favour of a simpler solution that is more likely to be successful.
You also need to be aware of the organisation's appetite for ingesting new ideas. The more exotic a solution, the higher the "explanation tax" in terms of having to explain it to every single stakeholder. Simpler, monolithic architectures can be difficult to scale, but at least they are easy to understand.
7. Big design up front… and too little design up front
Getting the level of up-front design right be a bit of a goldilocks problem. Too much up-front design can choke development, forcing premature decisions onto a team and denying them sufficient flexibility in responding to evolving requirements. Too much faith in the power of evolutionary design and agile iteration can be just as restrictive. There are some challenges that emerge that you may struggle to address unless you have thought about them in some way.
You don't need to predict a detailed end-state, but you do need to establish a foundation and clear direction of travel. You need to take the time to understand requirements and manage risks. There also needs to be a willingness to defer decisions without giving in to procrastination.
8. No trust
It's easy to choke off engineering productivity by not trusting teams to deliver. Architecture should set comfortable guard rails to provide reasonable guidance and give teams time and space to deliver. Occasional architecture reviews are perfectly reasonable, but weekly interrogations are not.
Some architects really struggle with this. Left to their own devices, engineering teams will make decisions that may not align with an architect's expectations. This doesn't mean that they are wrong. It's up to architecture to decide which hills it is going to die on and be prepared to let teams make their own way elsewhere. If an architect really wants to closely guide delivery, then they may be in the wrong role and should consider a sideways move into engineering…
9. Implementing TOGAF
Don't get me wrong here. I regard TOGAF as an invaluable source of effective techniques and battle-tested wisdom. It's just that relatively few organisations can benefit from a full TOGAF implementation. It requires such an enormous force of will and commitment from the very highest levels of the organisation. Unless everybody in the senior leadership can explain why TOGAF can add value, then any implementation is probably doomed.
This isn't terribly profound of me, and it's even recognised within the framework itself. After all, the preliminary stage of a TOGAF implementation involves deciding which parts of the framework to adopt. It is possible to shrink it down into an iterative process of defining current state and the route to any desired future state. This really is the essence of any architecture practice, and it doesn't necessarily need to be reinforced by the weight of formal process.
10. No architects
There is a view in some corners of agile belief that an architecture practice is unnecessary when you have empowered and self-organising delivery teams. To align with delivery "flow" you need to ensure that a team contains all the skills and expertise it needs to make any technical decisions. That means that architecture expertise should sit in the teams, not outside of them.
There is much truth in this. Like it or not, teams make architecture decisions all the time. Development is more efficient if teams have sufficient perspective and skills to make decisions, without having to consult some external guru for guidance.
However, the problem is that this pattern does not scale. The idea of the self-contained delivery team works for self-contained solutions where decisions tend not to have any wider consequence. As systems and organisations grow these decisions become more complex, interrelated, and intractable.
You can create "platform teams" to provide shared infrastructure for "flow aligned" delivery teams, but this doesn't really address the problem. You need somebody to maintain a holistic view of technology provision, drive standardisation, and ensure consistency. This is where architects add value, i.e. they enable delivery at scale.
For every pundit saying that you don't need architects there's a cluster of blog posts and Reddit threads describing the dumpster fire caused by teams working without architectural guidance...