架构艺术-The art of systems architecting

The art of systems architecting Tbe design of complex systems must blend tbe art of arcbitecture witb tbe science of engineering ew engineers would be sur- prised, today, to see the word “architecture” in their professional journals; nor would they have to think twice about its mean- ing. Architecture is under- stood to be the underlying structure of things-whether of buildings, communication networks, neural networks, spacecraft, computers, software or organi- zation charts-systems all. Less recognized, perhaps, is that where there are architectures, there must be ar- chitects. Moreover, there must be a process, “architecting,” by which the architectures are created, designed, and built. Architecting, itself, has ancient roots. It first appeared in Egyptian writings some 4000 years ago. Many of its basic principles were codified by the Roman, Vitruvius, in the 1st century B.C. But only in the last 50 years or so has the concept of “systems” been comparably formalized. The merging of architecting and systems into systems architechg is still more recent. That process is acceleratmg, driven by three factors: the increasing architectural com- plexity and scope of global-sized projects and markets, the ubiquity of computers in vir- tually all modem systems, and the power of computer aids to system design. Retrospectively, it is apparent that the success or failure of many defense, space, and civil systems of the last half century has depended in large part on how they were structured. The most successful ones were conceived, built, tested, certified, and oper- ated in a way that ensured their integrity and performance. They were based on a consis- tent set of principles and techniques that were maintained throughout all phases of the project. And their designs were resilient enough to bend to the inevitable changes brought about by time and circumstance. As civil architects would say, they had good bones. They also had fine architects who supervised their programs from begin- Eberhardt Rechtin University of Southern California ning to end. The systems that have failed- whether technologically, politically, or economically-lacked these essentials. Such conclusions are not new. Similar ones have been drawn over the centuries about pyramids, cathedrals, cities, ships, and fortiiications. What is new is that those con- clusions are now being seen as relevant to the engineering of electrotechnical systems. Systems engineering and architectmg are brought together by certain common prin- ciples. Each is concerned with complexity and reliability-systems engineering be- cause of its nature and architecting because of its scope. The form of a system is strongly driven by the functions it is called upon to perform. Architecting defines that form by matchmg, fitbng, balancing, and compromis- ing proposed functions and forms until a practical result can be achieved. SYSTEMS PRINCIPLES. Our first focus is on the principles of systems-an area more fa- miliar to most engineers. Different people can mean different things by the word “sys- tem.” For the purposes of architecting, a useful and sufficiently precise definition of a system is: “A collection of different things so related as to produce a result greater than what its parts, separately, could produce.” Indeed, the purpose of building a system is to achieve that greater result. Example: The system function of an assembled automobile is transportation, unavailable from the parts separately. This definition of system has at least two important consequences. First, all systems have subsystems ana‘ all systems are parts of larger systems. Hence the systems world is inherently unbounded: no matter where a boundary might be drawn, things important to the system will exist outside it. The same situation occurs in classical ar- chitecture. Example: Designing a water faucet (a very small system, but a system nonetheless) means considering not only its own function, but also the demands of the systems within which it operates, such as the inclusion of urban water-usage restrictors to minimize the effects of drought on scenic lakes several hun- dred kilometers away. Thus, complex systems cannot be ar- chitected, built, or operated in isolation. Their “outer” and “inner” worlds will al- ways intrude. The best that can be done is to draw boundaries so that intrusions, when they occur, are secondary and not primary-that is, that they can be accommo- dated without breaking the system. Example: The design of a manned spaceflight program, a strategic defense system, a nation- al wideband communication network, an air- line, or a light rail system is strongly influenced by extra-technical imperatives-economic, human, social, political, and international. These imperatives must be included in the de- sign or the system will fail or abort, quite pos- sibly well before completion. Placing them “outside” the system for design purposes could destroy any chance of success. The architect’s task is made particularly difficult by the fact that rarely, if ever, is there a single optimal solution for all parties and all circumstances. The objective, in- stead, is a kind of general satisfaction based on practicality, fit, balance, and compromise. As experienced architects will a f f i i , that takes both science and art. The second architecturally relevant con- sequence of our definition of system is the value added by a system must come from the relationships between the parts, notfrom the pa& per se. Each part already contributes its own inherent value to the system. But it is the total of all the parts working together that yields the whole system-a phenome- non sometimes known as synergism. Example: The Douglas Aircraft DC-3, the first commercial airliner to make a profit for its own- ers, consisted of airfoils from the National Ad- visory Committee on Aeronautics (the predecessor to the U S . National Aeronautics and Space Administration), monocoque de- signs already tried by the Boeing Aircraft Co., engines on the shelf, and control systems then in development. But, with modified elements in novel combination, the DC-3 made air trav- el efficient, reliable, and pleasurable. It follows that syslarns arshitects who work with systems must be specialists in relationships-notgenralisk who k m a lit- tle bit about all the parts. Their specialty is Defining terms Arclllecllng: the process by which a system is created, designed, and built. Herrltllcs: empirical rules of thumb derived from experience and judgment, useful for attacking prob- lems too complex to be solved by analytical tech- niques alone. Sytlem: a collection of different things related in such a way as to produce a result greater than what its parts, separately, could produce. Sysler anhHrclrm: the underlying structure of a system, such as a communication network, a neu- ral network, a spacecraft, a computer, major soft- ware, or an organization. 66 0018-9235/92/$3.00@1992 IEEE IEEE SPECTRUM OCTOBER 1% a concentration on the system as a whole: that is, on those elements, interfaces, and factors that have the most effect on overall system performance, cost, and schedule. Systems architects must necessarily know, or learn, a great deal about some details- those that impinge on the overall system- but need not, and probably should not, pay much attention to the rest, which are best handled by the subsystem experts with whom the systems specialists work. Example: A launch vehicle systems engineer need not know the detailed design of a solid rocket motor. But that systems engineer would be expected to understand in some detail how the rocket’s segments were connected, how each rocket was attached to others and to the payload, what its performance tolerances must be compared to other rockets on the same ve- hicle, what control authority is provided by its thrust control mechanisms, and so forth. Without question, it requires expertise to know which details, interfaces, tradeoffs, and compromises count the most and which, the least. Poor choices can be disastrous; too many choices can be overwhelming. ART AND SCIENCE. Much more so than engineering, architecting is an art as well as a science. There is an art to creating any structure, whether a building, a ship, a spacecraft, a network, or any other system. It is not just a fig- ure of speech to praise a system as elegant or as having style. The artistic element of ar- chitecting is most apparent when architects are asked how they cre- ate what they do, how they come up with alternatives out of the blue that withstand the scrutiny of anal- yses, and how they know that when all the parts come together, a system never built before will work to a client’s satisfaction. The usual, and not very helpful, answer is, “I just use common sense.” Further inquiry leads to the discovery that what is really meant is contextual sense: doing what is sensible in the context of the problem. Commercial aircraft architects do it in creating a safe and profitable aircraft, spacecraft architects in producing a reliable and efficient spacecraft, and soft- ware architects in developing powerful and user-friendly soft- ware. And that means the use of empirical insights, tricks of the trade, and lessons learned from past successes and failures-that is, heuristics. The art in architecting is a spe- cial process, essential in treating situations too complex for analy- sis. It evolved centuries ago as a way to handle ill-structured prob- lems with all their uncertainties, unknowns, conflicting require- ments, and sociopolitical imperatives- problems typical of complex systems. At the risk of oversimplification, disci- pline-oriented engineering is deductive, ana- lytcal, and rational, while systems-oriented architecting is inductive, intuitive, synthet- ical, and pragmatic. At one extreme are the powerful applied science tools of engineer- ing; at the other are the often personal arts of architecting. Straddling both is the prac- tice of systems engineering. Architects of buildings who have studied the process of architecting-how architects work-have identified four methods in com- mon use that depend on the nature and phase of the project, the particular problem to be solved, and the style of the architect: Uormarlve merhodelogy relies on standard, quantitative solutions based on subjective value judgments (“good” vs. “bad” prac- tice). Building codes, communication pro- tocols, and design handbooks are examples. R a l l o d n # t h & / ~ is based on quantitative analysis and algorithms that tell how to find a solution, but not what it is. The scientific method of data gathering, hypothesis, and test is an example. Calculus is mother. Ra- tional methodology-the mainstay of sys- tems engineering-is intended to be as ob- jective as possible. Optimization is one of its goals. Algurnentotl yo mthodelwy is based on broad participation of interested parties. Brain- storming is one of its techniques; quality cir- cles is another. This methodology aims for imaginative consensus. Its strength is group commitment to a common goal. Heurlstlc methdolorr is based on common sense or rules of thumb derived from ex- perience and judgment. The law of supply and demand is an example from economics. Murphy’s Law is an example from system design. The aim here is reasonable, satis- factory solutions and an avoidance of system- level disasters. More than the other three methodologies, the heuristic methodology is an art. The normative and rational methodologies are widely taught in engineering schools and used extensively in practice. These methods have powerful tools available-statistics, probability theory, modeling, optimization, tmdeoff charts. simulation. statis- The ConceptVal phase: .The choice between acclittedures may weU degend upon which set d drawbacks the dmt can handle best. Extreme r~~~~ should remain under challenge throughout sp kfim design, ~~~, and oprwation. the oripinal skkmentof the pfablem is mcessrily lions optimized. averill architecture than if there are not. The build and aast phases: ough h a small sy&n is wilrkelyto be good enough Within the same class of producEs and processes, the failure rate d a product is h m l y propwtmal to its cost. by high-qualii architecting, inspection, test, and rework. acceptance Miteria determine The operations phase: Before the flight, it’s opinion. After the flight, it‘s obvious. The first are often wrong. *For every is a COun$lsystem. *Sucees is deibled by the bholder, not the architet. There’s nothing lii being the first success. Spbm&h&#ng: C~~~ Compbx-, by Eberhardl Rechtin, published by Prentke Hall, Englewood clifls, N.J., 1991. tics, operations research, and per- formance analysis. They help break down problems into solva- ble subproblems whose solutions are then integrated into the whole. System certification is quantitative and not easily disputed. These two methodologies comprise the ‘ ‘science’ ’ part of architecting and the technical foundation of sys- tems engineering, detailed de- sign, and integration. In argumentative methodology, free-xanging discussion reigns. Its weakness is design by committee. On the surface, it seems to con- tradict a widely held view that the best architectures are the product of a single mind or small team. Success, therefore, requires good team dynamics-a well-designed human system guided by the em- pirical knowledge of human be- havior. In this respect, the ar- gumentative methodology might be considered a managerial vari- ation of the more general heuris- tic method. HEURISTICS UNBOUND. The heuris- tic methodology is particularly characteristic of architecting. In contrast with the other meth- odologies, it is synthetical, induc- tive, and experiential. Its tools are heuristics-rules of thumb for discarding out of hand unreasona- ble options, for maintaining the integrity of system goals, for tak- ing precautions against pitfalls ahead, and for recalling lessons learned. But most important, heuristics is the only methodology that Rechtm-The art of systems architecting 67 directly attacks problems too complex to be solved by analytical techniques alone; that is, those characteristic of unbounded systems. A good example of a descriptive heuris- tic, mentioned earlier, is Murphy’s Law: “If something can go wrong, it will.” A n as- sociated prescriptive heuristic, an antidote to Murphy’s Law, is: “Simpldy, simplify, simphfy.” Neither of these mentions statis- tics or statistical quality control. Instead, they suggest a strategy: if a system is built in such a way that something could possibly go wrong, no matter how improbable, fix it. An older heuristic, often used for simpler products, is: “If it ain’t broke, don’t fix it”-a strategy demonstrably not competi- t ive for large-scale, complex products. I t is not competitive primarily because an ele- ment “good enough” in a small system is unlikely to be good enough in a more com- plex one. (As more and more parts are added, the system reliabil ity will go down unless the individual part reliabilities go up.) The practical value of heuristic insights is seen in their extensions by W. Edwards Deming, Joseph M. J u m , Genichi Taguchi, and others. These are known as total quali- ty management (TQM), continuous meas- urable improvement (CMI), just-in-time (JIT) inventories, and other techniques. A quite different heuristic, useful in aero- space and computer design, is: “In parti- tioning a system into subsystems, choose a configuration with minimal communications between the subsystems.” With a few word changes, this could be applied to the design of communication networks, organizations, and system subcontracts. Example: A common question in the design of complex, smart spacecraft is whether to use a centralized or distributed computer system to run the major subsystems, such as propul- sion, guidance, control, command, tele- metering, science instrumentation, and sys- tem test. The centralized configuration is generally lighter, smaller, computationally more efficient, and less power consuming. The dis- tributed configuration requires less informa- tion transfer, and solves local problems local- ly. But most important, it permits each subsystem to be self-testing without recourse to a central control unit. As such, it enables subsystem subcontractors to deliver checked- out units to a prime contractor. To do likewise, a centralized configuration requires central computer copies at each subcontractor site and/or delivery of subsystems that can be checked out only at the system level-a con- tracting nightmare and a prescription for over- runs and delays. Fixing such problems usually requires adding weight, space, power, and computer capacity late in the development. The decentralized configuration is now preferred, for management and not technical reasons. Heuristics cannot promise that a heuristi- cally designed system will be the best per- forming of all possible systems. But, from experience, that type of system will be much Teaching systems architecting: science and art Instructing others in systems architecting involves both its science and its art. Teaching the underly- ing science is straightforward; teaching the art is still in the experimental stage. Existing guidelines are few, even from classical architecture. What does seem to be true, though, is that until the science of systems architecting is understood and the complexities of systems experienced, the role of its art is lime appreciated. Consequently, at the University of Southern California (USC) in Los Angeles, systems architecting is taught only to en- gineers with three or more years of experience (the average is seven years)-those who already recog nize that the science of engineering, though pwerful indeed, is somehow not sufficient to meet the d e mands they face in building complex systems. The challenge is to teach the art without crush- ing its creative core under a burden of memorized dictates and caveats. COOlFYlW6 C8MNIBW SENSE. Fortunately and per- haps surprisingly, codifying the common sense of successful systems architects is not so difficult. The first step is to show students that what is meant by common sense is contextual sense: what seems sensible depends on the system’s particular con- text (whether the system is a building, an aircraft, a spacecraft, a missile, a computer, software, a net. work, or an organization). That means that a heuristic (an empirical rule of thumb) that applies in one context may not apply in another. True, a heuristic that is sensible in one context may be sensible in another, but showing ap- plicability has to be by example to be credible. It can- not be deduced mathematically. Instead, a proposed heuristic, on presentation to people versed in a field, has to seem ”reasonable” to them and then must survive their almost automatic mental search for sup porting or contradicting examples. A diligent search for useful heuristics reveals a wealth of wisdom and lessons learned in many fields. Once given the concept of heuristics as architec. tural aids, an alert student can spot statements of common sense in most articles describing success- ful or unsuccessful systems. At USC, well over 100 heuristics have been found or newly articulated for the acquisition of electrical and aerospace systems. Comparable numbers no doubt can be found scattered