Software Architecture Fundamentals
Software architecture is the high-impact structure of a software system: its major parts, their responsibilities, and how they cooperate to meet business and operational needs.
itSoftware engineering | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Software Architecture Fundamentals
Software architecture is the consequential structure of a system: the parts that matter, their relationships, and the reason those relationships were chosen. This is not a product diagram wearing a serious expression, nor a list of frameworks waiting to be declared modern. It is the part where a system admits that changing one thing may disturb another.
The job begins with an outcome, a constraint, and a quality attribute such as availability, security, performance, or modifiability. Those words are not decorations for a review meeting. They become a measurable scenario: a named stimulus happens, a particular path responds, and an agreed measure says whether the response was good enough. Without that measure, a favored architecture style is mostly a very organized hunch.
Then come the boundaries, which are determined to use the same word while answering different questions. A responsibility boundary says what work belongs together. A runtime boundary says what starts and fails together. A data boundary says who may change a fact and enforce its invariants. They can line up beautifully, which is pleasant, but they do not do so by default.
The surprise is that separation does not remove coordination. It gives coordination a name, a contract, and somewhere to fail in public. A network relationship needs a request or message shape, timeout, error behavior, compatibility rule, authentication, and recovery behavior. A shared database can tie apparently independent services together with a determination that deserves respect, if not applause.
Use the Intro when the vocabulary and the overall model need room to breathe. Use Slides when the relationships and trade-offs need a compact map. Use the Cheatsheet when deciding which boundary or style question to ask next. The practice reference turns those questions into a review technique, and the exercise asks you to make the structure, failure path, and evidence agree. Architecture decision records keep the consequential choice and its consequences from disappearing when the diagram acquires a successor.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.sei.cmu.edu/software-architecture/
Supports
- Software architecture as consequential structure and relationships
- Architecture evaluation, documentation, and conformance analysis
- Quality attributes and continuous architectural evolution
- https://www.sei.cmu.edu/library/an-introduction-to-software-architecture/
Supports
- Architectural representations for understanding complex systems
- System organization and architectural styles
- https://www.iso-architecture.org/ieee-1471/cm/
Supports
- Stakeholders, concerns, viewpoints, and views
- Architecture descriptions organized around stakeholder concerns
- https://c4model.com/diagrams
Supports
- System context, container, component, and code diagrams
- Audience-focused architectural diagram selection
- https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
Supports
- Architecture styles as constraints with benefits and challenges
- Layered, queue and worker, independent service, and event-driven styles
- Trade-offs involving messaging, latency, data consistency, and operations
- https://doi.org/10.1145/361598.361623
Supports
- Parnas's 1972 information-hiding criterion for module decomposition
- https://www.sei.cmu.edu/documents/3309/2012_017_001_24099.pdf
Supports
- Documented pre-history of software architecture and the 1972 information-hiding milestone
- https://c4model.com/faq
Supports
- C4 model origins, early 2010 diagram names, 2011 naming, and 2015–2016 code-diagram rename
- https://martinfowler.com/articles/microservice-trade-offs.html
Supports
- Operational, distribution, latency, and staffing trade-offs of independently deployed services
- https://martinfowler.com/articles/break-monolith-into-microservices.html
Supports
- Incremental decomposition, operational readiness, and the coupling created by dependencies back to a monolith
- https://aws.amazon.com/blogs/architecture/reinvent-2019-introducing-the-amazon-builders-library-part-i/
Supports
- Timeouts, retries, backoff, jitter, and the risk of magnifying partial failures
- https://docs.structurizr.com/
Supports
- Structurizr's C4-oriented models-as-code workflow and architecture decision record support
- https://icepanel.io/
Supports
- IcePanel's collaborative architecture modeling and audience-specific views
- https://www.archimatetool.com/
Supports
- Archi's ArchiMate modeling tool
- https://sparxsystems.com/
Supports
- Enterprise Architect's repository, modeling, and traceability capabilities
- https://www.lucidchart.com/
Supports
- Lucidchart's collaborative diagramming product
