Software Architecture: Structures, Views, and Quality Attributes

3.1 Architecture, Design, and Code

3.1.1 The Three Levels

Software people talk about architecture, design, and code as if the words were interchangeable. They are not. The cleanest way to separate them is to line them up from the bottom of a detail scale to the top: code sits at the bottom (most detail), design in the middle, architecture at the top (broadest view, least detail).

An everyday analogy locks in the ordering. Building a house has three layers too: the architect decides "three bedrooms, kitchen on the east side, two floors" (architecture); the designer decides where every wall, door, socket, and pipe goes (design); the mason lays the bricks exactly as drawn (code). The mason can choose their trowel technique — that is syntax autonomy — but cannot move a door the architect placed. Where the analogy breaks: software designs change far more often than building drawings, which is why the rule "any functionality change must reflect in the design" matters so much more in software.

3.1.2 Design and Architecture in Practice

The same vocabulary appears at both levels, but the emphasis is different. When you talk about classes and packages, you are at design-level modules. When you talk about subsystems and off-the-shelf, bought-out components, you are closer to architecture. Not all bought-out components are architectural components, but an RDBMS definitely is, and a mail server is. If you are talking about a date widget, that is not architecture; that lives at the design level. So at various levels we talk about the same things, but with a different emphasis.

A date widget is a bought-out piece too, yet it is not architectural — size and impact decide, not the purchase order. An RDBMS shapes how whole subsystems talk to data; a date widget shapes one screen.

Day-to-day design looks like this. In a reasonably sized company you might work as a designer and a developer, or you might be part of a team that does the designing. During a stand-up meeting, during discussions, a decision is taken about what classes will exist in your product. If you designed the classes, you put them down on paper in some way and got an approval, or shared them with the team. The diagramming technology used for this is UML (Unified Modeling Language, the standard notation for drawing object-oriented designs). Once you actually write your script — C Sharp, Java, Python, Ruby on Rails, whatever it may be — that is coding. There can be situations where the coder is not the designer, or where coders are part of a team and the design decisions are taken together. Those decisions are normally penned down and signed off, so that all the coders working on various modules interact seamlessly with one another.

3.1.3 Student Questions and Answers

This confirmation is worth remembering as a mental shortcut: when someone says "high-level design," they usually mean architecture — the subsystem view. When they say "low-level design," they mean the class-and-method detail that feeds the coder.

In industry, this separation is why job postings split "developer," "designer," and "architect" roles: civil engineers use the same layering — structural frame, detailed drawings, brickwork — to let large teams build one thing without stepping on each other. In software, the same layering lets a team of coders work from a signed-off design while the architect keeps the system-of-systems view coherent.

3.2 Structures and Views

3.2.1 Structure versus View

Here is a question that trips up experienced engineers too: if two architects draw the same system differently, is one of them wrong? Not necessarily — they may be drawing different views of the same structure.

Every structure has distinct methods of presenting it to the stakeholders, so a number of views are available for a single structure. When you look at various structures you get a particular perspective: module structure, component-connector, allocation — the three you will meet in the next section.

Notice where this analogy breaks, because the break point teaches something: a photograph freezes one angle forever, while a view can be redrawn, refined, and re-shared as stakeholders change. And the professor's second image sharpens the point further — anatomy textbooks draw the body in standardized ways, but if you actually cut a body open, you will not find things exactly the way they appear in the pictures. The picture represents; it is a good way to present, a good view for people to understand.

3.2.2 The Physiology Example

Someone asked for an example of structures versus views, and the medical profession gives the best one.

This also explains why module, component-connector, and allocation are not inhabitants of different planets. The same element — a knee, a head, a hand, a foot — exists in the cardiological system, the orthopedic system, and the neural system. You are looking at the same thing from a different perspective. That is structure.

Picture three transparent sheets laid over the same body outline: one sheet draws only bones, one only vessels, one only nerves. Peel any sheet off and the body underneath is unchanged — that is exactly the relationship between a view (the sheet) and the structure (the body). The takeaway from the picture: many sheets, one body; many views, one architecture.

3.2.3 Views in Practice

Sketch of that view: a single box labeled Server at the center, with arrows fanning out to five smaller boxes labeled Client. Each arrow means "client sends a request, server replies." The real machine behind the server box runs dozens of processes on specific hardware over a mixed network — none of that appears in the view, and none of it needs to for the stakeholder's question ("how many clients hit one server?") to be answered.

In practice, this distinction is why architecture documentation standards separate "what to show" from "how to show it": hospitals, air-traffic control, and web companies all document the same kinds of structures through standardized views so that new doctors — or new engineers — can read the chart quickly.

