What architecture actually is
There is no unified definition. The course deliberately starts by comparing definitions from ISO/IEC/IEEE 42010, SEI and others, and asking two questions worth keeping for your whole career:
- Is software architecture a process or a product?
- Which definition is complete or right?
What an architecture description contains, at the level that matters:
| Included | Excluded as "unimportant detail" |
|---|---|
| Elements (VMs, web servers, load balancers, DBaaS) | API signature details |
| Element attributes (scaling, replication, CPU/memory/capacity, VM type/size/image) | Frameworks |
| Interfaces (protocols, APIs) | Internal implementation details |
| Database schemas |
Types of architecture
| Type | Focus | Note |
|---|---|---|
| Enterprise | Business–technology alignment; the right investments, evolution toward a future-state vision | More abstract |
| Solution | A solution to a business problem; business goals come first | More concrete |
| Technical / Software | Core technical architecture with a focus on good design | Deep in one or few technologies |
| Infrastructure | Servers, containers, deployment, CI/CD — effectively DevOps | In some organisations these are called System Architects; the "System Architecture" definition varies |
The three-axis mental model uses strategy focus, technology breadth and technology depth: a technical architect has depth in one or many technologies; an enterprise architect lives at the level of organisational strategy; a solution architect sits in the middle, balancing the two.
Solution architecture is, per Forrester, one of the key methods by which enterprise architecture delivers value to the organisation. Gartner frames it from a different angle: a solution architecture is an architectural description of one specific solution, and a solution architect combines guidance from several enterprise-architecture viewpoints — business, information and technical — together with guidance from the broader enterprise solution architecture (ESA). Comparing solution and software architecture: solution architecture is more business-oriented and the architect's primary responsibility is to talk with the business and achieve their goals appropriately; a software architect can and should focus on software design.
Martin Fowler and Gregor Hohpe's Architect Elevator model captures how this role keeps shifting: architects ride between the "engine room" of runtime and code-level concerns and the "penthouse" of strategy and organisational decision-making, rather than staying on one floor. Their pointed framing — most of what architects have traditionally done should be done by developers, by tools, or not at all — is a useful check against architecture work that is really just documentation for its own sake.
Solution architect activities
RFP/RFI processing
- Translate business requirements into a technical solution
- Client calls and on-site presentations
- High-level architecture design, effort estimation
- Requirements gathering (business needs/strategy, functional, non-functional)
- Levelling applies here too: SA L1/2 for technical parts, SA L2/3 for addressing business needs
Discovery
- Clarify technical and business parts of the solution — technology choice, integrations, analysis of the customer's IT landscape
- Participate in on-site and off-site workshops
- SA is not BA: SA is about breadth and architectural approach/strategy; BA is about depth, clarifying and documenting details
- Typical outputs: design, efforts, timeline
Solution architect involvement does not end once discovery is complete: across the standard delivery pipeline — RFI, RFP, discovery, implementation and support — an SA stays engaged at every stage, not only through the pre-sales phases but through implementation and support as well, even as the specific responsibilities shift from design to validation to steady-state guidance.
Architecture review — a process where architectural decisions are evaluated as to how they enable or restrict the system in meeting its Architecturally Significant Requirements. Its goals are concrete: validate that the architecture can support current and future business goals, assess its ability to meet quality-attribute requirements, detect design errors early in the development lifecycle, and identify potential project risks. In practice it runs as a short-to-middle-term assignment for a small team — at least one solution architect, optionally a delivery manager and a subject-matter expert to clarify requirements, plus developers for prototyping, code review or proofs of concept.
Architecture governance — the practice and orientation by which architectures are managed and controlled at an enterprise-wide level. Mostly an enterprise-architect activity, and a bit outside the solution architect's focus: consistency between sub-architectures, identifying re-usable components, architecture compliance across the enterprise.
Architecture context: the influence cycle
Architecture is not a one-way flow. Four forces shape it, and the resulting system then reshapes all four.
How the system influences back:
- Stakeholder requirements for the next system — the customer can receive a system based on the same architecture more reliably, sooner and more economically than building from scratch, typically with fewer defects.
- The structure of the developing organisation — architecture prescribes the units of software that must be implemented or obtained and integrated; a software module often maps 1-to-1 onto an organisational unit.
- The business goals of the developing organisation — a successful system can establish a foothold in a market segment, and the organisation may adjust its goals to exploit its newfound expertise.
- The architect's experience — every project adds to the corporate and personal experience base.
Alongside these four longer-running influences, every engagement also hands the architect a more immediate set of inputs — requirements, assumptions and constraints — which feed directly into the solution design before it becomes the system. It is worth distinguishing these situational inputs from the four structural influences above: the former change project to project, the latter accumulate over an architect's career.
On the input side: stakeholders each bring their own requirements and concerns; the technical environment grows constantly, and decisions get influenced by trends and buzzwords; the architect's own experience — the styles, patterns and platforms they have tried, good and bad — pushes them to apply prior knowledge to the current system.
Because it is impossible to achieve all things for all stakeholders at all times, finding a trade-off may be the key goal of a solution architect.
Structures and views
Three terms that must not be confused:
- Structure — the set of elements and their organisation (e.g. the module structure).
- View — a representation of a structure, documented per a template in a chosen notation, and used by some stakeholders.
- Viewpoint — where you are looking from: a set of conventions for constructing, interpreting, using and analysing one type of view. A viewpoint includes model kinds, viewpoint languages and notations, modelling methods and analytic techniques to frame a specific set of concerns. Examples: operational, systems, technical, logical, deployment, process, information.
Architects design structures. They document views of those structures. A view is what you see; a viewpoint is where you look from.
An architecture view in an AD expresses the architecture of the system of interest from the perspective of one or more stakeholders to address specific concerns, using the conventions established by its viewpoint. A view consists of one or more architecture models.
The original definitions come from ISO; other sources copy and explain or modify them. Do not spend excessive time on the distinction — understanding comes with experience.
The SEI categorisation of structures
| Category | Elements | Questions it answers |
|---|---|---|
| Module | Modules — units of implementation, assigned areas of functional responsibility. A code-based way of considering the system, with less emphasis on runtime manifestation | What is the primary functional responsibility of each module? What other elements is a module allowed to use? What does it actually use? What modules are related by generalization or specialization (inheritance)? |
| Component-and-connector | Runtime components (principal units of computation) and connectors (communication vehicles among components) | What are the major executing components and how do they interact? What are the major shared data stores? Which parts are replicated? How does data progress through the system? What can run in parallel? How can the structure change as it executes? |
| Allocation | The relationship between software elements and elements in one or more external environments in which the software is created and executed | What processor does each element execute on? In what files is each element stored during development, testing and build? What is the assignment of elements to development teams? |
Specific structures within them:
| Structure | Category | Relation | Purpose |
|---|---|---|---|
| Decomposition | Module | "is a submodule of" | Larger modules decomposed recursively until small enough to be easily understood. A common starting point for design as the architect enumerates what the units must do and assigns each to a module for later detailed design and implementation |
| Uses | Module | "uses" | Important but overlooked. Units are modules or, at finer grain, procedures or resources on module interfaces. One unit uses another if the correctness of the first requires the presence of a correct version (not a stub) of the second |
| Layered | Module | carefully controlled uses | When uses relations are controlled in a particular way, layers emerge — a layer being a coherent set of related functionality. In a strictly layered structure layer n may only use layer n−1; many variations and relaxations occur in practice. Layers are often designed as abstractions (virtual machines) hiding implementation specifics below, engendering portability |
| Client-server | C&C | protocols and messages | Components are clients and servers; connectors are the protocols and messages they share. Useful for separation of concerns (supporting modifiability), physical distribution, and load balancing (supporting runtime performance) |
| SOA (service-oriented) | C&C | services provided/consumed | A collection of distributed components provide and consume services. Useful for interoperability across distributed components, integrating legacy systems, and dynamic reconfiguration |
| Event-based | C&C | asynchronous messages | Components communicate through asynchronous messages, which isolates event producers from consumers and improves modifiability |
| Deployment | Allocation | "allocated-to", "migrates-to" | How software is assigned to hardware-processing and communication elements. Elements are software (usually a process from a C&C view), hardware entities (processors) and communication pathways. Lets an engineer reason about performance, data integrity, availability and security; of particular interest in distributed or parallel systems |
| Implementation | Allocation | mapping to file structures | How software elements (usually modules) map to the file structures in development, integration or configuration-control environments. Critical for managing development activities and build processes |
| Work assignment | Allocation | responsibility | Assigns responsibility for implementing and integrating modules to development teams. Makes clear that deciding who does the work has architectural as well as management implications; the architect knows the expertise each team requires. On large multi-sourced distributed projects it is the means of calling out units of functional commonality and assigning them to a single team rather than having everyone who needs them implement them |
Conceptual / logical / physical
| Level | What it expresses |
|---|---|
| Conceptual | A set of relationships between factors believed to impact or lead to a target condition; theoretical entities, objects or conditions of a system and the relationships between them. Represents concepts and relationships, expressing the meaning of the terms and concepts domain experts use to discuss the problem, and finding the correct relationships between different concepts |
| Logical | Logical relationships between the resources, activities, outputs and outcomes of a programme, assessing the causal relationships between elements. Addresses the information system macroscopically by focusing on its main components, their interconnections and the flows exchanged, structuring them by group into larger-scale modules |
| Physical | Network capabilities, server specifications, hardware requirements and other information related to deploying the proposed system |
Architecture and Agile
Architecture exists in every project independent of the process or methodology used. To succeed in delivery and make customers happy, each project from mid-sized upward should have a Delivery Manager and a Solution Architect collaborating toward a common goal.
The myths, and the reality:
| Myth | Reality |
|---|---|
| Big up-front design | Each system should be designed and documented reasonably: analyse current needs and provide as much design as is required and enough to start the project or make it successful |
| Longer releases | Architecture design approaches are themselves iterative and incremental. Creating design is an incremental process — every day new requirements arrive or business goals change, and it is absolutely fine to update the design incrementally |
| Massive documentation | It is perfectly fine to have a small amount of documentation if it suffices for your concrete project. If Confluence pages with photos of your whiteboarding are enough, that is fine. There is no sense creating 100 pages of architecture documents never used after they are created |
| Architects are decision makers | Solution architects' decisions are based on stakeholder needs. The primary task is to identify and understand the business goal; all decisions — design, technology stack, tactics for achieving quality attributes — should be based on those goals |
| Decisions are hard to reverse | Evolutionary Architecture is an effective approach supporting incremental changes: organised around business capabilities, fine-grained, modular |
| Long-term vs incremental design | While creating design, do it incrementally and iteratively |
| Low visible value | In some cases there is no sense in big up-front design — concentrate on concrete business goals and high-priority business features instead |
Solution architect and delivery manager look at the same successful delivery from different angles — technical and delivery. From the client side both are regarded as part of the senior governance roles of the account, and clients expect the two to be synced up, aligned and going hand-in-hand.
Competency levels
| Level | Expectation |
|---|---|
| Early career | Designs small-to-medium solutions, often under the guidance of a more senior architect on large engagements. Contributes technical sections to proposals. Deep in one or two technology stacks and a domain or two. An experienced problem solver and a mature developer and lead |
| Mid career | Owns large solutions and leads proposal work — which is part management, part selling, and harder than either. Broader stack and domain coverage, and now needs working knowledge of enterprise architecture, because from this point the two disciplines start to overlap |
| Senior / principal | Leads the most demanding engagements. Solution and enterprise architecture in equal measure; capable of governance and senior technology-management roles on the customer side; works credibly with executive peers; understands the business strategy well enough to help execute it |
Requirements are generic plus practice-specific: a data and analytics practice (DW/BI/Big Data/DevOps), an enterprise technology practice (Java/.NET/integration/Agile), and a digital experience practice (commerce/CMS/mobile/front-end) will each add their own expectations on top of the generic ones.
Exercises — Module 1
No assignment. The module is orientation. Soft skills are trained during the later Tasks.