System architecting has been around since the Egyptians built the pyramids. The pyramids presented an enormous number of problems for its designers due to the size of the structure, the lack of proper tools, and the need to make it a tomb fit for a god-king. Now we are faced with similar problems of system complexity that has outstripped our system building techniques in the area of embedded computer systems. Heuristics, models, and metaphors help architects abstract away complexity, but much of the difficulty in architecting lies in maintaining a unified vision of the system. Having a unified vision makes it much easier to create safe, dependable, or fast systems. Unfortunately, not everyone is a great system architect, and it may never be possible to teach someone all of the necessary skills. This poses some fundamental limitations on the systems we can create. We must continue to find new techniques to reduce complexity and make the system architect's job easier.
Architecture has been an important problem for humanity since ancient civilization. Its one of the driving forces in human development, because our structures are limited by it, and they only advance as it advances. Over the last fifty years, thanks to the computer revolution, our systems and structures have gotten more complicated then ever before. Giant software systems are some of the most complicated artifacts humans have ever created. Now, more then ever, we must study architecture if we are to continue to create new and innovative systems that provide a benefit to society..
This paper is about approaches to system architecture. A system is defined as a collection of different objects related in such a way that they can do more then what the sum of their parts could do separately. The system architecture is the fundamental structure and overall vision of a system. The systems architecture approach I will be exploring is the one similar to the approach Brooks put forth in The Mythical Man Month [Brooks75] and reinforced by Rechtin [Rechtin97]. This approach has one person or a small team responsible for the overall vision and direction of a systems development. Hence that person is the system architect. The importance of having a good system architect cannot be overestimated; it has been apparent from past experience that a unified vision of the system can be critical to success.
One of the most important things a system architect does is deal with complexity. Complexity limits the systems that architects can build, so any tool that reduces complexity will make the architect's job easier. Some tools that deal with abstraction are heuristics, models, and metaphors. These tools apply past knowledge to new problems by mapping unknown situations into something the architect is familiar with. This mapping can help the architect isolate the key pieces of information. The only problem with using these abstractions is that sometimes key pieces of information are eliminated from the architect's view of the system; abstractions must be used with care. Skilled architects figure out which abstractions are good and which can be dangerous.
Unfortunately, skilled system architects are difficult to find. System architecting is both an art and a science, and the best results come from its skilled practitioners. So far no process has been developed that can duplicate the work of a skilled architect. Our complex systems depend on strong architectures, so it is important that we understand how to produce them. Unfortunately, only a few skilled architects can do the best practice. This paper will explore system architecture, and some of the issues related to how it is done. It will also look at the training of system architects to see if anything can be done about the shortage.
The systems approach advocates using one person or a small design team to oversee the project architecture. This concept is based on the principle that the key to a projects success is having a unified vision for its development. Hap-hazard planning, and lack of a strong underlying foundation for a project can lead to disorganization and project chaos. Also, unified approaches are generally more efficient and flexible then approaches generated by committees. This affect can be seen in a number of successful historical projects [Maier96]. The SR-71 Blackbird was designed by Kelley Johnson, and the plane held speed and altitude records over its 30 year service period. Seymore Cray's vision contributed greatly to the success of Cray super computers. The DC-3 is another fine plane designed by one person. The principle of, and critical need for, conceptual integrity permeates the history of humanity's design triumphs. It can also be seen outside of engineering in great works of art. The Sistine Chapel ceiling was conceived by Michelangelo, and painted by himself and his apprentices. All major symphonies were written by one person. Art simply requires a unifying vision to give a work continuity and meaning; an engineering project requires the same thing to give it clarity and direction.
By providing a unified underlying architecture, system architects are able to focus on the emergent properties of a system. Since their concern is the overall architecture, they avoid becoming mired in the thousands of little project details. The emergent system properties are usually the most interesting properties. Things like security, dependability, and safety all need to be dealt with at the system level. The system architect is the best person to deal with them. They can disseminate information to the project groups working on each sub-system, and make sure those sub-systems stay in line with the overall architecture. System architects can also see global optimizations that can improve emergent properties. As the keepers of the overall system design, the architects should be responsible for dealing with all complex, emergent, system properties.
The other important role a system architect has is
dealing with the client. As the head designers, they are the best
equipped to interpret the status of the system for the client, and they can
determine if the system is meeting the client's need. This is a
critical capability, because the architect can buffer the demands of the client
from the demands of the developers.
Heuristics, Models, and Metaphors are tools a system architect can use to help clarify a problem. Each tool has a slightly different flavor, but they are all based on the principles of abstraction and the application of past knowledge.
Heuristics are small capsules of knowledge which help evaluate and give purpose to a design. They are tools that can help reduce the level of complexity facing an architect by bringing past wisdom to bear, but they must be used carefully. The right heuristic must be used with the right problem. Heuristics range from very high level, qualitative statements to low level, domain specific, quantitative statements, and their depth should be matched appropriately with the phase of the project. Rechtin believes that to be a useful, a heuristic must have the following five characteristics [Rechtin97a].
- It must make sense in the original context.
- Its sensibility or meaning should apply beyond its original context.
- It should be easy to rationalize.
- Its opposite should seem foolish.
- The heuristic's lesson should be time tested.
The effectiveness of these can be seen by looking at these classic, broadly applicable, heuristics:
Simplify, Simplify, Simplify: This the classic heuristic about complexity. Everyone should strive for simplicity, its a worthy goal for any project.Adding people to a late project makes it later: Brooks law is an important illustration of one counterintuitive aspect of software management.
One insight is worth a thousand analyses: Sometimes architects can get clouded in the scientific side of architecting. Architects must realize that part of what they do is art, not science, and it must be treated as such.
No complex system can be optimum to all parties concerned, nor all functions optimized: Complex systems will require compromise, another aspect of architecture that makes it an art, the system architect must be open to this and, the system must be flexible enough to handle it.
Before the flight its opinion, after the flight its obvious: Often, key points of an architecture won't become obvious until its been operating in the field, or in this case after the airplane's first flight.
Heuristics, especially the time tested ones, are almost always worth following, and it has been said that if the five heuristics agree with a decision then its a good decision. They are excellent rules of thumb for discarding irrelevant information, or impractical ideas, and every architect can benefit by using them.
A metaphor is a familiar concept used to explain the unfamiliar. One well known example is the desktop metaphor for personal computers. By setting up the unfamiliar environment, the personal computer, to look like something familiar, the top of an office desk, computers became much more accessible to people who weren't used to the technology. The idea of a desktop simplified the concept of a computer, and made it much easier to understand. The unimportant details, like the version of operating system, the command line, and the type of extension cards in the computer, were hidden from the user so everyday operation would be easier. Of course those details were only unimportant to some people, other people needed to have control of the computer. This brings up an important point about metaphors; sometimes they prevent important details from being seen.
The Apple Macintosh, for instance, made use of the knowledge processor metaphor and also suffered from it. The Macintosh was supposed to be a personal knowledge processor, and once it was a success the designers felt they had achieved their goal. To them the Macintosh was the perfect knowledge processor, and this metaphor did not call for any change to the device. They didn't see that people would want to upgrade and expand their knowledge processor, and they slowly lost their market share to a software company in Seattle. The metaphor they chose gave them the clarity to make an excellent product, but in the end it failed them by cutting important details out of the the picture.
Models are everywhere in software engineering and systems architecting because they help abstract away complexity. They also make it easier to communicate design ideas to different parties, understand complicated behavior, and formulate design decisions. However, just like metaphors, the architect must remember that the model is not reality, and too much information can be abstracted. For instance, the United States Navy's communication systems were not designed to use satellites because satellites were not around in the 1960's when the system was designed; the model they used did include the possibility of any other communications medium-- like a satellite network [Maier96].
The most difficult system to design is the unprecedented system. Unprecedented systems give the architect no established framework to develop from, and it makes the process of creating requirements complex. For new designs, it is important to remember how difficult developing requirements becomes. Developing the requirements independently from the architecture is ineffective, in this case art must take the place of science. There is no good way to estimate the feasibility of a design using traditional analysis methods, and any requirements will be so vague as to be useless. Here the designer must do both the requirements and the architecture at the same time, balancing the customers needs with what is architecturally feasible.
Creativity is critical to innovation, but must it always depend on one person with a vision? The question is the same one that comes up in the art and music world. How are great works of art made? Can the skill ever be taught? The answer for the art world and for systems architecting has been the same for hundreds of years: great art and architecture requires great artists. We can train people to make good architectures, just as musicians can be trained to write competent symphonies, but there is something innate in great artists that cannot be taught. Systems architecture must struggle with this problem; perhaps an idea can be taken from the music world, expose as many people as possible to systems architecture and find as many gifted individuals as possible.
System design is broken up into four main styles:
Rational: Formalize the design into a provably optimal solution. This covers formal methods, and careful analysis and modeling.
Consensual: Design by a committee. This has its good points and bad points. Committees tend to cover a lot of ideas. They also have a tendency to include all of those ideas in the design, whether they fit well or not.
Heuristic: Use general advice from years past to shape the architecture of new systems.
Few tools exist beyond models and heuristics to help systems architects. Most available design tools help only after the requirements have been established, and by that point the architecture may have already been set up. Modeling languages can help to express a design clearly, but again it sort of helps more after the basic parts of the architecture are established.
No metric currently in existence can certify the quality of a system architecture before it is built. Some metrics can give approximations, but the only way to determine if an architecture is good is to implement it. For instance, while it could be said that when a client agrees to accept a system that means it has been certified, the true test of a product may end up being if it sells well or if it requires little maintenance. After a system has been built its quite easy to see if the architecture was good or bad. User satisfaction is an excellent evaluation of an architecture. The problem, of course, is that by this point its hard to change most of the architecture. Essentially, its easy to spot a bad architecture, but its hard to make a good one.
There are a few techniques which may help with certain types of systems. A rapid prototype may help for small scale systems. It would allow the client to use the system and give the architects feedback. This feedback would help the architects get a better idea of what the clients really want. However, this would be a difficult technique to use for a very large, complex project. A simulator may be used to help design and verify a product. The automobile and airplane industries both use computer simulation to help design their products. This works well when development new versions of familiar systems, but it would be difficult to build a simulation of a unique system. By the time the simulator is complete, it might have been easier to just build a prototype of the product. Simulation and rapid prototyping can be quite helpful, but only in certain situations.
System architecting relates to any topic involving design or system level issues. It certainly relates to security, an emergent system property, and multidisciplinary design. An argument could be made for each of the following: safety, dependability, system life cycle, quality of service, and design process.
Security: Security is an emergent system property. The only way to have a secure system is to design that security into the underlying architecture.Multidisciplinary design: System architects need to understand many different areas of engineering, especially in something like an embedded system, with many different types of components. The architect must understand how all of the components interact.
First, the best approach to system architecture is to keep a unified vision for the project. This can best be done by one person or a small group of people. Architecture is a blend of both art and science, and probably no amount of technological advancement will remove the art from architecture. So the best way to get good architectures is to use talented architects. This may not always be feasible. If it is impossible to find one really talented architect, the next best approach may be to uses a small team of designers with a broad range of experience, and following a well established process, to create the architecture. Having a unified vision to guide a complex project has proven to be a good way to assure success, so consider the situation carefully before deciding to deviate from this approach.
The future of systems architecture poses some interesting challenges. Systems are going to continue to get more complex, and they are going to be owned by multiple clients. This situation will put an even greater strain on the system architect. So the question then, since good architectures come from good architects, is how do you get more good architects. This is question akin to: how do you find good composers? Or, can you teach Salieri to be Mozart? While I believe there is a certain amount of innate ability that an architect must have, the ability can certainly be improved. The best approach may be to expose as many engineers as possible to system architecture and find the ones who are really good at it.
[Brooks75] Brooks, Fredrick P., The Mythical Man-Month, (c) 1975, Addison-Wesley Publishing Company, Inc.
A classic reference on software engineering. It contains the foundations of the system architecture approach.
[Recthin97] Rechtin, Eberhardt, Maier, Mark W., The Art of Systems Architecting, p. 14 -17, (c) 1997, CRC Press, Inc.
An excellent reference specifically on systems architecting.
[Maier96] Maier, Mark W., Systems Architecting: An Emergent Discipline?, IEEE Aerospace Applications Conference, 1996
This is a good overview paper of the topic. It covers many of the essential points and gives some interesting overviews of how real systems were designed.
[Rechtin97a] Rechtin, Eberhardt, The Synthesis of Complex Systems, IEEE Spectrum, vol. 34, no. 7, p. 50-5
It covers the challenges that come from designing systems that have never been designed before.
Further reading on a management track:
Grinter, Rebecca E., Recomposition: Putting it All Back Together Again, CSCW
98, Seattle Washington USA
Here is the System Architecting page by Mark Maier:
http://www.eb.uah.edu/~maier/sysarch.htm