White Paper | Government Enterprise Reference Architecture

Government Enterprise Architecture

Reference
The Government Enterprise Architecture Reference (GEAR) is not just a tool but a pivotal
instrument for digital transformation in government organizations. Its structured approach is
the backbone for implementing digital transformation visions, underscoring its crucial role .

Authors Introduction
Dr. Darren Pulsipher Digital transformation is the application of computing, networking, storage,
Dr. Anna Scott and analytic technologies to data to enable organizations to modify, enhance,
improve, or deploy more efficient, more compelling, and more timely services
Table of Contents to their constituents and organizations while meeting mission outcomes. It’s
Introduction .......................................... 1 the opportunity to reimagine organizational practices and capabilities in light
Digital Transformation Methodology ... 1 of technological innovations. New technology can enable the digital
GEAR Overview ..................................... 2
transformation of government, but determining where to start, what
provides value, how new capabilities work with existing systems, and what is
Physical GEAR........................................ 2
economically feasible can be daunting. Many governments and government
Logical GEAR.......................................... 3 organizations have a vision for digital transformation. However, mapping
Application / Services Layer ................. 5 their vision to innovative technology and existing systems can be complex.
Data Management Layer...................... 8 This paper presents an approach to help governments implement their
Software Defined Infrastructure ........ 10 visions while taking advantage of current systems (no need to rip and replace)
Common Physical Layer ..................... 10
and ensuring that the new capabilities are interoperable, manageable,
future-proof, and scalable.
Identity and Security .......................... 12
Security............................................... 12
Digital Transformation Methodology
Conclusion ........................................... 12
Only some organizations have the luxury of starting from scratch when
embracing digital transformation. Almost always, an organization has very
well-developed systems that have existed for years or decades. These
systems also represent substantial investment and significant institutional
knowledge. Many of these systems work well enough for the businesses’
needs and do not need to be altered. However, they may have valuable data
that – if it were available – could create additional value when looked at at
an organizational level. Alternatively, existing systems may no longer be able
to provide the level of service needed for the organization to be competitive.
Matching current systems to the future vision and performing a gap analysis
provides a straightforward methodology for getting started with digital
transformation.

1
White Paper | Government Enterprise Reference Architecture

The following steps can be taken to identify gaps and GEAR Overview
find solutions:
This paper proposes a Government Enterprise
1. The first step in the methodology is to define the Architecture Reference (GEAR) suitable for roughly 80%
problem(s) to be solved and the vision of the future of the government use cases relevant to digital
state. This strategic planning is crucial for the transformation. GEAR is designed to provide a
success of digital transformation. foundational structure supporting a wide range of
2. Define the current state (including data sources applications and services using all data available across
and existing software and hardware). an organization. This basic architecture will need
3. Map your current capabilities to the Government customization because of the wide variety of use cases
Enterprise Architecture Reference (GEAR). and existing systems. Additionally, there will be many
4. Assess gaps. GEAR instances because multiple suppliers and
5. Develop a plan for how to fill these gaps using the software vendors can provide each logical architectural
reference architecture as a guide for an component.
interoperable future state.
GEAR is based on open, interoperable systems since
6. Implement projects to fulfill your vision based on
proprietary ones are constrained to single usage and
organizational priorities.
can add cost and complexity if done at scale. GEAR is
This oversimplifies but provides a starting point for designed to work with existing systems where possible
making high-level decisions and tackling a complex and incorporate new solutions where valuable.
problem. In this context, the GEAR offers a basis for
We explain the GEAR using two diagrams:
understanding what new technology can provide and
how it works together. It helps organizations “see” the 1. Physical – Diagram to show how to compute maps
art of the possible to decide quickly where technology to applications, networks, and physical locations.
can bring organizational value. Edge-to-cloud 2. Logical – Diagram to show the underlying software
architectures are inherently complex and can rarely be stack that manages data, storage, orchestration,
solved by a single company. This means that applications, and services and how these are
implementation of the reference architecture, supported by hardware (HW) and networks.
especially when integrated with existing systems, will
require multiple partners and some customization. Physical GEAR
GEAR is designed to provide a data management A single, high-level diagram (see Figure 1) showing how
structure for large organizations with complex the primary data sources and their physical locations
requirements. If this approach is followed, an can benefit digital transformation. For example, this
organization can add new capabilities that will mapping indicates the relevance of networks in the
integrate existing systems in an open and interoperable overall architecture. In enterprise, we take it for
fashion. Even if an organization starts with only a few granted that we have high reliability and bandwidth
specific problems to solve in the short term, it's connectivity. For many operational data sources, this is
essential to plan for existing changes in the future. This different. Data may be needed by a critical function
will minimize complexity, cost, and maintenance as an (related to health and human safety), meaning that a
organization continues its digital transformation typical cellular network does not have the required
journey. Digital transformation is a journey that can ultra-high reliability.
take years to complete, so this approach is an iterative
process applied as the organization grows and evolves.

