الوثيقة المتكاملة للمنهجية الوطنية للبنية المؤسسية National Overall Reference Architecture

National Overall
Reference Architecture
(NORA)
e-Government
Program (Yesser)

2
National Overall Reference Architecture (NORA) – Handbook
Tableof
Contents

3
Table of Contents
1. Introduction 19
1.1. Document purpose 19
1.2. National Enterprise Architecture Framework 19
1.3. Values of NORA 19
1.4. Goals of NORA 20
1.5. Features of NORA 21
1.6. Target audience 21
1.7. Document structure 22
1.8. Related information 22
1.9. Contact information 22
2. Executive Summary 24
2.1. Need for Enterprise Architecture 24
2.2. Background of NEA Framework 26
2.3. Objectives of NORA 28
2.4. Defining a purpose for agency EA 28
2.5. NORA methodology 30
2.6. NORA relationship to NEA Framework 34
3. Stage 1 - Develop EA Project Strategy 36
3.1. Stage summary 36
3.2. Stage purpose 36
3.3. Stage initiation 36
3.4. Key steps in stage 1 36
3.4.1 Step 1.1 Analyze EA trends and case studies 38
3.4.2 Step 1.2 Provide EA awareness 39
3.4.3. Step 1.3 Assess government agency’s e-transformation maturity 40
3.4.4. Step 1.4 Document government agency’s EA project strategy 44
3.4.5. Step 1.5 Present and obtain approval for EA project strategy 46

4
4. Stage 2 - Develop EA Project Plan 48
4.4.1 Step 2.1 Set up EA committees and working teams 49
4.4.2. Step 2.2 Finalize EA development approach 54
4.4.3. Step 2.3 Document detailed EA project plan 63
4.4.4. Step 2.4 Present and obtain approval for the EA project plan 66
5. Continuous Governance 68
5.1. Purpose of governance 68
5.2. Outcomes of governance 68
5.3. Governance initiation 68
5.4. Key areas in EA governance 69
5.4.1. Program management 71
5.4.2. Change management 71
5.4.3. Capability management 79
5.4.4. Policy management 82
5.4.5. Performance management 85
6. Stage 3 – Analyze Current State 88
6.4.1. Step 3.1 Gather and document EA requirements 90
6.4.2. Step 3.2 Analyze internal environment 93
6.4.3. Step 3.3 Analyze external environment 100
6.4.4. Step 3.4 Present current state analysis 102

5
7. Stage 4 – Develop EA Framework 104
7.4.1. Step 4.1 Define EA’s vision and mission statements, & architecture objectives 106
7.4.2. Step 4.2 Define EA’s architecture principles 109
7.4.3. Step 4.3 Present and obtain approval for EA vision, mission and
architecture objectives 111
7.4.4. Step 4.4 Define EA Framework structure 111
7.4.5. Step 4.5 Design EA architecture elements 113
7.4.6. Step 4.6 Design EA model 114
7.4.7. Step 4.7 Develop EA documentation standard 119
7.4.8. Step 4.8 Develop EA artifacts management processes 121
7.4.9. Step 4.9 Present and obtain approval for EA framework 121
8. About Reference Models & Architectures 123
8.1. Need for clarity 123
8.2. Definitions 123
8.3. Process to build reference models and architectures 125
8.4. Building blocks of reference models and architectures 127
8.5. Summary of deliverables for reference models and architectures 129
9. Stage 5 – Build Reference Models 133
9.4. About NEA reference models 134
9.5.1. Step 5.1 Build performance reference model 137
9.5.2. Step 5.2 Build business reference model 143

6
9.5.3. Step 5.3 Build application reference model 149
9.5.4. Step 5.4 Build data reference model 157
9.5.5. Step 5.5 Build technology reference model 164
10. Stage 6 – Build Current Architecture 173
10.4.1. Step 6.1 Capture current business and IT data 176
10.4.2. Step 6.2 Analyze and build current business architecture 179
10.4.3. Step 6.3 Analyze and build current application architecture 195
10.4.4. Step 6.4 Analyze and build current data architecture 208
10.4.5. Step 6.5 Analyze and build current technology architecture 220
10.4.6. Step 6.6 Current architecture analysis 237
11. Stage 7 – Build Target Architecture 246
11.4.1. Step 7.1 Define directions for developing target architecture 248
11.4.2. Step 7.2 Build target business architecture 252
11.4.3. Step 7.3 Build target application architecture 256
11.4.4. Step 7.4 Build target data architecture 260
11.4.5. Step 7.5 Build target technology architecture 264
12 Stage 8 – Develop Transition Plan 269

7
12.4.1. Step 8.1 Define transition projects 270
12.4.2. Step 8.2 Prioritize transition projects 271
12.4.3. Step 8.3 Create transition roadmap 274
12.4.4. Step 8.4 Analyze and document required resources and outcomes 277
12.4.5. Step 8.5 Obtain governance approval 279
13. Stage 9 – Develop Management Plan 281
13.4.1. Step 9.1 Develop EA usage plan 282
13.4.2. Step 9.2 Develop EA management plan 288
14. Stage 10 – Execute and Maintain 300
14.1. Stage Summary 300
14.2. Stage Purpose 300
14.3. Stage Initiation 300
14.4. Key Steps in Stage 10 301
14.4.1. Step 10.1 Implement the EA usage & management plan 301
14.4.2. Step 10.2 Implement the EA transition roadmap 305
Annex A : NORA Summary of Deliverables by Stages 307
Annex B : NEA System and EAMS 321
B.1. NEA System Overview 321
B.2. Agency EAMS 323
Annex C : NEA Meta-Model 324
C.1. Overview of NEA Meta-model 324
C.2. Objectives of NEA Meta-Model 325
C.3. NEA Meta-Model Classes 326

8
Annex D :e-Government Transformation Plan 336
D.1. Mandates of A Government Entity 336
D.2. Strategic e-Government Transformation in an Agency 336
D.3. Overview of e-Government Transformation Plan 338
D.4. How to use NORA for developing e-Government Transformation Plan 339
D.5. Relevant Artifacts for e-Government Transformation 341
D.6. Exhaustive list of e-Government Transformation artifacts 344
Annex E : NEA EA maturity model 345
Annex F : Business Service Attributes 348

9
Table of Figures
Figure ‎2-1: Impact of EA on government 25
Figure ‎2-2: NEA Framework 26
Figure ‎2-3: NORA Methodology 33
Figure ‎3-1: Example of bottom-up development strategy 46
Figure ‎3-2: Example of mixed development approach 46
Figure ‎4-1: Example of EA organizational structure 51
Figure ‎4-2: Example of EA transition roadmap 59
Figure ‎4-3: Example format for EA project plan 65
Figure ‎5-1: Five Aspects of EA governance 70
Figure ‎5-2: Example of artifact review and approval process 74
Figure ‎53: Example for EA usage direction 83
Figure ‎54: Example for EA management plan direction 85
Figure ‎61: Example of Vision/Mission alignment with goals and initiatives 95
Figure ‎62: Example of business and IT alignment 97
Figure ‎63: Example of major IT systems supporting government functions 98
Figure ‎64: Example of IT systems supporting government functions by business areas 99
Figure ‎71: Example of a Vision statement 106
Figure ‎72: Example of EA architecture principles 110
Figure ‎73: EA Framework structure example 113
Figure ‎8-1: Basic process in building reference models and architectures 126
Figure ‎8-2: Building blocks / components 127
Figure ‎8-3: Same building blocks in NEA reference models 128
Figure ‎9-1: NEA reference models and their inter-relationships 134
Figure ‎9-2: NEA PRM artifacts 137
Figure ‎9-3: Example PRM purpose and direction 139
Figure ‎9-4: Example PRM strategic goals / outcomes 140
Figure ‎9-5: Example of PRM indicator description 142
Figure ‎9-6: NEA BRM artifacts 143
Figure ‎9-7: Example BRM purpose 146
Figure ‎9-8: Example of business area, LoB, business function and sub-business functions 147

10
Figure ‎9-9: NEA ARM artifacts 149
Figure ‎9-10: Structured diagram of application systems, components and interfaces in NEA ARM 151
Figure ‎9-11: Agency ARM artifacts 152
Figure ‎9-12: Example ARM purpose or direction 153
Figure ‎9-13: Example of MOE’s business and sub-business functions 155
Figure ‎9-14: NEA DRM artifacts 157
Figure ‎9-15: NEA DRM 158
Figure ‎9-16: Agency DRM artifacts 159
Figure ‎9-17: Example for defining DRM purpose 161
Figure ‎9-18: Example for developing data classification structure 162
Figure ‎9-19: NEA TRM artifacts 165
Figure ‎9-20: Example TRM purpose 168
Figure ‎9-21: Example TRM structure 168
Figure ‎10-1: Data capturing activities 176
Figure ‎10-2: Difference between BRM and BA 180
Figure ‎10-3: BA artifacts’ relationship diagram 181
Figure ‎10-4: Organizational chart example 184
Figure ‎10-5: Business area, LoB, business function and sub-business function diagram example 186
Figure ‎10-6: The properties of business function description 189
Figure ‎10-7: Contents of a sub-business function 188
Figure ‎10-8: MOE’s sub-business function & business process relationship 189
Figure ‎10-9: Business process map example 192
Figure ‎10-10: Difference between ARM and AA 196
Figure ‎10-11: AA artifacts’ relationship diagram 197
Figure ‎10-12: Application overview example 200
Figure ‎10-13: Difference between DRM and DA 209
Figure ‎10-14: DA artifacts’ relationship diagram 210
Figure ‎10-15: Conceptual data model example 213
Figure ‎10-16: Logical data model example 214
Figure ‎10-17: Data flow diagram example 215
Figure ‎10-18: Difference between TRM and TA 221

11
Figure ‎10-19: Relationship TA artifacts 222
Figure ‎10-20: Infrastructure overview example 225
Figure ‎10-21: WAN diagram example 227
Figure ‎10-22: LAN diagram example 228
Figure ‎10-23: Internet diagram example 229
Figure ‎10-24: WLAN diagram example 230
Figure ‎10-25: Storage diagram example 231
Figure ‎10-26: Server farm diagram example 232
Figure ‎10-27: Example BA analysis 238
Figure ‎10-28: Example BA improvement opportunities 239
Figure ‎10-29: Example AA analysis 240
Figure ‎10-30: Example AA improvement opportunities 240
Figure ‎10-31: Example DA analysis 241
Figure ‎10-32: Example DA improvement opportunities 242
Figure ‎10-33: Example TA analysis 243
Figure ‎10-34: Example TA improvement opportunities 243
Figure ‎11-1: Example of EA principles review and its implications 249
Figure ‎11-2: Example agency improvement opportunities for various architectures 250
Figure ‎11-3: Example of target architecture direction through overall analysis 251
Figure ‎11-4: Example of updated business function in target BA 254
Figure ‎11-5: Example of updated business processes in target BA 255
Figure ‎11-6: Example process to identify new application systems & architecture 258
Figure ‎11-7: Example of updated application function in target AA 259
Figure ‎11-8: Example of identified artifacts for updates in target DA 262
Figure ‎11-9: Example updated database diagram 263
Figure ‎11-10: Example of direction setting for in TA 266
Figure ‎11-11: Example of updated infrastructure overview in target TA 267
Figure ‎12-1: Example selection method for transition plan 271
Figure ‎12-2: Example of transition project 271
Figure ‎12-3: Example prioritization principles 272
Figure ‎12-4: Example priority assessment structure 273
Figure ‎12-5: Example priority assessment 273

12
Figure ‎12-6: Example transition projects by stages 274
Figure ‎12-7: Example of goal setting for each stage 275
Figure ‎12-8: Example detailed schedule by each stage 275
Figure ‎12-9: Example resource estimation procedure 276
Figure ‎12-10: Example required resource classification 277
Figure ‎12-11: Example resource estimation 277
Figure ‎12-12: Example resource requirements by stage 277
Figure ‎12-13: Example expected outcome 278
Figure ‎13-1: Example for EA usage purposes 283
Figure ‎13-2: Example for EA usage scope 284
Figure ‎13-3: Example for EA usage tasks 286
Figure ‎13-5: Example for the relationship between EA tasks and artifacts 287
Figure ‎13-6: Example of EA management plan 289
Figure ‎13-7: Example of EA management scope 289
Figure ‎13-8: Example for EA management plan process 290
Figure ‎13-9: Example for EA management plan principles 290
Figure ‎13-10: Example for EA roles for large organization 292
Figure ‎13-11: Example for architect tasks 292
Figure ‎13-12: Example for EA update process 294
Figure ‎13-13: Example for EA change process 295
Figure ‎13-14: Example for EA diffusion process 295
Figure ‎13-15: Example for EA compliance review 296
Figure ‎13-16: Example for EA design exception process 296
Figure ‎13-17: Example for EA system design 297
Figure ‎14-1: Example for EA usage guideline 302
Figure ‎14-2: NEA System Context 322
Figure ‎14-3: NEA Meta-Model 324
Figure ‎14-4: Components of Strategic Management in government agency 338
Figure ‎14-5: Linking strategy and e-Government transformation 340
Figure ‎14-6: Relevant artifacts for e-Government Transformation Plan 342
Figure ‎14-7: NEA EA maturity model 345

13
List of Tables
Table ‎2-1: List of NEA Framework Components 27
Table ‎2-1: Common EA objectives / drivers 29
Table ‎3-1: Stage 1 steps 37
Table ‎3-2: EA value proposition to stakeholders 39
Table ‎3-3: Likely EA value proposition based on e-Transformation maturity 42
Table ‎3-4: Local examples for EA drivers or purposes 43
Table ‎3-5: Considerations for EA project strategy development 45
Table ‎4-2: Typical government EA committees and working teams 50
Table ‎4-3: Governance / Management fields 52
Table ‎4-4: Examples of governance / management fields in government agencies 53
Table ‎4-5: Examples of EA scope 55
Table ‎4-6: Examples of EA gradual scoping 56
Table ‎4-7: Development approach recommendations 57
Table ‎4-8: Budget categories for consideration 58
Table ‎4-9: Description on the EA usefulness 60
Table ‎4-10: Examples of EA usefulness categories 61
Table ‎4-11: Examples of EA usefulness 62
Table ‎5-1: Continuous governance steps 69
Table ‎5-2: Need for EA change management 72
Table ‎5-3: EA awareness methods 74
Table ‎5-4: Suggested content for EA awareness 76
Table ‎5-5: EA promotion activities 78
Table ‎5-6: Capabilities required in EA 81
Table ‎5-7: Activities to define EA usage plan 83
Table ‎5-8: Activities to define EA management plan 84
Table ‎5-9: Performance metrics example 86
Table ‎6-2: Example questionnaire 91
Table ‎6-3: Example format to gather EA requirements 92

14
Table ‎6-4: Internal analysis areas & expected outcomes 93
Table ‎6-5: SWOT chart template 101
Table ‎7-2: Considerations for effective Vision & Mission statements 108
Table ‎7-3: Criteria examples of good architecture principles 109
Table ‎7-4: Examples of research areas for EA Framework 112
Table ‎7-5: Description of EA elements 114
Table ‎7-6: Activities to develop the EA Model 115
Table ‎7-7: EA Model view by stakeholders 116
Table ‎7-8: EA Model view by architecture 116
Table ‎7-9: Example of Yesser’s standard terms 120
Table ‎8-1: Differences between Reference Models and Architectures 125
Table ‎8-2: Summary of artifacts by reference models and architectures 129
Table ‎9-2: PRM artifact descriptions 138
Table ‎9-3: Main activities to build agency PRM 139
Table ‎9-4: Example measurement areas, categories and indicators 141
Table ‎9-5: BRM artifact descriptions 144
Table ‎9-6: Main activities to build agency BRM 145
Table ‎9-7: Example of business area, LoB, business function and sub-business functions 148
Table ‎9-8: ARM artifact descriptions 150
Table ‎9-9: Main activities to build agency ARM 153
Table ‎9-10: NEA ARM principles 154
Table ‎9-11: DRM artifact descriptions 158
Table ‎9-12: Main activities to build agency DRM 160
Table ‎9-13: Example data structure definition 163
Table ‎9-14: Example data exchange definition 163
Table ‎9-15: TRM artifact descriptions 165
Table ‎9-16: TRM service area and category descriptions 166
Table ‎9-17: Main activities to build agency TRM 167

15
Table ‎10-2: Example of possible data sources 177
Table ‎10-3: BA relationship with other architectures 180
Table ‎10-4: BA artifact descriptions 182
Table ‎10-5: Activities to build BA 182
Table ‎10-6: The properties of organization chart 185
Table ‎10-7: Example of sub-business function description 189
Table ‎10-8: Business process description example 190
Table ‎10-9: Business activity description example 191
Table ‎10-10: The properties of service catalogue 193
Table ‎10-11: Service catalogue example 194
Table ‎10-12: AA relationship with other architectures 196
Table ‎10-13: AA artifact descriptions 198
Table ‎10-14: Activities to build AA 198
Table ‎10-15: The properties of application overview 199
Table ‎10-16: The properties of application catalogue 201
Table ‎10-17: Application catalogue example 202
Table ‎10-18: The properties of application function 203
Table ‎10-19: Application function example 204
Table ‎10-20: The properties of application relationship 206
Table ‎10-21: Application relationship example 207
Table ‎10-22: DA relationship with other architectures 209
Table ‎10-23: DA artifact descriptions 211
Table ‎10-24: Activities to build DA 211
Table ‎10-25: The properties of conceptual data model 212
Table ‎10-26: The properties of logical data model 213
Table ‎10-27: The properties of data flow diagram 215
Table ‎10-28: The properties of database portfolio catalogue 216
Table ‎10-29: Database catalogue example 217
Table ‎10-30: The properties of data dictionary 218
Table ‎10-31: Data dictionary example 219
Table ‎10-32: TA relationship with other architectures 221

16
Table ‎10-33: TA artifact descriptions 223
Table ‎10-34: Activities to build TA 223
Table ‎10-35: The properties of infrastructure descriptions 226
Table ‎10-36: The properties of hardware catalogue 233
Table ‎10-37: Hardware catalogue example 234
Table ‎10-38: The properties of software catalogue 235
Table ‎10-39: Software catalogue example 236
Table ‎10-40: Activities to analyze current architectures 237
Table ‎11-2: Activities for defining target architecture directions 249
Table ‎11-3: Target BA artifact descriptions 252
Table ‎11-4: Activities to build target BA 253
Table ‎11-5: Target AA artifact descriptions 256
Table ‎11-6: Activities to build target AA 257
Table ‎11-7: Target DA artifact descriptions 260
Table ‎11-8: Activities to build target DA 261
Table ‎11-9: Target TA artifact descriptions 264
Table ‎11-10: Activities to build target TA 265
Table ‎12-2: Activities to define transition projects 270
Table ‎12-3: Activities to prioritize transition projects 272
Table ‎12-4: Activities to create transition roadmap 274
Table ‎12-5: Activities for estimating resources and outcomes 276
Table ‎13-2: Activities to define EA usage purpose & scope 283
Table ‎13-3: Activities to define usage plan development 285
Table ‎13-4: Example for EA users 286
Table ‎13-5: Activities of EA management purposes & scope 288
Table ‎13-6: Activities to develop EA management organization 191
Table ‎13-7: Activities to define EA management process 293
Table ‎13-8: Activities to define EA management system 297

17
Table ‎13-9: Example for EA management system’s functions 298
Table ‎14-2: Example for EA management guideline 303
Table ‎14-3: Example for EA usage & management plan assessment 304
Table ‎14-4: Stage 1 summary 307
Table ‎14-8: Continuous governance summary 310
Table ‎14-9: Continuous governance steps 310
Table ‎14-26: NEA Meta-Classes 326
Table ‎14-27: NEA business service Meta-Class 335
Table ‎14-28: List of artifacts for e-Government Transformation Plan 343
Table ‎14-29: EA maturity components & levels 346
Table ‎14-30: Attributes of business service (Arabic & English) 348

18
1.Introduction

19
1. Introduction
1.1 Document purpose
The purpose of this document is to describe and elaborate 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 link to the overall National Enterprise Architecture (NEA) Framework.
1.2 National Enterprise Architecture Framework
The National Enterprise Architecture (NEA) Framework is a key element for the national e-Government
envisioned to incorporate a federate approach to enterprise architecture for the Kingdom of
Saudi Arabia (KSA). NEA Framework supports the identification of re-usable 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.
1.3 Values of NORA
Government agencies who do not have an EA in practice would typically face the following problems:
1. Lack of standardization of business services, data and IT interoperability within the government
agency and across government agencies
2. Lack of performance indicator in IT investment linking to the business objectives
3. Government business ownerships are unclear
4. Lack of whole of government agency view
5. Duplicated IT systems, data and IT infrastructure within a government agency is common
6. Misalignment between government agency’s business services and IT initiatives
7. Lack of standards to integrate services, business processes, IT systems, data and IT infrastructure
8. No performance indicators for business function and services
9. Lack of quality checks for delivering IT systems, data and infrastructure

20
10. Lack of integrated government services and consistent delivery.
11. With EA, the above problems can be eradicated. However, the development and implementation
of an EA is not an easy task and government agencies can face the following challenges:
12. EA stakeholders’ low awareness on EA, its benefits and its practices
13. Little knowledge of EA building process
14. Communication barriers and bottlenecks among EA stakeholders
15. Implementing EA without a systematic approach
16. Experiencing difficulty in maintaining EA practices
17. Excessive reliance on vendors and external expertise.
1.4 Goals of NORA
The goals of NORA are as follows:
1. Define scope and requirements of the EA at the government agencies
2. Help government agencies to have a smooth and effective EA implementation
3. Ensure quality of government agency’s EA through systematic processes and recommendations
4. Alignment of agency’s EA with Saudi government national architecture and National Action Plans
to facilitate whole of government approach
5. Facilitate EA utilization, promotion and capability building in the government agencies.

21
1.5 Features of NORA
The main features of NORA are:
1. As a guide for EA development, it is written from the government agencies’ perspective
2. All stages in the EA lifecycle are described to some detail to provide clarity to the government
agencies
3. Balanced approach in EA development that focuses both on processes and the production of
standard artifacts or deliverables
4. Examples and example outputs are provided to aid understanding
5. Highly customizable to suit varied requirements of different government agencies.
1.6 Target audience
As NORA is a guide for government agencies to develop their EAs, the target audience for NORA
are as follows:
1. Enterprise Architects
2. Business Architects
3. Application Architects
4. Data Architects
5. Technology Architects
6. IT Architects
7. CIOs
8. CXOs
9. Project Managers
10. Business Owners
11. IT System Owners
12. IT Managers
13. Project Managers
14. IT Consultants
15. IT Vendors.

22
1.7 Document structure
NORA contains the following sections:
1. Executive Summary
2. The executive summary gives a complete summary of NORA. After reading this section, the
reader can understand how NORA guides the government agencies in the EA development.
The executive summary is excellent for government agencies’ decision makers. All staff
involve in EA should also read this executive summary.
3. Stages of EA Development
4. This document provides the detailed description by stages. The detailed process and expected
EA deliverables are explain in each stage. Examples and templates are also provided where
possible.
5. Annex
The annexes provide additional templates, checklists and information.
1.8 Related information
As NORA is only one of the many documents, it is advisable to refer to the main NEA Framework.
1.9 Contact information
For any feedback, comments or need for more information on NORA, please email to
nea@yesser.gov.sa

23
2.Executive
Summary

24
2. Executive Summary
2.1 Need for Enterprise Architecture
Gartner Research defines enterprise architecture as:
“Enterprise Architecture (EA) is a discipline for proactively and holistically leading enterprise
(i.e. government) responses to disruptive forces by identifying and analyzing the execution of
change toward desired business vision and outcomes.
EA delivers value by presenting business and IT leaders with signature-ready recommendations
for adjusting policies and projects to achieve target business outcomes that capitalize on relevant
business disruptions.”
Government agencies have to respond to continuous disruptive forces such as economic
changes, social demands, political directions and technology advancements. The government
agencies’ responses to these disruptive forces are on their own silo actions. While government
agencies have made their best effort to derive their own desired outcomes, the end result
to the stakeholders such as citizens, businesses and government leaders are far from real
satisfaction.
With EA, on the other hand, the execution of change is a structured approach with the various
perspectives on the government business, desired outcomes, availability of technologies and
processes. When EA is correctly implemented, it provides the following valuable benefits to key
decision makers:
• Insight – the abstraction of knowledge based on detailed information including issues, challenges
and opportunities
• Oversight – the information overview corresponding to the overall accountabilities and
responsibilities of the government agencies, and for the whole-of-government
• Foresight – from the analysis of detailed data from various sources, trend analysis and event
probabilities can be calculated and estimated.

25
The diagram below shows the typical situation of government agencies without EA and the
benefits with EA.
Figure ‎2-1: Impact of EA on government

26
2.2 Background of NEA Framework
The NEA Framework is the window for strategic integration and collaboration of an effective na-
tional e-government implementation. NEA is the enterprise architecture for the whole-of-Saudi
government. Together with other strategies such as the Saudi e-Government Action Plan, the
NEA Framework and its components allow useful insight and foresight for the future development
and implementation of highly integrated e-government and e-services.
The NEA Framework has 11 main architecture components as depicted in the diagram below.
Each architecture component has a specific role and function. In addition, each architecture
component may have direct or indirect relationship(s) with other architecture components.
The table below provides a summary list of all the 11 architecture components. Please refer to
separate documents for detailed information of the architecture components.
Figure ‎2-2: NEA Framework

27
Compo-
nent Name
Component Description
Strategy The strategy component of NEA Framework captures the essences of strategic
alignment with National and e-government strategic plans. The constituents of
the strategic component takes cognizance of the envisioned future as per the
above plans, and aligns itself strategically by producing long term and short term
plans to meet that future vision. The Journey being guided by adequate policies.
Models The NEA Models are a high-level classification of views , key architectural elements
and the best practice for them. They facilitate in forming standardized viewpoints
for example from a snapshot of the whole of government to Performance, Business,
Application, Data, Technology, Security, Maturity etc..
Operation The operation is about managing the day to day business of NEA, that primarily
involves designing, and controlling the process of service delivery and redesigning
business operations in delivering services. It is guided by well-defined processes,
methodology and tools that ensure business operations are efficient and effective in
terms of meeting customer requirements.
Governance NEA governance is about providing the strategic directions to achieve the NEA
vision, mission and objectives through agile organization structure, clear roles
and responsibilities, and effective set of governance or management practices. It
is also about regular monitoring and reviewing of progress while understanding the
constant changes in economic, social and technological environments
Table ‎2-1: List of NEA Framework Components
NORA is one of the integral parts of NEA Framework. NORA’s role within the NEA Framework
is to provide a definitive and clear methodology for building EA in the government agencies.

28
2.3 Objectives of NORA
The objectives of NORA are as follows:
1. To guide government agencies in their development of EAs
2. To speed up EA development with quality outputs
3. To ensure EA in government agencies are aligned with their e-Government transformation
and IT plans.
2.4 Defining a purpose for agency EA
In alignment to the strategic 2nd Saudi e-Government Action Plan, every government agency is
expected to have an e-transformation roadmap that would pave the way for advancement of
delivering government services. EA is an excellent tool for planning as well as implementing this
e-transformation roadmap.
Although the ultimate goal is to transform their government services and business functions,
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.

29
Drivers EA Objectives - Values
Lack of governance and prioritization Comprehensive understanding of agency-wide
perspective, including its problems, challenges,
investments and opportunities
Lack of agency wide information IT standardization, with detail information and
inter-relationships between business and technologies
No integration among departments No duplication of investments and systems; integration
of work resulting in efficiency and better customer
service
Duplicated investments Prevent investments and work duplication
Ineffectiveness and inefficiency
in public service delivery
Understand agency weaknesses; integrated approach
to improve agency’s productivity and public service
delivery
No standard operations Implement quality business and service operations
No technology standards Interoperability of systems and processes in the agency
Investing capital and procurement costs Effective investments that align business and IT
Table ‎2-1: Common EA objectives / drivers
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
EA journey:
1. Implementing e-Government transformation roadmap
2. Optimizing IT investments
3. Reducing IT costs
4. Aligning IT to government business.
As EA is a wide program with an on-going 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:

30
Standardization and interoperability of services, IT applications, data and infrastructure
Selection and/or prioritization of projects in the government agency for funding and implementation
1. Building new capability such as improving customer service, making business processes
effective, and agency-wide adoption of mobile applications and devices
2. Improve and integrate business critical government services and business functions through
Business Process Re-Engineering and automation
3. Development of IT Resource Management and IT Portfolio Management.
2.5 NORA methodology
NORA methodology is based on a lifecycle consisting of ten major stages. The execution of the
stages are in sequence, however it can be tailored to suit the purpose of agency EA. Each stage
has its own architecture artifacts or deliverables. In NORA, a continuous set of governance
activities are carried out throughout the nine stages. Figure 2-3 below illustrates the 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 address 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
trainings, tools and new processes), performance management (new KPIs and standards) and
policy management.
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 to either develop its
EA internally or outsource.

31
Stage 2 – Develop EA Project Plan
Having established an approved EA Project Strategy, the government agency has to carry out
the 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 – Develop 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 is fundamental to its EA journey.
The government agency should focus on building 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.
Stage 6 – Build Current Architectures
The focus of this stage is in capturing the current architectures of the government agency so
that the agency can clearly understand its IT and business landscapes. This would allow a 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.

32
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 out-
comes 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 impor-
tant 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 standard operating procedures. To ensure contin-
ued 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 with taking actions to make the govern-
ment agency’s EA into a reality.

33
Figure ‎2-3: NORA Methodology
Please also refer to Annex A – Summary of NORA Deliverables by Stages that acts as a checklist
for government agencies in their EA development.

34
2.6 NORA relationship to NEA Framework
Although NORA is only a guide for government agencies to develop their EAs, it is nonetheless
an important methodology. When government agencies develop their EAs according to NORA,
not only do they deliver their own EAs, but also it ensures that all EA development complies
with the overall NEA Framework.
NORA allows government agencies to comply with and align to the national e-Government
transformation plan and initiatives. Through NORA, government agencies can review and develop
detailed reference models – each aligned with the NEA Framework’s reference models such as
Business Reference Model, Application Reference Model, Data Reference Model and Technology
Reference Model. When the various reference models are aligned, it aids government agencies
to share applications and information, and to develop highly integrated business functions and
services that delight citizens and businesses.

35
3.Stage1-Develop
EAProjectStrategy

36
3. Stage 1 - Develop EA
Project Strategy
3.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 to either develop its
EA internally or outsource.
3.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:
1. Increase the government agency’s EA awareness – from top management to the operations staff
2. Define and communicate EA goals and directions
3. Obtain management approval to embark on the EA journey.
3.3 Stage initiation
Yesser 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
Yesser to initiate their EA program.
3.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 deliver-
ables in Stage 1 are shown in Table 3-1:

37
Stage /
Step No
Description Deliverable
1 Develop EA Project Strategy Government Agency’s EA Project Strategy
1.1 Analyze EA trends and case studies (both
international and local agencies; also
across same line of business/Business
function in BRM )
Document relevant EA trends and case studies
relating to the government agency
1.2 Provide EA awareness to government
agency’s business and IT leaders
(Government agencies can invite Yesser to
brief on NEA)
Understand the importance of EA
1.3 Assess government agency’s e-transformation
maturity(Via Qiyas) and its alignment of IT
to the government business
Submit and present the assessment report to
the e-Transformation Committee or equivalent.
The assessment shall describe the agency’s:
1. Maturity of its e-transformation
2. Effectiveness of its business functions
3. Maturity on IT adoption
4. Agency’s capability on business productivity
and use of IT.
1.4 Document government agency’s EA project
strategy
Draft Government Agency’s EA Project Strategy
1.5 Present and obtain approval for the EA
project strategy
Approved Government Agency’s EA Project
Strategy by its e-Transformation Committee or
equivalent
Table ‎31: Stage 1 steps

38
3.4.1 Step 1.1 Analyze EA trends and case studies
As stated by International Benchmarking Clearinghouse (IBC), analyzing EA trends is a set of
“Activities to continuously evaluate and compare world’s leading corporations or agencies with
a current organization to improve the organization’s performance”.
This activity is vital for the agency implementing EA, in terms of understanding the best practices
adopted by similar verticals. To leverage their learning, choose the most applicable strategy
for the agency. However if the agency finds itself in a difficult position either to execute it, or if
there is a possibility of this effort forking into a new project and hence impede the EA strategy
development. Then, they may choose to limit the scope of the activity to reduce negative impact
on the EA Project.
While there are numerous ways to carry out this step, the following activities are recommended:
1. Form a small team of members (both IT and non-IT) who are interested and passionate
about EA
2. Understand the basics of EA by attending seminars or trainings
3. Carry out a high level research on the current trends in EA. Examples of reliable online
resources include Federal Enterprise Architecture (FEA), The Open Group Architecture
Framework (TOGAF), National Association of State Chief Information Officers (NASCIO) and
Enterprise Architecture Center of Excellence (EACOE). There are also numerous articles on
‘EA Trends in Government’ (simply search on the Internet for the latest)
4. Refer to more detailed EA case studies for similar line of business or government domain
such as Education, Health, Agriculture, Oil & Gas (Energy) and Municipality
5. Document the findings and find basic patterns in EA development
6. Refer to the Yesser’s National Enterprise Architecture (NEA) Framework. They can also discuss
with Yesser’s NEA Office for details and to find other relevant government agencies who have
embarked or completed their EAs
7. Finalize the EA analysis document.

39
3.4.2 Step 1.2 Provide EA awareness
Having documented the EA trends and case studies that are relevant to the government agency,
the next step is to spread the importance of EA. The idea is to provide constant awareness to all
levels of staff in the government agency – both the business and IT staff, including top management
and the operations staff.
In particular, provide the EA awareness to the top management or e-Transformation Committee.
This is important as they will be the main decision makers and sponsor for the EA project.
Government agency can also work with Yesser to present EA as a strategic enabler in
e-Government to them. The recommended EA value propositions are listed in Table 3-2:
S/No Stakeholder EA Value Proposition
1 Top Management (Minister, Di-
rector-General, CEO, CXO) and /
or e-Transformation Committee
1. Align government agency projects with Vision 2030,
National Transformation Plan and Saudi e-Government
Action Plan
2. Aid planning and prioritizing government agency-wide
action plan
3. Improve service quality to citizens and businesses
4. Prioritize and improve IT investments for government
agency
5. Business and technology innovation to deliver highly
integrated, value-added services.
2 Finance Director / CFO 1. Reduce wastage of IT costs
2. Prioritize and improve IT investments for government
agency.
3 Business Owners 1. Improve service quality to citizens and businesses
2. Increase productivity
3. Integrate work across business domains or divisions,
including inter-agency.
4 IT Director / CIO 1. Prioritize IT projects
2. Reduce wastage of IT costs
3. Identify consolidation projects to reduce IT cost and
better management
4. Develop inter-operability standards within govern-
ment agency and inter-agency.
Table ‎32: EA value proposition to stakeholders

