Software rules the world, everyone is aware of this. And along with it people say, Software is easy to change, easy to create, easy to adopt, etc. Still Software is often hard to understand. For both individuals and teams, having a common understanding of the architecture of software makes life easier to evolve the software to be faster, cheaper, and better. Over the past two decades I had the opportunity to work on several large scale systems. I also had the opportunity to start new projects from ground up and advice early startups with their software journey. During this process I had evolved a systematic approach and principles for crafting software. In this series I will write more about this.
It is easier to visualize the software structure using the analogy of building a house. At the start we often talk about a house having a set number of bedrooms, bathrooms, kitchen and additional rooms. Next the building architects talk about interconnections between the rooms. Finally they consider the materials to use and specific dimensions to apply for the rooms. In a similar fashion think of software architecture to be composed with three separate structures: Conceptual Architecture, Logical Architecture, and Physical Architecture.
Conceptual Architecture
Conceptual Architecture provides a simple to read and understand view of the software systems. It is the easiest place where the business and technology people can meet easily and share a common ground. I often start with an inquiry of who the users are and what functionality is of interest for each user group. Usually this is drawn as a simple set of boxes illustrating the major building blocks. In the simple Ecommerce website example we start with two building blocks respectively for the frontend and the backend.
Logical ARCHITECTURE
On further investigation, we can identify the detailed building blocks logically required for engineering the software. The result is the Logical Architecture that captures information about layering and sub-systems or components. The layered diagram illustrates the hierarchical dependency relationship between components.
Typically I would like to start with the user persona at the top, include biz logic and middle tier, local data, and then end with shared data + external partner services at the bottom. Lines showing dependencies are important to illustrate the connections. However I often omit the lines to keep the picture less cluttered. It is useful to identify and use consistent and good names for the components to help us in developing ownership and depth in the next phase.
Physical ARCHITECTURE
The third and most important stage is to describe all the different parts required to build the system. At this time we detail out the various aspects required for building, running, managing, and evolving the software. There is no single physical architecture picture. Often it is best to consider each aspect separately and annotate accordingly. The aspects to consider include:
- Source Code Layout
- Binaries and Software Packages built out
- Cloud and Network Topology / Dependencies
- Exact components to use (ex: pick Amazon RDS as the database of choice)
- Monitoring of the services
- Ownership boundaries
- Security Access Controls (ex: use IAM API keys, specific roles to use, etc.)
- API contracts and conventions
- Data Models to use, etc.
Getting Started
Above provides a quick glimpse of how to approach software architecture. No software system is perfect and always every piece is evolving with time. Some systems have better approach with documentation and most do not have documentation. Often documentation has been considered as a chore, which I disagree. Rarely do people want to buy a house without house inspection. In a similar sense when one picks up a new project it is useful to do a software inspection report to get caught up on what the reality is.
Equipped with a set of simple and solid pictures, one can make traction towards better ownership, evolution, and shaping of the teams and technology for the future. In the future articles I will write more about these.
Leave a Reply