Agile teaches us the true meaning of Architecture

What is architecture? Not of cities or buildings, but the organisational version: enterprise architecture, solution architecture, application architecture, software architecture, business architecture, infrastructure architecture? My neck hairs generally rise a little when we architects turn to this particularly vexing and ivory tower kind of navel gazing. But this time, I have to discuss it, because it is a prerequisite for an approach for looking at things like (architectural, technical) debt and the architecture practice, which will be the next story in this series of three.

Agile, and what it says about architecture

Architecture has an official mention in the ‘Agile Manifesto‘ where it says that one of its founding principles is: “The best architectures, requirements, and designs emerge from self-organizing teams.”. The problem is not only that this hardly a definition of what architecture is, as it only says where it comes from, but it is also rather naive.

Agile has not only serious advocates (and I count myself among them), but also its fair share of hard core fanatics, which tend to believe (and sometimes get their management to believe) that agile working gives you some sort of infinite change capacity and that it can handle all the different sorts of change there is, even large transformations. We even have — rather large — frameworks such as the Scaled Agile Framework (SAFe), which handles change up to the highest strategic levels, all based on Agile principles.

Such frameworks do have something in common with comprehensive frameworks that came before (say: FEAF, MODAF, TOGAF, etc. for architecture). Nobody really uses all of it. The  scope of the framework generally defies ready understanding by all those are – at least in name – working inside its settings. It often seems to me that a basis of actually working practice has been extrapolated to make a complete framework. While the ‘filler’ never really was put to the test, the whole is being sold as a ‘best practice’ nonetheless.

Frameworks like TOGAF and SAFe have something else in common: they are strongly based on the world of application development. This shows for instance when TOGAF bases one of its two definitions of architecture on ISO’s definition of software architecture. Or it is suggested when SAFe tells us that there are features and enablers and one of the enablers is ‘infrastructure’ (though one can of course abstract that notion). Frameworks tend to be a bit heavy on definitions and detail and they attempt to be comprehensive. They therefore often grow over time to define and encompass more and more. But large frameworks tend to be used only in part, because the full framework is bureaucratic overkill for most situations. Something that is often visible in a ‘definition sickness’, a wish to create strict definitions for everything, including things that will defy such definitions in reality (ref. Uncle Ludwig).

While large frameworks may be looked at with a critical eye, the concept of Agile itself (while not new) really is a very practical answer (at least in part) to the complexity and above all volatility that confronts most changes and transformations in today’s complex organisations. Complex because IT has made it possible to be complex. Volatile because compared to, say, factories full of heavy machinery, IT is pretty easy to change. It is soft-ware after all and even the hard-ware doesn’t have the lifetime of, say, a cathedral’s walls. The complex organisations of today pack a lot more autonomous change than the paper-based organisations of yore. A waterfall with very precise Big Up-Front Design (BUFD) has therefore become so impractical that it has become almost impossible in today’s IT-laden world. So, we are ending up with a constant massively parallel evolution within our organisations based on many (Agile) teams working in parallel. 

Defining Architecture

As I said above, discussions about ‘what architecture is’ are generally a near-complete waste of energy, better spent at producing good design decisions for your organisation. There are many definitions of architecture, I reproduced the most widely used above. In Mastering ArchiMate, I confess that I somewhat like 

Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those elements interrelate

from the Institute For Enterprise Architecture Developments. Not that I concur with everything else they write, but still. However, saying it is ‘about’ something doesn’t really say how it is about something. And ‘understanding’ is an equally weaselly term. So, it doesn’t really help you much. Many other definitions exist, from MIT, the US Government, etc. The one from the ArchiMate Foundation was: “A coherent whole of principles, methods, and models that are used in the design and realization of an enterprise’s organizational structure, business processes, information systems, and infrastructure“.

But a definition that rhymed with my own feelings on the matter was the one from Martin Fowler in his widely read 2003 paper “Who Needs an Architect?“. There he ends up defining architecture as “things that [are] hard to change”. This isn’t that different from Grady Booch’s definition who said:

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

