Quality Attribute Scenarios, Availability, and Interoperability

4.1 Requirements Review: Functional, Non-Functional, and Constraints

4.1.1 What Is Architecturally Relevant

Software requirements come in three kinds, and the split matters more than it first appears.

Functional requirements state what the system must do and how it must behave when things happen at runtime. An airline booking system shows the functional side at its plainest. You open the flight form, type the number of passengers, and fill in passport details. Searching flights, holding seats, and issuing tickets are all functionality: they describe how the booking gets done.

Quality attribute requirements (often called non-functional requirements) are qualifications of the functional requirements or of the whole product. They answer questions like: how fast must the search return? How often may the booking page be down? How easy is it for a first-time user to complete the purchase? A quality attribute is a measurable or testable property of a system that shows how well it serves its stakeholders. The testability part matters: "fast" is a wish, "search results in under two seconds for 95% of requests" is a requirement.

Constraints are fixed limits you design around. A constraint is a design decision that has already been made — it has zero degrees of freedom left. Mandated platforms, a fixed programming language, a locked budget, or a rule that an existing module must be reused are all constraints. They usually come from outside the architect's control: a business agreement with a supplier, staff who cannot be retrained, or a management decision already announced.

A laptop purchase makes the three kinds concrete:

Where do quality requirements come from? Sometimes the client knows exactly what is needed and states the quality requirements directly. More often, the client says only "make it good" and the architect has to draw the real requirements out — by asking about failures the business cannot tolerate, response times users expect, and changes the system must survive — and then pin them down in measurable form.

The IEEE specification lists the aspects a proper architectural description should consider. We use it as our reference frame when we describe a system, so that nothing important gets left out simply because nobody thought to ask.

4.1.2 The Quality Attributes Studied in This Course

No course can cover every quality anyone has ever named. We pick a handful and study them deeply:

• Modifiability — how easily the system changes (a development-time property).
• Availability — how often the system is up and ready (a runtime property).
• Performance — how much work it completes per unit of time, and how quickly it responds (runtime).
• Usability — how easily users learn and operate it (runtime).
• Testability — how easily you can show the software behaves as intended (development-time).
• Maintainability — how cheaply faults can be found and fixed after release (development-time).
• Security — how well it resists attacks on its data and services (runtime).

Notice the natural split: some qualities describe the system in operation, others describe the work of building and changing it. The working assumption of this course: if we understand these attributes deeply — how to specify them, trade them off, and design for them — we can handle the rest, because they all follow the same pattern.

4.2 Problems with Quality Attributes

4.2.1 Measurement, Trade-offs, and Contending Specialists

Three problems make quality attributes hard.

Problem one: you cannot design against a vague wish. You need a way to judge each attribute. A wish like "fast" or "always up" cannot be designed against, because it cannot fail a test. Is five seconds fast? For a stock-exchange order, no; for a monthly report, yes. Every system is modifiable with respect to some changes and rigid for others, available for some faults and brittle for others. So you need a quantitative method to specify what you want — numbers, units, and conditions that let anyone check pass or fail. Section 4.3 introduces exactly this tool.

Problem two: quality attributes fight each other. Push more of one and you lose some of another. Every gain is a trade-off. Making software portable means isolating everything platform-specific behind boundaries, and those boundaries add call overhead that slows the system down. Adding security checks adds latency. Maximizing availability with redundant hardware costs money and complicates every change. Almost no quality improvement is free.

Problem three: different people own different attributes. Each attribute has a community with its own specialist, its own vocabulary, and its own priorities:

The vocabularies do not even match. The performance community describes an event arriving at the system, the security community an attack, the availability community a failure, the usability community user input — four names that can describe the very same occurrence. Even ownership gets contested: when a denial-of-service attack takes a site down, is that an availability problem, a performance problem, a security problem, or a usability problem? All four communities have a claim.

Put the three problems together and you get the architect's real job. When requests come in from the client, everybody wants everything: the performance engineer wants speed, the infrastructure team wants uptime, the security staff want locks everywhere. Someone has to make them face the trade-offs — to say out loud which gain justifies which loss, and get the stakeholders to agree. That someone is the architect.

