وثيقة النموذج المرجعي للتطبيقات الوطنية

e-Government Program (Yesser)

Version: 2.0Date: 12/31/2015

National Application Reference Model (Version 2.0)

e-Government Program (Yesser) National Application Reference Model

Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or

reproduced without the prior written permission of the e-Government Program (Yesser) / 88

Document Description

Document Title National Application Reference Model Document version 2.0 Document Status Final Author National Enterprise Architecture Office Management at

Yesser




Table of Contents

1. Introduction ......................................................................................................................... 5

1.1. Document Purpose ........................................................................................................ 5 1.2. National Enterprise Architecture Framework ................................................................. 5 1.3. ARM Defined .................................................................................................................. 5 1.4. Values of ARM ............................................................................................................... 5 1.5. Goals of ARM ................................................................................................................. 6 1.6. Target Audience ............................................................................................................. 6 1.7. Document Structure ....................................................................................................... 7 1.8. Related Information ........................................................................................................ 7 1.9. Contact Information ........................................................................................................ 8

2. ARM Executive Summary ................................................................................................... 9 2.1. Background of NEA Framework .................................................................................... 9 2.2. About ARM ..................................................................................................................... 9 2.3. ARM Relationship to Other Reference Models ............................................................ 10 2.4. Importance of ARM in Saudi Government ................................................................... 10

3. Application Reference Model Principles ......................................................................... 12 4. Application Elements ........................................................................................................ 14

4.1. Application Systems ..................................................................................................... 16 4.1.1. Core application systems ..................................................................................................................... 17 4.1.2. Supporting application system classifications ..................................................................................... 18 4.1.3. Supporting application system descriptions......................................................................................... 18

4.2. Application Components .............................................................................................. 32 4.2.1. Application component classifications ................................................................................................. 33 4.2.2. Application component descriptions .................................................................................................... 33 4.2.3. A sample of reusable component ........................................................................................................ 43

4.3. Application Interface .................................................................................................... 45 4.3.1. Application interface classifications ..................................................................................................... 47 4.3.2. Application interface description .......................................................................................................... 48

4.4. Best Practices & Guidelines ......................................................................................... 53 4.4.1. Application architectural style .............................................................................................................. 53 4.4.1.1. Client/Server architectural style ........................................................................................................... 54 4.4.1.2. Service-Oriented architectural style ..................................................................................................... 54 4.4.1.3. N-Tier / 3-Tier architectural style .......................................................................................................... 55 4.4.2. Application development life-cycle model ............................................................................................ 56 4.4.2.1. Waterfall model .................................................................................................................................... 56 4.4.2.2. Prototyping model ................................................................................................................................ 57 4.4.2.3. Rapid application development (RAD) model ...................................................................................... 57 4.4.2.4. Spiral model.......................................................................................................................................... 58 4.4.2.5. Yesser SDLC ........................................................................................................................................ 59 4.4.3. Application development methodology ................................................................................................ 60 4.4.4. Application environments ..................................................................................................................... 63 4.4.5. Application design ................................................................................................................................ 64 4.4.6. Application development ...................................................................................................................... 66 4.4.7. Application interface ............................................................................................................................. 68 4.4.7.1. Libraries based Interface ...................................................................................................................... 69 4.4.7.2. Protocols based Interface .................................................................................................................... 69 4.4.7.3. Yesser GSB .......................................................................................................................................... 70 4.4.8. Application testing ................................................................................................................................ 75 4.4.9. Application configuration management ................................................................................................ 75

5. Application Systems for Saudi Government .................................................................. 76 5.1. Understand Business Requirements ........................................................................... 77 5.2. Prioritize Business Requirements ................................................................................ 79 5.3. Review Current Application Systems ........................................................................... 79 5.4. Design High-Priority, Quick-to-Market Application Systems ........................................ 80 5.5. Design High-Priority, Long-Term Application Systems ................................................ 81 5.6. Reuse Application Systems for Low-Priority but Quick-to-Market ............................... 82




Appendix: National Shared Application Systems ................................................................. 84

List of Tables

Table 2-1. ARM relationship with other reference models ......................................................... 10 Table 3-1: ARM principles .......................................................................................................... 13 Table 4-1: Application elements ................................................................................................. 14 Table 4-2 : Example of core application systems serving government functions ....................... 17 Table 4-3: List of supporting application systems ...................................................................... 30 Table 4-4: Application component areas and categories ........................................................... 42 Table 4-5: Board management component sample ................................................................... 45 Table 4-6 : Application Interface areas and categories .............................................................. 52 Table 4-7: Sample of CBD artifacts ............................................................................................ 61 Table 4-8: KSA GSB service catalogue ..................................................................................... 74 Table 5-1: Checklist review of current application systems ........................................................ 80 Table 0-1 National shared application systems .......................................................................... 88

List of Figures

Figure 4-1: Application elements ................................................................................................ 15 Figure 4-2: Supporting application system classifications .......................................................... 18 Figure 4-3: Development framework, application components and system ............................... 32 Figure 4-4: Application component classifications ..................................................................... 33 Figure 4-5: Common component and software development framework ................................... 43 Figure 4-6: Application interface classifications ......................................................................... 47 Figure 4-7: Waterfall model ........................................................................................................ 57 Figure 4-8: Prototyping model .................................................................................................... 57 Figure 4-9: RAD model ............................................................................................................... 58 Figure 4-10: Spiral model ........................................................................................................... 59 Figure 4-11: Yesser SDLC ......................................................................................................... 60 Figure 4-12: A simple example of several components (holiday reservation system represented in UML 2.0) ................................................................................................................................. 62 Figure 4-13: V development process for CBD ........................................................................... 63 Figure 4-14: The benefit of SW framework ................................................................................ 64 Figure 4-15: SW development paradigm .................................................................................... 65 Figure 4-16: Korean government SW development framework’s composition functionalities ... 66 Figure 4-17: Software development library ................................................................................ 68 Figure 4-18: GSB ....................................................................................................................... 71 Figure 5-1: Steps to identify & prioritize application systems ..................................................... 77 Figure 5-2: Examples of MOE’s LoBs, business functions and sub-business functions ............ 78 Figure 5-3: Priority vs Time matrix ............................................................................................. 79 Figure 5-4: National shared application systems & components ............................................... 81 Figure 5-5: National shared application systems (long-term) ..................................................... 82




1. Introduction 1.1. Document Purpose The purpose of this document is to describe the main application architecture elements and

national-wide application systems that government agencies in the Kingdom of Saudi Arabia

can refer. This Application Reference Model (ARM) is a good starting point to look for national -

wide and agency-wide application solutions.

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. ARM Defined The ARM is one of the reference models in the NEA Framework. The ARM describes the main

architectural elements of IT application solutions. It also provides a strategic reference to key

national-wide solutions or application systems. With both the application architectural elements

and national-wide solutions, government agencies can design and develop application systems

to solve their respective challenges and needs.

1.4. Values of ARM The ARM provides a reference for all government agencies to analyze, review, develop and

implement IT application systems that support the integrated functions and services across

different government agencies. Instead of simply looking for the best solution for an agency, the

ARM adds value by proposing IT application systems that can be use across government

agencies.




The ARM encourages government agencies to use national-wide IT application systems. In

addition, with structured design approach, IT application systems and their components are

shareable and reusable. With proper follow through, the ARM will bring about the following

potential benefits:

1. Improve government services to citizens and businesses

2. Enhance interoperability across government agencies

3. Leverage on current IT application investments and assets

4. Reduce total cost of ownership on future IT investments through the use of national

shared application systems and reusable application components

5. Align government agencies’ IT application systems with national shared application

systems & other central IT initiatives.

1.5. Goals of ARM The goals of ARM are:

1. Promoting national shared application systems for common functions in the government

agencies

2. Promoting the identification and implementation of IT application systems that support

the similar government or business functions across different government agencies

3. Promoting industry standards and best practices in IT application design to increase

interoperability across the government

4. Sharing reusable application components to reduce total development cost and time for

deployment

5. Identifying areas for IT application consolidation to support efficient acquisition and

deployment such as software licenses and use of latest software versions.

1.6. Target Audience Since the ARM is a reference that provides an insight to both IT application solutions and application elements, the target audience are as follows:

1. Enterprise Architects

2. Application Architects

3. IT Architects

4. Project Managers

5. IT System Owners




6. IT Managers

7. IT Consultants

8. IT Vendors

1.7. Document Structure The ARM contains the following sections:

1. Executive Summary

The executive summary describes the main features of ARM. After reading this section,

the reader can understand how ARM guides the government agencies to analyze and

design IT application systems. The executive summary is excellent for IT System

Owners, IT Managers and Project Managers.

2. ARM Principles

This section describes the principles that shape the ARM development and to guide the

development of IT application systems.

3. Application Elements

The main application elements – i.e. application systems, application components and

application interfaces – are describe in this section.

4. Application Systems for Saudi Government

This section provides the strategy and approach in looking for application systems for

both national-wide and agency use only.

1.8. Related Information

As the ARM is only one of the reference models in NEA Framework, it has important

relationships with the other reference models. It is useful to refer to the following:

1. Business Reference Model

2. Data Reference Model

3. Technical Reference Model.




1.9. Contact Information

For any feedback, comments or need for more information on the ARM, please email to [email protected]




2. ARM Executive Summary 2.1. Background of NEA Framework The 2nd National e-Government Action Plan for Kingdom of Saudi Arabia (KSA) aims to

transform the government in the delivery of services to the public. The National Enterprise

Architecture (NEA) is a strategic initiative to support government agencies in delivering the

targets set in the Action Plan.

The vision of NEA is “Achieving performance driven IT investment and standardized services for

a coherent whole of government by 2020” while the mission of NEA is “Leading transformation

of government agencies through improvement of IT effectiveness and efficiency”.

To fulfill the above vision and mission, 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 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. This is

addressed by accentuating the full potential of the federated enterprise architecture by steering

its adoption across the government through continuous engagement with all government

agencies.

2.2. About ARM The ARM is one of the reference models in the NEA Framework. It provides a strategic

reference to key national-wide solutions or application systems. With ARM, government

agencies can design and develop application systems to solve their respective challenges and

needs.

However, instead of simply looking for the best solution for an agency, the ARM adds value by

proposing IT application systems that can be use across government agencies. The ARM

encourages government agencies to use national-wide IT application systems.




2.3. ARM Relationship to Other Reference Models The ARM has important relationships with the other reference models in the NEA Framework as

listed in Table 2-1.

Reference Model Relationship with ARM

Business Reference Model

(BRM)

ARM can refer to business functions and sub-business

functions in the BRM to identify areas for automation and

improvements. Since the business function is a logical

view, it also identifies related government agencies

affected by the implementation of the IT applications to

support the specific business function.

Data Reference Model

(DRM)

As IT applications require data, the ARM has to cross-

reference with DRM to identify key data attributes and the

sources of data.

Technical Reference Model