(Note: a more complete quote has a good remark on ‘science versus art’ of design). I too feel strongly that architecture is in the end nothing but design and that the desire to truly separate them comes in part from “[wanting] to talk about design but [wanting] to puff it up to make it sound important” (Fowler, again). So, in our world of architecture, we can say: Architecture: the design decisions that are hard to change. Of course, they only really become hard to change when they have been implemented. Paper is patient and writings are easy to change (that is, unless you are in the 6 months architectural discussion from hell). But as a measure for their importance, it is a good definition, and much better than ISO’s, ArchiMate’s, TOGAF’s, etc..

There is a subtle issue though with the adjective ‘hard to change’. 

Suppose you have a design decision that tells your developers how they should structure their Python code. If you have a lot of code, changing all that code from one structure to another will be a lot of work. In other words it is hard. In other words, that design choice is ‘architecture’, in this case software architecture. But one developer can easily ignore that design decision and write code that does things differently. ‘Change’ is easy in soft-ware after all. So, while the entire implemented architecture is hard to change, in IT it is often easy enough in individual parts to change (see the quote from Ralph Johnson above). Architecture is thus sometimes something ‘hard’ made up of a lot of ‘soft’. You see that at all levels, e.g. if your design choice is using only Oracle databases, individual PostgreSQL databases are easy enough to set up, and so they easily appear (thus making your landscape more complex, which is generally frowned upon). But changing everything in your landscape from Oracle to PostgreSQL is hard (and it might not even be completely feasible). Hence, the definition becomes:

Architecture: the design decisions that are hard to completely remove from implementations.

(Fowler’s shorthand ‘hard to change’ will do in most cases, though). One other remark regarding ‘hard to change’: they may be hard to remove because of dependencies with others, so the meaning of implementation is ‘broad’: for instance changing both producers and consumers of a service. ‘Hard’ must always be seen from the perspective of your organisation, a nice example why architecture scope is generally wider than solution, project or product scope. Note: this definition is IT-independent. Note also: one could argue I have now defined the (lacking) meaning of ‘fundamental’ in the ISO definition.

Agile and Architecture, opposing ends of a scale

So there turns out to be a very interesting relation between the world of Agile and the world of Architecture. Agile is meant to make change as frictionless as possible. Agile is based on making change easy (or at least normal). And on the other side: Architecture, as we noticed, is that where change is hard. In other words, they are on opposing ends of a spectrum, they are a fundamental seesaw in your organisation.

I support the Agile claim that it is the optimal way to do change in our IT-heavy complex business landscapes. But that means that whatever we find is the hardest to accomplish with Agile approaches is de facto ‘architecture’. In that way Agile is teaching us what Architecture is.

Note: It is important to mention that Agile takes a lot from Lean which was based on the Toyota approach for physical factories. Toyota wanted to make manufacturing more flexible as a way to tackle complexity. But there are many aspects of that setting that do not easily translate to the silly putty world of software. For instance, Toyota maintained a very limited variability and most things could not change. In software everything can change and it is not by definition true that a method that was in the end a (minor) sub-optimalisation on the whole physical production process (with large effects), could be the full basis for another production process.

So, where do we find architecture, where does Agile get into trouble? There are a few obvious examples:

