EA Specifications and Artifacts

The National Enterprise Architecture Methodology defines a set of specifications and reference artifacts: the EA Content Metamodel, the six reference models, viewpoints, and the requirement record with its fields and states. This page lists them as they appear in the methodology.

Overview

Where this page sits: EA specifications and artifacts the practice produces, tied to the EA Content Metamodel and to the Stage 7 requirement records.
The EA Content Metamodel defines every component used to document EA information and build the different viewpoints.
Six national reference models stem from the metamodel, one for each of the six domains.
Entities use viewpoints to present components to stakeholders at different levels of detail, and every requirement is held in the requirements register across eight fields and eight states.

EA Content Metamodel

Domain	Role of the domain in the metamodel
Business Architecture	Holds the business capabilities, organisational units, process groups, services, business processes, positions, policies, roles, activities, and products.
Beneficiary Experience Architecture	Describes beneficiary segments, journeys, touchpoints, service channels, and the indicators that measure the experience.
Data Architecture	Defines data entities, attributes, relationships, data owners, and classification and governance levels.
Applications Architecture	Defines applications, their functions, interfaces, integrations, and their link to capabilities and services.
Technology Architecture	Defines the infrastructure components: servers, networks, databases, cloud platforms, and operating environments.
Security Architecture	Defines the protection controls, access mechanisms, identity management, and cybersecurity compliance requirements.

The six national reference models

Business Architecture Reference Model: administrative, core, and supporting capabilities, drawing on APQC and Saudi government practices.

Beneficiary Experience Reference Model: components built on the centralised beneficiary policy and international customer experience references.

Data Architecture Reference Model: aligned with the national data governance policies and personal data protection controls.

Applications Architecture Reference Model: reference components aligned with DGA regulations and national solutions.

Technology Architecture Reference Model: components built on the cloud computing guideline and business continuity controls.

Security Architecture Reference Model: components based on ISO 27001, Zero Trust Architecture, and National Cybersecurity Authority controls.

Viewpoints and levels of detail

Viewpoints are structured presentations of EA components that serve stakeholders at levels of detail ranging from a high-level view down to operational specifics. The viewpoints are set in the development cycle charter at Stage 1, then built up inside the current- and future-state documentation.

Capability viewpoint: links administrative, core, and supporting capabilities to services and procedures.

Service viewpoint: shows services, their channels, and their link to capabilities and applications.

Data viewpoint: presents data entities, their relationships, and their governance.

Applications viewpoint: shows applications, their functions, and their integrations.

Technology viewpoint: presents the infrastructure and the operating environments.

Security viewpoint: presents controls and protection and compliance requirements.

Requirement record: eight fields and eight states

Field	Description
Requirement Code	The approved identifier for the requirement, used for tracking and reference.
Requirement Text	A description of the challenge to be addressed through the EA components.
Requirement Source	The entity or stakeholder that raised the requirement.
Requirement Domain	The primary EA domain to which the requirement belongs.
Affected Domains	The other domains whose components must be developed to address the requirement.
Related Requirements	The codes of related requirements that may affect the processing of this one.
Requirement State	The current position of the requirement in its lifecycle, per the eight approved states.
Implementation Priority	The priority level of the requirement: High, Medium, or Low.

Approved

Suspended

Canceled

Current State

Future State

Planned for Implementation

In Progress

Completed

Reference note

Key takeaway

These specifications follow the National Enterprise Architecture Methodology, issued by the Digital Government Authority under NORA, with its names for the metamodel, the six reference models, the viewpoints, and the requirements register. Entities can add their own components or fields inside the register, as long as the eight approved fields and eight states remain in place.

General EA component model

Building blocks, attributes, and relationships.

Reference models

Six national reference models, one per domain.

EA views

Viewpoints for describing the EA.

Ready to start?

Book a free consultation. We walk through your priorities and recommend the right starting point.

Overview

Where this page sits: EA specifications and artifacts the practice produces, tied to the EA Content Metamodel and to the Stage 7 requirement records.
The EA Content Metamodel defines every component used to document EA information and build the different viewpoints.
Six national reference models stem from the metamodel, one for each of the six domains.
Entities use viewpoints to present components to stakeholders at different levels of detail, and every requirement is held in the requirements register across eight fields and eight states.

EA Content Metamodel

Domain	Role of the domain in the metamodel
Business Architecture	Holds the business capabilities, organisational units, process groups, services, business processes, positions, policies, roles, activities, and products.
Beneficiary Experience Architecture	Describes beneficiary segments, journeys, touchpoints, service channels, and the indicators that measure the experience.
Data Architecture	Defines data entities, attributes, relationships, data owners, and classification and governance levels.
Applications Architecture	Defines applications, their functions, interfaces, integrations, and their link to capabilities and services.
Technology Architecture	Defines the infrastructure components: servers, networks, databases, cloud platforms, and operating environments.
Security Architecture	Defines the protection controls, access mechanisms, identity management, and cybersecurity compliance requirements.

The six national reference models

Business Architecture Reference Model: administrative, core, and supporting capabilities, drawing on APQC and Saudi government practices.

Beneficiary Experience Reference Model: components built on the centralised beneficiary policy and international customer experience references.

Data Architecture Reference Model: aligned with the national data governance policies and personal data protection controls.

Applications Architecture Reference Model: reference components aligned with DGA regulations and national solutions.

Technology Architecture Reference Model: components built on the cloud computing guideline and business continuity controls.

Security Architecture Reference Model: components based on ISO 27001, Zero Trust Architecture, and National Cybersecurity Authority controls.

Viewpoints and levels of detail

Capability viewpoint: links administrative, core, and supporting capabilities to services and procedures.

Service viewpoint: shows services, their channels, and their link to capabilities and applications.

Data viewpoint: presents data entities, their relationships, and their governance.

Applications viewpoint: shows applications, their functions, and their integrations.

Technology viewpoint: presents the infrastructure and the operating environments.

Security viewpoint: presents controls and protection and compliance requirements.

Requirement record: eight fields and eight states

Field	Description
Requirement Code	The approved identifier for the requirement, used for tracking and reference.
Requirement Text	A description of the challenge to be addressed through the EA components.
Requirement Source	The entity or stakeholder that raised the requirement.
Requirement Domain	The primary EA domain to which the requirement belongs.
Affected Domains	The other domains whose components must be developed to address the requirement.
Related Requirements	The codes of related requirements that may affect the processing of this one.
Requirement State	The current position of the requirement in its lifecycle, per the eight approved states.
Implementation Priority	The priority level of the requirement: High, Medium, or Low.

Approved

Suspended

Canceled

Current State

Future State

Planned for Implementation

In Progress

Completed

Reference note

Key takeaway

EA Specifications and Artifacts

Overview

EA Content Metamodel

The six national reference models

Viewpoints and levels of detail

Requirement record: eight fields and eight states

Reference note

Related

General EA component model

Reference models

EA views

Ready to start?

EA Specifications and Artifacts

Overview

EA Content Metamodel

The six national reference models

Viewpoints and levels of detail

Requirement record: eight fields and eight states

Reference note

Related

General EA component model

Reference models

EA views

Ready to start?