A household decision shows the shape of the problem. A family choosing an apartment hears from everyone at once: one member wants short travel to work, another wants a big kitchen, a third wants low rent, a fourth wants to stay near school. Each demand is reasonable alone. Together they are unaffordable. The family only moves forward when someone lays the options side by side and makes the trade-offs explicit — give up the big kitchen to cut the commute, or pay more rent to keep both. Nothing in the apartment itself changed; what changed was that the conflicts became visible and got decided.

4.3 Quality Attribute Scenarios

4.3.1 The Six Parts of a General Scenario

A quality attribute scenario turns a vague quality wish into a testable statement. It has six parts:

1. Artifact — the thing under discussion. It can be a piece of software, a server, a piece of equipment, or the network. Frequently it is the whole system, but calling out the exact piece matters: a failure in a data store may be treated very differently from a failure in a metadata store.
2. Stimulus — something happens to that artifact. A stimulus is a condition that requires a response when it arrives: an event for the performance community, a user operation for usability, an attack for security, a fault for availability.
3. Source — where the stimulus comes from. The source can change how the system reacts: a request from a trusted internal component gets less scrutiny than the same request from an unknown external one.
4. Environment — the conditions at the time. The same stimulus may deserve different treatment in normal operation than during overload, startup, or shutdown. A modification request before code freeze is routine; the identical request after freeze is a different story.
5. Response — what the system does about it. The responsibilities the system (for runtime qualities) or the developers (for development-time qualities) carry out when the stimulus arrives.
6. Response measure — how we measure that response. Without a measure, nobody can say whether the response was good enough.

The measure matters most, because measurement is a big part of the architect's job: it is what turns a promise into a contract. And the environment deserves separate thought. A specification written for a broad production setting may fail in development or in a lower staging environment — machines there are smaller, data is thinner, and networks are shared differently. Write the environment down, or the requirement will be argued about forever.

Scenarios come in two flavors. A general scenario is system-independent: a template of possible values that could apply to any system. A concrete scenario fills the template with values for your particular system. Architects first agree on the general shape, then instantiate it.

Picture the six parts laid out as a flow: the source sits on one side and fires the stimulus; the stimulus travels to the artifact, which sits inside its environment (drawn as a box around everything); the artifact produces a response, and the response is judged by the response measure. Read left to right, it is just a disciplined story: who did what, to what, under which conditions, and how we will grade the answer.

4.3.2 Sources, Stimuli, Responses, and Measures

Sources sit inside or outside the system. People, hardware, software, physical infrastructure, even the physical environment can act. Another piece of interconnected software can generate a stimulus by calling your interface. Hardware can raise an interrupt. Physical infrastructure can break down or carry a heavy load. Temperature, noise, and humidity matter too — a server room that overheats will take processors down no matter how clean the code is.

The stimulus itself takes a handful of classic forms: a fault that develops, an omission in data (an expected input never arrives), a crash, inputs arriving at the wrong time (too early, too late, out of order), or wrong responses produced by the system. It can strike a processor, the network, storage, or any running process, hardware or software.

Responses form an action plan. The first question: can we stop the fault from turning into a failure? Several moves exist:

• Log and carry on. Record the fault and raise an alert to the right people while service continues.
• Step aside. Take the system unavailable in a controlled way, or run it in degraded mode. Large public platforms do this daily: in banking or on share-market days, non-essential services simply shut down so the critical ones survive the load.
• Defer. Offer deferred service: you ask for a report, the system says it cannot produce it now, promises it by email or into your login slot, and lets you know when it is ready.

These moves keep the user experience bearable under stress. The difference between a system people trust and one they curse is often not whether faults happen — they always do — but which of these moves the architecture prepared.

Every response needs a measure, because you commit to the client: if this happens, we will do that, in so much time. Or: this is the quantum of error we allow. Or: this much data loss is permissible. A response without a measure is a hope, not a commitment.

4.4 Tactics versus Patterns

4.4.1 Big Decisions versus Small Moves: The Sculpture Picture

