Enterprise Architecture and Systems Engineering: Component or Relationship Disciplines
The article examines the relationship between enterprise architecture and systems engineering, discussing overlapping frameworks such as TOGAF, DoDAF, UPDM, and model‑based approaches, and argues that while they share terminology and goals, EA focuses on business transformation and IT alignment, whereas SE emphasizes technical system development.
As a member of the Open Group and longtime participant in the INCOSE (International Council on Systems Engineering), I have taken part in joint meetings discussing the relationship between Enterprise Architecture (EA) and Systems Engineering (SE), where a heated debate arose when the local INCOSE chapter chair claimed that EA is fully contained within SE and that distinguishing the two disciplines is irrelevant.
The Southeast community did not fully accept this stance; INCOSE’s Architecture Working Group (AWG) aims to "extend architecture practice within systems engineering and advance the knowledge base," placing EA practice inside SE procedures rather than as a parallel discipline.
At a DoDAF (Department of Defense Architecture Framework) conference, a Defense University lecturer presented a paper on integrating DoDAF into SE, echoing the AWG view, while some participants emphasized that EA also encompasses social, cultural, business, management, and other behavioral factors beyond pure engineering.
It is recognized that EA derives from multiple practices, including SE, and this insight has been part of the open‑group architecture framework (TOGAF) since TOGAF 8; TOGAF 9.2 now strongly acknowledges that Business Architecture (Phase B of the ADM) drives the development of other architecture domains (Data, Application, Technology).
Numerous architecture frameworks exist today. TOGAF claims it can be combined with other frameworks, and this position aligns with the OMG‑coordinated effort to create a Unified Architecture Framework (UAF) that unifies major defense frameworks—DoDAF, MoDAF, and NAF—into a single profile known as UPDM.
When SysML or UML is used as the primary language for developing UPDM and UAF, the OMG activity has a strong systems‑engineering focus. The MBSE (Model‑Based Systems Engineering) processes promoted by OMG include project management, requirements management, system architecture, test case development, configuration management, and risk management.
INCOSE defines MBSE as a formal modeling application that supports system requirements, design, analysis, verification, and validation from concept through the entire lifecycle, emphasizing a unique, integrated repository where each model element has a single definition but may have multiple representations.
The benefits of SE and EA models include the ability to capture, analyze, share, and manage information; improve stakeholder communication; assess model correctness and completeness; and enhance knowledge reuse, change management, and design precision.
OMG defines SysML as a general‑purpose graphical modeling language for specifying, analyzing, designing, and verifying complex systems that may include hardware, software, information, people, processes, and facilities, and asserts that SysML combined with DoDAF equals UPDM.
For the SE community, UPDM is described as a way to represent DoDAF artifacts using UML and SysML, and many tool vendors (Atego, IBM, No Magic, Sparx) have implemented the standard, enabling architects to develop architectures at a higher level of abstraction consistently.
UPDM’s purpose is to provide a concise language to capture stakeholder concerns and express high‑level architecture, standardizing communication, reducing ambiguity, and supporting architecture optimization for design.
UPDM is not a new architecture framework; according to ISO/IEC/IEEE 42010, an architecture framework defines practices for creating, interpreting, analyzing, and using architecture descriptions, with examples such as MODAF, TOGAF, Kruchten’s 4+1 view model, and RM‑ODP. UPDM is a standardized graphical enterprise modeling language, not a method or process.
The future of UPDM is the Unified Architecture Framework (UAF), which aims to address the proliferation of supported frameworks, meet industrial, federal, and military needs, support additional frameworks (including TOGAF), and allow implementations with both SysML and non‑SysML tools.
The grid approach advocated by UAF supporters is illustrated below:
The grid is promoted because managing multiple competing frameworks leads to complex mapping tables and cumbersome descriptions.
Returning to the original question—whether EA is contained within SE, redundant, or parallel—various papers and presentations (e.g., from MITRE) map framework artifacts to each other, such as the shown mapping between DoDAF models and the TOGAF metamodel.
Although SE and EA share many modeling features and stakeholder concerns, they differ in perspective: EA focuses on business transformation and how IT (data, applications, technology) supports that business, providing a roadmap; SE provides the technical system models that architects use to implement the solutions.
Architects Research Society
A daily treasure trove for architects, expanding your view and depth. We share enterprise, business, application, data, technology, and security architecture, discuss frameworks, planning, governance, standards, and implementation, and explore emerging styles such as microservices, event‑driven, micro‑frontend, big data, data warehousing, IoT, and AI architecture.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.