Best Practices of Software Architecture

What is software architecture? The term “software architecture” is analogous to the term “building architecture” – but rather than representing the fundamental internal structure of a building, it is related to your application. 

Just as the architecture of a building depends on its purpose, (for instance, a residential building and a factory are erected with different internal structures and appearances), the choice of software architecture is also determined by the purpose of your project. Choosing the right architecture of software can reduce initial development time and cost, optimize maintenance expenses, prepare a system for extensions, make it reliable and secure, and will generally help to avoid any potential problems.  

On the other hand, the poor architecture of software can cause most of an application’s unexpected problems. In the following article, Intetics experts will introduce you to the basics of best architectural practices and share tips on how to decide which ones suit the needs of your business.  

Software architecture includes defining and structuring a solution that meets the technical and operational requirements of the project. 

What to Look for While Picking the Right Software Architecture 

The influence of software architecture extends throughout the whole lifecycle of the project. Let’s analyze how it changes from stage to stage. 

Reduced Development Time 

The very first outcomes of your architectural choices can be seen even before the first line of code is written. The project structure will directly influence the difficulty of finding new developers for the job or keeping existing employees. Progressive architectural decisions will make the development team more stable, but you will have a lower number of qualified specialists to choose from. It also will decide how much time and resources your team will need to carry the project to the production stage.

 In a short word, your architectural choices must be popular. This principle also guarantees that you will have support from the big development community, a broad choice of plug-n-play libraries, and a rich pool of technical and training information.

However, you must always keep an eye out for architectural solutions that result in successful real-world projects. Some ideas for software architecture are widely discussed but rarely applied, resulting in a lack of proven knowledge and real success stories. The amount of successful applications of given architectural concepts results in well-known metrics that allow you to evaluate your project during its entire lifecycle. 

Here is a real-world example: with the start of the COVID crisis, a big online educational platform decided to make huge changes in their application architecture and implement some experimental practices. As a result, when they shared their plans with the development department, it became clear that the team is not ready for such changes. Most people left the company:  only some of the newcomers remained. To make a migration, they had to put together a new team.

Scalability and Evolvability  of the System

Scalability is the term we use to describe a system’s ability to cope with an increased load. An application’s architecture influences how easy it will be to expand the underlying network infrastructure to handle more requests from users.

A well-known example of scalability pitfalls can be found in the early days of Twitter. At the time, the platform was unable to handle real-time feed updates when a user with millions of followers published a new tweet. And even nowadays, Twitter applies a separate algorithm for handling tweets from celebrities to deliver a smooth experience for all users.

Also, remember about evolvability – the possibility of quickly adding new features or changing existing ones. The right architecture allows you to easily select and add needed components, such as libraries, and to connect external services or entire new blocks to your application. You should always be able to add a new component without re-arranging the whole system.

High Reliability and Stability 

There are many factors that decide how reliable and predictable your application will be during its production lifetime. Thinking about them while designing an application architecture might save you many hours of sleep in the future:

1. Hardware faults – as all things come to an end, hard drives die with databases on them. Were these databases backed up? And what if the power supply took down an entire server – how fast and easy will it be to replace it? The recovery process will depend on many aspects of your application architecture – how quickly you will be notified about failure, how much time deployment and configuration of the new system will take, how easily you can redistribute the load from the dead piece of hardware, and so on. All scalability problems will definitely show themselves once hardware failure occurs. 
2. Software errors include bugs from new updates and unexpected errors in your code or libraries that are used in your project. Recovery from software errors depends on the evolvability of the system. How quickly can you address the bug in certain parts of the application? Will a small error inside an insignificant module take down a critical part of the project?
3. Malicious actions can cause all kinds of problems with both hardware and software. Reliable software architecture should include not only preventive mechanisms to stop cyberattacks from happening, but also have some recovery plan in case part of the system gets infected.

Minimized Support and Operating Costs 

The production stage of the project lifecycle inevitably brings to the table some recurring expenses that are only meant to keep the system running. Different architectural choices have a significant influence on the resulting monthly payment amount and can both pleasantly surprise you or drive you to bankruptcy. 

