Methodology of

National Overall Reference

Architecture (NORA)

31 March, 2024
Document Type: Methodology
Document Classification: Public
Issue No: 1.0

1 | National Overall Reference Architecture (NORA) Document No: DGA-1-2-1-212

DGA-1-2-1-212
 Contents

1 Introduction 5

1.1 Document Purpose 5

1.2 National Enterprise Architecture (NEA) Framework 5

1.3 Goals of NORA 6

1.4 Features of NORA 6

1.5 Defining A Purpose for Agency EA 7

1.6 NORA Methodology 9

1.7 NORA and NEA Framework 11

2 Stage 1 – Develop EA Project Strategy 12

2.2 Stage Summary 12

2.3 Stage Purpose 12

2.3 Stage Initiation 12

2.4 Key Steps in Stage 1 12

3 Stage 2 – Develop EA Project Plan 14

3.1 Stage Summary 14

3.2 Stage Purpose 14

3.3 Stage Initiation 14

3.4 Key Steps in Stage 2 15

2 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

 4 Continues Governance 15

4.1 Purpose of Governance 15

4.2 Outcome of Governance 16

4.3 Governance Initiation 16

4.4 Key Areas in Governance 16

5 Stage 3 – Analyze Current Stage 19

5.1 Stage Summary 19

5.2 Stage Purpose 19

5.3 Stage Initiation 19

5.4 Key Steps in Stage 3 20

6 Stage 4 – Develop EA Framework 21

6.1 Stage Summary 21

6.2 Stage Purpose 21

6.3 Stage Initiation 21

6.4 Key Steps in Stage 4 22

7 Stage 5 – Build Reference Models 22

7.1 Stage Summary 22

7.2 Stage Purpose 23

7.3 Stage Initiation 23

7.4 About NEA Reference Models 23

7.5 Key Steps in Stage 5 26

8 Stage 6 – Build Current Architecture 27

8.1 Stage Summary 27

8.2 Stage Purpose 27

8.3 Stage Initiation 28

8.4 Key Steps in Stage 6 28

3 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

 9 Stage 7 – Build Target Architecture 41

9.1 Stage Summary 41

9.2 Stage Purpose 41

9.3 Stage Initiation 41

9.4 Key Steps in Stage 7 42

10 Stage 8 – Develop Transition Plan 48

10.1 Stage Summary 48

10.2 Stage Purpose 49

10.3 Stage Initiation 49

10.4 Key Steps in Stage 8 49

11 Stage 9 – Development Management Plan 51

11.1 Stage Summary 51

11.2 Stage Purpose 51

11.3 Stage Initiation 51

11.4 Key Steps in Stage 9 52

12 Stage 10 – Execute and Maintain 52

12.1 Stage Summary 52

12.2 Stage Purpose 53

12.3 Stage Initiation 53

12.4 Key Steps in Stage 10 53

4 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

1. Introduction
1.1 Document Purpose
The purpose of this document is to describe and elaborate on the National Overall
Reference Architecture (NORA) that will be used as a guide for government
agencies to develop their own Enterprise Architecture (EA). This document also
describes, to some extent, how NORA is linked to the overall National Enterprise
Architecture (NEA) Framework.

1.2 National Enterprise Architecture (NEA) Framework

The National Enterprise Architecture (NEA) Framework is a key element for the
national Digital envisioned to incorporate a federate approach to enterprise
architecture for the Kingdom of Saudi Arabia (KSA). NEA Framework supports the
identification of reusable components and services and facilitates a basis for
Information Technology (IT) investment optimization. In addition, NEA enables
more cost-effective and timely delivery of e-services through a repository of
standards, principles, and reference models that assist in the design and delivery
of business services to citizens, residents, commercial establishments, and inter-
government collaboration.

Strategy

Long term Plan (Vision & Objectives) Policy

Models
Governance

Meta Reference Models

Model (PRM, BRM, DRM, ARM, TRM/SP)
Best Maturity
Segment Architecture Practice Model

Operation

Capability Guidelines/ NORA

NEA System
Building

Figure 1 NEA Framework

5 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

 1.3 Goals of NORA
The goals of NORA are as follows.
• Define the scope and requirements of the EA at the government agencies
• Help government agencies to have a smooth and effective EA implementation
• Ensure quality of government agency’s EA through systematic processes and
recommendations
• Alignment of agency’s EA with Saudi government's national architecture and
Digital transformation plans to facilitate whole of government approach
• Facilitate EA utilization, promotion and capability building in government
agencies.

1.4 Features of NORA

The main features of NORA are.
• As a guide for EA development, it is written from the government agencies’
perspective
• All stages in the EA lifecycle are described in some detail to provide clarity to
the government agencies
• Balanced approach in EA development that focuses both on processes and the
production of standard artifacts or deliverables
• Examples and example outputs are provided to aid understanding
• Highly customizable to suit the varied requirements of different government
agencies.

6 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

 1.6 Defining A Purpose for Agency EA
Every government agency is expected to have an digital transformation roadmap
that would pave the way for the advancement of delivering government services.
EA is an excellent tool for planning as well as implementing this digital
transformation roadmap.

Government agencies have to find and determine the most important driver or
motivation to develop their very own EA. The following table lists the common
drivers and the corresponding objectives to develop EA. These common scenarios
will influence the use of NORA as a guideline to develop EA for agencies.

Drivers EA Objectives - Values

Comprehensive understanding of agency-wide

Lack of governance and
perspective, including its problems, challenges,
prioritization
investments and opportunities

IT standardization, with detailed information and

Lack of agency-wide
inter-relationships between business and
information
technologies

No duplication of investments and systems;

No integration among
integration of work resulting in efficiency and
departments
better customer service

Duplicated investments Prevent investments and work duplication.

Ineffectiveness and Understand agency weaknesses; integrated ap-

inefficiency in public service proach to improve agency’s productivity and
delivery public service delivery
Implement quality business and service
No standard operations
operations.
Interoperability of systems and processes in the
No technology standards
agency
Investing capital and
Effective investments that align business and IT
procurement costs

7 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

 While government agencies may have different motivations, there are also
common purposes shared among all government agencies. The following are the
top reasons for embarking on the EA journey:
• Implementing digital transformation roadmap
• Optimizing IT investments
• Reducing IT costs
• Aligning IT to government business.

As EA is a wide program with an ongoing or continuous journey, it is possible that

government agencies will require specific purposes, over time, to review and
improve their EAs, such as the following examples:
• Standardization and interoperability of services, IT applications, data, and
infrastructure
• Selection and/or prioritization of projects in the government agency for funding
and implementation
• Building new capabilities such as improving customer service, making business
processes effective, and agency-wide adoption of mobile applications and
devices
• Improve and integrate business-critical government services and business
functions through Business Process Re-Engineering and automation
• Development of IT Resource Management and IT Portfolio Management.

8 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

 1.7 NORA Methodology

NORA methodology is based on a lifecycle consisting of ten major stages. The

execution of the stages is in sequence, however, it can be tailored to suit the
purpose of agency EA. Each stage has its own architectural artifacts or
deliverables. In NORA, a continuous set of governance activities are carried out
throughout the ten stages. Figure 2 below illustrates the NORA Methodology.

10
Execute/ Develop EA
Maintain
Maintenance /
Project 01
09 Maturity
Assessment
Strategy
EA Strategy

Build
Management Develop EA
Plan Project Plan
Usage Management
EA Project Plan
Plan / EA
Management Plan
02
08
Analyze
Develop Current State
Transition Plan NORA Current IT
Build Transition Plan Landscape / SWOT
Analysis