(TRM)

In designing IT solutions, the ARM has to also link with the

TRM on technical standards and best practices.

Table 2-1. ARM relationship with other reference models

2.4. Importance of ARM in Saudi Government IT application systems form the core solutions to solve business problems (in addition to

business processes, data, skills, etc.). Unlike hardware and data, IT application systems are

customize to meet the government business requirements so that government agencies can be

efficient and effective to provide excellent services to the public and other stakeholders.

While each government agency can design and develop the best application systems on their

own, these applications would only serve the respective government agency’s performance. As

part of the 2nd National e-Government Action Plan, government agencies have to continuously

transform in order to deliver excellent public services. From ARM’s perspective, government

agencies may transform their current modes of interaction, processing and service delivery in

application architecture.

With the use of ARM, government agencies can benefit the following:




1. Reduce the number, amount and time to develop various IT application systems. Instead,

government agencies are encouraged to use national shared application systems for

common functions

2. Prevent duplication of effort and duplication of application systems. By identifying

government agencies involved in the implementation or automation of key business

functions and business processes, the same or similar application system can be built

together

3. Each government agency, that is leading a specific area of business function, can also

identify all the agencies that are providing services within the business function. Not only

will this prevent duplication of work, but more importantly, it will provide the opportunity to

design an application to meet different requirements from the various affected

government agencies. The end result would be an integrated system for the business

function use by different agencies

4. Each government agency can reduce the total application development cost and time for

deployment by using reusable application components

5. Through application interfaces, data and information can be easily and securely

exchanged.




3. Application Reference Model Principles

ARM principles describe the preferred directions, aspired attributes and practices required to

guide both the development of the ARM and the government IT application systems. Table 3-1

describes the five ARM principles.

S/No Principle Principle Description / Rationale

1 Strategic Driven

Applications

Design and prioritize application systems that deliver

strategic outcomes.

To support the government agencies to meet strategic

goals, such as the national plans and the e-Government

Action Plan, application systems have to be designed

and prioritized according to these strategies and

business needs.

This principle ensures that there is focus and

prioritization in the development and deployment of

application systems.

2 Cross-Agency

Application

Systems

Design and develop application systems that serve

multiple government agencies.

To develop application systems that support the

business functions and business requirements. As a

business function is typically carry out by more than one

government agency, these application systems have to

serve the requirements of multiple government agencies.

This principle encourages application systems to meet

cross-agency implementation requirements.

3 Easy-to-Use yet

Secured

Design and develop application systems that are easy-

to-use and, at the same time, highly secured.




S/No Principle Principle Description / Rationale

Application

Systems

To design and develop application systems that are

intuitive, simple, secured and effective. Users need not

know the underlying technologies used or the processes

involved.

This principle ensures that users can be productive in

using the application systems.

4 Adaptable and

Reusable

Application

Systems &

Components

Design and develop application systems using reusable

components and systems while being adaptable to the

constant changes.

With constant changes and problems, application

systems have to be adaptable to meet the changing

conditions and requirements.

Due to the dynamic changing demands and

requirements, this principle allows quick and easy

changes to the application systems. It also allows faster

and lower cost in developing and maintaining application

systems.

5 Vendor-Neutral

Application

Systems

Design and develop vendor-neutral application systems.

To design and develop application systems for long-term

use that are independent on any specific vendor or

product.

This principle ensures that government application

systems are not lock into any particular vendor or

product that may result in vendor / product obsolescence

or extreme price hikes. This principle also supports open

technologies and free market competition.

Table 3-1: ARM principles




4. Application Elements The application elements constitute the key artifact of the ARM. This section lists the application

elements and describes the inter-relationships among these elements. There are three

application elements in ARM as described in Table 4-1.

S/No Element Name Element Description

1 Application System Describes the application system as an

automated functional unit of operation. Typically,

an application system has to support a

government business function or task. Hence, the

ARM links Business Reference Model (BRM)

through the application system.

2 Application Component Describes the components that make up an

application system. Many components will form

an application system. Multiple application

systems can utilize the shared or common

components.

3 Application Interface Describes the various methods on how

applications systems or application components

can integrate.

Table 4-1: Application elements

The benefits of the application elements are:

1. To aid government agencies in planning the development of new application systems

2. To identify the removal or replacement of obsolete and duplicated application systems

and/or components

3. To identify the potential re-use or sharing of application systems

4. To design application components that are re-usable and highly customizable




5. To design efficient and reliable application integration methods within the government

agency (including remote branches) and across other government agencies.

Figure 4-1 below illustrates the application elements in ARM.

Figure 4-1: Application elements




4.1. Application Systems In IT, an application system typically consists of a user interface, a logic processing and a

database or table to store data. However, from the ARM perspective, an application system is

an IT automation, or part of the automation, of a government business function or task. In short,

to improve the efficiency and effectiveness of government operations, an application system

has to serve the government business function or sub-business function as described in the

BRM.

The benefits of application systems are:

1. Through IT automation, application systems improve efficiency and productivity

2. When compared to manual processing, application systems give quality output through

standard validation of inputs and consistent processing rules

3. Total processing time is faster than manual processing.

Applications systems can be define into two broad categories as follows:

1. Core Application Systems

These application systems directly support the main government business functions or

sub-business functions. Typically, government agency or agencies that are responsible

for the government business function will use the core application systems. These

application systems aid the effectiveness and efficiency of the specific government

business function or sub-business function.

2. Supporting Application Systems

Application systems that provide supporting government business functions or sub-

business functions. These supporting application systems are to be use in most

government agencies to improve general productivity.




4.1.1. Core application systems

Core application systems are required to improve the performance of the government agencies.

Through IT automation, the core application systems can improve the effectiveness and

efficiency of the government primary business functions.

Typically, a core application system will address the government primary business function or

sub-business function. If the scope and complexity of the government function is manageable,

then the core application system can be develop at the appropriate business function level.

However, when the scope and complexity of the government function is too wide and

challenging, the core application system(s) have to be develop at the sub-business function

level.

As an example, the Education government Line of Business (LoB) is huge and complex. Thus,

each government sub-business function from pre-school to high school would have at least one

corresponding core application system as shown in Table 4-2. However, for graduate and post-

graduate education, it may be possible to have two integrated core application systems serving

two sub-business functions.

Business Function Business Sub-Function Core Application System

Name

Pre-School to High

School Education

Pre-School Pre-School Management

System

Primary School Primary School Management

System

High School High School Management

System

Graduate and Post-

Graduate Education

Graduate

a. Graduate and Post-

Graduate Management

System

b. Integrated University

Admission System

Post-Graduate

Table 4-2 : Example of core application systems serving government functions




As core application systems are directly link to the government functions, the ARM will not

provide the potential list of all core application systems. Reference to the BRM is necessary and

self-explained.

4.1.2. Supporting application system classifications

Supporting applications systems focus on the IT automation of the supporting government

business functions or sub-business functions. These supporting application systems, unlike

core application systems, can be use in most government agencies. While government

agencies may have core application systems to deliver their core responsibilities and

deliverables, supporting application systems further improves the productivity and efficiency of

government agencies.

The supporting application systems can be classified by the organizational support business

functions. In total, there are ten common support business functions, although this list is not

exhaustive. Figure 4-2 shows these ten common support business functions and the respective

application systems. The description of these functions and application systems are in the next

section.

Figure 4-2: Supporting application system classifications

4.1.3. Supporting application system descriptions

Supporting application systems can be classified within the organizational support business

functions. Table 4-3 lists all the potential or recommended application systems within their

respective ten supporting business functions.




App

No

Supporting Business

Function / Application Name Application Description

1 Building Management

Manages the various building components in the government agency including

physical security.

1.1 Building Management System

(BMS)

Manages the building(s) of the government

agency. The aim of this system is to manage all

the building features such as electrical usage,

mechanical usage and electronics usage.

Examples include the control of air-conditioning,

lighting and automated sliding doors in the

building. The BMS is use only for government-

owned buildings where the electronics, electrical

and mechanical parts have been design in

tandem with the building construction. Older and

smaller buildings normally do not have BMS.

1.2 Security Management System Manages the physical security of the

government agency. With this system, the

government agency can better manage risks

relating to physical security. The main features

of this system includes employee access control

(e.g. finger print check), door access control

(e.g. to certain floors and sections of the

building), time-based access (e.g. access

between 7am and 3pm on weekdays), and

circuit-camera TV (CCTV) for video recording of

entrance/exits of critical places. This security

system can also integrates into the 1.1 Building

Management System (BMS).

2 Business Management

Manages the key business processes in the government agency.




App

No

Supporting Business


2.1 Business Process Management

System (BPM)

Manages the various important business

processes in the government agency. The aim

of BPM is to optimize the business processes

that produce services (manual or e-services). It

is both a tool and a process that requires

disciplined methodology – from designing,

modelling, documenting, executing, to optimizing

or re-engineering. This system is useful when

government agencies review and continuously

improve their business processes as part of the

e-transformation journey.

2.2 Business Request Management

System

Manages the different requests for services in

the government agency. The aim of this system

is to facilitate and automate the process from

request, to assignment, to actual execution of

the business request. This system helps to

prioritize requests and to assign them to the

available resources. It is a good system for

government agencies that provide specific

services based on request (e.g. from another

government or another division). The system

would also allow the review of all the requests

statistics such as requests processed,

incomplete actions and requests not done.

3 Communication & Collaboration

Manages the internal communication, collaboration and knowledge sharing among

government staff within the government agency and across agencies.

3.1 Email and Calendaring Manages the effective communication via email

between the employees with other employees,

public and suppliers. The calendaring tool is to

aid scheduling of meetings and appointments in

order to maximize the employees’ time.




App

No

Supporting Business


3.2 Government Agency Intranet /

Portal

Manages one central system for access to

information, data and applications of the

government agency by the employees. Through

standard portal or website, employees get the

latest news & information, and ease the

standard access to applications & data.

3.3 Knowledge Management

System

Manages the central repository of important

data, information and documents. The aim of

this system is to improve the information sharing

so that employees can gain knowledge and pass

on to the other employees. Another possible

feature of the knowledge management system is

to have an active electronic collaboration that

allows online discussion by employees from

anywhere. This system is good for government

agencies with ‘knowledge-based’ and research-

based employees.

4 Corporate Planning & Development

Manages information that affects the government agency’s corporate performance

and human resources.

4.1 Organization Management and

Planning System

Manages the planning and general management

of the government agency. With this system,

government agency can better organize, plan

and execute its operations or events. The

features of this system include organization

definition & management, events planning &

management, and events tracking.




App

No

Supporting Business


4.2 Human Resource Management

System (HRMS)

Manages the government agency’s human

resources such employees, part-time workers

and contract workers. This system aims to

optimize the human resources within the

government agency and to maximize the

employees’ performance. The HRMS has

functions such as job scope/grade & job

roadmap definitions, recruitment, performance

setting & evaluation, skills development &