Operating costs contain expenses for hardware (rent or power bills) and paid subscriptions for external services. To cut some of them through architectural decisions, you might want to revisit questions like “Do we need all of these X servers running all the time, or do we want to use them on demand?”, “How do we get more performance from a piece of hardware?”, and “Do we need a subscription to the service X, or can we use some cheaper or free, open-source solution?”

Support costs include many more aspects – how many trained specialists do you need to maintain the project and how many of their routine tasks can be automated or accelerated? A lack of transparency and simplicity in the system will create roadblocks in daily workflow and will result in ineffective time spending for your employees. 

Most Common Architecture Types 

Below are the two most widely recognized architectural concepts. The division into types is conditional; in fact, in one project, you can use hybrids of these types or several types at once.

1. Monolithic Architecture

The application acts like an inseparable entity – it is deployed as one, and all functions go live and power down as one. Taking out one part of it and trying to run it alone is usually impossible. However, the modules inside it are often divided according to their technical or business purposes. 

It is one of the oldest known software architecture concepts. Most of its weak points and potential flaws are well-known and its overall structure is pretty simple compared to more distributed systems. Monolith architecture is relatively easy to understand from infrastructure, security, and CI/CD points of view. However, the monolithic approach decreases the development velocity and usually offers poor scalability and evolvability of the application.

2. Microservice Architecture

In the microservice approach,  the structure of an application is viewed as a collection of individual programs (microservices) that are independent of each other at the code and often network level. This concept offers top-tier evolvability and scalability. Most components of the application can be tested and deployed independently. 

On the other hand, the microservice systems are more challenging for developers than the monolith approach. A huge advantage of the microservice architecture is the independency of the components. However, the number one pitfall in microservices development is turning an application into a “distributed monolith” –  when services are independent in theory, but in practice, one malfunctioning part might bring down the whole system. 

This architecture concept implies more thoughtful planning of the development process; otherwise, you might end up with the cons of both monolith and microservice architectures and with the pros of none of them. The typical weak points of microservice architecture are complicated CI/CD processes and network infrastructure, as well as more potential entry points to cover for the cybersecurity team.

There are multiple architecture types like event-driven, service-oriented, distributed, cloud-native and others, that are more narrowly-purposed and contain weak spots or advantages of the architecture patterns above. Any one of them may become a good foundation for your project. What is important is to remember the fact that any successful real-world product will have some hybrid solutions depending on its needs. The goal is to keep your eyes on the prize (which is a project functionality) and find the best structure for any part of the system.

High-Level Architecture Principles as Criteria of Choice 

When thinking about adopting a new architecture, you should consider if it is in line with the 3 high-level principles.

Key Points of Good Architecture 

If we go deeper into software engineering, the right design should fulfill the following functional requirements:

1. The system should be maintainable, scalable, and reliable. 
2. The construction of the whole system should prevent inadvertent mistakes (decreasing the “human factor”). The transfer of data (knowledge in its presentation) should be easy and transparent. 
3. The overall performance should be adequate and in line with project goals.
4. The development team should be able to modify the system within acceptable timeframes.

Software Architecture Principles

Systems of any architecture must be in line with core practices of production software development. Violation of these principles of “good code” will inevitably hurt the development process quality and may even result in a big refactoring process in the future. Here are some of principles explained:

• Separation of concepts minimises the amount of interaction points between internal layers of the application. By drawing clear boundaries between layers, modules, services and other pieces of functionality, you will increase the application evolvability and scalability by a significant margin.
• Single responsibility principle states that each codebase component(function, class, module, microservice) should have responsibility over a single part of software functionality. Divide a complicated business task into a subset of small actions and encapsulate them into separated entities inside the project code – this way you will decrease the influence of possible errors, making code components easy replaceable and reusable.
• Principle of least knowledge states that internal structure of components should be hidden from other parts of the application. This practice ensures that application pieces are not tangled with each other and the whole software product stays highly evolvable.