03
07
Build Target Build EA
Architecture Structure
BA, AA, DA, DA EA Framework

Build
Build Current Reference 04
06 Architecture
BA, AA, DA, TA
Models
BRM, ARM, TRM,
DRM, SeRM

Figure 2 NORA Methodology

Continuous Governance (applicable during all stages)

As EA is a massive and long-term project, there are bound to be many challenges
and issues. It is vital, therefore, that the EA governance work is also addressed to
ensure the success of the project. The EA governance is continuous - covering
activities such as program management, change management (including EA
awareness and promotion), capability management (specific training, tools, and
new processes), performance management (new KPIs and standards), and policy
management.

9 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

 Stage 1 – Develop EA Project Strategy
This stage describes the key activities to research, plan, and obtain approval to
embark on the EA project. Each government agency has to obtain its project
funding and either develop its EA internally or outsource.

Stage 2 – Develop EA Project Plan

Having established an approved EA Project Strategy, the government agency has
to carry out a detailed plan for the EA project. This stage describes the key
activities involved in developing and obtaining approval for the EA project.

Stage 3 – Analyze Current State

With the approved EA project plan in place, the government agency can start the
actual work by analyzing its current state – both in terms of business and IT. This
stage describes the key activities in reviewing and analyzing the different aspects
of the current state of the government agency.

Stage 4 – Build EA Structure EA Framework

This is the stage where a government agency starts to develop its EA. In this stage,
the government agency constructs the main pillars such as EA vision & mission,
architecture goals & principles, EA Framework, taxonomy, and other related
standards that are fundamental to its EA journey. The government agency should
focus on building a quality EA framework and other relevant processes.

Stage 5 – Build Reference Models

Based on the EA framework developed previously, this stage is all about building
the reference models so that a government agency can have standard views and
taxonomies of key organizational assets and processes such as business,
application, data, and technology domains.

10 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

 Stage 6 – Build Current Architectures
The focus of this stage is on capturing the current architectures of the government
agency so that the agency can clearly understand its IT and business landscapes.
This would allow better visibility of the interconnections among different
architectures and components and aid in analyzing the agency’s issues, challenges,
and opportunities relating to business, information/ data, and technologies.

Stage 7 – Build Target Architectures

With the completion of the government agency’s current architectures, this stage
develops the target architectures. As a blueprint for the government agency to
realize its goals and desired outcomes in 3 to 5 years, the target architecture
defines the improved business and IT landscapes.

Stage 8 – Develop Transition Plan

With the completion of the various target architectures in the previous stage, it is
now important to plan and manage the transition required from the current
landscapes to the desired target landscapes.

Stage 9 – Develop EA Management Plans

This stage is about developing the EA usage and management plans so that EA
processes and values become an integral part of the agency's standard operating
procedures. To ensure continued EA value delivery to the government agency, it is
necessary and important to incorporate EA management plans into the
government agency.

Stage 10 – Execute & Maintain

This is the last stage, where a government agency executes and maintains its EA.
Having covered many stages in the EA journey, this last stage concerns taking
action to make the government agency’s EA into a reality.

1.8 NORA and NEA Framework

When government agencies develop their EAs according to NORA, not only do
they deliver their own EAs, but they also ensure that all EA development complies
with the overall NEA Framework.

NORA allows government agencies to comply with and align with the national
digital transformation plan and initiatives, it aids government agencies to share
applications and information and to develop highly integrated business functions
and services that delight citizens and businesses.

11 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

2. Stage 1 - Develop EA Project Strategy
2.1 Stage Summary
This stage describes the key activities to research, plan, and obtain approval to
embark on the EA project. Each government agency has to obtain its project
funding and either develop its EA internally or outsource.

2.2 Stage Purpose

Lay the foundation of a government agency’s EA implementation journey with
clear directions and commitments. The following specific expected outcomes
from this stage are:
• Increase the government agency’s EA awareness – from top management to
the operations staff
• Define and communicate EA goals and directions
• Obtain management approval to embark on the EA journey
• Stage Initiation.

2.3 Stage Initiation

DGA will communicate with the e-Transformation Committee in each
government agency to initiate the agency EA implementation. Government
agencies can also request and discuss with DGA to initiate their EA program.

2.4 Key steps in Stage 1

Preparation is an important stage that requires diligent research and planning.
This is the first major step to embark EA in the government agency. The key
activities and expected deliverables in Stage 1 are shown in the table below.

12 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

 No Description Deliverable

1 Develop EA Project Strategy Government Agency’s EA Project Strategy

Analyze EA trends and case studies (both

international and local agencies; also, across Document relevant EA trends and case studies
1.1
the same line of business/business function relating to the government agency
in BRM)
Provide EA awareness to government
agency’s business and IT leaders
1.2 Understand the importance of EA
(Government agencies can invite DGA to
brief on NEA)

Submit and present the assessment report to the

e-Transformation Committee or equivalent. The
assessment shall describe the agency’s:
Assess the government agency’s e-trans
1.3 formation maturity (Via Qiyas) and its 1. Maturity of its e-transformation
alignment of IT to the government business 2. Effectiveness of its business functions
3. Maturity in IT adoption
4. Agency’s capability on business productivity
and use of IT.
Document the government agency’s EA
1.4 Draft Government Agency’s EA Project Strategy
project strategy
Approved Government Agency’s EA Project
Present and obtain approval for the EA
1.5 Strategy by its e-Transformation Committee or
project strategy
equivalent

The EA Project Strategy should focus on strategic and long-term outcomes for the
government agency. In the next step, a more detailed EA Project Plan will be
created. For this step, the EA Project Strategy should cover the following topics:
1. The EA Value Propositions or Purposes
2. Goals or Objectives of the EA Project
3. Scope and Schedule of the EA Project
4. EA Development Considerations and Approach (including phase/gradual
development strategy and sourcing method i.e., In-House or Outsource)
5. Estimated Cost and Resources (Staff) Requirements.

13 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

3. Stage 2 - Develop EA Project Plan
3.1 Stage Summary
Having established an approved EA Project Strategy, the government agency has
to carry out a detailed plan for the EA project. This stage describes the key
activities involved in developing and obtaining approval for the EA project.

3.2 Stage Purpose

The government agency has to structure and form appropriate EA Core team(s)
and develop a detailed EA project plan. The following specific expected outcomes
from this stage are:
• Clarify the roles and responsibilities of management and the various working
teams
• Clarify the governance and management of EA in the government agency
• Obtain management approval and commitment to the goals, schedules, and
resources to develop and implement the EA.

3.3 Stage Initiation

This stage begins with the endorsement or approval of the EA Project Strategy in
Stage 1.

14 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

3.4 Key Steps in Stage 2
Following table summarizes the key steps in stage 2.

No Description Deliverable

2 Develop EA Project Plan Government Agency’s EA Project Plan

Upon approval of the Project Strategy

(Step 1.4), propose and set up the various
Approved EA committees and working teams
EA committees and teams such as EA
2.1 by the e-Transformation Committee or
Governance Committee, EA Working
equivalent
Team, Business-Domain Working Team,
and the IT Working Team.

Finalize the EA development approach,

such as scope, budget, schedule, and
including outsourcing or insourcing of
Approved EA development approach by e-
2.2 the Government Agency’s EA
transformation committee or equivalent
implementation. Also include the
adoption of EA culture into all aspects of
business and IT planning and reviews.

Upon approval of Steps 2.1 & 2.2, the EA

2.3 working team will document the de- Draft EA project plan
tailed EA Project Plan
Present and obtain approval for the EA Approved EA project plan by the EA Gover-
2.4
project plan nance Committee

