The discipline that combines system elements which, working together, create unique structural and behavioral capabilities that none could produce alone. The word “architecture” is commonly used to describe the underlying structure of networks, command-and-control systems, spacecraft, and computer hardware and software. The degree to which well-designed systems-level architectures are critical to the success of large-scale projects—or the lack thereof to failure—has been dramatically demonstrated. The explosion of technological opportunities and customer demands has driven up the size, complexity, costs, and investment risks of such projects to levels feasible for only major companies and governments. Without sound systems architectures, these projects lack the firm foundation and robust structure on which to build.
Complexity and its consequences
Systems are collections of dissimilar elements which collectively produce results not achievable by the elements separately. Their added value comes from the relationships or interfaces among the elements. (For example, open-loop and closed-loop architectures perform very differently.) But this value comes at a price: a complexity potentially too great to be handled by standard rules or rational analysis alone.
As projects have become ever more complex and multidisciplinary, new structures were needed for projects to succeed. Analytic techniques could not be used to find optimal solutions. Indeed, given the disparate perspectives of different customers, suppliers, and government agencies, unique optimal solutions generally would not exist. Instead, many possibilities might be good enough, with the choice dependent more on ancillary constraints or on the criteria for success than on detailed analysis.
Conceptual phases
As increasingly complex systems were built and used, it became clear that success or failure had been determined very early in their projects. In the early phases all the critical assumptions, constraints, choices, and priorities are made that will determine the end result. Unfortunately, no one knows in the beginning just what the final performance, cost, and schedule will be.
Systems-level architecture specifies how system-level functions and requirements are gathered together in related groups. It indicates how the subsystems are partitioned, the relationships between the subsystems, what communication exists between the subsystems, and what parameters are critical. It makes possible the setting of specifications, the analysis of alternatives at the subsystem level, the beginnings of detailed cost modeling, and the outlines of a procurement strategy.
There rarely is enough information early in the design stage for the client to decide on the relative priority of the requirements without having some idea of what the end system might be. Instead, provisional requirements and alternative system concepts have to be iterated until a satisfactory match is produced. Unavoidably, successful systems architecting in the conceptual phase becomes a joint process in which both client and architect participate heavily. In the ideal situation, the client makes the value judgments and the architect makes the technical decisions.
Systems-level architecture begins with a conceptual model, a top-level abstraction which attempts to discard features deemed not essential at the system level. Such a model is an essential tool of communication between client, architect, and builder, each viewing it from a different perspective. As the system comes into being, the model is progressively refined. See also Software engineering.
