Enterprise Architecture Defined
Enterprise Architecture (EA) involves the practice of analyzing, planning, designing, and eventual implementing of analysis of an enterprise in order to achieve the organization’s objectives.
The Gartner Group defines Enterprise Architecture (EA) as:
“… a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes.” (Gartner Glossary https://www.gartner.com/en/information-technology/glossary/enterprise-architecture-ea)
EA is best understood as a series of interrelated blueprints that define an organization’s structure, operations, IT assets, processes, inputs, and outputs and their alignment to the organization’s goals and strategic value. When used effectively, EA can be used to create a map of an organization and individual departments’, processes’, resources’, and people’s role within the enterprise and the added value of each EA element.
Significance is evolving its approach to architecture development to realize the potential of service-oriented DA frameworks. Recognizing that static, one-off, and time-bound snapshot artifacts fail to utilize the capabilities of new technologies, Significance is looking to invigorate architectural frameworks to better meet the demands of DOD leadership and facilitate more efficient data-based decision-making.
Opportunities and Challenges with EA at the Department of Defense (DOD)
Enterprise architecture has been part of the DoD requirements in the development of a wide range of technology solutions. However, over the course of its existence at the DOD, EA has devolved from supporting change to achieve business outcomes to being a “check box” exercise for various acquisition and budgeting milestones. We recognize certain EA artifacts are required for Clinger Cohen Act (CCA) and Business Capability Acquisition Cycle (BCAC) compliance. To meet those requirements, stagnant (to be able to “check the box”), often stand-alone artifacts that depict a point in time are developed and submitted as part of a compliance package. Unfortunately, too many programs and portfolios, this constitutes their commitment to EA.
This disconnect may be in part because even the term EA is often misunderstood, and the expertise has not adequately evolved or been integrated over the years. Enterprise level architecture is just one of a hierarchy of architectures. The hierarchy in its most concise terms is:
- Enterprise Architecture is a strategic level architecture that depicts an organization’s entire landscape of applications, processes, outcomes/events, and business goals across all business or mission areas.
- Portfolio or Segment Architecture is a business or mission-area architecture that depicts the landscape of applications, processes, outcomes/events, and business goals within a specific business or mission areas boundary.
- Program or Solution Architecture is a tactical level architecture for a specific program or solution.
The graphic below illustrates how DOD components traditionally develop and utilize these various levels of architecture.
The Implications of Traditional DOD EA Development
There are several problematic aspects to this paradigm.
- Inconsistency of program-level artifacts.
- Architectures are developed in isolation.
- Artifacts are created using different tools and methodologies that cannot be integrated.
- Different tools mean different modeling standards and inconsistency across and up and down the architectural hierarchies.
- Artifacts need to be manually manipulated to create higher level architectures.
- Artifacts that comprise architectures represent a snapshot in time and not real or near-real time information.
- Architectures developed largely in isolation and then rolled up after development contribute to the continuation of functional business/mission silos.
- Time-bound artifacts lead become outdated quickly and reduce effectiveness of architectures which in turn reduces the reliability of decisions based on architectural inputs.
A digitized architecture mitigates many of the challenges encountered with the typical approach above.
Tune in for Part 2 for the benefits and “how-to” of implementing a Digitized Architecture.