4. Continuous Governance
4.1 Purpose of Governance
With the approved EA project plan by the EA Governance Committee in the
previous stage, the EA Core and working teams can embark on the detailed EA
work. As EA is a massive and long-term project, there are bound to be many
challenges and issues. It is vital, therefore, that the EA governance work is also
addressed to ensure the success of the project.

The previous stage has defined the roles and responsibilities of the EA
Governance Committee. Hence, the purpose of the EA governance is very clear,
i.e., to steer and direct the EA project to successfully meet the government
agency’s vision, mission, and strategic goals. Recommended that the EA
Governance Committee report to the e-Transformation Committee or one of the
e-Transformation Committee members to chair the EA Governance Committee.

15 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

4.2 Outcome of Governance
The outcomes of the continuous governance are:
1. Up-to-date project reporting on schedules, budget, progress, and challenges
2. Pro-active and timely review of deliverables and artifacts (instead of reactive
management)
3. Top-down transparency in solving challenges and issues across the
government agency
4. Effective management of resources in the government agency.

4.3 Governance Initiation

The government agency’s e-Transformation Committee started the governance
by reviewing and approving the EA Project Strategy in Stage 1. The EA governance
officially started with the formation of the EA Governance Committee in Stage 2.
Note that EA governance is a continuous activity affecting all stages.

4.4 Key Areas in Governance

Key areas in governance are listed below.

No Description Deliverable

All Continuous Governance Success of Government Agency’s EA Project

Track and monitor the key activities and

deliverables of the EA. Highlight to the EA Program management of Government
1
Governance Committee potential delays, Agency’s EA implementation
changes in scope, and lack of resources.

Manage the introduction and changes to

the various activities in the EA. In Change management, especially on awareness
2
particular, carry out activities on EA and promotion of Government Agency’s EA
awareness and promotion.

Manage the capability requirements for

the EA implementation that includes Capability management on the progression on
3 training, changes to job scope, and review the government agency’s capabilities to carry
of division/department organizational out the EA Project plans
structures.
Manage the policies and regulations
required to implement the different Policy management on the policies and
4
factors or activities of the EA in the regulations relating to the EA execution
government agency.

Manage the performance outcomes of the Performance management on the metrics,

5
EA in the government agency KPIs, and outcomes of the EA

16 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

As EA affects the whole of the government agency’s functions, and not merely IT,
it is vital that the EA Governance Committee carry out its governance functions
throughout the EA lifecycle.

The EA governance covers five areas as summarized in Figure 3 - program

management, change management, capability management, policy
management, and performance management. Note that these five management
areas have to be planned and executed together rather than in sequence.
Through program management, which acts as a central management area,
specific projects and tasks can be planned, scheduled, and monitored. Details of
these governance areas are described below.

EA Management / Governance

Change
management

Program
Performance Capability
management
management management

Policy
management

Figure 3 Five Aspects of EA Governance

17 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

4.4.1 Program Management
The EA will be a continuous journey with dynamic changes affecting different
parts of the architectures and reference models. The EA also recommends
initiatives that require time to develop and fully implement.

4.4.2 Change Management

Before EA existed, the government agency had been organizing, planning, and
executing projects (both business and IT) in a typical manual and reactive fashion.
The introduction of EA requires big changes to the government agency, such as
organization review, integrated & strategic planning, and making decisions on
digital transformation projects in a structured and timely way. Thus, change
management is necessary for the success of the EA execution.

4.4.3 Capability Management

Not only does EA require a big organizational change, but it also requires a
commitment of the government agency to continuously improve its capability –
i.e., thought processes in executing work, improving skills & experiences in
architecting, improving business processes & automation, and in integrated
planning & decision-making.

4.4.4 Policy Management

In the development of the EA, the teams would have difficulties identifying things
as a standard or a guideline. While this is normal, the EA execution requires
policies and regulations to ensure government agency-wide standardization and
adoption of the various architectures/reference models.

4.4.5 Performance Management

As a strategic enabler, EA provides the ability to define and measure performance
of the government agency. While this can be incorporated into the Performance
Architecture (which is optional), the execution of EA nonetheless requires
performance metrics to be defined so that management knows whether the EA
project has been a success.

18 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

5. Stage 3 - Analyze Current Stage
5.1 Stage Summary
With the approved EA project plan in place, the EA Core and working teams can
start the actual work by analyzing the current state of the government agency.
This stage describes the key activities in reviewing and analyzing the different
aspects of the current state of the government agency.

5.2 Stage Purpose

The government agency has to carry out requirements study and detailed
analysis of the current state in terms of both business and IT. The following
specific expected outcomes from this stage are:
1. Define the government agency’s EA requirements (mainly from key
stakeholders)
2. Document the government agency’s environment analysis report – both
internal and external analysis
3. Document the government agency’s current strengths, weaknesses,
opportunities, and threats (SWOT).

5.3 Stage Initiation

This stage begins with the endorsement or approval of the EA Project Plan from
Stage 2.

19 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

5.4 Key Steps in Stage 3
This stage kicks off with documenting the government agency’s EA requirements
and the current business and IT landscapes (through environment analysis). This
document will help to steer the EA journey in the following stages. The key steps
in Stage 3 are listed in Table below.

No Description Deliverable

a. EA Requirements
b. EA Environment Analysis Reports (Current
3 Analyze Current Stage
Business Landscape and Current IT Landscape)
c. SWOT Analysis Report

Gather and document EA requirements

from various stakeholders such as the e-
Transformation Committee, EA Government Agency’s EA requirements are
3.1
Governance Committee, main business viewed by the EA Governance Committee.
functions’ stakeholders, and EA working
teams.
Gather and analyze Government Agen-
cy’s internal environment, such as orga- Government Agency’s EA environment
3.2 nizational capability to plan and execute analysis report reviewed by the EA
e-transformation plan, business plan, Governance Committee.
and IT plan.

Gather and analyze Government Agen-

cy’s external environment, such as gen-
Government Agency’s EA environment
eral trends in EA, United Nations, or
3.3 analysis report was reviewed by the EA
similar e-government rankings, including
Governance Committee.
recommendations, prioritized national
projects, and new government policies.

EA Governance Committee is informed about

Present to the EA Governance
3.4 the detailed current state of the government
Committee
agency.

20 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

6. Stage 4 - Develop EA Framework
6.1 Stage Summary
This is the stage where a government agency starts to develop its EA. In this stage,
the government agency constructs the main pillars such as EA vision & mission,
architecture goals & principles, EA Framework, taxonomy, and other related
standards that are fundamental to its EA journey. The government agency should
focus on building a quality EA framework and other relevant processes.

6.2 Stage Purpose

The previous stage gave the EA requirements and environment analysis reports
so that the EA Core team knows what the government agency’s EA has to address.
The purpose of stage 4 is to architect important EA fundamentals that will steer
and guide the EA development in subsequent stages. The following specific
expected outcomes from this stage are:
1. Define the government agency’s EA vision, mission, architecture goals, and
architecture principles.
2. Define EA documentation standard.
3. Define the EA artifact review and approval process.
4. Create the government agency’s EA Framework.

6.3 Stage Initiation

This stage begins with the completed EA requirements, environment analysis
reports (both current business and current IT landscapes), and the SWOT analysis
report from Stage 3. Note that the EA Governance Committee may also provide
additional strategic requirements at the end of Stage 3.

21 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

6.4 Key Steps in Stage 4
Stage 4 focuses on high-level architecture activities that require experience and
vision. The key steps in Stage 4 are listed in the Table below.

No Description Deliverable

Government Agency’s EA Mission, Vision,