2
White Paper | Government Enterprise Reference Architecture

Figure 1 Physical Representation of the Government Enterprise Architecture Reference

Figure 1 illustrates how data can be collected, analyzed, data sources poses unique challenges (protocol
shared, and stored from edge to cloud using a language, security, update frequency, etc).
reference architecture built on a standard software
(SW) stack that can operate on almost any type of Logical GEAR
hardware. The GEAR's design is highly flexible, A cloud or edge-only architecture can solve a few of
empowering organizations to move applications and today’s data problems. Resources from the edge to the
data based on business needs and the economics of cloud are often needed to optimize the solution for
data transport, storage, and computing costs. effectiveness (e.g., real-time) and cost (e.g., total TCO).
This physical diagram grossly oversimplifies almost As a result, we have developed a conceptual
infinite use cases and existing applications. It is architecture that targets multi-hybrid cloud and edge
intended to help organizations map where their data computing strategies, where data and applications can
sources, computers, and networks can reside and easily be moved as needed to optimize results and deliver on
visualize how these elements come together to form a the mission.
workable architecture. This is especially important for To enable a future-proof and expandable system, it is
the dynamic and converged edge environments. essential to understand how different parts of the
Existing systems in these areas are often designed and system relate to each other and establish isolation
installed as OT (operations technology) that is usually layers (through standard interfaces or abstractions).
hardwired and heavily reliant on isolation for security. This isolation allows the various systems in the solution
Bringing data into a converged architecture from these to “grow” in parallel with minimal effect on each other.

3
White Paper | Government Enterprise Reference Architecture

It also allows multiple vendors to be used within each case needs. This is the key to GEAR’s flexibility and
layer, making the system flexible and adaptable with no interoperability.
vendor lock. Establishing standard interfaces between
The logical enterprise architecture (Figure 2) shows
the sub-systems further allows the easy adoption of
how the different subsystems (layers) fit together.
new features for hardware or software based on use

Figure 2: Logical Representation of the GEAR

Because the purpose of changing existing systems and analytics, and AI creates value. Since data and analytics
adopting new technology is to improve outcomes and do not have to be collocated, we have called them
better meet mission/organizational needs, we place separate entities in the reference architecture.
“organization value creation” at the top of the stack. It’s
The other layers in the stack form the structure that
critical not to lose sight of the purpose of digital
allows data to be collected and analyzed. We will first
transformation and to ensure that innovations are
briefly overview each layer and then cover each in
employed to provide clear benefits to the organization
depth.
and its constituents. Value can take many forms, but
some common examples are: • Application / Services Layer—Development,
testing, deployment, monitoring, and
• High-level situational awareness for
provisioning of services and applications in the
management (common operating picture).
solution space. This is the primary interface to
• Improved constituent services through real-
Organizational Value Creation.
time data access and analysis.
• Data Management Layer—Manages (curation,
• Planned downtimes enabled by predictive
governance, lifecycle management, and tagging)
maintenance.
data across a heterogeneous infrastructure
• Improved organizational efficiency.
(Cloud, Data Center, Edge, and Client).
• Lower cloud, storage, and compute costs.
• Software-defined Infrastructure—Responsible
Data and applications are undervalued because they for managing the physical layer's solution
form the foundation for value creation. Data may be (deploying, monitoring, and provisioning).
the new oil, but how data is used by applications,