training, attendance & leave management,

employee awards and resume.

5 Financial Management

Manages the finances of the government agency from budgeting and payment to

monetary collection.

5.1 Budgeting System Manages the budgeting process of the

government agency that, in turn, helps to

improve the financial planning and expenditure.

The system typically follows a life cycle from

budget review, budget planning, budget

allocation, budget tracking and budget reporting.

5.2 Financial Management System Manages the various complex aspects of

finances in the government agency. The aim of

this system is to maximize the financial

resources of the government agency and to

account for all revenues & expenditures. The

system typically has modules such as general

ledger, accounts receivables, accounts payables

and cost center accounting. This system is

normally link to 5.1 Budgeting System, 5.3

Payment System and 5.4 Monetary Collection

System. Note that a large financial management

system can incorporate all these four systems

into one.




App

No

Supporting Business


5.3 Payment System Manages accounts for all the payment

transactions of the government agency. To

ensure financial accuracy and compliance to

financial laws, record all payment transactions

into the system. This system should be able to

track payments in all amounts and via different

modes such as cash, cheque, inter-bank

transfer and online payment.

5.4 Monetary Collection System Manages all the monies collected by the

government agency at different locations. The

aim of this system is ensure credibility by

capturing all monetary collections via different

modes such as cash, cheque, inter-bank

transfer and online payment.

6 General Administration & Management

Manages and administrates the official information in the government agency such

as assets, documents, records and office resources.

6.1 Asset Inventory Management

System

Manages the inventory of assets in the

government agency to improve accountability of

all valuable assets in the government agency.

Assets include office equipment and office

stationaries. This system does not link the

requirements to supply the inventory when it has

reached a low level. For this, please refer to 9.2

Supply-Chain Management System.

6.2 Document Management System Manages the electronic documents of the

government agency. This system can identify,

search and retrieve all documents to improve

office productivity. The system features include

scanning or digitizing the document, storing,

searching, retrieval and archiving.




App

No

Supporting Business


6.3 Record Management System Manages the records of the government agency

throughout their life cycle, from the time of

document creation to their eventual disposal.

This includes identifying, classifying, storing,

securing, retrieving, tracking and destroying or

permanently preserving records. The aim of this

system is to ensure evidence of actual events or

decisions made.

6.4 Workflow Management System Manages the automated workflow processes to

speed up general efficiency. This general

workflow management system is required to

automate business processes and services of

the government agency. The system allows

business processes to be automated, actions

routed and/or scheduled to specific person(s),

and tracked.

6.5 Resource Booking System Manages the book resources such as meeting

rooms, vehicles and even people. The aim of the

system is to optimize the use of resources in the

government agency. For meeting rooms booking

only, government agency can leverage on 3.1

Email and Calendaring application system that

includes basic resource booking as part of the

calendaring function.

7 IT Management

Manages the efficient use of IT resources in the government agency.




App

No

Supporting Business


7.1 IT Helpdesk System Manages the helpdesk system that allows users

or employees to call for help in the use of IT.

The aim of this system is to support users in the

effective use of IT devices and applications. The

system normally tracks from the call by the user

to the resolution of the problem. The IT

Helpdesk System is useful when there are a

large number of IT users or employees.

7.2 IT Infrastructure Management

System

Manages the various aspects of the IT

infrastructure such as network management,

server & storage management, and data center

operations management. The aim of this system

is to provide service excellence in managing the

complex and dynamic IT environment. This suite

of systems is suitable for government agencies

with high demand in the use and operations of

IT.

7.3 Application / IT Portfolio System Manages the IT and application inventories into

a meaningful profile for the government agency.

The aim of this system is to provide value on

inter-related information about different aspects

of IT (network, equipment, data, applications

and IT support). It provides management

information such as Total Cost of Ownership

(TCO), Return on Investment (ROI) and

Business Value of IT (ITBV). Other inter-

relationship information includes life span of IT

investments and duplicated investments. For

large government agencies, this system is

excellent when used in conjunction with 7.4

Enterprise Architecture System / Tool.




App

No

Supporting Business


7.4 Enterprise Architecture System

/ Tool

Manages the effectiveness of the Enterprise

Architecture (EA) program in the government

agency. With this system or tool, the architects

can discover and analyze government agency-

wide issues, duplications and limitations in both

business and IT perspectives. This tool is use

only when the EA project has started or

completed in the government agency.

8 Management Reporting and Business Analytics

Reporting of management information and strategic analytics in the government

agency.

8.1 Statistics and Reporting System Manages the statistics and reports to the various

management teams in the government agency.

The aim is to provide reports for decision-

making. On a fixed schedule (such as weekly,

monthly and quarterly), the statistics and reports

can be generated and sent out via email, portal

or direct access to the application system.

8.2 Dashboard System Manages the overall key performance indicators

(PKIs) and the status of major programs /

projects in the government agency. The aim of

this system is provide a comprehensive view of

all the PKIs set by the management of the

government agency. The dashboard provides a

summary of the key status of events, programs,

projects and other compliance measurements

that have been set. It shows status of events or

projects that are late or on schedule, and brief

statistics to understand the potential impact to

the government agency. Public feedback,

complaints and other measurements from the

social media can also be incorporate into the

dashboard system.




App

No

Supporting Business


8.3 Business Intelligence System Manages the combination of tools, technologies

and processes to process and analyze data into

meaningful information. The aim of this system

is to understand and manage data complexity by

filtering these data to provide “intelligence” for

decision-making. Business intelligence include

features such as benchmarking, analytics

(trending, predictive & prescriptive), mining (text,

data & process) and performance management

analysis. This system requires reliable data and

skilled analysts to carry out the intelligent

discovery and findings. Typically, it is used by

government agency with complex processing

and voluminous data.

9 Procurement Management

Manages the end-to-end procurement processes including project tendering &

awarding, to supply-chain execution.

9.1 Tender or Bid Management

System

Manages the whole process of tendering or

bidding by the government agency. The aim of

this system is to ensure transparent & accurate

recording of the tendering process of the various

tender or bids by the government agency. This

system includes modules such as vendor or

tenderer information management, tender

management and contract management.




App

No

Supporting Business


9.2 Supply-Chain Management

System

Manages the supply of goods & services

consumed by the government agency. The aim

is to improve the efficiency of having readily

available goods and services for the government

agency from various suppliers. This system is

useful for government agencies who require

large-volume supplies such as medicine, and

uniforms. Note that it is possible to combine this

application with the above 9.1 Tender or Bid

Management System.

10 Public Information & Communication (Customer Services)

Publication of official information to the public, including official public interaction

and communication.

10.1 Call Center Management

System

Manages the calls from public (citizens and

businesses) to obtain services or information

from the government agency. With this system,

the government agency can better serve the

public. This system may use for government

agencies that are customer-centric, i.e. there are

many interactions with the public. This system

includes the processes to receive public request

(by phone or email), service the request, and

close the request.

10.2 Customer Relationship

Management System (CRMS)

Manages the customer (public) and government

agency’s relationships. Like the Call Center

Management System, this system aims to

improve the customer service. This system

stores and analyzes information about the public

(citizens and businesses) and their interactions

or needs from the government agency in order

to improve and deliver quality customer service.

The CRMS is also link to the 10.6 Social Media

Management System.




App

No

Supporting Business


10.3 Customer Complaints

Management System

Manages the complaints from the public

(citizens and businesses). The aim of this

system is manage complaints from public in

order to serve them better by addressing their

complaints and concerns. Recorded complaints

are assign to staff for resolution and a follow-up

to respond to the public. This system is

important for government agencies that receive

many complaints. Note that this system can link

- or even develop as a module – under 10.2

Customer Relationship Management System

(CRMS). However, for government agencies

without CRMS, this can be a stand-alone

system.

10.4 Customer Feedback & Survey

System

This system allows public (citizens and

businesses) to feedback on selected issues to

the government agency. In addition, the

government agency can also carry out surveys

on the public. With this system, government

agencies can understand the needs and issues

of the public. Responses can be stored and

analyzed. Various survey results can be further

analyze through 8.3 Business Intelligence

System.




App

No

Supporting Business


10.5 Content Management System Manages the content of the government agency.

This system aims to produce and maintain

standard and consistent content so that the

public can be better and accurately informed.

Content include information and data from

various sources such as documents, and

application systems. It includes management life

cycle from creation, edition, publication, updates

and deletion of the content. This system allows

content to be centrally managed while the final

approved content can be distributed and

published via official websites, intranet and

social media (see 10.6 Social Media

Management).

10.6 Social Media Management Manages social media technologies such as

Facebook, Twitter, LinkedIn and Instagram. This

system allows the integration approach to better

interact with the public on the various social

media platforms. This system can connect to the

CRMS (to get information about public) and

Content Management System (to ensure the

publishing of standard content through the social

media platforms).

Table 4-3: List of supporting application systems

Important Note:

The above list is not exhaustive. In addition, some of the above applications can be combined

or separated. The aim of Table 4-3 is to give an idea of the main supporting application

systems. Enterprise Resource Planning (ERP) system is a common term that combines a few

enterprise functions such as financial management, HR and procurement – these have been

described as separate application systems above. Thus, ERP is not listed specifically as a

supporting application system but as separate application systems.




4.2. Application Components An application component is defined as a modular, deployable, and replaceable part of a

system that encapsulates its contents and exposes its functionality through a set of interfaces1.

All application systems have separate components so that all of the data and functions inside

each component are semantically related. With regard to system-wide co-ordination, application

components communicate with each other via interfaces.

Application components can be developed in advanced and shared. For example, if we prepare

some common components such as Login. Bulletin board and PKI component they can be

reused for other systems.

When we use shared components in application system development, there are many benefits:

1. Reduce cost and development time: Once developed, it can be reused and developers

only call a component when it is needed.

2. Increase flexibility: Runtime components can work independently and they are less

dependent on the environment.

3. Easier management: Administrator can look at or work with individual components

without bringing down entire application system.

4. Improve application system quality: The errors are fixed from reuse to reuse in

application components across several application systems and this leads to a higher

application system quality.

Figure 4-3: Development framework, application components and system2

However, application components can be only used on same development framework 3 or

software language such as JAVA, visual C and C++. Development framework is a skeleton,

1 http://pubs.opengroup.org/architecture/archimate-doc/ts_archimate/index.html “ArchiMate® Version 1.0” 2 http://www.egovframe.kr “E-government standard framework”, NIA, Korea 3 Sometime development framework is called application framework (Wikipedia)




template or generic structure that will cater a skeleton for developing software in a certain

application domain as the figure 4-3. Spring framework4, e-government standard framework of

Korea, and Oracle application development framework5 are widely used.

4.2.1. Application component classifications

Application components can be classified based on the characteristics and functions of them.

Figure 4-4 illustrates seven components’ area and related categories. The description of these

components and sample components are in the next section.

.

Figure 4-4: Application component classifications

4.2.2. Application component descriptions