Patterns are the big decisions that take care of the overall problem. An architectural pattern is a package of design decisions found repeatedly in practice, with known properties that let you reuse it — client-server, layered, broker, and so on. Tactics are small moves that achieve results inside that shape. A tactic is a single design decision that influences one quality attribute response.

Picture making a sculpture of a strong male body. You choose stone of a certain size and quality, knock off big chunks, and settle the size of the head, torso, and legs. That is the pattern level: a few large decisions that fix the overall form. Does that overall strategy carve the details? It does not. So you move to individual parts: you shape the nose so the expression reads correctly. That is tactic level — small, precise work that only matters because the big shape already exists.

The two levels relate in a precise way: tactics are the building blocks, and most patterns are assembled from several tactics working together — atoms and molecules, roughly speaking. One more difference matters when you design. A tactic aims at a single quality response and ignores trade-offs; trade-offs must be handled explicitly by the designer. A pattern, by contrast, has its trade-offs already built into its structure.

When to pick which: choose the pattern when the problem is structural and system-wide; reach for a tactic when the architecture's big shape is settled and one specific quality response still needs help.

4.4.2 Worked Example: Watching a Feedback Server

Say you run a server that collects feedback from users. The overall design is done: web pages set, server located, middleware code written, options provided. The pattern-level work is finished. Now you want daily assurance that the server works and feedback keeps getting deposited. Three small moves can give it to you.

Approach one: a daily report. Count how many feedback items arrived and deliver the number as a notification, SMS, or email. An efficient manager reads it — for thirty days. Then report fatigue sets in: the moment the report arrives unopened and unread, "the report is coming" becomes the signal that all is well. The habit stops protecting you. The report also fails in a specific way: it tells you about yesterday, so a server that died this morning stays dead until tomorrow's summary.

Approach two: use the log. Past experience says at least some feedback arrives every one to two hours. Turn that history into a rule: if a continuous hour passes with nothing deposited, raise an alert — "no feedback has come in during the last hour." This detects silence instead of counting totals, so it reacts within an hour rather than a day. Note the clever part: the broken system itself cannot alert you, so a separate log-based watcher does it. The watcher must live outside the thing it watches.

Approach three: a robotic depositor. A second system automatically submits a test feedback item and waits for the response. When the response fails to arrive, it raises an alert that the server is not working. This is the strongest check of the three: it exercises the whole path — network, server, deposit logic — end to end, like sending yourself a letter to test the postal service. Its cost: it adds test traffic, and it needs its own home so it does not die with the server it guards.

All three are small, easy moves. None needed a new architecture. The skill is remembering they exist.

4.4.3 Remembering to Use What You Know

You already know many tactics, and you will forget to apply them. It is like having a cold: you know the medicine, but busy work makes you skip it. You know you should drink water regularly; you forget anyway. The knowledge was never the missing piece — the retrieval was. Tactics sit out there for you, and an architect is supposed to reach for them. People hunt for big solutions and miss the little things that would do the job. The companion video series explains every tactic in detail; here we practice choosing and applying them.

4.5 The Seven-Point Design Checklist

4.5.1 Seven Questions for Every Quality Attribute

For each quality attribute, seven checklist points guide what you can do to deliver it. Read them carefully — your recommendations will lean on them. Every point is a category of design decision; walking through all seven guarantees no dimension of the design goes unexamined.

1. Allocation of responsibility — assign who or what delivers the attribute. Which components detect faults, which people respond to alerts, which module enforces the rule? A quality nobody owns is a quality nobody gets. Ask: have I named the element (and the human) responsible for each piece of this quality?

1. Coordination model — decide how activities across components coordinate so the goal gets met. This covers the communication mechanisms: synchronous or asynchronous calls, message queues, guaranteed or best-effort delivery, and how elements stay consistent with each other. Ask: can my components actually work together fast enough and reliably enough to meet the goal?

1. Data model — decide how data is handled, stored, moved, and what data is available at each point. Different attributes call for different data handling: security wants encryption and access rules; performance wants caches and summaries; availability wants replicas. Ask: does the shape of my data help or hurt this quality?