1. Whatever your approach to working agile and reacting directly to feature/defect pressure from your ‘customers’, large and complex environments can have a lot of dependencies that make change hard. That may for instance be a couple of key elements (say, the platform choice, such as database, an ESB, or even coding standards or coding language) that are used by many and so are hard to change. Or it may be that the different components have many subtle interrelations. In both cases: change is hard so the design choices that are hard to change when implemented (which can be pretty detailed ones) are architecture.
2. Agile in complex environments, especially when driven by mantras like YAGNI (You Ain’t Gonna Need It) has trouble being prepared for change (just in time). This is why SAFe’s ‘architectural runway’ exists, for instance, and why items on it get a separate treatment from the ordinary features and defects of the day. SAFe even states that one should reserve a certain fixed capacity for architecture work in sprints. In SAFe’s terms, work is being done ‘extending the runway’, so future features can ‘consume’ it. And here is why YAGNI is not always a good thing (a bit like principles in architecture which can be pretty toxic): being careful not to do useless work is good, but turning it into an orthodoxy is bad. Consider that you want to transform your infrastructure in an agile way from that lots-of-handwork managed hosting of today to a fully automated ‘devops-ready data center’ (DRDC) of tomorrow. You know you need certain platforms to support those applications, such as Tomcat, JBoss, Session state storage for both, File sharing, Redis, MongoDB, Message Queueing, IIS, etc.. Inspired by Lean (which itself was developed in a much less volatile physical manufacturing setting, and goes back to Benjamin Franklin), YAGNI tells you that you should not start to work on those until the first ‘customer’ knocks on the door (the ‘muda’, or ‘non value-adding work’ part of Lean). But this means that when they actually come, they will have to wait until you have prepared the prerequisites (you create ‘mura’, or ‘unevenness’). In other words, transformation of applications from the old managed hosting to the new becomes hard, because your runway is not ready when needed unless you manage it somewhat separate from the requests of the day.
3. Agile has trouble when too many related things change concurrently. Change becomes hard because you have to make many interwoven choices all at the same time in situations where you do not know everything yet and you might get stuck on a level above those agile teams (you create ‘muri’, or overburden). Making these choices is hard, so they are architecture. And so is trying to make domains independent (or in a derogatory term: turn them into silos…), an old architecture remedy.

Apologies for playing a bit fast and loose here with the Japanese terms. Agile, thus, brings into focus what architecture — the subject, not the practice, mind — is:

Architecture is every implemented design decision that makes Agile hard.

The choices what you put in your ‘extend the runway plan’ influences how hard it is to do your transformations: those choices thus are architecture. And they should not just be left to product owners under user pressure. They should also be set by the architecture stakeholders so there are checks & balances against ‘silo-ism’ and ‘short-termism’. More about the architecture (the practice) in part two of this mini-series.

Defining architecture as ‘the hard stuff’ is not all we need. Because apart from ‘what is hard’ we need some guidance as to what to aim at with architecture. Often it is said that the idea behind architecture is to enable agility by creating flexible solutions. In fact, Fowler has stated that the architect’s task is to remove architecture. But that it too simple. Flexibility generally comes with a cost and those ‘expenses’ (in time and money) cannot be scaled infinitely (again: see Johnson above). Everybody wants the solutions to be perfectly flexible, but this is neither cheap (and nobody wants to foot the bill), nor quick, nor always even possible. Sometimes the situation is simple: you must make a choice that will be hard to change, you cannot support all options (think platforms for instance, you can’t support them all). So, yes, by all means: if the lunch is not that expensive (or even ‘free’): choose flexible solutions or postpone choices as long as possible (which SAFe suggests: keep your options open). But in practice, often choices have to be made, choices that will be hard to change, architectural choices. Architecture strives to minimise unnecessary inflexibility, true, but it is naïve to think there will be a world where all change is easy and nothing is hard. There is more than flexibility. There are, I think, basically three: Robustness, Efficiency, and Flexibility (REF).

More about REF, the practice of architecture and specifically debt in part two, but I am reminded of the animation “Why Enterprise Architecture” we created years ago, while we were making architecture itself agile in a world of up-front designs.:

Listen to your doctor, counsel, etc.

And concluding: architecture (the thing) is what is ‘hard’, but you might as well say that ‘architecture (the practice) is hard’. They are closely related, architecture (the practice) is hard because today’s complexity makes change hard and today’s volatility makes change perilous. This is why you should pay good architects megabux 😉 Well, maybe not, but you should definitely listen to good architects and take their advice very, very seriously. The only simple question left is: how do I recognise a good architect?

Next article in this mini-series: Prioritising Architecture under Agile

PS. I’ll be giving the EA keynote at the Enterprise Architecture Conference Europe 2018 on October 23.

.