Table 4-3 lists all the potential or recommended application components and it includes related

sample component as well.

Com.

No

Component area

name / Component

category name

Component category description

4 http://projects.spring.io/spring-framework/ 5 http://www.oracle.com/technetwork/developer-tools/adf/adf-11-overview-1-129504.pdf




Com.

No

Component area

name / Component

category name


1 Collaboration

The component that supports easy and effective communication and information

sharing with the persons concerned.

1.1 Bulletin board The component that supports an online collection of

electronic messages, posted by and accessible to any

authorized user.

(Sample components)

· Board creation management

· Board usage management

· Board management

· Board design template management

· Reply management 1.2 Community The component that provides inquiry, registration,

modification, and elimination function in order to support co-

operation & information sharing among both users having

common interest and common users’ work group and offers

users’ management by a class, verification/administration of

accumulated data, and creation of a community.

(Sample components)

· Community creation management

· Community usage management

· Community member management

· Community template management

1.3 File sharing The component that supports distributing or providing access

to digital media such as computer programs, multimedia

(audio, images and video), documents or electronic books.

(Sample components)

· File management: Manage the attached files, which are

required when handling the business logic, in order to use

file list inquiry and file download functions




Com.

No

Component area

name / Component

category name


1.4 Messenger The component that supports text, voice and / or video

communications between two or more users.

1.5 Online survey The component that supports a questionnaire that the target

audience can complete over the Internet. Online surveys are

usually created as Web forms with a database to store the

answers and statistical software to provide analytics.

(Sample components)

· Questionnaire creation management

· Questionnaire management

· Questionnaire question management

· Questionnaire response management

· Questionnaire template management

1.6 Remote meeting The component that allows visual and audio transfer through

voice over internet protocol. Discussion takes place in real

time and may include graph, document and chart displays

1.7 Schedule sharing The component that supports whole teams or individuals to

inspect, add, modify each other’s work schedules, meeting,

activity, etc.

(Sample components)

· Schedule management: Manage the schedule events

such as seminars, lectures, sessions, meetings and

others, and it features monthly/weekly/daily schedule

management

1.8 Text message The component known as short message service (SMS) that

supports text messaging of phone, Web, or mobile

communication systems.

(Sample components)

· SMS service: Manage the text message transmission

interface for using SMS gateway




Com.

No

Component area

name / Component

category name


2 Data management

The component that supports information’s accumulation, fulfillment, and delivery in

organization.

2.1

Backup/Recovery

The component that creates copies of data to restore the

original after a data loss event or to restore and stabilize data

sets to a consistent, desired state.

(Sample components)

· Backup management: Manage the backup schedule, task

and results

2.2 Data quality

management

The component that ensures data are fit for their intended

uses in operations, decision making and planning and to

ensure internal consistency of the data.

2.3 Extraction

The component that supports the extraction of data from a

database.

2.4

Metadata

Management

The component that manages information where & what kind

of information is stored, how it is encrypted, what kinds of

relationship it has with others, where the data were created,

and what kind of connection it has with work activity.

2.5

Translation /

Conversion

The component that supports the manipulation and change

of data to a different format.

(Sample components)

· Converting date and time (to String or Number)

· Gregorian Islamic calendar conversion

· File conversion to doc, xls, ppt etc.

· Number conversion to string, date, etc.

3 Information provision

The component that supports processing of information for user such as reporting,

searching and translating.

3.1 Language translation

The component that supports changing the source-language

text by means of an equivalent target-language text.




Com.

No

Component area

name / Component

category name


3.2 Geographical

information

The component that is design to capture, store, manipulate,

analyze, manage, and present all types of spatial or

geographical data.

3.3 Real-time information

management

The component that manages and delivers real-time

information immediately upon collection. There is no delay in

the timeliness of the information provided.

3.4

Search

The component that searches typical / atypical information

according to user requirements in the government agency

and displays out relevant results.

(Sample components)

· String search

· Number search

4 Integration management

The component that supports integration of service, data, application and process to

act as a coordinated whole.

4.1

Application Integration

The component that supports the process of bringing data or

a function from one application program together with that of

another application program.

4.2

Data Integration

The component that supports combining data residing in

different sources and providing users with a unified view of

these data.

4.3

Process Integration

The component that supports to integrate business

processes that are an accountable way of communicating

information between entities like people, organizations and

governments for an anticipated means.

4.4

Service Integration

The component that supports to integrate multiple suppliers

of service to a single business-facing IT organization. It aims

at seamlessly integrating interdependent services from

various internal and external service providers into end-to-

end services in order to meet business requirements.




Com.

No

Component area

name / Component

category name


5 Security

The component that prevents and protects information of government agencies &

individuals from the internal and external threats.

5.1 Digital rights

management

The component that supports various access control

technologies to restrict the usage of proprietary software,

hardware, or content.

(Sample components)

· Copyright protection policy: Manages copyright protection

policy and information sharing policy notified to users

when registering

5.2 Digital signature The component that supports and manages electronic

signatures

5.3 Encryption The component that converts plain text to cipher text with a

cryptographic algorithm.

(Sample components)

· File Security: Manages a function to encrypt files using

the encryption algorithm or to decrypt files using the

decryption algorithm

5.4 User authentication The component that allows a device to verify the identity of

someone who connects to a network resource.

5.5 User authorization The component that supports authorization towards

computer, application, network’s users or group of users.

(Sample components)

· Authority management

· Authority group management

· Role management

5.6 Virus protection The component that prevents, detects, and removes self-

replicating programs that run and spread by modifying other

programs or files.




Com.

No

Component area

name / Component

category name


6 System operation

The component that supports efficient operations of systems such as system

configuring, monitoring, and error-responding tasks.

6.1 Configuration

management

The component that supports administration of system’s

components (H/W, N/W, S/W, etc.) through identification,

control, maintenance and verification of logical models or

services.

It also defines as the ability to properly control IT

infrastructures and services in the organization.

6.2 Connection

management

The component that manages the activities and features of a

device connection.

(Sample components)

· System connection status management

· Connection statistics

· SSO connection management

6.3 Failure management The component that supports handling the situation and

make it possible to provide normal service at early time in

case serious problems happen on application, data, network,

etc. its definition is to aid works such as back-up / restore /

damage-handling, etc.

(Sample components)

· Failure application management: Manage the functions of

registering, modifying, deleting, inquiring and inquiring

lists of failure application information

6.4 Remote control The component that supports performing - as using one’s

own computer - software, server, network management

works, such as program execution control, server load

management, etc., in the distant area with transmitting

graphic data in order to see remote computer’s screen from

the control computer in real time.




Com.

No

Component area

name / Component

category name


6.5 S/W distribution The component that supports installed computer programs,

application/delivery of components, installation & upgrade. It

makes easy to install new program to many PCs.

6.6 Synchronization The component that synchronizes the time and data among

physically separate systems.

(Sample components)

· File synchronization: Manage the functions to attach and

download files by synchronizing AP servers

6.7 System monitoring The component that supports memory use of computers &

applications, and balance & assignation of disk space &

outcome.

(Sample components)

· Server resource monitoring

· HTTP service monitoring

· Network service monitoring

· Process Monitoring

· DB Service Monitoring

· File System Monitoring

7 User support

The component that improves user’s system usage experience. It makes system

usage convenient and easy depending on personal traits.

7.1 Common Code

Management

The component that provides the function to register, update,

inquire the list and inquire details of the common codes.

(Sample components)

· Common code management: Manage the function to

register, update, inquire the list and inquire details of the

common codes




Com.

No

Component area

name / Component

category name


7.2 Notification The component that notifies relative service to users such as

mailing service, POP, message reception, etc.

(Sample components)

· Popup management

· Event management

7.3 Online Help The component, which is one of the aid forms provided in an

application program, offers explanation or instruction about

using the function of application program, information, and

help needed while using application program.

(Sample components)

· Online manual

· FAQ management

· Q&A management

7.4 Personalization The component that supports user’s interface or information

offer according to a user or user needed type.

(Sample components)

· My page: Manage user-favorite information in the form the

user likes such as: content register, modify, delete, view

and configure my page.

7.5 Registration The component that registers internal / external users with

identifiers for the right to access and use the relevant

systems.

7.6 User Experience The component that manages a person's perceptions and

responses that result from the use or anticipated use of a

product, system or service.




Com.

No

Component area

name / Component

category name


7.7 Web Editor The component that supports ability to edit various

documents in the web pages.

(Sample components)

· Web Editor: Manage freely editing the contents by the

user at board, and memo pad of library. It shall have the

functions of supporting the text & HTML editing function

and of image upload and of displaying image to the editor.

Web editor can be used at the location of web browser

with the input function such as board, announcement,

library, and photograph album

Table 4-4: Application component areas and categories




4.2.3. A sample of reusable component After an organization adopts CBM and establish or select a software development framework, it

can develop common components that are the collection of reusable common modules. At the

same time, it can utilize the pre-existing components developed by same software development

framework. The reusable components consider development and database environment, and

MVC pattern6.

Figure 4-5: Common component and software development framework

Below table shows the sample component guideline including the detail explanation of business

rule, related source code, class diagram and database table.

Criteria Description Example

Name Name of

component

Board management

Summary Detail

information or

functions of

component

Board management component provides registering the post

and inquiring list of post registered for management of board to

be used commonly for sharing of information between users

6 Model-View-Controller (MVC) is a software architectural pattern. It divided a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user.(Wikipedia)





Package

Dependency

Some

components

related with

other

components

and packages

Board package has direct functional dependency to the

common package and system package as well as

format/calculation/conversion package.

Related

Source

Related source

and original

source code

name

Type Source Remarks

Controller egovframework.com.cop.bbs. EgovBBSManageController.java

Controller class for board management

Service egovframework.com.cop.bbs.service. EgovBBSManageService.java

Service interface for board management

ServiceImpl egovframework.com.cop.bbs.service.impl. EgovBBSManageServiceImpl.java

Service implementation class for board management

Model egovframework.com.cop.bbs.service. Board.java

Model class for board management

Model egovframework.com.cop.bbs.service. BoardMaster.java

Model class for management of board property information

VO egovframework.com.cop.bbs.service. BoardVO.java

VO class for board management

VO egovframework.com.cop.bbs.service. BoardMasterVO.java

VO class for management of board property information

DAO egovframework.com.cop.bbs.service.impl. BBSManageDAO.java

Data processing class for board management

JSP /WEB-INF/jsp/egovframework/com/cop /bbs/EgovNoticeRegist.jsp

jsp page for post creation

JSP /WEB-INF/jsp/egovframework/com/cop/bbs/ EgovNoticeUpdt.jsp

jsp page for update of created post

JSP /WEB-INF/jsp/egovframework/com/cop/bbs/ EgovNoticeUpdt.jsp

jsp page for update of created post

… … …

Class

Diagram

Class

relationship

diagram





Related

Table

Database table

information