1. Managing resources — quality costs resources, and resources cost money; plan them. CPU, memory, network bandwidth, disk, and human operators are all finite. Ask: what resources does this quality demand, who sanctions them, and what happens when they run out?

1. Mapping among architectural elements — remember the three views from earlier material: module breakdown structures (units of development), component-and-connector structures (units of execution), and allocation structures that assign activity to hardware and software. Deciding which modules become which running processes, and which processes land on which machines, changes every runtime quality. Ask: where does each piece actually run, and is that placement right for this quality?

1. Binding time — decide when components learn about each other. With early binding, the relationship is fixed in advance, designed by the architect. With late binding, the choice happens while the application runs: grab the resource, connect, use it, release it. Later binding gives flexibility but adds mechanisms that can themselves fail. Ask: when should this connection be frozen — at design time, build time, or run time?

1. Choice of technology — pick the technology with eyes open about cost and risk. Every abstract decision ends up realized in a concrete product, framework, or protocol, and each carries maturity, licensing, staffing, and compatibility consequences. Ask: what does this technology give me, what does it cost, and what new risks does it introduce?

4.6 Availability

Availability is the first attribute we take through the full treatment: meaning, scenario, tactics, and the seven-point checklist applied end to end.

4.6.1 What Availability Means

Availability means the component that should do the work is there when you want it. It sounds simple; agreements make it precise. A service level agreement (SLA) with a provider might guarantee the server stays available 99.9999% of the time. The agreement also fixes the nature of allowed breakdowns: how much maintenance downtime per year, at what times maintenance may run, and how fast you must come back after a breakdown.

An SLA typically pins down four things:

1. The availability percentage — the fraction of time the service must be usable.
2. Allowed maintenance windows — when planned downtime may happen, and how much of it per year.
3. Recovery speed — how quickly service must return after an unplanned breakdown.
4. Penalties — what the provider owes you when the promise is broken; cloud providers publish these commitments openly and pay service credits when they miss them.

4.6.2 Availability versus Reliability

Engineers do compute availability from measurable quantities. Two numbers drive it: MTBF (mean time between failures — on average, how long the system runs before it breaks) and MTTR (mean time to repair — on average, how long it stays broken before someone or something fixes it). The steady-state availability follows:

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

Read the shape rather than memorize it. Every minute added to MTBF pushes availability up toward 1; every minute added to MTTR pulls it down. If repair became instant ($MTTR\to 0$), then $A=MTBF/MTBF=1$ — perfectly available. If failures never happened ($MTBF\to \infty$), availability also approaches 1. Both limiting cases behave sensibly, which is a quick sanity check on the formula. Textbooks sometimes write the same idea as uptime divided by (uptime plus downtime); here we keep the MTBF/MTTR form to match the lecture.

4.6.3 The Availability General Scenario

The availability scenario follows the six-part shape from Section 4.3, filled with availability-specific values.

Sources and stimuli. Internal or external sources — people, hardware, software, physical infrastructure — signal an availability problem. The stimulus takes one of a few classic forms: omission (you cannot reach the server; an expected reply never comes), crash (omission repeated until the component stops responding altogether), incorrect timing (timing does not match between two hardware elements meant to synchronize; the response arrives early or late), and incorrect response (the response that comes back is not what you expected). Any processor, communication channel, storage device, or running process can be the artifact under attack.

Environments. Normal operation is one environment. Others: degraded operation, startup, shutdown, repair (what services remain while technicians work?), and overload. Overload has familiar faces: a cricket match floods the network; month-end floods the banks. Each environment can demand its own availability promise — being up during month-end may matter far more than being up at 3 a.m. on a holiday.

Responses. Know the fault, plug it, and keep the system from failing. Concretely:

• Log faults so a department can watch the logs and attend to them, with escalation level one, level two, level three.
• Disable the component generating the fault — some facilities may vanish for a while, and so be it.
• Notify users: "the system will be down for so many hours for maintenance."

