Week 3, first architecture lecture. Chapter 1 named architecture as the first major design activity; this lecture defines it formally and lists what an architect actually does.

First half: the fundamentals, meaning what architecture is and why it matters.

Second half: the key tasks, from identifying stakeholder concerns to keeping the implementation in sync with the design. Final 252 asked you to list five of them.

It closes by applying Chapter 1’s problem-solving framework to architecture.

Architecture is first a communication tool: it gives every stakeholder (developers, managers, clients, operators) one shared picture of the system to discuss and decide on.

Its two questions are what parts exist and how they fit together: the major components and the connections between them.

It is not about development details, algorithms or data structures. Those belong to detailed and construction design. A diagram that shows sorting logic is no longer an architecture diagram.

“Architecture” has three meanings at once: the high-level structures of a system, the discipline of creating them, and the documentation that records them.

It captures three dimensions: structure (the parts), communication or behaviour (how the parts interact at run time), and non-functional requirements (the qualities the system must have: performance, security, availability…).

It focuses on the decisions that would be difficult to change once the system is built: the choice of components, how they talk, where data lives. That is why these decisions are made first and with care.

The formal definition, part (1): architecture is the foundational software design activity. It comes first and everything else is built on it.

All of this exists to support detailed design and construction: it is an input to the next phases, not an end in itself.

Part (2): architecture is also the product of that activity, the high-level diagrams and component models (the same process/product split as Chapter 1).

At this level we deliberately don’t care how each part works inside. Only which parts exist and how they talk.

Zooming into the backend: a ShoppingCart class (addItem(), removeItem(), checkout()) and a Payment class (processCreditCard(), confirmTransaction()). At checkout, ShoppingCart calls Payment.processCreditCard(). Here method names, data flow and logic matter.

You can use the same diagram types in both phases (a sequence diagram, for instance). The difference is the level: in architecture they show subsystems, actors and major flows; in design they go down to classes, methods and attributes.

Slide 15: architecture supports (is an input to) detailed design and construction. These five phrases are exactly what Final 252 Q2-1 asked you to explain (any three).

Foundational means architecture provides the groundwork for meeting the requirements, both functional and non-functional. Without it, there is nothing for the rest of the design to stand on.

It should be forward engineering: done first, leading to the implementation. The opposite, reverse engineering, analyses a system after it has been built to recover its architecture. That is useful for old systems, but it is not how a new one should be designed.

Because it is foundational, architecture is where designing for quality begins. Ignoring quality attributes here is a grave mistake: performance or security that the structure doesn’t support is very hard to add later.

Architecture provides abstractions of the requirements in the design domain: each requirement is mapped to design elements (components, connectors) that will satisfy it.

That mapping turns requirements from text into diagrams, and it makes requirements traceable: for any requirement you can point to the components that implement it, and follow it through to code and tests.

The mapping assumes the requirements are understood, which is often not the case. Architects therefore need to be good at requirements engineering: gathering, analysing and clarifying what the system must do. Chapter 2 Lecture 2 covers this.

No single structure or diagram can describe a whole architecture. Try judging both usability and performance from one picture: a screen-flow diagram says nothing about load, a deployment diagram says nothing about ease of use.

The second reason is communication: architecture serves stakeholders with different backgrounds and questions, so different diagrams are needed for different stakeholders.

Architecture records three things about each major component: the component itself, the services (functionality) it provides to others, and the quality properties of those services.

Example A (left): component B provides an algorithm, but nothing is said about its quality. The client just assumes it is “good enough”, and may discover too late that it is too slow or can’t be reused.

Example B (right): the same component tagged with its qualities, e.g. performance O(n²) (slow for large inputs) and low reusability. Now the client knows the limits and can decide whether to use it. Quality tags make components transparent and choices informed.

Architecture focuses on quality, but it must also produce a design that supports efficient detailed design and construction. A structure that is elegant on paper but awkward to implement fails this test.

That is why architects benefit from knowing programming and design concepts well: they must foresee how their components will be built.

And architecture alone cannot guarantee quality. Example: the architect requires security, a programmer skips it for lack of time, and the final code meets every quality except security. Qualities must be carried through into the code.

It often runs in parallel with some specification activities: sketching an architecture helps discover and check requirements.

Identify stakeholders’ concerns: the requirements and quality attributes each stakeholder cares about (slides 18–23).

Identify architectural styles and patterns. A style is a general template for organising a system (e.g. distributed system); a pattern is a more specific reusable solution to a recurring problem (client–server, pipes and filters).

Identify the influences of architectural decisions in organisations: their effect on budget, schedule and resources.

Establish policies for design synchronicity, so every part follows the same design rules. Example: if the rule is “one database system, MySQL”, no team quietly uses MongoDB in its module (slide 28).