Name Explanation

COMTCCMMNDETAILCODE Board code management COMTNBBS Board information management COMTNBBSUSE Board usage management COMTNFILE Board attached file’s attribute management COMTNFILEDETAIL Board attached file’s information management COMTNTMPLATINFO Board template management

Related

Function

Sub function,

business rule,

execute

manual, and

screen shot,

etc.

Board management is composed of post list inquiry, post detail

inquiry, post update and answer writing function.

Post list inquiry (sample)

Explanation

Business rule

Provide the screen to inquire the post list. List inquiry screen for posting exists in 3 types including URL link(system use board), access through community and access through society

execute manual

Board list is inquired by 10 items per page. The paging consists of 10 pages. The condition of search is implemented by the Board name and Board Type. To update the scope of search per page, update pageUnit, pageSize of context-properties.xml file.

screen

To register new posting, use the Register button on the top. To check the contents of posting, select the title to move to the Posting Detail Inquiry screen

Reference See board creation management function

Table 4-5: Board management component sample

4.3. Application Interface An interface expresses a software component in terms of its operations, inputs, outputs, and

underlying types. It defines functionalities that are independent of their respective

implementations, which allows definitions and implementations to vary without compromising

the interface. It makes easier to develop an application by providing all the building blocks that

can be put together. It can also ease the work of extending applications by facilitating the

integration of new features into existing applications (a so-called "plug-in Interface").




Benefits

Providing information and services through interfaces supports interoperability and openness.

Well-designed application interfaces make data freely available for use within agencies,

between agencies, in the private sector, or by citizens.

1. Increase the reach of system services by allowing other agencies, partners, and the

private sector to integrate, and amplify, government agency’s data and content

2. Save costs by allowing third-party innovators to use information and services to create

new, useful products that are beyond the scope - or budget - of government agency

3. Build markets by improving access to government resources like health, economic,

energy, education, environmental resources for entrepreneurs to build upon

4. Leverage on government assets: Data and information produced by government

agencies are a national asset, paid for by the citizens. APIs can expose data that was

only available to a few and make it more available to everyone

5. Automation: It allows machines to handle the workload, which would otherwise require

the manual work of a human. In addition, it enables integration between government

agencies to run their business workflows so that they can be done with fewer steps and

greater productivity without human involvement

6. Integration: It allows data and information exchange to be more easily throughout

government agencies or other external enterprise applications. Thus, it ensures a

smooth and integrated user experience, and relevant and up-to-date information, for the

user. The information is delivered wherever it can be useful to users, not just in those

places where data are created and maintained.




4.3.1. Application interface classifications

The usefulness of an application system is extended when it can be linked or have an interface

to another application system. Instead of performing all the functions required, an application

system can interface to so that another application system can carry out a specific function and

/ or to pass processed data. An application interface can be either library-based or protocol-

based as shown in Figure 4-6.

Figure 4-6: Application interface classifications




4.3.2. Application interface description

Table 4-6 lists all the recommended application Interfaces.

Int.

No

Interface area

name / Interface

category name

Interface category description

1 Library Based Interface: It is usually related to a software library; the interface

describes and prescribes the expected behavior while the library is an actual

implementation of this set of rules. It is usually specific to a given technology; hence

a Library based Interface for a given language cannot be used in other languages,

unless the function calls are wrapped with specific adaptation libraries.

1.1 API Application programming interface (API) comes in the form of

a library that includes specifications for routines, data

structures, object classes, and variables. To use this type of

application interface, an application will reference or import a

library of code or of binary functions, and use the

functions/routines from that library to perform actions and

exchange data and information.

Object-Oriented based APIs provide data and functionality

organized around classes, as defined in object-oriented

languages. Each class offers a discrete set of information

(attributes) and associated behaviors (methods).

2 Protocol Based Interface: It is usually a standardized service based on a common

protocol (rules for how the service works) and formats (schema for using the

service) that are familiar to developers.




Int.

No

Interface area

name / Interface

category name


2.1 TCP/IP It is the computer networking model and set of

communications protocols used on the Internet and similar

computer networks. It is the most important protocols; the

Transmission Control Protocol (TCP) and the Internet

Protocol (IP) were the first networking protocols defined in

this standard. TCP/IP provides end-to-end connectivity

specifying how data should be packetized, addressed,

transmitted, routed and received at the destination. This

functionality is organized into four abstraction layers which

are used to sort all related protocols according to the scope

of networking involved From lowest to highest, the layers are

the link layer, containing communication methods for data

that remains within a single network segment (link); the

internet layer, connecting independent networks, thus

establishing internetworking; the transport layer handling

host-to-host communication; and the application layer, which

provides process-to-process data exchange for application.

2.2 HTTP The Hypertext Transfer Protocol (HTTP) is an application

protocol for distributed, collaborative, hypermedia information

systems. HTTP is the foundation of data communication for

the World Wide Web. Hypertext is structured text that uses

logical links (hyperlinks) between nodes containing text.

HTTP is the protocol to exchange or transfer hypertext.

HTTP functions as a request-response protocol in the client-

server computing model. A web browser, for example, may

be the client and an application running on a computer

hosting a web site may be the server.




Int.

No

Interface area

name / Interface

category name


2.3 FTP File Transfer Protocol (FTP) is a standard network protocol

used to copy a file from one host (network/internet connected

computer) to another over a TCP-based network, such as the

Internet. FTP is built on a client-server architecture and uses

separate control and data connections between the client and

the server.

FTP is the standard method used for transferring files to a

website or server and FTP is supported/offered by almost all

web hosting companies/providers.

2.4 SOAP Simple object access protocol (SOAP) is a lightweight

protocol that allows applications to pass messages and data

back and forth between disparate systems in a distributed

environment enabling remote method invocation.

It codifies the use of XML as an encoding scheme for request

and response parameters using HTTP protocol as a means

for transport. It possesses send and receive HTTP (or other)

transport protocol packets, and process XML messages

(envelopes).

It covers the following four main areas:

A message format for one-way communication

describing how a message can be packed into an XML

document.

A description of how a SOAP message should be

transported using HTTP (for Web-based interaction) or

SMTP (for e-mail-based interaction).

A set of rules that must be followed when processing a

SOAP message and a simple classification of the entities

involved in processing a SOAP message.

A set of conventions on how to turn an RPC call into a

SOAP message and back.




Int.

No

Interface area

name / Interface

category name


2.5 REST Representational State Transfer (REST) defines a set of

architectural principles by which Web services (Web APIs)

can be designed that focus on a system's resources,

including how resource states are addressed and transferred

over HTTP by a wide range of clients written in different

languages.

A concrete implementation of a REST Web service follows

four basic design principles:

Use HTTP methods explicitly.

Be stateless.

Expose directory structure-like URIs.

Transfer XML, JavaScript Object Notation (JSON), or

both.

2.6 GSB The Government Service Bus (GSB) is the national

infrastructure that contains integrated structure of hardware

and software designed to facilitate exchange of shared

government data among government agencies for safe and

timely online delivery of services.

There are two aspects of integration with GSB. One aspect is

integration of a government agency with GSB as a provider

of services and data for use by other agencies through GSB.

Each government agency can integrate with GBS as a

consumer of services and data provided through GSB.




Int.

No

Interface area

name / Interface

category name


2.7 EAI Enterprise application integration (EAI) is an integration

framework composed of a collection of technologies and

services which form a middleware to enable integration of

systems and applications across an enterprise.

EAI may involve developing a new total view of an

enterprise's business and its applications, seeing how

existing applications fit into the new view, and then devising

ways to efficiently reuse what already exists while adding

new applications and data.

Table 4-6 : Application Interface areas and categories




4.4. Best Practices & Guidelines Although the application elements were describe in the previous sections, it is also good to

follow best practices and guidelines in application design and development.

Best practices and guidelines are a compilation of the best methods and techniques globally for

application design and development. The basic idea is to learn from the internationally

recognized practices so that government agencies can produce quality application systems,

components and interfaces. These best practices and guidelines are not mandatory for

government agencies. As the name suggest, these are very good things to follow and adopt

where possible.

Except when specific cases are describe, these best practices and guidelines apply to

application systems, components and interfaces. In many instances, they are very much inter-

related and, thus, these best practices would be applicable to the application systems,

components and interfaces.

These best practices and guidelines provide the following benefits:

1. Design and develop qualified application systems, components and interfaces that are

agile and reusable

2. Reduce time to develop application systems

3. Prevent costly mistakes and errors commonly made.

4.4.1. Application architectural style

An architectural style is a set of principles and patterns that provides an abstract framework for

a family of systems. An architectural style improves partitioning and promotes design reuse by

providing solutions to frequently recurring problems. Another important benefit of architectural

styles is that they provide a common technical architectural language. This facilitates a higher

level of conversation that is inclusive of patterns and principles, without getting into specifics.

Architectural styles include patterns such as client/server, service-oriented architecture (SOA),

and N-tier. It is important to understand that the styles describe different aspects of applications.

The following sub-sections list the common architectural styles that should be included in a

typical application architecture:




4.4.1.1. Client/Server architectural style7

The client/server architectural style describes a distributed application structure that

partitions tasks or workloads between the providers of a resource or service, called

servers, and service requesters, called clients. Often clients and servers communicate

over a computer network on separate hardware, but both client and server may reside

in the same system. This style describes the relationship between a client and one or

more servers, where the client initiates one or more requests, waits for replies, and

processes the replies on receipt. The server typically authorizes the user and then

carries out the processing required to generate the result. The server may send

responses using a range of protocols and data formats to communicate information to

the client. Common examples of computer applications that use the client/server

architectural style are Email, network printer and the World Wide Web.

4.4.1.2. Service-Oriented architectural style

Service-oriented architecture (SOA) enables application functionality to be provided as

a set of services, and the creation of applications that make use of software services.

Services are loosely coupled because they use standards-based interfaces that can be

invoked, published, and discovered. The SOA style can package business processes

into interoperable services, using a range of protocols and data formats to

communicate information. Clients and other services can access local services running

on the same tier, or access remote services over a connecting network.

The key principles of the SOA architectural style are:

1. Services are autonomous. Each service is maintained, developed, deployed,

and versioned independently

2. Services are distributable. Services can be located anywhere on a network,

locally or remotely, as long as the network supports the required communication

protocols

3. Services are loosely coupled. Each service is independent of others, and can

be replaced or updated without breaking applications that use it as long as the

interface is still compatible

4. Services share schema and contract, not class. Services share contracts and

schemas when they communicate, not internal classes

7 Wikipedia




5. Compatibility is based on policy. Policy in this case means definition of features

such as transport, protocol, and security.

The main benefits of the SOA architectural style are:

1. Domain alignment. Reuse of common services with standard interfaces

increases business and technology opportunities and reduces cost

2. Abstraction. Services are autonomous and accessed through a formal

contract, which provides loose coupling and abstraction

3. Discoverability. Services can expose descriptions that allow other