Architecture Objectives, and Architecture
4 Develop EA Framework Principle Statements
Government Agency’s EA Framework
Define EA’s vision and mission state- Draft EA Vision, Mission, and architecture
4.1
ments, & architecture objectives objectives
4.2 Define EA’s architecture principles Draft EA Principles
Present and obtain approval for EA's vi- Approved EA Vision, Mission, Architecture
4.3
sion, mission, and architecture objectives Objectives, and Architecture Principles
4.4 Define EA Framework structure Draft EA Framework Structure
4.5 Design EA architecture elements Draft EA Architecture Elements
4.6 Design EA model Draft EA Model
4.7 Develop EA documentation standard EA documentation standard
Develop EA artifacts management pro-
4.8 Draft EA Artifact management processes
cesses
Present and obtain approval for the EA
4.9 Approved EA Framework
framework

7. Stage 5 - Build Reference Models

7.1 Stage Summary
The previous section has defined and described the reference models and
architectures. Based on the EA framework developed previously, this stage is all
about building the reference models so that a government agency can have
standard views and taxonomies of key organizational assets and processes such
as business, application, data, and technology domains.

22 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

7.2 Stage Purpose
The purpose of stage 5 is to architect and build the relevant EA reference models
of the government agency. The following specific expected outcomes from this
stage are:
1. Performance Reference Model
2. Business Reference Model
3. Application Reference Model
4. Data Reference Model
5. Technology Reference Model.
Note that the above are recommended outcomes. A government agency can
have more or less, or even combine, reference models depending on its EA
requirements, its EA framework design, and its EA goals. Other examples of
reference models are security reference model, service reference model, and
infrastructure reference model.

7.3 Stage Initiation

This stage requires the EA vision, mission, architecture goals & principles, and the
EA framework from the previous stage. In addition, the government agency needs
to refer to DGA’s NEA Reference Models. By referring to the NEA reference
models, the government agency can develop its own reference models, ensuring
alignment with the whole of the government as well as achieving its EA goals.

7.4 About NEA References Models

Since government agencies have to refer to NEA reference models, it is a
prerequisite to understand all five reference models and their inter-relationships.
The objectives or goals of the NEA reference models are:
1. To provide whole-of-government structured information on IT and business
landscapes
2. To provide effective views or perspectives for different stakeholders in the
government – from business to applications to data to IT infrastructure
3. To provide a reference point for government agencies to review and distill
relevant information and design for their own use.

23 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

Figure 4 illustrates the NEA reference models and their inter-relationships.

PRM sets the performance standards

ARM Supports
Business
Performance reference model

Business
Reference Model

Application
BRM
Reference Model

DRM Supplies
Data

TRM Supports
Applications
Drives
The
Data
agency Reference Model

Technical
Reference Model

Figure 4 NEA reference models and their inter-relationships

a. Performance Reference Model

The Performance Reference Model (PRM) is an outcome-focused measurement
framework that can assist government agencies in the design and
implementation of effective business measurement systems and performance
architectures. The PRM, through the measurement indicators, sets the
performance standards for the government. Hence, from an architectural
viewpoint, the PRM sets the performance standards for the other four reference
models.

b. Business Reference Model

The Business Reference Model (BRM) is a classification category used to describe
the type of business functions for the whole Saudi government. It gives a logical
functional view instead of functions by physical government agencies. The
functions and requirements in BRM drive the other reference models, i.e., the
Application Reference Model, Data Reference Model, and Technology Reference
Model.

24 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

c. Application Reference Model
The Application Reference Model (ARM) is a categorization of different types of
application systems, application components, and interfaces. It is the framework
for categorizing national shared IT systems and application components to help
identify opportunities for sharing, reuse, and consolidation or renegotiation of
software licenses. The ARM supports directly the BRM in delivering business
outcomes.

d. Data Reference Model

The DRM (Data Reference Model) is a model that classifies data and defines a
standard data structure to support developing data architecture and promoting
data standardization/reuse/ management. The DRM supports the ARM directly in
delivering business goals by supplying data and information. The various
application systems have to use data to provide information to businesses.

e. Technology Reference Model

The Technology Reference Model (TRM) classifies and defines technologies and
technology standards/specifications that support businesses and services. Under
structured technology classifications, technology standards are defined to
promote interoperability among government agencies. The TRM supports the
data usage in DRM, supports application systems in ARM through the technology
definitions and infrastructure implementations, and supports the agency staff
through the use of personal and office technologies.

Please refer to the actual NEA reference models for details.

25 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

7.4 Key Steps in Stage 5
Stage 5 is all about building the relevant reference models. The table below lists
all the key steps in Stage 5.

No Description Deliverable

Document Government Agency’s

5 Government Agency’s Reference Models
Reference Models

Develop a model that standardizes

performance elements for improving IT
5.1 Approved Performance Reference Model
projects and their quality. Obtain approval
from the EA Governance Committee.

Develop a model that classifies and

defines business functions and related
5.2 Approved Business Reference Model
information. Obtain approval from the EA
Governance Committee.
Develop a model that classifies and
defines shared application
systems/components to promote service
5.3 integration and reuse by identifying Approved Application Reference Model
redundant or correlated applications.
Obtain approval from the EA Governance
Committee.
Develop a model that classifies data and
defines standard data structures to
support data architecture development,
5.4 Approved Data Reference Model
data standard, and data reuse. Obtain
approval from the EA Governance
Committee.
Develop a model that classifies and
defines technologies and technology
5.5 standards/ specifications supporting Approved Technology Reference Model
business and services. Obtain approval
from the EA Governance Committee.

In building the various agency’s reference models, the EA Core and working
teams have to make reference to its EA Framework (developed in Stage 4) and
NEA Reference Models.

26 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

8. Stage 6 - Build Current Architecture
8.1 Stage Summary
Once the framework and reference models are established and agreed upon, the
government agency embarks on one of the most critical steps in its EA journey.
The focus of this stage is on capturing the current architectures of the
government agency so that the agency can clearly understand its IT and business
landscapes. This would allow better visibility of the interconnections among
different architectures and components and aid in analyzing the agency’s issues,
challenges, and opportunities relating to business, information/data, and
technologies. The information captured and architectures created in this stage
include Business Architecture, Application Architecture, Data Architecture, and
Technology Architecture. The government agency may build all the current
architectures or select relevant architectures depending on its EA scope and
development strategy.

8.2 Stage Purpose

The purpose of this stage is to analyze and document the status of the current
government agency’s IT and business landscapes. The expected outcomes or
deliverables of this stage are:
1. Current Business Architecture
2. Current Application Architecture
3. Current Data Architecture
4. Current Technology Architecture.
Note that the above are recommended outcomes. A government agency can
have more or less architectures depending on its EA scope, goals, EA framework
design, and development strategy. Other examples not listed above include
current security and performance architectures.

27 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

8.3 Stage Initiation
With the completion of the previous phases, the EA Core Team and working
teams have to ensure that the following deliverables are in place:
1. Performance Reference Model
2. Business Reference Model
3. Application Reference Model
4. Data Reference Model
5. Technology Reference Model.
Again, depending on the EA scope and development strategy, the government
agency has to ensure that the corresponding reference models are completed. If
the government agency intends to build all architectures, then it needs the five
above reference models. However, if the government agency is doing a specific
EA scope, such as data and technology consolidation, then it needs to have at
least the data and technology reference models in place.

8.4 Key Steps in Stage 6

Table below lists the key activities and expected deliverables for stage 6.