40
In addition to the EA Value Proposition, the team can also provide EA awareness on factors
such as:
a. Explain best EA practices in other agencies.
b. Explain EA related laws and regulations imposed on government agencies via decrees .
c. Explain how EA affects agency’s performance and innovation endeavors, and what EA will
bring to the agency’s executives.
d. Utilize external expertise as needed.
It is recommended that the team present the EA value proposition to the IT Director or CIO
first. Subsequently, the team can present or provide awareness to the different stakeholders
and obtain feedback from them. Finally, they can present to the top management to get their
buy-in. The government agency can also approach Yesser’s NEA office to help in the EA awareness
sessions.
For now, the awareness sessions are to make the stakeholders think about the value of EA. It is
not to get their approval yet (although it would be good). Once they are aware of the benefits
of EA, the team may also need to engage them for the next step. Note that these awareness
sessions are part of the continuous EA governance (see the ‘Continuous Governance’ section
for details).
3.4.3 Step 1.3 Assess government agency’s e-transformation maturity
This step focuses on the maturity of the government agency’s e-transformation. From the
above value propositions, EA can help to determine areas for improvements to increase the
e-transformation maturity. The e-Transformation maturity is measured yearly by Yesser using
the Qiyas tool. The outcome of this step will drive the actual scope and motivation for the
government agency’s EA. The following activities are recommended:

41
1. Obtain the government agency’s maturity report from Yesser via Qiyas
2. Factors for consideration include rate of IT adoption, effectiveness of business services &
functions, satisfaction level of citizens & businesses, rate of alignment with 2nd Saudi
e-Government Action Plan, government agency’s capability on business productivity, and
the extent of sharing of applications, data and IT infrastructure within the government
agency and inter-agency
3. Identify the areas for improvements
4. Analyze these areas and map to the specific EA value propositions
5. Also refer to NEA Maturity Model so that the government agency can further assess its
maturity
6. Shortlist the recommended EA value proposition(s)
7. Present to the e-Transformation Committee or equivalent and get their approval or concurrence.
From their feedback, may need to do changes to finalize the EA value proposition.
Table 3-3 provides a summary of the likely EA value propositions based on the e-transformation
maturity level. Note that this is only an indication. Government agencies have to do their own
detailed analysis.

42
S/No
e-Transformation
Maturity
Likely EA Value Proposition(s)
1 LOW a. Align government agency projects with Saudi e-Government
Action Plan
b. Aid planning and prioritizing government agency-wide
action plan
c. Improve service quality to citizens and businesses
Prioritize IT projects
2 MEDIUM a. Align government agency projects with Saudi e-Government
Action Plan
b. Aid planning and prioritizing government agency-wide action
plan
c. Improve service quality to citizens and businesses
d. Increase productivity
e. Prioritize and improve IT investments for government agency
f. Reduce wastage of IT costs
g. Identify consolidation projects to reduce IT cost and better
management
h. Develop inter-operability standards within government
agency and inter-agency
3 HIGH a. Prioritize and improve both business and IT investments for
government agency
b. Business and technology innovation to deliver highly integrated,
value-added services
c. Significant performance improvements for the government
agency
Table ‎3-3: Likely EA value proposition based on e-Transformation maturity

43
Below are examples of local government agencies’ EA drivers – i.e. the motivation reasons or
purposes in developing their own EAs.
Government Agency EA drivers
The National Information Center
(Technology arm of Ministry of
Interior)
1. Lack of agency-wide view to govern projects (both
business & IT) and resources
2. Duplicated investments especially in IT
3. Inefficient and ineffective in delivering quality and
timely government services
4. Operational difficulties due to abundance of non-
standardized infrastructure and technologies
The National Center for Education
Information (Ministry of Education)
1. Lack of agency-wide view to govern projects (both
business & IT) and resources
2. Duplicated investments especially in IT
3. High demand for IT services and solutions
4. Complex business and IT landscapes
5. Organizational difficulties such as ineffective
communications, lack of transparency and
inefficiency
Ministry of Education
(Higher Education) – Safeer Program
1. No organizational-wide view of services, applications,
business processes, data and IT infrastructure that
affect strategic decision making
2. High IT operational costs
3. Operational complexity
National Center for Assessment in
Higher Education (Qiyas)
1. Lack of organizational-wide governance
2. Not business-driven; instead IT-led
3. Improve the delivery of quality services
4. Operational complexity & high costs
5. Performance limitations
Table ‎3-4: Local examples for EA drivers or purposes

44
3.4.4 Step 1.4 Document government agency’s EA project strategy
After some EA awareness sessions and followed by the approval from the top management or
e-Transformation Committee, there should be sufficient driving factors by now to embark on
the EA development. It is vital, however, to document an EA Project Strategy clearly describing
the goals, expected outcomes, and project schedule with a list of resources required.
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 Out-Source)
5. Estimated Cost and Resources (Staff) Requirements.
Table 3-4 illustrates the key considerations in developing the EA Project Strategy.

45
Considerations Pros Cons
Scope
Gradual
Stable EA management
with minimized risks
Losing momentum due to
extended development period
All at once
Outcome in
organization’s
overall perspective.
Risk of failure depending on
organization’s readiness
Workforce
In-House
Internal resource can
be utilized Extended preparation time
Outsourcing
Timely staffing of
expertise desired
Little knowledge accumulation.
Excessive reliance on outer
resources.
Direction
Upward Visible outcomes on time
Extra efforts on integration/
alignment needed
Downward
Realizing EA’s full po-
tential
Extended time to see visible
outcomes
Focus
All Even An overall architecture
can be obtained
Additional time and cost.
Missing in-depth information on
critical areas
Focus on
Key Areas
Visible outcome in
major areas.
Momentum when
expanding areas
Difficulty of use due to uneven
depth of information
Table ‎3-5: Considerations for EA project strategy development
Depending on the EA value proposition or purpose, the EA strategy is typically build gradually
over time from bottom-up, top-down, or both. The following are examples of EA development
strategies.

46
Figure ‎31: Example of bottom-up development strategy
Figure ‎32: Example of mixed development approach
3.4.5 Step 1.5 Present and obtain approval for EA project strategy
Present and get approval on the EA Project Strategy from the e-Transformation Committee or
equivalent. Note that this is not an easy task and may need a few iterations. The recommended
activities are:
1. From the awareness sessions, the team can have a good idea who can provide good direc-
tions, requirements and supportive of the EA project. Thus, obtain feedback on the EA
project strategy from these key stakeholders
2. In addition to the EA project strategy documentation, prepare a precise yet effective pre-
sentation slides
3. Present to the key stakeholders and other EA supporters. From their feedback, update the
presentation slides and EA project strategy document respectively
4. Finally, present the e-Transformation Committee or equivalent for approval.

47
4.Stage2-Develop
EAProjectPlan

48
4. Stage 2 - Develop EA
Project Plan
4.1 Stage summary
Having established an approved EA Project Strategy, the government agency has to carry out
the detailed plan for the EA project. This stage describes the key activities involved in developing
and obtaining approval for the EA project.
4.2 Stage purpose
The government agency has to structure and form appropriate EA Core team(s) and develop the
detailed EA project plan. The following specific expected outcomes from this stage are:
1. Clarify roles and responsibilities of management and the various working teams
2. Clarify the governance and management of EA in the government agency
3. Obtain management approval and commitment on the goals, schedules and resources to
develop and implement the EA.
This stage begins with the endorsement or approval of the EA Project Strategy in Stage 1.
Table 4-1 lists the key steps in Stage 2.

49
Stage /
Step No
2 Develop EA Project Plan Government Agency’s EA Project Plan
2.1 Upon approval of the Project Strategy
(Step 1.4), propose and set up the vari-
ous EA committees and teams such as EA
Governance Committee, EA Working Team,
Business-Domain Working Team and the IT
Working Team.
Approved EA committees and working
teams by the e-Transformation
Committee or equivalent
2.2 Finalize the EA development approach such
as scope, budget, schedule, and including
outsourcing or insourcing of the Government
Agency’s EA implementation. Also include
the adoption of EA culture into all aspects
of business and IT planning and reviews
Approved EA development approach
by e-transformation committee or
equivalent
2.3 Upon approval of Steps 2.1 & 2.2, the EA
working team will document the detailed EA
Project Plan
Draft EA project plan
project plan
Approved EA project plan by the EA
Governance Committee
Table ‎4-1: Stage 2 steps
4.4.1 Step 2.1 Set up EA committees and working teams
The first activity is to set up the necessary committees and working teams. Depending on the
government agency’s EA goals and scope, the type of committees and working teams may vary.
Although every government agency has an e-Transformation Committee that oversees the
overall development and progress of the e-Government transformation, there is a need for an
EA governance committee to oversee and direct the progress of the EA development project. EA
is one of the main enablers for an effective e-Government transformation. Typically, one of the
e-transformation committee members (i.e. the main EA sponsor) will chair the EA governance
committee. Table 4-2 lists the common committees and working teams for a government EA
development project, while Figure 4-1 shows a example EA organizational structure. Note that
these are only recommendations. Government agencies have to find the best organizational
structure for its EA project.

50
S/No
Name of
Committee /
Working Team
Responsibilities Members
1 EA Governance
Committee
a. Steers and provides strategic government
agency-wide directions
b. Empowers the working teams with account-
abilities and resources
c. Makes strategic decisions on EA recommen-
dations that affect the whole-of-govern-
ment agency (including its branches if any)
d. Raise up matters or issues affecting govern-
ment agency-wide and inter-agency col-
laborations
e. Reviews and endorses the EA Project plans,
frameworks and reference models
f. Reviews and approves strategic policies and
actions as
recommended by the EA Core Team.
The government agency
e-Transformation Committee (if exist)
can also play another role as the EA
Governance Committee.
Alternatively, the members
recommended are:
i. Deputy Under Secretary / Deputy
CEO / Deputy DG as Chairperson
(basically the 2nd highest person in
the government agency)
ii. CxO(s)
iii. CIO / IT Director
iv. Chief Architect
(could be an outsourced role)
v. Directors of core
business functions.
2 EA Core Team a. Architects the government agency’s EA
b. Develops EA framework and reference mod-
els
c. Recommends strategic directions, policies
and projects for the whole-of-government
agency.
i. Chief Architect
ii. Business Architect
iii. Application Architect
iv. Data Architect
v. Technology Architect
vi. EA Working Team members (see below).
3 EA Working Team a. Develops the various EA Reference Models
and Standards
b Maintains the EA
artifacts
c. Provides trainings and awareness to the
government agency.
i. Business domain experts in+the core
government agency’s functions
ii. IT Manager
iii. IT engineer who is in charge of infra-
structure and technology matters
iv. Database Administrator (DBA)
v. Application Analyst.
Table ‎4-2: Typical government EA committees and working teams

51
Some important notes:
1. EA project is not only about IT. Hence, it is important that sufficient staff from the business do-
mains are involved. The business domains experts should be experienced and have good detailed
knowledge about the government agency’s main businesses.
2. It is also recommended to get the business experts who are in charge of the core e-services and
customer/citizen service relationship (if any)
3. As for the IT staff members, they should be experienced and are leading specific teams such as
infrastructure, database and applications.
Figure 4-1 illustrates an example of the EA organizational structure.
Figure ‎4-1: Example of EA organizational structure

52
In addition to the organizational structure of the committees and working teams, it is also a
necessity to define basic governance or management processes relating to the approval of
projects and activities. The tables below provide different governance/management areas for
considerations and example cases use in government agencies respectively. For more details on
governance, please refer to the section “Continuous Governance”,
Management
Field
Key Content
Program Management
1. Track the progress of the EA project
2. Provide updates to the EA Governance Committee
3. Highlight or alert issues pertaining to schedule, resources and
budget.
Change Management
1. Ensure quality of content in the EA deliverables and artifacts
2. Control and approve changes and publishing of artifacts
3. Agree on removal or deletion of obsolete artifacts.
Performance Management
1. Analyze and review impact of EA on the government agency
2. Measure the usefulness of EA in different aspects and operations
of the government agency
3. Approve the areas of improvement as described in the EA’s
recommendations.
Capability Management
1. Identify skills for development in the government agency
2. Identify departments, division or business functions that require
increased or improved capabilities
3. Approve on training programs and incentives.
Table ‎4-3: Governance / Management fields

53
Government
Agency
Management Scope
The Ministry of AAA
• EA progress management group
• EA progress management procedure
- Progress management procedure, change request · re-
view, decision-making on changes, EA synchronization, EA
re-composition, EA release
The Ministry of BBB
• EA management group
• EA work planning
- EA project planning, EA observance, EA change, EA use sup-
port, EA system operation, EA assessment
• Management support tool
- management guideline, training planning, change manage-
ment, transition plan, performance model
The Ministry of CCC
• EA management group plan
• EA management process
• EA maturity model
• EA management guideline
Table ‎4-4: Examples of governance / management fields in government agencies
These recommendations on committees / working teams and governance processes have to be
approved by the e-Transformation Committee or equivalent. On approval, these committees
and working teams can officially embark on the detailed EA development work. Please refer to
the ‘Continuous Governance’ section for more details.

54
4.4.2 Step 2.2 Finalize EA development approach
The result of Stage 1 was the high-level EA Project Strategy developed by a small group of
individuals. As EA is a wide topic with many factors, it is a prudent approach to develop a more
detailed EA Project Plan with inputs from various perspectives within the government agency.
With the setup of the various EA committees and working teams, the official EA work can begin.
The EA Core Team and the various working teams can meet, discuss and finalize on the following:
1. EA Objectives / Goals
Agree on the primary objectives or goals of the EA project. The initial objectives or goals defined
in the EA Project Strategy have to be reviewed and discussed with the new members in the EA
Core Team and working teams. It is common that the EA objectives or goals are and/or amended.
2. EA Scope
The EA Core Team and working team members need to have detailed discussion on what entails
the EA development scope for the government agency. The EA scope will affect the resources
required, time and budget. With inputs from different members, there is a tendency that the
scope can be specific. The government agency also has to consider a gradual or consolidated
scoping i.e. to do everything in the EA at once or to build the EA gradually over time. The EA
Core Team or Chief Architect has to normalize or find a balance in the EA scoping. Below are
some examples of the EA scopes.

55
Item Specific Scope
Current
/ Target
Architecture
1. What was the primary Purpose for developing EA?
2. Is the primary purpose to develop future business and IT blueprints?
3. Is the primary purpose to manage effectively the current IT resources?
Architecture
Scope and
Level
1. An agency with no EA experience would better off with a gradual
approach.
2. The T-approach (overall architecting + in-depth architecting on cer-
tain areas) can be taken as needed.
3. Gradual scoping appropriate to EA purposes
4. A current architecture should be detailed enough to perform an
overall analysis. Target architecture should be drawn at the planner
level and contain details down to the developer level.
Business
/ Application
/ Data
/ Technology
/ Security
1. Is business process improvements?
2. Is there a need to align IT projects with the business objectives?
3. Is a data renovation such as data standardization or data sharing
urgent?
4. Is there an urgent need for IT standardization or IT asset management?
Table ‎4-5: Examples of EA scope

56
Gradual Scoping Examples
1
a. On some domains (Strategy, Business, IT etc.)
b. Vision / Principles, Framework, Reference Models
c. Current and Target Architecture
d. Transition Plan
e. Training / Promotion
2
a. On all domains
b. Current and Target Architecture
c. Transition Plan
e. EA Tool
f. Training/Promotion
g. EA Maturity Level Assessment
3
a. EA Use and Management Plan
b. Guideline Revision
c. Reinforce EA Environment
d. Training/Promotion
e. EA Expertise (Internal Architects)
Table ‎4-6: Examples of EA gradual scoping
3. Development Approach
In Stage 1, the EA Strategy has probably described the development strategy. This is typically a
phased approach such as bottom-up, top-down or mixed. In this stage, the EA Core Team and
other development teams have to review and further discuss the best approach taking into
consideration the changes made to the EA scope. Depending on the actual EA value proposition
or purposes, the following are recommended:

57
S/No
EA Objectives /
Values
Strategy
1 Understanding agency-wide
perspective on issues,
problems, challenges, etc.
Carry out both business and IT landscape studies. This in-
formation are valuable for both business and IT planning
activities, and they are pre-amble to the EA activities.
2 IT Standardization especially
for infrastructure, databases
and applications
Develop the technology Architecture including IT stan-
dards and guidelines as the first major EA deliverable.
3 Tuning and Consolidation of IT
Infrastructure
Develop the Technology Architecture including IT stan-
dards and guidelines as the first major EA deliverable. In
particular, architect for shared and consolidated IT infra-
structure environment. Use Return-on-Investment (ROI)
as a financial justification for the consolidation exercise.
4 Consolidating data elements
and data exchange
Develop the Data / Information Architecture as the main
deliverable. However, need physical solution such as net-
work, databases, storages, etc. Recommended to next
develop the Technology Architecture and then implement
the data consolidation exercise.
5 Application consolidation Develop the Application Architecture. However, need
physical solution such as servers, databases, storages,
etc. Recommended to next develop the Technology Ar-
chitecture and then implement the application consoli-
dation exercise.
6 Business and service improve-
ment, delivery
First, develop the Business Architecture. Document
all the key business processes and services. Develop a
methodology to select business processes and services
for improvements. Recommended to develop the Appli-
cation or Technology Architecture subsequently.
7 Reviewing and improving major
program
Ensure that the program scope is clear. Recommended
to develop the Business Architecture first. The other IT-
related Application, Data and Technology architectures
can start in parallel.
8 Business and IT Alignment and
Investment
Recommended to first develop the Technology Ar-
chitecture. Next, develop the Business Architecture.
If possible, also develop the Application Architecture
(but if this is not possible due to time, then simply lists
the entire application inventory to establish the busi-
ness function and application relationship). Carry out
a gap analysis study and provide recommendations for
improvements.
Table ‎4-7: Development approach recommendations

58
4. Budget
Review, analyze and re-estimate the initial budget from Stage 1. The EA scope affects the overall
development budget. Time and money need to be budgeted properly, since EA practice is ongoing
and variable. Update the EA budget taking the following information for consideration.
Budget
Category
Budget Description
EA Development Budget 1. EA development scope Current Architecture, Target Architecture
development scope Entire/Partial, Organizations/Projects Business/
Application/Data/Technology/Security Reference model development
scope
2. EA tool cost, Software/Hardware cost (It’s possible to do step-by-step
planning and budgeting for the EA development, EA Tool)
EA Management Budget 1. EA management target scope and budget
2. EA reporting or business intelligence tool cost
EA Training And Pro-
motion Budget
1. EA training, workshop budget
2. EA promotion budget
Others 1. External expertise cost, etc.
EA Maintenance Costs 1. EA maintenance
2. EA hardware and software maintenance
3. EA tool maintenance
4. EA reporting or business intelligence tool maintenance
Table ‎4-8: Budget categories for consideration

59
5. Roadmap
A critical review of the milestones or schedule is necessary. The EA Core Team and working
teams have to list and prioritize the expected EA deliverables based on the EA scope. Considerations
affecting the schedule includes alignment to the 2nd Saudi e-Government Action Plan, the
government agency plans and any need for compliance with Saudi Government policies or
projects.
At this stage, appoint a Project Manager so that the EA Transition Roadmap can be prepared
jointly with EA Core Team. From the EA Transition Roadmap, the next step will develop a detailed
Project Plan. Below are examples of EA Transition Roadmap.
Figure ‎4-2: Example of EA transition roadmap

60
6. Usefulness of EA
The final part of the EA development approach is to describe the usefulness of the government
agency’s EA that has to match with the original EA Value Proposition(s). Thus, the EA Core Team
and working teams have to discuss and list the usefulness of EA especially for the different
stakeholders. Table 4-9 describes some of the usefulness of EA.
Usefulness Key Content
Use in IT planning 1. Check project overlapping, reuse, criteria compliance, etc. in the vision of
whole agency
2. Check alignment with agency’s vision, purposes, and target architecture
3. Reflect on IT investment decision and relations.
Use in project
execution
1. Identify work status, IT systems status, target system requirements,
target of reuse, target of shared use, standardization requirements,
etc. and reflect them on business plan, work instruction, etc.
2. IT entrepreneur can analyze work status & IT status by using current ar-
chitecture and, he can perform business by using EA principles, reference
model, target architecture, etc.
Use in IT resource
management
1. Apply EA principles, reference model, standard, etc. to IT resources
management, such as their identification, standardization, reuse,
implementation, disuse, etc.
Use in Business
Process
Re-Engineering
1. EA can identify areas for Business Process Re-Engineering, and to build a
roadmap for automation of those business processes, in such a case the
focus would be more on the Business Domain of EA and less focus on the
other domains.
Table ‎4-9: Description on the EA usefulness

61
Table 4-10 below lists are some common examples of EA usefulness mapped into categories.
Category EA Usefulness Examples
IT & Investment
Planning Alignment
Prioritize IT projects
Ensure no duplication of IT or other projects
Merge EA transition / implementation plan with IT plan
Identify business areas and services for improvements
Budget IT and related projects
Identify areas and projects with high capital and maintenance costs
Information
Alignment
Align business (thru Business Reference Model) with financial systems
Align business (thru Business Reference Model) with knowledge-based and
content management systems (including content on websites and mobile
applications)
Align business and all application systems thru use of standard data
repository and data exchanges (thru Data Reference Model)
Business Improve-
ments
Identify business processes and services that need to meet the stan-
dard performance (defined in Performance Reference Model)
Identify and improve business processes and services (thru Business
Reference Model)
IT Project Planning IT project validity review
Develop IT master or annual plans
Develop IT project plans that are aligned with IT master plan and EA
Transition Roadmap
IT Project Execution Define scope and requirements based on EA information
Design solutions based on target architectures
Program manage various IT projects using EA Management System (EAMS)
Audit Extract audit checklist items from EA information
Prepare for audit with all the enterprise information available in EAMS
IT Evaluation Evaluate IT project deliverables against standards and policies defined
in EA
Post evaluation against EA performance indicators

62
Infrastructure Op-
erations
Check for compliance against technology standards & guidelines
defined in Technology, Data and Application architectures
Capture infrastructure inventories based on definitions in Technology
Architecture
Plan for improvements, migration and technology refresh of hard-
ware and software based on policies and standards defined in EA
Table ‎4-10: Examples of EA usefulness categories
Table 4-11 list examples in the some agencies.
Government
Agency
Use Scope
The Ministry of AAA
• Medium-and long-term IT plan and IT investment plan
• Establish medium-and long-term IT plan & IT investment plan. Re-
view the validity of IT investment plan
• Execute IT business
• IT plan development, business progress and review.
The Ministry of BBB
• Select IT project and IT investment plan
- Business process improvement, IT planning
• Project plan development and contract
- Business planning and entrepreneur selection
• Establish IT system
- IT system development
• Operate IT system and manage the asset
- System operation, IT asset management.
The Ministry of CCC
• IT plan development
• Budget planning and adjustment
• Direction setting for future tech-
nologies
• Decision of how to introduce IT
technology
• Project management
• Infrastructure Implementa-
tion and maintenance
• IT asset management
• IT system operation
• Information protection and
security
• Information recourses sharing
Table ‎4-11: Examples of EA usefulness

63
Present the EA development approach to the EA Governance Committee for approval.
4.4.3 Step 2.3 Document detailed EA project plan
Having obtained the EA Governance Committee’s feedback and approval on the EA develop-
ment approach, the team can start documenting the detailed EA Project Plan that will elabo-
rate on the objectives, scope, schedules, funding and project management details. The previ-
ous outputs, such as the EA development approach, will be use to prepare the EA Project Plan
that will be used to track and monitor the progress of all the key steps and activities in the
development of the government agency’s EA.
Following is an example format for project plan. It is also advisable to prepare the detailed proj-
ect schedule based on Microsoft Project.
1. EA Initiative Overview
A. Background and Rationale
• Specify background and rationale of EA project plan, according to domestic/overseas envi-
ronment changes
• Specify agency’s IT status and EA rationale in order to solve relative issues
• Specify background and rationale of EA project plan in a view of agency’s goals to be
achieved by EA implementation ⋅ development
B. Provision
• Write down service/process’s improvement which can be made by EA after EA implementation
C. Scope
• Specify scope of EA development project
• Specifying EA project’s key contents & EA development scope, since detailed project scope/
contents can be written down in ‘Request for Proposal’
D. Expected outcome
• Write down qualitative, quantitative expected outcomes made after completing EA project
• It is required to present clearly expected outcomes the agency wants to have through the
project since they are related with project’s overall direction.

64
2. Current Status/ Issues
A. Business Status
• Present a work diagram which shows whole work in order to understand agency’s overall
work composition
• Specify task name, task overview/ function, performing group, related agency, etc. which are
included in the project
• Write down a chart of the Vendor which performs the project in the agency
B. IT Status
• Write down as to figure out agency’s overall IT status
• Write down application system’s profile in order to figure out the system’s overall size and
service contents
• Write it down with its basic spec ㅡ hardware(server, disarray), etc. ㅡ in order to figure out
tools’ overall size
• Write down information with which connection status with external systems can be figured out
C. Case Study [Optional Component]
• Describe contents about domestic/ overseas EA project cases
• Describe implications after analyzing domestic/ overseas EA project cases
D. Issues/ Solutions
• Describe issues in terms of agency’s business, data, application, connected technology, IT
management system, etc. by using results of BPR/ ISP, etc.
• Describe issues, limitations, etc. which the agency has when EA implementation/operation
• Describe solutions to solve the issues
3. Project Management
A. Goals/ Directions
• Describe agency’s vision policy goals
• Describe overall EA project goals and specific goals which can be achieved by the project

65
[Example of Project Purposes by an Agency]
Keyword The Ministry
of AAA
The Ministry
of BBB
The Ministry
of CCC
The Ministry
of DDD
The Ministry
of EEE
Common use of Information O O
Interoperability O O
IT System Development O O O
Connection of Work with IT O O O O O
Using as a Innovation Tool O O
EA Implementation Base Devel-
opment
O O
IT Base Development O O O
Standardization O O O
B. Project Strategy
• Describe project strategies suitable to agency’s characteristics
• Describe project strategies as to draw success factors from trial projects and other case stud-
ies and then, perform the project
• Describe whether standard factorsㅡsuch as national EA standard framework, reference
model, standard artifact metamodel, etc. ㅡ is applied or not
• Describe whether technology assessment standards YEFI, NEA Framework, NORA etc. is
observed or not
C. Organization/ Process
• Describe required organizational structure and their roles
• Include CIO, Architecture Committee, Chief Architect, EA Core team, etc. into the agency
• Describe structured EA project planning’s responsibility/ roles
D. Schedule
• Mark project’s total time required, contact period, phase, main events, (beginning and com-
pleting session, workshop, law amendment, the first day of service, public hearing, etc.) etc.
4. Project Description
A. Project Overview
• Explain the project

66
B. Project Details
• Describe detailed project contents by each scope
• Describe detailed project contents by each phase
C. System Development
• Describe a diagram of target system, key functions, and compositions for EAMS development
5. Resources/ Budget
A. Budgeting (long-term)
• Describe total budget made during the project
• Describe how to secure budget
B. Budgeting (for the year)
• Describe required budget based on the year’s project scope
• Describe required budget of the year in detail according to type such as service charge, cost of
system setup, purchase of tools, etc.
• Describe estimation standard and estimated contents in detail
6. EA Use/ Management
A. EA Use
• Describe use plan, such as use purpose, use scope, etc. which are defined to use EA information
B. EA Management
• Describe management system , management purpose, management scope, etc. which are
defined to maintain EA information
Figure ‎4-3: Example format for EA project plan
4.4.4 Step 2.4 Present and obtain approval for the EA project plan
Prepare the presentation slides and review them. It is good to do a presentation to any inter-
ested stakeholders first such as CIO or IT department and a business department for their feed-
back. Finally present and get approval from the EA Governance Committee.

67
Continuous
Governance

68
5. Continuous Governance
5.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 detail 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 address to ensure the success of the project.
The previous stage has defined he 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.
5.2 Outcomes 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.
5.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 the EA governance is a con-
tinuous activity affecting all stages.

69
5.4 Key areas in EA governance
The key areas in EA governance are listed in Table 5-1.
Stage /
Step No
All Continuous Governance Success of Government Agency’s
EA Project
1. Track and monitor the key activities and
deliverables of the EA. Highlight to EA
Governance Committee on potential
delays, changes in scope, and lack of
resources
Program management of Gov-
ernment Agency’s EA implemen-
tation
2. Manage the introduction and changes to
the various activities in the EA. In particular,
carry out activities on EA awareness and
promotion
Change management especially
on awareness and promotion of
Government Agency’s EA
3. Manage the capability requirements for
the EA implementation that includes
training, changes to job scope, and review
of division / department organizational
structures
Capability management on the
progression on the government
agency’s capabilities to carry out
the EA Project plans
4. Manage the policies and regulations re-
quired to implement the different factors
or activities of the EA in the government
agency
Policy management on the poli-
cies and regulations relating to
the EA execution
5. Manage the performance outcomes of
the EA in the government agency
Performance management on
the metrics, KPIs and outcomes
of the EA
Table ‎5-1: Continuous governance steps
As EA affects the whole of the government agency’s functions, and not merely IT, it is vital that
the EA Governance Committee has to carry out its governance functions throughout the EA
lifecycle.

70
The EA governance covers five areas as summarized in Figure 5-1 - program management,
change management, capability management, policy management and performance manage-
ment. 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 gover-
nance areas are describe below.
Figure ‎5-1: Five Aspects of EA governance

71
5.4.1 Program management
The EA will be a continuous journey with dynamic changes affecting different parts of the ar-
chitectures and reference models. The EA also recommends initiatives that require time to de-
velop and fully implemented.
The EA Core team must program manage the EA journey. The following are the key activities:
1. Update the program plan for the main initiatives and projects resulting from the development
phases, in particular the target architectures
2. Brief and propose on what and when to alert the EA Governance Committee for activities and
projects that are delayed, faced complex issues or require additional resources and funding
3. Have a regular meeting (e.g. monthly) to update the EA Governance Committee
4. Have a regular meeting (e.g. weekly) among the Chief Architect, EA Core team and working teams
5. Where possible, to delegate one specialist staff to manage one big program or project such as
change management, capability management, policy management and performance manage-
ment.
5.4.2 Change management
Before EA exists, the government agency has been organizing, planning and executing projects
(both business and IT) in typical manual and reactive fashion. The introduction of EA requires
big changes to the government agency such as organization review, integrated & strategic plan-
ning, and making decisions on e-Government transformation projects in a structured and time-
ly way. Thus, change management is necessary for the success of the EA execution.
Basis for change management
The plans for the long-term change management require approval from the EA Governance
Committee. In addition, constant updates to the EA Governance Committee and even to the
other top management in the government agency is recommended. This is to ensure that top
management or the e-Transformation Committee is aware of the progress and changes to the
EA program.

72
The EA Value Proposition - as part of the EA Strategy - was prepared, presented and approved
by the top management or e-Transformation Committee in Stage 1. The team can use and up-
date this document as the basis for EA change management. In particular, the EA change man-
agement has to address the following:
S/No Stakeholders Why EA?
1 Top Management a. Meet strategic goals
b. Improves IT spending and investments
c. Compliance with Saudi e-Government Action Plan
2 Business Owners a. Improves business efficiency & effectiveness
b. Increases number of e-services
c. Better services to citizens and businesses
3 IT Staff a. Prioritize IT projects
b. Quality IT deliverables
4 Operations Staff a. Improves personal work efficiency
b. Better, integrated work processes
c. Better services to citizens and businesses
Table ‎5-2: Need for EA change management
Scope of change management
The development and updates of the EA artifacts or deliverables are part of change management.
These artifacts have to be produced, reviewed, amended, published, communicated and main-
tained. More importantly, change management covers the awareness of the EA project, and
the promotion of EA as a strategic transformation enabler for the government agency. When all
employees understand about EA – from top management to the operations staff – only then can
EA be a success.
In short, change management has to address three key areas – EA artifacts management, EA
awareness and EA promotion.

73
1. EA Artifacts Management
As early as possible (at least by Stage 4 i.e. develop EA Framework), the EA Core team has to
establish artifacts management processes and standards that will ensure quality deliverables
are documented, updated and approved. The main processes are:
a. Artifact review and approval management process
b. Artifact release management process
c. Artifact change management process
d. Artifact compliance management process.
The EA Core team has to develop minimally the above management processes. Below is an
example of one the processes.
Artifact Review and Approval Management Process
As there will be many artifacts and documents produced in the course of the EA development,
it is necessary to have a standard process to review and approve the various documents. It is
assumed that the government has its own version control process in place (which is not covered
in NORA). Figure 5-2 illustrates an example process for the review and approval of artifacts.

74
Figure ‎5-2: Example of artifact review and approval process
In this example, there are four reviews before the final approval for the artifact or documenta-
tion. Each review starts by checking-out the artifact. The feedback for each review is collected
for amendment. Note that each review may have multiple occurrences. The basic description
of the reviews are as follows:
a. Core team review
Mainly the Chief Architect and the EA Core team members will do the first review. This review is
to ensure accuracy of content and the inter-relationships with other EA artifacts.

75
b.Working team review
The working team members can then review for applicability as they are aware of the specific
requirements and operational implications.
c. External review
The third review is by an external team that may be within the government agency or even oth-
ers. This review is to get inputs from stakeholders.
d. EA governance committee review
Finally, the governance committee will be presented with the artifact for their review and com-
ments.
For each of the four reviews, the EA Core team members have to do the following editorial tasks:
i. From the feedback obtained, update the artifact or document
ii. ‘Scrub’ the artifact or document for basic quality such as grammar & spell check, formatting,
fonts, etc. as defined in the EA documentation standard
iii. Validate the artifact or document to ensure that correctness of basic content including com-
pliance to the EA documentation standard
iv. This is followed by ‘proof read’. This step is to ensure that the content can be understood
v. Finally, the artifact or document is verified to ensure correctness of content and its inter-
relationships with other artifacts
vi. The artifact or document is then check-in.
2. EA Awareness
The need and importance of EA has to be communicated to all the government agency staff, in
particular to the stakeholders identified above. Awareness campaigns such as presentations,
workshops and seminars can be conducted. It is recommended that the EA Core team and
working teams discussed the most effective ways to execute the awareness. The tables below
show examples of how and what content are to be provided in the EA awareness sessions.

76
Awareness Method Target Audience Frequency
Presentation (including updates on
EA Program)
Top Management Quarterly
Presentation IT Management Once
Presentation Business Owners Once
Workshop IT & Business Staff Quarterly
Table ‎5-3: EA awareness methods
Awareness Method
Estimate
Duration
Suggested Content
Presentation (Top Management) 1 hour
i. EA Goals & Objectives
ii. Need for EA in Government
Agency (i.e. benefits)
iii. EA Transition Roadmap
iv. Synergize EA with Strategies and
Investment Decisions
v. Progress Update
Presentation (IT and Business Own-
ers)
2 hours
ii. Need for EA in Government
iii. High Level Current Architecture
iv. High Level Target Architecture
v. EA Transition Roadmap

