Evolutionary Architectures in Practice

Introduction

For every IT system in every industry, it’s of paramount importance to build the system with the right architecture that will enable it to meet all functional and non-functional requirements.

The architecture is the foundation for the success of a project, which results in the business’ efficiency success or failure.

Requirements evolve and change over time. Software systems are an investment to help the business and this investment has to be allowed to evolve in order to be effective support for the years to come.

A long, long, long time ago

The very word foundation relates often to the construction of a building. The foundation cannot be changed (easily) after construction starts.

A long, long, time ago the prevailing method was to do a business analysis, then a functional analysis (design) of the system and technical architecture.

There were attempts to set in stone the architecture, which was the guarantee of certain disciplines in the development of complex business systems.

Fixed architecture definition stopped developers from experimenting with new technologies and made them focus solely on implementation of the business logic and user interactions.

But, the fixed architecture was also a source of frustration that limits one’s ability to respond to changes.

No architecture definition can really survive even medium projects which consistently discover new requirements and have changes in priorities; this is to be expected as a normal thing in every dynamic business environment.

Inevitable evolution

The idea of evolutionary architecture comes from the acceptance of the inevitability of changes and to be better prepared for them.

One of the key assumptions is the ability to enable more flexibility and there are modern means to do that.

The typical layered decomposition of applications never provided a lot of flexibility. It must be done all at once or risk an inconsistency between tightly bound services that are connected and/or interdependent. 

Then came the microservices revolution and decomposition in another dimension – vertical.It’s possible to upgrade a technology stack for a given microservices set or module without changing the entire application at once.

This incremental process is the key to evolutionary architecture.

There are also methods to try and assess or measure the flexibility of the architecture (fitness function).

Evolutionary architecture emphasizes at least two dimensions of anticipated changes: technological and business domain model changes.The tight coupling of the components is always an enemy of the architecture’s evolution ability, in all the dimensions (vertical, horizontal), because it makes it harder to isolate and change the different parts of the system.

Get the balance right

It’s not the usual fight of old and bad; ‘up-front’ with modern ‘always adaptable’, which is simplification gone too far. Many of us wish it was that easy.

Architecture is a set of trade-offs when fulfilling one requirement that is affecting other requirements. There’s no such thing as a perfect architecture and we can only aim for an optimal architecture.

Architectures were never set fully into stone, especially in the long projects and product developments. The question is how good the architecture evolution management is: accidental, reactive, under the rug/carpet or open, or a visible part of the development process.

What is the right amount of up-front vs. incremental in your product development?

On the other hand, developers cannot focus on evolving the architecture every single day. It’s the foundation of their work, but actual business related work has to be the priority; like understanding the requirements while designing the best possible components and implementing them.

Let me focus on the absolutes.

Full up-front

A lot of time is spent on designing a tech stack, component decomposition, and all the details.

This really is wrong. In actuality, you should focus on the most important principles of the architecture and the most important technology stack elements.

Is it Java or Dotnet?

Is it AWS/Azure/GCP native or cloud agnostic?

Serverless? Microservices? Modular? Monolith?

Answers to these fundamental questions have to be known before development starts. Experimenting with the key assumptions every day can kill any software project. But, full up-front architecture is something that is just a waste of time.

→ Avenga technology experts on the future of serverless, see the pros and cons and what makes us a reliable partner to talk about it.

Important details

I’ve always hated the term “high level architecture” which too often means to focus on the most important fundamentals and skip the details.

Skipping the thousands of details in the early stage really is a good idea. The details won’t survive too long in the agile development mode as it’s a waste of valuable team capacity.

But skipping important details is something architects cannot afford to do.

Which details are important? The details that can make the difference between project failure and success or between business failure and success.

They are always there. Asking the right questions comes with the experience of previous projects, especially in similar business domains.

Just one example: “Client data comes from an ERP” and can also be editable in the application, while architects assume “there will be client catalogues, as always”. There’s no monotony, nor business as usual, in custom software development.

→  Learn more how we develop and implement your products, and put your ideas into practice with our fast, innovative, and solution-oriented work.

Non-functional requirements

One of the common mistakes is to make wrong assumptions. Like when non-functional requirements were not specified by the client and we pretended that they didn’t exist and we did not address them in the beginning.

There are always performance requirements, scalability requirements, audit trails, authentications and authorizations, and many others.  And they will never be as simple as in your favorite framework of choice.

Being truthful is a good starting point for every architect.

The sooner you face those requirements head on, the better for your system/product.

→ Read about non-functional requirements and what are the pitfalls of using open source to make the solution really capable and fully functional.

Happy flows end with sadness

Assuming that everything will be running well in the system and its environment is unrealistic.  Expecting a happy flow by pretending or solving problems with a simple “just return error code” is totally unacceptable.

Even if your system could be perfect (never), the other systems won’t be.

Paying more attention to the ‘failed flaws’ when it’s a critical part of the system (from the business perspective) is the difference between amateurs and professionals.  Especially with microservices architectures and the curse of eventual consistency. There are many more things you have to address directly and manually.

It’s always easier to discuss how the client purchases the digital products, pays for it and lives happily ever after, but handling all those inconveniences, like a failed payment attempt, the product is no longer available, etc. is often the difference between a great customer experience with business’ success and the “always BETA” product that users will leave as soon as they can.

It adds workload and it adds complexity. And you can run and you can hide, but these problems will get you.

Experience blinds

No two businesses are the same. This rule applies to banks, insurance companies, telecoms, pharma, and any sector.  Companies transform all the time . . . or leadership teams change, both bring new ideas and adjusted priorities.

Experience helps you to ask much better questions, but of course there is never a guarantee that you’ll receive the same answers.

The right amount of paranoia doesn’t help to make architects smile but it always helps to deliver better solutions.

Obsessive scalability

Scalability also requires the right balance. It used to be ignored in the past resulting in hard to fix problems when it was too late.

Now the world seems to be going in the opposite direction. Even the small apps for a limited numbers of users are created as if they were to become another Netflix or Facebook.

Again, you have to get the balance right.

When you think you’re done – you’ve just begun

This is one of the key rules of evolutionary architecture, but it is worth repeating.  The work on the architecture never stops. The question is how many changes will there be, and which changes are required and helpful at any given moment in response to or in anticipation of the changes.

This is very important, especially in the product development process. We don’t want the products to become obsolete either from a business functionality perspective or from a technology perspective.

Here comes the sun

Good evolutionary architectures are possible. We are delighted to be able to deliver them to our clients while helping them to achieve their business goals.

The overall mood of this article is proof of how seriously we, at Avenga, take the architecture of a system that we build and how happily doing this work is in our DNA.

The flexibility of the architecture, in itself, is never a higher priority for us then the adequacy of the architecture to the business and IT problem. Efficiency is always at the top.

If you want to find out what we are doing,  you’re welcome to visit us here.