No Description Deliverable
Build Government Agency’s Current Government Agency’s Relevant Current
6
Architectures Architectures
6.1 Capture current business and IT data Government Agency’s Current Data
Analyze and build the business
architecture
that describes the current business
Government Agency’s Current Business
6.2 functions, sub-business functions,
Architecture
business
processes, business activities, and
business services
Analyze and build the application
architecture that lists all the current
applications (fully automated, partially
Government Agency’s Current Application
6.3 automated & manual), and the
Architecture
relationships between these applications
and the business
functions/processes/services
Analyze and build the data architecture
that shows all the current data used by
Government Agency’s Current Data
6.4 the government agency, the usage of
Architecture
data by applications, including data ex-
change within and externally
Analyze and build the technology
architecture that illustrates the current IT Government Agency’s Current Technology
6.5
infrastructure used by the various Architecture
applications, data, and people
6.6 Current Architecture Analysis Summary of Improvement Opportunities

28 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

8.4.1 Step 6.1 Capture current Business and IT Data
The first important step is to capture both the current business and IT data in the
government agency. Current data is required to understand the actual reality of
the agency’s business and IT landscapes. Data has to be up-to-date, accurate, and
verified. It is always better to have more detailed data than insufficient data.

Depending on the agency’s actual EA scope and objectives, the EA Core and
working teams have to prepare the relevant means to capture the required data.
If the agency is doing the entire EA, then it has to capture information about the
business, applications, data/databases, and infrastructure. On the other hand, if
the agency is doing only technology architecture, then it has to capture the
current IT technologies and infrastructure data.

However, the teams may face difficulty in obtaining the support of the various
parties or divisions to capture the current data. As part of change management
(please see Continuous Governance – Change Management section), it is
recommended to provide clear communications to the relevant departments,
divisions or branches in the agency on the need for EA and the data capturing
exercise.

The following are the recommended activities to capture current data in the
agency:

S/No Activity

1 Identify data elements and data sources required

2 Design data capturing method(s)

3 Design data-capturing templates.

4 Present to EA Governance Committee on data capturing approach

5 Brief the relevant parties.

6 Capture the relevant current data.

7 Verify and update

29 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

8.4.2 Step 6.2 Analyze and build current business architecture
On completion, the current BA will depict the current business landscape of the
government agency. Since the BA is an expansion of the agency BRM, the
following are the artifacts or deliverables. Note that there are three additional
artifacts or deliverables. Collectively, they will provide a comprehensive
description of the current BA.

No Artifact / Deliverable Description

1 Purpose / Direction The purpose of BA
2 BA Principles The architectural principles of BA
3 Business Areas (BRM) The main business areas for the agency

The main LoBs (Lines of Business) for the agency within the
4 Lines of Business (BRM)
business areas

Business Functions
5 The key business function descriptions within LoBs
(BRM)

Sub-Business Functions The sub-business function descriptions within each business

6
(BRM) function

The list of business process descriptions within each sub-

7 Business Processes
business function

8 Organization Chart The current organization chart for the agency

9 Service Catalogue The current list of business services

Building the Agency BA

Below table summarizes the main activities for building the agency BA.

No Activity Artifact / Deliverable

Define the BA purpose or
1 BA purpose/direction statement
direction
2 Define the BA principles BA principles

Document the organization

3 Organization chart
information

Define the business Reviewed/updated business areas, LoBs, and business

4
functions (BRM) functions and created sub-business functions

Define the business

5 List of business processes for the agency
processes
Document the service cata-
6 Service catalogue
logue
7 Document and review Reviewed draft of current BA
Obtain governance
8 Approved agency current BA
approval

30 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

The figure below shows the relationships among BA artifacts and the
relationships with artifacts from other architectures.

BA related artifacts

Other architecture
related artifacts
BRM
References model

Data flow diagram Business function Application catalogue

Organization chart
Database portfolio

Infrastructure Business process

description

HW, SW catalogue
Service catalogue

Figure 5 BA artifacts’ relationship diagram

8.4.3 Step 6.3 Analyze and build the current application architecture
Below table summarizes the agency BA relationships with other current
architectures.

Other Current Architectures AA Relationship

AA provides application systems to the various business

BA
functions in the government agency.

AA requires data models and data elements to be used for

DA
decision-making and efficient operations.

AA provides the requirements for technologies to support the

TA
hosting and usage of application systems.

31 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

Description of the Agency AA
On completion, the current AA will depict the current application landscape of
the government agency. Since the AA is an expansion of the agency ARM, it
provides a catalogue of current applications. The application catalogue and three
other additional artifacts or deliverables provide a comprehensive description of
the current AA.

No Artifact / Deliverable Description

1 Purpose / Direction The purpose of AA

2 AA Principles The architectural principles of AA
3 Application Systems (ARM) The main application systems for the agency

Application Components
4 The key application components for the agency
(ARM)

Application Interfaces
5 The main application interfaces for the agency
(ARM)

6 Application Catalogue The list of applications and their attributes

7 Application Functions The description of the application functions
8 Application Relationships The description of the application relationships
9 Application Overview The overview description of the application systems

Building the Agency AA

Below table summarizes the main activities for building the agency AA..

No Activity Artifact / Deliverable

Define the AA purpose or
1 AA purpose/direction statement
direction
2 Define the AA principles AA principles
Review application
systems, application
Reviewed/updated application systems, application
3 components, and
components, and application interfaces
application interfaces
(ARM)
Document the application
4 Application overview
overview
Document the application
5 Application catalogue
catalogue
Document the application
6 Application functions
functions
Document the application
7 Application relationships
relationships
8 Document and review Reviewed draft of current AA
Obtain governance
9 Approved agency current AA
approval

32 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

The figure below shows the relationships among AA artifacts and the
relationships with artifacts from other architectures.

AA related artifacts
Organization chart
Other architecture
related artifacts

ARM References model

Business function

Application catalogue Application overview

Application function
HW, SW catalogue

Application Conceptual data

Data dictionary relationship model

Figure 6 AA artifacts’ relationship diagram

8.4.4 Step 6.4 Analyze and build current data architecture

On completion, the current DA will depict the current data landscape of the
government agency. Since the DA is an expansion of the agency DRM, it provides
a catalogue of data and the data models currently in use. There will be five
additional artifacts in the DA. Together, they give a comprehensive description of
the current data usage in the government agency.

No Artifact / Deliverable Description

1 Purpose / Direction The purpose of DA

2 DA Principles The architectural principles of DA
3 Data Model (DRM) The main data model for the agency
4 Data Classifications (DRM) The key data classifications
5 Data Structure (DRM) The main data structures for the agency
6 Data Exchange (DRM) The list of data exchanges for the agency

The pictorial high-level description of the data model for

7 Conceptual Data Model
the agency

8 Logical Data Model The logical data models of the agency

The various pictorial representations of data flows for the

9 Data Flow Diagrams
agency

10 Database Portfolio Catalogue The consolidation of all databases in the agency

11 Data Dictionary The definitions for common data in the agency

33 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

Building the Agency DA
Table below summarizes the main activities for building the agency DA.

No Activity Artifact / Deliverable

Define the DA purpose or

1 DA purpose/direction statement
direction
2 Define the DA principles DA principles
Review data model, data
Reviewed/updated data model, data classifications
3 classifications, and data
and data structures
structures (DRM)

Create the conceptual data

4 Conceptual data model
model
5 Create the logical data model Logical data model
Document the data flow
6 Data flow diagrams
diagrams
Compile the database
7 Database portfolio catalogue
portfolio catalogue
8 Document the data dictionary Data dictionary
9 Document and review Reviewed draft of current DA
10 Obtain governance approval Approved agency current DA

Below table summarizes the agency DA relationships with other current

architectures.

Other Current Architectures DA Relationship

DA provides information on agency-wide data and sources of