77
Workshop 1 day
ii. National Enterprise Architecture
(NEA) for Saudi Government
iii. Need for EA in Government
iv. Current Issues & Challenges
v. High Level Current Architecture
vi. Possible Solutions
vii. High Level Target Architecture
viii. EA Transition Roadmap
ix. How Can Staff or Division Contrib-
ute to EA
Table ‎5-4: Suggested content for EA awareness
As EA can only be a success if the government agency starts to think and act strategically, it may
be necessary to conduct additional awareness sessions to specific stakeholders such as the stra-
tegic and finance divisions. These stakeholders are potentially required to conduct integrated
strategic and financial investment decisions of the government agency.
3. EA Promotion
Complementing the awareness program above, the EA has to be promoted so that both man-
agement and operational staff in the government agency can identify the value that EA brings
forth. It is recommended that the EA Core team work with the media or public relations in the
government agency to finalize and implement the promotion. The following are the key steps
for consideration in the EA promotion:

78
Activity Description
Purpose of promotion Identify the actual purpose in the EA promotion. This may
affect the scope and budget of the promotion campaign
Understand how management and
staff receives promotional messages
Analyze the typical behavior when promotional messages
are communicated to management and operational
staff in the government agency. This helps to design the
promotion package
Design promotion key message While there are many goals and benefits of EA, the team
needs to design a short message(s) that the
management and staff can understand
Design the tag line / logo Finally, design the tag line or phrase for the EA. This is
something catchy that can be easily remembered. Also
the team may consider designing a logo or special dia-
gram of the EA
Determine the effective media
for promotion
In addition to online media such as Intranet and email,
the team can consider other options including social me-
dia, videos, physical posters and physical gifts (e.g. mugs,
mouse-pad, and USB thumb-drive). Typically the promo-
tion has a number of these combinations
Produce and promote the EA With the above in place, the team can finally produce the
final EA promotion package
Table ‎5-5: EA promotion activities
It is also highly recommended to conduct an annual EA seminar to disseminate latest progress
updates and show the next projects in the pipeline. Other government agencies can also be
invited to share their success stories.

79
5.4.3 Capability management
Not only does EA requires a big organizational change, but it also requires 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 & automa-
tion, and in integrated planning & decision-making.
Complementing the change management, the capabilities of the government agency can be
classified into the following areas:
1. Enterprise Architecture
Although the Chief Architect, the EA Core team and working teams have completed the EA
development, the EA still requires continuous maintenance and updates. Hence, from a sustain-
ability perspective, the government agency requires sufficient staff trained in EA.
There is a need for specialization in the different areas of EA such as Business Architecture,
Application Architecture, Data Architecture and Technology Architecture. These specialization
requires additional training and learning from other architects.
2. Business Automation (including efficient use of IT devices)
Through EA, there will be proper alignment of business and IT. To see the outcomes of the EA,
however, requires effective business automation.
It is not simply to use IT to replace the manual way. More importantly, it is to review and im-
prove the business processes, and improve the team/division structure that executes these
processes. Capabilities such as ability to operate efficiently mobile devices, business process
re-engineering / improvement and organization reviews are required.

80
3. Integrated Planning
For a more effective planning and decision-making, EA aids the review, planning and managing
the projects in the government agency. The EA target architectures and reference models allow
synergy with the strategies / action plans of the government agency. This should be the focus
when the EA is fully completed (please see Execution Stage).
4. Service-based Outcomes
As Saudi government agencies continuously strive to improve their services to the citizens, busi-
nesses and government employees, it is necessary to deliver service-based outcomes. In other
words, government agencies have to consider what and how the government services can be
implemented that are useful for the public. The target outcomes of EA are objects, components
and services. For example, a government function is supported by application systems based on
a set of re-usable application components; in addition, the government function is made up of
a number of business processes that deliver specific services to the public. Through EA, services
and e-services are readily identified.

81
Table 5-6 summarizes the capabilities required in EA execution.
S/
No
Capability Description Who
1 Enterprise
Architects
To design, architect and implement enter-
prise IT-Business solutions and initiatives
Suggested Trainings:
i. NEA Briefing
ii. TOGAF/FEAF or similar
iii. Visit similar government agency (local or
overseas) to learn EA experiences.
Staff who knows
both IT and Business
2 Business Process
Re-engineering
(BPR)
To review, improve and re-engineer the
efficiency and effectiveness of business
processes
i. BPR or similar
ii. Visit similar government agency (local
or overseas) to learn how they improve
their business processes.
Business Owners,
Business Process
Experts
3 Integrated
Planning
To plan as a government-wide integrated
program (rather than by division or by
resource e.g. IT & finance)
i. Corporate Integrated / Collaborative
Planning or similar.
Strategic Planners,
Enterprise
Architects, Business
Owners,
Corporate Planners
4 Public service
design
To design and implement services that are
needed by the public – i.e. citizens and
businesses. Also to provide outcomes as
services instead of government authorita-
tive requirements
i. Service value
ii. Public service design
Business Owners,
Operational Staff
Table ‎5-6: Capabilities required in EA

82
5.4.4 Policy management
In the development of the EA, the teams would have difficulties to identify things as a standard
or a guideline. While this is normal, the EA execution requires policies and regulations to ensure
a government agency-wide standardization and adoption of the various architectures / refer-
ence models.
For effective governance or management, the EA Core team and working teams have to prepare
and implement the relevant approved policies. It is recommended that these EA policies be
implemented in phases in conjunction with the Change Management Plan. Examples of policy
or regulation areas in EA are:
1. EA Usage Plan
2. EA Management Direction
3. Compliance to Project Approval Process
4. Compliance to Architectures & Reference Models
5. Compliance to Technology Standards.
1. EA Usage Plan
While the EA Core and working teams are busy preparing and developing the EA, the EA Gover-
nance Committee has to set clear directions on the eventual usage of the EA – i.e. when to use
or implement the EA (or parts of the EA) and who will implement the EA (in terms of divisions,
departments and branches).
The table below lists the main activities to identify EA usage plan direction and scenario, while
the subsequent diagram shows examples of EA usage direction. Clear policies or direction state-
ments can be defined and be communicated to all parties in the government agency on the us-
age of EA. The actual development of the detailed EA Usage Plan is typically carry out in Stage 9.

83
S/No Activity Description
1. Identify usage
plan direction
• Identify EA usage cases from the EA best practices and
trends
• Identify EA usage types based on EA requirements and
the result of best practices analysis
2. Identify usage
scenario
• Identify EA usage scenario from best practices and trends
• EA usage scenario can be developed by merging of use
cases and identifying of EA requirements
3. Define EA usage
plan policy or
regulation
• Draft the relevant policies or regulations
• Review and obtain feedback; carry out relevant updates
• Obtain EA Governance Committee approval
Table ‎5-7: Activities to define EA usage plan
Figure ‎5-3: Example for EA usage direction

84
2. EA Management Direction
Although some of the EA requirements were gathered in the early stages of the EA develop-
ment, it is a good governance practice to review and update these requirements. The EA Gov-
ernance Committee has to set clear management directions for both the development of the
EA, and the implementation of the EA. The purpose of this activity is to define EA management
direction by referring to agency’s EA requirements, EA architecture principles, EA usage plan
and the developed artifacts.
Setting the main management directions require comprehensive information from trends
analysis and new technologies including considerations for political and social factors. The EA
Governance Committee has to consider all other governance aspects such as change and per-
formance management, in defining necessary policies or regulations on the EA management
direction. Below are descriptions to define the management direction and examples. Note that
the actual EA management plan will be drafted in Stage 9.
S/
No
1. Identify EA management
plan direction
• Identify EA management plan cases from the EA
best practices and trends
• Identify considerations of EA management plan in EA
principle, purpose, and scope
2. Identify environmental
analysis & requirements
• Identify architecture requirements from IT trends analysis
and agency’s strategy information in environmental analy-
sis results
• Identify architecture development scope by each area
• Identify EAMS operating information
• Identify information which EA management plan needs
to support in EA usage plan development
• Identify the key consideration for EA management plan
3 Define EA management
policy or regulation
• Draft the relevant policies or regulations
• Review and obtain feedback; carry out relevant updates
• Obtain EA Governance Committee approval
Table ‎5-8: Activities to define EA management plan

85
Figure ‎5-4: Example for EA management plan direction
3. Compliance Policies
The EA Core and working teams have to draft relevant policies, regulations or direction state-
ments to ensure that the various parties or divisions in the government agency will use and
comply with EA standards and guidelines. All the policies or direction statements will require
review and approval by the EA Governance Committee. It is also important to ensure that these
policies are clearly communicated to all parties in the government agency.
5.4.5 Performance management
As a strategic enabler, EA provides the ability to define and measure performance of the gov-
ernment 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.
The performance metrics have to be aligned with the Saudi e-Government Action Plan and the
government agency’s strategies and plans. Corporate score cards, national government and
local government indexes can be used to derive the key performance indicators (PKIs). The
performance metrics should also be use in the strategic planning by the government agency. An
example of a performance metric is in Table 5-7.

86
S/No KPIs Target
Not
Performing
Under
Performing
Performing
A Strategic Planning
1 Alignment to Saudi e-Govern-
ment Action Plan
90% Less than
70%
Less than 90% Meet or Exceed
90%
2 Incorporate Government
Agency’s Strategies & Plans
95% Less than
70%
95%
B Drive out Duplications of ICT Investments
3 Improve business processes
(through BPR or reviews)
5 business
processes
0 -2 3 Meet or Exceed
5
4 Use National Shared Applications 2 Applications 0 1 Meet or Exceed
2
5 Share Data with Government
Agencies (Give or Receive)
5 Data
Sources
0 -1 3 or less Meet or Exceed
5
6 Remove or Replace Applications
with Obsolete Technologies
75% Removal
or Replaced
by year XXXX
Less than
50%
75%
C Increase Indirect Value of Government ICT Investments
7 Use National ICT Infrastructure
or Initiatives where possible
4 National ICT
Infrastructure
0 - 2 3 Meet or Exceed
4
8 Use Government Agency-Wide
Application Framework &
Components (promote re-usable
services)
5 Application
Components
0 - 2 3 Meet or Exceed
5
9 Transform manual communica-
tions within and among govern-
ment agencies into electronic
95% Less than
50%
95%
D Contribute to the Establishment of Information Society in KSA
10 Deliver services and information
electronically
95% Less than
50%
95%
11 Transform manual communications
with public into electronic
90% Less than
50%
90%
Table ‎5-9: Performance metrics example

87
Stage3–Analyze
CurrentState

88
6. Stage 3 – Analyze Current State
6.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 activi-
ties in reviewing and analyzing the different aspects of the current state of the government agency.
6.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:
Define the government agency’s EA requirements (mainly from key stakeholders)
Document the government agency’s environment analysis report – both internal and external
analysis
Document the government agency’s current strengths, weaknesses, opportunities and
threats (SWOT).
This stage begins with the endorsement or approval of the EA Project Plan from Stage 2.
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 6-1.

89
Stage /
Step No
3 Analyze Current Stage a. EA Requirements
b. EA Environment Analysis Reports
(Current Business Landscape and
Current IT Landscape)
c. SWOT Analysis Report
3.1 Gather and document EA require-
ments from various stakeholders
such as e-Transformation Commit-
tee, EA Governance Committee,
main business functions’ stakehold-
ers, and EA working teams
Government Agency’s EA requirements
reviewed by EA Governance Committee
3.2 Gather and analyze Government
Agency’s internal environment such
as organizational capability to plan
and execute e-transformation plan,
business plan and IT plan
Government Agency’s EA environment
analysis report reviewed by EA Gover-
nance Committee
Agency’s external environment
such as general trends in EA, United
Nations or similar e-Government
rankings including recommenda-
tions, prioritized national projects
and new government policies
analysis report reviewed by EA
3.4 Present to the EA Governance Com-
mittee
EA Governance Committee is informed
about the detailed current state of the
government agency

90
6.4.1 Step 3.1 Gather and document EA requirements
Like any big and complex project, it is important to get clear requirements. In Stage 1, the EA was
introduced to the government agency and basic requirements or directions were obtained. In this
stage, more detailed requirements have to be gathered from different stakeholders in the govern-
ment agency.
Getting and documenting the EA requirements require a number of activities. The following
progressive set of activities are recommended:
1. Plan the type of information required and from which stakeholders
2. Prepare another round of awareness sessions on EA to the stakeholders including those in
middle management and even operations staff
3. Design a set of questionnaire to capture basic requirements on common problems in the gov-
ernment agency (this output is useful not only for EA but for other organizational and IT im-
provements); this questionnaire can be manual or preferably in electronic version (please see
Table 6-2 for example)
4. Conduct the EA awareness sessions and send out the questionnaire
5. Review and analyze the questionnaire’s responses; and document the main findings
6. From the main findings, the team can start to interview key stakeholders to verify these
findings and to obtain more requirements. Please refer to Table 6-3 for example format of
documenting the stakeholders’ requirements. The recommended stakeholders would be:
a. IT infrastructure team such as network, helpdesk and IT support teams
b. Data teams such as IT DBA and owners of data (if available)
c. IT application development team such as IT Manager and Application Analyst
d. Application and e-service Owners (business staff)
e. CIO and top management.
7. Document the final EA requirements and present to the EA Governance Committee.

91
Question
Areas
Example Questions
Organization a. Is there a clear vision and mission for the government agency?
b. Are staff aware of the government agency’s plans (business, IT, etc.)?
c. Is there a mandate on the goals of e-transformation plan for the gov-
ernment agency from its management?
d. How would they rate the government agency’s capability to manage
influences and factors caused by external factors such as economic
changes, politics, social impacts, environmental demands and technology
innovations?
e. Are there quality standards or key performance indicators defined for
the government agency?
Business
Performance
a. Are the various business functions and business services measured?
b. And are they aligned with the government agency’s quality standards
or KPIs?
c. What are the key issues faced by the business functions?
e. How are business functions’ challenges and problems being ad-
dressed? In particular, how to resolve inter-department or inter-divi-
sion issues?
Application /
Solutions
a. Who decides the need for an application / solution automation?
b. Who budgets or funds for the development of these applications /
solutions?
c. Are there are standards for developing or choosing an application /
solution (including the platform such as mobile, stand-alone, web-
based, etc.)?
d. Are the applications / solutions shared across divisions or departments?
e. Does the government agency access other government agencies’ ap-
plications? If yes, please collect the list of applications / solutions
f. Is there a standard authentication mechanism to access the various
applications / solutions?

92
Data / Information a. Who decides on the ownership of data?
b. Is data or information being shared within the government agency
across the divisions, departments and branches?
c. Are there any data shared with the citizens, business or other government
agencies? If yes, please list the data
d. Are there any data duplications in the government agency?
e. Are there incidents of lost or stolen data?
IT Infrastructure a. Is there a shared network within the government agency?
b. Is there government agency connected to the Saudi Government
Network?
c. Can staff access internet?
d. Are staff given a PC or digital device?
e. Is office automation (email, e-documentation) a common practice in
the government agency?
f. Are there security measures to protect the IT infrastructure?
Table ‎6-2: Example questionnaire
Stakeholders
What
(Data or
Information)
How
(Things to
be done)
Why
(Reason)
Where
(Things to
be done)
Who
(To carry
out)
When
(To carry
out)
Top
Management
Business Owners
Data Owners
Application
Developers
IT Infrastructure
EA Core Team
Table ‎6-3: Example format to gather EA requirements

93
6.4.2 Step 3.2 Analyze internal environment
While the previous step gives the EA working team a very good idea about the EA require-
ments, the team has to also understand where does the government agency stand in terms
of its organization’s EA maturity & capability. Thus, both an internal and external environment
analysis have to be carried out. Start by reviewing the documents prepared in Stage 1 - relevant
EA trends and case studies relating to the government agency, and the government agency’s
e-transformation maturity.
The basic idea of internal environment analysis is to know the maturity level of the government
agency from an internal perspective – both from an organization and IT areas. This information
would help shape the EA outcomes in the next few stages. The outputs from Stage 1 have to be
reviewed and understood. A more detailed analysis is now required as summarized in Table 6-4.
Analysis Area Analysis Measurement Expected Outcomes
Organizational Review Vision and Mission Alignment Identify gaps in mission/vision
& objectives
Business Functions / Tasks Identify gaps or misalignment
of tasks to overall objectives
IT Review Business and IT Alignment Identify gaps or misalignment
of applications to business
IT Standards IT interoperability issues
Table ‎6-4: Internal analysis areas & expected outcomes

94
Organizational Review
In this review, the team has to carry out 2 measurements – vision and mission alignment and
how the business functions or tasks support the overall goals or objectives. For both measure-
ments, the analysis is based on the government agency’s organization chart including its vision,
mission and objective statements. For a start, the team must obtain these latest organizational
information.
1.Vision and Mission Alignment
a. This measurement is to answer the strategic question i.e. are all business units in the govern-
ment agency aligned to its overall vision, mission and objectives?
b. Check and evaluate the vision and mission statements; thus the teams need to really under-
stand what exactly the government agency is set up to do
c. Find out if the various departments or divisions or branches have their own vision and mis-
sion statements; ensure that they are aligned to the main statements. Sometimes, a division
or department embarks on its own set of vision and mission statements that do not align to
the government agency’s main vision and mission statements
d. Analyze how the government agency’s broad objectives are supported by the various de-
partments and divisions. It may be common that these objectives may be directed to more
than one department or division
e. Refer to the government agency’s action plan or roadmap; this would help to understand
and map the activities
f. Document the abnormalities or gaps among the goals and objectives and how they are not
directly mapped to the departments and divisions (if any).
g. Capture ‘Agency E-transformation plan’ and ‘Objectives’ related to agency for the National
Data Gathering as shown in the annex C(NEA Meta-Model)

95
Figure ‎6-1: Example of Vision/Mission alignment with goals and initiatives
2. Business Functions / Tasks
a. This measurement is to answer the strategic question i.e. are all business functions / tasks
clearly defined and executed or are there grey areas and unclear business functions / tasks?
b. Similarly like above, find out how government agency’s objectives and goals are mapped to
the different functions / tasks
c. Please see Figure 6-1 as an example
d. For e.g. Goal 3 would have Strategy 2 and followed by Initiative 3; this initiative has to be
mapped to a business function / task and then to a department or division
e. Document those that are not properly mapped or unclear or with duplicates.

96
IT Review
In this review, the team has to carry out two measurements – business and IT alignment, and
the IT standards. It would be good if the government agency can document its IT landscape
(i.e. a detailed description and inventories of all the IT-related assets, systems. applications and
data). Other useful sources of information include IT Portfolio if available. If none of these are
available, the IT teams have to use whatever inventories they have. For a start, please carry
out an update on all the IT inventory to get the latest information. The following figures are
examples of the IT review outcomes.
1. Business and IT Alignment
a. This measurement is to answer the strategic question i.e. are the core business functions of
the government agency effective and being supported by IT automation?
b. Review the IT Plan of the government agency; for each major IT project or application sys-
tem, analyze to see if it supports a business function or task
c. Similarly review the data used in the government agency; for each data entity type (for e.g.
Citizen, Employment and Government Agency), check how the business functions and tasks
utilize it – either Read, Write, Update or None at all. Also check for data duplications
d. Another perspective is to sort all the IT systems and data by the various business functions;
from here, it is easy to analyze which business functions have the highest rate of IT adoption
e. Document these findings and analysis.
f. Capture the IT Project related information for National Data Gathering as shown in the annex
C(NEA Meta-Model).

97
Division Name/Department Name
Systems
Independently
Implemented &
Operated
Separate information
systems,..etc
Data Duplication
Clients information
duplications,
Services information
discrepancies across
divisions,.. etc
Government
Dynamic Directions
New services
Requested,..etc
Duplicated
Information
Complicated
Linkage
Structure
DB1
CRM Purchasing Inventory
DB2DB2
Division Name/Application Owner
Purchasing System
Inventory System
Correspondence System
Duplication Examples
Date Set A
Date Set B
Date Set B
Date Set B
Date Set B
Date Set B
Date Set B
IT Status -Core Issues & Problems
Figure ‎6-2: Example of business and IT alignment

98
Figure ‎6-3: Example of major IT systems supporting government functions

99
Figure ‎6-4: Example of IT systems supporting government functions by business areas
2. IT Standards
a. This measurement is to answer the strategic question i.e. how pervasive is the use of IT in
the government agency, and does the IT adoption comply with specific standards?
b. The teams have to analyze a few key IT areas such as infrastructure, data, applications and
e-services
c. For infrastructure, areas of measurement include network penetration (i.e. how much net-
work has been installed in the government agency, and the network utilization), IT devices
adoption rate, maturity of data center, and servers & storage
d. Database standards, data definitions and data exchange methods are to be analyzed
e. For applications, the teams have to review the application development standards, application
platform standards, application testing and deployment to name a few
f. Last but not least, review the standards used to design, develop and deploy e-services (not
that the measurement of e-services maturity can be obtained from Yesser)
g. Consolidate and document the IT Standards measurements.

100
6.4.3 Step 3.3 Analyze external environment
External environment analysis is to gauge the external factors that influence the government
agency. It also allows comparison between a government agency and other similar agencies.
This information would help shape the EA outcomes in the next stages. The outputs from Stage
1 – EA Trends and case studies - have to be reviewed and understood.
View external environment analysis from two perspectives – external factors and external
scope.
Examples of external factors include political, economic, social, technology and nature/environ-
ment. These factors cause multiple impacts to the government agency. An example of an exter-
nal scope is the region for analysis such as within the city (e.g. Riyadh), or country (e.g. KSA),
or region (e.g. GCC) or globally. Different external scope of perspectives would have different
impact to the government agency.
The following are the key activities of external environment analysis:
1. Based on the stakeholders’ requirements from previous step, determine the external scope of
coverage – i.e. to determine if the analysis is only within the country or regionally for example
2. From the initial findings in Stage 1, determine the additional scope required; ensure that a rea-
sonable scope of analysis can be carried out (and better to narrow the scope initially)
3. Carry out a SWOT analysis (Strengths, Weaknesses, Opportunities and Threats)
4. Compare some of the SWOT analysis with other external reports like United Nations, and direct
comparisons with government agency in another country or region
5. Document the SWOT findings and comparisons into the external environment analysis report.

101
Table 6-5 is an example of a SWOT Chart Template.
SWOT Chart Template
• Strengths:
• What the government agency does well in?
• What unique resources and capabilities can
the government agency draw on?
• What advantages does the government
agency have?
• What do citizens and businesses see as the
government agency’s strengths?
• Weaknesses
• What could the government agency
improve on?
• What should the government agency
avoid?
• What do citizens and businesses see as
the government agency’s weaknesses?
• Opportunities
• What promising options are open to the
government agency?
• What are the interesting trends the govern-
ment agency is aware o government f?
• How can the government agency convert its
strengths into opportunities?
• Threats
• What obstacles does the government
agency face?
• What trends could hinder the govern-
ment agency?
• What are other government agencies
doing?
• Are the required specifications for the
services provided by the government
agency changing?
• Is changing technology threatening the
government agency?
• Could any your weaknesses seriously
threaten the operation of the govern-
ment agency?
Table ‎6-5: SWOT chart template
At the end of this stage, the EA requirements together with the environment analysis reports
would help the EA Core team to understand how the government agency’s EA can help to resolve
these issues and meet the requirements.

102
6.4.4 Step 3.4 Present current state analysis
Present these findings of the government agency’s current state to the EA Governance Committee for
information and comment. Through this presentation, the governance committee is aware of the
current challenges, issues, threats and even possible opportunities. From their collective wisdom,
the EA Governance Committee can provide strategic directions for subsequent EA development.
If required, the EA Governance Committee may also want these findings to be presented to the
e-Transformation Committee or equivalent.

103
Stage4–Develop
EAFramework

104
7. Stage 4 – Develop EA
Framework
7.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 is fundamental to its EA journey. The gov-
ernment agency should focus on building quality EA framework and other relevant processes.
If I had 8 hours to chop down a tree, I’d spend 6 hours sharpening my axe “
~ Abraham Lincoln
7.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 subse-
quent 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 EA artifact review and approval process
4. Create the government agency’s EA Framework.

105
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.
Stage 4 focuses on high level architecture activities that require experience and vision. The key
steps in Stage 4 are listed in Table 7-1.
Stage /
Step No
4 Develop EA Framework 1. Government Agency’s EA Mission,
Vision, Architecture Objectives and
Architecture Principle Statements
2. Government Agency’s EA Framework
4.1 Define EA’s vision and mission state-
ments, & architecture objectives
Draft EA Vision, Mission, , and
architecture objectives
4.2 Define EA’s architecture principles Draft EA Principles
4.3 Present and obtain approval for EA vi-
sion, mission and architecture objectives
Approved EA Vision, Mission, Architecture
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
4.8 Develop EA artifacts management
processes
Draft EA Artifact management processes
4.9 Present and obtain approval for EA
framework
Approved EA Framework

106
7.4.1 Step 4.1 Define EA’s vision and mission
statements, & architecture objectives
The EA Core team should work on developing an EA vision and mission that represents the
government agency’s primary EA purpose and value. The vision and mission should be followed
and articulated by the EA’s future roles & directions for successful EA establishment / usage. It
should also be clearly understood to the government agency’s stakeholders and they can grasp
its definition at a glance.
The EA vision should be a long-term statement about what the EA is, and why it is an important
future outcome for the government agency. The EA mission statement, on the other hand,
describes at a high level, about how the EA can be a vital asset for the government agency.
Both these statements should be short and simple. Below are some examples of vision statement.
Figure ‎7-1: Example of a Vision statement

107
The following activities are recommended for the EA Vision and Mission statement development:
1. From the EA requirements and environment analysis reports, shortlist key words that help to
shape the future EA. Examples are words such as performance-driven, agile government, effec-
tive decision making, business-IT alignment, IT investments, and citizen-centric services
2. Review the government agency’s vision and mission statements, and extract key words that
affect the EA development
3. Check for the IT vision and mission statements (if any). If available, extract key words that
match with the shortlisted key words above
4. Consolidate all the key words for the vision and mission statements
5. Conduct a brainstorming session among the EA Governance Committee and EA working
teams to define the vision and mission statements
6. Define the architecture objectives of the EA based on the vision and mission statements
7. The team may also want to get feedback from other stakeholders such as specific business
divisions and even the top management. Update these statements from their feedback
8. Table 7-2 is a guideline on the considerations for effective vision and mission statements.

108
Area Consideration
Understandability
• A vision and mission statement should be clearly understood and
promptly captured by EA stakeholders
• Definitions and use of certain terms within the agency can increase
understandability
Solidity
• Consider the missions, values, and directions that the current government
and e-Government program are pursuing
• An EA vision / mission statement that is linked to agency’s established
values can easily convince internal EA stakeholders
Consensus
• An EA vision / mission statement should be created based on all stake-
holders’ consensus and awareness
• An EA vision / mission should be agreed upon and recognized within
an agency to be successful
Alignment
• All architectural areas should be aligned with a given EA vision because
EA vision is a guide that directs other elements such as EA purposes,
principles, and framework. This makes an EA consistent and unified
Usability
• EA vision / mission should be connected to agency’s business purposes
in order for EA to be used in various business processes
• Consider how to realize EA vision / mission in each area of an agency
(Organization, H/R, Businesses, etc), and adjust EA management and
evaluation process
Table ‎7-2: Considerations for effective Vision & Mission statements

109
7.4.2 Step 4.2 Define EA’s architecture principles
With the government agency’s vision, mission and architecture objectives defined, the next
activity is for the EA Core team to rationalize the architecture principles. While this may sound
easy, the definition of these principles should be deeply analyzed and reviewed as it affects
the EA development. Architecture principles are statements about high level rules and strict
guidelines to shape and steer the development and maintenance of the government agency’s
EA. These principles would aid decision making and even architecture designs of the various
components in the EA. More importantly, these architecture principles reflect a level of con-
sensus on how architecture elements should be abstracted, integrated and used to develop the
future or target architectures, and eventually how stakeholders can appreciate the values or
outcomes of EA.
Table 7-3 are some recommended criteria for the development of good or acceptable architec-
ture principles.
Criteria Description
Easy to Understand The architecture principle should be easy to understand by any person
Completeness The architecture principle should be comprehensive in coverage.
Typically it would cover both IT and business aspects
Consistency The architecture principle should be applied to consistently to all
aspects of EA development. It should consistent in its application
to all architectures or reference models
Robust The architecture principle should be robust to changing environ-
ments and circumstances. While there are constant changes like
politics, technologies and social demands, the architecture prin-
ciple should be able to endure these factors and continue to be
relevant
Table ‎7-3: Criteria examples of good architecture principles

110
Figure 7-2 illustrates how EA principles are derived from the EA purpose or value proposition
statements.
Figure ‎7-2: Example of EA architecture principles
The following are the recommended factors for consideration in developing the EA architecture
principles:
1. The EA vision and mission statements, and the architecture objectives should drive the
architecture principles
2. Alternatively, the EA purpose or value-proposition statements can also be used to derive the
architecture principles
3. Refer to other EA frameworks as examples; also refer to NEA architecture principles
4. Brainstorm for the relevant EA architecture principles to aid the EA development and main-
tenance. The Enterprise Architect should lead the session
5. Prioritize and document these principles; preferably not more than seven principles.

111
7.4.3 Step 4.3 Present and obtain approval for EA vision, mission and ar-
chitecture objectives
Present the EA vision and mission statements, architecture objectives and architecture principles
to the EA Governance Committee. As these are very high-level statements, expect comments
from the committee and the need to enhance them to get a final approval.
7.4.4 Step 4.4 Define EA Framework structure
The next step is to define an EA Framework structure that outlines the overall ‘look’ of the EA. It
describes the boundaries of the EA for the government agency based on the vision and mission
statements, architecture objectives and architecture principles that shape the development of
the EA. An EA Framework is a structure used for organizing EA elements and their relationships.
The EA Framework is used to design and develop the actual government agency’s EA and other
reference models.
The key activities to develop an EA Framework structure are:
1. Analyze the related trends and case studies for EA for similar government line of business
or function (see Table 7-4 as an example). This could be both external and local government
agencies. Look at their EA frameworks or conceptual architecture diagrams
2. Also refer to NEA and other government agencies’ EA frameworks
3. Analyze each component in the example EA frameworks and take the relevant components
4. Design the high level based on the need to have the relevant components
5. Review and enhance the EA Framework (this is an iterative process).

112
Research Item Description
National EA Frame-
work Standard
Provide frameworks and guidelines required for EA development by
identifying, organizing national EA framework elements and setting
relationships between them
EA Demonstration
Project
Agencies’ EA demonstration projects for EA implementation
(Ministry of Information and Communication, Ministry of Govern-
ment Administration and Home Affairs, Public Procurement Service,
Ministry of Maritime Affairs and Fisheries)
Overseas Case
Overseas framework cases
(FEAF: established and construct reference models according to
OMB guideline
TEAF: define elements such as architecture framework, governance,
process, etc.
DOI: the U. S. interior department’s framework)
Table ‎7-4: Examples of research areas for EA Framework
Figure 7-3 is an example of an EA Framework structure. Government agencies need not follow all
of the architectures in the example but the relevant ones to meet the overall EA strategy. Some
of the architectures in the example can be added (for example Service Architecture and Process
Architecture) or can be replaced (such as Information Architecture instead of Data Architecture).

113
Figure ‎7-3: EA Framework structure example
7.4.5 Step 4.5 Design EA architecture elements
With the high level EA Framework structure, the EA Core team can start identifying and defin-
ing architecture elements within each architecture boundary. By referring to other related EAs,
the EA Core team can make logical relationships and deductions. As the EA Framework has also
already established a “Big Box”, this step is to fill the elements within each architecture. These
elements will also be the main artifacts – i.e. documents that are created, designed and main-
tained as part of EA.
The recommended architecture elements are listed below in Table 7-5. The EA Core team can
add or remove these elements on a need basis. For each of the following elements, the EA Core
team lead by the Chief Architect have to rationalize and describe the architecture elements.
Note that this is an iterative process and requires a series of brainstorming and review sessions.

114
S/
No
Element or Artifact Definition
1 Principles Describe the architecture principles of the
particular architecture; it has to have more
than 1 principle
2 Architecture Element Describe the relevant architecture elements
of the particular architecture; it can 1 or
more elements
3 Rules and Standards Describe the important rules and standards
in developing the architecture; it supports
the principles established above
4 Components Describe the components that are related to
the architecture elements; typically one archi-
tecture element has one or more components
5 Domains Describe the area or scope of architecture
implication; typically related to technology
domains, each architecture may have 0, 1
or more domains
6 Patterns Describe or illustrate, normally in diagrams,
the main architecture patterns that is useful to
further develop the actual reference model;
typically each architecture has at least one
pattern
7 Building Blocks Describe how the relevant elements can be
pieced together; it shows the dependency if any
Table ‎7-5: Description of EA elements
7.4.6 Step 4.6 Design EA model
Having designed the high level EA Framework structure and its architecture elements, the EA
Core team has to design the EA Model that is express as a matrix classifying all resources from
different views or perspectives. For now, the EA Model is a high-level classification of views and
key architectural elements. Subsequently in the EA development, the EA Core team will use this
model to develop further detailed reference models.
The purpose of the EA Model definition is to establish current / target architecture and a basic
system for the management and application of the EA.

115
S/No Task Method Deliverable
1. Define architecture
model’s view and
perspective for
registering, using,
managing EA
information
a. Perspective definition
b. Perspective or viewpoint is divided
by a role of EA stakeholders such as
CEO, CIO, IT Manager, Architect and
IT Developer or Vendor
c. Perspective classifies agency’s
decision-makings with a hierarchical
structure and defines the stages by a
decision-making characteristic
d. Perspective is defined by roles, not
by level or positionAt first, define
Perspective by using typical clas-
sification, and adjust categories or
vocabularies to fit agency’s needs.
EA Model by Stake-
holder (see Table
7-7)
2. Define architec-
ture model’s view
and perspective
from stakehold-
ers’ functional
responsibilities
a. View definition
b. View is a standard for observing
architecture’s specific parts. In other
word, as to figure out an identical ar-
chitecture and, it’s divided by a type
of architectural resources
c. View is largely divided into busi-
ness and technology. While the
business is divided into organiza-
tion, functions, and projects, the
technology is divided into data,
application, security, etc.
d. In general, one view is taken by a
business, and several views are
taken by technology components
such as data, application, technol-
ogy, and security
e. National EA framework standard
suggests five types of architecture
information ㅡ business, data, ap-
plication, technology and security.
EA Model by Archi-
tecture (see Table
7-8)

