For several years as part of The Open Group, I have been a member and officer within the California chapter of The Association of Enterprise Architects and also belong to INCOSE – The International Council on Systems Engineering (SE). A few years ago, we had a joint meeting of both chapters to discuss the relationship of Enterprise Architecture (EA) to Systems Engineering (SE). During that meeting, a heated debate occurred in which the then-President of the local INCOSE chapter strongly asserted that EA is not only incorporated within the discipline of SE but that the differentiation between the two was not relevant. He argued there is no difference between a System of Systems (SoS) and an Enterprise, and that using the latter is not only redundant but overly emphasizes the notion of business.
This position is not fully shared by the SE community; in fact, within INCOSE there is an INCOSE Architecture Working Group (AWG) whose mission is “to expand the practice of architecture in Systems Engineering and advance the body of knowledge.” This definition places the practice of EA within the discipline of SE, rather than an allied discipline that is practiced in concert with it. Prior to the current Administration the Department of Defense held annual DoDAF (Department of Defense Architecture Framework) conferences.
During one of these, one of the speakers who was on the faculty of the National Defense University presented a paper on how DoDAF was subsumed within the discipline of SE, which is consistent with the AWG perspective. Several of us there pointed out that EA involves much more than engineering, as it includes social, cultural, business, management and other behavioral factors within the enterprise. Another participant asked the some 500 plus attending the plenary session how many identified as engineers. In response, only about 10 percent of those in the room raised their hands. This underscored, supported and led to an additional discussion of the integrity of EA (here in the context of DoDAF) as its own practice.
The recognition of EA as drawing from multiple disciplines, including SE, is foundational to The Open Group Architecture Framework (TOGAF) as practiced since TOGAF 8. Now in TOGAF 9.2 there is the strong recognition that within TOGAF’s Architecture Development Method (ADM), Phase B (Business Architecture) is primary to the development of the other architecture domains (Data, Applications, and Technical). Currently, there are many different architecture frameworks. TOGAF maintains that it can be used in conjunction with other frameworks and methodologies. This stance is significant to a current international initiative being coordinated within the OMG (Object Management Group) to establish a new Unified Architecture Framework (UAF) as an extension of attempts to coordinate the major defense architecture frameworks – DoDAF, MoDAF (Ministry of Defense Architecture Framework – used in Great Britain) and NAF (NATO Architecture Framework). This effort is known as UPDM or the Unified Profile for DoDAF, MoDAF, and NAF. Consistent with this advance is the recognition of the relevance of also incorporating leading practices from other major frameworks, including FEAF 2 (Federal Enterprise Architecture Framework) managed by the Office of Management and Budget (OMB) for federal agencies, and from various commercial architecture frameworks.
This OMG initiative has a strong System Engineering emphasis as stressed in the use of SysML or the System Modeling Language as the primary language for UPDM and the development of UML. This again raises the relationship of EA to SE. There is admittedly a shared vocabulary and concerns between the two disciplines. For example, according to Mary Tolbert at MITRE, the following are the major systems engineering processes for which OMG using SysML is attempting to move from a text-based to a model-based practice. These processes include project management, requirements management, architecture (systems architecture), testing of test cases, configuration management and risk management. The general SE vision then is to ensure the capability to create, from the information associated with architecture modeling artifacts, a variety of deliverables (here defined as reports generated from an integrated model repository): specifications, systems architecture models, interface requirements and analyses of alternatives. The vision is to move these from being based on open text to being derived from executable models – here using SysML.
According to INCOSE, Model-Based Systems Engineering (MBSE) is a “formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout development and later lifecycle phases.” Model-based implies a unique representation of architecture/engineering elements in a model repository; that only one definition exists for any element of the model, although any number of representations are possible based on these elements; and the models are integrated such that relationships between elements are themselves model elements. Likewise, for both MBSE and Model-Based EA, the intent is to facilitate traditional SE and EA activities leading to enhanced communications, specification and design precision, system design integration and the re-use of system artifacts. Thus the output of both MBSE and Model-Based EA is a system model of defined elements and relationships.
The benefits for both SE and EA models is the ability to capture, analyze, share and manage information; improve communication among stakeholders (stakeholder management); enhance the ability to manage complexity via an unambiguous and precise model of a system that can be evaluated for correctness and completeness; and to enhance knowledge capture, reuse and change management.
According to INCOSE and OMG, “the OMG Systems Modeling Language (OMG SysML) is a general-purpose graphical modeling language for specifying, analyzing, designing, and verifying complex systems that may include hardware, software, information, personnel, procedures, and facilities.” OMG promotes SysML modeling for software models, systems models to DoDAF models. They contend that SysML plus DoDAF = UPDM (the Unified Profile for DoDAF and MoDAF).
For the SE community, the UPDM is characterized as a way of expressing DoDAF artifacts using UML and SysML. The DoD has mandated the standard, which is now implemented by a number of tool vendors including Atego, IBM, No Magic, and Sparx. This enables architects to develop architectures at a high level of abstraction in a consistent way.
The purpose of UPDM is to provide a concise language to capture stakeholder concerns and express high-level architectures that address them. It is a standardization that reduces ambiguity in communicating (including external stakeholders) and supports the refinement of architecture to enable design.
UPDM is not a new architecture framework, as defined by ISO/IEC/IEEE 42010: “An architecture framework establishes a practice for creating, interpreting, analyzing, and using architecture descriptions within a particular domain of application or stakeholder community. Examples of Architecture Frameworks: MODAF, TOGAF, Kruchten’s 4+1 View Model, RM-ODP.” Also, UPDM is not a methodology or process. Rather it is a graphical enterprise modeling language.
The future of UPDM is the UAF or Unified Architecture Framework. The rationale for the new UAF is to address the large proliferation of frameworks that UPDM supports, as well as the need to support industry, federal and military use, ability to support additional frameworks (including TOGAF) and to allow implementation by non-SysML tools, as well as ones using SysML.
The proponents of UAF advocate a new grid approach as the following diagram shows:
The use of the Grid is promoted because of the difficulty in managing views with many competing frameworks, which has led to complex mapping tables and unwieldy descriptions.
Returning now to the issue raised at the beginning of this discussion regarding SE and EA, is EA subsumed within SE, redundant with SE, or parallel to each other? In a series of papers and presentations, MITRE and others have mapped framework products or artifacts to each other.
One such mapping shows the relation of DoDAF models to the TOGAF content metamodel:
While both SE and EA share many of the same modeling characteristics and address common sets of stakeholders, we need to consider how each has different perspectives and goals. We argue EA is relevant in the initiation of transformation projects, which in turn are handed off to systems architects who in turn provide these models and descriptions to SE implementers. Hence, there is a synergy between these disciplines. In EA the focus is on the business and how it is supported by information technology (via data, application and technical architecture domains). In this way, EA provides a roadmap for business transformation and gives guidance to systems engineers in the creation and implementation of systems.
Authored by by Dr. Beryl Bellman, Principal & Senior Instructor