Software architecture vs software design 

The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

– Clements, Bass,

Kazman 2012

Software architecture is the foundational element of software design. So what’s the difference between them? Software architecture and design in software engineering can be likened to that of conventional architecture and design of buildings. When designing physical structures, the architect creates the concept, while the designer (or engineer) works out the specific details required to actually make the project happen. The architect is concerned with the ‘big picture’ questions about what the project is, how it will look, what its function is and so on, whereas, the designer/ engineer is concerned with how to make the architect’s ideas work.

Design – Implementation

The software architecture is all done before any of the actual coding begins.

It is developed with the project’s mission or goal in mind, and serves as the basis for the rest of the design project.

Software design is all about how the software architecture can be implemented into the overall system. This involves:

• Coding
  
• Using specific design patterns
  
• Choosing classes, interfaces, functions and responsibilities
  
• Working with specific components and modules

Software architecture: A closer look

Every software project will have a brief, and the software architecture is the first step at bringing that brief to life. Some key functions of software architecture include:

• It helps stakeholders to visualise, understand, and analyse a system’s qualities.
  
• It focuses on the structure (rather than implementation).
  
• It can be used to anticipate expensive choices in a project before they’re made.
  
• It is used as the basis for making core decisions to ensure high-quality work.

Software architecture is concerned with context, which can be split into three main areas:

1. The functional requirements:
   – What should a particular system do?
   
2. Non-functional requirements (the ‘ilities’):
   – Functionality
   – Reliability
   – Usability
   – Efficiency
   – Maintainability
   – Scalability
   
3. Restrictions
   – Legal requirements
   – Standards
   – Cost
   – Time-to-market
   – Talent hiring

Software architecture allows teams to make decisions about the project by analysing the approaches they’ve taken and determining whether they will result in the desired solution. This saves time and money because the team will be able to anticipate potential issues before actually having committed significant resources to its coding and development. This increases the project’s agility, minimises its risks and serves its stakeholders effectively.

Common software architecture structures

When we create a new building, we have to make choices about which materials to use, what kind of foundation to build it on, which style to use and so on. Software architecture is no different. There are quite a number of ways that architectures can be structured and patterned, with some more popular than others. Here are the two of the most commonly used patterns:

1. Layered pattern architecture

This database-driven architecture is probably the most common approach as it is a great way to store information effectively in tables. It has been used for some of the biggest software frameworks like Express, Java EE, and Drupal. In a layered approach, the data begins at the top layer and works its way down until it reaches the bottom (which is typically a database). As it descends, each layer has a different task which focuses the data and solves issues such as reformatting the values.

2. Event-driven architecture

This approach is agile and with high performance. Large numbers of programs spend the majority of their time waiting for an event to occur (such as a human using a computer). It is built around the idea that sometimes data will need to be processed, and other times it won’t. This is managed through a central unit that processes all the data sent to it, before delegating them to the relevant modules.

Where a layered architecture will pass data through all levels, event-driven architectures will only send the data to the appropriate location; hence, why they are considered highly efficient. This architecture is great at adapting to complex environments. It can be scaled easily and extended if new event types are used. However, testing can only be done on individual modules if they are independent, otherwise, they will have to be tested in a fully functional system. Error handling can be challenging to structure if several modules are handling the same events.

The challenges

Software architecture does have its limitations, which must be considered carefully throughout the development process. If you fail to identify risks and problem areas, you could potentially make errors in your choice of priorities, and you might fail to manage trade-offs. These could all lead to delays in delivering the project, more significant costs, or even a complete failure of the project itself.

As software architecture is still a relatively new discipline, there can be a lack of tools available to companies to use it. The architecture is yet to be ‘standardised’, which can cause disparities between projects and companies. Analysis methods for predicting whether an architecture adequately meets the implementation needs are not always developed enough to create a reliable result.

Lastly, the concept of software architecture is not always understood or valued enough by companies or their stakeholders. This can result in a lack of awareness of its importance in software development, and a lack of understanding of a software architect’s role in the design process as a whole. These can all lead to errors in the processes along the way, higher costs, and overlooking potentially critical issues.

Good software architecture practices

In order to minimise the risks and limitations mentioned previously, good practises must be put in place from the outset. Some essential practises include:

• Keeping comprehensive documentation of all aspects of the architectural design and their interrelationships with other aspects of the project, as well as the goals or functions they should achieve.
  
  
• Implementing a system of regularly evaluating the architecture to determine whether it’s achieving its purpose. If not, then actions can be taken to rectify the problem before it becomes a critical issue down the road.
  
  
• Continuously analysing the system to ensure that it is conforming to the intended architecture type.
  
  
• Putting systems in place at every stage of the architecture process to maintain quality assurance of the system’s tasks, goals, and outputs.

If these points are carried out effectively, it will allow software architects to make accurate predictions about a product’s quality and make good, informed decisions. There will be fewer problems down the line as they will be flagged at a much earlier stage.

Summary

Software architecture has become an integral part of software engineering and design. Done well, it can save companies and their stakeholders enormous amounts of both time and money. It predicts how and where issues may occur, and how to solve them before they even get implemented. Now is the perfect time to get up to speed on a function that is no longer emerging; it has emerged.