Software Architecture: Roles, Context, and Structures

2.1 Course Recap and Administrative Framing

2.1.1 Course Format and Flip Mode

This is the second session of a 16-session course, and each session runs for about ninety minutes. The course runs in flip mode — a common arrangement in modern engineering courses. In flip mode the roles of class and homework are inverted:

• Pre-recorded lectures carry the conceptual overview. Before each contact session you watch a recorded lecture that gives the full coverage of the theory — the definitions, the frameworks, the worked ideas.
• The live contact session is for interaction and flow. Class time is spent on student questions, clarifications, and connecting the ideas into a coherent arc — not on first-pass teaching.

This matters for how you should study: the theory lives in the recordings, so arrive at the session already having done the reading and watching. The live session assumes that baseline and builds on it.

2.1.2 Quiz and Examination Expectations

Open internet sounds generous, but it comes with a trap: some quiz banks on the internet carry wrong answers. The course material stays the reliable source — search engines can help, but they cannot replace understanding. Preparation means going through the material; a student who covers it properly should be able to handle the quiz well, and a student who searches rather than learns will find the time pressure and the misleading sources working against them.

The examination paper matches the course content exactly, but the questions are case-study oriented. They require application of mind rather than reproduction of content from a book — you will be handed a scenario and asked to reason about it with the concepts of the course, not asked to recite definitions. Last year's question paper is made available by the examination department, and it is worth reviewing it in advance so you can see the format and the level of reasoning expected. (The exact distribution channel and format of last year's paper are course-administrative details defined in the official course handout, so check that handout for the current arrangement.)

2.1.3 Q&A on Course Content Flow

A student asked whether the contact sessions would follow the flow of topics shown in the course handout. This is a fair question — the handout and the slides do not line up at first glance — so it is worth preserving both the question and the answer.

The course is deliberately fast-paced. The intent is not to dilute the material to match an older offering; the aim is to preserve the flow and the coverage. If a topic seems out of order on the slide deck, trust the handout's mapping and the session plan rather than assuming something was dropped.

2.1.4 Level of Abstraction

This course sits at a high level of abstraction, and you are asked to study it at that level. Studying it at a low level of abstraction leads to being overwhelmed — the subject is not a list of low-level technical details to memorize, and trying to treat it that way buries the important structure under the trivia.

The 80/20 rule applies: twenty percent of the effort covers eighty percent of the requirement. In practice this means a relatively small investment in the right overview buys most of the course's value — but only if that twenty percent is spent on the architectural view rather than scattered low-level details.

Software architecture is not a coding course, so the course does not teach code. Coding is a low-level activity — the individual statement, the individual call — whereas architecture sits above that, concerned with the structure that holds the code together. If you come from a coding background, resist the urge to drop to the code level: the exam tests the architectural view, not the implementation details.

2.1.5 Why Software Architecture Matters

Software architecture focuses on quality attributes — the non-functional characteristics that determine how well a system serves its purpose over time. The discipline addresses functional and non-functional requirements and system constraints, but its central concern is the quality attributes:

• Performance — how quickly the system responds.
• Modifiability — how easily the system can be changed.
• Security — how well the system resists misuse.
• Scalability — how well the system handles growth in load or users.
• Reusability — how much of the system can be reused elsewhere.
• Testability — how easily the system can be verified.
• Usability — how easily people can use the system.
• Availability — how reliably the system stays operational.

These are the attributes that separate a system that merely works from a system that keeps working, keeps being improveable, and keeps being safe under load. They will recur in nearly every topic in this course — the utility tree, the scenarios, the architecture evaluation methods — so it is worth building a clear mental list of them now.