3.3 The Three Structures: Module, Component-Connector, and Allocation

If a structure is what exists and a view is how you present it (Section 3.2), which structures does an architecture actually have? Three — and every architecture you will ever discuss is some combination of them.

3.3.1 Module Structure

The module structure is where you break down any software system into blocks. It gives a systematic division of the roles into various blocks. The module structure can be derived by decomposition in several ways:

• Decomposition by use. You break the system up depending on the use of each module. One module uses another when its correctness requires the presence of a correctly working version of the other — this relation lets you carve out usable subsets and add extensions without touching the whole system.
• Layers. You break it into layers when activity is conducted by different layers — for example, the famous layered structure of networking. A layer is an abstract "virtual machine" offering services through a managed interface; in a strictly layered system each layer uses only the layer immediately below it, which buys portability: swap the bottom layer and nothing above needs to know.
• Class structure. This is closer to the design level, but sometimes it is used even architecturally. You indicate broad classes, or sometimes there may not be classes at all — there may be a collection of classes. The further breakdown into individual classes is done by the designer.
• Data model. This is where the data is stored. You may have a large quantum of unstructured data in a NoSQL Hadoop module. You may maintain an RDBMS in Oracle or SQL Server. You may be maintaining local text files on the desktop, keeping certain components of data inside your mobile for active use, keeping certain data as part of your objects and saving them in memory, or maintaining data in arrays. The data model captures the decisions about how you keep your data: whether you replicate it in various locations, whether regional data is available separately, and if it is a distributed model, how you distribute the data, how you ensure its availability, and how you update it when it sits in a cloud spread across geographies.

3.3.2 Component-Connector Structure

The component-connector structure views components as interacting units without a hierarchical or breakup relationship between them. The connectors inform you how they communicate. A component here is always a runtime entity — a running server, a live service instance — not a pile of source code. A connector is the communication vehicle: a request-reply protocol, a message queue, a pipe.

Real-world: this is the structure you use when one module consumes the service of another module. The decision is how you will connect — whether you will use SOAP or REST. When you run various activities together, you might like to show the communication of synchronous processes.

Students familiar with UML have pointed out that the module structure is a static structure while the component-connector is a dynamic structure; the language is borrowed from design vocabulary, where you have a number of static diagrams and a number of dynamic diagrams. The similarity holds, though architecture diagrams are not at the level of detail you find in UML.

3.3.3 Allocation Structure

Allocation is the allocation of responsibilities to structures, to various modules or components. It covers how manpower is allocated to them, how work is allocated to them, and whether they work in parallel or in series. The allocation structure answers: which activities, which processes, and which modules will run on which physical devices, and which software components will handle what type of activity. If you want to do parsing, filtering, or sorting, will you have separate software modules to handle it, or separate hardware devices? There may be allocation even at the level of development. This allocation may help you get better security, integrity, availability, and performance — for whatever purpose you choose to allocate your work across places.

Implementation allocation is the management of the development activity: work assignment. Which team will develop which module, and what type of expertise is required in the team? You distribute the work so that, say, all your middleware is located in a layer, and you give it to the team that has the right expertise in business processes to handle the middleware properly.

Three everyday allocation flavors cover most cases: deployment (which process runs on which machine), implementation (which module sits in which directory of the code repository), and work assignment (which team builds which piece).

3.3.4 How the Structures Relate

A client-server system shows all three structures at once. When you decompose it, you get a client and a server, each with various roles to play — that is the module view. When you look at it as a component-connector structure, you are talking in terms of the request-reply part.

This three-way split is the working vocabulary of every architecture review board in industry: when a bank reviews its payment platform, it walks the module view for change impact, the C&C view for load and failure questions, and the allocation view for cost and team planning.

3.4 Abstraction, Patterns, and Frameworks

3.4.1 Architecture as Abstraction

Why do managers, testers, and coders all nod at the same one-page architecture diagram when they understand the system at completely different depths? Because the diagram is an abstraction — and that is its whole point.

Architecture is an abstraction of the system: you get a crude idea of what you are looking at, without going into details. That is precisely its value — a shared, coarse understanding that everyone can agree on or push back against before a single detail is built.

The formal way to say this: an abstraction selects certain details and suppresses others. Architecture keeps the details that have ramifications outside a single element — how elements relate, what their responsibilities and interfaces are — and drops the private internals nobody outside the element needs. That suppression is not a loss; it is the only way a human team can reason about a system too big to hold in one head.

