Software Architecture Webbings
A general understanding tour of a generally recognised and accepted foundation, loosely tied to the corresponding SWEBOK V4 Knowledge Area (KA), just published in August 2026[1], along with some psychedelic detours from fallen-off-bed concussions.
“And God said: 'Let there be light.' And there was light.” - Genesis
The architecture feeling
It’s not only about the design and construction of physical structures, but it also relates to creating software-based systems, blending traditional architecture principles with software development practices, encompassing both tangible and intangible elements.
It’s the art and science of constructing software with its assortment of concepts, principles, processes and methods.
Software architecture is still software design but with the intent to also encompass software system structures not directly reflected in the code’s structure.
Architecture can also be seen as an outcome describable by a set of structures fundamentally needed to reason about a software system, comprising its parts, the relations among them, and the properties of both, encapsulated in an intelligible representation of a particular computing environment, outward-looking from its own hard and soft boundaries, up to considering people, organisations and whatever else it affects or connects to.
Architecture then becomes itself a thing to reason about, for instance, the measure of how well an idealised system was ported to concrete realisation.
The architectural design of software systems takes place under a specific phase in the software development life cycle (SDLC), typically at inception, followed by wider architecting processes spanning the entire life cycle of what eventually ends up being built.
Meet the concerned stakeholders
Architecting with neatly separated concerns for the sake of their consistency is a noble attempt to match the varied stakeholders’ views on what’s fundamental, such as when it will be ready and how much it will cost, as well as whether a given arrangement of system components meets a set of - particularly big - requirements.
Like requirements, concerns may be classified as functional or non-functional, the latter also addressed as quality attributes, the many “ilities” – feasibility, reliability, availability, usability, maintainability, scalability… disposability.
What is it for?
Software architecture is supposed to give the people stuck with a given system a shared understanding of what’s being designed and built, or maintained on life support.
It also serves as a preliminary conception, a basis to analyse and evaluate design alternatives, or to enable its reverse engineering, which would then be called reverse architecting.
Conway’s law and all[2], a nicely documented architecture can facilitate the ascertainment of the system vis-à-vis some stated purpose along with its fruitful understanding from the identification of commonalities that can be leveraged to account for the variability among interacting components, and turn their underlying concerns into affordances, not hindrances, by neat separation.
Michael Jackson – not the singer – posited that description is at the heart of software development, and that the central theme revolves around the relationship of method to problem structure on one side, and to description on the other.[3]
Hence the value of a tangible representation, especially as it evolves. Architecture descriptions (ADs) – targeted at the concerned – are for some blueprints to guide the construction, and for others a basis to approach the system intelligibly.
Architecture Views and Viewpoints
A view depicts one or more aspects of an architecture that addresses one or more related concerns, which can be logical in the sense of how they make sense from a functional standpoint; process-related as to how the system’s use will take place in an orderly fashion; physical as to where it all can be visited; and developmental on how it can be broken down – not literally – into implementation units along with the dependencies among them and how they’re supposed to be cobbled together.
Accustomly, one view at a time.
Each view incorporates well-defined conventions, notations, and models that should make a properly documented architectural viewpoint. As such, viewpoints are recipes to guide the creation, interpretation and use of architectural views. Common recipes include the module viewpoint that depicts the software at rest, the component and connector viewpoint to express its runtime, incarnated organisation, and live interactions.
You should have a viewpoint with a specific vocabulary or language capable of providing a corresponding view for talking about a set of concerns and the mechanisms for addressing them under the devised architecture.
Architecture styles and patterns
An architectural style describes the macrostructure of a system that follows a particular manner of construction that yields a particular kind of software system’s characteristic features with its own peculiar but universally recognisable overall organisation; picture a Rococo, or Baroque app.
In contrast, an architectural pattern expresses a common solution to a recurring problem within the context of a software system as a reusable, structural building block. In other words, a software pattern is a proven solution to a well-defined problem in a known and previously accounted-for context.
There is no strict dividing line between styles and patterns, as the forefathers, known as “The Gang of Four” – not the Maoist political faction nor the music band – very eloquently stated[4]:
“Design patterns are not about designs such as linked lists and hash tables that can be encoded in classes and reused as is. Nor are they complex, domain-specific designs for an entire application or subsystem.”
As such, architecture patterns, in turn, differ from design patterns in that an architecture pattern impacts the structural aspect of a system, whereas a design pattern impacts how the source code is designed.[5]
Common, well-defined architecture styles are, for example, the layered architecture, also known as the n-tier architecture, and the microkernel architecture, sometimes referred to as a “plug-in architecture”.
When mixed with architecture viewpoints, which provide the language for talking about the various aspects of software systems, both patterns and styles become idioms describing the view elements, their types and instances, and constraints on combining them, in their own eccentric, idiomatic way.
Decisions, decisions, decisions
Architectural decisions, typically made at a high level of abstraction, tend to profoundly affect the development process, notably downstream and up to permanently onto the software system, forming a network of decisions, the ones to follow suit constrained or derived from prior ones.
The architecture rationale captures the grounds of those decisions, their assumptions, the alternatives considered, and the trade-offs involved in the choices made. Keeping records of all decisions, including the ones rejected, will as much prevent further poor decisions, such as ones once rejected and now forgotten, as foster ones worth reconsidering in the face of changes in relevant conditions.
Architecture technical debt is normally incurred from deferred decisions, such as when a software project is pressed for schedule and produces an architecture lacking sufficient modularity; the resulting big ball of mud will generate a ton of debt affecting subsequent development and maintainability, requiring extensive refactoring, hampering future timelines, and possibly introducing whole batches of crippling defects into the system.
Architecture in the context of the software development process
Architectural design can take place in varying contexts under the software engineering process. In more traditional life cycles, it tends to be staged by the software requirements, of which some will be taken as architectural drivers, influencing major architecture decisions.
In some Agile practices, the software architecture is said to “emerge” as a description facilitated by the code itself, based on user stories – not exactly requirements per se – through a rapid series of development cycles, making such emergence a bit less directional.
How does it relate to design, and what the hell is it then?
It can be posited that architecture is design, but at a higher level of abstraction, as it addresses a wider range of concerns that either end up shaping the requirements or even transcending them, particularly the functional requirements. It involves identifying a system’s major components and their interactions in a computing environment, and deciding on the fundamentals while deferring other aspects at lower levels of abstraction.
The architecting process is, itself, iterative, almost Hegelian, comprising concurrent analysis, synthesis, and evaluation under various levels of abstraction granularity, in a setting where one gets to know the ASRs, or “architecturally significant requirements” that describe the design problems the architecture is poised to solve by birthing some overarching system principles from where the candidate solutions are meant to be synthesised and validated as to whether the choice-surviving ones satisfy those ASRs.
Finally, architecting does not occur in a vacuum but in the large, for example in an enterprise architecture, as one player in a system of systems game, bound to be implemented, maintained, and managed, particularly in knowledge management fashion (KM).
"The first matrix I designed was quite naturally perfect; it was a work of art, flawless, sublime. A triumph equalled only by its monumental failure."
- The Architect
"Plan to throw one away, you will anyhow."
- Fred Brooks
[1] Software Engineering Body of Knowledge (SWEBOK) https://www.computer.org/education/bodies-of-knowledge/software-engineering
[2] S. E. Bailey, S. S. Godbole, C. D. Knutson and J. L. Krein, (2013). "A Decade of Conway's Law: A Literature Review from 2003-2012,". 3rd International Workshop on Replication in Empirical Software Engineering Research, Baltimore, MD, USA, pp. 1-14. doi: 10.1109/RESER.2013.14.
[3] Michael Jackson (1995). Software Requirements & Specifications – a lexicon of practice, principles and prejudices. ACM Press.
[4] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1995). Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley.
[5] Mark Richards (2022). Software Architecture Patterns. O’Reilly Media, Inc.
