Skip to main content

Architecture

Introduction​

Blueprint Icon

In many ways, software architecture is like the blueprint of a building. It is the high-level design that defines the structure of a software system. Just as a blueprint provides a detailed plan for constructing a building, software architecture provides a detailed plan for constructing a software system.

In waterfall development this process takes the form of some sort of system design phase that occurs between the requirements gathering and implementation phases. In practice, any design will need to adapt as the implementation progresses, but it's still beneficial to have a high-level plan to guide the development process.

What is Software Architecture?​

If you ask software engineers to define what the architecture of a system is, you'll get a variety of answers. Some will say it's the high-level design of a system, or the way that components interact with each other. Others will say it's the structure of a system, or the way that the system is organized.

These definitions fail to capture the essence of software architecture. I prefer this definition:

"Software Architecture is the shared understanding that expert developers have of the system."
-- Martin Fowler

This shared understanding is what allows developers to work together effectively, and to make decisions that are consistent with the overall design of the system. If all contributors to a project understand which parts of the system are critical, which parts are flexible, and which parts are likely to change, they can make better decisions about how to implement new features or fix bugs.

One important point to note, any shared understanding of a system is only ever a snapshot in time. As the system evolves, the shared understanding will need to evolve as well. This is why it's important to have a process for updating the architecture as the system changes.

Software Architects​

Many organizations have a role called "Software Architect". In some organizations, this role is just a way of describing a senior engineer. In others, the role implies that the architect has some influence on the overall design of the systems being built and how they will interact.

The exact responsibilities depend mostly on the seniority of the architect and the size of the organization. Some common subsets of this role include:

  • Application Architect: Guides the design of applications and communicates those designs to the development team. This is the type of architect that most developers think of when they hear the term "Software Architect".
  • Systems Architect: Design systems at a step higher in complexity. They work with interrelated sets of technologies and applications.
  • Domain Architect: This might be a specialist in a specific business domain, such as finance or healthcare. It might also be a specialist in a technical domain or stack, such as cloud computing or mobile development.
  • Enterprise Architect: This is the highest level of architect, responsible for the overall design of the organization's systems. They are responsible for ensuring that the organization's systems are aligned with its business goals. This is the role that business leaders think of when they hear the term "Software Architect". Many organizations don't have this role, but it's common in large organizations.

Objectives of Software Architecture​

Having a clear system architecture has a number of benefits:

  • Guide Development: A clear architecture provides a roadmap for development. It helps developers understand how the system is organized and how different components interact with each other. Major refactoring tends to be less likely when the architecture is clear.
  • Facilitate Communication: A clear architecture helps developers communicate with each other. It provides a common language for discussing the system and helps developers understand how their work fits into the larger system. It also helps guide communication with stakeholders. The right diagram can help a non-technical stakeholder understand the system at a high level.
  • System Analysis: Architecture diagrams can help identify potential problems in the system. For example, a diagram might show that two components are tightly coupled, which could lead to problems if one component needs to be replaced. It can also help to determine if non-functional requirements are being met.
  • Large Scale Reuse: A clear architecture can help identify components that can be reused in other systems. This can save time and money in the long run.

Conclusion​

Software architecture is a critical part of the software development process. It provides a high-level plan for constructing a software system and helps guide development, facilitate communication, and identify potential problems in the system. A clear architecture can help developers understand how the system is organized and how different components interact with each other.

Image Credits​

Architect icons created by Taufik Ramadhan - Flaticon