From Chapter 4: Aristocracy, Democracy, and System Design
Excerpt
By the architecture of a system, I mean the complete and detailed specification of the user interface... As Blaauw has said, "Where architecture tells what happens, implementation tells how it is made to happen." He gives as a simple example a clock, whose architecture consists of the face, the hands, and the winding knob. When a child has learned this architecture, he can tell time as easily from a wristwatch as from a church tower. The implementation, however, and its realization, describe what goes on inside the case—powering by any of many mechanisms and accuracy control by any of many. (Ch 4. p. 45)
From Slaughterhouse Five
ExcerptIn this chapter, Brooks asserts that the conceptual integrity of a design is of signal importance and insists on the need for an architect who has been imbued with the authority necessary to preserve that integrity.
Now, when I myself hear that somebody is dead, I simply shrug and say what the Tralfamadorians say about dead people, which is "so it goes."' (Kurt Vonnegut)
While I've had many quibbles with this visionary book, I find more object to in this particular passage than any that I've previously discussed.
Brooks begins this chapter with a description of the Rheims cathedral. He holds Rheims up as a premier example of conceptual integrity and he contrasts it with other cathedrals whose design suffers because "later builders were tempted to 'improve' upon the designs of the earlier ones." There's an implied warning to programmers in this rather strained analogy: don't get too inventive or you'll screw things up.
 |
| Sketch of flying buttress at Amiens Cathedral (constructed 1220-1270 AD) |
That's a good thing. Despite Brooks admonition, programmers must be inventive. Why?
Unlike the good-old-days of the 13th century when tools and techniques changed on a geologic timescale, architects had no need to engineer change in their designs. Tomorrow would be like today. No worries about game changing innovations in the the next year or even the next century.
 |
| Arch C has a tas-de-charge |
And, as if that wasn't enough to raise doubts about Brooks' advise, there's a bigger problem: requirements for a software systems will always be in state of flux. It's inevitable. Users will need more. Broader applications will be imagined. Infrastructures will change. If the architect did not plan for improvement, the system will become brittle and break with the smallest change. Maintenance costs will soar. And then infrastructure and culture will grow to address the inadequacies of the system. Organizations will sprout with budgets and personnel to address the shortcomings. With the budgets come the bureaucracies who will guard their very existence by setting up political ramparts to 'protect' the very system shortcomings that justify their existence. Is it any wonder that large software systems, like the NASA ground systems, live for decades and are nearly impossible to replace?
In this regard, the example of the Reimian architects fails badly. Imagine the fix they would have been in if they had to specify a building that could host both an Easter Mass and a Superbowl! Yet this is pretty much the lot of your contemporary software architect who must embrace those who would 'improve their designs,' because they hold the key to a system's long term viability. An architect who resists the need for improvement invites a high cost of ownership and widespread user resistance and antipathy.2
Perhaps the observation with the greatest potential for an adverse consequence is Brooks' invocation of the Blaauw's claim, "...where architecture tells what happens, implementation tells how it is made to happen." Here's what worries me.
In contemporary aerospace parlance, the system engineering effort defines what the system should do. The implementation effort defines how the system is to be built. The "what" is described in a requirements document. The "how" is described in a design document. So, if we take Brooks and Blaauw literally, the architect's role is to merely produce requirements and not design.
That's a bit disingenuous. Brooks also says architecture is a "specification of the user interface." Note the contradiction—a specification is a design artifact, a realization of, a specific way to meet a requirement. In other words, a specification is a how, not a what. So in that respect, Brooks is calling on the architect to designate a design and be part of the implementation effort. Note the contradiction.
This in no mere mincing of words. Remember "what is is?"3 Sometimes words matter. Underneath this seemingly pointless contradiction lies one of the biggest challenges facing the development of a new system. Countless hours have been expended in NASA debating what is a 'what' and what is a 'how'. (The answer will always be relative to context and never absolute.) Why the concern? The determination of whether a statement describes a 'what' or 'how' determines budget and decisional authority.
In the traditional view, the architect is a system engineer, pure and simple. Any attempt to designate a novel role is considered a power grab.
In the reformist view, where reformist implies that software design and development is a first order concern for space system development, the role of an architect is considered a new role. One with authority to reach across both the system engineering and design efforts. The reformist architect connects the 'how' to the 'what' and the 'what' to the 'how'. This is especially important for non-functional requirements like exensibility, maintainability and testability. Aside from a specification, those words will always be empty.
The lack of implementation authority is a severe shortcoming of the the traditional view. If an architect does not need to be responsible for the 'how', the role may be awarded to an individual who lacks the software development talent and experience required to meet the challenge of designing a software system for change. Sadly, that is the rule and not the exception.
 |