applications and services to locate them and automatically determine the

interface

4. Interoperability. Because the protocols and data formats are based on

industry standards, the provider and consumer of the service can be built and

deployed on different platforms

5. Rationalization. Services can be granular in order to provide specific

functionality, rather than duplicating the functionality in number of applications,

which removes duplication.

4.4.1.3. N-Tier / 3-Tier architectural style

N-tier and 3-tier are architectural deployment styles that describe the separation of

functionality into segments each segment being a tier that can be located on a

physically separate computer. N-tier application architecture is characterized by the

functional decomposition of applications, service components, and their distributed

deployment, providing improved scalability, availability, manageability, and resource

utilization. Each tier is completely independent from all other tiers, except for those

immediately above and below it. N-tier architectures usually have at least three

separate logical parts, each located on a separate physical server. Each part is

responsible for specific functionality. When using a layered design approach, a layer is

deployed on a tier if more than one service or application is dependent on the

functionality exposed by the layer.

The main benefits of the N-tier/3-tier architectural style are:

1. Maintainability. Because each tier is independent of the other tiers, updates or

changes can be carried out without affecting the application as a whole




2. Scalability. Because tiers are based on the deployment of layers, scaling out an

application is reasonably straightforward

3. Flexibility. Because each tier can be managed or scaled independently,

flexibility is increased

4. Availability. Applications can exploit the modular architecture of enabling

systems using easily scalable components, which increases availability.

4.4.2. Application development life-cycle model

As a guideline, government agency should have a standard application development life-cycle

model. Although there are many lifecycle models, the common ones are waterfall, prototyping

rapid application development and spiral models. Government agencies can also consider

adopting the Yesser System Development Lifecycle (SDLC) methodology. Below are simple

descriptions about the common application development life-cycle models and Yesser SDLC.

4.4.2.1. Waterfall model

Although the waterfall model originated from the manufacturing and construction

industry, it has been a popular application development model since the 1970s. The

waterfall model was adapted into software and application development as there was

no formal application development model back then.

As defined by Wikipedia, the waterfall model is “a sequential design process, used in

software development processes, in which progress is seen as flowing steadily

downwards (like a waterfall) through the phases of conception, initiation, analysis,

design, construction, testing, production/implementation and maintenance”.




Figure 4-7: Waterfall model

4.4.2.2. Prototyping model

One of the main disadvantages of the waterfall model is that users have to wait a long

time before they can see a ‘draft’ model or something to test. Prototyping model is to

develop quickly a simple prototype so that users can have a good idea of the system

and to give more requirements in terms of both functionalities and design.

Wikipedia defines it as “software prototyping is the activity of creating prototypes of

software applications, i.e., incomplete versions of the software program being

developed. It is an activity that can occur in software development and is comparable to

prototyping as known from other fields, such as mechanical engineering or

manufacturing”. The basic steps of prototyping are shown in Figure 4-8. Once the

prototype is acceptable, the application will be fully developed, tested and implemented.

This model has other variations such as Throwaway Prototype and Incremental

Prototyping.

Figure 4-8: Prototyping model

4.4.2.3. Rapid application development (RAD) model

The RAD model aims to run two parallel steams of planning and coding – thus it has a

fast development turnaround time. The RAD model is define in Wikipedia, as “Rapid

application development (RAD) is a software development methodology, which favors

iterative development and the rapid construction of prototypes instead of large amounts

of up-front planning. The "planning" of software developed using RAD is interleaved




with writing the software itself. The lack of extensive pre-planning generally allows

software to be written much faster, and makes it easier to change requirements”.

Figure 4-9 below shows RAD model.

Figure 4-9: RAD model

4.4.2.4. Spiral model

The spiral model is where a set of standard processes goes through the cycles of

application development. Wikipedia defines it as “the spiral model is a risk-driven

process model generator for software projects. Based on the unique risk patterns of a

given project, the spiral model guides a team to adopt elements of one or more process

models, such as incremental, waterfall, or evolutionary prototyping” as illustrated in

Figure 4-10.

In each cycle of the model, there is a set of four activities:

1. Determine objectives (i.e. the success factors of the stakeholders)

2. Identify and resolve risks (thus, this model is also risk-driven)

3. Develop and test

4. Plan for the next iteration.

The spiral model is typically good for complex systems with various application

development options and schedules. It is possible that the outcome of the large

application system has different modules being develop using different models.




Figure 4-10: Spiral model

4.4.2.5. Yesser SDLC

The Yesser SDLC process key elements can be thought of as high level grouping for

one or more activity within the process that achieve a common goal or objective. Below

is a list of the Yesser SDLC process key elements:

1. RFC Assessment

2. Requirements Gathering & Development

3. Solution Architecture

4. Solution Design

5. Solution Development

6. Solution Verification (Quality Control)

7. Solution Deployment

8. Configuration Management

9. Quality Assurance

10. Solution Tracking & Monitoring




Figure 4-11 shows the summary of Yesser SDLC. For more details, please refer to

Yesser website or request for a copy of the methodology.

Figure 4-11: Yesser SDLC

4.4.3. Application development methodology

An application development methodology is used to structure, plan, and control the process of

developing an information system. The methodology may include the pre-definition of specific

deliverables and artifacts that are created and completed by a project team to develop or

maintain an application. Table 4-6 shows the sample of component based development artifacts.

It will ensure consistent application development practices in the government agency. Even for

outsource application development, the standard application development methodology should

be a standard requirement for the application vendor to comply.

A standard application development methodology is also promoted as a means of improving the

management and control of the software development process, structuring and simplifying the

process, and standardizing the development process and product by specifying activities to be

done and techniques to be used. It is often tacitly assumed that the use of a standard

application development methodology will improve system development productivity and quality.

However, there are many kinds of application development methodologies exist such as

information engineering, object oriented, component-based and agile. Also, to reuse common




components, not only pre-developed components but also component-based development

method should be necessary.

Process Artifacts

Analysis A1.User requirement definition A2.Use case description A3.User requirement tracing

Design

D1.Class design D2.User interface design D3.Component design D4.Interface design D5.Architecture design D6.Total test plan D7.System test scenario D8.Entity relation diagram D9.Database design D10.Integrationi test scenario D11.Unit test case D12.Data migration and initial data design

Implementation I1.Program code I2.Unit test result I3.Database table

Test

T1.Total test result T2.System test result T3.User manual T4.Operation guideline T5.System implement result T6.Acceptance test plan T7.Acceptance test result

Table 4-7: Sample of CBD artifacts

Component-based development emerged in the late 1990s as a reuse-based approach to

application systems development. It was motivated by the frustration that the object oriented

programing (OOP) had not led to extensive reuse originally suggest. The proponents of OOP

maintain that SW should be written according to a mental model to the actual or imagined

objects if represents8. OOP focus on modeling real-world interactions and attempting to create

“nouns” and “verbs” that can be used in more human-readable ways, ideally by end users as

well as programmers coding. By contrast, CBD makes no such assumptions, and instead states

8 Wikipedia “Component-based software engineering”




that developers should construct software by gluing together prefabricated components. It

emphasizes reusable components and embodies the “buy” don’t “build” philosophy9.

Figure 4-12: A simple example of several components (holiday reservation system represented in

UML 2.0)10

Figure 4-12 shows an ideal process of CBD. Its assumption is that the components selected

and used are sufficiently close to the units identified in the design process, so that the

adaptation process requires (significantly) less efforts then the units’ implementation. That is the

reasons CBD method will reduce cost and development time, increase flexibility, make easier

management, and Improve application system quality.

9 Debayan bose “Component based development” 10 Wikipedia




Figure 4-13: V development process for CBD 11

4.4.4. Application environments

To ensure security and quality, it is a best practice to have the following environments for

application systems:

1. Development Environment

This environment is solely for application development. Fully developed application

systems, components and objects are migrated to the test environment.

2. Test Environment

The testing of application systems, components and codes are first carry out in the test

environment. On testing completion, the application components and objects will be

migrated to the UAT environment.

3. UAT (User Acceptance Testing) Environment

Business users will carry out the functional testing in this environment.

4. Production Environment

Only when the application system is fully tested, the components and objects will be

migrated to the production environment where the application system will be officially in

use.

11 Ivica Crnkovic et al. “Component-based Development Process and Component Lifecycle”




4.4.5. Application design

It is a best practice to have a standard software development framework – to be use internally

and even for outsource application development. The framework ensures a control design and

environment for developing, assembling and testing components and services. The software

development framework is a set of prewritten code or libraries that provide functionality common

to a whole class of application.

The purpose of using a standard software development framework is basically to speed up

development by not having to rewrite features and structure that are commonly used in most

applications. Instead of inventing the wheel over and over again, the developer has many

wheels (functions/features etc.) that are already tested and working properly12.

Many people equate the term software development framework with an object-oriented software

library, or set of libraries, intended to provide reuse. However, there is an important difference

between a framework and a library, that difference is often called “inversion of control.” If you

are using a library, the objects and methods implemented by the library are instantiated and

invoked by developers’ custom application. Developers need to know which objects to

instantiate and which methods to call in order to achieve developers’ goals. On the other hand,

if developers are using a framework, developers implement the objects and methods that are

custom to developers’ application and they are instantiated and invoked by the framework13.

Figure 4-14: The benefit of SW framework

12 M Björemo, “Evaluation of web application frameworks” 13 Mike Baker, “What is a Software Framework? And why should you like 'em?”




In the 2000s, many software development frameworks were announced and published to

overcome software industry’s critical situation such as inconsistent development approach,

increasing development costs and low software development quality. It helps to realize

productivity, scalability, performance and easy management in software development. In

addition, it enhances IT service quality because developers focus only on their business logic

while all technical issues are handled by software development framework. There are many

kinds of software development framework. Some of them are published as a free open source

software so it allows to be freely used within a condition14.

Figure 4-15: SW development paradigm

14 See https://opensource.org/approval




Figure 4-16: Korean government SW development framework’s composition functionalities

4.4.6. Application development

It is a best practice to have the following:

1. Standard Naming Convention

The worth of a software or application system is in the documentation. A standard

naming convention ensures that the software is readable and traceable. It will also help

to quickly search and find the required information.

2. Standard Error Logging Process & Message

Errors will occur in all application systems. In order to provide quality application

systems, standard error logging process and error messages aid the de-bugging and

solving application errors. Note that some software development framework allows the

definition of standard error logging process and messages.

3. Standard Source Code Documentation




In addition to the standard naming convention, source code should comply with standard

documentation standards. It gives a uniform look to the source codes and makes it

readable. Source code documentation is useful for developers during development, de-

bugging and amending the codes.

4. Standard Application Development Library and Components

Finally, a standard application development library allow components to be retrieve and

reuse. This will speed up the application development process, reduce the amount of

total errors and reduce the overall development cost. An application library is a collection

of commonly used components, functions, classes or subroutines that provide ease of

development and maintenance by allowing developers to easily add or edit