4
White Paper | Government Enterprise Reference Architecture

• Physical Layer—This layer is Responsible for how they interface. It is often possible to build in state-
commanding, controlling, and monitoring the of-the-art features (use of AI models) by expanding
solution's physical devices (Compute, Storage, current capabilities. No one wants to rip and replace
Network, and Accelerators). systems that are in place and working. Instead, the goal
• Security Aspect – Gives a standard security model is to utilize the current devices as a foundation to build
across the subsystems of the solution. for the future goal. A roadmap of technology and
• Identity Aspect—The ability to uniquely identify process changes shows how the foundation can be built
and attest the identities of users, hardware, upon to achieve long-term architecture.
applications, services, and virtual resources.
Application / Services Layer
Many organizations already have many of these The Application / Services Layer can be broken into 2
subsystems in their toolbox of solutions, so developing component layers (see Figure 3):
a solution from scratch is rarely necessary. The
recommended starting point is to understand what you • The Application Management Layer (AML)
are currently using, how those tools fit together, and • The Services Management Layer (SML)

Figure 3 Application Services Layer

Application Management Layer Layer and its capabilities are exposed to the AML. For
The AML manages applications and workflows and the example, training a large language model runs on Intel
development, testing, deployment, and updates of Habana hardware most efficiently.
those applications and workloads. The AML contains
The AML contains sub-packages that group common-
abstractions that help App Development, DevOps, and
off-the-shelf tools together. In the Analytics Services
IT Operations manage complex workflows and
package, standard tools for data analytics can be found,
applications through the application development
including business data understanding, modeling, and
lifecycle. The AML sits at the top of the system stack
simulation. AI/ML Services represent various tools and
and communicates directly with the Data Management
services focusing on Artificial Intelligence and Machine
Layer and the Service Management Layer. It also
Learning algorithms and solutions. These two packages
leverages the Identity Aspect and Security Aspect
take advantage of the application and workflow
layers. Because certain applications operate most
services that allow these solutions to be orchestrated
efficiently on specific hardware types, the Physical
at the highest level of integration by providing a

5
White Paper | Government Enterprise Reference Architecture

standard definition framework to show how these clouds (see Figure 4). It is a middleware layer in the
applications and workflow interact. architecture responsible for orchestrating and
managing services across multiple clouds (public and
Several tool suites have been built to aid DevSecOps.
private) and the edge. The SML coordinates with the
These tools are grouped in the DevSecOps Services and
Data Management Layer and the Software Defined
include Automation Frameworks (Salt, Chef, puppet,
Infrastructure. It takes requests from the AML to
ansible), CICD tools (Gitlab, GitHub, Jenkins, etc.), and
deploy services that makeup applications and
Environment Management.
workflows.
Service Management Layer
The Service Management Layer (SML) subsystem
manages services, stacks, environments, and multi-

Figure 4: Actors of the Service Management Layer

The main goal of the SML is to provide the Application applications and services are deployed and managed
Developer with a simple, repeatable, robust automatically without human interaction. Decisions
mechanism to deploy services into the multi-cloud and about where services should land should be automatic
edge ecosystem. It must also offer IT Operations based on the IT policies established, not determined by
mechanisms to enforce cost, reliability, and security the Application Developer or IT Operations Engineer.
policies. Applications and Services are deployed to
The SML has several actors who work with the
cloud assets based on these policies and can be run
subsystem. Each one of these has a different
across cloud/edge boundaries as dictated by the IT
motivation for using the system. Even though some of
policies enforced in the system. All communications
the methods used are the same, their reasons for using
between services should follow secure communication
the system are very different.
protocols as the IT policies dictate. The key is that a
single portal or gateway should be used so that