• Mask the fault: operations continue while the fault sits in a log; you then decide under what conditions operations should stop with an apology instead.
• Shift to degraded mode if the trouble is serious but survivable.

None of this is free: responses cost money, so they get negotiated and written as agreements between stakeholders rather than decreed by one side.

Measures. Time interval during which the system must be available; availability percentage; time taken to detect the fault; time to repair; hours of degraded mode permitted per year; and the rate at which faults get caught before they become failures (for example, "handle up to 100 faults per second without failing"). You design the architecture to hit these numbers.

4.6.4 Orthogonal Qualities, Faults, and Failures

Keep the vocabulary chain straight: fault (the cause shows up) → error (the fault has taken effect internally) → failure (the deviation becomes visible and the service breaks its promise). Availability work lives in the gaps of that chain — detect at the fault stage, contain at the error stage, and the failure never happens.

4.6.5 Worked Example: The ICU Heartbeat Monitor

Modern hospitals wire ICU patients to monitors that watch heartbeats. Data flows to a server. When the server judges that a patient needs immediate attention, it alerts the control room so a doctor goes straight to that bed. There may be several doctors and many more patients; nobody can stand in front of every patient every moment. The automated judge compares waveforms against normal patterns — this is decision sciences and monitoring, whatever label the day gives it.

Availability questions follow naturally. How often may the server miss capturing a heartbeat? The server is a machine; there may be moments when a bed's signal does not arrive. Should the maintenance team learn that "for so many seconds this server has logged no signal from bed so-and-so — go and act"? The cause could be networking, the server itself, or the application misbehaving. Without a watchdog, availability quietly dies.

Note the split: functionality is monitoring the heartbeats of ICU patients; availability is being up while doing it. With IoT the same theory stretches further — a person with a pacemaker can be watched from a remote hospital.

4.6.6 Availability Tactics

The goal: endure faults so they never become failures. One flow to internalize: a fault comes in, gets masked, the system shifts into repair mode, and the service engineer is informed so repair finishes before failure. A live example comes from teaching itself: when the signal kept dropping mid-session, the roles were reversed — another presenter drove the session while the usual speaker became a listener. Availability was assured by swapping roles. A faculty member can drop out for ten minutes of a ninety-minute session and nobody notices.

The tactic families, with every member explained:

Detect the fault — you cannot react to what you cannot see.

• Ping/echo: send a request and wait for a reply; if no echo returns within a set threshold, declare the component unreachable. Measures both reachability and round-trip delay.
• Monitor: a dedicated component watches the health of processors, processes, input/output, and memory, and orchestrates the other detection tactics. When the monitor uses a timer that the watched process must keep resetting, the arrangement is called a watchdog — a process that stops "petting the watchdog" gets flagged.
• Heartbeat: the watched process sends a periodic "I am alive" message instead of waiting to be asked. The difference from ping/echo is who initiates: ping/echo has the monitor ask; heartbeat has the component volunteer.
• Timestamps: stamp events with clock readings to catch wrong sequences of events, mainly in message-passing systems.
• Sanity checking: test whether specific outputs are reasonable — a person's age of 250 or a bill below zero fails the check even though nothing crashed.
• Condition monitoring: check conditions inside a process or device against design assumptions; computing checksums over data is the classic case.
• Voting: run three copies of the same computation on identical inputs and let majority rule; disagreement among the three reports a fault. Triple modular redundancy is the standard realization, with the voting logic kept tiny and rigorously tested because it must itself almost never fail.

Prepare for repair — backups, really.

• Active redundancy (hot spare): all nodes process identical inputs in parallel, so the spare already holds the live state and can take over in milliseconds. One active plus one spare is called "one plus one" redundancy.
• Passive redundancy (warm spare): only the active node works; it periodically ships state updates to the spare. Cheaper than active redundancy, slower to take over.
• Spares (cold spare): the backup sits powered off until needed, then boots and loads state. Slowest and cheapest — suited to systems that need high reliability between failures but can tolerate longer outages.

Recover from the fault — limit the damage and get working again.