| "Liver of Piancenza" by LokilechTool for divining from entrails |
What could go wrong? How might a "complete and detailed specification" of a user interface be inadequate?
Assume that Brooks' concept of a "user interface" is the same as we think of it today, i.e. a description of how you put data into and get data out of a functional box without looking inside. In contemporary parlance, that's a black box description.
Black boxes are wonderful because they hide the internals from a user. No need to bother with those niggling internal details. Just plug in a value and the right answer magically appears.
At least that's the theory. In practice, if something goes wrong, there is no visibility into what might be going wrong. I've seen programmers spend nerve-wracking, costly weeks debugging a problem only to find it buried in some 3rd-party library. And black boxes can also be a nightmare for testers. Consider the poor soul who trips an infrequent, non-repeatable error as the launch date nears. Was there a defect? Was it tester error? One thing's for sure, if an error can't be repeated, it can't be fixed.
As a practical matter, black box use if fine for application users, and a recipe for trouble during development. What kind of trouble? Here's a few examples that come to mind (especially for a realtime, safety-critical space applications):
- Consider an interface that specifies an integer input and an integer output. It says nothing about what happens behind the scenes. Internally that function might be optimized by using a type with fewer bits. The result could be a value that ends up rounding off to the wrong value. In many cases that's fine, but in other cases it may produce errors. Costly errors. A related issue was cause of the Ariane V disaster.
- Consider the complete interface specification for a library of functions. It includes a list of all inputs and outputs. But what happens if there's a loop where one function call another? How will these functions interact? Is an output affected by the order of execution? An interface specification limited to inputs and outputs will be silent about interactions.
- Consider a application that is reused as part of another larger system. Is the reused system being used in ways that are consistent with its design? Can new interfaces be safely added to the reused system? Will the new interfaces affect existing users? How will the deployment process affect existing users? An architecture that only defines the user interface will be silent on the many design consideration for reuse and modification.
What should an architecture do? It should provide design guidance in the form of constraints for programmers. The constraints that allow for change. The architecture should also describe the semantics of the system both in front of and behind the interface. The difficulty of the task cannot be overstated, but these are the necessary keys to conceptual integrity.
I suppose all this sounds like a mere tempest in a teapot. Perhaps this short anecdote will convince you otherwise.
On my last NASA assignment, I worked for a senior manager who was responsible for the ground systems used on nearly a dozen NASA missions. It was (and is) an out of date and extremely costly system to maintain.
A few years ago, headquarters allocated better than $10 million dollars for a multi-year upgrade. It was a rare opportunity to introduce a better ground system. Our team was especially smart and experienced. We analyzed the current requirement set and developed a simple, but powerful information architecture and structural architecture. We were optimistic. We prepared an architecture description document that described how we would build the system and presented it to the management team for review.
Remarkably we were stopped dead in our tracks. Our manager withdrew the funds for our design. His reason was simple: we had wasted our time defining more than the system interface. He was convinced that you can say all that's necessary with only an interface document. No example, no amount explaination could convince him otherwise. Despite his years of experience, he had no notion of what was required to successfully architect a new system. All progress on the new system immediately ground to a halt.
Today, those modernization funds have been exhausted without a single major improvement to the system. That's how it goes in NASA. That's how it is in a large bureaucracy.
"So it goes."
1. Trevelyn, G.O., The American Revolution, Part III, Saratoga and Brandywine, Valley Forge, England and France at War. Longmans, Green, and Co. 1907.
2. Brooks will acknowledge the problem of "changeability" in a later chapter (written for the 2nd edition), but he does not address the challenge it poses for conceptual integrity.
3. Nod to Bill Clinton's statement to the grand jury in 1998.
"It depends on what the meaning of the word 'is' is. If the--if he--if 'is' means is and never has been, that is not--that is one thing. If it means there is none, that was a completely true statement....."
No comments:
Post a Comment