BA data from external parties; this aids decisions on data sharing
and reuse

DA provides data models, database information, and data

AA elements
to be used by application systems

DA provides the requirements for technologies to support the

TA
hosting and usage of database systems and data exchanges

34 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

The figure below shows the relationships among DA artifacts and the
relationships with artifacts from other architectures.

DA related artifacts

Business function
Other architecture
related artifacts

Reference model
Business process DRM

Data flow Conceptual data Application

diagram model relationship

Logical data
model

Application
Data dictionary catalogue

Organization Database HW, SW

chart portfolio catalogue

Figure 7 DA artifacts’ relationship diagram

8.4.5 Step 6.5 Analyze and build current technology architecture

As the EA Core and working teams have already developed other current
architectures, it is important to understand their inter-relationships as
summarized in the below table.

Other Current Architectures TA Relationship

TA provides the client and office technologies such as PCs,

BA mobile devices, printers, and scanners to the agency
employees in different branches and divisions

TA provides the infrastructure technologies to host and

AA
support application systems and components.

TA provides the infrastructure technologies to enable data

DA
transactions and exchanges.

35 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

On completion, the current TA will depict the current technology landscape of the
government agency. Since the TA is an expansion of the agency TRM, the
following are the artifacts or deliverables. Note that there are four additional
artifacts or deliverables. Collectively, they will provide a comprehensive
description of the current TA.

No Artifact / Deliverable Description

1 Purpose / Direction The purpose of TA

2 TRM Principles The architectural principles of TA
3 Service Area (TRM) The highest-level technology service area
4 Service Category (TRM) The technology service category within a service area
5 Service Standard (TRM) The list of technology service standards in use
The high-level representation of the IT landscape in the
6 Infrastructure Overview
government agency (normally in diagrammatic form)
The descriptions of the main infrastructure technologies
7 Infrastructure Description
in use
8 Hardware Catalogue The current list of hardware
9 Software Catalogue The current list of software

Below table summarizes the main activities for building the agency TA.

No Activity Artifact / Deliverable

Define the TA purpose or

1 TA purpose/direction statement
direction
2 Define the TA principles TA principles
Review the service areas and Reviewed service categories within service areas for the
3
service categories (TRM) agency
Review the service standards Reviewed service standards within each service
4
(TRM) category relevant to agency
5 Analyze the data collected Nil
Describe the infrastructure
6 High-level representation of the IT landscape in agency
overview
Provide the infrastructure
7 List of infrastructure technology descriptions in use
descriptions
Develop the hardware
8 List of hardware in use
catalogue
Develop the software
9 List of software in use
catalogue
10 Document and review Reviewed draft of current TA
11 Obtain governance approval Approved agency current TA

36 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

The figure below shows the relationships between TA artifacts and the
relationships with artifacts from other architectures.

TA related artifacts

Other architecture
TRM related artifacts

References model

Infrastructure
overview

Infrastructure
Organization chart
description

HW, SW catalogue

Database portfolio Application catalogue

Figure 8 Relationship TA artifacts

8.4.6 Step 6.6 Current architecture analysis

It is a major accomplishment milestone on the completion of capturing the
current architectures. With the information and pictorial representations, the EA
Core and working teams can have different perspectives about the government
agency on the business, applications, data, and infrastructure. These current
architectures also allow the discovery of not-so-obvious linkages, dependencies,
and even synergies or integrated components. On the other hand, it is a milestone
unlike any; this is because it performs many important aspects, including but not
limited to the following. The advantage of viewing the whole enterprise cutting
across silos, establishing the obvious and not-so-obvious linkages and
dependencies, capturing synergies etc., facilitates the identification of
opportunities for the progress of the agency as well as the issues that are
hindering its future growth.

The current architecture analysis is an activity to understand current issues and

challenges of the government agency on the one hand and to explore ideas for
improvement and integration on the other hand.

37 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

The following describes important activities for this step.

No Activity Artifact / Deliverable

1 Analyze BA BA improvement opportunities

2 Analyze AA AA improvement opportunities

3 Analyze DA DA improvement opportunities

4 Analyze TA TA improvement opportunities

Reviewed draft summary of improvement

5 Document and review
opportunities

6 Obtain governance approval Approved agency summary of improvements

1. Analyze BA
Review the current BA.
A recommended method is to compare the BA artifacts against the agency’s
mission and vision statements, strategic goals/objectives, the agency annual
plans, digital transformation Plan, and the agency PRM .The EA Core and working
teams can also use analysis tools such as Value Chain analysis, 7S analysis, SWOT
analysis, and business process simulation. Carry out the following activities:

a. List the main issues and challenges faced in BA

b. Analyze the business functions and services by logical and physical dimensions
c. List the prioritized strategic business outcomes
d. List the key business work activities or functions and how they have to improve
based on (a) and (c)
e. Using the BA principles as a guide, define specific improvement opportunities
for the list in (d).

38 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

2. Analyze AA
Review the current AA.
A recommended method is to compare the AA artifacts against the strategic
goals/objectives, the agency annual plans, digital transformation Plan, the agency
PRM, and the prioritized application list (from agency ARM). The EA Core and
working teams can also use SWOT analysis. Carry out the following activities:
a. List the main issues and challenges faced by AA
b. Identify some of the global trends in application systems
c. Analyze the application systems by categories and departments/branches;
also analyze the required application systems to support the BA improvement
opportunities
d. List the prioritized application systems, components, and interfaces for
development, replacement, amendment, and retirement
e. Using the AA principles as a guide, define specific improvement opportunities
for the list in (d).

3. Analyze DA
Review the current DA.
A recommended method is to compare the DA artifacts against the agency
annual plans, digital transformation Plan, and the agency PRM. The EA Core and
working teams can also use analysis tools such as data dependency and SWOT
analysis. Carry out the following activities:
a. List the main issues and challenges faced in DA
b. Identify some of the global trends in data management and data usage
c. Analyze the data represented by logical and physical dimensions; also analyze
the required data to support the AA improvement opportunities
d. List the prioritized strategic data models, data elements, and databases
e. Using the DA principles as a guide, define specific improvement opportunities
for the list in (d).

39 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

4. Analyze TA
Review the current TA.
A recommended method is to compare the TA artifacts against the agency annual
plans, digital transformation Plan, and the agency PRM. The EA Core and working
teams can also use analysis tools such as data dependency and SWOT analysis.
Carry out the following activities:
a. List the main issues and challenges faced in DA
b. Identify some of the global technology trends and technology standards
c. Analyze the infrastructure and other technologies; also analyze the required
technologies required to support the BA, AA, and DA improvement
opportunities
d. List the prioritized strategic technologies for development; also include
technologies that require to be replaced or retired
e. Using the TA principles as a guide, define specific improvement opportunities
for the list in (d).

5. Document and review

After completing all the analysis, consolidate all the improvement areas and
document them into a structured information base on the agency’s
documentation standards. Perform a cross-domain analysis (BA, AA, DA, TA), to
identify and document more opportunities for improvement. Do an internal
review and updates. It is also advisable to get other parties – business owners,
application developers, DBAs and data owners, and the infrastructure team - to
carry out a final review.

6. Obtain governance approval

With the completion of the deliverables with the other above related contents,
present to the EA Governance Committee. The Chief Architect should front this
presentation. From the comments from the committee, make the necessary
changes to obtain their final approval.

40 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