6
White Paper | Government Enterprise Reference Architecture

Figure 5: Motivators of Actors of Multi-Hybrid Cloud

• Platform As A Service—built for Application

Developers, it focuses on reusing services and
• IT Operations Motivators: optimizing
decreasing the complexity of using those services
infrastructure for cost, protecting infrastructure
to build applications.
and IP, and increasing reliability and resiliency.
• DevOps Engineer Motivators: automating These tool sets have been developed by and for specific
everything, streamlining code pipelining, and actors. Integrating these tools helps to fill gaps in the
managing build and deployment with CI/CD. individual devices.
• Application Developer Motivators: repeatable
and reusable service stacks, deploying services
across cloud and environments.
• Stack Developer Motivators: delivering solutions
in quick iterations, concise break, fix, and deploy
cycles.

The SML spaces are full of tools that can be integrated

to deliver the use cases demanded by the actors in this
space, which can be categorized as follows:

• Cloud Management Platforms - built for IT

Operations focusing on multi-cloud support and
management of infrastructure profiles across
Figure 6: Convergence of tools
multi-clouds.
• Automation Frameworks - built for DevOps and The SML has sub-systems as part of the multi-cloud
Stack Development, focusing on providing and architecture (for private, public, and micro clouds),
deploying software in a repeatable/reusable including:
manner.
• On-demand self-service portal

7
White Paper | Government Enterprise Reference Architecture

• Environment Management - manages 2. Data Definition Framework that defines data

environments (dev, test, prod) across multiple pipelines, categorization of data, and their
clouds. generating or storage sources.
• Service Orchestrator - orchestrates the services 3. Common Data Services like ingress, transform,
in different environments. store, and egress.
• Service Registry – provides a centralized
Almost all architecture actors have some input into the
repository of service definitions.
DML:
• Data Coordinator - works with the DML to
orchestrate data and services. • Data Officer – set data policy and strategy.
• Security - works with the security policies and • Data Steward – manage data and policies.
tools to ensure applications and services • IT Operations – manage infrastructure.
communicate securely. • Application Developer – develop Apps.
• Provision Engine - provisions software stacks and • Data Scientist – analyze data and derive
services on infrastructure. intelligence.
• Cloud Broker - manages the clouds (which can • Data Engineer – manages sources, blueprints, and
manage which request). procedures.

Data Management Layer The DML subsystem supports multiple data

The DML is the newest architectural element in architectures at the same time. This allows the Data
enterprise architecture and is crucial in providing the Engineer to quickly build repeatable blueprints for
flexibility needed for today’s demanding computing different data architectural approaches based on the
environments. It was developed to handle the most efficient for a specific problem. As a result, the
complexity of managing data across multiple data same system or solution can utilize various operating
centers, clouds, and edge devices. The Data data models. Data models can be categorized into two
Management Layer (DML) manages data across the architecture types:
ecosystem, including data lifecycle management, data
security and governance, storage infrastructure,
analytics, data sources, and application data usage.
Across all architectures, there are three standard
components:

Figure 8: Data Architecture Types

• Centralized – Data Warehouse and Data Lake

• Distributed – Data Mesh, Data Exchange, Data
Fabric, Data Mart, and Data Streams

The centralized processing approach utilizes data

architecture to benefit the end users. This paradigm is
good for some data use cases but not all. Many
Figure 7: Data Management Layer centralized data architectures fall apart as more
1. The Data Management component orchestrates systems move outside the traditional data center walls.
the ecosystem's data movement, lifecycle This is where distributed processing architectures
management, and governance. become essential. The distributed architecture is
flexible enough to handle data processing modes from

8
White Paper | Government Enterprise Reference Architecture

