What is agile architecture anyway? The red pill and the blue pill

Having coached many teams, projects and organizations on both software architecture and agile, one of the questions I’ve been asked a lot over the past fifteen years is: what is agile architecture?  Unfortunately, there is no easy answer to this question. There is no simple truth out there.

What agile architecture really is considered to be is different from organization to organization, from project to project and from team to team. Basically, it isn’t even one single question. Much rather I consider what agile architecture is the compression of two separate questions. The first question can be formulated as: what makes a software architecture agile? I would phrase the second question – which is equally important – as the following:can we do architecture in an agile way?

What makes a software architecture agile?

Let’s start with the first question. When you look up agile in dictionaries, it is defined as the ability to move quickly and easily, and also as the division of tasks into short phases of work with frequent reassessment and adaptation. Both of these definitions relates well to software architecture. In my opinion the first quality (move quickly and easily) relates to how well a certain software architecture can adapt to changes in its requirements.

Let me give you an example. Suppose I have a software product based on a relational database, say SQL Server or Oracle, and due to a high increase over time in the volumes of data it uses, it might be a better solution to move to a non-relational database, perhaps MongoDB. Quite often these requirements are yet unknown when the project first starts, but only surface much later, most likely after the product went in to production.

A product’s software architecture could be called agile if a transformation from one data source to another can be achieved quickly and easily. If the interface to the database is abstracted out nicely, such a transformation is much easier than if the code contains thousands of references to the actual database and queries build up in strings all over the product – a situation I had to deal with in a project fairly recently. This software architecture is not very agile, I would say. Dependencies will kill you every time. So the right level of abstraction, in this case a simple API to deal with all database interaction, could help enlarge the agility of a software architecture.

Another interesting aspect to move more quickly and easily is the testability of the software product. If your code base is thoroughly (unit and integration) tested, preferably automated, you might suggest that it is easier to change the software architecture. If the fore mentioned project would have had reliable automated tests, we could exchange one database for another with more trust. Unfortunately it didn’t have many automated tests.

Can we do architecture in an agile way?

The second quality, frequent reassessment and adaptation, in my opinion largely deals with the ability to constantly improve your architecture over time. This ability is often referred to as evolutionary architecture. Although many people still believe that you should set up your architecture completely prior to the project, in this age of ever-changing technology, changing requirements and growing insights, especially in agile projects, I find that hard to believe. At most you are able to set up an initial architecture, define layers and concepts, and perhaps the paradigms that enable your architecture, such as domain driven design. You can visualize you initial architecture – and all the rest, in my experience, needs to grow from there.

So yes, when you dive into a microservices architecture, you will be able to state that your components deliver RESTful services over HTTP, but it takes a while before you figure out how to best do this. It takes trying out, finding some frameworks to help you, make mistakes, learn from those, and only eventually you will have a suitable implementation. There’s a three step strategy that illustrates quite well how I preferably let my architectures evolve over time:

• First do it. If you don’t have any experience in a specific technique or technology, just try it out. Just write the code that does the job. Simply make it work.
• Then do it right. After you’ve done it a couple of times you will see some patterns emerge. Code that is handled the same way in multiple places. Once you start recognizing these patterns, you will be able to create cleaner code, or a nicer API. Implement it and refactor the handcrafted code from your first tries.
• Then do it better. Once your API is used for a while, you will see further improvements and you can build these into your API.

I guess this also answers the second question. Can we do architecture in an agile way? There is no other way. With new technology, which is almost unavoidable in projects, you will not be able to set it up and write code to it in advance. You have to do architecture agile. You will learn from what you do, and learn how to do it better continuously. Your architecture is evolving all of the time.

Do architects code?

That brings me to another question also quite often posed to me, and waiting to be answered. Should architects code? Yes, I’ve heard all the arguments that there are two types of architects, those who code and those who don’t code. And yes, architects who don’t code always come up with the argument that the necessity to code all depends on the type of decisions you are making as an architect. Again, It’s a question of taking the red pill or the blue pill.

“You take the blue pill, the story ends. You wake up in your bed and believe whatever you want to believe. You take the red pill, you stay in wonderland, and I show you how deep the rabbit hole goes.” – says the quote. In my opinion, architects do need to take the red pill. You need to know how deep the rabbit hole really goes. In this age where code is al around you, and new frameworks pop up on a daily basis, there is no way an architect can just draw some boxes and lines on a white board or a PowerPoint slide and call the rest implementation details – I’ve seen architects literally do this. Over time, not coding will diminish your credibility with the team. You will need to know what the consequences and implications are of you decisions, both functional and technical.

Don’t become the well-known ivory tower architect. A simple box on a PowerPoint slide can be a hell to implement