• Exception handling: catch the error condition and route it to code that masks the fault, usually by correcting the cause and retrying.
• Rollback: revert to a previous known-good checkpoint — familiar from RDBMS work — then continue from there.
• Software upgrade: find the problem, fix it, roll out an update without stopping service; the routine move in DevOps environments.
• Retry: repeat the failed operation, betting the fault was transient; always cap the retry count so a permanent failure gets declared.
• Ignore faulty behavior: discard messages from a source judged spurious and carry on until the next update or fix.
• Degraded mode: keep the most critical functions, drop the rest.
• Restart: reset the failing component; escalate the restart scope if the small reset does not hold.
• Non-stop forwarding: split control duties from data duties, so packet forwarding continues along known routes even while the control brain reboots — a router trick now used widely.

Reintroduce the service — bring repaired parts back safely.

• Shadow: run the repaired component in shadow mode first, watching its behavior before giving it real traffic.
• State synchronization: refresh the returning component's state from the live one so it rejoins consistent.
• Escalation: widen the restart step by step — thread, then process, then whole subsystem — minimizing affected service at each level.
• Restart and non-stop forwarding also serve reintroduction after recovery.

Prevent the fault — stop it before it happens.

• Removal from service: pull the shaky part out on purpose — telling users "this function is unavailable at present, please try tomorrow morning" — to scrub latent faults such as memory leaks before they accumulate into failure. Also called software rejuvenation.
• Transactions: wrap multi-step updates in all-or-nothing units (the ACID properties) so a half-done update cannot corrupt state.
• Predictive model: watch trends (queue lengths, session rates) and act when the numbers predict a coming fault.
• Exception prevention: design components so error conditions cannot arise — bounds-checked pointers, wrappers around risky resources.
• Increased competence set: widen the range of situations a component handles gracefully, so fewer conditions count as faults at all.

Degraded mode earns a worked story.

4.6.7 Design Checklist Applied to Availability

Allocation of responsibility. Assign components to log faults, notify people or entities, disable events, mask faults, and operate in degraded mode. In IT nothing happens unless somebody planned it: plan the whole arrangement, staff the support people, and give them the task of watching and attending.

Coordination model. Components must coordinate even to log a fault. Notification takes machinery too. Conventionally alerts went out by SMS. Today a monitor duty station gets app notifications, backed by people on duty around the clock. Build a centralized SMS delivery server: all notifications flow to it, and it issues messages with escalation levels attached.

Data model. If not everything needs the same availability, segregate the data. Vertical division splits columns of a table into separate tables; horizontal division spreads rows across places. Shape the split around the availability each part needs. Summary data can be instantly available while detail says "sorry, not at present." Sit with the database architect and configure accordingly. Fewer fields per table pack more rows into one block, so queries run faster and indexing works harder. On results day: pass/fail appears immediately; detail waits. Collect email IDs and deliver detail later, or push the result itself by email — taking the load off the server is itself an architectural choice. Replicate data into caches at various locations as well.

Mapping among architectural elements. Think about processes, communication channels, and storage. Where does data live — behind a proxy, in a local cache, on a central server? A B2B link can push results from the board server to school servers the moment they are ready, so students query their own school instead of the Central Board of Secondary Education portal. Announcement windows can stagger by region: West Bengal 6 to 7, Tamil Nadu 7 to 8, Mumbai 8 to 9. Companies do the same with appraisal systems, giving departments different completion dates so nobody loads the server together.

Resource management. Sanction resources — people, equipment, software. The architect recommends what the effort needs: spare machines, standby operators, monitoring licenses.

Binding time. Binding time asks: when does one component learn it must talk to another? Early binding fixes the relationship in advance, designed by the architect. Late binding decides while the application runs: grab the resource, connect, use it, release it. Failover raises the same question. With hot swappable hardware you switch back and forth freely. With a cold backup you bring the main server down, announce services returning shortly, and commission the backup. Is processor switching on fault detection pre-programmed, or chosen by fault type? How does the linkage trigger?