116
3. Define Artifacts
Meta-Model
a. Define all the key elements or
artifacts
b. Define the attributes of these ele-
ments or artifacts
c. Define relationships among ele-
ments or artifacts
d. Please refer to NEA Meta-Model
Draft EA Frame-
work with Artifacts
Meta-Model
4. Define Artifacts’
Elements
a. Define the actual elements and arti-
facts
b. Define the actual attributes
c. Define the actual relationships among
the elements or artifacts
Draft EA Frame-
work with Artifacts
and Elements Defi-
nitions
Table ‎7-6: Activities to develop the EA Model
Who Business Application Data Technology Security
CEO/CIO Deal with strategy, plan, overall process, key information, main infrastructure,
organizational chart
IT Manager Deal with business process, information, IT infrastructure
Architect Deal with logical business process design, logical information model, component/
application design, system dispersion/ deployment
IT Developer / Vendor Deal with integration and tests with considering limitations to tools, technology,
and resources
Table ‎7-7: EA Model view by stakeholders
Who Business Application Data Technology Security
CEO/CIO Human
resources,
goods, places
and incidents
Business func-
tions, process and
activities
All necessary
information and
its relationships
Hardware,
software and
network
Secu-
rity policy or
structure
IT Manager
Architect
IT Developer
/ Vendor
Table ‎7-8: EA Model view by architecture

117
General Recommendations for DefiningViews and Artifacts
Make an architecture model best fitted with the government agency’s characteristics. Suggest
a list of documents and formats that each business / IT management department manage, and
use them.
In general, artifacts are constructed with a figure type or a description type. In case there are
figure type artifacts, check if description type artifacts are needed, and vice versa. Clearly define
artifacts with questions such as:
1. Are specific use purposes for each artifact defined?
2. What do artifacts establish?
3. Why is the artifact required?
The following are recommended activities for defining Meta-Model Artifacts:
3. Elements definition
a. Artifacts meta-model elements define each element for registering and managing artifacts
b. Deduce elements based on agency’s EA Usage planning
c. Deduce elements based on agency’s EA development purposes
d. Deduce elements best fitted with agency’s EA requirements
e. It’s advisable to delete easily changeable information from elements
f. Define elements by referring to ‘National EA Artifact Meta-model Definition’
g. The agency should define compulsory items in ‘National EA Artifact Meta-model Definition’.
If not, the agency should do a mapping with the national EA items for government’s utiliza-
tion. Among the architecture information, consider the mandatory items of mandatory
artifacts that should be offered to national EA support system.

118
3.Attributes definition
a. Define each element’ attributes
b. Since they can be basic information of understanding elements, all required attributes
should be deduced for EA use
c. It’s advisable to delete easily changeable information from attributes.
4. Define a relationship between elements
a. Set a relationship by figuring out correlation between elements
b. The relationship should be defined correctly since it can be a foundation of understanding
the relationship with other elements during artifacts registration / use.
The following are activities to define the artifacts / elements and their actual attributes:
1.Artifacts definition
i. With reference to EA purpose/ use, define required artifacts for using business/ IT information
by each view and perspective
ii. Define them by following mandatory artifacts suggested in ‘National EA Artifact Meta-mod-
el Definition’ in order to be offered to national EA support system
iii. Define the artifact’s elements according to its definition and purposes
iv. According to artifacts definition, agency’s artifacts definition, including artifacts definition,
purpose, description, templet, example, meta-model, etc., is written
v. Can use artifacts naming method to keep their consistency
vi. In case required elements for each artifact are same, they can be integrated, defined as
one element
vii. Write agency’s artifacts definition with reference to National EA Artifact Meta-model
Definition’.

119
2. Define a relationship between artifacts
a. Can define a relationship between artifacts by figuring out their attributes
b. Identify the relationship by defining the relationship between elements
c. Check how artifacts are aligned, especially between business and IT
d. Through this step, can Identify missing or necessary relationships between elements and
add them.
7.4.7 Step 4.7 Develop EA documentation standard
To complete the whole EA Framework, it is a good practice to develop an EA Documentation
Standard. The objective is to ensure consistent quality in the production and maintenance of
EA artifacts and documents.
The following steps are recommended:
1. Adopt the government agency’s standard documentation template; if this is not available,
then create one
2. Standardize on the written format such as page size, fonts, table-of-content, header & footer
and paragraphing (e.g. 1.5 line of space, full-justified)
3. Standardize on EA and government agency’s terms and terminologies; Table 7-9 below is an
example of Yesser’s documentation standard for terms
4. Standardize on the choice of tool to produce diagrams and figures (as EA will produce many
diagrams) such as Visio
5. Standardize on the process for creating, updating, versioning, reviewing and approving these
artifacts and documents.

120
S/No Yesser Standard
Terms
Comment
1 e-Government Program (Yes-
ser)
Use the full terms for first definition in the documentation;
subsequently use ‘Yesser’
2 e-Government Describes general e-Government
3 e-service Describes general e-service
4 The 2nd
e-Government Action
Plan
The name of the current action plan for 2013-2017
5 e-transformation Describes the general transformation route from a traditional
government into an electronic government
6 YeFI Yesser Framework For Interoperability
7 e-Government National Portal The initiative for one standard government national portal
8 e-Government Data Center The initiative for a central government data center
9 Government Secure Network
(GSN)
The initiative for one government secure network
10 Government Service Bus (GSB) The initiative for government to exchange data and information
11 National Center for Digital
Certification
The initiative to implement national Pubic Key Infrastructure
(PKI)
12 Single Sign-On (SSO) The initiative to implement one standard authentication mech-
anism to access government services
13 SADAD Payment System (SA-
DAD in short)
The initiative to implement standard national billing and
payment system
14 e-Channel(s) Describes the method of interaction between service pro-
vider and consumer (e.g. Web, Mobile Application and Kiosk)
15 e-Training Describes interactive online training delivery
16 government agency Refers to the general government ministries, authorities,
boards, councils, etc.
Table ‎7-9: Example of Yesser’s standard terms

121
7.4.8 Step 4.8 Develop EA artifacts management processes
As there will be many artifacts and documents produced in the course of the EA development,
it is necessary to have a standard management process to review and approve the various
documents. Please refer to the section Continuous Governance – where the artifact process
management are describe as part of the EA overall change management – for more details.
The team needs to develop all the relevant artifacts management processes.
7.4.9 Step 4.9 Present and obtain approval for EA framework
With the completion of the EA Framework 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.

122
AboutReference
Models&Architectures

123
8. About Reference Models &
Architectures
8.1 Need for clarity
In the next few stages, the government agency will build reference models and architectures.
However, before building them, it is important to understand the differences among the vari-
ous reference models, current and target architectures. The EA Core team and working team
members have be clear about these deliverables and their respective objectives or purposes.
In addition, it would help to understand the relationships among these different deliverables.
8.2 Definitions
The following are the main definitions:
1. Reference Model
From The Open Group Architecture Foundation (TOGAF):
“A reference model is an abstract framework for understanding significant relationships among
the entities of [an] environment, and for the development of consistent standards or specifica-
tions supporting that environment. A reference model is based on a small number of unifying
concepts and may be used as a basis for education and explaining standards to a non-specialist.”
A reference model specifies standard classification and definition of common components used
for developing EA. EA reference model defines a set of standard representations and specifica-
tions to be use for developing EA, ensuring consistency, uniformity, and interoperability with
reference to NEA reference model.
In short, a reference model is use to describe, show and explain in general terms the main archi-
tectural elements or components so that different stakeholders can reference it to understand
and make relevant decisions that apply to their local context.

124
There are two main reference models in EA – NEA Reference Model and Government Agency
Reference Model.
2.Architecture
TOGAF defines an architecture as follows:
a A formal description of a system, or a detailed plan of the system at component level, to
guide its implementation (source: ISO/IEC 42010:2007).
b. The structure of components, their inter-relationships, and the principles and guidelines
governing their design and evolution over time.
In EA, the architecture describes the relevant elements or components from the reference
model, and further designs the details based on available data and circumstances to meet the
architectural objectives.
3. Difference between Reference Model and Architecture
One analogy is like city planning. The National Enterprise Architecture (NEA) reference model
describes the overall city plan. By referencing it, each government agency will know which part
of the city and what buildings it need to build. The government agency can then develop its own
specific building reference model where it will give more details to the building designs.
From its reference model, the government agency can architecture its current buildings (with more
details like office layout, gardens, parking areas, security offices, masjid and reception office). On
the other hand, the target architecture will show how the buildings will be transform in the future
with the respective details.
Table 8-1 provides the respective descriptions of the various reference models and architectures.

125
S/No EA Artifact Description
1. NEA Reference Model Saudi government-wide reference model for all
government agencies. It gives the consolidated
government-wide model of the key IT and business
objects and their relationships.
2. Agency Reference Model Specific view of the NEA Reference Model for the
government agency only. It provides the government
agency’s model of its IT and business objects in relation
to the NEA Reference Model.
3. Agency Current Architecture Description and design of the current IT and business
landscape. It shows all the actual current IT, business
objects, and their relationships.
4. Agency Target Architecture Description and design of the target or future IT and
business landscapes. It shows all the future IT and
business objects and their relationships after changes
made to the current architecture (i.e. additions, dele-
tions and modifications of the current IT and business
objects).
Table ‎8-1: Differences between Reference Models and Architectures
8.3 Process to build reference models and architectures
In the next few stages, the government agency will build reference model and architectures in
succession. This section, however, aims to provide a comprehensive view about the building
process and the inter-relationships among these deliverables.
The basic process to develop these deliverables are as follows:
1. Build agency reference models
By referring to the NEA reference models, the government agency has to build its own reference
models. The objective is to analyze from the whole-of-government models, take the appropriate
and relevant context, and build the required architecture elements for the government agency.

126
2. Build current architectures
From the government agency’s reference models, the EA Core and working teams have to gather
information to reflect the current state of the IT and business landscapes. The outcomes will
describe the government agency’s relevant current architectures. In addition, the government
agency has to analyze and plan for improvements or ways to overcome current challenges and
limitations.
3. Build target architectures
The government agency has to develop target outcomes or goals that will drive the design of
the future target architectures.
Figure 8-1 summarizes the basic process in building these reference models and architectures.
Figure ‎8-1: Basic process in building reference models and architectures

127
8.4 Building blocks of reference models and architectures
The building blocks or components for NEA reference models, agency reference models
and architectures are similar. Figure 8-2 illustrates the main components in each model or
architecture. The EA Framework developed in the previous stage would also be similar in
terms of the components.
Figure ‎8-2: Building blocks / components
Each model or architecture would minimally describe the following:
1. Purpose & Direction
The purpose statement describes what the model or architecture does. It is specific and normally
measurable. The direction statement describes the main delivery focus; it affects the scope of the
model or architecture.
2. Principles
These are architectural principles for the model or architecture development. Each principle pro-
vides specific scope and reason the development of the model or architecture. As a guideline,
the number of principles should not exceed seven.

128
3.Artifacts
These are actual deliverables or outcomes of the model or architecture. The artifact name has
to match with the definitions and names in the EA Meta Model. The number of artifacts com-
monly range from 4 to 10 in each model or architecture.
NEA consists of five reference models as shown in the figure below. Each model has the same
building blocks or components. Government agencies have to apply the same building blocks or
components in developing their own reference models and architectures in the next few stages.
Figure ‎8-3: Same building blocks in NEA reference models

129
8.5 Summary of deliverables for reference models and
architectures
The table below lists the important deliverables or artifacts to be produce in the government
agencies’ reference models and architectures.
Domain
NEA Reference
Model Artifacts
Agency Reference
Model Artifacts
Agency Current Ar-
chitecture Artifacts
Agency Target Ar-
chitecture
Artifacts
Performance Performance Reference
Model
Comprising of:
1. Purpose / Direction
2. PRM Principles
3. Strategic Goals
4. Performance Goals
5. Measurement Areas
6. Measurement Cat-
egories
7. Measurement
Groups
8. Indicators
Performance Reference
Model
1. Comprising of:
3. PRM Principles
4. Strategic Goals
5. Performance Goals
6. Measurement Areas
7. Measurement Cat-
egories
8. Measurement Groups
9. Indicators
N.A. N.A,
The performance
measurement indicators
will be embedded in the
various target architec-
tures
Business Business Reference
Model
Comprising of:
2. BRM Principles
3. Business Area
4. Line of Business
(LoB)
5. Business Function
Business Reference
Model
Comprising of:
2. BRM Principles
3. Business Area
4. Line of Business (LoB)
6. Sub-Business Function
Purpose / Direction
1. BA Principles
2. Agency BRM
3. Organizational Chart
5. Business Processes
6. Service Catalogue
Purpose / Direction
1. BA Principles
2. (reviewed / updated)
3. Organizational Chart
(reviewed / updated)
5. Business Processes
(improved)
6. Service Catalogue
(updated)

130
Domain
NEA Reference
Model Artifacts
Agency Reference
Model Artifacts
Agency Current Ar-
Agency Target Ar-
chitecture
Artifacts
Application Application Reference
Model
Comprising of:
2. ARM Principles
3. Application Sys-
tems
4. Application Com-
ponents
5. Application Inter-
faces
6. Best Practices and
Guidelines
7. Application
Systems for Saudi
Government
8. List of National
Shared Application
Systems
Application Reference
Model
Comprising of:
2. ARM Principles
3. Application Systems
4. Application Compo-
nents
5. Application Interfaces
6. Prioritized List of Ap-
plication Systems
Purpose / Direction
AA Principles
Agency ARM
Application Overview
Application Catalogue
Application Functions
Application Relationships
Application Consolidation
Plan (optional)
Purpose / Direction
AA Principles
(updated)
(updated)
Application Functions
(updated)
Application Relation-
ships (updated)
List of Agency Shared
Application Systems
and Components
(optional)
Data Data Reference Model
Comprising of:
Purpose / Direction
DRM Principles
National Data Model
Data Classification
Data Structure
Data Exchange
Data Management
List of National Shared
Data Services
Data Reference Model
Comprising of:
Purpose / Direction
DRM Principles
Conceptual Data Model
Data Classification
Data Structure
Data Exchange
Data Management
Purpose / Direction
DA Principles
Agency ARM
Logical Data Model
Data Flow Diagram
Database Portfolio Cata-
logue
Data dictionary
Data Consolidation Plan
(optional)
Purpose / Direction
DA Principles (re-
viewed / updated)
(updated)
Data Management
(updated)
Logical Data Model
(updated)
Data Flow Diagram
(updated)
Database Portfolio Cata-
logue (updated)
Data dictionary (up-
dated)
Data Services (optional)

131
Domain
NEA Reference
Model Artifacts
Agency Reference
Model Artifacts
Agency Current Ar-
Agency Target Ar-
chitecture
Artifacts
Technology Technology Reference
Model
Comprising of:
Purpose / Direction
TRM Principles
Service Area
Service Category
Service Standards
Technology Reference
Model
Comprising of:
Purpose / Direction
TRM Principles
Service Area
Service Category
Service Standards
Purpose / Direction
TA Principles
Agency TRM
IT Infrastructure Overview
IT Infrastructure Descrip-
tion
Hardware Catalogue
Software Catalogue
Purpose / Direction
TA Principles (re-
viewed / updated)
IT Infrastructure Over-
view (updated)
IT Infrastructure
Description (updated)
Hardware Catalogue
Software Catalogue
Infrastructure Services
(optional)
Table ‎8-2: Summary of artifacts by reference models and architectures

132
Stage5–Build
ReferenceModels

133
9. Stage 5 – Build Reference
Models
9.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.
9.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.
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 Yesser’s NEA
Reference Models. By referring to the NEA reference models, the government agency can de-
velop their own reference models ensuring alignment with whole of government as well as to
achieve its EA goals.

134
9.4 About NEA reference models
Since the government agencies have to refer to NEA reference models, it is a pre-requisite to
understand all the 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 informa-
tion and design for their own use.
Figure 9-1 illustrates the NEA reference models and their inter-relationships.
Figure ‎9-1: NEA reference models and their inter-relationships

135
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 of Saudi government. It gives a logical functional view instead
of functions by physical government agencies. The functions and requirements in BRM drives
the other reference models, i.e. Application Reference Model, Data Reference Model and Tech-
nology Reference Model.
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 the 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 the 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 define to promote inter-operability among govern-
ment agencies. The TRM supports the data usage in DRM, supports application systems in ARM
through the technology definitions and infrastructure implementations, and supports the agen-
cy staff through use of personal and office technologies.
Please refer to the actual NEA reference models for details.

136
Stage 5 is all about building the relevant reference models. Table 9-1 lists all the key steps in Stage 5.
Stage
/ Step
No
5 Document Government Agency’s Reference Models Government Agency’s Reference
Models
5.1 Develop a model that standardizes performance
elements for improving IT projects and their
quality. Obtain approval from the EA Governance
Committee
Approved Performance Reference
Model
5.2 Develop a model that classifies and defines busi-
ness functions and related information. Obtain
approval from the EA Governance Committee
Approved Business Reference
Model
5.3 Develop a model that classifies and defines
shared application systems/components to pro-
mote service integration and reuse by identifying
redundant or correlated applications. Obtain ap-
proval from the EA Governance Committee
Approved Application Reference
Model
5.4 Develop a model that classifies data and defines
standard data structures to support data architecture
development, data standard, and data reuse. Obtain
approval from the EA Governance Committee
Approved Data Reference
Model
technologies and technology standards/speci-
fications, which support business and services.
Obtain approval from the EA Governance Com-
mittee
Approved Technology Reference
Model
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.

137
9.5.1 Step 5.1 Build 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 measure-
ment systems and performance architectures.
It is made up of an hierarchical model that helps identify measurement needs; a classification
framework that describes the types of measurement that can support the identified needs; and
a measurement framework that helps define effective measurement indicators.
NEA PRM
Figure 9-2 shows the NEA PRM artifacts while Table 9-2 describes the artifacts or deliverables.
Government agencies have to refer and understand the NEA PRM artifacts and contents. Please
refer to the PRM details and consult NEA office for clarification or discussion.
Figure ‎9-2: NEA PRM artifacts

138
S/No Artifact / Deliverable Description
1 Purpose / Direction The purpose of PRM
2 PRM Principles The architectural principles of PRM
3 Strategic Goals / Outcomes The highest level strategic outcomes for Saudi
government
4 Performance Goals The specific performance goals in certain areas and
/ or over certain time period for Saudi government
5 Measurement Areas The various broad areas for measurement
6 Measurement Categories The various categories for measurement within
a measurement area
7 Measurement Groups The various groups for measurement within a
measurement category
8 Indicators The actual measurement indicators
Table ‎9-2: PRM artifact descriptions
Relationship between NEA PRM and Agency PRM
The NEA PRM describes the reference for whole-of-government performance standards. By
referencing the NEA PRM, a government agency can extract the relevant scope that is applicable.
Hence, the agency PRM is like a sub-set of the NEA PRM and the diagrams for both NEA PRM and
agency PRMs are the same. However, the agency PRM has to describe more detail performance
indicators for the government agency within the same measurement categories and groups. At
the same time, the agency PRM has to align with the NEA PRM in terms of the high-level strategic
goals and measurement areas.
Building the Agency PRM
Table 9-3 summarizes the main activities for building the agency PRM.

139
S/No Activity Artifact / Deliverable
1 Define the PRM purpose or direction PRM purpose / direction statement
2 Define the PRM principles PRM principles
3 Define the Strategic Goals and Perfor-
mance Goals
Strategic goals and performance goals
for agency
4 Define the Measurement Areas, Catego-
ries, Groups and Indicators
Set of indicators within measurement
groups within measurement categories
within measurement areas
5 Document and review the draft PRM Reviewed draft PRM
6 Obtain governance approval Approved agency PRM
Table ‎9-3: Main activities to build agency PRM
1. Define the PRM purpose or direction
Depending on the actual EA scope for the government agency, it has to define the appropriate
PRM purpose or direction. The government agency can refer to the NEA PRM’s purpose or goals
to further refine or localize its purpose. The figure below shows an example of the PRM purpose
and direction.
Figure ‎9-3: Example PRM purpose and direction

140
2. Define the PRM principles
Refer to NEA PRM principles to adopt and adapt for the government agency’s own PRM principles.
Note that good principles would aid or direct the subsequent development work of the PRM. As a
guide, there should not be more than seven principles.
3. Define the Strategic Goals and Performance Goals
From the NEA PRM’s strategic goals, identify the relevant goals that are directly applicable to
government agency. For each of the strategic goals identified, adapt it into local agency context
that will become the agency’s strategic goals. If need be, refer to the government agency’s strat-
egy / annual plans and royal decrees if any. It would also be effective to illustrate the strategic
goals and performance goals in a diagrammatic form as shown below.
Figure ‎9-4: Example PRM strategic goals / outcomes

141
4. Define the Measurement Areas, Categories, Groups and Indicators
The next few activities are inter-related. With reference to NEA PRM, analyze and localize the
measurement areas, categories, groups and indicators.
The measurement areas refer to the highest level in the government agency. Typically, these
measurements can derive from Mission, Vision and highest level PKIs. Examples of measure-
ment areas are Customers / Public, Investments, Expenditures, Employees, Technologies and
Assets. For each area, drill down to define the measurement categories such as financial, HR,
customer service and IT. The next step is to define the measurement groups such as division,
branch, department, unit and team.
It is advisable to develop progressively evaluation indicators for a specific group since it is dif-
ficult to do all at once. Table 9-4 shows examples of measurement indicators.
Measure-
ment Area
Measurement
Category
Indicator
S/No
Indicator Defini-
tion
Measurement
Method
Measurement Indi-
cator
Customer Customer
Satisfaction
C.1 Satisfaction
response by
customer
Immediately after
service by pressing
Satisfaction Rating
button
% of satisfaction by
Very Good, Good,
OK, Bad, Very Bad
C.2 Average time
to process cus-
tomer’s inquiry
Survey to random
sampling of
customers
Number of hours
Technol-
ogy
IT Service
Request
T.1 Number of
Processed IT
Request
Calculate number
of processed IT
requests to total
requests received
% of processed IT
request
New Tech-
nologies
T.2 Number of New
Technologies
Adopted
Number over the
year
Number of new
technologies
Table ‎9-4: Example measurement areas, categories and indicators

142
Figure ‎9-5: Example of PRM indicator description
5. Document and review the draft PRM
After all the definitions, document all the relevant information into a structured information
base on the agency’s documentation standards. Do an internal review and updates. It is also
advisable to get another party 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 or Business Architect should front this presen-
tation. From the comments from the committee, make the necessary changes to obtain their
final approval.

143
9.5.2 Step 5.2 Build business reference model
The Business Reference Model (BRM) is a classification category used to describe the type of
business functions at the government agency, in a given sector or national levels. BRM focuses
on categorizing a business base on structured business elements such as business area, line of
business and business functions perform by the government agency.
NEA BRM
Figure 9-6 shows the NEA BRM artifacts while Table 9-5 describes the artifacts or deliverables.
Government agencies have to refer and understand the NEA BRM artifacts and contents. Please
refer to the BRM details and consult NEA office for clarification or discussion.
Figure ‎9-6: NEA BRM artifacts

144
S/No
Artifact /
Deliverable
Description
1 Purpose / Direction The purpose of BRM
2 BRM Principles The architectural principles of BRM
3 Business Areas The highest abstract groupings of business for Saudi government
4 Lines of Business The broad logical groupings of business for Saudi government
(instead of definitions by physical agencies)
5 Business Functions The main business functions within each Line of Business
6 Sub-Business Functions The finer-grain business functions within each business function
Table ‎9-5: BRM artifact descriptions
Definitions
The following are the main definitions for common understanding:
Business Area
A Business Area is the collection of the highest abstraction description of related government’s
accountabilities to the different stakeholders such as the Royal Family, citizens, businesses and
internal governments.
Line of Business (LoB)
An LoB is a broad collection of government roles and responsibilities (both primary and sec-
ondary) within a Business Area. The LoB’s perspective is from a role or responsibility, and not
by government agency.
Business Function
A Business Function is a set of work to be carry out to accomplish the roles and responsibilities
described in the LoB. Each LoB has two or more business functions.

145
Sub-Business Function
A Sub-Business Function is a set of physical activities to be carry out to complete the work
defined in the business function. A Business Function has two or more sub-business functions.
Relationship between NEA BRM and Agency BRM
The NEA BRM describes the reference for whole-of-government business. By referencing the NEA
BRM, a government agency can understand how it relates to the different line of business (LoB)
under different business areas. By extracting the relevant business scope that is applicable, the
agency can develop its own BRM. Hence, the agency BRM is like a sub-set of the NEA BRM (the
diagram for agency and NEA BRMs are the same). However, the agency BRM has to describe more
detail business functions and sub-business functions for the government agency within each LoBs.
Through such definitions, the agency BRM will align with the NEA BRM in terms of the high-level
business areas and line of business.
Building the Agency BRM
Below table summarizes the main activities for building the agency PRM.
1 Define the BRM purpose or direction BRM purpose / direction statement
2 Define the BRM principles BRM principles
3 Define the Business Areas, Lines of Busi-
ness (LoB), Business Functions and Sub-
Business Functions
List of related business areas, LoBs,
business function and sub-business
function descriptions
4 Document and review the draft BRM Reviewed draft BRM
5 Obtain governance approval Approved agency BRM
Table ‎9-6: Main activities to build agency BRM

146
1. Define the BRM purpose or direction
Depending on the actual EA scope for the agency, define the BRM purpose or direction. In addition
to improving overall effectiveness, the agency BRM typically gives an insight into the actual
accountabilities, roles, key functions and relationships with other government agencies. The
BRM is also an excellent tool to aid e-Government transformation. It is also necessary to refer
to the agency PRM and incorporate relevant strategic goals and measurements into the BRM.
The figure below gives an example purpose or direction for BRM.
Figure ‎9-7: Example BRM purpose
2. Define the BRM principles
Refer to NEA BRM principles to adopt and adapt for the government agency’s own BRM principles.
Note that good principles would aid or direct the subsequent development work of the BRM. As a
guide, there should not be more than seven principles.
3. Define the Business Areas, Lines of Business (LoB), Business Functions
and Sub-Business Functions
This step has a few inter-related activities that is best done collectively in an hierarchical way.
Refer to NEA BRM and do the following:
a. Find the related business areas that the agency has accountabilities or responsibilities
b. Similarly, for each business area identified, find the LoBs for the agency. Please note that the
BRM is a logical representation of responsibilities. Thus, it is common that an agency is involve
in at least two LoBs
c. For each LoB, find all the related business functions
d. Finally, for each business function, find all the sub-business functions carry out by the agency.

147
Figure ‎9-8: Example of business area, LoB, business function and sub-business functions
The figure above illustrates the relationship and information on the various business artifacts
or descriptions for Ministry of Education (MoE). This is only an example and does not fully
depict the actual case for MoE. For the same example, the information can also be shown in
the table below.

148
Business
Area
Line of
Business
Business Function
Sub-Business
Function
Royal Family
Affairs
Not listed Not listed Not listed
Citizen Services Education Pre-School to High-School
Education
1. Curriculum Planning for
Schools
2. School Administration
and Governance
Graduate and Post-Graduate
Education
1. Curriculum planning for
universities
2. Accreditation
Business Services Licensing &
Regulatory Control
Licensing & Regulatory Con-
trol of Private Schools
1. Registration and Com-
munication with Private
Kindergartens & Schools
2. Licensing Management
3. Regulatory Enforcement
Government
Services
Not listed Not listed Not listed
Table ‎9-7: Example of business area, LoB, business function and sub-business functions
1. Document and review draft BRM
After listing all the definitions, document the relevant information into a structured information
base on the agency’s documentation standards. Do an internal review and updates. It is also
advisable to get another party to carry out a final review.
With the completion of the deliverables with the other above related contents, present to
the EA Governance Committee. The Chief Architect or Business Architect should front this
presentation. From the comments from the committee, make the necessary changes to ob-
tain their final approval.

149
9.5.3 Step 5.3 Build 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 SW licenses
NEA ARM
Figure 9-9 shows the NEA ARM artifacts while Table 9-8 describes the artifacts or deliverables.
.Government agencies have to refer and understand the NEA ARM artifacts and contents
Figure ‎9-9: NEA ARM artifacts

150
S/
No
Artifact /
Deliverable
Description
1 Purpose / Direction The purpose of ARM
2 ARM Principles The architectural principles of ARM
3 Application Systems The application systems to support business. It can be classified as
a core application system or a supporting application system
4 Application Components The key application component classifications and descriptions
5 Application Interfaces The common methods or interfaces to connect among applications
6 Best Practices & Guidelines The common best practices and guidelines for development and
implementation of application systems, components and interfaces
7 Application Systems for
Saudi Government
The guide for choosing and prioritizing applications systems for
government agencies
Table ‎9-8: ARM artifact descriptions
The figure below illustrates the structured diagram of NEA ARM. It shows the classifications of
the supporting application systems, application components and interfaces. Please refer to the
ARM details and consult NEA office for clarification or discussion.

151
Figure ‎9-10: Structured diagram of application systems, components and interfaces in NEA ARM
Relationship between NEA ARM and Agency ARM
The NEA ARM describes the reference for whole-of-government application systems development.
By referencing the NEA ARM, a government agency can understand the structure and
classifications applications systems, components and interfaces. The NEA ARM also describes
the common application systems for use in government supporting business functions. There
is also a best practices and guidelines on application development and maintenance so that
government agencies can develop quality application systems. Finally, the NEA ARM guides
government agencies in choosing and prioritizing their application development.

152
The agency ARM, on the other hand, describes the main application systems (core and supporting),
components and interfaces for development and implementation specifically for the agency.
These application systems have to support the businesses as defined in the agency BRM. In
addition, the agency BRM would have a prioritized list of application systems for development.
The agency ARM structure is shown in the figure below. The agency ARM has to ensure alignment
with the NEA ARM in terms of the high-level application system and component classifications.
Figure ‎9-11: Agency ARM artifacts

153
Building the Agency ARM
Below table summarizes the main activities for building the agency ARM.
1 Define the ARM purpose or direction ARM purpose / direction statement
2 Define the ARM principles ARM principles
3 Define the application systems List of core and supporting application system
descriptions for the agency
4 Define the application components List of key application component descriptions
5 Define the application interfaces List of key application interface descriptions
6 Prioritize the application systems List of prioritized application systems for devel-
opment
7 Document and review Reviewed draft ARM
8 Obtain governance approval Approved agency ARM
Table ‎9-9: Main activities to build agency ARM
1. Define the ARM purpose or direction
Depending on the EA scope of the agency, the EA Core and working teams have to discuss and
agree on the ARM purpose or direction. It is also necessary to refer to the agency PRM and in-
corporate relevant strategic goals and measurements into the ARM. Below is an example of an
ARM purpose or direction statement.
Figure ‎9-12: Example ARM purpose or direction

154
2. Define the ARM principles
Refer to the NEA ARM principles as shown below. A good set of principles will aid the development
of the agency ARM. Review and customize the appropriate principles for the agency ARM. As a guide,
do not have more than seven principles.
S/
No
Principle Description
1 Strategic Driven Applications Design and prioritize application systems that deliver
strategic outcomes.
2 Cross-Agency Application Systems Design and develop application systems that serve
multiple government agencies.
3 Easy-to-Use yet Secured Application
Systems
Design and develop application systems that are easy-
to-use and, at the same time, highly secured.
4 Adaptable and Reusable Application
Systems & Components
Design and develop application systems using reusable
components and systems while being adaptable to the
constant changes.
5 Vendor-Neutral Application Systems Design and develop vendor-neutral application systems.
Table ‎9-10: NEA ARM principles
3. Define the application systems
The agency has to define the application systems into core and supporting. As application
systems are required to support the business, the EA Core and working teams must refer to the
agency BRM. Each business function should be supported by at least one application system.
The team should then review the sub-business function and rationalize if the same application
system can be support that sub-business function; if not, then another specific application
system may be required for the sub-business function.

155
Figure ‎9-13: Example of MOE’s business and sub-business functions
In the example above, under Education LoB, MOE requires at least two applications to support
the ‘Pre-School to High School Education’ and the ‘Graduate and Post-Graduate Education’.
However, it is not practical to have one system to support the two sub-business functions – i.e.
‘Curriculum Planning for Schools’ and ‘School Administration & Governance’ as they are rather
varied functional requirements. Thus, MOE requires at least two application systems under the
Pre-School to High School Education. Similarly, MOE requires another two application systems to
support the two sub-business processes under ‘Graduate and Post-Graduate Education’.
In the same token, MOE will have a list of application systems to support the common business
functions or sub-business functions such as finance management, IT management, corporate
planning & development, and building management among others.
The EA Core and working teams must also identify the potential application system owner. If
the government agency is the primary owner of the business or sub-business function, then the
agency has to develop the identified core application. However, if the agency plays a secondary
or supporting function to the business function, then the agency should use the application
system developed by the primary agency.
Thus, by now, the government agency should have a clear list of what application systems it
has to own and develop, and what are the applications it should use from the other primary
government agencies.

156
4. Define the application components
NEA ARM has defined the main application component classifications. Please review them all.
In most cases, the agency should adopt all these application components as they are generic
yet useful. In addition, review and add other application components to aid the development of
the agency’s applications. Al these application components should and can be re-use or shared.
5. Define the application interfaces
Like the pervious step, review the list of the common shared application interfaces developed
by Yesser. The government agency should be able to adopt most of the application interfaces.
Similarly, review and add other specific application interfaces required.
6. Prioritize the application systems
Refer to the NEA ARM ‘Application Systems for Saudi Government’ section. Follow the steps to
help the government agency prioritize its application systems. At the end of this process, the
government agency would have different lists with different priorities for application system
development.
7. Document and review
After listing all the prioritized application systems, components and interfaces, document the rel-
evant information into a structured information base on the agency’s documentation standards. It
is recommended to map out the relationship between the application systems and the business or
sub-business functions. Do an internal review and updates. It is also advisable to get another party
such as business / application owners to carry out a final review.
EA Governance Committee. The Chief Architect or Application Architect should front this
presentation. From the comments from the committee, make the necessary changes to obtain
their final approval.

157
9.5.4 Step 5.4 Build data reference model
The Data Reference Model (DRM) is a model that classifies data and defines a standard data
structure to support developing data architecture and promoting data standardization / re-
use / management. The DRM gives a standard data classification for all the data use in the
government agency, including the data sources and the data relationships.
NEA DRM
Figure 9-14 shows the NEA DRM artifacts while Table 9-11 describes the artifacts or deliver-
ables. Government agencies have to refer and understand the NEA DRM artifacts and contents.
Figure ‎9-14: NEA DRM artifacts

158
1 Purpose / Direction The purpose of DRM
2 DRM Principles The architectural principles of DRM
3 National Data Model The data model for KSA government
4 Data Classification The major data classifications
5 Data Structure The overall data structure
6 Data Exchange The common methods for data exchange
7 Data Management The guide for data management for agencies
Table ‎9-11: DRM artifact descriptions
The figure below illustrates the overall NEA DRM. It provides descriptions of the various arti-
facts. Please refer to the DRM details and consult NEA office for clarification or discussion.
Figure ‎9-15: NEA DRM

159
Relationship between NEA DRM and Agency DRM
The NEA DRM provides the reference for whole-of-government data usage and standardization.
By referencing the NEA DRM, a government agency can understand the high-level data model,
data classification, data structure and data exchange. The NEA DRM also provides the data man-
agement guide for quality and reliable data usage and exchange.
On the other hand, the agency DRM describes the main data model for its own use based on
the NEA DRM artifacts. The agency DRM will have its own agency data model, data classification,
data structure and data exchange. The agency DRM structure is shown in the figure below. The
agency DRM has to ensure alignment with the NEA DRM in terms of the data model, data clas-
sification, data structure and data exchange.
Figure ‎9-16: Agency DRM artifacts

