In this article I am going to talk about some of the trends that have effected architecture over the previous twenty years.

The three major trends are:

1. the emergence of public cloud
2. the introduction and eventual dominance of agile software development
3. 
   the domination of the FANGS

All three of these trends have had a fundamental impact on how we think of architecture and the kinds of systems which we build, and I don’t think these are widely understood.

The emergence of public cloud

The impact of public cloud on software architecture has been profound.

All architectural decisions are, fundamentally, economic decisions - they are decisions about how to apply resources to achieve some kind of optimum, in the presence of trade-offs.

Public cloud fundamentally alters the economics of many of these decisions.

In particular:

• Infrastructure-as-Code and continuous deployment reduce the cost of complexity and of scale
• Easy deployment patterns for rich infrastructure components means that new components can be included at low cost
• Serverless systems (i.e. scale-to-zero with metered billing) means that components can be very low cost in initially, and so can be introduced easily

The huge range of services available with these characteristics is fundamentally different from the way systems were designed twenty years ago.

Previously most systems architects would have had a very limited toolbox - a few databases, probably a single preferred application server and a few delivery support items, caches, authentication systems and that kind of thing. Most systems would have been built as monoliths using a two-tier or three-tier architecture not because that was the best option but because it was the only feasible one.

All major public cloud companies offer training and certification in architecture and design. AWS offer Solutions Architect and Application Architect courses and exams, and Microsoft offer a Designing Microsoft Azure Infrastructure Solutions course.

The goal of these courses is awareness - the range of services they offer is so huge, and some of them are so complex, that awareness of them is their greatest problem. They do sometimes provide support in how to assemble complete systems as well - Amazon’s “Well Architected Framework” is notable here - but the bulk of the training is in what they offer and how to use it.

Agile software development

The dominant methodology for software development is now that known as agile. I imagine everyone reading this has some idea what it is. The original Agile Manifesto still puts it better than most. It says that agile favours:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

This has resulted in most software developers being trained to actively avoid heavyweight processes and documentation.

The result of this is to squeeze architectural activities into the margins - decision-making takes place “near the codeface” and is performed by those involved in implementation.

Agile was a reaction to previous approaches which drew inspiration from other fields of engineering, where detailed planning is the norm. These detailed planning approaches were also the norm in software but were found to have serious drawbacks.

In essence, the economics of software are very different from typical engineering. Software has a basically zero replication cost, so once the software is designed and written it is complete. If cars, for example, could be reproduced at zero cost from the output of the design then (a) cars would be agile and (b) they’d be an awful lot more complicated.

The backlash to document and process heavy design approaches in software was very strong and many developers now have never worked using any approach other than agile.

In my view this has gone too far - there is a sweet spot, which varies from project to project, where both planning and responding to change have value. Accommodating this is difficult, and the emerging approach of Continuous Architecture embodies the attempt to be able to iteratively conduct architectural activities, responding to change but also having a clear plan.

The domination of the FANGs

The “FANGs” are a humorous attempt to describe the mega-tech corporations. FANG stood for Facebook Apple Netflix Google. There have been many other similar acronyms.

These businesses now dominate the global economy and form the underlying infrastructure of our lives. Their decisions have wide-ranging impacts on everything.

In the technology sector they are the place many people want to work, and the way they design and build their products now fills the articles, books, webcasts and conferences that practising developers and engineers consume.

This means the architectural approaches they use dominate our discussions. Many of the practices we consider best practice come from these companies.

A lot of this is very positive, books like Nicole Forsgren’s Accelerate have been hugely influential and provide a lot of underlying data showing how lean techniques can be very effective.

The challenge here is that the vast majority of architecture is not being done at a FANG. Most of it happens inside non-software businesses building systems for themselves, and often those systems just don’t need the characteristics of Netflix.

These systems don’t need infinite scale, or seven nines uptime, and designing them to provide it is unhelpful.

I have talked to many developers who have really gone all-in on some of these approaches, implementing systems using microservice architectures, or using serverless systems, where really they would be fine with existing monolithic two-tier or three-tier designs.

These decisions can have huge economic impacts, increasing development effort substantially, but without generating any real business benefit.

This is not their fault - if everything you read (including from the training provided by public cloud companies!) tells you to do this, then why would you not?

The end result of these trends is that:

1. Architecture is often done late, informally and without structure
2. The dominant approaches used are often inappropriate for the systems being designed
3. Nobody learns to analyse their architectural requirements well, because the typical requirements of the FANGs dominate

Surprisingly, perhaps, there is very little training in architecture provided in courses for Computer Science or Software Engineering, and because of the above trends very few developers and engineers ever really experience architecture being performed in a structured way.