functionalities.

As mentioned in the section Application Design above, it is important to note that the

libraries should be instantiated and invoked within the application framework.

It is common to have one software development framework with multiple libraries

supporting different application platforms such as J2EE, .NET and Android. The Figure

4-16 illustrates the basic parts of software development library. Over time, the

developers can create reusable components that are group into functional or related

classes such as security (e.g. authentication and PKI), validation (e.g. input data formats

and basic logic), data calls (i.e. making standard calls to specific data sources) and

dates (e.g. checking for future business working day). These components in the library

are assemble and expose via API call into the framework. Please note that these

functions in the development library may complement the functions described in the

framework above.




Figure 4-17: Software development library

4.4.7.Application interface

To link and communicate with other services, systems, components or data, it is a best practice

to have the following application interface.

Interface specifies the services that other applications (or systems) can utilize, and how they

can do so. This interface can be seen as a signature of the application - the client application

does not need to know about the inner workings of the application (implementation) in order to

make use of it. The interface of an application defines the services provided by the application

separately from the actual implementation of them inside the application. Because of that

separation, accessing application through its published interface reduces dependency on the

internal implementation details specifics and so replaces the implementation of the services by

another implementation of the same interface should not cause client application to fail.




Application Interface often comes below in different forms based on the way they can be

communicated and called.

4.4.7.1. Libraries based Interface

An interface is usually related to a software library. The interface describes and

prescribes the expected behavior while the library is an actual implementation of this

set of rules. Such form of interface are usually specific to a given technology, hence a

library based Interface for a given language cannot be used in other languages,

unless the function calls are wrapped with specific adaptation libraries.

When an information/data is exchanged via a local interface to a single machine the

data is effectively exchanged (or a reference to it) in memory: e.g. via memory

allocated by a single process, or among multiple processes using shared memory, an

application server.

4.4.7.2. Protocols based Interface

An interface can also be an implementation of a protocol. When an interface

implements a protocol it can be based on proxy methods for remote invocations that

underneath rely on the communication protocol. The role of the interface can be

exactly to hide the detail of the transport protocol.

Protocols can be considered remote interfaces that usually shared between different

technologies to allow the different technologies to exchange information, acting as an

abstraction/mediation level between the two different environments.

An interface protocol is usually a standardized service based on a common protocol

(rules for how the service works) and formats (schema for using the service) that are

familiar to developers. APIs are, at their most basic, a combination of protocol (the

means of interacting with data and services) and format (the model by which the data

and services are arranged in order to allow such interaction). Interface protocols are

typically either SOAP (Simple Object Access Protocol) or REST (Representational

State Transfer). REST is recently preferred by many because it’s based on the familiar

http Web protocol.




To enable the exchange of information among systems that use different technologies,

when an interface implements a protocol, it can prescribe a language-neutral message

format. Formats of Interface protocols are usually either XML (Extensible Markup

Language) or JSON (JavaScript Object Notation). JSON is increasingly popular with

developers due to its speed, ease of use, and wide acceptance. SOAP uses XML as a

general container for the messages to be exchanged, similarly REST API can use

both XML and JSON.

When a message is exchanged via an interface protocol between two different

platforms using objects on both sides, the object in a programming language can be

transformed (marshalled and un-marshalled) in an object in a remote and different

language.

4.4.7.3. Yesser GSB

Yesser has established the Government Service Bus (GSB) that is protocol based

interface to facilitate exchange of shared government data among government

agencies for safe and timely online delivery of services. GSB is to enable government

agencies deliver online services in an integrated, easy and simple manner. The

concept of e-Government requires all government agencies to deliver their services

and make their data accessible to supplement services offered by other government

agencies. This is done through GSB. Figure 4-18 shows the way of integration and

interlink among government agencies through GSB.




Figure 4-18: GSB

GSB service consumers need to follow the below guidelines to develop client

application that invoke the SOA based web services offered by providers:

- Consumer should interlink to Government Secure Network (GSN) before starting

integrating with GSB based services providers. GSN represents the physical

interconnection channel among government agencies.

- Get the WSDL (Web Services Description Language) file that defines the actual

contract a service exposes. Most of the existing development IDE(Integrated

Development Environment)s and web service development tools can automatically

build the skeleton of the service client from the WSDL by creating an object model

that corresponds to the data structures used by the service and will also handle

the operations’ invocation and the low level details of SOAP protocol messaging.

- Include the following headers (YEFI15 header, WS-Addressing, and WS-Security)

in the GSB SOAP Massage request :

o YEFI Header: It is a custom Web Service SOAP header that conveys basic

information about the consumer. It contains the following mandatory

attributes (Source ID, Source Name, Service ID)

o WS-Addressing: It is a specification of transport-neutral mechanisms that

allow web services to communicate addressing information. An important

attribute in WS-Addressing header is the Message ID, which is a UUID

(Universally Unique Identifiers) that is used to track request and response

messages.

o WS-Security: the WS-Security username token is a runtime configuration

that needs to be enabled by the service’s client. This configuration can be

enabled through the client generation wizard in most of the modern IDEs. It

requires a username and password credentials to be included as header

attributes for service authentication.

- If it is needed, attach documents to the GSB SOAP message request by following

guidelines of Message Transmission Optimization Mechanism (MTOM) standard.

MTOM is the W3C standard that is supported by most software development

platforms.

- Table 4-7 illustrates current available services through GSB

Provider Services

15 Yesser Framework for Interoperability




Provider Services

Ministry of Interior

· Citizen/Expat profile

· Citizen/Expat life status

· Citizen/Expat traffic violations

· Expat exit visa.

· Expat legal status

Dept. of Zakat and Income tax · Zakat record verification

Ministry of Commerce and Industry · Commercial registration

Ministry of Civil Service · Job status

Council of Saudi Chambers · Chamber of commerce membership

National Center for Assessment-Qiyas · Qiyas examination results

Saudi Post

· Verification of postal address/ by ID number

· Verification of "Wasil" address/ by ID number

· WASEL Address inquiry for individuals and establishments

Ministry of Education · Student records

General Organization for Social Insurance

· Job status

· GOSI membership

Ministry of Municipal and Rural Affairs · Contractor classification

· shop licenses

Saudi Industrial Development Fund · Loan status inquiryRiyadh Municipality

· Building licenses

· Shop licenses

Makkah Municipality Jeddah Municipality

Al-Madina Municipality Al-Ahsa Municipality

Al-Qassim Municipality Jazan Municipality Najran Municipality

Eastren Province Municipality Tabuk Municipality

Taif Province Municipality AlJouf Municipality

Hail Municipality Assir Municipality

Albaha Municipality

Technical Vocational Training Corparation

· Alumni records

· Shamel exams results

Ministry of Labor

· Nitaqat (Inquiry about details of the business

category in “Nitaqat” classification for Saudization purposes).

· Tawteen (Inquiry about Tawteen information for an establishment).




Provider Services

Inistiute of Public Administration · Training programs

· Alumni recordsKing Fahd University of Petroleum and

minerals · Alumni records Prince Sattam Bin Abdallaziz University

Dammam University

· Alumni records

· Student enrollment

King Saud University Imam Muhammad Ibn Saud Islamic

University Taif University

King Faisal University King Abdulaziz University Umm Al-Qura University King Khaled University

Jeddah University Najran University

Saudi Electronic University Jazan University

Communications and information Technology Commission

· Saudi Domain Names (Nitaqat): Inquiry, initial registration and suggesting the Saudi Domain Names (Nitaq) online.

Saudi Commission for Tourism & Antiquities

· Time sharing license

· Tourist guide license

· Travel agency license

· Tourism operator

· Tourism accommodations license Saudi Arabian General Investment

Authority · Licenses details

Saudi Arabian Monetary Agency · Account balance for government agencies

· Bank Statement for government agencies

Ministry Of Justice · Real estate deeds

· Attorney

· Law practice licensePrince Sultan Military Medical City

· Electronic health file

National Guard Health Affairs King Faisal Specialist Hospital

Security Forces Hospital King Fahd Medical City

Ministry of Foreign Affairs · Visa status inquiry

Ministry of Finance

· Budget (This service enables Government Agencies to avail budget related functionalities).

· General Accounting (This service enables Government Agencies to avail General Accounting related functionalities).

· Payment Order




Provider Services

Saudi Credit And Savings Bank · Clearance record inquiry

Real Estate Development Fund · Loan inquiry

Public Pension Agency · Pension information

Table 4-8: KSA GSB service catalogue

Main advantages of interlinking with GSB are:

GSB is a central platform for interlinking and integration among government

agencies with respect to data and information needed for delivery of e-services.

It helps government agencies establish integrated e-services.

Services delivered through GSB are of high quality, performance, creditability

and reliability.

Regularly updated data.

Interlinking with GSB saves time and cost as compared to interlinking and

integration between each agency and another.

Enables government agencies process and deliver their services completely

online.

Reduced e-services development lifecycle.

Services from each government agency are accessible by all government

sectors.

An added value of interlinking to GSB as a user:

o GSB is a single repository for all government services and data

o GSB helps maximize efficiency of e-services for the user by depending on

services delivered by GSB.

o Provides the user with highly reliable data that meets standard criteria.

o Enhances transparency, equity and equality upon delivering of e-services.

The added value for integration with GSB as a service provider:

o Provides a single platform and place for exhibiting and marketing of all

services in order to realize “Building once for multiple use” principle.

o Saves costs of individual interlinking of each government agency with

another.

o Realizes “Paperless government” principle.




4.4.8. Application testing

It is a guideline to have the following:

1. Standard Testing Methodology

The standard testing methodology defines the business case as to when to use the

appropriate testing method(s) such as unit testing, string testing, load testing, stress

testing and usability testing. With the standard testing methodology, all stakeholders –

developers, users, project managers and vendors - are clear about what are the

expectations from the various testing scenarios. A thorough standard testing

methodology, which includes test pass indicators, increases the quality of application

development and deployment.

2. Automated Test Tool

A test tool overcomes the laborious and error-prone manual testing approach. The

automated test tool can define the test objectives, test scenarios, test data and test

simulations. It speeds up the testing process while increases the final quality of the

application systems.

4.4.9. Application configuration management

It is a best practice to have an application configuration management that ensures effective

management of application systems, components and interfaces resulting in quality delivery of

application systems. Application configuration management is mainly about processes –

registering, tracking, approving and deploying application components and objects. It is a best

practice to use a tool with a rigorous configuration management process.

The configuration of all software components, objects, interfaces and services are registered. It

defines the physical and functional attributes of the application systems and related components

such as name, version number, system name, system functions, system owner and date of

production. The configuration management process or tool also tracks all the changes. Thus, it

is useful for audits and quality control.




5. Application Systems for Saudi Government

The previous chapter describes the application elements – i.e. application systems, application

components and application interfaces. Reference to these application elements enable

government agencies to develop quality reusable application systems and components.