Everyday analogy: a metro map shows lines, stations, and interchanges but bends no real curves and measures no real distances. It suppresses geography to amplify connectivity — exactly what an architecture diagram does with implementation detail. The map breaks down when someone asks "how far is station A from B on foot?" — just as the architecture diagram cannot answer "how many milliseconds does this call take?"

3.4.2 Patterns

If you are looking at a distributed architecture, a client-server architecture, a peer-to-peer architecture, or a model-view-controller (MVC) architecture, you are naming an architecture. These names represent architectural patterns.

Patterns mentioned in this lecture: shared data, client-server, multi-tier, layered, peer-to-peer, MVC. Each name carries a bundle of expectations: say "client-server" and everyone pictures clients requesting and one server replying; say "shared data" and everyone pictures components reading and writing one persistent store; say "multi-tier" and everyone pictures components spread across distinct hardware layers. Patterns will be covered in depth later in the course.

Patterns work like species names in biology: "mammal" tells you warm-blooded, milk-feeding, hair-bearing before you meet the individual animal — the same compression the hazy-animal abstraction gave us one subsection ago.

3.4.3 Frameworks

Architectural frameworks are the broad outline of what patterns will be put together to get a particular solution.

A worked miniature: an e-commerce platform might combine client-server (storefront talks to backend), shared-data (catalog and orders in one database), and multi-tier (web tier, application tier, database tier) into one framework describing the whole solution. Each pattern is a word; the framework is the grammatical sentence that makes them a commitment.

In industry, job interviews and design reviews run on this vocabulary: "we run a multi-tier, shared-data architecture behind a client-server front end" communicates in one sentence what would otherwise take pages — the same way doctors exchange whole patient histories through standard chart conventions.

3.5 Good Architecture, Fitment, and Quality Attributes

3.5.1 There Is No "Good" Architecture

Students keep asking "what is the best architecture?" — and the question itself is broken. Here is why.

It does not match, and you do not get to argue that the architecture will definitely deliver the performance, so why is it not acceptable. It performs better than what was required — at a cost.

The same logic scales up: a three-tier layered service-oriented architecture may be just right for a large enterprise web system and completely wrong for an aircraft controller; an architecture crafted for easy modification makes no sense for a throwaway prototype.

Two architectural solutions may not be identical. You prioritize your list of quality attributes; the same problem with a different set of stakeholders can produce a different prioritization. That is why you must involve the stakeholders, identify the people who have to be involved, prioritize the quality attributes, document and share your architectural solution, let people know what you are going to deliver, and then implement incrementally with the big picture in mind. You keep the big picture, but you build up gradually, keeping in mind that you might have to change in between. If you use a pattern or a particular tactic, you have to explain why you are using it and which quality attributes you plan to achieve through it.

3.5.2 Reasons an Element Exists

When you break up your architectural elements, each element has a reason to exist; each subsystem has a reason to exist. The reasons can be functional, but this course is less concerned with functional reasons. It is more concerned with the quality reasons:

If you look up quality attributes on Wikipedia or Google, you will see at least 30 of them, and with more elaborate detail you will find 100. In this course we stick to this handful, because the others can be viewed as variations or derivatives of these. The list is repeated deliberately so that it becomes part of your natural vocabulary.

3.5.3 Stakeholders, Prioritization, and Incremental Delivery

The stakeholder loop is the practical engine of architecture:

1. Identify who must be involved — every party whose concerns the architecture must answer.
2. Prioritize the quality attributes with them, because priorities differ by stakeholder set.
3. Document and share the solution, so people know what will be delivered before it exists.
4. Implement incrementally against the big picture, expecting change in between.

The same problem with a different stakeholder set may legitimately receive a different priority order, which is why copying another project's architecture without its stakeholders is meaningless. A trading desk prioritizes performance first; a hospital records system puts availability and security first; both are right.

This fitment mindset is exactly how enterprises choose platforms in industry: cloud vendors publish fit-for-purpose guidance per workload rather than ranking products as universally best, because the paying stakeholder's priority list — not a universal scoreboard — decides.

3.6 Documentation, UML, and Study Strategy

3.6.1 Documentation and Agile

Architecture depends on the criticality of documentation. Those of you familiar with Agile know that we should not be over-documenting. The right amount of documentation is enough to keep everyone aligned; documentation for its own sake is a failure mode.

The working test: documentation earns its place when someone will read it to make a decision — a coder implementing a module, a stakeholder approving an approach, a new team member coming on board. If no reader exists, the page is waste, however well written.

3.6.2 UML Expectations