• Don’t repeat yourself or DRY principle raises attention around duplicated pieces of functionality inside a codebase. Reducing repetition will make a project more evolvable and will mitigate the consequences of potential failures. Utilisation of language inheritance features in pair with abstractions is a great tool to fight redundancy. 
• Minimising of upfront design principle, also known as YAGNI (“You ain’t gonna need it”) warns you about the cost of planning too thoughtfully for too far ahead. To have little to no regrets about unused functionality and wasted time, design only the necessary things. Upfront design and testing can be your allies if the cost of the development process or consequences of failure are very high; however you should always closely expect the necessity of premature design effort.

Any of the above principles are known for generations of programmers as rules of good software design, so there is little to no reasons to intentionally break them, hoping for better results. And even though adhering to these best practices might look like a lot of work sometimes, the effort will surely pay off during the future life of the project. 

Architectural Patterns

The term “architectural pattern,” describes a class of regular solutions to commonly occurring problems. Such a pattern has defined properties and can be reused in several components of the design. Here are widely-recognizable software architectural styles and patterns: 

• Client/Server patterns. The application is based on a server and can support numerous clients. 
• Component-Based styles. The composite design is based on individual pluggable components that can easily be replaced or updated.  
• Domain Driven Design (DDD). Each business domain can feature its own structural components that were written using different languages, including internal name spaces and domain structures DDD facilitates the communication between development team members. 
• Layered styles. The application is diverted into layers that have different functionality, and software engineers can easily distribute their responsibility. 
• Message Bus patterns. The project contains several internal systems that must be able to share data and operate in a unified manner in response to a set of common business requests.  
• N-Tier / 3-Tier / Multi-tier patterns. The application is divided into layers that each carry its dedicated function – like implementing business logic, communication with external services, manipulating data in storage, etc.  
• Object-Oriented patterns. The structure contains fixed classes or objects, and the functionality is based on relationships and interactions between them. 
• Service-Oriented patterns. A single UI is created as a composition of a variety of services. 
• Hexagonal style\ports and adapters pattern. All the business logic is concentrated in one place that behaves like a “black box” in the eyes of the outside world.  The connection between the environment and outside infrastructure is organized through adapters and ports. 

Usage of Frameworks in Your Project

An architecture framework provides you with a set of practices and requirements that are meant to help you to build the foundation of the software system. There are several types of frameworks:

• Software framework is a set of packages that provides a fast and standardized way to build and deploy an application from scratch. It is a reusable environment that has rich community support and a large amount of compatible plug-n-play modules for any means. Many developers are associating their experience with software frameworks, so you will have no problem finding experienced Rails, Laravel, or Spring developers.

1. P-modeling framework is a set of guidelines, methods, and templates meant to streamline the development process. There are many variations of this tool, such as 5-P, 7-P, 10-P and others, and it can be applied outside software development as well. P-modeling framework can become a powerful tool for achieving core project goals – but without proper execution, it might also become additional overhead and a source of wasted time.
2. Conceptual framework is an analytical tool that captures real business goals of the project and the ways of achieving them in the process of building a software solution. It is supposed to prevent you from drifting away from achieving business goals and instead link them to the process of architecture development. 

While making a decision about the usage of frameworks in your project, it is important to keep in mind that any premade set of tools and rules brings its own limitations. Associating your project with one or numerous frameworks allows you to unify development processes, easily access the power of community support, and enjoy the benefits of having numbers of premade libraries and tools for any task. However, you must never drift away from one core principle: framework ways and approaches must align with your project goals, not otherwise. 

Final Thoughts

Software architecture patterns are meant to help you to adopt some common practices, apply trusted solutions, and structurize the internals of the application. It doesn’t mean that you should marry your project with any of the architectural principles and carve in stone “We are doing things only according to pattern X or die.” As your business grows and changes, the architecture of its software products will change too. You might not be able to predict all the possible scenarios and avoid all hidden pitfalls, but remember – your most important duty is to focus on the business objectives. 

Limitations of various development tools and patterns can and must be shaped to align with your vision of top-tier software applications, and we are here to help you. The Intetics team has extensive experience in building custom software projects of any scale – from conception to the production release. 

Author: Into Tesler