Choice of technology. IATA grades airlines into level 1 and level 2 by compliance with quality checks, and the United States bars carriers below level 1 from its airspace. Technology choice works the same way. If the company affords level 1 technology, pick it. If only level 2 fits the budget and stakeholders accept the risk after being told, go lower — but the architect lays out cost, benefit, and rating, and stakeholders decide. You recommend fully informed; they choose.

4.6.8 Study Advice: Experience Gaps, Exams, and Quizzes

Doubt clearing opens the next session. Bring questions on any tactic the companion videos left unclear, and they get taken up first.

4.7 Interoperability

4.7.1 What Interoperability Means

Interoperability is the ability of two different systems to interact properly and exchange information, as committed to stakeholders. Two levels hide inside that sentence. Syntactic interoperability means the data crosses correctly: both sides agree on formats, types, and message structure. Semantic interoperability means the receiver interprets the data the way the sender meant it: both sides agree on what the numbers mean. Systems can exchange perfect bytes and still misunderstand each other completely if one sends prices without tax and the other expects tax included. It has become central to modern products.

Uber shows why. The service aggregates taxi operators: drivers register themselves and their cars, customers request rides, cars become available. That sounds like a handful of actors. But Google supplies the mapping, the AI that figures the best pickup plan, and the mechanism that pops up your chosen destination at the right time of day. Remove Google and the product dies. Then payments: the passenger pays online through Paytm, Google Pay, or a card, so aggregators and banks must be up too. The next horizon: the car's own navigation joining in, the way Apple CarPlay or Android Auto loads onto a car's panel — why should a driver prop up a phone?

4.7.2 Everyday Interoperability Stories

Audio gear shows closed ecosystems: buy the Bose mid-range and you must buy Bose woofers, because the system refuses other makers. Computer parts went the other way — buy any hard disk and it fits. One vendor chose lock-in; the industry chose standards, and the open side won the market.

Chargers tell the same story. Newer laptop models ship unique charging ports, so a traveler lands, orders an adapter, and even an eight-connector universal unit can fit none of them — a pure interoperability failure. Every physical piece needed to connect exists, yet nothing works, because nobody agreed on the port. Apple accepting the C-type connector (USB-C) from the iPhone 15 onward freed owners from hunting proprietary chargers; until then, people carried pocket adapters.

4.7.3 The Interoperability General Scenario

Map the six parts onto a charger:

• Source: another system — here, the power board.
• Stimulus: a request to exchange information — electricity trying to enter the laptop.
• Artifact: the laptop.
• Environment: the country you sit in, India or America, since voltage levels differ; modern adapters tolerate 120 to 250 volts, so that part eased.
• Response: the connector does not fit.
• Remedy: get an adapter.

The software version: an online payment must send data in the format the bank demands. Banks hand programmers an integration kit that handles cryptography to their specification; install the component and data crosses a secure channel. The kit is interoperability sold as a product.

Measures: how often data gets accepted or rejected, what percentage of information exchange fails, compatibility trouble counts, and data dropping when the network or signal runs too weak.

4.7.4 Interoperability Tactics

Two families.

Service discovery: many services expose APIs; when you need one — say a GST calculator — a discovery mechanism locates it and makes it available. The textbook name for this family is simply discover service: search a known directory by type, name, location, or attribute, possibly through several levels of indirection, until the wanted capability is found. Discovery matters most when partners meet for the first time at run time.

Managed interface: think orchestra leader. Given your requirement, it finds a compatible service, adapts to the port, and hands you working interconnectivity. Textbooks split this family into two moves: orchestrate, where a control mechanism sequences calls across services that know nothing of each other (workflow engines do this), and tailor interface, where capabilities are added to or removed from an interface — translating data, buffering, smoothing, or hiding functions from untrusted callers. The orchestra leader does both: it picks the players and adjusts each part until the joint performance works.

4.7.5 Design Checklist Applied to Interoperability

Allocation of responsibility. Decide which systems interact with which. Assign components to accept requests, exchange information, reject bad requests, notify, and log.

Then non-repudiation: a person must not deny making the request. Trap the location the request came from, check credentials, keep an authentication server. Logging in an untrusted environment exists precisely so that "I never asked for that" can be answered with evidence.