9. Stage 7 - Build Target Architecture
9.1 Stage Summary
With the completion of the government agency’s current architectures, this stage
develops the target architectures. As a blueprint for the government agency to
realize its goals and desired outcomes in 3 to 5 years, the target architecture
defines the improved business and IT landscapes. The detailed analysis will lead
to the development of target architectures that include Business Architecture,
Application Architecture, Data Architecture, and Technology Architecture. The
government agency may build all the target architectures or select relevant
architectures depending on its EA scope and development strategy.

9.2 Stage Purpose

The purpose of this stage is to analyze, design, and document the target
government agency’s IT and business landscapes. The expected outcomes or
deliverables of this stage are:
1. Target Business Architecture
2. Target Application Architecture
3. Target Data Architecture
4. Target Technology Architecture.
Note that the above are recommended outcomes. A government agency can
have more or less architectures depending on its EA scope, goals, EA framework
design, and development strategy. Other examples not listed above include target
security and performance architectures.

9.3 Stage Initiation

With the completion of the previous stages, the EA Core Team and working teams
have to ensure that the following deliverables are in place:
1. Summary of Improvement Opportunities
2. Current Business Architecture
3. Current Application Architecture
4. Current Data Architecture
5. Current Technology Architecture.
As mentioned above, depending on the EA scope and development strategy, the
government agency has to ensure that the corresponding current architectures
are completed. If the government agency intends to build all architectures, then it
needs the five above current architectures. However, if the government agency is
doing a specific EA scope, such as data and technology consolidation, then it
needs to have at least the data and technology architectures in place.

41 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

9.4 Key Steps in Stage 7
Below table lists the key activities and expected deliverables for stage 7.

No Description Deliverable
Build Government Agency’s Target
7
Architectures
Define directions for developing target
architecture by analyzing environmental
7.1 Target Architecture direction
factors such as agency’s vision/principles,
current architectures etc.
Analyze and build the target business
architecture based on architecture
Government Agency’s target Business
7.2 principles, current business architecture’s
Architecture
analysis results, and current business
architecture deliverables.
Analyze and build the target application
architecture based on architecture
Government Agency’s target Application
7.3 principles, current application
Architecture
architecture’s analysis result, and current
application architecture deliverables.
Analyze and build the target data
architecture based on architecture
7.4 principles, current data architecture’s Government Agency’s target Data Architecture
analysis results, and current data
architecture deliverables.
Analyze and build the target technology
architecture based on architecture
Government Agency’s target Technology
7.5 principles, current technology
Architecture
architecture’s analysis result, and current
technology architecture deliverables.

9.4.1 Step 7.1 Define directions for developing target architecture

In the previous stage, the team built or documented the current architecture and
analyzed current architecture issues. One of the outputs from the previous stage
is the Summary of Improvement Opportunities. The EA Core and working teams
have also previously analyzed agency’s vision/purposes & other environmental
factors, and then, based on them, we can define target architecture’s directions.
The table below lists the activities in defining directions for target architecture.
No Activity Artifact / Deliverable
Review agency EA vision and
1 Reviewed agency EA vision and principles
principles
Review environment and
2 Nil
requirements analysis
Review current improvement
3 Nil
opportunities
Summarize target architecture
4 Target architecture directions
directions
5 Document and review Reviewed draft target architecture directions
6 Obtain governance approval Approved target architecture directions

42 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

9.4.2 Step 7.2 Build target business architecture
Description about the agency target BA
On completion, the target BA will depict the future business landscape of the
government agency. Since the target BA is the future version of the current BA,
both have the same artifacts or deliverables. The main difference is that the target
BA describes the future scenarios – i.e., providing solutions to the current issues
and challenges.

No Artifact / Deliverable Description

1 Purpose / Direction The purpose of BA
2 BA Principles The architectural principles of BA
3 Business Areas (BRM) The main business areas for the agency
4 Lines of Business (BRM) The main LoBs for the agency within the business areas
5 Business Functions (BRM) The key business function descriptions within LoBs
Sub-Business Functions The sub-business function descriptions within each
6
(BRM) business function

The target list of business process descriptions within

7 Business Processes each sub-business function highlights new, improved,
and deleted processes.

8 Organization Chart The target organization chart for the agency

The target list of business services; highlight new,
9 Service Catalogue
improved or deleted services

43 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

Building the agency target BA
Table below summarizes the main activities for building the agency target BA.

No Activity Artifact / Deliverable

Review the BA purpose or
1 Reviewed/updated BA purpose or direction statement
direction and BA principles
2 Review the BA principles Reviewed/updated BA principles
Define the target business
Reviewed/updated business areas, LoBs, business functions,
3 functions
and sub-business functions
(BRM)
Define the target business
4 List of target improved business processes for the agency
processes
Define the target service
5 Target service catalogue
catalogue
Document the target
6 Target organization chart
organization information
7 Document and review Reviewed draft target BA
8 Obtain governance approval Approved agency target BA

9.4.3 Step 7.3 Build target application architecture

Description of the agency target AA
On completion, the target AA will depict the future application landscape of the
government agency. Since the target AA is the future version of the current AA,
both have the same artifacts or deliverables. The main difference is that the target
AA describes the future scenarios – i.e., providing solutions to the current issues
and challenges, such as new application systems.

No Artifact / Deliverable Description

1 Purpose / Direction The purpose of AA

2 AA Principles The architectural principles of AA

3 Application Systems (ARM) The main target application systems for the agency

4 Application Components (ARM) The key target application components for the agency

5 Application Interfaces (ARM) The main target application interfaces for the agency

6 Application Catalogue The target list of applications and their attributes

7 Application Functions The target description of the application functions

8 Application Relationships The target description of the application relationships

9 Application Overview The target overview description of the application systems

44 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

Building the agency target AA
Below table summarizes the main activities for building the agency target AA.

No Activity Artifact / Deliverable

Define the AA purpose or
1 Reviewed/updated AA purpose or direction statement
direction
2 Review the AA principles Reviewed/updated AA principles
Define the target
application systems,
Target application systems, application components,
3 application components,
and application interfaces
and application interfaces
(ARM)
Document the target
4 application Target application overview
overview
Document the target
5 application Target application catalogue
catalogue
Document the target
Target application functions and application
6 application
relationships
functions and relationships
7 Document and review Reviewed draft target AA
Obtain governance
8 Approved agency target AA
approval

9.4.4 Step 7.4 Build target data architecture

Description of the agency target DA
On completion, the target DA will depict the future data landscape of the
government agency. Since the target DA is the future version of the current DA,
both have the same artifacts or deliverables. The main difference is that the target
DA describes the future scenarios – i.e., providing solutions to the current issues
and challenges in terms of data usage and data exchange.

45 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

 No Artifact / Deliverable Description
1 Purpose / Direction The purpose of DA
2 DA Principles The architectural principles of DA
3 Data Model The main target data model for the agency
4 Data Classifications (DRM) The key target data classifications
5 Data Structure (DRM) The main target data structures for the agency
6 Data Exchange (DRM) The list of target data exchanges for the agency
The target pictorial high-level description of the data
7 Conceptual Data Model
model for the agency
8 Logical Data Model The target logical data models of the agency
The various target pictorial representations of data flows
9 Data Flow Diagrams
for the agency
Database Portfolio
10 The target consolidation of all databases in the agency
Catalogue
11 Data Dictionary The target definitions for common data in the agency

Building the agency target DA

Below table summarizes the main activities for building the agency target DA.

No Activity Artifact / Deliverable

Define the DA purpose or
1 Reviewed/updated DA purpose or direction statement
direction
2 Review the DA principles Reviewed/updated DA principles
Update data model, data
classifications, data Updated target data model, data classifications, data
3
structures, and data structures, and data exchanges
exchanges (DRM)
Document the target
Target conceptual data model and target logical data
4 conceptual and logical data
model
models
Document the target data
5 Target data flow diagrams
flow diagrams
Compile the target database
6 Target database portfolio catalogue
portfolio catalogue
Document the target data
7 Target Data dictionary
dictionary
8 Document and review Reviewed draft target DA
9 Obtain governance approval Approved agency target DA