edge to cloud. Since these architectures are more problems with Data Lake architectures caused by
numerous and less well-known, we will discuss them in centralizing all of the data. Data Fabrics process data on
more detail below. the edge where the source generates the data. This
distributed architecture follows much of the same path
Distributed Operating Data Models that cloud technology did in the early 2000s and
Data Mesh includes centralized control, orchestration, and
In the Data Mesh architecture, applications can be management of the data.
moved close to the data or the data close to the
applications. Data processing is done on edge devices,
and results are pushed to the data center/cloud to be
linked. This contrasts with traditional Data Warehouses
and Data Lakes, where data is stored in a centralized
location.

Figure 11: Data Fabric

Figure 9: Data Mesh
Data Mart
Data Exchange
A Data Mart is a small data repository for structured
Another mode of operation is Data Exchange. This takes
data specific to a department. Tailored to the detailed
the Data Mesh concept and extends it to different
problem statements, they contain copies of data from
classifications or owners of data. This mode limits the
limited sources and typically a smaller data set. Data
movement of data and who has access to it, making it
Marts usually limit access to the data and report to one
ideal for Government and Healthcare, where privacy
organization or a small group of users in one
and classification regulations restrict data access. Data
organization. Data scientists leverage Data Marts to
Exchange architecture allows policy gates to limit the
build complex analytical models, generate timely
data that can be passed back to the application
periodic reports that require highly predictable
requesting the data. It also provides analytics/services
performance, and work with sensitive data and
for the geo-fenced data site.
resulting reports.

Figure 10: Data Exchange

Data Fabric
.
Data Fabrics are the natural next architectural
evolution to emerge since they resolve some of the Figure 12: Data Mart

9
White Paper | Government Enterprise Reference Architecture

Data Streams
Data Stream architectures allow data analytics to be
processed in the data stream. Each Data Stream
manipulates the data as it is ingested and egressed to
another application, report, or data stream. Data
Streams allow for data to be used anywhere in the
ecosystem, including on the edge devices, in the data
center, in the cloud, and even in transit between the
different types of infrastructure. Analytical reports can
be generated parallel across multiple devices by Figure 14: Software Defined Infrastructure
combining data transforms through data streams.
These key architectural elements are minimal viable
features for a standard interface to IaaS solutions used
in a Physical Layer. The ability to interact with a
standard API interface regardless of the type of Cloud
is essential for interoperability between private and
public cloud offerings. To include Edge Devices into the
ecosystem, the concept of a micro cloud was developed
with the same minimal Common Infrastructure API.

Figure 13: Data Streaming

Software Defined Infrastructure

Software Defined Infrastructure (SDI) contains the
abstractions for private and public clouds. The SDI layer
is a familiar standard interface for all cloud resources-
virtual, container, and bare metal. The Software Figure 15: Multi-Hybrid Cloud
Defined Infrastructure Layer (SDI) is a middleware layer
in the architecture. It primarily manages Infrastructure This concept extends the boundaries of the cloud to the
as a Service (IaaS) operations and management. SDI edge and allows for the management of infrastructure
architectural elements are well-known and established and applications across a traditionally tricky border.
in the industry, with commercial and open-source The shared Common Infrastructure API allows the
product offerings available (VMWare, OpenStack, Multi-Cloud Orchestrator from the Service
Nutanix, etc.). The critical elements of an SDI layer are Management Layer to request infrastructure (Bare
Orchestration and Control, Infrastructure elements metal, Virtual, or containerized) to deploy complex
(Storage, Network, Compute/Accelerators, and applications across several cloud offerings.
Security), and a Common Infrastructure API Gateway.
Common Physical Layer
The Physical Layer (PL) contains abstractions allowing
better management across an ecosystem inside the
data center, cloud, and edge devices. These
abstractions give the ability to manage highly variable
hardware configurations by describing the common
operating and taxonomy of the devices. This

10
White Paper | Government Enterprise Reference Architecture