If you intend to become an architect, and you are not familiar with UML or with design patterns, use this course as an opportunity to go through the video sessions on design patterns (they come from a separate course on object-oriented design; they are not part of this course, and they will not be taught here, but they are a good idea for anyone intending to stay in this industry without a prior design course).

3.6.3 Keys and Legends

A key in a diagram is always helpful; it gives you a lot of independence. If you use standard UML and write that you are using standard UML 1.0 or 2.0, we know you are using the vocabulary provided by UML. But if your company or your team chooses to use vocabulary informally, you can define it: any box of this shape is a module, a hexagon is a component, and an arrow with two ends is a request-reply. The moment the reader sees a hexagon, they know you mean a component. A key can be very helpful in any diagram.

3.6.4 Study Strategy and the Examination

This is a master's course, not an undergraduate course, so vocabulary matters. You are expected to understand the vocabulary, and you are encouraged to use Google or ChatGPT for it — some people take offense at being told to look things up, but you have to go with the times. When certain technologies and items are available, you have to move forward. Since this is a broad-view course, we will not go into great detail on individual items. If something fascinates you, dig deep into it; there is a lot of material available on every word uttered in this course, enough for a research assignment. But understand the course broadly. People who worry more about quizzes and tests than about the course get it backwards.

The best way to approach tests and quizzes in a course like this — definitely true for software architecture — is the 80-20 rule, the Pareto principle (roughly 80 percent of results come from 20 percent of causes — here, a broad view yields most of the marks). Get a broad view of the course; do not go into too much detail unless it fascinates you. If you try to dip too deeply into any given item, you will be intimidated, you will find the course too vast, and you will not be able to approach it. But if you have problems with vocabulary, the language used in the course material, you must Google it, or use ChatGPT for something more elaborate. You should not fall short on vocabulary, because the most common mistake in the examination papers is people misunderstanding questions.

On evaluation: this course has multiple faculty, and they are not junior faculty — each has about 20 to 30 years of experience, which this very advanced course requires. Every paper is checked by all the faculty. A question may have parts — A, B, C, D — and those parts could be independent questions themselves. Question number one, for all the students registered in the course, is corrected by the same faculty, so any bias a particular faculty has is common across all students. That removes the unfairness that appears when two different faculty correct the same question on different scales. You may not tune on with faculty one, but you will probably tune on with faculty two or three. Architecture, like any design, is a bit of an art in addition to being a science, so there is a lot of scope for subjectivity. Even people who believe they are right can find their perspective does not agree with what was expected. With different faculty correcting each paper, you will not be completely swept off your feet by one person's thought.

3.7 Requirements: Functional, Quality Attributes, and Constraints

Every system carries three kinds of requirements, and only some of them shape the architecture. Knowing which is which tells you where to spend architectural effort.

3.7.1 Functional Requirements

Any software system will have functional requirements: what will the system be expected to do. A barometer app measures barometric pressure; WhatsApp sends messages; Word is where you type letters; Excel is where you make spreadsheets; PowerPoint is where you make presentations; a point-of-sale application sits on the counter in a mall and handles billing. Functionally, you can determine what the application does.

3.7.2 The Point-of-Sale Walkthrough

All of that is functionality. But what about quality attributes?

3.7.3 Quality Attributes

Today what has emerged as certainly the most important quality attribute seems to be usability, followed by security. People never saw usability as a major quality attribute — "software should be user friendly" was left at that. Today you have got to quantify user friendliness; you have got to define it. If your application is not usable, any amount of performance, availability, scalability, or testability means nothing — the application will simply not be used by anyone.

3.7.4 Constraints

Typical constraints: "the system will use programming language X," "you will reuse this existing module," "the platform will be our in-house cloud." Each is a design decision someone else already made — your job is to accept it and reconcile the rest of the design around it, not to relitigate it.

3.7.5 Which Requirements Reach the Architecture

Some functional requirements are architecturally sensitive — only some. To achieve those functional requirements, you might need to handle them in the architecture. For example, you have to do billing at remote locations with limited connection: it is a functional requirement that you have to do a particular type of operation. Many people will say that is a usability issue; we will not get into arguments. We accept that certain functional requirements may require architectural consideration. Constraints will definitely need to be attended to architecturally, because you have to factor into the architecture that you do not violate the constraints. Quality attributes are 100 percent architectural — they can only be approached architecturally.

Functionality does not determine architecture — but that is not always true. Lots of different architectures can achieve the same thing. Functionality and quality attributes are orthogonal: they may be totally unrelated; they are different dimensions, different aspects of the same personality. It is the same system; it has certain functionalities and it has quality attributes. To that extent, quality attributes are the major concern of the architect. But there are certain functionalities that will dictate your choice of architecture. You can search for examples of functionality that requires architectural consideration, and this course takes some up too.