Why does this matter economically? About 80% of typical software cost lands in maintenance — the ongoing work of fixing, extending, and adapting a system after it is first delivered. (The professor stated this 80% figure in the session; published studies vary, with commonly cited estimates of maintenance's share of total lifecycle cost ranging from about 60% to 90%.) Because delivery has been phased out in most modern product teams, artifacts are delivered from day one, keeping operations in sync with development and enabling continuous deployment. The result is that maintenance, development, and enhancement have become a perpetual activity in most products — a system is rarely "finished," and the architecture that makes that ongoing change cheap or expensive is exactly what this course teaches you to think about.

2.2 The Role of the Architect in an Agile Environment

2.2.1 Architecture in Agile Projects

A common question is whether architecture has a place in an agile environment. The answer is that the architect becomes more important. The reasoning is straightforward: agile methods accept change continuously, and every change that crosses the boundaries of the architecture is expensive. So the architect takes the major architectural decisions in advance so that changes of an architectural kind are minimized. Agile flexibility is about accepting inputs, not about abandoning structure — the team stays responsive to new requirements precisely because the load-bearing decisions were made early and do not keep moving.

There is an apparent tension between agile (deliver working software fast, respond to change) and architecture (decide structure early). The underlying philosophies are not at odds: too much up-front planning stifles responsiveness, and too much agility produces chaos. The architect's job is the middle ground — an initial architecture that guides development, kept alive by refactoring as requirements emerge.

2.2.2 Three Kinds of Change

The value of architecture shows up in what happens when a requirement changes. There are three kinds of change, and they differ hugely in cost:

1. A requirement change that touches no module. When the architecture keeps the major modules and subsystems intact, a requirement change may not require changing those modules at all. This is the cheapest kind — the change lands entirely in configuration, in a new component, or in the way existing components are wired.
2. A change that forces coordinated change across modules. A change in one module forces changes in other modules; that brings coordination overhead — several teams must change, agree, and integrate together. This is the expensive middle case.
3. A change inside a single subsystem. The change stays inside one subsystem and leaves the rest of the system alone. This is the easy kind of change — one team owns the work, no coordination across boundaries.

The architect divides the system into modules so that most changes are of the last kind. This is a design goal, not a hope: the module boundaries are chosen so that the changes you can foresee land inside single modules, and the changes you cannot foresee land in modules that happen to be self-contained.

2.2.3 Stakeholder Needs and the Cost of Quality

The architect must meet the quality requirements agreed with the stakeholders — the performance, availability, modifiability, security, and other attributes negotiated up front. But the job does not stop at the agreed requirements: the architect must also predict future stakeholder needs and educate the stakeholders accordingly.

Why predict and educate? Because educating stakeholders protects the architect. People who do not realize what they need will blame the architect for not providing it — the requirement that "nobody asked for" becomes, after delivery, "why didn't you build this properly?" The architect who has surfaced future needs in advance has turned an accusation into an agreed decision.

Every quality attribute carries a cost, and the cost is paid by certain stakeholders. Those stakeholders must understand two things:

• The cost of providing a quality attribute — what the system, schedule, and budget give up so that, say, availability reaches 99.9%.
• The impact of not providing it — what happens to the business when the system is down for hours, or when a security flaw is exploited.

This cost-of-quality conversation is a negotiation, not a lecture: the stakeholder decides what the business is willing to pay, and the architect must make sure the stakeholder is deciding with open eyes.

2.2.4 Early Decisions and the High-Level Picture

A major part of this course covers three linked things: engagement with stakeholders, design decisions that must be taken early, and constraints imposed by stakeholders or the environment. The environment includes the organization itself: the organization structure of the developing organization, the client organization, and the operations organization all influence the architecture. A system that must be maintained by a small on-call team is architected differently from one maintained by a large vendor team; a client organization with many internal departments shapes different module boundaries than a single-user client.

Once the architect holds the high-level picture and can present exactly how a solution will be implemented, a reasonable cost estimate and schedule estimate can be fixed. Without that picture, an agile project has no direction — estimates are guesses, scope drifts, and the "flexibility" of agile becomes chaos. The high-level picture is what converts an agile project from a sequence of improvisations into a disciplined response to change. (Studies of industrial projects support this intuition: there is a "sweet spot" where some up-front architecture effort pays off and is not wasteful — too little produces rework, too much produces rigidity.)

2.2.5 Reusable and Proven Technology

Architects favor transferable, over-the-counter technology with proven quality attributes. The reasoning is economic: a technology that is already used widely has known performance, known security behavior, known support, and known maintenance cost. Betting the architecture on an unproven technology means betting the project on unknown quality attributes.

In a large development organization, reusable modules give a cost advantage and bargaining power over competitors. A company that has built many telecom modules can fit those modules into any new telecom application, reducing the effort needed and strengthening its position in a bid — the reusable inventory lets it promise faster delivery and lower price than a competitor who starts from scratch. Reusable components also lead to independently developed components that may be outsourced or bought off the shelf. A database product can be bought from a vendor when it is productive to do so; a database simply becomes a component of the company's system — a component with a vendor behind it, but a component nonetheless.

2.3 The Architectural Context

The context of an architecture splits into four overlapping worlds: technical, project life cycle, business, and professional. Each contributes constraints and goals, and the architecture is their joint product.

2.3.1 Technical Context

When an architect approaches a problem, the first thing to understand is the technical context: the product itself, the technologies that would be used to build it, and the technological options available. What is the system supposed to do? What platforms, languages, databases, and frameworks are realistic choices? What quality attribute requirements must it satisfy? Nothing influences an architecture more than the quality attributes it must meet — a system that must serve a million simultaneous users is architected differently from one that serves fifty.

The technical context is also shaped by the current technical environment — what is available and proven at the time of design. An architect cannot choose a technology that does not exist yet or is not mature enough to bet a product on. The same architectural problem in 2005 and in 2025 has different answers because the environment changed.

2.3.2 Project Life Cycle Context

The project life cycle consists of analysis, design, development, deployment, and maintenance. The architect must understand where the project sits in this life cycle, because the same decision has different weight at different points:

• In analysis, requirements and constraints are still being discovered — the architect's input shapes what is built at all.
• In design, architectural decisions are made and the cost of change is still low.
• In development, the architecture is being realized and the cost of changing it is rising.
• In deployment, the system enters operation — decisions here concern infrastructure, rollout, and operations.
• In maintenance, the architecture determines how cheaply the system can keep changing for the rest of its life — recall that most of a system's cost lands here.

The architect who misreads the life cycle position makes the wrong kind of decision — treating a design-phase decision as if it were maintenance-phase, or locking in structure when requirements are still moving.

2.3.3 Business Context

The business context answers why the project exists at all. The architect meets the key stakeholder and asks why the application is being built and what is expected of it. The answers are business goals, and they come in concrete numbers:

• Grow market share from 40% to 60%.
• Grow turnover from 200 million to 400 million.
• Stop customers from leaving the website after the first two pages, by improving usability and performance.

These business goals exist to increase market share, profitability, or total sales. Notice what this means for the architect: the real requirement behind a performance requirement is often a revenue number. When a stakeholder says "the checkout page must respond in two seconds," the business goal behind it is "customers who wait longer abandon their carts." An architect who understands the business goal can negotiate the technical requirement intelligently; one who hears only the number cannot tell which part of the two seconds is negotiable.

2.3.4 Professional Context

The professional context is the background of the architect: the type of experience, past successes, and the biases the architect carries. The architect comes with a lifetime of background — every system the architect has built, every failure observed, every technique learned shapes how the next design is approached.

This is both an asset and a hazard. Experience lets the architect recognize problems quickly and reach for solutions that are known to work. But the same experience carries bias: a past success can become a reflex ("we always build this kind of system as a client–server pair") even when the current problem does not fit. The professional context is the lens the architect sees through — and a lens both focuses and distorts.

2.3.5 Stakeholders

Stakeholders are everyone with an interest in the system — and the list is longer than it first looks:

• the end users, who interact with the system;
• the people who pay for the application, whose budget it consumes;
• the people in the operating organization whose work life will change;
• the developers who build it;
• the maintainers who will keep it alive;
• the people who provide infrastructure;
• the government, which may regulate it;
• the environment, in the broadest sense — society, markets, competitors;
• the customers, who buy whatever the system produces.

Every stakeholder has a different requirement, and those requirements conflict as often as they agree. The end user wants speed; the payer wants low cost; the maintainer wants simplicity; the government wants audit trails. The architect does not satisfy all of them equally — the architect balances them, and the balance is the architecture.

2.3.6 The Influence Cycle and the Center of the Universe

An architecture is determined by a combination of all these forces — the four contexts and the full stakeholder list push on the design from every side. The professor's picture of how these forces work is an influence cycle, and it closes on itself:

1. The forces (contexts, stakeholders, environment) influence the architect.
2. The architect determines the architecture.
3. The architecture influences the system.
4. The system feeds back into the environment — it changes the market, the organization, the options available for the next project — closing the cycle.

2.4 Technical Environment and Industry Practices

2.4.1 Following Industry Practices

When a company develops software in a domain such as online sales for the FMCG sector (fast-moving consumer goods — the everyday products like food, drinks, and household items that sell quickly and in volume), following industry practices matters for several reasons:

• Customers expect a certain shape of product. A consumer-facing sales site has a familiar shape: a catalogue, a search box, a cart, a checkout. A company must meet those customer expectations and then exceed them. Going far from what is expected means the best product may not be adopted by customers — the technology can be superior and still lose, because the customer cannot use it the way they have learned to use the category.
• People move between companies. If processes follow familiar patterns, new staff adapt quickly. A developer or operator who joins a company from another firm in the same industry can start contributing immediately if the practices are standard; if the practices are idiosyncratic, every hire is a re-education project.

Industry conventions are, in other words, a form of shared infrastructure: they make both customers and staff interchangeable, which keeps the industry liquid.

2.4.2 Enterprise Systems Seen in Practice

The two major ERP systems (enterprise resource planning systems — the large integrated applications that run a company's core business processes like finance, inventory, and human resources) seen in many client organizations are Oracle Apps and SAP. These systems matter to an architect in an unexpected way: they shape the talent market.

Companies choose employers partly because knowledge of such an application advances their career. Knowing SAP or Oracle Apps deeply is a marketable skill, and that creates a retention problem. One early SAP implementer lost almost all of its trained people after a few years because the knowledge was valuable elsewhere — the firm had trained a workforce that the whole industry then hired away.

2.4.3 Technology Vocabulary Across Generations

The industry speaks a shared vocabulary — and an architect must speak it to communicate within the industry. The vocabulary includes:

• web-based — applications delivered through a browser;
• object-oriented — systems organized around objects that bundle data and behavior;
• service-oriented — systems organized around services that other systems call over a network;
• mobile-aware — applications designed for phones and tablets;
• cloud-based — systems hosted on shared, elastic infrastructure;
• social networking — applications built around user connections and sharing.

Over a professional lifetime the industry moved through architectural generations:

1. Desktop applications — the program lives on each user's machine and uses that machine's resources.
2. Client-server applications — a thin client on the user's machine talks to a central server that holds the data and logic.
3. Peer-to-peer networks — machines talk directly to each other, with no central authority, each acting as both client and server.

That era debated thick client versus thin client:

• Thin clients hold little logic and little data — web-oriented applications were thin clients. The browser displays; the server thinks.
• Thick clients hold substantial logic and data locally — desktop-based applications were thick clients. The machine does the work; the server mostly stores.

The trade-off behind that old debate never went away — it reappears in every generation, from client-server to cloud. How much work belongs on the user's device and how much in the center? Where does the data live, and who controls it? Understanding this language lets the architect reason about new generations in terms of the old ones.

2.5 Life Cycle Processes

2.5.1 Life Cycle Models

Life cycle processes describe how people work together. A life cycle model is a plan of the phases of a software project — what work happens, in what order, and how one phase hands off to the next. The models discussed here are:

• Waterfall — the oldest model; phases run one after another with little going back.
• Iterative — the work is done in repeated cycles, each cycle producing a working slice of the system.
• Agile — a family of iterative methods that emphasize responding to change, close team collaboration, and frequent delivery of working software.
• Model-driven — the system is developed from formal models that generate the code or much of the code automatically.

In practice every organization shapes its own life cycle from its preferences — no two companies run exactly the same process, and the model on the slide is not the model on the floor. Today teams work with DevOps (development and operations integrated into one continuous pipeline) in an agile environment and follow scrum (an agile framework built around fixed-length sprints). In earlier days teams were proud of extreme programming (an agile method with practices like pair programming and continuous integration). The oldest model people discussed was the waterfall model.

2.5.2 The Waterfall Model

The waterfall model is the classic, and its structure is easiest to see as a fixed sequence of phases:

That is the deep reason the industry moved beyond waterfall: in a waterfall, feedback arrives too late. The iterative and agile families exist to make the feedback loop shorter — verify the requirements early with a working slice, not late with the whole system.

2.5.3 Agile and the Architect's Continuing Role

In an agile environment the customer is kept on board — the customer is part of the team, not a distant sign-off authority. Where does the architect sit in this arrangement? The professor's answer has three parts:

1. The overall design may be fixed. The architecture is established early, and the team develops within it.
2. Architects are involved heavily in the initial stage — this is where the architecture takes shape and where the architect's influence is largest.
3. The architect or members of the architect's team must stay involved throughout so the team does not stray from the architecture. The involvement is continuous, not front-loaded.

How does continuous involvement work in practice? When meetings propose changes that may affect the architecture, the change is escalated back to the architect, who decides what should be done — whether the change is absorbed locally, modifies the architecture, or is rejected. The escalation path is what keeps an agile team agile: the team can respond to change quickly because it knows which changes touch the architecture and who decides on those.

2.6 The Architect's Activities

2.6.1 Understanding the Business Case

The architect first understands why the project exists in the first place; this is the business case — the reason the organization is spending money on this system. Is this system meant to grow revenue, cut cost, satisfy a regulation, or fend off a competitor? The business case is the yardstick every later decision is measured against. An architecture that is elegant but does not serve the business case is a failed architecture, however pretty its diagrams.

The link to the previous section is direct: the business context (2.3) answers why the project exists; the business case is that answer written down and made actionable. The architect who cannot state the business case in one sentence cannot defend a single major decision.

2.6.2 Smelling Out the Requirements

The architect must smell out the architecturally significant requirements — the requirements that shape the structure of the system. These are not written down and are not stated across the table. They hide in conversation, in hesitation, in what stakeholders mention and then walk back. The architect figures out what is truly required and prompts the stakeholders — asks the questions that make the buried requirement surface.

This is a genuine skill, not a trick: eliciting the requirement, converting it into a decision, and getting the decision formally owned by the person who will later judge the result.

2.6.3 Documentation and Communication

Once the work is decided, it must be documented and communicated and put down on paper. Documentation is how a decision survives its maker: the architecture must be understandable to the developers who implement it, the client who owns it, the maintainers who will keep it, and the next architect who will inherit it. An undocumented decision is a decision that will be silently unmade by the first person who finds it inconvenient.

2.6.4 Running Tests and Proofs of Concept

The architect runs tests on the plan. A POC (proof of concept) can simulate a stated requirement — for example, a search for a product that must complete within two or five seconds under a given number of users. The environment is simulated, that slice is built, and the client is shown the result before the whole system is developed. The POC answers one question with evidence instead of opinion: will this approach meet this requirement at this scale?

Two points from the session are worth keeping verbatim:

• If the method is not good enough, the architect changes the architecture, not the budget. The POC's purpose is to reveal that a chosen approach cannot meet the requirement — and the architect's response is to change the approach, not to accept a worse requirement or inflate the cost.
• A POC may be needed before a quotation is frozen, especially when a new technique is being developed, because the cost of building the system is architecture dependent. You cannot quote a price for a house you have never designed; similarly, a fixed price for a system whose architecture is unproven is a guess, and the POC turns the guess into a measured number.

2.6.5 Ensuring Conformance

The architect must ensure that what is implemented conforms to the architecture. Design is an act; conformance is a discipline. Without it, the architecture slowly decays — a shortcut here, a deviation there — until the system is "agile" in the worst sense: an architecture that exists only on paper, while the code does something else. The architect stays involved (as section 2.5.3 described) precisely so that conformance is checked continuously rather than discovered at the end.

2.7 Business Goals, the Utility Tree, and Scenarios

2.7.1 Business Context Can Change

The business context is not rigid. It shifts — and if the context changes completely, the architect goes back to the drawing board. The session's example is a real one:

A team is implementing a major system under the conventional regime when the government announces GST (the Goods and Services Tax). The architect tells the customer the order can still be executed but the system will not be usable because GST provisions are not handled — the delivered system would compute taxes and process transactions under rules that no longer exist.

In that era a GST portal was not available, so the organization had to build its own infrastructure for computation and data pickup, and the flow of processes had to change. Two lessons sit inside this story:

• The architect's job is to say the uncomfortable thing early. The system could be delivered on time and on budget — and be useless. Flagging that is exactly the "educate stakeholders" duty from section 2.2.3.
• Because the client got early intimation, a revision in cost could be approved and the work could proceed. The bad news was delivered in time to change the order. Late intimation would have meant a delivered-but-useless system and a broken relationship; early intimation meant a revised, approved, and executable plan.

The GST example also shows why "scope" is not fixed by the contract: the environment writes requirements that no contract anticipated, and the architect is the early-warning system.

2.7.2 Business Goals and Quality Attributes

The business context ultimately answers what the system is for. The primary business goals concern profit, market share, and turnover — the same three that appeared in the business context of section 2.3. These goals percolate down into how the system is implemented through the quality attributes:

• performance — the system must be fast enough to keep customers and users engaged;
• availability — the system must be up when business runs;
• testability — the system must be cheap to verify, so changes stay safe;
• modifiability — the system must be cheap to change as the market changes;
• security — the system must protect the business's assets and its customers.

Later lectures qualify these quality attributes in detail and document them precisely; this lecture's job is to show the chain: business goal → quality attribute → documented requirement.

2.7.3 The Utility Tree

The utility tree is the structure used to capture the quality attributes of a system — and the first assignment in this course discusses it. The picture is exactly a tree:

• The trunk of the utility tree is the root goal — the overall "goodness" of the system, the utility the system is meant to deliver.
• The main branches are the main quality attributes. The course focuses on a few of them: performance, availability, scalability, modifiability, testability, security, and usability. Other attributes can be understood by analogy — if you can place one quality attribute in the tree, you can place any of them.

A textual sketch of the tree looks like this:

Utility (root goal: overall goodness of the system)
├── Performance
├── Availability
├── Scalability
├── Modifiability
├── Testability
├── Security
└── Usability

Each branch can be refined further — performance might split into "transaction response time" and "throughput"; security might split into "confidentiality" and "integrity" — and the leaves of the tree are the concrete requirements, usually written as scenarios. So the tree reads top-down as: root goal → quality attribute → refinement → concrete scenario. Standard treatments of the utility tree put "utility" at the root, quality attributes on the first level of branches, refinements of each attribute on the next level, and the specific architecturally significant requirements as the leaves.

A tree with a leaf that cannot be traced to the root goal is a requirement without a reason — and the utility tree is precisely the tool that exposes such orphans.

2.7.4 Architectural and Non-Architectural Goals

Not every business goal reaches the architecture. Some business goals can be achieved without architecture: a company may reorganize its setup, talk to its lawyers, or change policies — these have nothing to do with the architecture of the product. The architect must be able to tell the two apart:

• Non-architectural goals — achievable by organizational or procedural change (restructure a team, change a policy, consult legal). No architecture involved.
• Functional goals — some need architectural involvement and many do not. A functional change that stays inside one component is not an architectural issue; a functional change that cuts across the system's structure is.
• Every quality attribute issue requires the architect. This is the sharp line: whatever the business wants that touches performance, availability, security, modifiability, scalability, testability, or usability lands on the architect's desk, because these are the properties that the structure of the system creates or destroys.

2.7.5 Scenarios

Quality attributes are depicted, explained, and documented through scenarios — short, concrete stories of a stimulus and the system's required response. The architect collects scenarios during interviews with stakeholders. Examples from the session:

• A search must return within five seconds.
• A person who breaks into the system must be identified.
• Repeated login attempts from an unknown location must stop that channel.

Each of these is a stimulus ("search requested", "break-in attempted", "login attempts from unknown location") paired with a required response ("return results in five seconds", "identify the intruder", "block the channel"). A complete scenario has six parts — the source of the stimulus, the stimulus itself, the environment it occurs in, the artifact it hits, the required response, and a response measure — so that the requirement is testable. "Search must return within five seconds" carries the response measure ("within five seconds"); without a measure, "search must be fast" is not a requirement, only a wish.

Then the negotiation begins. Stakeholders discuss the scenarios and decide how much money they are willing to pay for each quality attribute, then vote and prioritize. This is the cost-of-quality conversation from section 2.2.3, now made concrete: every scenario is a price tag. Wanting every quality attribute is impossible and very expensive; the team works against time and cost, so scope is decided by what time and cost the stakeholders will spend.

2.8 The Skills of the Architect

2.8.1 Technical Knowledge

Does an architect need to be a programmer, a designer, or hold an MBA degree? The professor's answer: the architect needs a worldview of information technology and an understanding of the components of IT systems — the pieces (hardware, software, networks, data, middleware) and how they fit together. Field knowledge of design and programming helps, but the architect must at least understand how software systems work — you cannot architect what you cannot reason about.

Above all the architect must be aware of the technologies available today. No one can know every technology — the field is far too large — and missing a technology may mean missing an opportunity. That is part of life, because a hand is only so big: every technology you know well is one you cannot know at all, and the architect's inventory of known technologies is always a sample, never the whole space. The practical consequence is that the architect's knowledge must be actively maintained — the technologies that were current when you started are not the technologies that are current now (section 2.4's vocabulary shifts with each generation).

2.8.2 Communication and Negotiation

The architect must be diplomatic and able to negotiate with stakeholders, talk to them without hurting them, and convey ideas through reading, writing, speaking, diagrams, and models. Notice how much of the list is not programming: the architect's output is only partly the architecture itself; the rest is making the architecture understood by everyone it touches.

This connects directly to section 2.6.2 ("smelling out the requirements"): the skill of hearing what is not said at the table is the same skill as hearing what is whispered beside it.

2.8.3 Updated Knowledge and Practices

The architect should keep updated knowledge of architectural practices, business practices, and technical practices — and know what other businesses do. Three bodies of knowledge, kept current together:

• Architectural practices — how systems are being designed and evaluated today (methods like ATAM, structures like the ones in this lecture);
• Business practices — how the industry organizes and sells its work;
• Technical practices — what the current technologies are and how they are used.

Knowing what other businesses do keeps the architect honest: the practices of the industry (section 2.4) are a moving target, and the architect who stops watching the market designs against a market that no longer exists.

2.8.4 The Influence of Past Work

The architect is influenced by the architectures and systems built in the past. The professor's image for this is the bullock cart on a track: first the cart makes the track, and then the track forces the cart to stay within it. The path the cart wears into the ground becomes a rut that constrains where it can go.

The lesson: the architect should acknowledge past influence but keep eyes and ears open to new technologies and methods. The track is useful for the first half of the journey; if you never look up from it, you will miss the road that goes somewhere better.

2.9 Q&A: Reusability versus Cost-Effectiveness

2.9.1 The Question on Reusability and Cost

A student asked whether, if a reusability mechanism increases the cost from the start, the reusability architecture should be preferred, or priority should go to the cost-effective method. A related question asked whether reusing an old module that performs well and is cost effective is acceptable when adopting new technology brings its own challenges.

Both questions are really the same question: when does the architect choose a more expensive option now (reuse-ready design, new technology) instead of the cheaper one?

2.9.2 The Answer: A Trade-Off Decision

Software architecture is neither a purely technical course nor a purely arts course; it involves creativity, and best practices sometimes pull away from creativity. The third, non-technical aspect the architect must master is the commercial aspect, and every architecture decision weighs cost and benefit. The professor's answer:

The key move is the distinction architectural versus technical. A technical decision is made by an engineer against fixed criteria; an architectural decision is made with the stakeholders, against the business case (section 2.6.1). Whether reusability is worth its upfront price is exactly such a decision: the answer lives in the economics of the project, not in the elegance of the design.

2.9.3 Cost Benefit Methods in the Course

The course devotes at least two lectures to these economics:

• ATAM — the Architecture Trade-off Analysis Method — decides what should be done and what should not. Its purpose is to assess the consequences of architectural decisions, and it is, at its core, a risk identification method: it detects areas of potential risk in the architecture. It works by comparing design decisions against quality attribute requirements — the same scenarios and utility tree from section 2.7, which is why the utility tree is so important to this lecture and its first assignment.
• CBAM — the Cost Benefit Analysis Method — near the end of the course, evaluates the cost and benefit of choices. CBAM builds on ATAM and its output is a ranking of architectural strategies by value-for-cost, so that the choice with the best economics comes out on top.

Whether a choice involves reusability or the adoption of new technology, the decision is an architectural trade-off or a cost benefit decision — ATAM and CBAM are the tools the course will give you for exactly the questions asked in section 2.9.1.

2.9.4 The Economics of Reuse

For a development organization, reuse can be an internal strategy. An architect in a development organization may push certain technologies because part of the cost benefit can be passed to the customer and it gives a competitive advantage: reusing modules lowers cost, allowing a good profit for the organization and some saving for the operations organization.

The structure of this arrangement matters:

• The development organization builds once and reuses many times — the fixed cost of the module is spread over every project that uses it.
• The operations organization (the client who runs the system) gets a saving because the reused module is proven — cheaper to integrate, cheaper to maintain.
• The architect is the one who proposes the technology stack that makes reuse possible, and part of the benefit is passed to the customer, which is the selling point that makes the decision acceptable.

Reuse, in other words, is not a virtue in the abstract: it is an economic strategy with a cost now and a return later, and its only honest justification is the arithmetic.

2.9.5 Selling the Value

In a commercial environment somebody pays the bill, and the architect must convince the people who pay that the choice is worth it. Cost effectiveness means value for cost — the cost and the value are measured together, not separately. If a choice carries value, the value must be sold to the stakeholders; when the analysis is done, the valuable choice comes out on top.

2.10 What Software Architecture Is

2.10.1 Elements and Relationships

Software architecture is about big blocks — the elements of a system — and the relationships between these elements. The course covers the proper definitions in the recorded material, but the key idea is the interaction of subsystems, the capability of individual subsystems, and how they interrelate. Three things to hold in mind:

• the elements — the subsystems, components, modules that make up the system;
• the capability of each individual subsystem — what each block can do on its own;
• the relationships — how the blocks interact, depend on, and constrain each other.

An architecture, in this view, is not the sum of the blocks: it is the pattern of their interactions. Two systems with the same blocks but different relationships are two different architectures — and, usually, very different systems.

2.10.2 Ways Architecture Is Presented

There are various ways in which an architecture is presented — several structures, each one a legitimate view. The body's comparison gives the intuition: one system, many structures, each structure showing what matters to a particular concern. The practical consequence for the architect is that the architecture must be documented in all its relevant structures (section 2.6.3), because each stakeholder and each change request reads a different one.

2.11 Architecture Structures: Module, Component-and-Connector, and Allocation

2.11.1 The Module Structure

Viewed as a module structure, the overall functionality is divided into blocks, or boxes. In each box the focus is on what is done, not how it is done — and that what includes quality attributes such as how efficiently and how available the work is.

The module structure is the static structure: it captures how the system's functionality is divided up and assigned to implementation units. Each module carries specific computational responsibilities, and these divisions are the basis of work assignments for programming teams — this team owns the database, that team owns the business rules, the third owns the user interface. When the course's first assignment asks for a block diagram showing which subsystem handles which activity, it is asking for the module structure.

2.11.2 The Component-and-Connector Structure

The component-and-connector (C&C) view treats the architecture as components that interact over connections, with a protocol for communicating between them. This structure is dynamic and concerns the behavior of the system: how components interact with each other at runtime, and the quality of that behavior, including how quickly, how efficiently, how often, and how securely.

Where the module structure answers "what is it divided into?", the C&C structure answers "what happens when it runs?". A component in this view is always a runtime entity — a running process, a service, a client and a server — and the connectors are the channels over which they communicate (procedure calls, message buses, network links, and the protocols that govern them).

2.11.3 The Allocation Structure

The allocation structure distributes workload among human beings, hardware elements, and software elements. It decides how the work is shared, which activities are done by which module, and whether work can be done in parallel. This placement — mapping the software elements onto things that are not software — is the allocation structure.

Three classic allocation questions: Which piece of software runs on which machine? (deployment). Which developer or team builds which module? (implementation/work assignment). Which part of the system must be built before which other part? (the ordering that determines what can proceed in parallel). Section 2.10's human-body analogy carries over: the allocation structure is like deciding which specialist operates on which organ and in which operating room.

2.11.4 Choosing Which Structure to Present

The course covers the three structures in the coming classes: module, component-and-connector, and allocation. When presenting an architecture, the architect decides which of the structures best suits the particular problem. Some structures explain the functionalities to be achieved, so the architect may give a block diagram showing which subsystem handles which activity.

2.12 Availability: A Worked Calculation

2.12.1 The Quality Attribute of Availability

Availability is a key quality attribute. An SLA may specify the availability expected of a server — for example, five minutes of downtime a year, with a penalty beyond that. The overall system has an availability, and the availability of each subsystem contributes to it. Before the arithmetic, the definitions matter:

• A failure is an event — the system (or a part of it) stops delivering its service.
• Availability is the probability that the system is up when needed — equivalently, the fraction of time the system is operational.
• The textbook measure ties availability to uptime and downtime: availability = mean time between failures divided by (mean time between failures + mean time to repair):

$$A=\frac{\text{MTBF}}{\text{MTBF}+\text{MTTR}}$$

A subsystem with availability 0.99 is up, on average, 99% of the time — the famous "two nines." A whole system made of such subsystems is rarely 99% available, as the series calculation shows.

2.12.2 Availability in Series

Consider two subsystems in a series, each with availability 0.99. The system performs two independent functions one after the other — if either subsystem is down, the whole chain stops, so the availability falls. The overall availability is the product:

$$A_{\text{series}}=A_1\times A_2$$

With each subsystem at 0.99:

$$A=0.99\times 0.99=0.9801$$

2.12.3 Availability with a Mirror Backup

Now consider a backup setup where one subsystem mirrors the other. Note the professor's precise wording: this is a backup process, not two parallel processes. Although parallel processes give better performance, the backup is implemented as a series process in operation — the mirror sits alongside and takes over when the primary fails. As a mirror, the system improves overall availability.

The logic: the system is down only when both subsystems are down. The chance that one subsystem is down is $1-0.99=0.01$; the chance that both are down is:

$$0.01\times 0.01=0.0001$$

The overall availability is:

$$A=1-0.0001=0.9999$$

In general, for a mirrored pair:

$$A_{\text{mirror}}=1-(1-A_1)(1-A_2)$$

Responsiveness is the performance attribute, and availability is a separate quality attribute; both are covered in more detail later in the course.

2.13 Every System Has an Architecture

2.13.1 No System Without an Architecture

Sometimes a person studies a system and reports that the system does not have an architecture. There is no system without an architecture. The architecture is always there, and it can be good or bad; a bad architecture is still an architecture.

This is the counterpart to the definition in section 2.1. Architecture is the set of structures the system actually has — the big blocks and their relationships (section 2.10) — and a system is always built with some structure, even when that structure was never designed. "No architecture" is not a description of a system; it is a verdict that the speaker does not like the structure they found. The profession's job is to evaluate that structure, not to deny it.

2.13.2 Documentation Is Not Required for Architecture

An architecture may be documented or not documented. A lack of documentation does not mean there is no architecture. Bad architecture is not an absence of architecture, and a lack of documentation is not an absence of architecture. Still, if an architecture exists it should be documented — otherwise use becomes difficult.

The two confusions the professor is clearing up:

• Bad architecture ≠ no architecture — the structure exists and is poor; it must be analyzed and improved, not wished away.
• Undocumented architecture ≠ no architecture — the structure exists in the code and in the heads of the people who built it; it simply has not been written down.

Documentation is a responsibility (section 2.6.3), not a precondition. The absence of the document does not excuse the reader from the system's actual structure — which is why the next subsection exists.

2.13.3 Recovering Architecture

Part of the course deals with recovering the architecture — finding the architecture when documentation does not exist. This is typical for legacy systems. Unless the architecture of a system is understood, it is very difficult to improve the system; the system may be the best that could be done with that approach, and a new design may just reproduce what already exists. Tools and approaches exist for recovering an architecture.

The recovery discipline rests on section 2.13.2: because the architecture is in the system regardless of documentation, it can be extracted — reverse engineered from the code, the deployment, the runtime behavior — rather than invented. Why bother? Three reasons:

• Understanding precedes improvement. You cannot improve what you do not understand; every change risks breaking the invisible structure.
• Appreciating the old design. The system may be the best that could be done with the approach it uses — condemning it without understanding it means a redesign that silently rebuilds the same mistakes, or worse, loses what was good.
• Conformance discovery. Recovery often reveals that the system has drifted from any design that was ever documented — the same decay section 2.6.5's conformance discipline is meant to prevent.

2.14 Views: Static and Dynamic Representations

2.14.1 The Module Structure as a Static View

Architecture is not only the module structure. The three structures are module, component-and-connector, and allocation. The module structure is like a photograph: it is a static structure — the system frozen in a moment, showing how the functionality is divided, with no sense of time or motion.

2.14.2 The Component-and-Connector Structure as a Dynamic View

The component-and-connector structure is more dynamic. It tells the type of interaction, and interaction has to do with behavior. The behavior of a system is how components interact with each other. The architect must engage with the behavior of the system, including not only the functionality of the behavior but also the quality of the behavior: how quickly, how efficiently, how often, and how securely.

Where the photograph shows the shape of the system, the dynamic view shows the film of it: a request arrives at one component, travels across connectors, is answered, fails, retries, contends with other requests. The performance, efficiency, and security attributes of section 2.7 live in this film, not in the photograph — which is why the C&C view is the one that must be produced whenever the question is about how well the system behaves under load.

2.14.3 What a View Is

Like the human body, an architecture can be viewed in various ways. Photographs of the body, or cut-up components, show everything together. A diagram, however, draws only one of the systems — for example, the nervous system, the circulatory system, or the digestive system. That diagram is a view.

The important precision: the view is not the structure. The structure is a property of the system itself (section 2.13 — every system has one, documented or not). The view is the representation — the drawing, the diagram — that lets a particular stakeholder examine a particular structure. One system, three structures, many possible views; a good architecture document ships a set of views that cover the structures the stakeholders actually need to see.

The session closed at this point, and the next session continues from the remaining slides.

Exam Guidance Summary

The session's closing guidance for the examination, consolidated:

• The examination uses case-study questions that require application of mind; reproduction of content from the book does not serve the purpose. The exam rewards the student who can reason about a new system, not the student who can recite the slides.
• Study the course at a high level of abstraction rather than digging deep into details; a student with an overview handles the examination better. The conceptual skeleton — roles, contexts, structures, quality attributes — carries more marks than memorized minutiae.
• Expect questions linking stakeholder and context ideas: technical context, business context, professional context, and the influence cycle (section 2.3).
• Know the utility tree and scenarios: quality attributes such as performance, availability, testability, modifiability, security, and usability are documented through scenarios (section 2.7).
• Be ready for trade-off and cost benefit reasoning; ATAM is the architecture trade-off analysis method and CBAM is the cost benefit analysis method (section 2.9).
• Be able to compute combined availability for series and parallel or mirrored subsystems from given availability values (section 2.12: $A_{\text{series}}=A_1\times A_2$; $A_{\text{mirror}}=1-(1-A_1)(1-A_2)$).
• Know that a lack of documentation does not mean a lack of architecture, and that recovering an architecture is part of the architect's job (section 2.13).

Key Industry Applications

Industry references from the session, with the JD Edwards point corrected:

• Oracle Apps and SAP are the two ERP systems most often seen in client organizations in practice — the same pair named in section 2.4's vocabulary of the trade.
• MS SQL Server and Oracle databases are commonly selected based on the comfort of the development organization or dictated by the operations organization as a constraint — the choice is organizational, not purely technical (an example of the allocation structure's work assignment in real life).
• JD Edwards was reported in the session to have been acquired by SAP. The corporate history should be corrected: JD Edwards was acquired by PeopleSoft in 2003, and PeopleSoft itself was then acquired by Oracle in 2005 — so JD Edwards is today part of the Oracle family, not SAP. The session's direction (a large vendor acquiring JD Edwards) is right; the vendor named is not.
• The SRS, the software requirement specification, is the output of the analysis phase in the waterfall model (section 2.5).
• Waterfall, extreme programming, scrum, and DevOps name the life cycle and process models used across generations of teams (section 2.5).
• A POC simulates a requirement such as a search completing within two or five seconds and is used before the full system is built (section 2.6.4).
• The utility tree and the SLA connect quality attributes to business goals in real engagements (sections 2.7 and 2.12).
• Reading the textbook is encouraged alongside the slides to support the course.