Coordination model. Watch message arrival times and jitter (arrival-time wobble); unreadable messages; CRC errors arriving too often — log them. Repeated wrong user ID and password attempts matter as well. Merchant flow: you buy on Amazon; Amazon approaches a payment gateway rather than the bank directly; the gateway issued Amazon a merchant ID and password; Amazon sends ID, password, order number, and amount over an encrypted channel. Wrong credentials arriving again and again would get Amazon blocked — unlikely, but the gateway would raise concerns and push stronger security.

Data model. Each interoperating system holds its own data abstractions; the architect works out how abstractions map onto each other and share data. When one side's model is confidential, transformations translate between the private model and the shared one.

Mapping among architectural elements. Carry the mappings across the cooperating systems: which components sit on processors that can reach the network, and how communication meets security, availability, and performance needs.

Resources. Adapters, equipment, harnesses — sanction them. Interoperation consumes real capacity, and a flood of external requests must never exhaust resources needed by legitimate users.

Binding time. When does a system learn of another's request? Some pairs stay permanently connected; others meet over a discovery network — connect, use, disconnect, release resources. Certain hardware stays wired together for life. Each choice trades flexibility against machinery that can itself fail.

Choice of technology. Draw the system boundary; decide whether business logic and database share a home; pick the database; pick communication protocols. Web-service stacks and REST-style interfaces are the standard shelves to choose from — each buys syntactic agreement cheaply, while semantic agreement still takes negotiation between organizations.

Exam Guidance Summary

• Reproducing the tactics sheet earns zero marks. Expect a situation; select the fitting tactic and argue the choice. The argument — why this tactic fits this fault in this environment — is where the marks live.
• The tactics page may sit in front of you in an open book exam — still pick the correct medicine. Access to the list changes nothing about the skill being tested: matching a situation to a tactic.
• Exam questions run much simpler than class coverage. Memorizing is futile; concepts and careful reading win. Class examples run at a far higher level than typical exam questions, so a smaller experience gap is no disadvantage.
• Do not miss the quizzes; the first quiz arrives shortly. Poor marks recover, missed quizzes do not.
• Measuring reliability across series and parallel systems comes in a later session; treat availability and reliability as interchangeable terms for now, with availability building on reliability.
• Doubt clearing opens the next session; deposit questions early — especially on any tactic the companion videos left unclear.

Key Industry Applications

• Ride aggregation: Uber depends on Google Maps for routing and prediction, and on Paytm, Google Pay, card networks — Visa, MasterCard — plus banks and gateways for money movement. Remove any one partner and the product weakens or dies, which is interoperability stated as a business risk.
• Payment infrastructure: integration kits from banks handle cryptography; gateways authenticate merchants like Amazon with ID, password, order number, and amount over encrypted channels. The rejection-SMS flow shows responsibility assignment and non-repudiation working together in production.
• Escalation machinery: centralized SMS delivery servers with L1/L2/L3 tiers and two-hour action windows; managed service providers selling monitoring separately. This is availability's coordination model staffed by real people.
• Public results platforms: boards in the Central Board of Secondary Education style stagger regional windows (West Bengal 6 to 7, Tamil Nadu 7 to 8, Mumbai 8 to 9), sync B2B to school servers, deliver by email, split users by ID range, and redirect across cities and cloud servers — degraded mode and mapping decisions at national scale.
• Examination servers: client-side paper download, 100-character option-string upload, off-hour evaluation. Mapping work among architectural elements that shrinks peak load to a trickle.
• Healthcare IoT: ICU heartbeat monitoring and remote pacemaker supervision — availability tactics guarding systems where a missed fault is not an inconvenience but an emergency.
• Standards ecosystems: IATA airline grading (with the United States barring sub-level-1 carriers from its airspace); USB-C adoption from the iPhone 15; Bose closed audio stacks versus interchangeable PC hardware. Technology choice and interoperability standards shaping whole markets.
• DevOps practice: software upgrades as a recovery tactic; rollback habits inherited from RDBMS work.