Picture two dials on the same control panel: one dial sets what the machine does, the other sets how well it does it. Turning one does not turn the other — except at a few marked positions where the mechanisms physically interlock (the architecturally sensitive functions).

3.7.6 The Green Button Example

3.7.7 Influences on Architectural Decisions

The full loop of influences runs like this. There is a system of interest, and the moment the system exhibits an architecture, you get a feeling that this is what I require. The stakeholders have an interest in the system. The architectural description identifies the stakeholders. The stakeholders have concerns, which they express, and the architectural description has to address the concerns. You frame an architectural viewpoint, which is also factored into the architectural description. You make a model based on the architectural viewpoint, and based on the model you create an architectural model. The architectural model contains certain structures, which are presented in views. The architectural description is shared with people, and a lot of correspondence is generated around it. The architectural description has to have some reasoning: the architect has to explain why certain choices are being made. Based on all the choices, you create an architecture, and it has to tally with the requirements of the system of interest.

This whole framing has been given as an ISO/IEEE specification for architecture description — the standard numbered ISO/IEC/IEEE 42010. One needs to look at it, though what you have done in the earlier sessions is enough to understand the architectural context.

In industry, this triage happens in every project kickoff: product owners bring feature lists (functional), platform teams bring mandates ("deploy on our Kubernetes cluster" — constraints), and the architect negotiates the non-negotiables of speed, uptime, and safety (quality attributes) that will actually decide the system's shape.

3.8 Specifying Quality Attribute Requirements with Scenarios

3.8.1 The Quantification Problem

Suppose the customer says the software should be modifiable — it could be usable, secure, performant, anything. You finish developing your product, and the customer says, "I do not find the software modifiable." You say, "We made it very easy to modify." There is a difference of opinion, and you do not get the payment.

3.8.2 The Vocabulary Problem

Each attribute community develops its own vocabulary, so different people use different words and there can be a difference in understanding. The classic case, seen over the last 20 years: the client told you the system should be user friendly; you promised it will be user friendly; you come up with a system you believe is very user friendly; and the customer says this is not my idea of user friendly, followed by some unutterables you have to accept, because the person paying you is the client.

Through all this interaction with the user, you start developing a common vocabulary, and the customer sometimes gives it a name. One user described wanting an accordion-type screen that opens up on the left — today, accordion has become a pattern. Another described breadcrumbs: the trail can break up and you should be able to go back, knowing exactly where your page has navigated. Today these are design patterns — a breadcrumb pattern — familiar to anyone working on web development. They are not part of this course, statutory warning. While discussing a course at this level, one tends to use vocabulary from all over the world; that does not mean you start memorizing every utterance. When examples come from various domains, technical jargon from those domains appears, and you should not allow that to frighten you into thinking you are supposed to have that level of knowledge in every domain.

Real-world: you will meet ERP (Enterprise Resource Planning — integrated business software for finance, inventory, HR) and CRM (Customer Relationship Management — software tracking customers and sales) terminology. The standard application software running in the world uses these terms; if you have just one year of IT experience and you happen to be in an area with nothing to do with ERP or CRM, Google it, because the course will not run discussions on those topics. In the previous year's paper there was a question on SAP, and a student asked how they were expected to know the full form of SAP. With broad reading you may not know what SAP is or which country it was developed in, but you will know what an ERP solution is, and that SAP is one of the popular ERP solutions — famous ones like Oracle Apps and SAP are discussed. If at that stage you do not know what an ERP is or what a CRM is, you will meet terminology like this while going through the course, and you cannot afford not to understand what these stand for — that is the general vocabulary this course expects. When a question appears, the faculty are usually careful and give enough indication in the question itself about what it is about, so sometimes you can answer even without understanding what exactly ERP stands for. Even people with a cursory idea of ERP are not expected to know the details of how an ERP system works. But when the discussion is about quality attributes relating to the system, you should be able to appreciate what is meant by the availability or performance of any system in place of ERP — the question could as easily have said "XYZ system"; ERP was just a nice-sounding name. Do not allow yourself to get scared by jargon in this course. And any amount of dialogue with the stakeholders is a good thing.

3.8.3 Anatomy of a Quality Attribute Scenario

When we talk about quality attributes, we talk about availability, performance, testability, maintainability, security, scalability, usability. For any of these, the attribute acts on an artifact. The artifact is the centerpiece for looking at any quality attribute that relates to it. The artifact responds to a stimulus, and the stimulus has a source — it could be a programmer, a user, or another subsystem. The artifact gives rise to a response, which has to be measured.

