System Engineering is a field within engineering with a robust approach to the design, creation, and operation of complex engineering systems. Enterprise Architecture (EA) can be considered the blueprint of a system: it identifies (and defines) aspects within a current system (as-is) and utilizes these aspects to effectively determine the future state of a system (to-be).
EA provides physical artifacts that represent the system developed by System Engineering. EA consists of a combination of System Views (SVs), Operational Views (OVs), and Technical Views (TVs) developed for individual programs. These architectural artifacts (that we utilize) are designed based on and adhering to the FAA’s Integrated System Engineering Framework (ISEF) version 1.5. The FAA’s ISEF is a subset of the Department of Defense Architectural Framework (DODAF) and is the standard for all. The Enterprise Architecture should be an open, flexible, modular, manageable, and secure information management and sharing architecture.
The use of open architecture principles achieves this capability and provides value by reducing costs and risks, enabling new services, and extending existing services by adding value to them.
Both disciplines use modeling tools (SE for design, EA for description). System Engineering provides the inputs needed to develop the EA artifacts.
- ConOps (developed in conjunction with system engineering) is used as an input to the operational views
- Use Cases are used as inputs to OVs and SVs since they describe both operational and systems actions
- Functional Architectures develop system functions, used in SVs
- Data flow diagrams used in developing both OVs and SVs
Both methodologies are used iteratively to refine the system, feeding off of each other to develop the system. The “as-is” model and “to-be” model concepts are examples.
The as-is defines the current state of the system or business process in an organization. The goal of an as-is analysis is to depict the current system or business process and clarify exactly how it works today. For example, conducting a shortfall analysis would describe and document deficiencies and operational improvements sufficiently.
The to-be analysis is a description of future desired processes. It solves the shortfalls and gaps previously identified in the as-is. The to-be analysis requires creativity in solving problems and designing processes to achieve business outcomes.
Systems Engineering transitions from as-is to to-be by identifying gaps between the two and transforming them into system requirements, specifications, models and solutions architecture. To-be is often transformed based on feedback from Systems Engineering with continuous exchanges between requirements, design and implementation. During an SE implementation, the to-be is transformed to as-is and the new loop begins. As the environment (system or business process) evolves, as-is will have identified necessary updates and transformation.
In summary, EA helps to identify the system enterprise needs, while SE is involved in requirements design based on systems identified by EA, implementation, verification and maintenance.
Contact North Star Group to learn more about the cohesive deployment of systems engineering and enterprise architecture.
