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?
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.
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:
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.
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
17 en 18 mei 2017 Praktische tweedaagse workshop met internationaal gerenommeerde spreker Alec Sharp over herkennen, beschrijven en ontwerpen van business processen. De workshop wordt ondersteund met praktijkvoorbeelden en duidelijke, herbruikbare r...
1 juni 2017 Iedere organisatie heeft te maken met het integreren van systemen en applicaties. Maar welke technologie zet u in bij welke vorm van integratie? Guy Crets bespreekt de verschillende oplossingen voor integratie. Integratie van IT-sys...
13 t/m 15 juni 2017Driedaagse workshop over requirements management door James Archer. Opstellen, testen en ondubbelzinnig vastleggen van requirements. Unieke driedaagse workshop over requirements management op basis van de Volere methodiek door Jame...