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

e-Government Program (Yesser)
Version: 2.0
Date: 12/31/2015
National Application Reference Model
(Version 2.0)

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)
Page 2 / 88
Document Description
Document Title National Application Reference Model
Document version 2.0
Document Status Final
Author National Enterprise Architecture Office Management at
Yesser

Page 3 / 88
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

Page 4 / 88
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

Page 5 / 88
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.

Page 6 / 88
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

Page 7 / 88
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.

Page 8 / 88
1.9. Contact Information
For any feedback, comments or need for more information on the ARM, please email to
nea@yesser.gov.sa

Page 9 / 88
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.

Page 10 / 88
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:

Page 11 / 88
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.

Page 12 / 88
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.

Page 13 / 88
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

Page 14 / 88
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

Page 15 / 88
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

Page 16 / 88
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.

Page 17 / 88
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

Page 18 / 88
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.

Page 19 / 88
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.

Page 20 / 88
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.

Page 21 / 88
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.

Page 22 / 88
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.

Page 23 / 88
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.

Page 24 / 88
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.

Page 25 / 88
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.

Page 26 / 88
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.

Page 27 / 88
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.

Page 28 / 88
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.

Page 29 / 88
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.

Page 30 / 88
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.

Page 31 / 88

Page 32 / 88
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 framework3
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)

Page 33 / 88
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

Page 34 / 88
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

Page 35 / 88
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

Page 36 / 88
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.

Page 37 / 88
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.

Page 38 / 88
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.

Page 39 / 88
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.

Page 40 / 88
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

Page 41 / 88
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.

Page 42 / 88
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

Page 43 / 88
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)

Page 44 / 88
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

Page 45 / 88
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").

Page 46 / 88
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.

Page 47 / 88
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

Page 48 / 88
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.

Page 49 / 88
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.

Page 50 / 88
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.

Page 51 / 88
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.

Page 52 / 88
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

Page 53 / 88
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:

Page 54 / 88
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

Page 55 / 88
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

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

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

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

Semelhante a وثيقة النموذج المرجعي للتطبيقات الوطنية (20)

Mais de YesserProgram

Mais de YesserProgram (11)

Último

Último (20)

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