160
Building the Agency DRM
Below table summarizes the main activities for building the agency DRM.
1 Define the DRM purpose or direction DRM purpose / direction statement
2 Define the DRM principles DRM principles
3 Define the data model Data model for agency
4 Define the data classifications Key data classifications for agency
5 Define the data structure Main data structure for agency
6 Define the data exchanges Data exchanges for agency
7 Document and review Reviewed draft DRM
8 Obtain governance approval Approved agency DRM
Table ‎9-12: Main activities to build agency DRM
1. Define the DRM purpose or direction
Depending on the EA scope of the agency, the EA Core and working teams have to discuss and
agree on the DRM purpose or direction. It is important to scope carefully the DRM, as it can
potentially be very wide. It is also necessary to refer to the agency PRM and incorporate relevant
strategic goals and measurements into the DRM. Below is an example of a DRM purpose or
direction statement.

161
Figure ‎9-17: Example for defining DRM purpose
2. Define the DRM principles
Refer to the NEA DRM principles. A good set of principles will aid the development of the agency
DRM. Review the NEA DRM principles and customize the appropriate principles for the agency
DRM. As a guide, do not have more than seven principles.
3. Define the data model
The objective of a data model is to show data in a logical and structured method that aid data
discovery and data re-use. It provides the overall view of all the different architectural data
components in a structured fashion.
By referring to the NEA DRM, each government agency can identify which data are established
and operational at the national level. Similarly, the agency has to build its data model to depict
operational data used in the agency. Develop a similar data model for the government agency.
The data model would have data classifications, data structure and data exchanges.

162
4. Define the data classifications
The amount of data can easily cause operational complexities in any government agency. With
massive data elements from different sources, it is necessary to organize and classify data so
that the agency can efficiently search, use and manage data.
Refer to NEA DRM. Based on the data required by the government agency, classify these data
accordingly. The figure below is an example data classification.
Figure ‎9-18: Example for developing data classification structure
5. Define the data structure
The NEA DRM has defined data structure consisting of data elements, data entities, data properties
and their relationships. Similarly, define the data structure for the agency data. The EA Core or
working teams may want to start be defining the structure for commonly use data in the agency.
Below is an example of data structure definitions. Note that a number of these data definitions
map to the data classifications established in the above step. In addition, the agency has to docu-
ment the data properties and relationships.

163
Items of Entity
Definition
Entity Description
Entity Name
As entity name to be managed by agency DRM, it is uniquely, consistently
named by using business terms
Entity Definition Defines both what is the entity and to whom, how, where the entity is used
Data Subject Area
Data subject area which the relevant entity belongs to in data classification
system
Data Group
Data group which the relevant entity belongs to in data classification sys-
tem
Unusual Remark of Entity Describing items to separately emphasize, except entity definition
Entity Version Relevant entity’s version
Entity Ownership Name or code of an agency or department creating the relevant entity
Table ‎9-13: Example data structure definition
6. Define the data exchanges
Finally, define the data exchanges with other government agencies. Based on the data entities
defined above, simply list all the data exchanges. For alignment, please refer to the NEA DRM
for the data exchange definitions and methods. The table below is an example list of data ex-
change.
S/
No
Data
Entity
Agency Name
/ Location
Exchange
Description
Exchange
Frequency
Exchange
Direction
1 Name of
data entity
Name of agency
and location or
branch
Description about
the data exchange
and data entity
Frequency
such as
monthly,
weekly, daily,
hourly
Inbound or
Outbound
Table ‎9-14: Example data exchange definition

164
Upon completion of the above deliverables, the EA Core and working teams have to document
the DRM according to the agency’s documentation standard. Carry out an internal review. In
addition, it is recommended to get other parties to review the DRM such as the business team
and the DBAs.
With the completion of the deliverables with the other above related contents, present it to
the EA Governance Committee. The Chief Architect or Data Architect should front this pre-
sentation. From the comments from the committee, make the necessary changes to obtain
9.5.5 Step 5.5 Build technology reference model
The Technology Reference Model (TRM) classifies and defines technologies and technology
standards/specifications that support businesses and services. The purpose of TRM is for enu-
merating and understanding the underlying IT service & technology elements, analyzing them
and then applying classifications and relevant standards.
NEA TRM
Figure 9-19 shows the NEA TRM artifacts while Table 9-15 describes the artifacts and deliver-
ables. Government agencies have to refer and understand the NEA TRM artifacts and contents.
Please refer to the TRM details and consult NEA office for clarification or discussion.

165
Figure ‎9-19: NEA TRM artifacts
1 Purpose / Direction The purpose of TRM
2 TRM Principles The architectural principles of TRM
3 Service Area The highest level technology service area
4 Service Category The technology service category within a service
area
5 Service Standard The list of technology service standards
Table ‎9-15: TRM artifact descriptions

166
The table below describes the various service areas and service categories.
Service Area Service Categories
Service Access and Delivery Access Channels
Delivery Channels
Service Requirements
Service Transport
Service Platform and Infrastructure Support Platforms
Delivery Servers
Software Engineering
Databases/Storage
Hardware/Infrastructure
Component Framework Security
Presentation/Interface
Programming
Data Interchange
Data Management
Service Interface and Integration Integration
Interoperability
Interface
Table ‎9-16: TRM service area and category descriptions

167
Relationship between NEA TRM and Agency TRM
The NEA TRM describes the reference for whole-of-government technology standards. By
referencing the NEA TRM, a government agency can extract the relevant scope that is applicable
within the agency. The agency TRM has to describe more detail technology standards where
applicable if these are not describe in the NEA TRM. At the same time, the agency TRM has
to ensure alignment with the NEA TRM in terms of the high-level service areas and service
categories.
Building the Agency TRM
Below table summarizes the main activities for building the agency TRM.
1 Define the TRM purpose or direction TRM purpose / direction statement
2 Define the TRM principles TRM principles
3 Define the service areas and service
categories
Service categories within service areas
for the agency
4 Set the service standards Service standards(standard profile) within
each service category relevant for agency
5 Document and review Reviewed draft TRM
6 Obtain governance approval Approved agency TRM
Table ‎9-17: Main activities to build agency TRM
1. Define the TRM purpose or direction
Depending on the actual EA scope for the government agency, it has to define the appropri-
ate TRM purpose or direction. The government agency can refer to the NEA TRM’s purpose or
goals to further refine or localize its purpose. It is also necessary to refer to the agency PRM and
incorporate relevant strategic goals and measurements into the TRM. Figure 9-16 below shows
an example of the TRM purpose and direction.

168
Figure ‎9-20: Example TRM purpose
Figure ‎9-21: Example TRM structure

169
2. Define the TRM principles
Refer to NEA TRM principles to adopt and adapt for the government agency’s own TRM prin-
ciples. Note that good principles would aid or direct the subsequent development work of the
TRM. As a guide, there should not be more than seven principles.
3. Define the service areas and service categories
With reference to NEA TRM (see Table 9-17 above), analyze and localize the service areas and
service categories.
In most cases, the agency would adopt all the service areas, as these are high-level technology
classifications. However, the agency may add or remove if required (this is possible if the gov-
ernment agency’s scope for TRM or EA is limited).
For each service area, analyze if the government agency requires the service categories. Simi-
larly, the agency may add or remove service categories if required.
As the service areas and inter-connected with the service categories, it is recommended to do
a thorough review for applicability.
4. Set the service standards
Setting the service standards require research and thorough analysis. The government agency
can refer to NEA TRM’s service standards and adapt them for the agency.
To set the service standards, the following activities are highly recommended:
a. Define ‘standard’ method to define service standards
Firstly, it is necessary to define carefully the standard method to set the service standards.
The agency TRM’s principles may affect the service standards adoption and description. For
example, if one of the TRM principles is not to use vendor-specific technology, then the service

170
standard cannot describe the vendor products or technology standards. On the other hand,
if there is no such principle on vendor products, the service standards can refer to both open
standards and vendor-specific products.
It is also necessary to define the standard classification such as:
i. Mandatory – standards that shall be complied
ii. Recommended – standards that are good to comply but not a must
iii. New – latest technology standards that can be used if possible
iv. Obsolete – standards that are outdated and should be replaced.
Another consideration is to describe the status and publish date of the standards so that read-
ers know if these are new, revised or outdated standards.
The EA Core team should also ensure that these standard classifications are align with the com-
pliance management under Continuous Governance section.
It is also a ‘standard’ practice is to reference the service standards to the official organization or
vendor source such as ISO, IEEE and OASIS among others.
b. For each service category, collect and list all the necessary technology standards
With all the technology standards, ensure that they are applicable. For related, duplicated or
similar standards, the agency has to decide if would be simpler and more effective to combine
the standards or separate them.
After consolidating all the standards, assign the standard classification and official source of the
standard.

171
c. Write the actual service standards according to ‘standard’ method
Finally, write the actual service standards in the format or method what was agreed. The EA
Core or working team members have to consider the ability for the reader to quickly search and
find the required service standards.
For examples of good standards, please refer to ISO, IEC, IEEE and OASIS.
After drafting all the definitions and standards, document all the relevant information into a
structured information base on the agency’s documentation standards. Do an internal review
and updates. It is also advisable to get another party to carry out a final review.
EA Governance Committee. The Chief Architect or Technology Architect should front this pre-

172
Stage6–BuildCurrent
Architecture

173
10. Stage 6 – Build Current
Architecture
10.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
in capturing the current architectures of the government agency so that the agency can clearly
understand its IT and business landscapes. This would allow a 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 selective relevant architectures depending on
its EA scope and development strategy.
10.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 strat-
egy. Other examples not listed above include current security and performance architectures.

174
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.

175
Table 9-2 list the key activities and expected deliverables for stage 6.
Stage /
Step No
6 Build Government Agency’s Current Ar-
chitectures
Government Agency’s Relevant
Current Architectures
6.1 Capture current business and IT data Government Agency’s Current Data
6.2 Analyze and build the business architec-
ture that describes the current business
functions, sub-business functions, busi-
ness processes, business activities and
business services
Government Agency’s Current
Business Architecture
6.3 Analyze and build the application archi-
tecture that lists all the current appli-
cations (fully automated, partial auto-
mated & manual), and the relationships
between these applications and the
business functions / processes / services
Application Architecture
6.4 Analyze and build the data architecture
that shows all the current data used by
the government agency, the usage of
data by applications including data ex-
change within and externally
Data Architecture
6.5 Analyze and build the technology archi-
tecture that illustrates the current IT in-
frastructure used by the various applica-
tions, data and people
Technology Architecture
6.6 Current Architecture Analysis Summary of Improvement Op-
portunities

