Guru on Rails

if you don’t sacrifice for your dream then your dream becomes your sacrifice.
Sydney, Sat 01 Jun 2019
Introducing evolutionary architecture
Wed 30 May 2018

Have you ever heard "Software Architecture"? So what is this? Software Architecture is simply Architecture of Software. What's inside your ecosystem and how they interact with each other.

There are many things in a software. Architects need to examine what is the importance and balance all of those things.

At the initial project timeline, Architects have to understand business and requirement. As a Software Architect we need to identify the architecture concerns.

accessibility efficiency usability flexibility learnability maintainability mobility predictability rliability resilience
reusability safety scalability securability stability testability        

These "-ilities" are the most important in building software. In fact we won't achieve all of them because many factors oppose one another. For example "high performance" and "scalability". Scalability goes deeply to ways of organizing code, components. Sometime we need to sacrifice a thing to get another such as the speed and quality. Nowadays, startups usually want to implement fast so that they skip automated test. However, automated test is the factor making system reliable. 

We start a project easily at the initial timeline and getting hard to manage and implement at next few months. Despite our best efforts, our project becomes harder to change over time. It's because of a variety of reasons, occurring outside the control of architects and long-term planners. Change is the improvement and the characteristic of everything so that we can't avoid change but we can exploit it. We cannot predict chance but we can architect our systems knowing the technical landscape will change. For example, we can apply polymorphism to model in order to expand later.

We should build architectures that have no end state, keep evolving in the future. We focus on time and change relation and building a component to protect architectures, make it as continual architecture. As we all know, changes are multiple dimensions. we build a system supports incremental change across these dimensions.

There are two aspects of software architecture: development and deployment. Day by day we have tasks, we make changes over and over again. We might just make a small change. For deployment, it requires the modularity and decoupling for business features. 

Let's go through microservice architecture. We have first service for checking equipments. We have second service for getting vessel schedule in order to know when vessels come. Worker will go to check the equipments. We deploy two services independently. First service is still alive even second service died for any reasons. 

Because of incremental change aspect, we need to protect the important characteristics across multiple dimensions. Thus, we have to build a kind of function that we call it "fitness function". This function will guide changes. The fitness function encompasses a variety of mechanisms, including automated test, metrics and some kind of manual test. I just mentioned about multiple dimensions, that is the "-ilities". That's also called architectural concerns such as techniques, security, data, operational system etc. In order to build evolutionary architecture we need to determine and think about how system evolves across these dimensions.

Fitness function - principle of evolutionary architecture.

As we discussed already above, in order to protect the important characteristics of architecture, we need a solution. So how? That's fitness function which preserves these important things. However, we have multiple dimensions so that we should build a bunch of fitness functions, each one corresponding with a dimension. However, automated checks may be preferable but some parts may not be implementable. In this case, manual test is still useful.  Thus, we have two kind of fitness function, they are test and metric. But in test, we have automated test and manual test. Need to remember that fitness function may be a test but test doesn't mean the fitness function. In order to distinguish fitness function from other kind of test we rely on the definition that fitness function protect the important architectural characteristics. It depends, if our purpose is protecting the coding standards. Thus, we implement automated test for testing the coding standards for every time developers make changes. In addition, fitness function made by manual process I meant here including tools for testing as well.

We may take these risks if we don't identify the fitness function early:

  • Making the wrong design choices.
  • Making design choices that cost time and money but unnecessary.
  • Not being able to evolve.

Incremental change

In fact, when we say about evolutionary architecture that we're implying incremental changes. We're not talking deeply about how to build an architecture. But we're talking about how to make it easy to evolve our ecosystem. Evolving our ecosystem without breaking any important architecture and avoid downgrading it. Thus, time and changes will be going together.

There're two aspects of incremental changes. They are development and deployment. For development, it's easy to see that we make changes every day. Adding new features, fixing bugs, modifying based on requirement changed. For deployment, it's similar to CI - continuous integration. CI encourages to automate our project, a kind of deployment pipeline, listening for changes and automatically run to verify and deploy. It also encourages developers to split tasks into stage. Thus, every time developers make change, CI tools listen on it and automatically get code, building, testing and deploying so that developers always ensure that the changes deployed to production on an ongoing basic don't break things. For instance, it's similar to what we do every day such as making changes, performing tests, if test results are ok, we deploy to server. But now we do it automatically. We can fan out to test, making many pipelines and then fan in to deploy to production.

Architectural coupling

Talking about evolutionary architecture, we talk about how to make it easy to evolve? We noticed that if thing is small and independent, thing will be easy to manage and change. Hence, we have two concepts "bounded context" and "coupling". Speaking of bounded context, it's kind of separation of context. We bound or group things in the same context. That is how things can implement details, allow to know anything inside, ask it a question to get answers.

 

If we want to know something about Marketing Context, ask it. It's easy to see that it's like single responsibility in design pattern. We bound contexts and make them independent is the idea. However, it's hard to make them independent completely. Thus, we have coupling concept. We bound contexts, making modules so that coupling proving the way modules communicate to each other.

The evolutionary architecture always associates with time and change. In order to make it easy to evolve, we need to decouple mechanisms such as contexts, modules. We also use fitness function to guide changes, protecting the important characteristics.