A stakeholder is any person, group or organisation with a direct or indirect stake in the system: systems, software and hardware engineers, project management, customers, testers, QA and configuration management, among others.

A stakeholder’s concern is high-level information about a characteristic they want the system to have (“it must never lose a payment”, “it must be easy to learn”). The architect must make sure the design addresses the concerns of all stakeholders.

Concerns are the driving force behind architectural decisions: the components and styles are chosen to satisfy them. The slide marks this as important.

The architect must find out how each group of stakeholders influences the system, and those concerns must be elicited before any design begins. Designing first and asking later produces the wrong system.

University app example: students want to see schedules and grades easily, professors need to upload grades and message students, administrators need to manage courses and records.

Their concerns differ in kind, not just in features: students care about a user-friendly interface (usability), administrators about security and data management. Each concern points the architecture in a different direction.

Quality attributes stakeholders worry about, read as “the degree of complexity involved” or “the system’s ability”. Usability: how hard it is to learn or use. Modifiability: how hard it is to change. Security: protecting information. Performance: useful work under time and resource limits. Reliability: the failure rate. Portability: how hard it is to move to other environments. Testability: how hard it is to verify.

NFR vs. quality attribute (Extra box): closely related but not identical. A non-functional requirement is a system-level goal (“the system must process 1000 orders per second”).

A quality tag assigns that goal to a specific component so it is clear which part must meet it (“backend order service ≤ 100 ms per order”, “database ≥ 5000 queries per second”).

Quality attributes are, like concerns, high-level descriptions. “The system must be secure” is true and useless to a developer: in this form they are not enough to build anything.

To make a system actually exhibit a quality, the architect makes specific design decisions, called tactics: “authenticate every user”, “encrypt stored passwords”, “run two servers”. Tactics turn a wish into something buildable and checkable.

A tactic is a design decision that affects the control of a quality attribute response: it changes how the system responds in situations that matter for that quality (attack, overload, failure, change request).

Quality attributes are usually identified in the requirements phase. The architect’s job is to specify how to meet them, by choosing tactics for each desired quality. The slide marks this as important.

Testability tactic: event logging. Log data and operations throughout the system, and let testers switch the logging on to see what the system is doing; when a bug appears, the log shows what led to it.

Modifiability tactics: localise changes (modularization, abstraction, encapsulation) and prevent ripple effects (encapsulation, reduce coupling). Updating the login feature then doesn’t touch grade submission. These are Chapter 1’s principles used as tactics.

The two pictures show the same system from two views: View 1 (the screens a user sees) is the right one to judge usability; View 2 (the internal components) is the right one to judge reusability. Neither view can answer the other’s question.

An architectural view is a representation of the system: one focused picture of it. Different representations are needed to evaluate different properties (performance from a process view, deployment from a physical view). Lecture 3 introduces Kruchten’s 4+1 views.

They are reusable solutions, documented so they are easy to understand and apply, and decisions based on them inherit years of documented experience instead of being invented from scratch.

Many exist, so the architect must know them well enough to judge the appropriateness of a style or pattern for a particular system. Chapter 4 covers the major ones.

Architects must also understand the effect of their choices on customers, budget, schedule and resource availability: a pattern can be technically right and still unaffordable.

Skipping it has a large impact on effort and cost, because defects found early take much less effort to correct than the same defects found in code or after release.

Amazon-style example: during design, architects check whether the system can handle millions of simultaneous users. If the database design won’t survive peak traffic, they rework it now, not during Black Friday. Chapter 8 covers evaluation methods (ATAM).

High synchronicity is the goal, but it is easy to deviate from the design, especially in multi-year projects where people, priorities and deadlines change.

Every phase after architecture must stay synchronised with it, which needs a well-defined, understood process. That includes maintenance, which can last for years after deployment.

Example: a banking app is designed with secure login and transfers; during development the team adds themes and chat and changes security without updating the design. The product no longer matches the design: low synchronicity. The cure is to document, review and approve every change.

Chapter 1’s holistic problem-solving framework applied to architecture. Inputs (requirements, system goals, scenarios) define the problem, and the architect first interprets them. Requirements are rarely complete on the first try, so this step repeats.

The process runs on resources (the team, modelling software, IDEs, hardware) and is governed by controls, rules for how, when and where activities happen. Examples: design reviews scheduled a week ahead, QA staff present at reviews, classified material reviewed inside a vault.

Summary of the fundamentals: architecture is the foundational activity that turns requirements into a collection of design elements describing the major components and their quality, to support detailed design.

The next lecture covers requirements engineering, because (slide 11) an architect can only translate requirements that are understood.