176
10.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 to obtain the support of the various parties or divisions
to capture the current data. As part of change management (please see Continuous Gover-
nance – 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
Figure ‎10-1: Data capturing activities

177
1. Identify data elements and data sources required
The first activity is to identify all the data elements and their respective data sources. The EA
Core and working teams can first refer to their reference models to determine the minimum
reference to artifacts. From these artifacts, identify the main data elements from current data-
bases and application systems. The teams need also to identify data from physical sources such
as forms, catalogues, websites, etc.
The table below provides example sources of capturing data.
Current
Architecture
Possible Data Sources
Business
Architecture
1. Organization chart
2. Agency roles and functional descriptions
3. List of business processes
4. Service catalogue (if any)
Application
Architecture
1. Application systems catalogue (if any); else list of all application sys-
tems including application owners and application systems status
2. List of application functions
Data Architecture 1. Database management system (DBMS) for all the databases
2. Database or data schema diagrams
3. List of data exchanges (external and internal)
4. Data model (if any)
5. Database catalogue (if any)
6. Data flow diagrams (if any)
7. Data dictionary (if any)
Technology
Architecture
1. Hardware catalogue
2. Software catalogue
3. Software license agreements
4. Network architecture diagrams
5. Data center layout diagrams
6. Storage information (including back-ups)
Table ‎10-2: Example of possible data sources

178
2. Design data capturing method(s)
Having identified the data elements and the data sources, the next activity is to analyze to de-
termine what data is unavailable. Most of the data should be available in the current systems
somewhere in the government agency. It is important to design a method(s) to capture all these
data into one repository so that the data can be analyzed later in this and subsequent stages.
For data unavailable or not updated, the teams may design data capturing methods such as
questionnaire, data spreadsheet and even online data input screens.
3. Design data capturing templates
The EA Core and working teams have to design the main templates to capture the data. Al-
though different architectures require different data, the teams may consider doing an inte-
grated data capturing exercise so that every data element is captured once. This is an excellent
exercise for the teams to start thinking through the data required for the various architectures.
The data capturing templates can be on spreadsheet or online screen.
4. Present to EA Governance Committee on data capturing approach
This is one of the crucial stages in the EA journey. It is necessary and important to capture all the
right amount data about the government agency. Present the data capturing approach to the
EA Governance Committee so that they understand the importance. In addition, the EA Gover-
nance Committee can provide appropriate directions and ensure relevant parties or divisions in
the agency will support the data capturing exercise.
5. Brief relevant parties
As part of change management, inform the relevant parties or divisions about the EA and in par-
ticular about the data capturing exercise. This briefing aims to get the support of the relevant
parties or divisions. The briefing is a good opportunity to help the spread the message about
the EA benefits.

179
6. Capture the relevant current data
Request for specific persons to be involved in the data capturing exercise. Brief them the details
of data capturing. Provide all the relevant data capturing templates and guidance to the relevant
parties or divisions. The EA Core and working teams, where required, should closely help those
who are capturing the current data.
7.Verify and update
Verify all the data captured. The EA Core and working teams may need time to verify and update
these data if required. It is recommended that data source owners review these data captured.
The data captured will be used in the next steps.
10.4.2 Step 6.2 Analyze and build current business architecture
In the previous stage, the team has built or document the agency’s Business Reference Model
(BRM) based on the NEA Business Reference Model. The government agency’s BRM will be use
as the main document to build the current Business Architecture (BA).
The current BA reflects the actual business accountabilities, roles, functions, processes and ser-
vices of the government agency. The current BA is useful to understand the various inter-agen-
cy relationships and the detailed internal business complexity affecting the agency’s divisions,
branches and departments.
Relationship between Agency BA and Agency BRM
In the previous stage, the team has developed the agency BRM based on NEA TRM. Thus, now
is the time to reference the agency BRM to build the BA.
In essence, the BA is derive from the agency BRM. The main difference, however, is the mani-
festation of the various artifacts or deliverables to reflect accurately the current state in the
government agency. In short, the BA has more details to depict the actual business scenarios
of the government agency.
The figure below shows the difference between the BRM and BA. As more data and details are
required, there will also be additional artifacts as highlighted in red.

180
Figure ‎10-2: Difference between BRM and BA
Relationships among Agency BA and other architectures
Table 10-13 summarizes the agency BA relationships with other current architectures.
Other Current
Architectures
BA Relationship
AA BA drives the requirements for IT applications to improve agency per-
formance, productivity and customer service
DA BA requires data and information for decision making and efficient op-
erations
TA BA provides the requirements for organization efficiency and
effectiveness through technologies such as office automation
and personal digital devices.
Table ‎10-3: BA relationship with other architectures

181
The figure below shows the relationships among BA artifacts and the relationships with artifacts
from other architectures.
Figure ‎10-3: BA artifacts’ relationship diagram
Description about the Agency BA
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 de-
liverables. Note that there are three additional artifacts or deliverables. Collectively, they will
provide a comprehensive description of the current BA.

182
S/
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(Line of Business) for the agency
within the business areas
5 Business Functions (BRM) The key business function descriptions within LoBs
6 Sub-Business Functions (BRM) The sub-business function descriptions within
each business function
7 Business Processes The list of business process descriptions within
each sub-business function
8 Organization Chart The current organization chart for the agency
9 Service Catalogue The current list of business services
Table ‎10-4: BA artifact descriptions
Building the Agency BA
Below table summarizes the main activities for building the agency BA.
S/
No
Activity Artifact / Deliverable
1 Define the BA purpose or direction BA purpose / direction statement
2 Define the BA principles BA principles
3 Document the organization information Organization chart
4 Define the business functions(BRM) Reviewed / updated business areas, LoBs,
business functions and created sub-busi-
ness functions
5 Define the business processes List of business processes for the agency
6 Document the service catalogue Service catalogue
7 Document and review Reviewed draft current BA
8 Obtain governance approval Approved agency current BA
Table ‎10-5: Activities to build BA

183
1. Define the BA purpose or direction
The TA and TRM purposes are alike. The difference is that the TA purpose can show actual out-
comes directly. Review the TRM purpose, amend and define the TA purpose or direction.
2. Define BA principles
The BA and BRM principles are similar. The slight difference is that the BA has to describe more
organizational and services information. Hence, it is necessary to review the BRM principles and
may make minor changes or additions in particular about addressing more service-orientation
for the government agency.
3. Document the organization information
This step is simply to document the main organizational information about the government
agency. This helps in ensuring alignment with government agency’s primary purpose and ac-
countability.
The main information to be captured are the organization chart, and its mission and vision
statements. Other information such as broad strategies and goals of the government agency
are optional items.
Note that if the information are already available in the BRM, then the EA Core team has to
simply verify and update them. If it is not available, then the information have to be officially
sourced and documented. Typically, the organizational information should be available on of-
ficial websites. Figure 10-3 is an example of an organization chart, while Table 10-5 lists the
main attributes of an organization.

184
Figure ‎10-4: Organizational chart example

185
Property Description
Relationship
with national
meta model
Name
An organizational unit is any functional unit like Corporate/department/
section that collectively executes the business functions.
It is also use to represent any external entities such as Government Agencies,
Ministries, Authorities and Councils.
It could also represent a collaboration of multiple Organization Units (like
committees and programs)
-
Description The government agency’s main mission, vision or role -
Type The government type such as ministry, authority, council, center, program, etc. -
Hierarchy Level The different organizational levels in the government agency -
Child Units
A group or unit of staff reporting to a higher level supervisory unit or
department
-
Location The actual location such as city or town names -
Has Positions The number of positions in the same hierarchy -
Owned Business
function
The business functions owned by a department or unit -
Owned Business
Services
The business services owned by a department or unit -
Table ‎10-6: The properties of organization chart
4. Define the business functions(BRM)
In this step, the EA Core team and working teams have to analyze and document important
architecture elements together – Business Areas, LoBs, Business functions and sub-business
functions. It is highly recommended that the team member with the most experience and
knowledge in the Saudi government roles, functions and processes lead this exercise. Figure
10-4 illustrates the relationships among the various elements in BA.
Review the business areas in the BRM. Ensure that the current business areas identified are
still relevant. The team members may want to check if there added new accountabilities or

186
responsibilities for the government agency mentioned through royal decrees or government
official announcements as these may affect this review process.
For each business area, review all the relevant LoBs that the government agency is responsible.
Refer to the government agency’s BRM. Ensure and verify that the list of LoBs in the BRM are
correct. Note that nearly all government agencies would have LoBs in different business areas.
It is important that the team comb all the LoBs in the NEA BRM as a verification exercise.
For each LoB, the EA Core team and working teams have to document all the business functions
within the respective LoBs. While the BRM may list some of these business functions, the team
has to verify and add other missing business functions if any. This exercise would ensure that all
the government functions are documented – both primary and secondary. As a guide to verify
the business functions, the team can review the top 4 levels of the organization chart includ-
ing all the divisions and departments. It is a norm to have a range between 10 and 30 business
functions for a government agency.
Within each business function, the team now has to analyze and list all the sub-business func-
tions. These are finer grain descriptions about the business function. A business function nor-
mally has 2 or more sub-business functions. The team can review the organization chart as a
guide - especially at levels 5 and lower where all the units, branches and teams are define. A
government agency typically has 40 to 100 sub-business functions. Document all the business
functions and sub-business functions in the example format below.
Figure ‎10-5: Business area, LoB, business function and sub-business function diagram example

187
Relationship
with national
meta model
Name The name of business function -
Description The detail description of this function -
Level
The level of relevant business function such as area,
LOB, function, and sub-function
-
Upper function
The related upper function’s name. ‘Sub-function’
should be related with one of ‘function’
-
Figure ‎10-6: The properties of business function description
5. Define the business processes
Having documented all the business and sub-business functions, the EA Core team and working
teams have to work with the business owner or representatives to analyze and to document all
the business processes within each sub-business function. Note that the NEA and government
agency’s BRM do not have this list of business processes.
Although this is a tedious task, it is important to document all the business processes so that the
government agency can visualize and identify areas of improvements to the various business
functions and sub-functions. This task is also necessary to facilitate the discovery of potential
processes that can be improved or re-engineered to improve the sub-business function or busi-
ness function as a whole. These business process improvements aid the agency’s e-Government
transformation journey. It is highly recommended that the departments or branches responsi-
ble for these sub-business functions dedicate staff to work with the EA Core and working teams.
For a start, the EA Core and working teams have to understand and agree on the following im-
portant definitions:

188
a. A sub-business function normally has two or more business processes
b. A business process consists of a series of business activities carry out to perform a specific
business outcome; it has one or more inputs and one or more outputs
c. The business processes, if automated, are supported by one or more IT applications.
Figure 10-6 shows the information about a sub-business function.
Figure ‎10-7: Contents of a sub-business function
Figure 10-7 shows the main information about a sub-business function using one of MOE’s
examples. Note that this is for illustrative purpose only and does not contain the full updated
information. In this example, the sub-business function of Licensing Management has four
business processes.

189
Figure ‎10-8: MOE’s sub-business function & business process relationship
Document the sub-business function and its processes as shown in the tables below.
Attribute Description
Sub-Business Function ID B.1.3
Sub-Business Function Name Licensing Management
Sub-Business Function Description Manage the issuance, update and revoke of private
school license
Input • Company Registration ID
• Payment by requestor
Output Private School Operating Certificate
Application Systems • Licensing Portal System
• Private Schools Management System
• National Shared Payment System
Table ‎10-7: Example of sub-business function description

190
Process
ID
Process
Name
Process De-
scription
Process
Owner
Input Output
B.1.3-1 Manage Licensing
Rules
Manage and update
the various rules /
conditions relating
to the operating
private schools
Licensing
Management
Director
Updates from
ministries;
royal decrees
Updated set of
rules
B.1.3-2 Register &
Maintain Private
Schools List
Create and Update
list of private
schools
Licensing
Management
Director
Updated set
of rules
Updated Private
Schools List
B.1.3-3 Process Request
for new, update
or terminate
Review and ap-
prove or reject the
request for a new /
update / terminate
private school
Licensing
Management
Director
Request Approved
request
B.1.3-4 Issue or Revoke
License
Print and issue physi-
cal license;
Remove and revoke
physical license
Licensing
Management
Director
Approved
request
New license or
revoke license
Table ‎10-8: Business process description example

191
Document all the activities within each process. The table below is an example of
the activities under ‘Process New Request for Private School’ i.e. B.1.3-3.
Activity
ID
Activity
Name
Activity De-
scription
Activity
Owner
Input Output
B.1.3-3-1 Validate request Check all relevant information
in request
Private Schools
Licensing Officer
Request form Nil
B.1.3-3-2 Verify request Verify request is valid and
correct
Private Schools
Licensing Officer
Request form Nil
B.1.3-3-3 Check for simi-
lar school
Ensure that the proposed
school name is not in use
Private Schools
Licensing Officer
Request form Nil
B.1.3-3-4 Check owner’s
records
Carry out detailed financial
and criminal checks on
owner(s)
Private Schools
Licensing Officer
Proposed
owner’s
national ID
Proposed
owner’s status
B.1.3-3-5 Check curricu-
lum compliance
Check for compliance to
national curriculum
Curriculum Edu-
cation Officer
Proposed
curriculum
plan
Curriculum
compliance
status
B.1.3-3-6 Conduct physi-
cal check
Check proposed private
school environment
Private Schools
Licensing Officer
Proposed
site location
information
Physical location
status
B.1.3-3-7 Decide on
request
Decide to approve or reject Private Schools
Licensing Officer
Outputs from
previous
activities
Decision
Table ‎10-9: Business activity description example
In addition to the activity description above, it is highly recommended to depict the process and
activities in a process map. Figure 10-8 is an example process map.

192
Figure ‎10-9: Business process map example
6. Document the service catalogue
From the list of business processes and activities, the EA Core and working teams can analyze
jointly with the sub-business function owner and process owners to document the services
offered to citizens (G2C), businesses (G2B), employees (G2E) and other government agencies
(G2G). As part of the current business architecture, it is important to know what services
(either electronic or manual) are offered within each sub-business function. This would aid
the government agency to identify areas for business or service transformation.
Typically, a set of business processes will form one distinct service offering by the government
agency. Within a sub-business function, there can be one or more sets of related business
processes, hence one or more services.
It is common mistake to equate business processes to the delivery of services, i.e. it is a mistake
to equate one business process = one service. Sometimes, even detailed business activities
are regarded as services (for example, a business process may have 5 activities that produce
so-called 5 services). Always view a service from the customer’s perspective, i.e. outcome that
has a value to the customer. Business process and activities on how to carry out the service is
of no concern to the customer, although it is major concern for the business or function owner.

193
Analyze the business processes and document the services as follows:
a. Using the business process maps, identify any service offered for each business process (i.e.
output to a stakeholder or customer is usually a service)
b. Document the service according to its categorization (please see Table 10-9). Ensure that the
format is same or similar, as the service details are required to consolidate for the National
Saudi Government Service Catalogue. Table 10-10 shows an example service catalogue
c. Analyze to remove duplicate services across different business processes.
Relationship
with national
meta model
Service
ID
Unique service identifier
Business
service(SRS)
Business Service
Name
Name of the business service
Business
service(SRS)
Business Service
Description
Description of the business service
Business
service(SRS)
Service
Type Based on Consumer
Category of the business service, i.e. G2C, G2B, G2G or G2E
Business
service(SRS)
Service Type based On
Granularity
Main Service or Sub Service
Business
service(SRS)
Service Maturity Maturity of Service- Informative, Transactional etc..
Business
service(SRS)
Service Delivery Channel
Mode of the service delivery such as manual, online, kiosk or
combination
Business
service(SRS)
Service Location Location of the Service being delivered.
Business
service(SRS)
Service
Owner
Name or designation of the service owner
Business
service(SRS)
Service Fees The amount charged from consumers of the service
Business
service(SRS)
Service Output
Outputs at the end of the service such as documents, reports and
updated information
Business
service(SRS)
Pre-Requisite Mandatory requirement or condition before the service can start
Business
service(SRS)

194
Relationship
with national
meta model
Service Requirements Supporting documents required to use the service
Business
service(SRS)
Business Process Af-
fected
Zero, one or more services affected by this business process; the
affected services identified by their unique Service ID
Business
service(SRS)
Data Dependency Data required from other agencies to execute the service
Business
service(SRS)
Service Linkage
Is this service utilized by other agencies to execute their own
services
Business
service(SRS)
Servicing Time
Time required to deliver the service to consumer from service
request to the logical end.
Business
service(SRS)
Table ‎10-10: The properties of service catalogue
Using the MOE’s example, there are 2 services rendered under the Licensing Management as
shown in the table below.
Service
ID
Business
Service
Name
Business Service
Description
Service
Category
Service
Owner
Service
Output
Pre-Requisite Service
Mode
Business
Process
Affected
B.1.1 Search for
Private
School (e.g.
by school
name)
Allows public to
search a private
school in KSA. Details
include the location
of the school, school
contact information
and the basic teach-
ing curriculum
G2C /
G2B
Licensing
Manage-
ment
Director
Private
School
details
Nil Online B.1.3.1
B.1.2 Register
and Update
Private
School
Register new private
schools, update infor-
mation about private
schools and the
removal of private
schools. This service
includes the issue of
private school operat-
ing license
G2B Licensing
Manage-
ment
Director
Private
School
Operating
License
Company Regis-
tration Number,
Prior payment
for services
Online
with
manual
checks
and ap-
proval
B.1.3.1,
B.1.3.2,
B.1.3.3,
B.1.3.4
Table ‎10-11: Service catalogue example

195
Document all the above information according to the agency’s documentation standards. Do
an internal review and updates. It is also advisable to get another party (especially the business
owner and business teams) to carry out a final review.
8. Obtain Governance Approval
With the completion of the above deliverables, present to the EA Governance Committee. The
Chief Architect or Business Architect should front this presentation. From the comments from
the committee, make the necessary changes to obtain their final approval.
10.4.3 Step 6.3 Analyze and build current application architecture
Application architecture (AA) represents a focal point for a government agency’s IT applications.
It defines how what applications are available, how they support the business and who the
users are. Application architecture will directly help in aligning the government agency business
processes to application systems that support them.
The objective of current application architecture is to describe the application systems & their
relationships that are currently in use by the various business functions. By understanding this
current reality, it gives many opportunities to find areas for business automation, remove
application duplications and improve integration for both business and application systems.
Relationship between Agency AA and Agency ARM
In the previous stage, the team has developed the agency ARM based on NEA ARM. Thus, now
is the time to reference the agency ARM to build the AA.
The agency AA shows the current reality based on the main artifacts of ARM. It describes the
various artifacts or deliverables that reflect accurately the current state in the government
agency in terms of application systems. In short, the AA has more details than the ARM to
depict the actual application system scenarios of the government agency.

196
The figure below shows the difference between the ARM and AA. As more data and details are
Figure ‎10-10: Difference between ARM and AA
Relationships among Agency AA and other architectures
Table 10-9 summarizes the agency BA relationships with other current architectures.
Other Current
Architectures
AA Relationship
BA AA provides application systems to the various business functions in
the government agency
DA AA requires data model and data elements to be use for decision
making and efficient operations
TA AA provides the requirements for technologies to support the hosting
and usage of application systems
Table ‎10-12: AA relationship with other architectures

197
The figure below shows the relationships among AA artifacts and the relationships with artifacts
Figure ‎10-11: AA artifacts’ relationship diagram
Description about 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.

198
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
4 Application Components
(ARM)
The key application components for the agency
5 Application Interfaces (ARM) The main application interfaces for the agency
6 Application Catalogue The list of applications and their attributes
7 Application Functions The description about the application functions
8 Application Relationships The description about the application relationships
9 Application Overview The overview description of the application systems
Table ‎10-13: AA artifact descriptions
Building the Agency AA
Below table summarizes the main activities for building the agency AA.
1 Define the AA purpose or direction AA purpose / direction statement
2 Define the AA principles AA principles
3 Review application systems, application
components and application interfaces
(ARM)
Reviewed / updated application systems,
application components and application
interfaces
4 Document the application overview Application overview
5 Document the application catalogue Application catalogue
6 Document the application functions Application functions
7 Document the application relationships Application relationships
8 Document and review Reviewed draft current AA
9 Obtain governance approval Approved agency current AA
Table ‎10-14: Activities to build AA

199
1. Define the AA purpose or direction
While the agency ARM provides a good reference to the logical parts of the various applications,
the purpose or direction of the agency AA would describe how these application systems could
actually support the business. Review the ARM purpose, amend and define the AA purpose or
direction.
2. Define AA principles
The AA and ARM principles are similar. The slight difference is that the AA has to describe the
details of the application systems, components and interfaces. In addition, the AA principles
have to address about the application development issues and processes. Hence, it is necessary
to review the agency ARM principles and make minor the necessary changes or additions.
3. Review application systems, application components and application
interfaces (ARM)
From the ARM, review the application systems, components and interfaces. These have been
define to guide the agency in the application development. Simply review all these and make
the necessary additions, amendments and deletions.
4. Document the application overview
The purpose of application overview is to illustrate a high-level representation of all the current
applications within the agency. The application overview should include at least the following
details:
Attribute Description
Relationship with
national meta
model
Application Name The internal name of the application
Application
system(Name)
Category Name
A logical group of the applications. It can be based
on any logical grouping such as being core business
applications or supporting applications
-
Table ‎10-15: The properties of application overview

200
Figure ‎10-12: Application overview example
5. Document the application catalogue
From the application systems, components and interfaces reviewed, the EA Core and working
teams can simply define and document all these information into a structured application cata-
logue. With this application catalogue, it is easy and fast to find all the necessary information about
the various current applications in the agency.
The purpose of this viewpoint is to describe the contextual elements of the application such
as the application modules, application services, development type, maintenance cost, etc. Ap-
plication catalogue is use to identify a list of all the current applications with their details in the
agency. This view should include at least the following attributes:

201
Relationship with
national meta
model
Application Name The internal name of the application Application
system(Name)
Application Description Some details about the application Application
system(Purpose)
Application Type Core business application or support -
Business function List of business function supported by
application
-
Business Owner The Business unit owning the application -
Development Type Externally developed, In-house, out-
sourced, commercial off the shelf, etc.
Application
system(Introduction
method)
Vendor The name of the application’s vendor -
Version Application’s version -
Environment Test, production, development -
Number of Licenses The number of the user licenses of the
application
-
Development language Microsoft .Net, Eclipse Java EE, Oracle
Forms. etc.
Application
system(Development
language)
Related Database The name of the related database -
Hosted Server Name / IP The name or IP address of the server
hosted the application
-
Launch Date The date in which the application be-
came in production
-
Retirement Date The date that the application has been
/ will be retired
-
Total cost The total cost of the application Application
system(Total develop-
ment cost)
Maintenance Cost The annual maintenance cost of the
application
Application
system(Annual main-
tenance cost)
Table ‎10-16: The properties of application catalogue

202
Below is one example entry of an application catalogue.
Application
Attribute
Description
Application Name Training
Application Descrip-
tion
This application is used for training registration (In-service Training
and Pre Service Training)
Application Type Core business application
Business Service Admission and Registration for In-Service Training
Admission and Registration for Preparatory Training
Business Owner Admin and Registration department
Development Type In-house developed
Vendor Oracle
Version Developer 6i
Environment In production
Number of Licenses N/A
Development lan-
guage
Oracle Forms.
Related Database Hopd5
Hosted Server Name/
IP
Training_Srv/10.10.10.5
Launch Date 11/05/2010
Retirement Date 11/05/2016
Total cost 3.510000 SAR
Maintenance Cost 860000 SAR
Table ‎10-17: Application catalogue example

203
6. Document the application functions
The purpose of application functions is to identify and describe the functions (activities) per-
formed by the systems in order to depict the relationship between applications and business
functions within the agency. This view is useful when identifying the application systems used
by a particular business function. It also allows the identification of duplicated system functions
among applications. Hence, it allows analysis of duplicated business functions or duplicated ap-
plication systems. The application functions should include at least the following details:
Relationship
with national
meta model
Application Name The internal name of the application system
Application
system(Name)
Module / Sub
Module Name
A module/sub module is a software component or
part of a program and in an enterprise-level software
application may contain several different modules,
and each module serves unique and separate business
operations
-
Function Descrip-
tion
The description of the main function of the application /
module/ sub module
-
Table ‎10-18: The properties of application function

204
The table below is an example of an application function description.
S/
No
Application
Name
Module Name Sub Module Name Function Description
1 Training Trainee system N/A Registration for Training (In-service Training and Pre Service
Training)
2 Planning and
Development
Scholarship
System
N/A Support faculty members to get higher education (Master and
Ph.D.). All details of faculty member who are going for higher
study, their scholarship etc. are captured in this system
Planning System N/A Plan annual activities of the organization

205
S/
No
Application
Name
Module Name Sub Module Name Function Description
3 Business
Human
Resources
Job Positioning Classifies the organization job titles and manages all transactions
Human Resources Personnel System Manages all employee transactions (employment, promotions etc.)
Human Resources Evaluation system Evaluates employee performance
Human Resources Payroll system Processes all payroll and financial claims made by employees
Human Resources Delegation & Banking Controlling all banking transfers
Human Resources Vacations system Manage and archive all kinds of vacations (normal, emergency,
sick vacation)
Human Resources Housing system Managing all Campus facilities
Human Resources General Query &
statistics
On the basis of query and data, it produces a dashboard to the
decision makers
Human Resources Cooperative staff Keep all information of Cooperative/Support staff
Human Resources Organization Social
committee
Managing all financial activities of the organization social com-
mittee
Human Resources Residency system Following up all housing residency procedures such as renew-
ing, exit & return forms
Stock Control
System
Purchasing Controlling all goods requisitions from the organization departments,
verifies the request, asking for vendors quotations, and completing
purchase cycle
Stock Control
System
Inventory Managing all inventory items stock of the organization
Stock Control
System
Stock Control Control all purchasing and inventory procedures of IPA
Stock Control
System
Materials
Assignment
Following up all IPA properties/materials which are assigned to
employees or departments
Stock Control
System
Recruiting system Recruit new employees by conducting entrance examinations
for academic and non-academic jobs. Also accept all online
applications submitted by candidates.
Archiving System
for internal
Document
N/A The system is used for indexing and scanning all IPA internal
documents
Accounting System N/A Government Accounting system
Communication
System for incom-
ing letters
N/A The system is used for incoming letters from other organization.,
The system is used for indexing and scanning of letters/docu-
ments
Table ‎10-19: Application function example

206
7. Document the application relationships
The purpose of application relationship is to define relationships among different applications
(internal or external) in order to understand the degree of interaction and the data exchange
among these applications. This view should include the details in the table below.
Relationship
with national
meta model
Application Name The internal name of the application
Application
system(Name)
Interacting Application
The name of the interacted application with the first
application
Integration Objective The purpose of the integration
Interface Name / Type
The details of the Integration Interface between the two
applications
Data Entity
The name of the data entity exchanged between the
applications
Data(Name)
Flow
Direction of the relationship (unidirectional or bidirec-
tional)
Frequency The frequency of exchanging data through the interface
Connectivity Type
The type of network connectivity between the two
applications: Internet, LAN, Offline, etc.
Table ‎10-20: The properties of application relationship
Below is an example of application relationship description of the current internal application
integration details.

207
S/
No
Application
Name
Interacting
Application
Integration
Objective
Interface
Name /
Type
Data
Entity
Flow Frequency
Connectivity
Type
Business
All Applica-
tion
Employee info N/A
Em-
ployee
Data
Out Daily LAN
Training Business
To transfer
money to
student
N/A
Student
Data
Out Daily LAN
Training
Planning and
Development
Info about
training like
how many
training
conducted,
seminars, etc.
N/A N/A Out Daily LAN
Consultation
Planning And
Development
Info about
consultation
and statistics
N/A N/A Out Daily LAN
Table ‎10-21: Application relationship example
With the completion of the various application documentation, consolidate them into one
structured document according to the agency documentation standards. Carry out an internal
review to verify all the data and artifacts. It is also recommended that an external or third party
(for example application owners) carry out another review. Based on their feedback, make the
necessary improvements.
With the completion of the deliverables with the other above related contents, present it to
the EA Governance Committee. The Chief Architect or Application Architect should front this

208
10.4.4 Step 6.4 Analyze and build current data architecture
The objective of the current data architecture (DA) is to describe the data entities and structures
used by the business services and business applications. The data architecture describes how
data is processed, stored, and utilized in the government agency. The data architecture is a
crucial component in establishing an overall adaptive environment that enhances and facilitates
data sharing across the agency.
Relationship between Agency DA and Agency DRM
In the previous stage, the team has developed the agency DRM based on NEA DRM. Thus, now
is the time to reference the agency DRM to build the DA.
The DA represents the elements associated with the information in the government agency such
as conceptual data model, logical data model, data entities, databases and other data-related
elements.
The agency DA shows the current reality based on the main artifacts of the agency DRM. It
describes the various artifacts or deliverables that reflect accurately the current state in the
government agency in the use of data. In short, the DA has more details than the DRM to depict
the actual data scenarios of the government agency.
The figure below shows the difference between the DRM and DA. As more details are required,
there will also be additional artifacts as highlighted in red.

209
Figure ‎10-13: Difference between DRM and DA
Relationships among Agency DA and other architectures
Below table summarizes the agency DA relationships with other current architectures.
Other Current
Architectures
DA Relationship
BA DA provides information on agency-wide data and sources of data
from external parties; this aids decisions on data sharing and re-use
AA DA provides data models, database information and data elements
to be use by application systems
TA DA provides the requirements for technologies to support the hosting
and usage of database systems and data exchanges
Table ‎10-22: DA relationship with other architectures

210
The figure below shows the relationships among DA artifacts and the relationships with arti-
facts from other architectures.
Figure ‎10-14: DA artifacts’ relationship diagram
Description about the Agency DA
On completion, the current DA will depict the current data landscape of the government agen-
cy. 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.

211
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
7 Conceptual Data Model The pictorial high-level description of data model for
the agency
8 Logical Data Model The logical data models of the agency
9 Data Flow Diagrams The various pictorial representations of data flows for
the agency
10 Database Portfolio Catalogue The consolidation of all databases in the agency
11 Data Dictionary The definitions for common data in the agency
Table ‎10-23: DA artifact descriptions
Building the Agency DA
Table 10-24 summarizes the main activities for building the agency DA.
S/
No
1 Define the DA purpose or direction DA purpose / direction statement
2 Define the DA principles DA principles
3 Review data model, data classifications and
data structures (DRM)
Reviewed / updated data model, data classifications
and data structures
4 Create the conceptual data model Conceptual data model
5 Create the logical data model Logical data model
6 Document the data flow diagrams Data flow diagrams
7 Compile the database portfolio catalogue Database portfolio catalogue
8 Document the data dictionary Data dictionary
9 Document and review Reviewed draft current DA
10 Obtain governance approval Approved agency current DA
Table ‎10-24: Activities to build DA

212
1. Define the DA purpose or direction
While the agency DRM provides a good reference to the high-level data model, data classifications
and structures, the purpose or direction of the agency DA is to describe the actual data usage
landscape. Review the DRM purpose, amend and define the DA purpose or direction.
2. Define DA principles
The DA and DRM principles are similar. The slight difference is that the DA has to provide more
information about the actual data landscape in the government agency. Hence, review the DRM
principles and amend them to catalyze the development of agency-wide data landscape.
3. Review data model, data classifications and data structures (DRM)
From the DRM, the EA Core and working teams have to review the data model, data classifications
and data structures. Add, amend or delete the information if required. This information will be
required for the next few activities.
4. Create the conceptual data model
A conceptual data model identifies the highest-level relationships between the different data
entities using ERD notation with at least the following details:
Relationship
with national
meta model
Data Entity The name of the data entity exchanged be-
tween the applications
Data(Name)
Entity Relationship The relationship between data entities and
the multiplicity
-
Table ‎10-25: The properties of conceptual data model

213
Below is an example of a conceptual data model.
Figure ‎10-15: Conceptual data model example
5. Create the logical data model
A logical data model describes the data in more detail, without regard as to how they will be
physical implemented in the database. Features of a logical data model include:
Relationship with national
meta model
Data Entity The name of the data entity Data(Name)
Entity Relationship The relationship between data
entities
-
Attributes All the attributes of the entity -
Primary Keys A list of the primary key(s) -
Foreign Keys A list of the foreign key(s) -
Table ‎10-26: The properties of logical data model

214
The figure below is an example of a logical data model. Draw the logical data model for the agency.
Figure ‎10-16: Logical data model example
6. Document the data flow diagrams
Data flow diagram represents both input and output information from the application systems.
It also shows the data storage locations, data sources and data destinations. Through pictorial
diagrams, it is efficient and easy to gather information on data supplier and consumer, including
the transformation points of the data.
From the logical data model, analyze the inputs and outputs to each data entity. Map the data
stores, inputs and outputs into the business processes developed in BA. The table below is
example of attribute descriptions, while the figure is an example data flow diagram. Finally,
draw all the relevant data flow diagrams.

215
External Entity (Input /
Output)
An external entity can represent a human, system or subsystem.
It is the data source or destination.
Process (Function) A process is a business activity or function where the manipula-
tion and transformation of data takes place.
Data Store A data store represents the storage of persistent data required
and/or produced by the process. Data entity and database table
are the examples of data stores.
Data Flow A data flow represents the flow of information, with its direction rep-
resented by an arrowhead that shows at the end(s) of flow connector.
Table ‎10-27: The properties of data flow diagram
Figure ‎10-17: Data flow diagram example

216
Compile the database portfolio catalogue
The purpose of database portfolio catalog is to identify the databases use by application sys-
tems (listed in current AA). This artifact also provides the logical mapping between related data
elements that is very useful in depicting the holistic view of the enterprise architecture. The
database catalogue should include at least the following details:
Relationship
with national
meta model
Database Name of database use by application systems -
Description High level database description -
DBMS Information Some details regarding the database management system
(Oracle DB, Adabas, DB2, MySQL, etc.)
-
Server Name / IP The name or the IP address of the database server -
Database Size The size of the database -
Backup Info Frequency of the backup and data backup recovery plan -
Business Criticality Business criticality of the database (e.g. very critical, normal,
low)
-
Business Owner / Unit The data owner -
Table ‎10-28: The properties of database portfolio catalogue
For each of the logical data model, identify the corresponding database(s). Document all the
details in the database portfolio catalogue as shown in the example below.

217
The table below provides a general example of the database details view.
S/No Database
Name
Description DBMS Info Server
Name/IP
Database
Size
Backup Info Business
Criticality
Business
Owner / Org
Unit
1 Special
Training DB
This database is
central repository
for all data related
elements of special
training
Oracle
10gR2, 9i
in J and D
172.20.1.36 10 GB Weekly backup
(Cold Backup)
and there is no
recovery plan
exists
Critical
Special Train-
ing Dept.
2 English
Training DB
This database is
central repository
elements of English
training
Oracle
10gR2, 9i
in J and D
172.24.8.14 2 GB Weekly backup
(Cold Backup)
and there is no
recovery plan
exists
Critical
English
Learning
Centre
3 Library DB This database is
central repository
elements of the
library.
Oracle
10gR2, 9i
in J and D
172.20.1.36 10 GB
N/A Average
Library Dept.
Table ‎10-29: Database catalogue example
8. Document the data dictionary
The purpose of the data dictionary is to define the data attributes regardless of the physical
storage or form. As data dictionary defines all the common data elements, it is useful in
confirming data requirements for business and other data exchanges. The data dictionary
provides a comprehensive description of each data element as shown below.

218
Relationship
with national
meta model
Data Entity The name of each entity (also called a table) Data(name)
Description A description of the data entity Data(description)
Attribute name The name of each attribute name -
Attribute description A description of the data attribute -
Primary / Foreign Key Identification of primary and foreign key of each
attribute
-
Data Type The data type of each field (text, image, date , etc.) -
Field Size The maximum length of the field -
Mandatory Whether this attribute is mandatory or not(Yes/no) -
Table ‎10-30: The properties of data dictionary
From both the logical data model and database portfolio catalogue, the team has to analyze and
list all the data elements. Describe the data elements as shown in the table below.

219
Data Entity Product
Description An item in the catalogue of products that are available for purchase by a customer
Attribute name Product Number
Attribute description The unique identifier of the item in the catalogue
Primary / Foreign Key Primary Key
Data Type Integer
Field Size 00000000 to 99999999, always 8 digits including
leading zeroes
Mandatory Yes
Attribute name Description
Attribute description Short description of the product for customer
consumption
Primary / Foreign Key No
Data Type Character
Field Size min:1, max:256
Mandatory No
Attribute name Unit Cost
Attribute description The current list price of the product
Primary / Foreign Key No
Data Type Currency
Field Size SAR max 100,000,000,000
Mandatory Yes
Table ‎10-31: Data dictionary example

220
Upon completion of the above deliverables, document all the relevant information into a structured
DA document base on the government agency’s documentation standards. Carry out an internal
review and appropriate updates. It is also a good practice to get an external party to review the
DA document such as DBAs and business owners.
With the completion of the deliverables with the other above related contents, present to the EA
Governance Committee. The Chief Architect or Data Architect should front this presentation. From
the comments from the committee, make the necessary changes to obtain their final approval.
10.4.5 Step 6.5 Analyze and build current technology architecture
The technology architecture (TA) describes the software and hardware capabilities that are
required to support deployment of business, data, and application services. This includes ICT
infrastructure, middleware, networks, and communications among others. The main objective
of the current TA is to map a set of technology components - which represent software and
hardware components – into a structured pictorial and descriptive view of the technologies in
use by the government agency.
The TA provides the detailed description of the technology-related elements and this section
addresses the technology domain in the Enterprise Architecture, their purpose template,
example and linkages.
Relationship between Agency TA and Agency TRM
In the previous stage, the team has developed the agency TRM based on NEA TRM. Thus, now
.is the time to reference the agency TRM to build the TA
In essence, the TA is derive from the TRM. However, the main difference is the application of the
various artifacts or deliverables to reflect accurately the current state in the government agency.
In other words, the TA has more details to depict the actual physical technology scenarios of the
government agency.

221
The figure below shows the difference between the TRM and TA. As more data and details are
Figure ‎10-18: Difference between TRM and TA
Relationships among Agency TA and other architectures
As the EA Core and working teams have already developed other current architectures, it is
important to understand their inter-relationships as summarized in below table.
Other Current
Architectures
TA Relationship
BA TA provides the client and office technologies such as PCs, mobile
devices, printers and scanners to the agency employees in different
branches and divisions
AA TA provides the infrastructure technologies to host and support ap-
plication systems and components
DA TA provides the infrastructure technologies to enable data transac-
tions and exchanges
Table ‎10-32: TA relationship with other architectures

222
The figure below shows the relationships among TA artifacts and the relationships with artifacts
Figure ‎10-19: Relationship TA artifacts
Description about the Agency TA
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.

223
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
6 Infrastructure Overview The high-level representation of IT landscape in the government
agency (normally in diagrammatic form)
7 Infrastructure Description The descriptions of the main infrastructure technologies in use
8 Hardware Catalogue The current list of hardware
9 Software Catalogue The current list of software
Table ‎10-33: TA artifact descriptions
Building the Agency TA
Below table summarizes the main activities for building the agency TA.
1 Define the TA purpose or direction TA purpose / direction statement
2 Define the TA principles TA principles
3 Review the service areas and service
categories (TRM)
Reviewed service categories within service areas for the agency
4 Review the service standards (TRM) Reviewed service standards within each service category relevant
for agency
5 Analyze the data collected Nil
6 Describe the infrastructure overview High-level representation of IT landscape in agency
7 Provide the infrastructure descriptions List of infrastructure technology descriptions in use
8 Develop the hardware catalogue List of hardware in use
9 Develop the software catalogue List of software in use
10 Document and review Reviewed draft current TA
11 Obtain governance approval Approved agency current TA
Table ‎10-34: Activities to build TA

224
1. Define the TA purpose or direction
The TA and TRM purposes are alike. The difference is that the TA purpose can show actual
outcomes directly. Review the TRM purpose, amend and define the TA purpose or direction.
2. Define TA principles
The TA and TRM principles are similar. The difference lie mainly in the operational implementation
of technologies such as performance, sharing of physical assets and security controls. Review
the TRM principles, amend and define the TA principles.
3. Review the service areas and service categories (TRM)
Review the service areas and categories to ensure that these are correct and relevant.
4. Review the service standards (TRM)
Review the service standards defined in TRM. If the TRM was developed long time back (for
example more than three years ago), there may be a need to even review the service categories.
Review all the service standards and make the necessary updates.
5.Analyze the data collected
The data collected should minimally be grouped to the appropriate service standards such as web
browsers (Internet Explorer, Google Chrome), platform dependent (Windows), platform independent
(J2EE, Linux), application servers, portal servers, databases (DB2, Oracle, MySQL), Storage (NAS, SAN,
Cloud), LAN and WAN. Analyze the data to understand the trends or patterns in technology usage.
6. Describe the infrastructure overview
The purpose of this overview is to provide a high-level representation of the IT infrastructure
in the government agency and to develop a comprehensive view of the current infrastructure
components such as the headquarter network and the connected branches, the internet
connectivity, servers farm , LAN, WLAN, communications links, etc. The data collected and
analyzed should be summarized into this infrastructure overview.

225
Provide a pictorial infrastructure overview highlighting the technology components in various
service standards. A example artifact is shown in the figure below.
Figure ‎10-20: Infrastructure overview example

226
7. Provide infrastructure descriptions
The purpose of IT infrastructure descriptions is to provide all the details needed to describe the
current infrastructure components or service standards such as LAN, WAN, Internet, storage and
servers. This view should include at least the following details listed in the table below.
Property Supporting Document
WAN WAN logical diagram
The description about the WAN connectivity at the organization should include but not
limited to the followings:
Number of WAN links , speed of the links ,WAN technology (VPN-MPLS...), name of the
internet service provider (ISP), details of WAN link redundancy ,connected branches
details, GSN connection, Firewall setup details, etc.
LAN LAN logical diagram
The description about the LAN inside the organization should include but not limited to
the followings:
Number of current users (PCs), LAN Speed , service available for each user, VLANs, IP
addressing scheme, links type, access switches details, and etc.
Internet Internet connectivity diagram
The description about the internet connectivity should include but not limited to the
followings:
Internet service provider (ISP) details, link speed and utilizations, load balancer details
and etc.
WLAN Wireless connection diagram inside the agency
The description about the wireless connection should include but not limited to the
followings:
Wireless access setup, wireless access points details, encryption details , etc.
Storage Storage solutions diagram
The description about the storage details should include but not limited to the followings:
Storage infrastructure details, backup descriptions, storage capacity , utilization, and etc.
Server Server farm diagram
The description about the server farm details should include but not limited to the
followings:
Number of servers used, connections details, and etc.
Table ‎10-35: The properties of infrastructure descriptions

227
WAN
Figure ‎10-21: WAN diagram example
Description The organization has only one branch connecting to the headquarter
through (IP/VPN) of STC. Branch office of Jeddah is accessing Riyadh head
office network and system through this VPN connection (30 Mbps) using
Cisco 1800 integrated services routers installed at both ends without
redundancy. This router connect to a firewall (Juniper / SSG550) to
protect the organization’ network .The connection to Yessers’ GSN is
through a dedicated router provided and managed by Yesser and is protected
by firewalls on both ends.

228
LAN
Figure ‎10-22: LAN diagram example
Description
Riyadh head office has client server architecture and there are 1424 users (PCs)
to access the infrastructure facility Cisco 3750G PoE stack switches acting as floor
access switches to provide connectivity to the users and nodes. All access switches
via UTP cable are aggregated to the distribution switch (Cisco 4507) at each building
that have 10 Gbps uplink to the Core switch (Cisco 6509) at the data center . The
IP schemas used at the organizations for the servers : 172.16.0.0/16, and for the
clients: 172.18.0.0/16.

229
Internet
Figure ‎10-23: Internet diagram example
Description
The Internet connectivity is provided by two service providers (STC and Mobily)
through two 20 Mpbs links. Access to the Internet from the organization takes place
through a Microsoft Websense Proxy Server and Web Filter that connects to dual
F5 Load Balancers which provide safe and continues internet browsing capabilities.

230
WLAN
Figure ‎10-24: WLAN diagram example
Description
The current wireless access setup is comprised of a master controller (Aruba
3600) and 73 wireless access points distributed throughout the organization.
Data transmission in the wireless network is secured using WPA2 AES encryption.
The Clearpass 500H is currently being configured to integrate with the Active Directory
for access permissions.

231
Storage
Figure ‎10-25: Storage diagram example
Descrip-
tion
Following are the details of the organization storage:
• Two EMC SAN Storage: EMC VNX5300 with maximum capacity of 360TB and the
utilization is 23%.
• Two MDS Switch: Cisco MDS 9124 multilayer fabric switch with high availability.
As a backup solution, the agency is currently using the Snap Vault solution from Net
App to perform Disk-to-Disk backups (D2D) every day. Jeddah branch currently used as
disaster recovery site (DR).

232
Server
Farms
Figure ‎10-26: Server farm diagram example
Description The server farm typically hosts the most important IT assets in the organization;
it is connected directly to the core switch cisco 4500 .The current technology
infrastructure at the organization utilizes a total of 73 physical servers (62 in the
primary datacenter in Riyadh, and 11 in the DR datacenter in Jeddah . All servers
come with multiple 1GB Ethernet cards, and some servers have converged
network adapters (CNA) allowing them to connect to the SAN. Also the organization
is deploying a VMware virtualization solution. The current virtualization includes 16
SUN/Intel-based servers with 2 CPU/16GB or 2CPU/32B specs. The virtualized en-
vironment currently runs more than 23 different applications. The utilization for all
the servers (virtual and physical) are not exceed 50%.
8. Develop the hardware catalogue
The purpose of the hardware catalogue is to provide a list of hardware components in use
across the agency including servers, switches, storages, routers, firewalls, load balancers, wireless
access point, IPS, IDS, etc.
Based on the data collected, develop the hardware catalogue with the following minimum
details as shown in the example below.

233
Relationship
with national
meta model
Hardware Name The internal name of this component Hardware (Name)
Hardware Type The type of the hardware (server , switch , router , storage,
firewall, controller , wireless access point ,load balancer, etc.)
Hardware (Type)
Model Number The manufacturers model such as cisco 2960x, HP Proliant
460C, NetApp FAS2050, f5 3600 etc.
Hardware (Model Name)
Description Detail description for this component (purpose, functions, ) -
Vendor The manufacturer of the device Hardware (Vendor)
Application Name Business application hosted or supported by this device Application system
(Name)
Location The location details of this device
OS Name The name of the operation system running Hardware(OS name)
IP address The IP address of this device -
Processors details Some details of the device processors (number and speed) -
Capacity details The maximum capacity this device can accommodate. -
Usage details The current usage details of this device -
Connectivity
details
Some details about the device connectivity to the network -
Introduction date The started date in which this device is used Hardware
(Introduction year)
Retirement Date The date that the device will be retired -
Business severity The severity of business impact such as mission critical,
critical, medium, and low
Hardware
(Business severity)
Total cost Total cost of the hardware installation Hardware(Total cost)
Maintenance Cost The annual maintenance cost of the hardware if applicable
Hardware (Annual main-
tenance cost)
Table ‎10-36: The properties of hardware catalogue

234
Hardware Description
Hardware Name Training Server
Hardware Type Server
Model Number Blade HP Proliant 460C Gen8
Description This server host one of the core applications called the training system.
Vendor HP
Application Name Training
Location DC in Riyadh (Basement floor- Cabinet#1)
OS Name Windows 2000 Advanced Server -SP4
IP address 172.16.16.99
Processors details 2 processors (8 core, 2 GHz, 20MB, 95W)
Capacity details 2 x 300 GB (RAID1)
Usage details 19% of the max capacity used.
Connectivity details 1 GB NIC connected to the core switch cisco 4500
Introduction date 10/2013
Retirement Date N/A
Business severity Low
Total cost 18500 SAR
Maintenance Cost N/A
Table ‎10-37: Hardware catalogue example

235
9. Develop the software catalogue
The purpose of the software catalogue is to provide a list of software components in use across
the agency such as OS, productivity tools, middleware, security tools and network management
tools (NMS).
Based on the data collected, develop the software catalogue with the following minimum de-
tails as shown in the example below (which is for only one component).
Relationship with
national meta model
Product/Software
Name
Name of software named by its manufacturer Software
(Name)
Software Type The type of the software (OS, security tool, middle-
ware, NMS, mail, DBMS, productivity tool, etc.)
Software
(Type)
Model / Version Software version/model Software
(Name of SW)
Description Some description about this component
purpose, function…)
-
Vendor Name of software manufacturer Software
(Vendor)
License details Software’s license management policy (users, PCs,
servers, etc.)
Software
(License Policy)
Business Unit Business units supported by this software -
Hosting Hardware
Name/IP
The name of the hosted server -
Number of current
users
Number of current users using this software -
Introduction date the year when the software is installed Software
(Introduction year)
Total cost Total cost of the software installation Software
(Total cost)
Annuala
Maintenance Cost
The cost of SW annual maintenance cost Software
(Annual maintenance cost)
Table ‎10-38: The properties of software catalogue

236
Product/Software
Name
Description
Software Type Network Monitoring Software
Model / Version PRTG - Version 15.4.21
Description PRTG Network Monitor runs on a windows machine within the
network, collecting various statistics from the machines, software,
and devices in order to generate performance reports
Vendor Paessler AG
License details The licensing are based on the number of sensors (unlimited)
Business Unit IT Department
Hosting Hardware Name/IP NMS-Srv / 172.16.16.71
Number of current users N/A
Started date 9/2015
Total cost 89,000 SAR /year including the maintenance cost
Annual Maintenance Cost N/A
Table ‎10-39: Software catalogue example
After drafting all the definitions and standards, document all the relevant information into a
and updates. It is also advisable to get another party (especially the technology and operations
teams) to carry out a final review.
EA Governance Committee. The Chief Architect or Technology Architect should front this pre-

237
10.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 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 of enterprise cutting across silos, establishing
the obvious and not so obvious linkages and dependencies, capturing of synergies etc. facilitate
identification of opportunities for 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 one hand, and to explore ideas for improvement and integration on
the other hand.
The following describes important activities for this step.
S/
No
1 Analyze BA BA improvement opportunities
2 Analyze AA AA improvement opportunities
3 Analyze DA DA improvement opportunities
4 Analyze TA TA improvement opportunities
5 Document and review Reviewed draft summary of improvement
opportunities
6 Obtain governance approval Approved agency summary of improvements
Table ‎10-40: Activities to analyze current architectures

238
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, the Saudi e-Government Plan,
the agency PRM and the agency e-transformation plan (if any). 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).
Figure ‎10-27: Example BA analysis

239
Figure ‎10-28: Example BA improvement opportunities
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, the Saudi e-Government Plan, the agency PRM, prioritized application
list (from agency ARM) and the agency e-transformation plan (if any). The EA Core and working
teams can also use SWOT analysis. Carry out the following activities:
a. List the main issues and challenges faced in 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).

240
Figure ‎10-29: Example AA analysis
Figure ‎10-30: Example AA improvement opportunities

241
3.Analyze DA
Review the current DA.
A recommended method is to compare the DA artifacts against the agency annual plans, the
Saudi e-Government Plan, the agency PRM and the agency e-transformation plan (if any). 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).
Figure ‎10-31: Example DA analysis

242
Figure ‎10-32: Example DA improvement opportunities
4.Analyze TA
Review the current TA.
A recommended method is to compare the TA artifacts against the agency annual plans, the
Saudi e-Government Plan, the agency PRM and the agency e-transformation plan (if any). 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).

243
Figure ‎10-33: Example TA analysis
Figure ‎10-34: Example TA improvement opportunities

244
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 improve-
ment. 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.
EA Governance Committee. The Chief Architect should front this presentation. From the com-
ments from the committee, make the necessary changes to obtain their final approval.

245
Stage7–BuildTarget
Architecture

246
11. Stage 7 – Build Target
Architecture
11.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 out-
comes 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 selective relevant architectures
depending on its EA scope and development strategy.
11.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.

247
With the completion of the previous stages, the EA Core Team and working teams have to en-
sure 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.
Below table list the key activities and expected deliverables for stage 7.

248
Stage /
Step No
7 Build Government Agency’s Target Architectures
7.1 Define directions for developing target architecture
by analyzing environmental factors such as agency’s
vision/principles, current architectures etc.
Target Architecture direction
7.2 Analyze and build the target business architecture
based on architecture principles, current business ar-
chitecture’s analysis result, and current business ar-
chitecture deliverables.
Government Agency’s target
7.3 Analyze and build the target application architecture
based on architecture principles, current application
architecture’s analysis result, and current application
architecture deliverables.
Application
Architecture
7.4 Analyze and build the target data architecture based
on architecture principles, current data architecture’s
analysis result, and current data architecture deliver-
ables.
Data Architecture
7.5 Analyze and build the target technology architecture
based on architecture principles, current technology
architecture’s analysis result, and current technology
Technology
Architecture
11.4.1 Step 7.1 Define directions for developing target architecture
In the previous stage, the team has 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.

249
S/
No
1 Review agency EA vision and principles Reviewed agency EA vision and principles
2 Review environment and requirements analysis Nil
3 Review current improvement opportunities Nil
4 Summarize target architecture directions Target architecture directions
5 Document and review Reviewed draft target architecture directions
6 Obtain governance approval Approved target architecture directions
Table ‎11-2: Activities for defining target architecture directions
1. Review agency EA vision and principles
Review the EA vision that agency desires to reach and review principles to build an architecture
on, and get some implications to develop agency’s target architecture.
Figure ‎11-1: Example of EA principles review and its implications

250
2. Review environment and requirements analysis
Review the environment and EA requirements analysis done in the early stages. These would
provide the overall scope and priority areas in the EA development. Analyze and gauge the need
for adjustments or changes. Thus, this will ensure that architecture directions would be aligned
with the overall agency EA purpose.
3. Review current improvement opportunities
From the detailed review of opportunities done in the previous stage, identify improvement
opportunities in each architecture area (business, application, data, technology). It would be
good to consider the implications of these improvements to the government agency. The EA
Core and working teams should review other strategies such as KSA 2030 Vision and the Saudi
e-Government Action Plan. It is also important to review the agency PRM to help in setting
performance measurements. Combine all these inputs to develop all the potential opportunities.
Prioritize these opportunities based on the above reviewed principles and environment analysis.
Finally, consider and plan the implementation of these opportunities so they can meet the
agency’s strategic goals or outcomes.
Figure ‎11-2: Example agency improvement opportunities for various architectures

251
4. Summarize target architecture direction
Summarize and organize findings such as agency’ EA vision, principles, etc., and analysis results,
and define EA directions for building target architecture (as to business, application, data, and
technology).
Figure ‎11-3: Example of target architecture direction through overall analysis
Document all the information above into a summary with clear recommendations on the target
architecture directions and the high-level schedules aligned with KSA and agency’s strategic
targets. Carry out an internal review. It is also recommended that another party (for example
the agency Strategic Planning Unit) review these target directions.
Present the summarized target architecture directions to the EA Governance Committee. Note
that this will be the first useful EA output that the EA Governance will see. Thus, expect some
questions and more ideas from the committee members. From their feedback, make the necessary
updates and obtain their approval.

252
11.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 agen-
cy. 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 about the future scenarios –
i.e. providing solutions to the current issues and challenges.
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
6 Sub-Business Functions (BRM) The sub-business function descriptions within each
business function
7 Business Processes The target list of business process descriptions within
each sub-business function; highlight new, improved
and deleted processes
8 Organization Chart The target organization chart for the agency
9 Service Catalogue The target list of business services; highlight new,
improved or deleted services
Table ‎11-3: Target BA artifact descriptions
Building the agency target BA
Table 11-3 summarizes the main activities for building the agency target BA.

253
S/
No
1 Review the BA purpose or direction and BA
principles
Reviewed / updated BA purpose or direction
statement
2 Review the BA principles Reviewed / updated BA principles
3 Define the target business functions (BRM) Reviewed / updated business areas, LoBs,
business functions and sub-business func-
tions
4 Define the target business processes List of target improved business processes
for the agency
5 Define the target service catalogue Target service catalogue
6 Document the target organization information Target organization chart
7 Document and review Reviewed draft target BA
8 Obtain governance approval Approved agency target BA
Table ‎11-4: Activities to build target BA
Using the target architecture directions as an input, do the following:
1. Review the BA purpose or direction
Review the BA purpose or direction. The purpose should be applicable for the target BA. Make
the necessary changes if required.
2. Review the BA principles
Refer to the changes in the EA principles if any. Review and make the necessary changes if required.
3. Define the target business functions (BRM)
Review the business areas, LoBs, business functions and sub-business functions. From the tar-
get architecture directions, identify and analyze the areas of improvements such as removal of
duplicated functions, improve customer service and improve business performance. Document the
changes required especially for the business functions and sub-business functions.

254
Figure ‎11-4: Example of updated business function in target BA
4. Define the target business processes
From the above recommendations for target business functions and sub-business functions,
review the affected processes that require change. Similarly, these processes include duplicated
processes, and processes affected to improve customer service and business performance.
Below is an example of updated business processes.

255
Figure ‎11-5: Example of updated business processes in target BA
5. Define the target service catalogue
Upon identification of the target business functions, sub-business functions and business
processes, the EA Core and working teams have to identify all the current services affected.
Analyze them and define the target services, i.e. new services, removal of duplicated services,
joint or integrated a few services into one, and improve quality of services.
6. Document the target organization information
Since business processes and business services will change, so does the staff and organization
structure. Review and document the changes required for the target organization chart and
related information.
Document all the above information according to the agency’s documentation standards. Do
an internal review and updates. It is also advisable to get another party (especially the business
owner and business teams) to carry out a final review.

256
11.4.3 Step 7.3 Build target application architecture
Description about 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 about the future scenarios
– i.e. providing solutions to the current issues and challenges such as new application systems.
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 about the application functions
8 Application Relationships The target description about the application relation-
ships
9 Application Overview The target overview description of the application systems
Table ‎11-5: Target AA artifact descriptions

257
Building the agency target AA
Below table summarizes the main activities for building the agency target AA.
1 Define the AA purpose or direction Reviewed / updated AA purpose or direction statement
2 Define the AA principles Reviewed / updated AA principles
3 Define the target application systems,
application components and application
interfaces (ARM)
Target application systems, application components and
application interfaces
4 Document the target application overview Target application overview
5 Document the target application catalogue Target application catalogue
6 Document the target application func-
tions and relationships
Target application functions and application relationships
7 Document and review Reviewed draft target AA
8 Obtain governance approval Approved agency target AA
Table ‎11-6: Activities to build target AA
1. Review the AA purpose or direction
Review the AA purpose or direction. The purpose should be applicable for the target AA. Make
2. Review the AA principles

258
3. Define the target application systems, application components and
application interfaces (ARM)
Review the current application systems, application components and applications interfaces.
From the target BA, identify affected applications, components and interfaces that are required
to support the future business landscapes.
From the target architecture directions, further explore ways to improve sharing of application
systems and components in the agency. In addition, explore ways to use national or govern-
ment-wide application systems.
Similarly, from the target architecture directions identify how future data usage will affect the
applications. Find solutions to these data usage and exchange and update the target application
systems, components and interfaces.
Below is an example to identify new application systems.
Figure ‎11-6: Example process to identify new application systems & architecture

