The Review That Cannot Close
The missile is hanging beneath an aircraft wing. In the briefing photograph it looks finished: a smooth body, external surfaces, and the familiar outline of a guided weapon. The program team has spent months describing the parts. Today, the review board has one deceptively simple question. Is the system ready?
Imagine three answers. The hardware team says the missile's major assemblies have passed their individual checks. The aircraft team says the missile fits the approved mounting arrangement. The support team says the equipment can be received and accounted for. All three answers may be true. Yet the board still cannot close the review. Nobody has demonstrated that those facts add up to the complete capability being claimed.
This is a fictional review, not a report about an actual program. And the object beneath the wing is fictional too. We will call it A R V zero one. It is a composite air-launched guided missile invented for this curriculum. Any feature we give it is an illustrative assumption, not a specification of a real weapon. We will return to this same imaginary system in later episodes, rather than inventing a new example every time an engineering concept becomes difficult.
Why can't the board close? Perhaps the answer lies inside the missile. Perhaps it lies at the connection to the aircraft. Perhaps the team has drawn the system boundary too narrowly. Or perhaps the word ready means something different to each reviewer.
In our earlier landscape episode, we learned four ways to locate a weapon on a map. What carries it? What guides it? What does it engage? What effect does it produce? That map helped us ask sensible questions about unfamiliar weapon families. Today we change the question. We already know what sort of object we are looking at. What we don't know is how the complete system hangs together.
For our tour, assume A R V zero one contains sensing, onboard computing, a means of estimating its motion, guidance and control functions, propulsion, mechanisms that respond to commands, an intended-effect payload, electrical power, and a supporting structure. Assume it has interfaces with a compatible host aircraft. We are deliberately leaving range, speed, dimensions, performance, and internal arrangements unspecified. They would add apparent precision without helping us learn architecture.
By the end, I want you to see three things when you look at that photograph: responsibilities inside the object, relationships crossing its boundary, and evidence that would be needed before anyone could honestly say the system is ready. The review board will be waiting for our answer.
The Boundary You Choose
Start at the aircraft. The missile hangs beneath it, but hanging is only the visible relationship. Before flight, the host aircraft may provide physical support, electrical services, information, and a means of releasing the store. Exactly which services exist depends on the design. Our fictional missile has no universal interface that makes it compatible with every aircraft.
Imagine drawing a circle around the missile. Inside the circle are the items we have decided to treat as the missile itself. Outside are the aircraft, ground equipment, operators, maintenance organization, and wider mission system. A line crossing the circle represents an interface. The line matters because information, energy, force, or responsibility may have to cross it.
Now draw a larger circle around the aircraft and missile together. You have not changed either object. You have changed the question. Inside this larger boundary, an issue that looked like an external dependency may become a problem the combined system must resolve. Move the boundary again, and maintenance, training, and logistics enter the picture.
There is no single boundary that answers every engineering question. A manufacturer may define a product boundary. An integration team may define an aircraft-and-store boundary. An operator may care about the complete supported capability. Confusion begins when people use the same word, system, while drawing different circles in their heads.
Return to our hangar. A missile can be physically attached to an aircraft without being fully integrated with it. Mechanical fit does not establish that the right information can pass, that the aircraft and missile behave together as intended, or that the organization can safely sustain the capability. We met this distinction in the landscape episode. Here it becomes our first architectural rule.
An interface is not just a connector. It is an agreement about what two sides exchange and what each side can rely upon. A physical connection may carry loads. An electrical connection may deliver power. A data connection may exchange messages. A human interface may present status to an operator. Each connection creates a place where assumptions must meet reality.
We will devote another episode to interface thinking. For now, hold onto the picture of the circles. The missile has an internal architecture. The aircraft and missile have an integration architecture. And the mission depends on an even larger system that cannot fit in a photograph.
The Jobs Hidden Inside
Now imagine the outer skin becoming transparent. We are not opening a real missile or studying a manufacturing drawing. We are building a conceptual picture, with only enough detail to understand the jobs that must be done.
Start with the information side of the story. A sensing function gathers observations about the world. A sensor might detect a feature, measure a signal, or provide another observation relevant to the system. That observation is not automatically a trustworthy conclusion. It has meaning only when other functions interpret it, and it may have uncertainty or limitations.
Navigation answers a different question: what do we know about the vehicle's own position and motion? It may use measurements and estimates rather than a single perfect answer. Guidance then concerns the intended path or motion, based on the information available and the system's defined purpose. These words sound close together, so it helps to hear their differences. Sensing observes. Navigation estimates where the vehicle is and how it is moving. Guidance determines what motion is wanted.
But wanting a motion does not produce it. Control concerns how the system responds to that desired motion. Actuation provides a possible physical means of making a commanded change. The controller and actuator are not synonyms. One is a responsibility for producing the appropriate response; the other is a class of mechanism that can help make the response real.
Think about driving in an unfamiliar city. You look out the window and observe the street. You estimate where you are. You decide where you need to go. You make steering and braking corrections. And the car's mechanisms respond. You may also receive a message with updated information. That message changes what you know; it does not by itself turn the steering wheel. The analogy is imperfect, but it protects us from treating sensing, navigation, guidance, control, and communication as one mysterious thing called intelligence.
Where do computing and software fit? They may support several of those responsibilities at once. A physical processor is not identical to the function it performs. A single item can support multiple jobs, and a single job may depend on multiple items. That is why an architecture cannot be inferred from the number of computers on a parts list.
Next, picture the functions that supply physical movement and response. For our fictional missile, we assume a propulsion capability. Propulsion provides a means of producing thrust; it is not the same as guidance. Actuation concerns controlled physical response. We are not assigning particular hardware, performance, or locations to either function. Other weapon families can organize these responsibilities differently. A guided bomb, for instance, need not carry propulsion.
Now consider the payload. In our teaching model, it is the part associated with the intended physical effect. That tells us nothing about its detailed design, and we will not supply one. It also does not tell us whether a larger mission has succeeded. An intended effect, a demonstrated physical result, and an operational outcome remain different claims.
Electrical power supports many of the jobs we have just named. Structure supports the physical relationships among elements and the conditions they must withstand. Both are easy to overlook because neither is usually the feature advertised on the briefing slide. Yet without a suitable supply of energy and a physical arrangement that preserves necessary relationships, the other functions cannot be assumed to work together.
Finally, picture the interfaces. Some connect elements inside the missile. Others cross the boundary to the aircraft or supporting systems. Through them may pass energy, information, physical loads, or status. The details depend on the fictional design we eventually choose to disclose. For now, an interface means a defined relationship, not merely a visible plug.
That is our first complete map: observe, estimate, decide, respond, move, produce an intended effect, and sustain the physical and informational conditions that make those jobs possible. These are conceptual responsibilities, not a universal missile blueprint. You should now be able to name the jobs without imagining that each one occupies its own neat compartment.
The Missing Lines
Return to the review board. The subsystem teams have each shown impressive results. The sensing equipment produced observations in a test. A computer ran its software. A mechanism responded to a command. Why isn't that enough?
Because each demonstration has a boundary around it. During a test, somebody supplied power, information, commands, or an environment. Somebody decided what counted as success. A function that works under those conditions may still depend on another function doing its job at the right time and in a compatible way.
Picture an orchestra warming up. Every instrument sounds excellent on its own. But that does not prove the group can perform together. The musicians need a shared score, cues, timing, and the ability to hear one another. A solo test is real evidence. It is simply evidence for a smaller claim than a complete performance.
Now put the orchestra aside and return to A R V zero one. A conceptual diagram might show an observation passing to a computing function and a command passing to a response function. Those arrows are promises about relationships. They do not prove that information arrives in a useful form, that the receiving function interprets it as intended, or that the combined behavior has been demonstrated. An architecture makes these relationships visible so engineers know what needs evidence.
There is a second surprise. The neat boxes may not correspond to neat pieces of hardware. The navigation and guidance responsibilities might share computing resources. Power may support nearly every other element. Structural constraints may influence where several functions can exist. A physical item can serve more than one purpose, while one responsibility can extend across several items. We will explore these different architectural views later.
So the board's problem is not necessarily that a part has failed. It may be that the team has collected true statements about parts without showing that the relationships between them satisfy the larger claim. That is a different kind of incompleteness.
Ask a sharper question of any diagram. What must pass between these elements? What is each side assuming about the other? And what evidence would convince us that the relationship actually works? Those are the missing lines. They are often where the architecture becomes most interesting.
The Same Object in Different Moments
Back in the hangar, A R V zero one is attached to its aircraft. Nothing dramatic is happening. Yet this is already part of the system's life. People may inspect it, record its condition, verify its compatibility, and prepare it according to approved procedures. We are not going to describe those procedures. The architectural point is that readiness depends on more than what is inside the missile.
Imagine the aircraft departing with the missile still attached. The object is moving, but it has not become an independently flying vehicle. Its host continues to matter directly. Later, if a release is authorized, the relationship between aircraft and missile changes. A physical attachment ends. Some services that were available while attached may no longer be available in the same way.
That transition is interesting even without knowing any flight mechanics. A system that relied on another system must now fulfill certain responsibilities within a different boundary. We are not assuming that every missile behaves the same way. We are noticing that a change in circumstances can change which dependencies matter.
During flight, the system's internal functions may become more visible as a connected whole. Information is gathered and interpreted. Guidance and control responsibilities continue according to the architecture. Energy is consumed. Structure and environment remain part of the story. Different designs organize these responsibilities differently, and our fictional example deliberately avoids performance claims.
Eventually the vehicle reaches an end state. Whether the intended physical effect occurs is a different question from whether the wider mission succeeds. That distinction still matters. A functioning mechanism is one level of evidence; a successful mission is another. If the system is not used, its life may instead include removal, storage, maintenance, retirement, or disposal under applicable safety controls.
Notice what just happened. We described the same object at several moments, but the relevant relationships changed. During carriage, the host aircraft was central. After release, other dependencies became more important. At the end of the lifecycle, recovery, records, environmental obligations, and safe disposition may matter more than flight behavior.
A later episode will tell the flight story in more detail. This one needs only a simpler lesson: architecture is not a static photograph. A system must make sense across the circumstances in which it is expected to exist.
What Does Ready Mean?
Our fictional review is almost over. We can name the internal responsibilities. We can describe the boundaries and the relationships. But the chair asks the original question again. Is the system ready?
This time, nobody should answer with a single photograph or a single test result. Ready for what claim, within what boundary, and supported by what evidence?
If the claim is that a particular assembly meets its documented requirements, that is one question. If the claim is that the missile and host aircraft work together as intended, that is another. If the claim is that an organization can operate, maintain, account for, and sustain the complete capability, the boundary becomes larger again. The evidence needed for one claim cannot automatically stand in for the others.
Systems engineers use two especially useful words here. Verification asks whether the product meets specified requirements. Validation asks whether the resulting product is suitable for its intended use. These are complementary judgments, not interchangeable labels for testing. A team can meet a requirement that was incomplete or poorly connected to the real need. It can also believe a system is useful without having established that its requirements were met.
Consider an ordinary hospital monitoring device. It might pass its electrical and software checks but still be difficult to use in a busy clinical setting. Or it might be easy to use yet fail a documented accuracy requirement. Both observations matter, and neither replaces the other. We are using the analogy to separate claims, not to equate medical devices and weapons.
Now imagine the board asking for an architecture slide. It shows a sensor, a computer, propulsion, and a payload. You can immediately ask what is absent. Where is the power function? What carries information between responsibilities? Where are the physical and human interfaces? What changes when the aircraft is no longer carrying the missile? Which organization supports the capability over its life?
These questions do not prove a problem exists. They reveal what the slide has not established. That distinction matters. Good engineering skepticism is not the habit of declaring failure. It is the habit of matching every conclusion to the evidence that can actually support it.
We will eventually study detailed interfaces, allocation, system-of-systems behavior, and architectural tradeoffs. Today's task is simpler and more fundamental. When somebody says ready, draw the boundary around the claim before you accept the answer.
The Photograph, Revisited
We started with a missile beneath an aircraft wing and a review that could not close. Look at the photograph one last time. Nothing visible has changed. What you can see has changed.
Inside the missile you now recognize a set of different responsibilities. Some observe the world. Some estimate the vehicle's state. Some determine desired motion. Some help produce a physical response. Others provide propulsion, an intended-effect payload, electrical power, and the structure that supports everything else. Computing and communication may contribute across several of those responsibilities. We have not assigned them a universal physical layout, because the jobs matter more than a fictional drawing of where every part sits.
You also see what the photograph cannot show. Connections among those responsibilities. Agreements at the aircraft boundary. The people, information, maintenance, and support arrangements outside it. And the changing relationships across the system's life.
Try a quick thought experiment. A reviewer says, the computer passed its test, therefore the missile is ready. You now know to ask what that computer was tested with, what it was expected to exchange, and which larger claim the test actually supports. Another reviewer says, it fits under the wing, therefore integration is complete. You know that physical compatibility is evidence of something important, but not evidence of everything.
The third reviewer says, the architecture is just a diagram of all the components. You can offer a better definition. Architecture is a deliberate description of responsibilities, relationships, and boundaries. It gives engineers a way to reason about the whole, to see what has been assumed, and to ask what must be demonstrated.
That is what this fictional missile is for. A R V zero one will stay with us as we change our questions. We will ask what the system must do, how behavior is organized, how functions relate to physical elements, what interfaces require, and how the missile fits within larger systems. We will also follow its life through changing circumstances. Each episode will reveal a new layer, rather than pretending one introductory tour can teach everything.
The review board still needs evidence before closing its fictional review. We have not invented that evidence, and we should not pretend the system is ready. But we have done something useful: we can now explain why the original answers were incomplete and what kind of questions would move the review forward.
One object in a photograph. Many responsibilities inside it. Many relationships beyond it. The habit to keep is simple: before you ask whether every part works, make sure you know what whole those parts are supposed to make.