Any response will also be dependent on the environment in which the artifact is placed. Standard environments are test, stage, dev, and prod environments. There can be variations: a prod environment with overload, an environment with certain systems under breakdown or stoppage. So, under various environments, you have to specify the stimulus, the source it comes from, the response, and how the response is to be measured.

A picture worth keeping: draw six boxes left to right — source → stimulus → artifact (with environment written underneath it) → response → response measure — and arrows flowing through them. Every quality attribute discussion in this course will drop into those same boxes with different contents.

3.8.4 General Scenarios in Practice

Examples of artifacts: the processor, the communication channel, the storage unit, the processes, a server, client machines, a service that has been provided. What stimulates that artifact could be an omission or a commission, a crash, incorrect timing, an incorrect response — anything can be a stimulus. It acts on the artifact to get a response.

When any of these things happen to an artifact, the response should ensure that the fault is not allowed to become a failure. Some corrective action should be taken immediately. Definitely you should lock the problem that has taken place. Disable the source: if there is a denial-of-service attack, immediately shut down those IPs. You could mask a particular type of request. You could run the system under degraded mode.

Where does the stimulus generate from? Stimuli can be automated or personal. Personal stimuli come from people — the infrastructure people, the designers, the users. Automated stimuli are auto-generated from software or hardware through interrupts; the physical infrastructure may generate certain signals, and the physical environment may generate them. So you must know where the stimulus comes from and how to measure whatever response you get.

3.8.5 Measuring the Response

There has got to be a yardstick for measuring. If it is availability, the measure is for how much time it was not available. If it exceeds a certain amount, a service level agreement (SLA) is invoked and there might be a penalty to be paid. There may be an escalation: if the downtime is more than a certain amount, senior people get involved and salvage the situation, because people at the lower level may have missed the problem, or out of fear they are not escalating, or they feel they would be able to handle it — but as a corporate you want it scaled up and attended. Other availability measures: what percentage of the time the system is available, how much time it can be run in degraded mode, how much time is required to set things right.

For a modifiability request, the nature of the request can be categorized using function point analysis. Function point is a method followed by the Rational group at IBM, which has a lot of international following. There is a function point user group that measures the quantity of software activity to be done for a particular task — it is called function point measurement, practiced by the user group of which you can also become a member: the Function Point User Group, FPUG for short. Other measures include the amount of time required to set it right, the repair time when there is a breakdown, and the proportion of faults that get handled by the system versus how many had to be handled manually.

This six-part discipline runs the industry's biggest contracts: cloud providers publish availability targets ("99.99 percent uptime") precisely because SLA penalties demand measurable responses — the same scenario anatomy, priced.

3.9 Achieving Quality Attributes with Tactics

3.9.1 Strategy, Tactics, and Operations

Once a quality attribute requirement is written as a scenario (Section 3.8), the next question is how to actually achieve it. To achieve quality attributes, we have tactics and we have patterns.

The mapping is exact: patterns are the national strategy (the broad arrangement), tactics are the team-building choices inside that arrangement, and operations are the running code. A pattern packages several tactics together; a tactic tunes one response inside any pattern.

3.9.2 What Makes a Tactic Dependable

Tactics are documented methods and tested methods. You can develop the tools programmatically or through hardware elements to implement a given tactic, and you know that this tactic is going to work in such a situation. That is why we use tactics — it is a very systematic way of working.

That prescription logic also explains where tactics sit relative to tradeoffs: a tactic focuses on one quality attribute response at a time; weighing its side effects on other attributes is the architect's separate job. Adding redundancy lifts availability but costs money and can slow writes — the tactic does the lifting, the architect does the weighing.

3.9.3 Choosing the Right Tactic

A worked miniature of correct prescribing: a case study says "the payment service must survive the crash of one server without dropping transactions." The fitting tactic is active redundancy — run two instances and fail over — because the stimulus named is a component crash and the required response is uninterrupted transaction handling. Quoting every availability tactic from the textbook earns nothing; naming this one, with that reason, earns the marks.

This diagnose-then-prescribe discipline mirrors how site reliability engineers work in industry: an incident review names the failing response (latency spiked during failover), then selects the specific mechanism (health-checked failover with connection draining) rather than applying every high-availability trick at once.

3.10 Guiding Design Decisions: Seven Management Approaches

Besides tactics, there are management approaches that architects take. They are listed under seven categories: allocation of responsibility, coordination model, data model, management of resources, mapping among architectural elements, binding time decisions, and choice of technology.