259
4. Document the target application overview
Once the target applications, components and interfaces have been identified, document them
into the target application overview. This is a pictorial representation of the target applications
for the government agency.
5. Document the target application catalogue
Similarly, refer to the current application catalogue and update it to reflect the target state.
Preferably, include the target application information such as application type (new, replace or
retire) and the current business processes affected. Thus, the target application catalogue has
to link with the target business processes and target service catalogue.
6. Document the target application functions and relationships
From the list of target application systems, update the application functions and relationships.
Typically, it is good to highlight the changes for the target information. Below is an example of
the updated application function.
Figure ‎11-7: Example of updated application function in target AA
With the completion of the various application documentation, consolidate them into one
structured document according to the agency documentation standards. Carry out an internal
review to verify all the data and artifacts. It is also recommended that an external or third party
(for example application owners) carry out another review. Based on their feedback, make the
necessary improvements.

260
11.4.4 Step 7.4 Build target data architecture
Description about 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 about the future scenarios
– i.e. providing solutions to the current issues and challenges in terms of data usage and data
exchange.
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
7 Conceptual Data Model The target pictorial high-level description of data
model for the agency
8 Logical Data Model The target logical data models of the agency
9 Data Flow Diagrams The various target pictorial representations of data
flows for the agency
10 Database Portfolio Catalogue The target consolidation of all databases in the agency
11 Data Dictionary The target definitions for common data in the agency
Table ‎11-7: Target DA artifact descriptions

261
Building the agency target DA
Below table summarizes the main activities for building the agency target DA.
1 Review the DA purpose or direction Reviewed / updated DA purpose or direction
statement
2 Review the DA principles Reviewed / updated DA principles
3 Update data model, data classifications,
data structures and data exchanges (DRM)
Updated target data model, data classifications,
data structures and data exchanges
4 Document the target conceptual and logi-
cal data models
Target conceptual data model and target logical
data model
5 Document the target data flow diagrams Target data flow diagrams
6 Compile the target database portfolio
catalogue
Target database portfolio catalogue
7 Document the target data dictionary Target Data dictionary
8 Document and review Reviewed draft target DA
9 Obtain governance approval Approved agency target DA
Table ‎11-8: Activities to build target DA
1. Review the DA purpose or direction
Review the DA purpose or direction. The purpose should be applicable for the target DA. Make
2. Review DA principles

262
3. Update data model, data classifications, data structures and data ex-
changes (DRM)
Review the data model, data classifications, data structures and data exchanges. With the new
target architecture directions, identify artifacts that require update. With the changes in both
the target BA and AA, it is normal that these artifacts collectively require change. The diagram
below illustrates an example to identify and update the artifacts to reflect the future scenarios.
Identify and make the necessary changes to reflect the future state for the data model, data
classifications, data structures and data exchanges.
Figure ‎11-8: Example of identified artifacts for updates in target DA
4. Document target conceptual and logical data models
The target BA and AA will affect the target DA. With the updates done in the above step, there
is a need to review and update the conceptual data model – for example, adding new data enti-
ties and removing of current data entities. It is also necessary to review and update the logical
data models to reflect the additional or changed data attributes and primary or secondary keys.
5. Document the target data flow diagrams
This activity is to review and document the changes to the data flows. With the above changes,
make the necessary updates to the current data flows. Highlight or associate the changes to the
new data models, data entities, and even the new business processes and application systems.

263
6. Compile the target database portfolio catalogue
A significant change would be to the database portfolio catalogue. Review the current cata-
logue and compile the target catalogue. The diagram below is an example of the changes
required to various databases.
Figure ‎11-9: Example updated database diagram
7. Document the target data dictionary
Finally, review the current data dictionary and update the documentation to reflect the target
data dictionary. It is necessary to describe the difference in the data elements and definitions
from current to target.
Upon completion of the above deliverables, document all the relevant information into a struc-
tured target DA document base on the government agency’s documentation standards. Carry
out an internal review and appropriate updates. It is also a good practice to get an external
party to review the DA document such as DBAs and business owners.

264
EA Governance Committee. The Chief Architect or Data Architect should front this presenta-
tion. From the comments from the committee, make the necessary changes to obtain their
final approval.
11.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 about the future scenarios –
i.e. providing technology solutions to the current issues and challenges.
S/
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
6 Infrastructure Overview The target high-level representation of IT landscape in the government
agency (normally in diagrammatic form)
7 Infrastructure Description The target descriptions of the main infrastructure technologies for future
8 Hardware Catalogue The list of hardware (no change; only when actual implementation)
9 Software Catalogue The list of software (no change; only when actual implementation)
Table ‎11-9: Target TA artifact descriptions

265
Building the agency target TA
Table 11-10 summarizes the main activities for building the agency target TA.
S/
No
1 Review the TA purpose or direction Reviewed / updated TA purpose or di-
rection statement
2 Review the TA principles Reviewed / updated TA principles
3 Review the service areas and service cat-
egories (TRM)
Reviewed service categories within ser-
vice areas for the agency
4 Define the target service standards Target service standards within each
service category relevant for agency
5 Describe the target infrastructure over-
view
High-level representation of target IT
landscape in agency
6 Update the target infrastructure descrip-
tions
Target infrastructure technology de-
scriptions and diagrams
7 Document and review Reviewed draft target TA
8 Obtain governance approval Approved agency target TA
Table ‎11-10: Activities to build target TA
1. Define the TA purpose or direction
Review the TA purpose or direction. The purpose should be applicable for the target TA. Make
2. Review TA principles
Refer to the changes in the EA principles if any. Review and make the necessary changes if
required.

266
3. Review the service areas and service categories (TRM)
Review the service areas and categories to ensure that these are correct and relevant. From
the target architecture directions, review if impact on the service areas and service categories.
Typically, there will be some changes required. The diagram below shows an example of how
the technology directions will affect the technology contents or service categories. Make the
relevant changes to reflect the future state.
Figure ‎11-10: Example of direction setting for in TA
4. Define the target service standards (TRM)
Once the service areas and service categories have been updated, the EA Core and working
teams have to define the target service standards that may include new standards or replacement
of current standards. It is also necessary to define obsolete standards.
5. Describe the target infrastructure overview
Compare the target service categories and standards with the current infrastructure overview
diagram. Simple analysis would allow the team to identify transformation or improvement areas
as shown in the example diagram below. Identify them and update the diagram into the target
infrastructure overview.

267
Figure ‎11-11: Example of updated infrastructure overview in target TA
6. Update the target infrastructure descriptions
Review the current infrastructure descriptions. From the areas of improvements identified above,
update the appropriate infrastructure descriptions. Note that in most cases the descriptions do
not change much, but rather the corresponding technology diagrams that require updates.
After updating all the definitions and standards, document the relevant information into a
and updates. It is also advisable to get another party (especially the technology and operations
teams) to carry out a final review.
With the completion of the deliverables with the other above related contents, present to
the EA Governance Committee. The Chief Architect or Technology Architect should front this

268
Stage8–Develop
TransitionPlan

269
12. Stage 8 – Develop
Transition Plan
12.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 would not be realized.
The transition plan is about defining and prioritizing intermediate activities, systems and projects
in order to implement that 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.
12.2 Stage purpose
The purpose of this stage to manage the transition between the current states to the target
state. The expected outcomes or deliverables of this stage is:
1. Transition Plan.
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.

270
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.
Below table list the key activities and expected deliverables for stage 7.
Stage /
Step No
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
8.4 Analyze and document required
resources and outcomes
Transition resource plan
8.5 Obtaining governance approval Approved transition roadmap and resource plan
12.4.1 Step 8.1 Define transition projects
This activity is about defining and prioritizing transition projects.
S/No Activity Description
1. Define Ideas for Improvement Improvement ideas are defined by classifying them into
business/application sectors or with agency’s core busi-
ness functions
2. Define Transition Projects Transition projects are defined by listing up ideas for im-
provement, a target architecture, and each architecture
area.
List transition projects from the current and target
architecture gap analysis and complete the project
list by adjusting and organizing them while consid-
ering priority, sequence, etc.
Table ‎12-2: Activities to define transition projects

271
Figure ‎12-1: Example selection method for transition plan
Figure ‎12-2: Example of transition project
12.4.2 Step 8.2 Prioritize transition projects
After defining all the required transition projects, it is necessary to prioritize them. The table
below lists the key activities to prioritize these projects.

272
S/
No
1. Define Project Value • Define their values according to relationships be-
tween projects, such as the project’s characteristics,
importance, effectiveness etc.
2. Define Priorities • Prioritize them based on results of their validity
and risk assessment with considering relationships
between projects
3. Define Stages for Project • Based on projects and their priority assessment,
define transition projects by stage
Table ‎12-3: Activities to prioritize transition projects
Figure ‎12-3: Example prioritization principles

273
Figure ‎12-4: Example priority assessment structure
Figure ‎12-5: Example priority assessment

274
Figure ‎12-6: Example transition projects by stages
12.4.3 Step 8.3 Create transition roadmap
Make EA transition roadmap according to the project’s priority, interface, and pre / post rela-
tionships, and develop a detailed schedule by each project.
S/
No
1. Write project purposes in each stage Set an overall planning phase or stage (3 - 5 years)
and define desired objectives by year
2. Write a transition project roadmap in
each stage
List up projects of higher priority in each stage
Write it by mapping each transition project with
each stage
3. Write a detailed schedule by each
transition project
Write a detail schedules for each project and its
sub-projects
Table ‎12-4: Activities to create transition roadmap

275
Figure ‎12-7: Example of goal setting for each stage
Figure ‎12-8: Example detailed schedule by each stage

276
12.4.5 Step 8.4 Analyze and document required resources and outcomes
Estimate the required resources for all projects and analyze expected outcomes according to
the EA project plan in each stage.
S/
No
1. Define a method of estimat-
ing required resources
Define type of required resources and an estima-
tion method according to the type in order to de-
duct required resources by each classification
2. Estimate required resources
by each transition project
Estimate required resources by each transition proj-
ect according to their type
3. Estimate required resources
by year
Estimate required resources by year according to EA
Transition roadmap in each stage
4. Define expected outcomes Write a detail schedules for each project and its
sub-projects
Table ‎12-5: Activities for estimating resources and outcomes
Figure ‎12-9: Example resource estimation procedure

277
Figure ‎12-10: Example required resource classification
Figure ‎12-11: Example resource estimation
Figure ‎12-12: Example resource requirements by stage

278
Figure ‎12-13: Example expected outcome
Some general considerations:
• Although subject to the agency and their environment, it is normal to set a transition period
to target architecture as 3 - 5 years. In this case, it is a good way to make “transition archi-
tecture”, middle-stage of target architecture that can play role of a milestone to transition.
• Because of a sudden change of business environment, technology development, etc. a transition
plan as well as developed target architecture can be modified. Therefore, both target architecture
and transition plan should be managed by EA.
• Whether a transition plan is succeed or not depends on concreteness and realistic possibility
of the plan. In other words, we should consider ‘is it reasonable when it comes to expense/
effectiveness analysis?’, ‘does it fully reflect users’ requirements on target architecture?’, ‘do
agency’s stakeholders fully participate in developing transition plans and fully understand
the contents?’ etc.
• The transition to target environment does not happen rapidly, but is perform gradually by
each architecture area or transition stage according to EA transition plan. Because of this, it
takes much time to completely transit to target environment, and a transition process and

279
transition elements are very complicated. Therefore, for successful transition, we should
minimize risks against changes, protect investment, organize plans for secure transition,
and reflect them on a transition plan.
12.4.5 Step 8.5 Obtain governance approval
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.

280
Stage9–Develop
ManagementPlan

281
13. Stage 9 – Develop
Management Plan
13.1 Stage summary
This stage is about developing the EA usage and management plans so that EA processes and val-
ues become an integral part of the agency 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.
13.2 Stage purpose
The purpose of this stage is to analyze and document the plan in ensuring 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
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 un-
der Continuous Governance section – on particular, on EA usage and EA management directions.

282
The table below lists the key activities and expected deliverables for stage 9.
Stage /
Step No
9 Develop Management Plan EA Usage and Management Plans
9.1 Develop EA usage plan EA usage plan
9.2 Develop EA management plan EA management plan
9.3 Obtaining Governance Approval Approved EA usage and management plans
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 de-
.velopment of these plans
13.4.1 Step 9.1 Develop EA usage plan
It is an activity to specify EA usage ways by defining its purposes and scope through analyzing
agency’s environment & possible users. The following are the activities to develop the EA usage
plan.
1. Define Usage Purposes & Scope
Based on EA usage policy or direction statements defined under governance section, the EA
Core and working teams have to define the EA usage purposes & scope.

283
S/
No
1.a Define usage purposes • Based on above Identifying, define usage purposes as
to make them a common decision-making standard
for achieving EA implementation purposes & expected
outcomes
• Above purposes are comprehensive. So, they also can be
defined specifically, like core use purposes, supplementary
use purposes, etc.
1.b Define usage scope • Based on above Identifying, define EA usage scope by
grouping shared elements
• EA usage scope of agencies doing EA demonstration
project is defined as a IT life cycle, such as IT planning,
IT project performing, IT operation, IT assessment, etc.
Table ‎13-2: Activities to define EA usage purpose & scope
Figure ‎13-1: Example for EA usage purposes

284
Figure ‎13-2: Example for EA usage scope
2. Usage Plan Development
In order that the agency performs practical IT projects using architecture information, they need
guidelines that describe which each EA usage scenario can use the appropriate architecture infor-
mation. Define EA usage process by each scope, in order that the EA supports common decision-
makings while performing practical IT projects.

285
S/
No
2.a Define Usage
tasks
• Identify and define EA usage tasks based on its objectives and
scope.
2.b Define possible
users
• Define directly/indirectly related-stakeholders with EA projects
• Among stakeholders, Identify future EA users through holding
internal meetings
• Define EA user groups by classifying them with their roles, and
define each group’s roles and responsibilities
• In addition, define roles related to using architecture information
2.c Define Usage
scenario
• Write a business flow based on business activities and related
organizations that are defined in usage tasks
• Identify and define business activities which are required to
use architecture information by each usage task
• Define which architecture information can be used for doing
each business activity. In other words, we can define the
name and item of specific artifact.
2.d Develop Usage
Guideline
• Define a list for using EA information, and make a guideline
• Based on usage scenario, write a guideline for fully using EA
by each task.
Table ‎13-3: Activities to define usage plan development

286
Figure ‎13-3: Example for EA usage tasks
User Main role Related organization
Decision-Maker - A final decision-maker about business
innovation, IT project promotion, and IT
project policies
The official in charge of IT
IT Promotion Committee
Architecture Review Commit-
tee
IT Investment Review Board
IT Planning De-
partment
- Making mid and long term IT plans
- Budgeting on unit information system
development/ operation and assessing the
results
IT Planning Team
Budget Planning Team
Architecture Man-
agement Depart-
ment
- Managing the information such as EA stan-
dard, etc.
Architecture Management
Team Architecture Group
User/ Business
Department
- As being in charge of agency’s businesses,
they also offer requirements from users, etc.
International Affairs Division
Public Service Center

287
User Main role Related organization
IT Project
Department
- They are in charge of unit system develop-
ment, from project planning to system
development/ operation
System Development Group
System Maintenance Group
System
Development
Department
- Most of them are external agencies which
are in charge of system development
System Development Team
System Operation
Department
- Most of them are external agencies which
are in charge of system operation
System Operation Team
Table ‎13-4: Example for EA users
Figure ‎13-5: Example for the relationship between EA tasks and artifacts
3. Obtaining Governance Approval
EA Governance Committee. The Chief Architect should front this presentation. From the com-
ments from the committee, make the necessary changes to obtain their final approval.

288
13.4.2 Step 9.2 Develop EA management plan
The value of EA is for it to be utilized when making decisions with using pertinent information
and linkages. It is important to maintain accuracy and consistency of EA information; hence, EA
management plan helps to maintain EA continuously by not only setting EA directions but also
making EA management structure and EA management process. The following are the simple
activities to develop the EA management plan.
1. Define EA Management Purposes & Scope
Based on the EA management policy defined under governance, define EA management pur-
poses & scopes, and develop EA management principles.
S/
No
1.a Define EA
management
purposes
• Define EA management purpose which matches agency’s architecture
purposes & directions from best practices
1.b Define EA
management
scope
• Define EA management scope with considering EA project purposes,
scope, principles, and purposes for EA use
• Identify maintenance-needed-elements with referring to identified
management scope
• EA management targets are organizations, human resources, systems,
application, architecture’s artifacts, etc.
• Define the organization’s EA management scope with referring to above
identified management scope and target elements
• Check if developed EA management scope has omitted items by refer-
ring to other agencies’ EA management scope and targets
• Confirmed EA management scope in here includes defining an
organization, management process, management support system, etc.
1.c Define EA
management
principles
• Identify key management points for defining management principles
(organization, competency, operation, methods for review, system, etc.
• Define management principles by each management point which EA
management plan should follow for achieving management purposes
Table ‎13-5: Activities of EA management purposes & scope

289
Figure ‎13-6: Example of EA management plan
Figure ‎13-7: Example of EA management scope

290
Figure ‎13-8: Example for EA management plan process
Figure ‎13-9: Example for EA management plan principles

291
2. Develop EA Management Organization
Define EA management organization’s structure & roles for maintaining EA, EA management
process for following architecture principles and attaining architecture goals, and EA manage-
ment support systems for supporting it.
S/
No
Activities Description
2.a EA management
organization definition
• Figure out management tasks and their required functions
by checking management scope and targets
• Based on management tasks and functions, figure out
required organizations that can perform the tasks
• If there are no related organizations that can perform the
tasks, we can create a new organization
• Based on the tasks and organizations, we can define their
organizational structure by building up a decision-making
structure for performing the tasks
2.b EA management
organization’s roles
definition
• Analyze stakeholders of a management organizational
structure, and identify their required roles
• Define their roles that define responsibilities and authori-
zation by the management organizational structure’s each
organization
• Based on roles, redefine the organizational structure, and
make an institutional change plan
Table ‎13-6: Activities to develop EA management organization

292
Figure ‎13-10: Example for EA roles for large organization
Figure ‎13-11: Example for architect tasks

293
3. Define EA Management Process
In EA governance section, there are five aspects such as change, program, performance,
capability, and policy management. In this section, it will provide more detail processes of
EA management.
S/
No
3.a Define EA planning
process
• Define EA planning process by developing EA and reflecting
any improvements of EA.
3.b Define EA change
management process
• Define EA change management process of maintaining and
updating EA information
• Define EA change management process which includes
overall process from requesting, processing, to releasing
changes
• Architecture update: define a process of regular
planning and target architecture designing for architecture
improvements
• Architecture change: define a process of reviewing and
authorizing change requests
• Architecture diffusion: a practical way of performing
can be different according to an architecture diffusion
target and channel. We can develop a process of planning,
execution, and feedback for architecture diffusion
• Architecture compliance review: develop a process
of checking if it complies with ‘current architecture’ in IT
system development project
• Design for exceptions: develop a process of designing
alternatives to the architecture, with which we can review
validity of exceptions and applying them
• Architecture-based IT system design: providing an
outline of IT systems based on architecture and target
architecture in order to support IT system development
3.c Define EA use support
process
• Define EA support process for smoothly sharing and using
EA information

294
3.e Define a system
management process
• Define a process of managing and operating management
systems used for maintaining EA information
• Based on management system’s operating organizations,
define a system operation process, such as system change
process, system back-up process, etc.
• Define a process with referring to a guideline for operating
IT systems
3.f Define an
assessment process
• Define a process of assessing EA information’s use & man-
agement
• The agency can assess outcomes by themselves through de-
veloping their own performance indicators with reference to
performance reference model in EA development phase
• Agency can assess agency’s EA maturity level with reference
to EA maturity model that was made by Yesser (refer
Annex E)
Table ‎13-7: Activities to define EA management process
Figure ‎13-12: Example for EA update process

295
Figure ‎13-13: Example for EA change process
Figure ‎13-14: Example for EA diffusion process

296
Figure ‎13-15: Example for EA compliance review
Figure ‎13-16: Example for EA design exception process

297
Figure ‎13-17: Example for EA system design
4. Develop EA Management System
Develop EA management system for continuously maintaining and using EA artifacts and EA-
related information.
S/No Activities Description
4.a Define
requirements
• Checking and organizing basic functions of management systems
• Define a function of using EA artifacts information in terms of various
tasks
• Define a function of continuously maintaining EA artifacts information
• Define a function of linking with management tools which are used for
creating artifacts
• Define a function of linking internal systemsㅡlinking assets
management system, performance management system, and
business management system, which are operated by the
agency, themselves, with EA information
• Define linking functions required to offer agency’s EA artifacts in-
formation to national EA management system
4.b Build up
a system
• After defining system requirements, a system can be built based on
them with using system development methodology. Development
methodology can be referred to for system buildup.
Table ‎13-8: Activities to define EA management system

298
See below table of example requirements.
Function Description
Framework Management Managing a framework, a standard for managing agency’s
EA systematically
Meta-model Management Registering and managing standardized Meta-model to
register artifacts
Reference Model Management Registering and managing BRM, ARM, DRM, TRM, and PRM
Artifact Management Registering and managing EA artifacts
Architecture Analysis Analyzing architecture artifacts with various types
System Management Managing system, such as user management, authoriza-
tion management, etc.
Table ‎13-9: Example for EA management system’s functions
5. Develop EA Management Guideline
EA management guideline helps to update EA on the current status against changes of projects
or IT systems, and is composed of management principles, organizations, and process.
6. Obtaining 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.

299
Stage10–Execute
andMaintain

300
14. Stage 10 – Execute and Maintain
14.1 Stage Summary
This is the last stage where a government agency executes and maintains its EA. Having cov-
ered many stages in the EA journey, this last stage concerns with taking actions to make the
government agency’s EA into a reality.
14.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 the using and maintaining the various information related to EA
3. Execute or implement the EA including the management of the transition activities
14.3 Stage Initiation
With the completion of the previous stages, the EA Core Team and working teams have to en-
sure 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.

301
14.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 14-1.
Stage /
Step No
10 Execute and Maintain
10.1 Implement the EA Usage & Management Plan Project/Program Management
Deliverables
10.2 Implement the EA Transition Roadmap Project/Program Management
Deliverables
14.4.1 Step 10.1 Implement the EA usage & management plan
Another challenge for the EA Core team and working teams is the actual implementation of
the EA usage & management plan that was prepared in the previous phase. It is one thing to
prepare the plan, but it requires effort and coordination to actually implement the EA usage &
management Plan. This is where all the organization, systems, resources and the governance/
management processes are implemented in a coordinated manner.
The EA Core team has to ensure that the EA usage & management plan are executed according
to the details in the plan. To some extent, some of the areas in the plan have been covered or
described in the steps above such as EA governance / management including the change man-
agement aspect. A few important things to note are:

302
1. Institutionalization the usage & management plan
It’s required to make EA usage & management guideline mandatory in order to continuously
manage and use EA and make an internal notice of whether the guideline is followed to all
organizations.
Figure ‎14-1: Example for EA usage guideline

303
Table ‎14-2: Example for EA management guideline
2. EA usage and management plan execution
We can use EA at work based on the EA usage and management guideline. All EA information
and related artifacts should be regularly or instantly updated as change management process
after that we can execute EA plans smoothly. In case EA system has been developed, we can
derive and use EA information from it based on EA use scenario.
3. EA usage and management plan supervision
EA team’s manager can supervise the status of EA operation and usage according to EA
guidelines. Continuously monitor whether EA management processes and EA usage sce-
narios are being well obeyed. In case EA system has been developed, we can figure out EA
utilization status by using statistics, etc. from the EA system.

304
4. EA usage and management plan assessment
Define assessment elements to evaluate EA usage and management plans and regularly (once
a year) conduct assessments by investigating and interviewing stakeholders.
Elements Key contents
Compliance
1
Have all the usage & management tasks specified in EA guidelines been
applied at work?
Check them by making a list of usage & management tasks in EA
guidelines
T/F
2
Has architecture information been updated according to EA usage &
management process?
Check them by making a list of architecture information to be updated
T/F
3
Does the person in charge use/follow EA usage/management procedures
regarding to their tasks?
Check them by making a list of usage & management tasks
T/F
Compatibility
1
Is EA usage & management process correct?
Check them by making a list of EA usage & management processes
T/F
2
Is architecture information updated according to a usage & management
process correct?
Check them by making a list of architecture information by each EA us-
age & management task
T/F
Convenience
1
Isn’t EA usage & management process complicated?
Check them by making a list of EA usage & management tasks
T/F
2
Does it take too much time to process EA usage & management tasks?
Measure time of processing each EA usage & management tasks
T/F
3
Is it easy to update EA information according to each usage &
management tasks?
Can use 1-5 point scale
4
What’s satisfaction level caused by utilizing & managing EA?
Can use 1-5 point scale
Table ‎14-3: Example for EA usage & management plan assessment

305
5. EA usage and management plan improvement
Based on the results of EA usage & management plan assessment, its improvement directions
can be defined and EA usage & management plan can be supplemented and enhanced.
14.4.2 Step 10.2 Implement the EA transition roadmap
The transition of EA from the current state to the eventual target is a challenging task, but with
great satisfaction when it is completed successfully. In the implementation of the EA Transition
Roadmap, the EA Core team and working teams have to act as coordinators (between projects
and divisions) and advisors (on what the project owners should do and when).
While the previous step tackles all the management / governance areas, this step focuses on
the basic steps to implement the transition projects and activities. With the EA Transition Road-
map prepared in the previous phase, the implementation of this roadmap has three main activi-
ties as follows:
1. Review and update the EA Transition Roadmap
Since the EA Transition Roadmap was prepared and approved, there are many activities such as
conducting awareness sessions, presentation to the stakeholders and discussions on new ini-
tiatives. Over time, some of these discussions could spin off other projects or affect the original
schedule and priority of the projects in the transition roadmap. It is necessary, therefore, to review
and update the EA Transition Roadmap from various feedback, suggestions and new directives
from top management. The following are recommended activities:
a. Add, update or remove the projects identified; if need be, re-prioritized the whole list of
projects
b. For each project, identify and confirm the project owner. In addition, check the resources
and schedules are reasonable. If not, update the resources required and time needed to
complete the projects
c. Update the Transition Roadmap. If major updates were done, get approval from the EA Gov-
ernance Committee
d. Also update the Program Management Plan correspondingly.

306
2.Assign projects to Project Owners
With the approved updated EA Transition Roadmap, the EA Core team has to inform and assign
the projects to the respective project owners. It is recommended that each project carry out
the following:
a. Formation of Project Team (Project Owner, Project Manager and Project Members)
b. Briefing to the Project Team by the EA Core Team on expected deliverables and resources
provided
c. Formalize communication channel for Project Team to update and report progress to the EA
Program Manager. Key Performance Indicators (PKIs) have to be established so that the EA
Transition Roadmap can be tracked and the overall progress can be updated to the EA Gov-
ernance Committee.
3.Track and report progress of transition
Last but not the least, all the projects and major activities in the EA Transition Roadmap have
to be tracked. For consistent, good program management and tracking of the various projects,
the following are recommended:
a. Centralize all reporting into a management dashboard if possible
b. Determine flags or indicators to measure project progress – i.e. % completion and green,
amber or red flags
c. Occasionally, review the EA program management and link to the relevant EA governance /
management areas in previous step. There may also be a need to update the EA artifacts as
the various projects progress (see next step).

307
Annex A: NORA Summary of
Deliverables by Stages
The following tables summarize the deliverables within the different stages of NORA.
STAGE 1: Develop EA Project Strategy
Item Description
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 to either develop its EA internally or outsource.
Purpose Lay the foundation of a government agency’s EA implementation journey
with clear directions and commitments.
Initiation Yesser will communicate with the e-Transformation Committee in each
government agency to initiate the agency EA implementation. Govern-
ment agencies can also request and discuss with Yesser to initiate their EA
program.
Table ‎14-4: Stage 1 summary

308
Stage /
Step
No
1 Develop EA Project Strategy Government Agency’s EA Project Strategy
1.1 Analyze EA trends and case studies (both
international and local agencies; also
across same line of business /
segment)
Document relevant EA trends and case studies
relating to the government agency
1.2 Provide EA awareness to government
agency’s business and IT leaders
(Government agencies can invite Yesser
to brief on NEA)
Understand the importance of EA
1.3 Assess government agency’s
e-transformation maturity (Via Qiyas)
and its alignment of IT to the government
business
Submit and present the assessment report to the
e-Transformation Committee or equivalent. The
assessment shall describe the agency’s:
1. Maturity of its e-transformation
2. Effectiveness of its business functions
3. Maturity on IT adoption
4. Organization capability on business productivity
and use of IT.
1.4 Document government agency’s EA
project strategy
Draft Government Agency’s EA Project Strategy
project strategy
Approved Government Agency’s EA Project
Strategy by its e-Transformation Committee or
equivalent

309
STAGE 2: Develop EA Project Plan
Item Description
Summary Having established an approved EA Project Strategy, the government agency
has to carry out the detailed plan for the EA project. This stage describes the
key activities involved in developing and obtaining approval for the EA project.
Purpose The government agency has to structure and form appropriate EA team(s)
and develop the detailed EA project plan.
Initiation This stage begins with the endorsement or approval of the EA Project Strategy
in Stage 1.
Stage /
Step No
2 Develop EA Project Plan Government Agency’s EA Project Plan
2.1 Upon approval of the Project Strategy (Step 1.4),
propose and set up the various EA committees
and teams such as EA Governance Committee,
EA Working Team, Business-Domain Working
Team and the IT Working Team.
Approved EA committees and working
teams by the e-Transformation Committee
or equivalent
2.2 Finalize the EA development approach such as
scope, budget, schedule, and including outsourc-
ing or insourcing of the Government Agency’s EA
implementation. Also include the adoption of EA
culture into all aspects of business and IT plan-
ning and reviews
Approved EA development approach by e-
transformation committee or equivalent
2.3 Upon approval of Steps 2.1 & 2.2, the EA working
team will document the detailed EA Project Plan
Draft EA project plan
2.4 Present and obtain approval for the EA project
plan
Approved EA project plan by the EA Gover-
nance Committee

310
Continuous Governance
Item Description
Summary 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 address to ensure the suc-
cess of the project.
Purpose The previous stage has defined he 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.
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 the EA governance is
a continuous activity affecting all stages.
Table ‎14-8: Continuous governance summary
Stage /
Step No
All Continuous Governance Success of Government Agency’s EA Project
1. Track and monitor the key activities and deliverables
of the EA. Highlight to EA Governance Committee on
potential delays, changes in scope, and lack of re-
sources
Program management of Government Agency’s
EA implementation
2. Manage the introduction and changes to the vari-
ous activities in the EA. In particular, carry out ac-
tivities on EA awareness and promotion
Change management especially on awareness
and promotion of Government Agency’s EA
3. Manage the capability requirements for the EA
implementation that includes training, changes to
job scope, and review of division / department or-
ganizational structures
Capability management on the progression on
the government agency’s capabilities to carry
out the EA plans
4. Manage the policies and regulations required to
implement the different factors or activities of the
EA in the government agency
Policy management on the policies and regu-
lations relating to the EA execution
5. Manage the performance outcomes of the EA in
the government agency
Performance management on the metrics, KPIs
and outcomes of the EA
Table ‎14-9: Continuous governance steps

311
STAGE 3: Analyze Current State
Item Description
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.
Purpose The government agency has to carry out requirements study and detailed
analysis of the current state in terms of both business and IT.
Initiation This stage begins with the endorsement or approval of the EA Project Plan
from Stage 2.
Stage /
Step No
3 Analyze Current Stage a. EA Requirements
b. EA Environment Analysis Reports
(Current Business Landscape and
Current IT Landscape)
c. SWOT Analysis Report
3.1 Gather and document EA require-
ments from various stakeholders such
as e-Transformation Committee, EA
Governance Committee, main business
functions’ stakeholders, and EA working
teams
Government Agency’s EA requirements re-
viewed by EA Governance Committee
Agency’s internal environment such as
organizational capability to plan and
execute e-transformation plan, busi-
ness plan and IT plan
nance Committee

312
3.3 Gather and analyze Government Agen-
cy’s external environment such as gener-
al trends in EA, United Nations or similar
e-Government rankings including recom-
mendations, prioritized national projects
and new government policies
nance Committee
3.4 Present to the EA Governance
Committee
EA Governance Committee is informed
about the detailed current state of the
government agency
STAGE 4: Develop EA Framework
Item Description
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 is fundamental to its EA jour-
ney. The government agency should focus on building quality EA framework and
other relevant processes.
Purpose The previous stage gave the EA requirements and environment analysis reports
so that the EA 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.
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.

313
Stage
/ Step
No
4 Develop EA Framework Government Agency’s EA Mission,
Vision, Architecture Objectives and
Architecture Principle Statements
Government Agency’s EA Framework
4.1 Analyze the EA requirements and findings from the
environment report to address the gaps. These gaps
would address what is currently missing and also what
is required to meet future needs
Document gaps i.e. EA requirements
and environment improvements
needed
4.2 Carry out questionnaire and/or brainstorming ses-
sions with key stakeholders to define the EA vision,
mission, architecture objectives and architecture
principles (these statements have to address gaps
identified in Step 2-1)
Draft EA Vision, Mission, Architecture
Objectives and Architecture Principles
4.3 Present and obtain approval from EA Governance
Committee
Approved EA Vision, Mission, Archi-
tecture Objectives and Architecture
Principles
4.4 From the EA Vision, mission, architecture objectives
and principles, define the EA framework structure
Draft EA Framework Structure
4.5 With the EA framework in place, design the archi-
tecture elements
Draft EA Architecture Elements
4.6 Fill up the framework by defining the EA Model and
the relationships between elements
Draft EA Model
4.7 To standardize the EA documents, create the EA
documentation standard
Draft EA Documentation Standard
4.8 Similarly, to ensure quality, define the EA artifact
management processes
Draft EA Artifact management pro-
cesses
4.9 Present the outputs from 4.4 to 4.8 and obtain ap-
proval from EA Governance Committee
Approved EA Framework

314
STAGE 5: Build Reference Models
Item Description
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.
Purpose The purpose of stage 5 is to architect and build the relevant EA reference
models of the government agency.
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 Yesser’s NEA Reference Models. By referring to the NEA refer-
ence models, the government agency can develop their own reference models
ensuring alignment with whole of government as well as to achieve its EA goals.

315
Stage /
Step No
5 Document Government Agency’s Reference
Models
Government Agency’s Reference
Models
5.1 Develop a model that standardizes perfor-
mance elements for improving IT projects
and their quality. Obtain approval from the
EA Governance Committee
Approved Performance Reference
Model
business functions and related information.
Obtain approval from the EA Governance
Committee
Approved Business Reference
Model
shared application systems/components to
promote service integration and reuse by
identifying redundant or correlated appli-
cations. Obtain approval from the EA Gov-
ernance Committee
Approved Application Reference
Model
5.4 Develop a model that classifies data and
defines standard data structures to support
data architecture development, data stan-
dard, and data reuse. Obtain approval from
the EA Governance Committee
Approved Data Reference Model
technologies and technology standards/
specifications, which support business
and services. Obtain approval from the EA
Approved Technology Reference
Model

316
STAGE 6: Build Current Architecture
Item Description
Summary The focus of this stage is in capturing the current architectures of the government
agency so that the agency can clearly understand its IT and business landscapes. This
would allow a better visibility of the interconnections among different architectures
and components, and aid in analyzing the agency’s issues, challenges and opportuni-
ties relating to business, information/data and technologies.
Purpose The purpose of this stage is to analyze and document the status of the current govern-
ment agency’s IT and business landscapes.
Initiation The completion of the relevant reference models from the previous stage.
Stage /
Step No
6 Build Government Agency’s Current Architectures Government Agency’s Relevant Current Ar-
chitectures
6.1 Capture current business and IT data Government Agency’s Current Data
6.2 Analyze and build the business architecture that
describes the current business functions, sub-
business functions, business processes, business
activities and business services
Government Agency’s Current Business Ar-
chitecture
6.3 Analyze and build the application architecture
that lists all the current applications (fully auto-
mated, partial automated & manual), and the
relationships between these applications and the
business functions / processes / services
Government Agency’s Current Application
Architecture
6.4 Analyze and build the data architecture that
shows all the current data used by the govern-
ment agency, the usage of data by applications
including data exchange within and externally
Government Agency’s Current Data Archi-
tecture
6.5 Analyze and build the technology architecture
that illustrates the current IT infrastructure used
by the various applications, data and people
Government Agency’s Current Technology
Architecture
6.6 Current Architecture Analysis Summary of Improvement Opportunities

317
STAGE 7: Build Target Architecture
Item Description
Summary With the completion of the government agency’s current architectures, this stage de-
velops 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.
Purpose The purpose of this stage is to analyze, design and document the target government
agency’s IT and business landscapes.
Initiation The completion of the relevant current architectures from the previous stage.
Stage /
Step No
7 Build Government Agency’s Target Architectures Government Agency’s Relevant
Target Architectures
7.1 Define directions for developing target architecture
by analyzing environmental factors such as agency’s
vision/principles, current architectures etc.
Target Architecture direction
7.2 Analyze and build the target business architecture
based on architecture principles, current business
architecture’s analysis result, and current business
7.3 Analyze and build the target application architecture
based on architecture principles, current application
architecture’s analysis result, and current application
Application Architecture
7.4 Analyze and build the target data architecture based
on architecture principles, current data architec-
ture’s analysis result, and current data architecture
deliverables.
Data Architecture
7.5 Analyze and build the target technology architecture
based on architecture principles, current technology
architecture’s analysis result, and current technology ar-
chitecture deliverables.
Technology Architecture

318
STAGE 8: Develop Transition Plan
Item Description
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.
Purpose The purpose of this stage to manage the transition between the current state
to the target state.
Initiation The completion of the relevant target architectures from the previous stage.
Stage /
Step No
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
8.4 Analyze and document required re-
sources and outcomes
Transition resource plan
8.5 Obtaining governance approval Approved transition roadmap and re-
source plan

319
STAGE 9: Develop Management Plan
Item Description
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 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 gov-
ernment agency.
Purpose The purpose of this stage is to analyze and document the plan in ensur-
ing the EA deliverables are accepted and use by the different stakehold-
ers in the government agency.
Initiation The completion of the activities in the transition stage.
Stage /
Step No
9 Develop Management Plan Management Plans
9.1 Develop EA usage plan EA usage plan
9.2 Develop EA management plan EA management plan
9.3 Obtaining governance approval Approved EA usage and management plans
STAGE 10: Execute and Maintain
Item Description
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 with
taking actions to make the government agency’s EA into a reality.
Purpose The purpose of this stage is to implement the EA artifacts that were docu-
mented in the previous stages.
Initiation The completion of the activities in the previous management stage.

320
Stage /
Step No
10 Execute and Maintain On-going maintenance of the
Government Agency’s EA
10.1 Implement the EA Usage & Management Plan Nil
10.2 Implement the EA Transition Roadmap Nil

321
Annex B: NEA System and EAMS
Government agencies have mandate to fulfill and deliver excellent services concentrated on a
particular vertical. The single-minded focus of the government agency in delivering on their ver-
tical is paramount for success of government. However, there is a need for bringing a whole of
government view, not only for the coherency of government but also to improve on efficiency
and effectiveness across all verticals.
The NEA system can be defined as a central national repository use for the purpose of captur-
ing and facilitating a whole of government view. The goals and objectives for the NEA System
is listed below.
Goals
The goal of this project is to build and operate a NEA system repository that aimed at achiev-
ing NEA Goals and Objectives. This is realized by capturing the information outlined in the NEA
Meta model covering elements of Business and IT.
Objectives
1. Implement NEA repository system to assist in whole-of-government IT planning
2. Facilitate identification of areas for reuse of services, components, systems etc.
3. Capturing the big picture of whole-of-government IT landscape and IT assets.
B1. NEA System Overview
The following system context is used to represent the relevant systems and the key users from a
context point of view, they do not include the details regarding the exact type of systems being
used to provide the required functionality. The purpose of the below diagram is to illustrate the
possible systems/users that is part of the solution.

322
NEA Repository system
Agency User
HTTPS
Agency EA
System
NEA System Admin
API
NEA Meta-Model
HTTPS
CSV
Excel
NEA Member
HTTPS
Public User
HTTPS
NEA Data Analyst
HTTPS
Planning System
Procurement
System
Budget
System
Audit System
National Project
System
API
E Gov Action Plan
BRM ARM DRM
Business Service
Transf Plan IT Project App Systm
Sys Fnct Software Hardware
NEA Maturity Model
Workflow
Service Repository E Forms CRM
Qiyas System
API - Sync
Saudi Portal
Yesser Portal
Existing Yesser Systems
Import
WS
WS
WS
NEA Portal
Figure ‎14-2: NEA System Context
Following are the key elements from the System Context and their purpose in the NEA System.
Agency User: - User from Agency.
Agency EA System: - EA Management system from an Agency.
Public User: - Individual Users who has access to the public information in NEA Repository
External Systems: The NEA repository system needs to interact with other external systems
to gather specific information, such other systems are systems related to Planning, Budgeting,
Procurement, Audit and National Projects etc.
GSB: Yesser has established GSB in order to facilitate integration and exchange of shared gov-
ernment data among various agencies interlinking with GSB. Considering dependency of gov-
ernment services that necessitate interlinking and integration of each agency with other agen-
cies in order to deliver a particular service, GSB plays a pivotal role in facilitating business and
technology integration among government agencies
Other Existing Yesser Systems:

323
Other related Yesser systems and the relevant information with respect to NEA repository are
listed below:
1. Service Repository: The Service repository holds the information regarding the core services de-
livered by the Government Agencies
2. Qiyas System: This system is used to measure the e-Transformation across all the government
agencies
3. E Forms: Agencies utilize the E Forms system to request services like fund request from Yesser
4. CRM: The CRM system for Yesser, the system is Microsoft CRM
5. Saudi Portal: It is the national portal of KSA, it also holds the information regarding Services of-
fered by government agencies, in addition to other relevant information.
6. Yesser Portal: The portal exposes services from Yesser provided to the government agencies.
B2.Agency EAMS
The EA Management System or EAMS is an important component in the NEA Repository system
context.
Most agencies would prefer to keep their agency-wide information in an EAMS. This would
make it convenient for the agency to extract information from its own EAMS and contribute
towards whole of government view within the NEA Repository.
The information from EAMS can be sent to the NEA System either by using appropriate API’s or
via exporting data from the EAMS and importing it into NEA System.

324
Annex C: NEA Meta-Model
C1. Overview of NEA Meta-model
NEA Meta-model comprises of national and agency level elements. The national level elements
try to capture information for whole of government approach from strategic, business, technol-
ogy and data point of view. Agencies provide information regarding similar aspects addressing
the scope at agency level. The elements are linked together strategically as well as taxonomi-
cally to provide end-to-end visibility to the e-Government ecosystem.
Agency E-
transformation
plan
Business
service(SRS)
IT project
Application
system
Data HardwareSoftware
Objectives
DRM ARM
Data Centre
Figure ‎14-3: NEA Meta-Model

325
C2. Objectives of NEA Meta-Model
The primary objective of NEA Meta-model 1.0 is to define a whole-of-government national
Meta-model and toward establishing a whole-of-government architecture. Other objectives are
as listed below:
1. Enhancing understanding about agency’s EA components and standard related information
2. Proposing necessary items that agency should apply in order to link agency’s EA information with
whole-of-government NEA
3. Capturing the current architecture of whole-of-government at the same time keeping it minimal-
istic demands for agencies
4. Providing sufficient linkages to ensure consistency
5. Flexibility to accommodate more elements in future as need arises.

326
C3. NEA Meta-Model Classes
Component Property
Item
Domain
Domain
Restric-
tion
Explanation
Agency
e-Transformation
Plan
ID ID ID
Name Name
Name of Agency e-Transfor-
mation plan
Description Content
Detailed description of
Agency
E-transformation plan
Planned Start
Month
Date
Planned End
Month
Date
Budget Currency
Budget allocated for this
Plan
Objective
ID ID ID of Objective
Objective Name Objective
Description Content
Detailed description
of Objective
Related items
Agency
e-Transformation
Plan
Agency e-Transfor-
mation Plan ID
RefID
IT Project
Name Name Name of IT project
Description Content
Detailed description of IT
project
MoF Project
code
Code MoF Project code
Type Enum
Consultation
Development
Purchasing
Maintenance &
Operation
Licensing
Others
All project types rather
than the above
ⓞ Other types Content
Detailed contents in case IT
project type is others
Status Code
In preparation
Ongoing
Close

327
Component Property
Item
Domain
Domain
Restric-
tion
Explanation
Start month
Month/
Year
MM/YYYY
Project start month/year in
Gregorian
Ex) 05/2013
End month
Month/
Year
MM/YYYY
Project end month/year in
Gregorian
Ex) 05/2014
Project Owner Ex) Yesser, MCIT, etc.
Related items
Agency e-Transformation Plan
Agency e-Transfor-
mation Plan ID
RefID
Objective Objective ID RefID
Application
system
Name Name
Name of App
system
Ex) ERP system, HR
system
Introduction
method
Enum
Purchase
Classification of App, sys-
tem’s introduction method
Dissemination from other
agencies
Outsourcing Development
Self-Development
Others
ⓞ Other
methods
Content
Detailed contents in case
introduction method is
others
Purpose Content
Objective of common
system’s introduction
※reason for being devel-
oped, for which business it
was developed, etc
Development
Year
Year YYYY
Initial development year
of Application system in
Gregorian
Ex) 2010
Development
language
Code
Java
Programming Language or
Development tool used to
build this application
C, C++, .net
Oracle Developer/ADF
PHP
Others
Development
Language
Version
Version
Development Language
Version

