We are evolutionary architects
On our ToThePoint business cards, you won’t find many different roles and fancy titles.
We simply like to think of (and label) ourselves as evolutionary architects.
What is evolutionary architecture?
It is our mission to create evolutionary IT so that members of our society can focus on the things that matter to them the most.
This means when you see a Pointer walk in, you know things will get done right.
To reach a point where you know things will get done right, you’ll have to be able to deliver evolutionary architecture.
This is guaranteed by making sure we have evolutionary architects in our ranks that are able to deliver future oriented agile products.
The true meaning is twofold
We believe one grows in what one does best, as widely oriented as possible whilst keeping a future-oriented technology agnostic view on solutions.
Let’s say you have 10 fabric weavers
– 2/10 are considered the lead weavers,
– 2/10 are exceptionally good at their job,
– 4/10 are mediocre
– 2/10 are not all that good but do no harm and hop along.
Now imagine that those weavers are led by a division manager. If one day, that division manager retires and is to be replaced by one of the team members, who would you pick as his replacement?Most companies will probably look to the 2 lead weavers and the 2 exceptionally colleagues. And pick one of those 4 as the new division manager.
While it might make sense to you, we actually consider this a mistake. Being a good weaver doesn’t necessarily make you a good manager (although it arguably helps).
What is for sure, though: you will lose a damn good weaver.
Now consider a weaver, being trained, from the beginning, to become a division manager, and to look at the bigger picture. Faced with the same decision-making task in that scenario, makes your task a lot easier, doesn’t it?
The idea is to specialise in the art of weaving and its principles instead of just bogging your head down and weave like there is no tomorrow.
Whilst you are undoubtedly working very hard to learn weaving all kinds of fabric — you should also try to look over the wall as soon as possible. Ideally you should try to grasp the underlying principles of weaving and to decouple those principles from the underlying technology and as such evolve to becoming an evolutionary architect.
Inso-doing you’ll become someone that truly understand the guiding principles and knows how they can be implemented. You’ll become an evolutionary architect that knows why the guiding principles are used in certain scenario’s and better left alone in others. An evolutionary architect that is guided by those principles can look at the guiding principles in a technology agnostic context.
The evolutionary Pointer is someone that truly understand the guiding principles and knows how they should be implemented. They know why those principles are used in particular scenarios and why they better be left alone in others. An architect is guided by those principles but able to look at them in a technology agnostic context is fit to be called ‘evolutionary’ by our book.
Business domains, technology, people, the world in general, they all evolve. We like to make sure we build architectures that are capable to evolve with the world around them.
How neat, cool, elegant and accurate your architecture is today, it will probably need to change sooner or later. As such, an architecture should be able to cope with incremental changes at any of its dimensions, whilst refusing to break down completely. This enables gradual and fine-grained evolution. Put another way, an architecture that can embrace incremental changes by design deserves the evolutionary label in our book.
One way if achieving this is by designing a microservices architecture. Advocating a modular, loosely coupled approach to design and by definition adhering to every principle of an evolutionary architecture.
At ToThePoint we are particularly fond of the concept of Domain Driven Design since it pushes the concept of compartmentalisation even further and embraces the fact that there is no one domain model to rule them all.
Splitting up business domain models and accepting the fact that they evolve differently is one small step in your mindset but a huge step in the right direction for your architecture to actually become evolutionary.
A design using microservices with a clear API, used as a contract to the outside world, is less likely to break stuff when its internals change.
Because it is designed to evolve in a granular way, whilst disrupting as little other microservices as possible (a technique like consumer-driven contracts can greatly improve resilience to interface changes).
Designed this way any microservice can scale and evolve independently from other components in your architecture. In our experience, that is a great place to find yourself in.
Three important effects
Making things evolutionary brings a couple of advantages with it. One could argue that some of those effects are actually needed ingredients, instead of happy side-effects. For instance, you can adapt a DevOps culture, with continuous delivery and deployment principles and most probably drastically reduce time to market. Is adapting a DevOps culture a happy side-effect or is considered a sine qua none?
One of our Pointers regularly states that when something is hard or truly hurts each time you have to do it… the only right reaction is that you just have to do it more. You’ll get better at it. Until you get tired of it and start automating stuff. In other words, bring the pain forward! Did I already mention here that setting up delivery pipelines is another one of those principles, advocated by an evolutionary architecture? Thought so.
Another, typically undervalued, advantage of adhering to an evolutionary architecture is the fact that decisions can be postponed to the last responsible moment, and that they surely don’t need to be taken up front. Postponing a decision to when it’s absolutely needed is usually a really good idea, because there will most probably be more (and more detailed) information available to take into account.
Documentation is another of these heavily opinionated topics. Traditionally, architects tend to resort to modelling tools, producing a series of diagrams for each and every piece of design, arguably stating the obvious in many of them. We have our own (strong) opinion on this as well: we adhere to the concept of living documentation, gathered in an utmost agile way, preferring photos of whiteboard drawings over using modelling software.
Evolutionary architect in a nutshell
Anyone recognising the fact that by the time a pretty architecture picture is implemented, the world most definitely has evolved, and assumptions made might be worthless (or less worthy at least). Embracing the fact that your architecture is not static but can evolve by design is critical.