3.10.1 Allocation of Responsibility

You want to solve a particular problem. You understand the problem, understand what the functionality of the system is, what type of architectural infrastructure you have, and find out how you will be able to use the infrastructure to achieve the quality attribute. The responsibilities can sit with certain modules or components, or with connectors — see how you can allocate the responsibilities appropriately. Sometimes you might like to divide the responsibility. If the load is too heavy for one server to handle, you go in for load distribution and spread the load over multiple servers. If there is not enough capacity in the server, you might increase the memory or change over to a solid-state hard disk, or distribute the processing load. The responsibility can be reorganized between modules, components, and connectors.

3.10.2 Coordination Model

For quality attributes to be achieved, you have got to take care of your timing. Concurrency means activity happening together, with asynchronous communication between the activities. Certain activities should be completed; you should have completion, correctness, and consistency — these are the properties you look for. Through a proper coordination environment between various elements, you change the communication method.

Synchronous and asynchronous matter too: the moment you have synchronous communication, it becomes a bottleneck, because once there is an outward communication you cannot carry on until you get a response, so you might like to work asynchronously. The model may need a change in the coding or in the method of handling to manage asynchrony. Guaranteed delivery puts a lot of load into checking; if the guarantee is not a necessity of the system, you may enhance the performance by not asking for the guarantee. These are the coordination decisions that can impact quality attributes.

3.10.3 Data Model

The data model decides how you will store the data: distributed or local; whether you maintain a data mart or warehouse old data; whether you keep concurrent data available in the mart; whether certain data lives in SQL while other data sits in object storage. You might go in for data at different grades of latency: certain data will be available for current use, some of it may be just archived and retrieved on request, and you might pre-process certain data so that you can get a quick response. These types of decisions can be taken on the data model.

3.10.4 Management of Resources

Management of resources covers how many servers there will be, whether you will go for load sharing or load distribution, what type of storage elements you will use, what type of processing capabilities you will use, whether you will have multi-processing, and what type of communication network will carry the communication load.

Real-world: there are situations where huge volumes of data — petabytes — are best moved by flight; if you work it out, for certain locations a physical transfer is the best way to move data to its destination in a short time. Not everything goes physically, of course. How you manage your resources is one of the ways an architect decides how to approach a quality issue.

3.10.5 Mapping Among Architectural Elements

Mapping is actually matching a functionality with components — the components could be hardware components or software components. When you have certain processes running, the allocation to the processes could be dynamic: you can map them to various processes depending on the load. In a distributed processing environment, you might be able to use lots of latent resources lying idle for processing. That can be an architectural solution: use local processing power to bear the load.

3.10.6 Binding Time Decisions

Those new to IT may not be familiar with binding time. Binding means fixing a variation point — deciding, at some moment, which concrete option becomes real. There are two predominant types of binding: runtime binding and compile time binding. Compile time binding is binding at design time: when you design the system, you decide which component will use which component and how they will interact. In a runtime binding situation, while the application is running, the resources are dynamically allocated. In the case of programs, that means calling objects, classes, instantiating classes. In an architectural situation, it means the use of servers and third-party resources — while running, depending on the load requirement, you may use resources. In today's environment you may even vary the quantum of memory and hardware storage dynamically.

Every one of the other six categories carries a binding time question: should this choice be frozen now (compile/design time) or kept flexible until runtime? Late binding costs mechanisms (negotiation, lookup, instantiation logic) but buys flexibility; early binding is cheap but brittle.

3.10.7 Choice of Technology

The choice of technology covers whether you will use the cloud, an in-house cloud, or in-house infrastructure with machines on site; whether you will use simulators; whether you will use test tools; what type of infrastructure you will be using; and whether you will deliver on tablets, desktops, or mobile. These choices are made by the architect to assure that the quality attributes are achieved.

These seven headings are how mature engineering organizations structure architecture review checklists: each proposal is walked category by category so no dimension — responsibility, timing, data, resources, mapping, binding, technology — escapes a conscious decision.

3.11 Summary: Six Scenario Components and Seven Design Decisions

3.11.1 The Six Scenario Components

In summary, we have seen functional requirements, quality attributes, and constraints. We have seen the six components of a scenario, which you should know by rote, because there is a typical question where you are asked to describe quality attribute scenarios.

A quick self-test that forces recall: take any app on your phone (say, a maps app) and fill all six boxes — source: the user's finger tap; stimulus: a route request; environment: normal operation with weak network; artifact: the routing service; response: a route is computed and drawn; response measure: route shown within two seconds. If any box stays empty, the requirement is not yet testable.