328
Component Property
Item
Domain
Domain
Restric-
tion
Explanation
Other lan-
guages
Contents
Detailed contents in case
Development language is
others
Application
Domain
Enum
Acquisition Management
Customer Service
Emergency Management
Financial Management
Grants Management
Workforce Management
Human Resource Manage-
ment
Legal
Physical Safety
Property and Asset Manage-
ment
Security Management
Systems Management
Application
User Interface
Enum
Web Based Application
Window Based Application
Others
Type of Ser-
vice Delivered
Enum
Core Business Services
Supportive Business Services
Internal Use Only
ⓞ Related Law Name
The name of App. system
related Law
Total develop-
ment cost
Number SAR
Total cost of App. system
development excluding
hardware and software
Ex) 100,000 SAR
Annual main-
tenance cost
Number SAR
Total cost of App. system
maintenance excluding
hardware and software
maintenance
Ex) 100,000 SAR

329
Component Property
Item
Domain
Domain
Restric-
tion
Explanation
Cloud Plan Enum
Yes
Weather App. system has
cloud plan or not
No
Already adopted
Don’t know
Relationships
Data
Name
Hardware
Name
Software
Name
IT project
Name
Busi-
ness
ser-
vice
Name
Hardware
Name
Type Enum
Server
Type of introduced hard-
ware
Storage
Security tool
Backup Tool
Others
ⓞ Other types Content
Writing down relevant de-
tailed contents in case the
type of hardware is others
Ex) L4 switch, Scanner etc.

330
Component Property
Item
Domain
Domain
Restric-
tion
Explanation
Hardware
ⓞDetailed type
of hardware
Enum
Serv-
er
Unix
NT(Windows)
Linux
Mainframe
Others
Stor-
age
SAN Storage
NAS Storage
Others
Secu-
rity
tool
Firewall
IPS/IDS
VPN
DDos
Others
Back-
up
Tool
Tape library
VTL
Others
Oth-
ers
Vender Enum
HP
Name of hardware manu-
facturer (writing down
manufacturer’s name, not
supplier’s name)
IBM
SUN
FUJITSU
DELL
HITACHI
INTEL
EMC
HITACHI
BROCADE
McDATA
ADIC
Overland
Quantum
Others
Model name Name
Name of hardware named
by its manufacturer

331
Component Property
Item
Domain
Domain
Restric-
tion
Explanation
Hardware
OS name Enum
AIX
Name of OS loaded in
hardware
Linux
Windows
HP Unix
Solaris
Others
ⓞ Other OS
names
Content
Writing down OS name in
case OS name is others
Introduction
year
Year YYYY
Writing down the year
when the machine is in-
stalled in Gregorian year
Ex) 2009
Business
Severity
Enum
Mission Critical
Critical
Medium
Low
Total cost Number SAR
Total cost of the hardware
installation
Ex) 100,000 SAR
Annual main-
tenance cost
Number SAR
The cost of hardware an-
nual maintenance cost
Ex) 100,000 SAR
Software Name Name
Software means
common use or
sharing software
※ inputting it with
the form of ‘hard-
ware name_soft-
ware purpose’
Ex) ERP_DB server_
DBMS, ERP_DB
server_WAS, etc.

332
Component Property
Item
Domain
Domain
Restric-
tion
Explanation
Software
Type Enum
Operating system
WEB/WAS
Middle ware
DBMS
Modeling tool
Graphic tool
Mail
Virus Vaccine
Others
ⓞOther types Content
Vender Enum
CentOS
Name of software manu-
facturer (writing down
manufacturer’s name, not
supplier’s name)
Ex) Oracle
HP
IBM
Microsoft
RedHat
Oracle
SUSE
VMware
Apache
MySQL
SAP
PostgreSQL
Others
Name of SW Name
Name of software named
by its manufacturer
Ex) Oracle DBMS 10g
Introduction
year
Year YYYY
Writing down the year
when the SW is installed in
Gregorian year
Ex) 2009
Total cost Number SAR
Total cost of the SW instal-
lation
Ex) 100,000 SAR
Annual main-
tenance cost
Number SAR
The cost of SW annual
maintenance cost
Ex) 100,000 SAR

333
Component Property
Item
Domain
Domain
Restric-
tion
Explanation
Software
License Policy Code
User
Software’s license manage-
ment policy
CPU
Server
Site
Simultaneous Access
Others
Other license
polices
Content
Relevant detailed contents
in case license policy is
others
Number of
license
Number
Data
Name Name
Name of data
※ It is a ‘data entity’
which represents a
data subject from
the common data
model that is used
in the conceptual or
logical data model.
(See Appendix )
Description Contents
Type Enum
Structured
UnStructured

334
Component Property
Item
Domain
Domain
Restric-
tion
Explanation
Data
Data
Classification
Enum
Location,
Pollution,
Overseas Saudi,
Traffic Information,
Weather,
Law,
Licensing,
Policy,
Individual,
Public Official,
Resident,
Umrah & Haj Visitor,
Relationship between Indi-
vidual & Organization,
Organization,
Political Service,
National Service,
Document,
Patent,
Library,
Statistics,
Book Categories,
Natural Resources,
Movable Asset,
Human Resources,
Real estate,
Budget,
Accounting,
Tangible Assets,
Intangible Assets

335
Component Property
Item
Domain
Domain
Restric-
tion
Explanation
Data Centre
Name Name Name of data
※ It is a ‘data entity’
which represents a
data subject from
the common data
model that is used
in the conceptual or
logical data model.
(See Appendix)
Classification Enum Tier 1
Tier 2
Tier 3
Tier 4
Location Name
Table ‎14-26: NEA Meta-Classes
Component Property Item Domain
Domain
Restriction
Explanation
Business
service
Agency Name Name
Name of business service Name
Business service description Content
Service Number Text
Service Output Name
Table ‎14-27: NEA business service Meta-Class

336
Annex D: e-Government
Transformation Plan
D1. Mandates of A Government Entity
Every government agency in the KSA has specific mandates to fulfill for instance the e-
Government program of Yesser was founded since the government of KSA attaches great
importance to transformation to e-Government, due to the enormous benefits of e-Gov-
ernment concepts to the national economy.
Royal Decree (133) dated 21/05/1424 assigned responsibility towards management, planning and
development of the CIT sector, including launching e-Government, to Ministry of Communication and
Information Technology (MCIT).
Royal Decree (7/B/33181) dated 10/07/1424 H referred to MCIT the responsibility of establishing
a plan to deliver e-Government services and procurement of necessary resources.
Which resulted in the formulation of Yesser as an entity with mandates that it needs to deliver
on. Based on this an entity would establish their vision, mission goals and objectives.
D2. Strategic e-Government Transformation in an Agency
“Strategic Management is trying to understand where you will fit in tomorrow’s world and de-
ciding where you want to be and – getting there” :- Jack Welch
The business strategy tries to answer 3 to 4 fundamental questions:
• Whom to serve? - WHO
• What to offer?- WHAT
• How to serve? - HOW
• Who should Serve? – BY WHOM

337
The WHO and WHAT are part of business strategy and is dictated by the government agency
mandates. HOW and by WHOM is addressed by means of strategic management. The business
Strategy and strategic management are guided by Vision, Mission and Objectives of the gov-
ernment agency and the National Strategy and Saudi e-Government action plans.
So it is expected that an agency has a business strategy, captured by tools like balance score
card, strategic management (and implementation) captured by tools like value chain or 7s
framework.
In organizations that have a sizable and mature IT division would develop their own IT strategy in
line with the Business Strategy of the agency.
The diagram below describes the various components of strategy management in an orga-
nization.

338
Agency Mandates
MissionVision Objectives
Business Model Today Business Model Tomorrow
Business Strategy
IT Strategy
National Strategy
& e- Government
Action Plan
BalanceScoreCardValueChain
Figure ‎14-4: Components of Strategic Management in government agency
D3. Overview of e-Government Transformation Plan
The e-Government Transformation Plan is a roadmap for the agency to transform from the cur-
rent state to an organizationally optimized and seamlessly integrated business functions and pro-
cesses supported by an efficient ICT capability using Enterprise Architecture Methodology. The
ultimate objective of the plan is to help the government agencies become more citizen-centered,
service focused, efficient, process driven and result oriented. The plan mainly focuses on improv-
ing government processes, connecting to citizens (through e-Services) and building standard inter-
actions/integrations within and across the agencies.

339
D4 How to use NORA for developing e-GovernmentTransformation Plan
The organization is required to map its current and future architecture states in relation to the
business and IT perspectives and subsequently prepare an architecture roadmap and imple-
mentation governance that closes the gap between the two states - in other words, a blueprint
of the organization’s ICT-enabled business.
By utilizing NORA the agency produces the following deliverables:
• Current Architecture – By completing stage 6 of NORA ( Build Current Architecture)
• Target Architecture – By completing stage 7 of NORA ( Build Target Architecture)
• Analysis that identifies the shortfalls of the current state in terms of its ability to support the
objectives and strategies of the business, with respect to future state ( Part of Stage 6 and
Stage 7 of NORA)
• Transformation Plan (i.e. e-Government Strategic Transformation Plan) that defines the
initiatives required to migrate from the current state into the future state. This is delivered
as part of stage 8 of NORA.

340
Agency Mandates
MissionVision Objectives
Business Strategy
IT Strategy
National Strategy
& e- Government
Action Plan
Transformation Plan
BalanceScoreCardValueChain
Figure ‎14-5: Linking strategy and e-Government transformation
The activities that need to be performed in carrying out this exercise is not exactly IT driven, it
is linked directly to government entity mandates, National Strategy and Action Plans, business
strategy and strategy management of the government entity. This also implies that the ade-
quate involvement of not only executives of the agency but also the strategic and operational
stakeholders are needed as well. Figure 14.5 illustrates the linkage of e-Transformation plan
with components of strategy within the agency.

341
D5. Relevant Artifacts for e-Government Transformation
The agency e-Government Transformation plan comprises artifacts that represent:
• Current State Enterprise Architecture
• Artifacts related to Current Business Architecture
• Artifacts related to Current Application Architecture
• Artifacts related to Current Data Architecture
• Artifacts related to Current Technology Architecture
• Future State Enterprise Architecture
• Artifacts related to Future Business Architecture
• Artifacts related to Future Application Architecture
• Artifacts related to Future Data Architecture
• Artifacts related to Future Technology Architecture
• Analysis that identifies the shortfalls of the current state in terms of its ability to support the
objectives and strategies of the business, with respect to future state.
• Artifacts that lists new ideas, gaps and opportunities for improvement in Business,
Application, Data and Technology Domains
• Transformation Plan (i.e. e-Government Strategic e-Transformation Plan) that defines the
initiatives required to migrate from the current state into the future state.
• Artifact that Represents e-Government Transformation Plan, which comprise of logi-
cally grouped projects linked to the above list, their priorities and their respective
timelines.

342
Transformation Plan
Business
Applications
Data
Technology
Business
Applications
Data
Technology
NORA
EAPractice
Figure ‎146: Relevant artifacts for e-Government Transformation Plan
The e-Government Transformation Plan comprise of a set of NORA Artifacts and NORA Work
Products, artifacts are the end deliverables from a NORA stage, whereas work products are the
interim documentation or data collected or reports made while creating those deliverables.
The below table shows the exhaustive list of the artifacts part of the e-Government Transforma-
tion Plan.

343
NORA Stage NORA Artifacts
NORA Work
Products
Develop EA Strategy, Develop EA
Project Plan and Analyze Current
State.
EA Strategy Agency’s Vision, Mission,
Objectives and Initiatives.
SWOT Analysis Agencies IT Project List
Current IT Landscape
Develop EA Framework Agencies EA Mission, Vision,
Objectives
Agencies Architecture Principle
Agency PRM, BRM, ARM, DRM,
TRM wherever applicable
Build Current Architecture and
Target Architecture
Organization Chart
Business Function
Business Process
Service Catalogue
Target Architecture
Application Function
Application Relationship
Target Architecture
Data model Overview
Dataflow Diagram
Data Logical Diagram
Data Dictionary
Database Portfolio Catalogue
Target Architecture
Infrastructure Overview
Infrastructure Description
HW and SW Catalogue
Build Current Architecture ,Target
Architecture and Build Transition Plan
Current Architecture Analysis List of Improvement Ideas or
Gap AnalysisDirections for Target Architecture
Target BA, AA, DA, TA
Prioritized Project List
Project Roadmap
Transition Plan
Table ‎14-28: List of artifacts for e-Government Transformation Plan

344
D6. Exhaustive list of e-Government Transformation artifacts
The exhaustive list of artifacts that are of use in building the e-Government Transformation plan
is listed below, although all of them are not mandatory but it does help in constructing a better
picture and hence to plan better.
1. Vision
2. Message/Mission
3. Strategic Goals
4. Risks &Challenges
5. Stakeholders
6. Values & Principles
7. Conceptual Model
8. Organizational Structure
9. Services
10. Processes
11. Business Requirements
12. Business Gaps
13. Listing Applications
14. Listing Applications Modules
15. Relations between Applications
16. Applications Requirements
17. Applications Gaps
18. Data Entities
19. Relationships between Data Entities & Applications
20. Relationships between Data Entities and Business Structure
21. Methods of Data Management and its security
22. Data Requirements
23. Data Gaps
24. Listing Technology Components.
25. Technology References Definition.
26. References of Technology security.
27. Relationships between Technology Components &Information Systems.
28. Technology Infrastructure Requirements
29. Counting Technology Gaps
30. Gaps Listing
31. Definition of initiatives and future projects
32. Roadmap for Transformation

345
Annex E: NEA EA maturity model
The EA Core team can evaluate and measure its EA maturity. The team can obtain the EA Matu-
rity measurement from NEA, Yesser. This maturity measurement should be done on an annual
basis. From the maturity index, the EA Core team can reflect and re-plan how they can improve
their EA execution.
Since the government agency will be assessed on its EA, the Core team has to understand the
National EA Maturity Model that has 5 maturity levels.
1. Initial or Informal
2. Under Development
3. Defined
4. Managed
5. Optimizing.
It also has 5 components or areas of measurement - EA Process, EA Development, Business
Linkage, Senior Management Involvement and EA Communication. Figure 14-7 illustrates the
NEA EA Maturity Model while Table 14-29 describes the details of each level.
Figure ‎14-7: NEA EA maturity model

346
Maturity
Component /
Maturity Level
Measurement Description
EA Process Is there an established EA process?
1 Ad-hoc EA processes exist
2 Basic EA processes are defined
3 The EA processes are well defined and all of them are documented
4 The EA processes are part of the culture and are linked to business & IT
processes
5 The EA processes are optimized and continuously improved based on
quality metrics
EA Development To what extent are the EA documents and deliverables provided by EA
(team/division/office)?
1 Ad-hoc EA documentation and standards exist
2 Basic EA documentation such as ‘Organization structure diagram’, ‘Appli-
cation architecture diagram’, ‘Data entities diagram’ and more than one
of ‘Reference models’ exist
3 All of EA documentation such as Current architecture, Target architec-
ture, Gap analysis and Migration plan, ‘5 Reference models(PRM, BRM,
ARM, DRM, TRM)’, and ‘Meta model’ exist
4 Updated EA documentation exists to reflect the major IT and business
changes
5 EA documentation is continuously or periodically updated to reflect all IT
and business changes
Business Linkage To what extent is the EA linked to business strategies or drivers?
1 Minimal or implicit linkage to business strategies or business drivers
2 Explicit linkage to business strategies or drivers. , EA is involved in the
initiation of any new business initiatives
3 EA is integrated with Business processes management. Explicit linkage to
business drivers and information requirements

347
4 Business processes management are adjusted based on the feedback re-
ceived and lessons learned from updated EA. Periodic re-examination of
business drivers
5 EA metrics are used to optimize and drive business linkages. Business
involved in the continuous process improvements of EA
Senior Management
(CEO/CIO/Director)
Involvement
To what extent are the senior management involved in the establishment
and ongoing development of the EA?
1 EA Core team is established but Limited management team awareness or
involvement in the EA process
2 Occasional / selective senior management (IT Director) involvement with
the EA Core team and in EA Process with various degrees of commitment
3 Senior-management team (IT Director) aware of and supportive of the
EA process
4 Senior-management team (CIO) directly involved in the EA review process
5 Senior-management team (CEO) directly involved in the optimization of
the EA development process and governance
EA Communication To what extent are the decisions of EA practice documented?
1 Using ad-hoc tools for EA documentation, for example Visio diagrams,
Word documents and Excel sheets
2 The operating unit’s EA documentation is available on webpage based on
ad-hoc tool information, this can be internal webpage or external
3 The operating unit EA webpages are updated periodically and are used to
document EA deliverables
4 EA documents updated regularly on EA web page and EA tools are used
to support maintaining and managing EA documentation
5 EA documents frequently reviewed for latest EA developments / stan-
dards with awareness session to IT staff on EA content
Table ‎14-29: EA maturity components & levels

348
Annex F: Business Service Attributes
Every government entity is mandated to provide information regarding their business services
into the Marsad system. The table below lists all the attributes the agency need to provide.
S/
No
Attributes in Arabic Attributes In English Value
1 ‫الخدمة‬ ‫رقم‬ service number
2 ‫عربي‬ - ‫الخدمة‬ ‫اسم‬ Service Name-Arabic
3 ‫انجليزي‬ - ‫الخدمة‬ ‫اسم‬ Service Name-English
4 ‫للخدمة‬ ‫المقدمة‬ ‫اإلدارة‬ Service provider department
5 ‫الخدمة‬ ‫نوع‬ service type
6 ‫الخدمة؟‬ ‫تصنيف‬ Service classification
7 ‫المستفيد؟‬ ‫حسب‬ ‫الخدمة‬ ‫نوع‬ service type by the beneficiary
8 ‫الجغرافية‬ ‫التغطية‬ Geographic coverage
9 ‫الخدمة‬ ‫على‬ ‫الحصول‬ ‫رسوم‬ Service fee
10 ‫الوطنية‬ ‫الميزانية‬ ‫من‬ ‫الخدمة‬ ‫تمويل‬ ‫تم‬ ‫هل‬
‫الحكومية؟‬ ‫اإللكترونية‬ ‫للتعامالت‬
Is the service has been funded by the national e-
Government budget?
11 ‫على‬ ‫للحصول‬ ‫باأليام‬ ‫المستغرق‬ ‫الوقت‬
‫الراهن‬ ‫الوضع‬ ‫(خالل‬ ‫)الخدمة‬
The time consumed(By days) to provide the ser-
vice (through the status quo)
12 ‫على‬ ‫للحصول‬ ‫باأليام‬ ‫المستغرق‬ ‫الوقت‬
‫المستقبلي‬ ‫الوضع‬ ‫(خالل‬ ‫)الخدمة‬
The time consumed(By days) to provide the ser-
vice (during future status)
13 ‫للجهة‬ ‫تابعة‬ ‫الخدمة‬ ‫لتقديم‬ ‫مواقع‬ ‫هناك‬ ‫هل‬
‫الرسمي‬ ‫الدوام‬ ‫وقت‬ ‫خارج‬ ‫تعمل‬
Are there Service channels outside official work-
ing time?
14 ‫لدى‬ ‫بيانات‬ ‫أو‬ ‫خدمات‬ ‫على‬ ‫الخدمة‬ ‫تعتمد‬ ‫هل‬
‫أخرى؟؟‬ ‫حكومية‬ ‫جهات‬
Does the service rely on other government agen-
cies services and data ?
15 ‫جهات‬ ‫لدى‬ ‫خدمات‬ ‫الخدمة‬ ‫هذه‬ ‫تدعم‬ ‫هل‬
‫أخرى؟؟‬ ‫حكومية‬
Does the service support other government agen-
cies services?
16 ‫الرقمي‬ ‫التصديق‬ ‫خاصية‬ ‫تفعيل‬ ‫تم‬ ‫هل‬
‫لمستفيدي‬ ‫الرقمي‬ ‫التصديق‬ ‫شهادة‬ ‫وإصدار‬
‫الخدمة؟؟‬ ‫هذه‬ ‫ومستخدمي‬
Is digital certification feature activated? Is issuing
digital certification for the beneficiaries and users ac-
tivated?
17 ‫الخدمة؟‬ ‫نضج‬ ‫مستوى‬ Service maturity level

349
18 ‫اليه‬ ‫الوصول‬ ‫يمكن‬ ‫الخدمة‬ ‫لنضج‬ ‫مستوى‬ ‫أعلى‬ The highest service maturity level can be reached
19 ‫النضج؟‬ ‫في‬ ‫األعلى‬ ‫للمستوى‬ ‫الخدمة‬ ‫انتقال‬ ‫تاريخ‬ Date of service transmission to the next level of
maturity
20 ‫الخدمة‬ ‫من‬ ‫المستهدفين‬ ‫عدد‬ The targeted beneficiaries number of service
21 ‫بشكلها‬ ‫سنويًا‬ ‫الخدمة‬ ‫من‬ ‫المستفيدين‬ ‫عدد‬
‫االلكتروني‬
The number of service beneficiaries (electronic
form) annually
22 ‫السنة‬ ‫خالل‬ ‫االلكترونية‬ ‫العمليات‬ ‫عدد‬ The number of electronic transactions annually
23 ‫الواحد‬ ‫للمستفيد‬ ‫الخدمة‬ ‫استخدام‬ ‫تكرار‬ Frequent use of service by a beneficiary.
24 ‫في‬ ‫الخدمة‬ ‫وحالة‬ ‫الخدمة‬ ‫أتمتته‬ ‫قابلية‬
‫الحالي‬ ‫وضعها‬
Service automation availability and current state
25 ‫متاحة؟‬ ‫الخدمة‬ ‫وإجراءات‬ ‫متطلبات‬ ‫هل‬ Are the requirements and procedures of service
available?
26 ‫إجراءاتها؟‬ ‫توثيق‬ ‫تم‬ ‫هل‬ Are the service procedures documented?
27 ‫الخدمة‬ ‫عمل‬ ‫مسار‬ ‫رسم‬ ‫تم‬ ‫هل‬ (workflow chart)‫؟‬ Is the service workflow chart designed ?
28 ‫هندستها‬ ‫إعادة‬ ‫أو‬ ‫إجراءاتها‬ ‫تحسين‬ ‫تم‬ ‫هل‬
‫)؟؟‬BPR/BPI(
Have the service procedures been improved or
re-engineered (BPR / BPI)?
29 ‫موحدة؟‬ ‫الخدمة‬ ‫تقديم‬ ‫إجراءات‬ ‫هل‬ Are the procedures of providing the service unified?
30 ‫الخدمة‬ ‫تقديم‬ ‫قنوات‬ Service channels
31 ‫عربي‬ - ‫للخدمة‬ ‫المباشر‬ ‫االلكتروني‬ ‫الرابط‬ Service link in the official websites - Arabic
32 ‫انجليزي‬ - ‫للخدمة‬ ‫المباشر‬ ‫االلكتروني‬ ‫الرابط‬ Service link in the official websites-English
33 ‫اليوتيوب‬ ‫على‬ ‫الفيديو‬ ‫رابط‬ Video link on YouTube
34 ‫اآللي‬ ‫بالرد‬ ‫الخاص‬ ‫االتصال‬ ‫رقم‬ IVR call number
35 ‫اإلستخدام‬ ‫لطريقة‬ ‫رابط‬ Service usage link
36 ‫الخدمة‬ ‫استخدام‬ ‫دليل‬ Service usage guideline
37 ‫عربي‬ - ‫الخدمة‬ ‫وصف‬ Service Description - Arabic
38 ‫انجليزي‬ - ‫الخدمة‬ ‫وصف‬ Service Description - English
39 ‫الخدمة‬ ‫تنفيذ‬ ‫خطوات‬ Service implementation steps
Table ‎14-30: Attributes of business service (Arabic & English)

350

351

الوثيقة المتكاملة للمنهجية الوطنية للبنية المؤسسية National Overall Reference Architecture

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to الوثيقة المتكاملة للمنهجية الوطنية للبنية المؤسسية National Overall Reference Architecture (20)

More from YesserProgram (19)

Recently uploaded (20)

الوثيقة المتكاملة للمنهجية الوطنية للبنية المؤسسية National Overall Reference Architecture