Selecting Architecture Products for a Systems Development Program

T he purpose of architecture is to answer questions. In other words, the architecture provides the information needed by decision makers during the course of the systems engineering process to define concepts and processes, allocate functionality, define test metrics, design software, and make other development decisions. However, the output of the systems engineering (SE) process is not the architecture; rather, it is the system being produced [1]. Unfortunately, the architecture often becomes divested from the SE process it is meant to support , becoming an output or deliverable in and of itself [2]. In part, this is perpetuated by government regulations specifying that each acquisition program produce architecture with little thought as to how architecture will be used by the program [3, 4, 5]. So, the output of most architecture efforts tends to be a three-ring binder that weighs five pounds or so, which no one ever reads. This has given a bad name to the architecting process, and has left many decision makers asking why they spent their limited money and time producing architectures. To correct this situation, both the software-centric and system-centric communities need to reexamine the architect-ing process, rediscover the intended uses for architecture, and ensure architecting is always done in support of the SE life cycle. For software designers, this will mean a break from the concept that four or five standard Unified Modeling Language (UML) diagrams will solve the needs of all stakeholders. This article presents one method for ensuring the architecture is producing the products needed to support the overall SE process. The SE process has been described as an elaborate engineering decision process that includes the following [6]: • Begins with understanding the system requirements and specifications. • Translates these specifications into a conceptual design in the form of a functional architecture. • Translates this functional architecture into logical design or physical architecture. • Translates the physical architecture into a detailed design or implementation architecture for the system ultimately to be produced or acquired. • Completes development through the production of a product that conforms to this architecture, potentially through various strategic sourcing efforts and associated integration and test. These steps show the SE process for what it really is – a series of decision points leading up to a delivered product. This means the architecture's products must be tied to the rest of the SE process and, more specifically, to decision points …