Written and compiled by Ian Segers as personal guide for his job as Solution Architect. In case you are reading this directly on GitHub, you can read this Markdown rendered on the GitHub Page. This is a static website which gets easily cached. To make sure to have the latests contents, do a hard refresh (CTRL + SHIFT + R for chrome/brave/edge).
Many definitions exists out there, but I like to inspire my definition on Systems, from the field of Systems Thinking.
Software architecture is everything that matters about the architecture and design of information systems. whatever that might be.
Before we further explain what that exactly might entail, it is important to first understand what are systems.
A “system” in systems thinking is a set of interconnected elements, which can be subsystems in their own right, organized within defined boundaries. These elements function cohesively to achieve a common purpose or produce specific outcomes, influenced by the system’s structure and internal interactions.
Here can find a detailed breakdown of the definition.
A system can be as simple as a bathtub. The bathtub holds water, there is a faucet that allows to regulate inflow of water, and there is a drainage pipe that allows for outflow of water. There are interconnected elements, and they produce a specific outcome (e.g. fill up the bath tub) based on the systems’s structure and internal interactions (open the faucet, close the drainage).
An example op an adjacent system would be the sewage system. The bathtub system and sewage system are inter-connected. The defined boundary of the bathtub system is the faucet, tub, and drainage pipe. The defined boundary of the sewage starts from the drainage pipe and ends at the sewage filtering station.
The bathtub system and sewage system are both part of a larger overarching system called the water supply and sanitation system. Making the bathtub system and the sewage systems subsystems of the water supply and sanitation system.
Yet again, the bathtub system itself can have multiple subsystems. The faucet for example can be examined more closely, and be considered as a (sub)system in its own right again, detailing the internal workings of the faucet.
Notice that a system is not just about how it is structured. There is also a time aspect to this, how does the system behave over time? How does that behavior change as we interact with the system? (e.g. close the faucet, open the drainage, …) This is what we mean with “these elements … produce specific outcomes”.
With Information Systems we can look at it in the exact same way. An organization can be seen as one large IT system - with each component in it - being a system in its own right (e.g. a webserver), producing specific outcomes and behavior. This comes with a defined boundary (e.g. all the on-prem systems of the organization). All these systems are interconnected, facilitating communication between and within (sub)systems. Data being the content that is communicated over these interconnections or lives within components.
This means that one can “zoom in” on any component of an information system and look at it’s internals, exposing potential another subsystem. However, for ease of reasoning about a system diagram, we don’t expose the details of any subsystems, based on what the diagram tries to communicate.
Information systems also have a time aspect, it’s not a static snapshot, the system over time produces certain outcomes.
A system has defined boundaries, and that’s what we do also with information systems. An information system has defined boundaries, detailed what components are part of it, some might use “scope”. These boundaries or scope usually encompass a “domain”. A domain is a name or term that indicates on what premise the scope or boundaries of the system are defined. This could be a business domain (e.g. Marketing) or a technical domain (e.g. Database Layer). In this handbook we refer to this as Technical and Domain partitioning, telling on how we define our boundaries of our systems(s).
Domain-Driven-Design (DDD) has a concept of “Bounded Context” that is meant to aid in defining your domain, which should indicate how the boundaries are defined.
See Topic: Laws Of Software Architecture
When “doing architecture” as a software architect you should:
This handbook is from my experience and many materials that I have read. My intention is to clarify on every topic I cover my sources that I have used, it can be in my own words, it can be sometimes copied from any of my sources. My apologies if I failed to do so, please contact me (via a PR on this GitHub Repo, great for transparency) if I did fail to do so. I obviously don’t take credit for when I quote source material and you should proceed with caution if you want to reuse these.
Here you can find my raw todo notes on all topics that I plan to address in this handbook.