architectural layer has the goal of addressing the resources in a “Profile” abstraction. The Device has a
following characteristics: simple interface for control and telemetry through the
Device Profile, which allows the Software-Defined
• Common Taxonomy
infrastructure layer (SDI) to deploy and provision
• Portability and Interoperability applications and services to take advantage of the
• Security and Root of Trust Device’s specialized hardware.
• Common Management Control Plane
• Performance Optimization With the explosion of edge computing and sensors, the
• Stability and Reliability complexity of managing the devices in conjunction with
• Flexibility and Agility the cloud and the data center has dramatically
expanded. Managing 10s to 10,000s of devices is
overwhelming for IT operations engineers, and many
management and control architectures cannot scale
appropriately. For this reason, the enterprise architect
has created the Aggregated Device that allows the
grouping of devices into collections that can be
managed and controlled more easily. Aggregated
devices can contain devices or other aggregated
Figure 16: Physical Layer Representation devices, giving the ability to have infinite layers in the
hierarchy of devices.
The PL sits at the bottom of the Architectural stack but
interacts with all other layers and aspects. It relies on
Security and Identity aspects to establish the hardware
root of trust, identity, and data encryption at the lowest
levels. Figure 16 shows the abstract layers established
across Edge, Legacy, Data Center, and Cloud physical
resources.

Figure 18: Physical Aggregate Layout

Often, organizations combine the physical

management and the logical management of devices.
Combining the physical and logical approaches is
problematic as they create highly coupled, rigid, and
fragile solutions that cannot adapt to change.

The enterprise architecture separates the physical and

logical topologies, allowing for flexible architecture in
business and operating environments. Additionally, the
Figure 17: Edge Device two topologies give the flexibility to establish an
authentic edge to cloud architectures, including setting
The critical element in this layer is called a Device. A up a cloud that spans resources in prem data centers,
Device contains one or more hardware elements, public clouds, and edge devices. It allows scheduling
including processors, memory, accelerators, storage,
and managing applications and services across
and network capabilities. Each Device has a snapshot of traditional boundaries.
its capabilities, hardware, and currently available

11
 White Paper | Government Enterprise Reference Architecture

an entity, human or machine. Once an entity is

authenticated, it is given authority to access other
resources in the system. By providing identity to every
element in the design, mishaps in security can be
mitigated and better controlled. Given the new focus
on Zero Trust Architectures, we constantly re-verify
identity, and authorization is revoked if credentials do
not match those expectations.
Figure 19: Logical and Physical Separation

Figure 19: Logical and Physical Separation This figure

shows three clouds that share devices and span the
control topology established for optimized IT
operations. This flexibility allows clouds (logical
devices) to adapt to changing environments. These
changes can include cyber threats, physical disasters,
partial connectivity of edge devices, or even someone
tripping over a network connection in the data center.
Figure 20: Identity and Security

Security
Identity and Security Security contains security tools and subsystems used
The Identity provides identity through all layers of the throughout the architecture. It is used in every layer
enterprise architecture. This aspect is responsible for and was developed to provide a standard mechanism
the trusted identity of users, devices in the data center, for performing common security use cases, such as
the cloud, the edge, services and applications, and encryption, detection, remediation, and root of trust.
data. Having a standard identity management systemis
critical to having consistency in the system. This Conclusion
identity must be trusted so that the data, applications, With the complexity and ever-changing ecosystem of
and hardware can deliver solutions that can be used technology, business process innovation, and operating
confidently. environments, we have developed the GEAR to show
Identity has critical sub-systems that help manage how all the elements needed to deliver digital solutions
identity: Access, Authorization, Authentication, and come together in a consistent and manageable
Key Management. Authenticating an entity in the framework. This facilitates bringing new capabilities to
system is the first step in identity management. Keys existing architectures by clarifying their interactions
are used to certify and attest to the authentication of and dependencies and enabling organizations to
transform rationally and cost-effectively digitally.

¹ All information provided here is subject to change without notice. Contact your Intel representative to obtain the latest Intel product specifications and roadmaps.
Intel technology’s features and benefits depend on system configuration and may require enabled hardware, software, or service activation. Perfo rmance varies depending on system configuration.
No computer system can be secure.
Copyright © 2024 Intel Corporation. All rights reserved. Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and other countries.
* Other names and brands may be claimed as the property of others.

12