Object-Oriented Enterprise Architecture Development Background

Serco's Architecture Development Evolution
Evolution History

Serco's Architecture Development Evolution

As the DoD moves toward Net-Centric Operations and Warfare (NCOW), we determined a new approach to system engineering centered on the use of enterprise architecture was needed to define new operational concepts and capabilities enabled by information technology; better understand and communicate the complexities and interdependencies within and among enterprises to achieve truly effective operations in a Net-Centric environment; and effectively manage the definition, development, fielding, sustainment, and evolution of materiel and non-materiel solutions needed to achieve Net-Centric capabilities.

Figure 1 - Use Cases describe participants, roles and responsibilities, and desired outcomes (i.e., results of value) for a given process (e.g., timely missile warning to a forward user)

A critical step in the development of this architecture-centric approach to systems engineering was taken by the DoD Architecture Framework Working Group (AFWG) when it defined standardized architecture representation across the DoD. In doing so, the AFWG succeeded in providing stakeholders a better means of achieving interoperability and integration by identifying and addressing inter- and intra-enterprise dependencies. Today, the Department of Defense (DoD) Architecture Framework (DoDAF), Version 2.0, suggests the use of a common approach for representing DoD architectures. The DoDAF approach enables architecture descriptions to be shared across Joint and Combined organizations. Recognizing the potential of taking an architecture-centric approach to capabilities acquisition, the Joint Chiefs of Staff mandated the use of DoDAF views to justify the need for and guide the acquisition of all major military systems per CJCSI 3170 (Joint Capabilities Integration and Development System) and CJCSI 6212 (Interoperability and Supportability of National Security Systems, and Information Technology Systems).

An architecture-centric approach to systems engineering can improve acquisitions by enhancing discipline, improving communications/collaboration among stakeholders, clarifying definition of the enterprise, documenting the solution, and synchronizing concepts, requirements, products, and systems. This approach fosters greater understanding of organizational, system, and enterprise relationships, identifies reusable components, aids integration of acquisition and warfighter Decision Support System (DSS) processes, and provides flexibility needed to assess impacts and manage change. In short, architecture provides a framework for effectively defining and managing the evolution of an information technology intensive enterprise.

Some significant challenges in pursuing architecture-centric acquisition include: Effectively defining, modeling, and communicating enterprise complexity Ensuring required operational capabilities drive system development – linking capabilities directly to enterprise components Identifying and managing enterprise and program boundaries Recognizing reusable operations and components to reduced ownership cost Coping with change (threats, missions, operations, organizations responsibilities, technology, etc)

Serco provides a solution to meet these challenges. Drawing upon principles of modern software engineering, we extended industry best practices in object-oriented analysis and design (OOAD) to address enterprise architecture development.

Key features of our object-oriented approach include: Scalable to enterprise size and complexity and broadly applicable to many different programs Common modeling language understood by both warfighters/operators and system developers to facilitate clear and unambiguous collaboration/communication and "stakeholder buy-in" Effects-based approach ensures fielded systems deliver stakeholder required outcomes (services and products) Synchronized evolution of operational capabilities and systems solutions Adaptation mechanisms readily identify reusable operations and supporting capabilities Flexible structure rapidly accommodates large and/or frequent change

Figure 2 - Operational Sequence Diagrams model operational activities and supporting information exchanges

Our object-oriented approach delivers all DoDAF-required views. Key architecture products include use cases, operational sequence diagrams, and system sequence diagrams, which used in combination, achieve an integrated architecture as described in the DoDAF. Serco uses these products to provide clear traceability between required operational capabilities and supporting systems.

Use Cases (Figure 1) capture and describe operational capabilities by defining key processes (e.g., Maintain Relevant Missile Warning Information), a desired outcome (e.g., timely missile warning to a forward user), the participants (organizations and systems), and the participants individual roles and responsibilities to produce the desired outcome.

Operational Sequence Diagrams (Figure 2) model the interactions and information flows between warfighters/operators and supporting systems to capture the process detail of the desired capability and desired outcomes.

Once Use Cases and Operational Sequence Diagrams clearly capture stakeholder needs, System Sequence Diagrams (Figure 3) allocate the responsibilities (required functionality) to system elements to achieve the end-to-end capability to produce the desired outcomes.