Through reusable application systems and components, the total cost of IT investments and the

total cost of ownership are reduce. Yesser has embarked on the National Shared Applications

initiative that allows a number of government agencies to share application systems.

Government agencies must know what application systems to develop, replace or enhance to

meet their business requirements. In addition, government agencies must consider using the

National Shared Applications. This section provides a guide for choosing and prioritizing the

appropriate application systems by following these steps (see Figure 5-1):

1. Understand Business Requirements

2. Prioritize Business Requirements

3. Review Current Application Systems

4. Design High-Priority, Quick-to-Market Application Systems (A)

5. Design High-Priority, Long-Term Application Systems (B)

6. Reuse Application System for Low-Priority but Quick-to-Market (C).




Figure 5-1: Steps to identify & prioritize application systems

5.1. Understand Business Requirements By understanding the business requirements, appropriate new applications systems can be

design and develop, or older systems replace and enhance. There are three important sources

of information to help understand business requirements – the Business Reference Model

(BRM), the government strategic plans and royal decrees or instructions.

1. BRM

It is very important to understand the Line of Business (LoB), business functions and

their relationships. By referring to the BRM (and the government agency’s Business

Architecture if available), a government agency can understand its roles and

responsibilities as defined in the LoBs and the respective business functions within each

LoB.

For example, in Figure 5-2, the Ministry of Education (MOE) has responsibilities in two

LoBs – Education and Licensing & Regulatory Control (note: in reality, MOE has other

LoBs not listed here). Within each LoB, there are business functions and sub-business

functions that affect MOE. Further analysis will reveal that MOE is the primary agency




for the business function ‘Pre-School to High School Education’, while it is the secondary

agency for the other business functions.

From these relationships, the requirements for MOE would focus on its responsibilities

as a primary agency, i.e. ‘Pre-School to High School Education’. On the other hand,

MOE has to work with the primary agencies for the other business functions. In this

example, MOE has to support Ministry of Education - Higher Education (MOE-HE) in the

‘Graduate and Post-Graduate Education’ and with Ministry of Commerce and Industry

(MCI) in the ‘Licensing and Regulatory Control’ of Private Schools’.

Figure 5-2: Examples of MOE’s LoBs, business functions and sub-business functions

By understanding these relationships, the ARM can also educate business owners to

have a wider government-wide perspective. Hence, it would be easier to obtain detailed

business requirements from the business owners and to prioritize these business goals

or requirements.

2. Government Strategic Plans

A number of plans affects the strategies of government agencies such as the National

Strategic Plan, 2nd e-Government Action Plan and the annual government agency’s plan.

These plans have to reviewed and analyzed. By grouping the activities from these plans




into LoB and business functions, a government agency can clearly list its prioritized

business requirements.

3. Royal Decrees / Instructions

There are times when royal decrees or instructions are issue to all government agencies

or to specific government agencies. These royal decrees have clear instructions and

deadlines. Government agencies normally have to react to these royal decrees as top

priority.

5.2. Prioritize Business Requirements

List all these business requirements in terms of priority (low or high) and time needed (quick

e.g. less than 3 years, or long like more than 3 years for implementation). Figure 5-3 illustrates

a 2-by-2 matrix where all the business requirements are place into one of the four matrices.

Figure 5-3: Priority vs Time matrix

5.3. Review Current Application Systems

From the prioritized business requirements, review the currently available application systems.

Typically, there will be a need to develop new applications, enhance current applications,




replace current applications with new applications and remove current applications. Table 5-1

provides a summary review checklist of the current applications to meet business requirements.

Business Requirements

Application System

Is It Currently

Available?

Can It Meet

Requirements?

Action

Current Application to Support

Business Requirements

Y Y Use current

application

Y Most Amend current

application

Y Some Replace with new

application

N - Develop new

application

Table 5-1: Checklist review of current application systems

It is also timely to review applications that do not serve any of these business requirements.

Plan these applications for removal or retirement. For development / replacement with new

applications, please refer to the next two sections.

5.4. Design High-Priority, Quick-to-Market Application Systems

The characteristics of these applications (group A) are typically:

1. Support the secondary business functions or sub-business functions of a government

agency

2. Need to react to important operational issue or problem.

For these business requirements, consider the following design solutions:

1. Refer to the primary government agency responsible for the business function and

discuss for a joint solution (including funding and schedule)

2. Use National Shared Applications or Components where possible (refer to Figure 5-4)

3. If the above is unavailable, consider Customize-Off-The-Shelf (COTS) application

systems




4. Bespoken design (i.e. fully customize) as a last resort.

Figure 5-4: National shared application systems & components

Note:

Please refer to Appendix A for more details on national shared application systems.

5.5. Design High-Priority, Long-Term Application Systems The long-term application systems (group B) are typically:

1. A solution for multiple government agencies or one large primary government agency

with many users

2. The application system is complex

3. These are core application systems for the primary government agencies

4. Initiate and design by the primary government agency responsible for the business

function (e.g. HR System for the whole of government by Ministry of Civil Service,

Integrated Financial System for whole of government by Ministry of Finance, and

University Entrance Student Registration System for all universities and colleges by

Ministry of Education)




5. Part of a strategic plan.

Consider the following application design solutions:

1. Develop as a National Shared Application (see Figure 5-5 as examples) so that it can be

used by multiple government agencies

2. Inform and discuss with all the secondary government agencies involved in the business

function to get integrated requirements

3. Preferably do a business process re-engineering (BPR)

4. Recommend to design as an integrated, complete system (including helpdesk and

software licenses) but implement in phases.

Figure 5-5: National shared application systems (long-term) Note:

The above list is not exhaustive. Figure 5-5 currently lists the national application systems under

the Supporting Business Function category. Over time, there will be more national application

systems in particular those that support the primary LoB directly. Possible future national shared

application systems are the Electronic Medical Record System (Health) and the Business

Licensing System (Licensing and Regulatory Control).

5.6. Reuse Application Systems for Low-Priority but Quick-to-Market

Consider implementing the low priority application systems (group C) especially when

government agencies have spare resources. The characteristics of these applications are

typically:




1. Support the sub-business functions common in most government agencies; hence these

are supporting application systems

2. Helps in general productivity and solve operational inefficiency.

Consider the following design solutions:

1. Use National Shared Applications or Components where possible (refer to Figure 5-4)

2. Government agencies can also use their own reusable application systems and

components where available.




Appendix: National Shared Application Systems The following table summarizes the national shared application systems supported by Yesser.

ARM

category

Application

Name Description Features

Owner in

Yesser

Communica

tion &

Collaboratio

n

Saudi

Government

Portal

The Saudi eGovernment Portal is the central Saudi Arabian

government portal through which not only citizens, residents,

businesses and visitors but also other government

organizations and businesses can access eGovernment

services (eServices) online. This approach was chosen as the

best way to enable government services in an efficient

manner. It also makes eServices accessible anytime from

anywhere throughout the Internet. Broad eService

accessibility is achieved by providing eServices via the portal

either by integrating with other government agencies or

through links to their websites.

· Illustrating government

services and eServices

· Including a variety of e-

Participation tools

· Showing news and events

regarding e-Government in

Saudi Arabia

Products

Management

Division




ARM

category

Application


Owner in

Yesser

e-

Corresponden

ce System

E-correspondence application facilitates all of the manual

correspondence occurring between internal departments in

Yesser in addition to other government agencies. The

application helps in assigning a barcode to the manually

received document and its digital archiving. The application

also automates part of the relevant business process.

· e-Correspondence -

Follow-ups


Report


Archive


Search

Administrative

Services

Division

e-Gov. Mobile

Services

(Ma’ak)

It is a type of application software designed to run on mobile

devices such as a smartphone or tablet, and present the

government mobile applications in different views. The

application allows the government agencies to submit their

mobile application information to the products team. Upon

review and approval, the mobile applications will be displayed

and be made available in the Ma’ak store. Citizens can

download and use the various mobile applications.

· Manage Applications Infrastructure

Division




ARM

category

Application


Owner in

Yesser

SMS Gateway

System

SMS Gateway project is an e-Government National Project to

send and receive SMS messages. It allows all users

(agencies, citizens and other clients) of the GSB to use and/or

integrate SMS with their existing systems through a single

point of entry.

· SMS – Send / Receive Messages

· SMS - View Reports

Infrastructure

Division

Public

Information

&

Communica

tion

National

Contact Center

(Amr)

AMER is a National Contact supports all government

agencies through various channels. Designed in compliance

with the best technical and security specifications and it is

outsource to external vendor.

The center responds to inquiries raised by the public and

beneficiaries of e-Government services. It provides support

and information about e-government and e-services provided

by government agencies.

Using various communication channels (telephone, e-mail,

website, web chat, SMS, FAX, and social networks), the

center serves all e-Government service users. Prompt

advice, assistance and technical support are provided while

communicating with users through that various means.

· AMER CRM

· AMER Website

· AVAYA Telephony System


Routing

Shared

Products &

Services

Division




ARM

category

Application


Owner in

Yesser

Security Single Sign-On The Single Sign-On (SSO) validates user access to

applications and services on the Saudi eGovernment Portal.

The SSO is an electronic referential identity relating to

individuals or enterprises with a natural or virtual personality.

The SSO is use for validation to all e-services offered by

different government agencies.

Instead of signing-on to

multiple applications using

different user ids and

passwords, the main

feature of SSO is the

seamless integration of one

user id and password to

access various government

applications and e-services.

Registration for SSO is

done at the Ministry of

Interior website.

The G-Cloud

Division




ARM

category

Application


Owner in

Yesser

Public Key

Infrastructure

(PKI)

To ensure secure, efficient transmission and exchange of

information electronically, the Kingdom of Saudi Arabia has

created a National Public Key Infrastructure, named National

Center for Digital Certification (NCDC). NCDC was created by

an act of law and its mandate is stipulated in the Saudi

Electronic Transactions Act. NCDC provides trust services to

secure exchange of information between key stakeholders.

Within the Saudi government, secure exchange of information

and data is carried out through the Public Key Infrastructure

(PKI) service that was built over the NCDC infrastructure. The

PKI was built on the e-government infrastructure managed by

Yesser.

A PKI lets you:

Authenticate users more

securely than standard

usernames and

passwords

Encrypt sensitive

information

Electronically sign

documents more

efficiently

The G-Cloud

Division

Protocol

based

interface

Government

Service Bus

(GSB)

The Government Service Bus (GSB) comprises of

intermediary systems that contain integrated structure of

hardware and software designed to facilitate exchange of

shared government data among government agencies for

safe and timely online delivery of services.

· Service Authenticating

(LDAP)

· Service Authorization

(LDAP)

· Web services repository

(WRR)

Software

Engineering

Division

Table 0-1 National shared application systems

وثيقة النموذج المرجعي للتطبيقات الوطنية

Government & Nonprofit

Transcript of وثيقة النموذج المرجعي للتطبيقات الوطنية