46 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

9.4.5 Step 7.5 Build target technology architecture
Description about the agency target TA
On completion, the target TA will depict the future infrastructure landscape of the
government agency. Since the target TA is the future version of the current TA,
both have the same artifacts or deliverables. The main difference is that the target
TA describes the future scenarios – i.e., providing technology solutions to the
current issues and challenges.

No Artifact / Deliverable Description

1 Purpose / Direction The purpose of TA
2 TRM Principles The architectural principles of TA
3 Service Area (TRM) The highest-level technology service area
4 Service Category (TRM) The technology service category within a service area
5 Service Standard (TRM) The target list of technology service standards
The target high-level representation of the IT landscape
6 Infrastructure Overview in the government agency (normally in diagrammatic
form)
The target descriptions of the main infrastructure
7 Infrastructure Description
technologies for the future
The list of hardware (no change; only when actual
8 Hardware Catalogue The
implementation)
The list of software (no change; only when actual
9 Software Catalogue
implementation)

47 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

Building the agency target TA
Below table summarizes the main activities for building the agency target TA.

No Activity Artifact / Deliverable

Define the TA purpose or
1 Reviewed/updated TA purpose or direction statement
direction
2 Review the TA principles Reviewed/updated TA principles

Review the service areas and Reviewed service categories within service areas for the
3
service categories (TRM) agency

Define the target service Target service standards within each service category
4
standards relevant to agency
Describe the target
High-level representation of the target IT landscape in
5 infrastructure
agency
overview
Update the target
Target infrastructure technology descriptions and
6 infrastructure
diagrams
descriptions
7 Document and review Reviewed draft target TA
8 Obtain governance approval Approved agency target TA

10. Stage 8 – Develop Transition Plan

10.1 Stage Summary
With the completion of the various target architectures in the previous stage, it is
now important to plan and manage the transition required from the current
landscapes to the desired target landscapes. There is a big gap between current
and target architectures. If these are not managed through the transition plan, it is
typical that the target architecture will not be realized.

The transition plan is about defining and prioritizing intermediate activities,

systems, and projects in order to implement the future state of the target
architectures. The major focus of this stage is to develop a detailed transition plan
consisting of projects or activities, required resources, timeline, and budget.
Techniques such as ABC Analysis, Priority Analysis, ROI Analysis can be utilized in
this stage.

48 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

10.2 Stage Purpose
The purpose of this stage is to manage the transition between the current state to
the target state. The expected outcomes or deliverables of this stage are:
1. Transition Plan.

10.3 Stage Initiation

With the completion of the previous stage, the EA Core and working teams have
to ensure that the following deliverables are in place:
1. Target Business Architecture
2. Target Application Architecture
3. Target Data Architecture
4. Target Technology Architecture.

Depending on the EA scope and development strategy, the government agency

has to ensure that the corresponding target architectures are completed. If the
government agency intends to build all architectures, then it needs the four
above target architectures. However, if the government agency is doing a specific
EA scope, such as data and technology consolidation, then it needs to have at
least the target data and technology architectures in place.

10.4 Key Steps in Stage 8

Below table lists the key activities and expected deliverables for stage 7.

No Description Deliverable

8 Develop Transition Plan Transition Plan

8.1 Define transition projects Transition project list

8.2 Prioritize transition projects Prioritized transition project list

8.3 Create transition roadmap Transition roadmap

Analyze and document the

8.4 required Transition resource plan
resources and outcomes

Obtaining governance
8.5 Approved transition roadmap and resource plan
approval

49 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

10.4.1 Step 8.1 Define transition projects
This activity is about defining and prioritizing transition projects.

No Activity Description

Improvement ideas are defined by classifying them into

Define Ideas for
1 business/application sectors or with agency’s core
Improvement
business functions.

Transition projects are defined by listing up ideas for

improvement, a target architecture, and each architecture
area.
2 Define Transition Projects List transition projects from the current and target
architecture gap analysis and complete the project list by
adjusting and organizing them while considering priority,
sequence, etc.

Target Architecture Transition Plan

Transition Project 1
Gap with
Business
current Select and list transition
Architecture Transition Project 2 projects from the
Businesses
GAP current/target
Analysis
Transition Project 3 architecture gap
Application/Da
Gap with analysis, and complete
current the project list by
ta Architecture
Businesses
adjusting and organizing
them while considering
Gap with priority, sequence, etc.
Technical
current
Architecture
technologies Transition Project n

Figure 9 Example selection method for the transition plan

50 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

11. Stage 9 – Develop Management Plan
11.1 Stage Summary
This stage is about developing the EA usage and management plans so that EA
processes and values become an integral part of the agency's standard operating
procedures. To ensure continued EA value delivery to the government agency, it
is necessary and important to incorporate EA management plans into the
government agency.

11.2 Stage Purpose

The purpose of this stage is to analyze and document the plan to ensure the EA
deliverables are accepted and use by the different stakeholders in the
government agency. The expected outcomes or deliverables of this stage are:
1. EA usage plan
2. EA management plan

11.3 Stage Initiation

With the completion of the previous stage, the EA Core and working teams have
to ensure that the following deliverables are in place:
1. Transition Roadmap
2. Transition Resource Plan.
This stage is also a follow-up on important policies or direction statements
previously defined under the Continuous Governance section – on particular, on
EA usage and EA management directions.

51 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

11.4 Key Steps in Stage 9
The table below lists the key activities and expected deliverables for stage 9.

No Description Deliverable

9 Develop Management Plan EA Usage and Management Plans

9.1 Develop an EA usage plan EA usage plan

Develop an EA management
9.2 EA management plan
plan

Obtaining Governance
9.3 Approved EA usage and management plans
Approval

Management and Governance

Under the Continuous Governance section, the EA Governance Committee has set
up clear directions on the EA usage and management plans. This stage will focus
on the development of these plans.

12. Stage 10 – Execute and Maintain

12.1 Stage Summary

This is the last stage, where a government agency executes and maintains its EA.
Having covered many stages in the EA journey, this last stage concerns taking
action to make the government agency’s EA a reality.

52 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

12.2 Stage Purpose
The purpose of this stage is to finally implement the EA artifacts that were
documented in the previous stages. The following are the expected outcomes of
this stage:
1. Promote or market the government agency’s EA so that government employees
are aware of the usefulness of EA
2. Train some employees on using and maintaining the various information
related to EA
3. Execute or implement the EA, including the management of the transition
activities

12.3 Stage Initiation

With the completion of the previous stages, the EA Core Team and working teams
have to ensure that the following deliverables, in addition to the target
architectures, are in place:
1. EA Management Plan
2. EA Usage Plan
3. EA Transition Plan
With all the above plans, the EA Core Team and working teams can start the
execution phase.

12.4 Key Steps in Stage 10

The last stage is the final challenge for the EA Core team and working team
members to materialize their previous efforts. The key steps in Stage 10 are
shown in Table below.

No Description Deliverable

10 Execute and Maintain

Implement the EA Usage &

10.1 Project/Program Management Deliverables
Management Plan

Implement the EA
10.2 Project/Program Management Deliverables
Transition Roadmap

For more details, visit the National Enterprise Architecture Program page

53 | National Overall Reference Architecture (NORA) DGA-1-2-1-212

 DGA.GOV.SA
54 | National Overall Reference Architecture (NORA) DGA-1-2-1-212