These integrated views provide the developer a clearly defined design framework to ensure full traceability between the desired operational capability, the desired outcomes (results of value) and the organizations/systems/elements required to achieve that operational capability.

As the software development industry is acutely aware, a significant power of an object-oriented approach is the ability to more easily identify reusable elements within and among enterprises to include 1) Processes such as Maintaining Relevant Situational Awareness (Figure 4), 2) System Components such as enterprise workstations, 3) Interfaces such as those between sensors and C2 systems, 4) Nodes such as Cheyenne Mountain Operations Center and its alternate center, and 5) Architectural Components such as information exchanges. The power of reuse can, if properly exploited, reduce development costs, schedule, and risks, while facilitating integration and interoperability.

Figure 3 - System Sequence Diagrams model the interactions among system elements needed to achieve the required operational capability

Our object-oriented approach to architecture-centric acquisition produces more highly integrated, agile, and affordable systems, fielded in a shorter amount of time compared to traditional approaches.

Evolution History

Launched in the year 1996 the Combatant Commanders Integrated Command and Control System (CCIC2S) program sought to field flexible, affordable and interoperable command and control (C2) and war fighting support systems. Breaking the decades-long trend of developing stovepipe C2 solutions called for innovation in managing the development of this integrated capability. One such innovation was the use of DoDAF-compliant enterprise architecture to bound the enterprise, identify key stakeholders and communicate the warfighter's requirements for new C2 capabilities and to drive the design of the system solution. After carefully considering the challenge of accurately describing such a large and complex C2 enterprise, the CCIC2S Architecture team lead by Serco developed an architecture approach based on the same analysis and design methods, and expressed using the same modeling language, as the vast majority of today's software developers. CCIC2S capabilities were modeled within an object-oriented (OO)/Unified Modeling Language (UML) enterprise architecture.

Encouraged by the robustness of the UML to express operational concepts, and the ease with which the warfighters could participate in the modeling sessions, the CCIC2S Enterprise Architecture team (Air Force Space Command, Serco, and MITRE) set out to extend this technology into the realm of system architecture. Defining the mechanism for producing a fully integrated architecture seemed to offer hope that complex requirements could be traced into the system's design, thereby reducing the risk that the delivered system would fail to satisfy the warfighter's C2 and mission support needs. To that end, Air Force Space Command (AFSPC) funded a collaborative study with members of the IBM Rational Corporation (originators of much of the OO/UML theory in practice today) aimed at defining an end-to-end UML method for translating operational capabilities into a system design. Based on IBM Rational's Unified Process for Systems Engineering (RUP-SE), the study group successfully framed an approach having the potential to take a specification of needed operational services and derive detail sufficient to begin creating a design model.

Figure 4 - An object-oriented approach enables the architect to easily identify common elements that can be developed once and reused many times across the enterprise

Within the DoD, program responsibilities are split between the Major Command (e.g. AFSPC) and the System Program Office (e.g. ESC) for development of the operational and system requirements, respectively. This separation of concerns often leads to the "throw the requirements over the fence" syndrome. The approach requires the collaboration of the operational and systems architects to be effective. With this collaboration, the approach balances both operational and system concerns in a manner that leads to effective system implementation. Without this collaboration, the warfighter's perspective could well impose requirements on the system that are unrealistic, or not understood, or both.

Implementation of this collaborative approach by the operational and systems architects should not have a negative impact on combined budget and schedule. While the activities of the approach are different from what the teams are currently performing, these activities would replace some of the current activities rather than add an additional burden. Moreover, the approach provides a higher focus on architecture interfaces making it easier to identify modular test points and operator responsibilities in the context of the system usage. This can be useful for earlier training development. In the long term, the collaborative nature of this approach results in less rework and higher quality software due to a clearer understanding of the specified requirements and desired capabilities.

The genesis of our approach traces to a report submitted by IBM Rational Software consultants to Air Force Space Command documenting the results of several workshops they facilitated in late 2004. At the workshops, IBM, Serco, and the MITRE Corporation collaborated on OO/UML techniques for bridging together DoDAF Operational and Systems Views. The IBM Rational consultants who authored the report were James Densmore and David Brown. Building on the concepts captured in this report, Rob Byrd, John Manzi, Tom Porter and Ed Seward of Serco, and Tom Folk and Eric Todd of The MITRE Corporation, expanded the discussion to provide a more comprehensive explanation of the AFSPC architecture development approach.