Principles of System Architecture

An IEEE Spectrum article (Oct 1992) about systems architecture included a list of heuristics/advice for building a system. I believe it applies to software systems just as well as hardware. The list is reprinted from Systems Architecting: Creating and Building Complex Systems, by Eberhardt Rechtin, Prentice Hall 1991.

The conceptual phase

  • The choice between architectures may well depend on which set of drawbacks the client can handle best.
  • Extreme requirements should remain under challenge throughout system design, implementation and operation.
  • Don't assume that the original statement of the problem is necessarily the best or even the right one.
  • No complex system can be optimum to all parties concerned, nor all functions optimized.
  • A model is not reality. (!)
  • Complex systems will develop and evolve within an overall architecture much more rapdily if there are stable intermediate forms than if there are not.
  • Build in and maintain options as long as possible.
  • Don't make an architecture too smart for its own good.

The build and test phases

  • The product and process must match.
  • An element good enough in a small system is unlikely to be good enough in a more complex one.
  • Within the same class of products and processes, the failure rate of a product is linearly proportional to its cost.
  • High quality, reliable systems are produced by high quality architecting, engineering, design and manufacture, not by inspection, test and rework.
  • Regardless of what has gone before, the acceptance criteria determine what is actually built.
  • To be tested, a system must be designed to be tested.
  • Qualification and acceptance tests must be both definitive and passable.
  • The cost to find and fix a failed part or software bug increases by an order of magnitude as that part is successively incorporated into higher levels in the system.

The operations phase

  • Before the flight, it's opinion. After the flight, it's obvious.
  • The first quick-look failure analyses are often wrong.
  • For every competitive system, there is a countersystem.
  • Success is defined by the beholder, not the architect.
  • There's nothing like being the first success.
Comments