Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

2.063 visualizaciones

Publicado el

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

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

  1. 1. National Overall Reference Architecture (NORA) e-Government Program (Yesser)
  2. 2. 2 National Overall Reference Architecture (NORA) – Handbook Tableof Contents
  3. 3. 3 National Overall Reference Architecture (NORA) – Handbook 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. 4 National Overall Reference Architecture (NORA) – Handbook 4. Stage 2 - Develop EA Project Plan 48 4.1. Stage summary 48 4.2. Stage purpose 48 4.3. Stage initiation 48 4.4. Key steps in stage 2 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.1. Stage summary 88 6.2. Stage purpose 88 6.3. Stage initiation 88 6.4. Key steps in stage 3 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. 5. 5 National Overall Reference Architecture (NORA) – Handbook 7. Stage 4 – Develop EA Framework 104 7.1. Stage summary 104 7.2. Stage purpose 104 7.3. Stage initiation 105 7.4. Key steps in stage 4 105 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.1. Stage summary 133 9.2. Stage purpose 133 9.3. Stage initiation 133 9.4. About NEA reference models 134 9.5. Key steps in stage 5 136 9.5.1. Step 5.1 Build performance reference model 137 9.5.2. Step 5.2 Build business reference model 143
  6. 6. 6 National Overall Reference Architecture (NORA) – Handbook 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.1. Stage summary 173 10.2. Stage purpose 173 10.3. Stage initiation 174 10.4. Key steps in stage 6 175 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.1. Stage summary 246 11.2. Stage purpose 246 11.3. Stage initiation 247 11.4. Key steps in stage 7 247 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 12.1. Stage summary 269 12.2. Stage purpose 269 12.3. Stage initiation 269
  7. 7. 7 National Overall Reference Architecture (NORA) – Handbook 12.4. Key steps in stage 8 270 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.1. Stage summary 281 13.2. Stage purpose 281 13.3. Stage initiation 281 13.4. Key steps in stage 9 282 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. 8. 8 National Overall Reference Architecture (NORA) – Handbook 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. 9. 9 National Overall Reference Architecture (NORA) – Handbook 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. 10. 10 National Overall Reference Architecture (NORA) – Handbook 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. 11. 11 National Overall Reference Architecture (NORA) – Handbook 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. 12. 12 National Overall Reference Architecture (NORA) – Handbook 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. 13. 13 National Overall Reference Architecture (NORA) – Handbook 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-1: Stage 2 steps 49 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-1: Stage 3 steps 89 Table ‎6-2: Example questionnaire 91 Table ‎6-3: Example format to gather EA requirements 92
  14. 14. 14 National Overall Reference Architecture (NORA) – Handbook Table ‎6-4: Internal analysis areas & expected outcomes 93 Table ‎6-5: SWOT chart template 101 Table ‎7-1: Stage 4 steps 105 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-1: Stage 5 steps 136 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 Table ‎10-1: Stage 6 steps 175
  15. 15. 15 National Overall Reference Architecture (NORA) – Handbook 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. 16. 16 National Overall Reference Architecture (NORA) – Handbook 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-1: Stage 7 steps 248 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-1: Stage 8 steps 270 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-1: Stage 9 steps 282 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. 17. 17 National Overall Reference Architecture (NORA) – Handbook Table ‎13-9: Example for EA management system’s functions 298 Table ‎14-1: Stage 10 steps 301 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-5: Stage 1 steps 308 Table ‎14-6: Stage 2 summary 309 Table ‎14-7: Stage 2 steps 309 Table ‎14-8: Continuous governance summary 310 Table ‎14-9: Continuous governance steps 310 Table ‎14-10: Stage 3 summary 311 Table ‎14-11: Stage 3 steps 311 Table ‎14-12: Stage 4 summary 312 Table ‎14-13: Stage 4 steps 313 Table ‎14-14: Stage 5 summary 314 Table ‎14-15: Stage 5 steps 315 Table ‎14-16: Stage 6 summary 316 Table ‎14-17: Stage 6 steps 316 Table ‎14-18: Stage 7 summary 317 Table ‎14-19: Stage 7 steps 317 Table ‎14-20: Stage 8 summary 318 Table ‎14-21: Stage 8 steps 318 Table ‎14-22: Stage 9 summary 319 Table ‎14-23: Stage 9 steps 319 Table ‎14-24: Stage 10 summary 319 Table ‎14-25: Stage 10 steps 320 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. 18. 18 National Overall Reference Architecture (NORA) – Handbook 1.Introduction
  19. 19. 19 National Overall Reference Architecture (NORA) – Handbook 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. 20. 20 National Overall Reference Architecture (NORA) – Handbook 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. 21. 21 National Overall Reference Architecture (NORA) – Handbook 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. 22. 22 National Overall Reference Architecture (NORA) – Handbook 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. 23. 23 National Overall Reference Architecture (NORA) – Handbook 2.Executive Summary
  24. 24. 24 National Overall Reference Architecture (NORA) – Handbook 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. 25. 25 National Overall Reference Architecture (NORA) – Handbook 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. 26. 26 National Overall Reference Architecture (NORA) – Handbook 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. 27. 27 National Overall Reference Architecture (NORA) – Handbook 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. 28. 28 National Overall Reference Architecture (NORA) – Handbook 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. 29. 29 National Overall Reference Architecture (NORA) – Handbook 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. 30. 30 National Overall Reference Architecture (NORA) – Handbook 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. 31. 31 National Overall Reference Architecture (NORA) – Handbook 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. 32. 32 National Overall Reference Architecture (NORA) – Handbook 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. 33. 33 National Overall Reference Architecture (NORA) – Handbook 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. 34. 34 National Overall Reference Architecture (NORA) – Handbook 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. 35. 35 National Overall Reference Architecture (NORA) – Handbook 3.Stage1-Develop EAProjectStrategy
  36. 36. 36 National Overall Reference Architecture (NORA) – Handbook 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. 37. 37 National Overall Reference Architecture (NORA) – Handbook 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. 38. 38 National Overall Reference Architecture (NORA) – Handbook 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. 39. 39 National Overall Reference Architecture (NORA) – Handbook 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. 40. 40 National Overall Reference Architecture (NORA) – Handbook 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. 41. 41 National Overall Reference Architecture (NORA) – Handbook 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. 42. 42 National Overall Reference Architecture (NORA) – Handbook 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. 43. 43 National Overall Reference Architecture (NORA) – Handbook 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. 44. 44 National Overall Reference Architecture (NORA) – Handbook 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. 45. 45 National Overall Reference Architecture (NORA) – Handbook 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. 46. 46 National Overall Reference Architecture (NORA) – Handbook 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. 47. 47 National Overall Reference Architecture (NORA) – Handbook 4.Stage2-Develop EAProjectPlan
  48. 48. 48 National Overall Reference Architecture (NORA) – Handbook 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. 4.3 Stage initiation This stage begins with the endorsement or approval of the EA Project Strategy in Stage 1. 4.4 Key steps in stage 2 Table 4-1 lists the key steps in Stage 2.
  49. 49. 49 National Overall Reference Architecture (NORA) – Handbook Stage / Step No Description Deliverable 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 2.4 Present and obtain approval for the EA 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. 50. 50 National Overall Reference Architecture (NORA) – Handbook 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. 51. 51 National Overall Reference Architecture (NORA) – Handbook 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. 52. 52 National Overall Reference Architecture (NORA) – Handbook 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. 53. 53 National Overall Reference Architecture (NORA) – Handbook 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. 54. 54 National Overall Reference Architecture (NORA) – Handbook 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. 55. 55 National Overall Reference Architecture (NORA) – Handbook 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. 56. 56 National Overall Reference Architecture (NORA) – Handbook 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. 57. 57 National Overall Reference Architecture (NORA) – Handbook 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. 58. 58 National Overall Reference Architecture (NORA) – Handbook 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. 59. 59 National Overall Reference Architecture (NORA) – Handbook 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. 60. 60 National Overall Reference Architecture (NORA) – Handbook 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. 61. 61 National Overall Reference Architecture (NORA) – Handbook 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. 62. 62 National Overall Reference Architecture (NORA) – Handbook 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. 63. 63 National Overall Reference Architecture (NORA) – Handbook 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. 64. 64 National Overall Reference Architecture (NORA) – Handbook 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. 65. 65 National Overall Reference Architecture (NORA) – Handbook [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. 66. 66 National Overall Reference Architecture (NORA) – Handbook 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. 67. 67 National Overall Reference Architecture (NORA) – Handbook Continuous Governance
  68. 68. 68 National Overall Reference Architecture (NORA) – Handbook 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. 69. 69 National Overall Reference Architecture (NORA) – Handbook 5.4 Key areas in EA governance The key areas in EA governance are listed in Table 5-1. Stage / Step No Description Deliverable 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. 70. 70 National Overall Reference Architecture (NORA) – Handbook 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. 71. 71 National Overall Reference Architecture (NORA) – Handbook 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. 72. 72 National Overall Reference Architecture (NORA) – Handbook 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. 73. 73 National Overall Reference Architecture (NORA) – Handbook 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. 74. 74 National Overall Reference Architecture (NORA) – Handbook 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. 75. 75 National Overall Reference Architecture (NORA) – Handbook 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. 76. 76 National Overall Reference Architecture (NORA) – Handbook 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 i. EA Goals & Objectives ii. Need for EA in Government Agency (i.e. benefits) iii. High Level Current Architecture iv. High Level Target Architecture v. EA Transition Roadmap
  77. 77. 77 National Overall Reference Architecture (NORA) – Handbook Workshop 1 day i. EA Goals & Objectives ii. National Enterprise Architecture (NEA) for Saudi Government iii. Need for EA in Government Agency (i.e. benefits) 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. 78. 78 National Overall Reference Architecture (NORA) – Handbook 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.

×