The confusion is understandable — both use-cases and scenarios describe interactions. But a use case narrates what the user accomplishes step by step, while a quality attribute scenario pins down how well one stimulus-response pair must behave. Different tool, different question.

3.11.2 The Seven Design Decision Categories

We also talked about the seven categories of design decisions: allocation of responsibility, coordination model, data model, management of resources, mapping among architectural elements, binding time decisions, and choice of technology.

Exam Guidance Summary

• Follow the 80-20 rule, the Pareto principle: get a broad view of the course; do not dive too deep into any single item unless it fascinates you outside the course.
• Vocabulary matters in this master's course. Google it or use ChatGPT; do not fall short on vocabulary, because the most common mistake in the examination is misunderstanding questions. The 12th Fail story — an answer prepared for terrorism rattled out for a tourism question — is the warning against mentally rewriting the question to match your preparation.
• In the answer script, do not write code (for example, JavaScript for model-view-controller). The approach earns the marks — a four on eight is an average mark, and effort spent reaching five does not help. Aim to be able to answer every question in the paper with a broad view.
• Read all the course material, including the prepared video sessions, and the textbooks if time permits. At minimum, understand the material well enough to land above-average marks.
• In the examination, speak in terms of the quality attributes studied in this course (performance, availability, security, scalability, testability, maintainability, usability), not the 30-plus or 100-plus variants found online.
• Know the six components of a quality attribute scenario by rote (source of stimulus, stimulus, environment, artifact, response, response measure). There is a typical question asking you to describe quality attribute scenarios — do not answer with an object-oriented use-case text.
• Do not reproduce the entire page of tactics for a quality attribute. Prescribe the one tactic that fits the case study, with the reason why it will work.
• Diagrams: exact syntax is not required in an architecture course; an English description of components and interactions suffices. But a key or legend in your diagrams is important, particularly for assignments.
• Evaluation: every paper is checked by multiple senior faculty (about 20 to 30 years of experience each); the same question is corrected by the same faculty for all students, so bias is uniform. Architecture is partly an art, so some subjectivity in evaluation is normal.
• Revaluation: do not beg for marks. Demand a change with very good reason, pointing out exactly what was asked and what was given. Marks can go down on rechecking, even for honesty — the paper is simply re-evaluated.
• Do not let jargon scare you: ERP, CRM, SAP, and similar terms. Questions usually give enough indication of what they are about; a question that says ERP could as easily have said "XYZ system".

Key Industry Applications

• Real-world: point-of-sale (POS) systems in malls — scanning, weight verification, QR codes, cash help desks, gate verification — illustrate functional requirements; WhatsApp, Word, Excel, PowerPoint, and barometer apps are everyday examples of functional software.
• Real-world: usability has emerged as the most important quality attribute, followed by security; user friendliness must be quantified through proof-of-concept (POC) negotiations — big red help buttons, help videos, per-field messages, tooltips, type-ahead drop-downs.
• Real-world: web UI patterns born from customer vocabulary — the accordion screen and the breadcrumb pattern — are now standard design patterns.
• Real-world: enterprise terminology — ERP solutions like Oracle Apps and SAP, CRM systems, POS systems — appears in industry and in exam questions; a broad reading of application software covers them.
• Real-world: module structure data models span NoSQL Hadoop stores, RDBMS systems like Oracle and SQL Server, local text files, mobile storage, in-memory objects, and arrays; distributed and cloud data introduces replication, regional data, and update decisions.
• Real-world: component-connector decisions involve service consumption over SOAP or REST and synchronous process communication.
• Real-world: degraded-mode operation appears in banking (reports shut down, transactions only, "service not available" messages) and in stock exchanges, which call it market open mode — no reports during exchange hours.
• Real-world: availability is governed by service level agreements (SLA) with penalties and escalation; modifiability can be sized with function point analysis from the Function Point User Group (FPUG), following the Rational group at IBM.
• Real-world: resource management may even mean physically shipping petabytes of data by flight when that beats the network.
• Real-world: choice of technology covers public cloud, in-house cloud, and in-house infrastructure, simulators, test tools, and delivery targets such as tablets, desktops, and mobile.
• Real-world: runtime binding appears in modern environments as dynamic memory and hardware storage scaling while applications run; distributed processing can put idle latent resources to work.

Each of these threads back to a lecture concept: the POS walkthrough grounds functional requirements (3.7), POC negotiations ground scenario quantification (3.8), degraded mode grounds stimulus-response decisions (3.8), SLAs ground response measures (3.8), and dynamic scaling grounds binding time decisions (3.10).