You are on page 1of 189

Ras Al-Khaimah

rakan eGovernment Strategy

Government of Ras-Al-Khaimah

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annexur Description Page

e No. No
1 AS-IS Report 3
2 Action Plan 41
3 Service Prioritization 54
4 Channel Strategy 72
5 Institutional Structure 83
6 Capacity Building 94
7 Marketing and Awareness Plan 104
8 Strategic Control 111
9 Standards and Policies 117

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annex 1- AS-IS Assessment

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S.No Description Page


1 Introduction 5

2 Approach and Methodology 6

3 Strategic Dimensions 7

4 Overview of the As-Is Assessment of 36


Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

1 Introduction

The Government of Ras Al Khaimah has identified eGovernment as one of the tools to enhance
the quality of service delivery to citizens, visitors, and businesses of RAK, while simultaneously
improving government efficiency and productivity. To take this further, the government of RAK had
formulated an eGovernment Master Plan and Strategy. The existing strategy seeks to attain the
following goals:

 Cost reduction through streamlined and combined processes;

 Assisting in improving Program performance in thrust areas such as law enforcement,
education, business, and economic development;
 Fostering economic development;
 Enhancing prosperity of citizens.

The areas of intervention that PricewaterhouseCoopers was to make as part of its assistance to
the Government of Ras Al-Khaimah for its eGovernment Programme . This report forms a part of
AS-IS assessment of the RAK eGovernment initiatives. As part of this assessment of the
various e-Government initiatives (including existing infrastructure, government processes,
government databases and their currency, and service delivery mechanisms) that have been
carried out and are in the process of being implemented. Develop and conduct a survey to
identify and analyze the key issues impacting eGovernment across 10 departments.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

2 Approach and Methodology

To assess the e-readiness of Ras-Al-Khaimah, the eGovernment agenda of RAK was examined
to understand the priority areas for the emirate to focus on. E-Readiness assessment of the
departments, and RAK overall, was undertaken to evaluate readiness and requirements in terms
of people, processes, and technology to effectively leverage Information Technology (IT) for
providing services.

Details of the activities undertaken to support the above approach are as given in table below:

Components of Approach Activities undertaken

E-Readiness assessment  Meeting with key functionaries of EGA to identify 10
departments for assessment
 Within the strategic areas, study conducted of 10
participating departments on their current IT capacity
o meetings
o Interviews
o AS-IS assessment questionnaire
o focus group discussions
 Assessment of the eGovernment requirements based on
the best practices.
 Benchmarking of the RAK eGovernment (submitted as
separate report)

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

3 Strategic Dimensions

The priority areas wherein the AS-IS assessment and related activities were conducted in are
depicted in the diagram below and are explained thereafter:

Figure 1: Strategic Dimensions


rvice Delivery Channels – Enhancement and implementation of four service delivery

channels that would not only make service delivery more efficient, but also make services
readily available for citizens, visitors, and businesses:
a. Portal
b. Common Service Centre
c. Mobile
d. Call Centre
2. Core Infrastructure: This Includes ICT infrastructure that acts as a foundation to
eGovernment initiatives as it would support the entire system. RAK’s strengths and
weaknesses in the following infrastructure components were examined:
a. Data Centre

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

c. Security Infrastructure
d. Payment Gateway
e. Disaster Recovery
f. Common Applications
g. Departmental IT Infrastructure
h. GIS
3. Key enablers - Implementation of six core components that would support effective
implementation of the above and ensure success of the eGovernment strategy, including
timely implementation. The assessment focused on rating Ras-Al-Khaimah’s eGovernment
enabling environment based on the following indicators:
a. Capacity building and change management - To ensure the availability of personnel
resources and skill sets by developing capacity and skills through training, career
planning and change management.
b. Common standards and policies – To strive towards an integrated and connected
government through the development of common standards and policies across all key
elements of the eGovernment Architecture.
c. Monitoring and evaluation - To allow the EGA, through the project office, to monitor
progress and more importantly results in customer satisfaction and government
d. Marketing and awareness - To ensure that there is enough awareness of the
programme, the benefits are to be communicated to the external and internal
stakeholders so as to generate enough demand for the electronic services and reduce
possible resistance to eGovernment.
e. Strategic control - Strategic Control is defined as the authority of the Government to
have complete control over the strategic assets, (software application, databases and
core infrastructure) and to achieve “real control”.
f. Institutional structure - For the effective implementation of eGovernment initiatives, a
supporting institutional framework is necessary with the responsibility for guiding and
monitoring the direction of the e-governance activities across the government.

e-Readiness Scoring

The structure of this report is based on the above strategic areas. These are presented and
discussed in terms of their scope in eGovernment; their current level of maturity within RAK,
along with their positioning relative to international good practices; and their corresponding e-
readiness/ maturity ratings (described below).

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Table 1: As-Is Assessment: e-readiness Scoring

Description Rating

E-Readiness for all the sub - parameters evaluated for the dimension are satisfactory
and little room exists for further improvement.

Significant progress has been made for some sub-parameters however gaps remain
in other important sub-parameters

Some steps taken in the right direction for a few of the sub-parameters, however
substantial gaps remain and there is a high scope for improvement. Low

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Strategic Area I—Service Delivery Channels

3.1 Service Delivery Channels

The delivery of services through electronic channels is a step towards providing choices and
convenience to customers for availing government services. However, provisioning services
through electronic means is only useful if it facilitates the target audience to access services more
easily through easily accessible channels

The choice of delivery channels impacts the following::

 Technology infrastructure required to support the channel (such as hardware, software

and networking)
 Business processes and procedures required to operate the channel
 Organization structure required to manage and deliver the electronic services (such as
skills, roles and alliances)
 Convenience and satisfaction for customers in availing public services

Based on the technological choices available today, readiness levels of various government
agencies, customer preferences and an overwhelming preference of key decision makers for
integrated service delivery, the following channels have emerged as the main service delivery
channels in addition to traditional government offices:

1. eGovernment Portal
2. Call Centre
3. Mobile Gateway enabling mGovernment
4. Common Service Centres (including self-service kiosks)

Currently, most Government services are delivered through the Departments while only a few of
the services have leveraged other delivery channels like the portal, or departmental
portals etc. The current state of affairs can be summarized as:

 The national/ departmental portals are the only alternate channels to departmental
counters for availing public services. However, the services on the portal are listed
without any alignment citizens’ needs which makes it difficult for the citizens to search
and avail services that they may specifically need.
 Process re-engineering has been attempted only on a limited scale due to which
government transformational projects are yet to be seen and this is reflected in the usage
of departmental counters as primary service delivery channels. Devising other modes of

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

service delivery requires much process re-engineering where the way in which the
government interacts with the citizens undergoes a fundamental change
 Government services through mobile and contact centre do not exist though plans are
afoot to set up a call centre soon.

The following table describes the current level of maturity of each of the above channels in RAK.
The sub-sections discuss each of these channels and their current level of maturity in greater

Table 2: Service Delivery Channel Assessment

3.1.1Call Centre

A call centre is a cost-effective and inclusive means to disseminate information to the citizens,
businesses, and visitors in an interactive way. Using call centres for service delivery reduces the
need for the citizens to visit the government office for information, hence reducing the load on the
main physical infrastructure of the government departments. The government can also use call
centres as an outbound channel to promote specific government schemes to target specific
segments such as citizens, businesses, and visitors.

Currently, EGA has entered into an agreement with a service to set-up a Call centre for the EGA.
This call centre is to cater to calls from citizens, business and government employees regarding
the eServices. In addition to the physical infrastructure however, it is imperative that
various support mechanisms are built-in to support it. This has however not happened in
RAK. The various deficiencies in the current implementation of call centres in Ras-Al-khaimah

 An incomplete process flow has been defined for the calls. The various scenarios
that queries branch out to have not yet been detailed out.
 Documents to support call centre staff have also not been detailed. A
comprehensive FAQ for the customer service agent to respond to customer queries has
not been developed.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Current system is not designed for rapid scale up, but the contract has provision for
expansion. The option of scalability to cater to high call rate during peak times is an
important one.
 A CRM system to record the type of calls and consequently classify them has been

3.1.2Common Service Centre

A Common Service Centre (including self-service kiosks) as a service delivery mechanism has
the potential to cater to various demographic groups. Manned Service Centres could provide
service users assistance in availing services that they may need. Self-service kiosks, or hardware
devices that allow users to perform transactions without any need of human assistance, also
provide users the ability to avail services at their own convenience and reduce the load on public

Currently the EGA has not set up any common service centre. However, in the economic
development department, there are counters for the Chamber of Commerce and Municipality for
providing the services of these departments related to Economic development.


Due to the high mobile penetration in the Emirate, service delivery through mobile devices would
be an effective alternative to traditional modes of service delivery through departmental counters.

Services such as utility payments, filing and submission of forms, and registering complaints etc.
could be done through mobile devices. It addition to cost-effectiveness, it would also enhance
efficiency of exchange of information/ services due to the low waiting time. Also service delivery
through mobile also provides convenience for the users, as services can be availed of even if
they are on the move.

Currently however, the emirate does not provide any services through a mobile gateway.

3.1.4E-Government Portal and department website

The Government portal can also act as a cost-effective and convenient means of interaction
between the government and the citizens/ businesses. Online services provide ease of
accessibility; they can be accessed anytime, from anywhere. The portal can also become an
integration point and a one stop shop for services that are provided by various departments.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Along with providing services, departments and other government agencies can also provide
information about themselves.

Currently, RAK has a government portal ( to act as a single point of interface on the
internet for citizens, businesses and government employees However, as part of the
eGovernment strategy, a total of 455 services were identified as core department services to be
provided electronically. Of those, only 32 services have been enabled for online delivery.
Additionally, of these services, only payment related services are provided end to end. All the
others are at a very nascent stage of online delivery and require manual intervention.

Majority of the departmental websites can be accessed through the RAK portal website.
As part o this assessment, departmental websites were also assessed based on three
parameters—user-friendliness; content; and delivery of e-services. Overall, the maturity
levels of websites in these areas are provided in table below, and a detailed assessment
follows thereafter.

User Friendliness Medium
Content Low
Delivery of e-Services Low


 Most departmental portals can be accessed from the portal. Departmental
websites however, are not consistent in their presentation. Consistent presentation
across websites makes navigability across websites much easier.
 There was also large variation across the websites in their English accessibility. This
could however be disproportionately true for websites in English, assuming that the
website developers were catering to the Arabic speaking community.

The other parameter that the websites can be assessed upon is navigability. Options such as
search bars, FAQ (Frequently Asked Questions), and site maps direct users to specific content on
the website.

 With the exception of Etisalat, no other websites provided the search functionality.
 Majority of the departments provided FAQ links, many of which however did not work.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Additionally, most did not provide users with trails to be able to follow his/her browsing
history on the website.
 With the exception of the Department of Land, Department of Economic Development,
Etisalat, and Saqr Port, none of the websites provided site maps.
 The third broad parameter, and arguably one of the most important one is the presence
of mechanisms through which users can give their feedback/ suggestions so that
websites can be improved basis user inputs. Most departments provided feedback
forms that were available for online submission.

Content: Providing departmental information, including their work and organizational structure is a
good practice, as it introduces the citizenry to the department, its undertakings and
accomplishments, and facilitates department-to-citizen accountability, wherein, along with the
structure, hierarchies, roles and responsibilities are also indicated.

 There was large variation in websites in terms of content. Some provided fairly
comprehensive content, and other provided very little. This is exacerbated by the fact that
there is no team for managing website content; hence there is not accountability for
maintaining and updating content on the websites.
 Majority of the websites had links to news related to the department but none of
the websites provided the date of the last update so that the user could trust the
information presented to him/her. The proxy that was used to assess the websites’
currency were the dates of news postings, some of these however were as old as one
year. Saqr Port Authority’s website was an exception, as it provided the users with
changes that have been made to the website. Also, the Etisalat website was up-to-date.
Additionally, the department of Economic Development, Finance, and municipality are
few of the departments that provide reports for download
 The majority of departmental websites provided links to information about their
department and their organizational structure, however, many of these did not work.
Some departments provided external links, to other departments; however, the
departments could consider providing links to external agencies, outside the government
to engage the users.

Services: All departments do not provide e-service. The following is an assessment for the

 Most of the e-services links did not work. The same is true of websites that had links
for downloadable forms. The customs and Ports authority had one service available
online-- application for new customs clearing representative card. The Saqr Port

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Department also had tender forms available for download. One of the most
comprehensive websites was that of Etisalat. It also provides options for online
transactions such as paying of bills.
 Most websites provided e-complaints services. However, many of the department (close
to 50%) have not solved a single case from complaints received on the gov
portal. This leaves the user with very little faith in portal to deliver timely and relevant

The indices used by the UN to measure e-readiness were used to rank departments in order of
their website maturity levels. The table provided consequently, lists them out:

 Emerging Presence is Stage I representing information, which is limited and basic.

 Enhanced presence is Stage II in which the government provides greater public policy
and governance sources of current and archived information, such as policies, laws and
regulation, reports, newsletters, and downloadable databases.

 Interactive presence is Stage III in which the online services of the government enter
the interactive mode with services to enhance convenience of the consumer such as
downloadable forms for tax payment, application for license renewal.

 Transactional presence is Stage IV that allows two-way interaction between the citizen
and his/her government. It includes options for paying taxes; applying for ID cards, birth
certificates/passports, license renewals and other similar C2G interactions by allowing
him/her to submit these online 24/7.

 Networked presence is Stage V which represents the most sophisticated level in the
online e-government initiatives. It can be characterized by an integration of G2G, G2C
and C2G (and reverse) interactions.

Table 3: Departmental Website Assessment

Department Website Maturity
Civil services None
Court Phase I
Customs and Ports Phase III
Economic Development Phase II
Finance Phase I
Land Phase I
Municipality Phase II
Public Works and Services Phase I
Saqr Port Phase III

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Department Website Maturity

Sewerage Authority NA
Town Planning and Survey English Version NA.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Strategic Area II—Core Infrastructure

3.2 Core Infrastructure

In order to be able to deliver services effectively through various channels in an integrated

manner, all the departments need to develop basic infrastructure such as applications, data
bases, and a communication medium. Hence, for integrated service delivery, it is envisaged that
instead of creating separate infrastructure for individual departments these infrastructure should
be shared by all departments to host their departmental application, access their databases from
a remote office in the country etc. Some of the following identified core infrastructure is already in

 Data Center (DC)

 Ras-Al-Khaimah Government Information Network (GIN)
 Security Infrastructure
 Payment Gateway
 Disaster Recovery
 Common Applications
 Departmental Applications

The following table summarizes the maturity levels of RAK in the above core infrastructure areas.
A detailed assessment of each of these is presented consequently.

Table 4: Core Infrastructure Assessment

RAK GIN Medium
Data Center Low
Security Infrastructure None
Disaster Recovery None
Payment Gateway High
GIS Medium
Common Applications Low
Departmental Applications Medium

3.2.1Common Data Centre

A Common Data Centre is a shared resource for the entire government to host the servers for all
the departments at a common facility. A data centre helps to provide a more reliable and secure
environment for the department servers. Additionally, the financial burden of implementing the
security and safety features (controlled access, fire safety, data back up) can be shared across

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

department. Processes such as disaster management and Business continuity can be deployed
and monitored more easily.

Currently, RAK does not possess a common data centre. Additionally, there are many security
issues that surround the current data storage mechanisms. Broadly, the following encapsulates
the current gaps in RAK’s data storage:

 As opposed to a common shared data centre where consolidated departmental

data would lie, currently, all the departments in RAK have a separate server rooms
located in the IT section of the department for hosting the servers.
 In addition to being a costlier option than a shared data centre, separate data
locations for departments also hinders sharing of information and knowledge
across departments.
 Additionally, a lot of issues surrounding the Data Centre stem from lack of institutional
structure around it. There is no management team existing for server rooms/ data
centre that could form and implement policies relating to data centre/ server rooms’
functioning. This has manifested in the following ways:
o There is lack of access control over the departmental server rooms. For
instance, in some locations, the access to the rooms is controlled by cards, and
the server rooms are monitored by CCTV, however the CCTV monitor is hosted
in the server room. This poses security threats to sensitive government data.

 There are no standard security measures for the back-up of the data. There
is no automatic back-up mechanism for the servers and only manual tape back-
up is taken by IT section staff. The EGA authorities also take remote back-up for
some of the departments.
 Additionally, there is no standard disaster recovery and business continuity
plan for the centres. Also, there is no fail safe power-back up mechanisms either.
This setup is insecure, as data can be lost and become irretrievable.
 Issues of scalability were also not taken into consideration in the design of
server rooms. There capacity of these servers is fairly limited and future needs
cannot be accommodated within the current infrastructure.

3.2.2RAK GIN

In addition to a consolidated data centre for all departments, the development of a Government-
wide network that would connect all governmental agencies in Ras-Al-Khaimah to this data
source is imperative. It would provide a common infrastructure by creating an Information and

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Communication backbone that caters to the needs of Government departments and agencies. A
Government wide network is also a secure and cost-effective option; the cost of investment for
separate networks for each of the departments will be high. Also, common network will enable
better utilization of network by sharing of excess capacity. Moreover, the Wide Area Network with
a capability to provide voice, data, video and Internet for improving the delivery of services to the
citizens would improve the response time and transparency in government functioning.

Currently, RAK has established a Government Information Network [GIN] connecting all the
government departments. The following diagram depicts the structure of the GIN:

Figure 2: RAK GIN

However, the GIN suffers from similar problems of the data-centre. It is limited in
scalability; it is highly susceptible to security failures; and lacks back-up facilities.

 The current RAK GIN network does not provide for scalability and it’s limited in its
capacity to provide services. It is based on the frame relay technology with a 2 Mbps

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

maximum bandwidth capacity. The Frame relay has scalability limitations compared to
the latest MPLS based meshed networks.While the link for LAND / Planning and survey
department has been upgraded to IP Connect of 10 Mbps, the other departments are still
on frame relay.
 Due to the congestion and low speeds of access that the GIN provides, most of the
departments have opted for different internet connections. This is however, an
insecure option. Any compromise/attack at those Internet gateways may be escalated to
the entire R-GIN network and will affect not only to the concerned department but the
entire R-GIN network and connected departments.
 In terms of security, the RAK GIN network has been secured by deploying firewall
systems across all departments having separate Internet connections. However,
Infrastructure without policies to support it is of very little use. Security policies and
audits for the GIN do not exist. Also, no monitoring tools to track network load,
utilization, traffic patterns, link failures, etc.have been deployed. This poses serious
security risks to the RAK GIN.
 No back up link for the RAK GIN exists; there is no failover / redundant path available
for the departments to connect to EGA in case of primary link failure.

3.2.3Common Applications

Common Applications are those applications, which can be used across departments to perform
common administrate duties. Even if there are minor deviations in procedures from agency to
agency, the assumption is that the deviations are minor and could be standardized across the
agencies. There are cost savings achieved through using common applications, as the cost of
development of applications across different departments is shared. This also leads to
standardization of processes and adoption of common standards and processes across different
departments. Common applications also facilitate easy and seamless information sharing
between departments.

In this regard, some of the initiatives taken by Government of RAK include:

 Human Resource application: This application has been developed for the Civil
services department, and maintains the records of all government employees in
various RAK departments. It is also used to prepare the payroll list for the payment of
salaries. The HR section in each department has access to this application. The

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

application however is limited because it is not directly liked to the payroll of finance

 Time and Attendance system: This infrastructure for recording the time and
attendance system has been deployed in all departments through a common system
and the department HR person has access to view the details of the employees. A
report is generated which is sent to the Civil services department.
 Enterprise Business Portal: This application is an office suite with facilities such as
Correspondence management, internal messaging, discussion board, calendar
management etc. However, due to shortcomings such as the lack of a user friendly
interface, lack of training on the application for new employees and an option
between using the EBP or the manual system it has not been adopted for use by any
of the departments.
 Archival system /Document management system: Most of the departments use
archival systems for scanning paper records to store them digitally. However, they all
use disparate, out-dated systems, and files are sent manually. Introduction of a single
document management system across all departments with encouragement to digital
communication is a great way to save paper and automate the entire government
 RAK portal services - eComplaint system: The system has been deployed. Some
of the departments use the system to respond to the complaints on the portal.
However, many of the departments have not resolved the complaints as per the
status on the portal

In summation, some of the limitations of the current system are:

 Current systems have been developed with limited operations and functionality, as
opposed to systems providing wider usage for a wider range of functions within
 The systems have been developed with the sole intention of automating
operational functionality, as opposed to being developed with an intention of improving
internal efficiency or cost savings (through consolidation of functions).
 Common Applications have only been developed for HR and recording time and
attendance system as opposed to being developed for other common processes.

The following table depicts the maturity of the various common applications that were assessed
as a part of this study.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Table 5: Common Applications Assessment

3.2.4Security Infrastructure

As discussed above, the lack of security policies put sensitive government information at high
risk. Moreover, with the implementation of eGovernment initiatives, the dependency on
information chain will be so high, that any breach of information confidentiality or integrity can
directly affect Ras-Al-Khaimah’s national interest. It is therefore important that the integrity of
sensitive government information and data is maintained in the exchange and access of
government data across agencies and departments. Protection of information is necessary to
establish and maintain trust between every government agency and its citizens, visitors, and
businesses. Data integrity is also important as timely and reliable information is necessary to
process transactions and support each department’s operations. To establish and maintain
effective information security it is essential that the Emirate possesses integrated processes,
people and technology in order to mitigate risk, in accordance with risk management policy, and
to ensure acceptable risk tolerance levels.

Current Assessment

Currently, the EGA has a security policy that provides for good practices to be followed for
securing the data information inside the departments, however there is no formal audits, reviews,
and monitoring of the implementation and reporting process for breaches. Most importantly, there
is no independent group that manages the security infrastructure. Therefore, there is no
accountability when it comes to managing infrastructure and hence updating it.


 There no documented security policy in any of the departments.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Though the EGA has established a firewall system to secure the servers in EGA and
internet connection in departments is filtered through a hardware firewall, due to lack of
monitoring mechanisms on security-adherence the system is susceptible to failure.
 No security audits of the network are conducted, thus failing to create pressure on
departments to adhere to regulations. Additionally, the lack of audits translates to no
feedback loop on security rules and issues of rule-adherence.
 None of the departments possess capabilities for PKI/ bio-metric authentications
that can be used by department applications requiring authentication, digital signature,
confidentiality, and access control for electronic transactions, thus making sensitive
government transactions insecure.


A geographic information system (GIS), also known as a geographical information system, is an

information system for capturing, storing, analyzing, managing and presenting data which is
spatially referenced (linked to location). GIS integrates spatial and other kinds of information
within a single system. It offers a consistent framework for analyzing geographical data by putting
maps and other kinds of spatial information into digital form. The effective use of spatially
referenced information is critical to the efficiency improvements towards which departments and
agencies are striving at:

• By embedding GIS in eGovernment workflows Government departments can ensure that

they are “location aware” in the provision of service
• GIS allows access to administrative records – property ownership, tax files, utility cables
and pipes – via their geographical positions.
• A comprehensive GIS system helps in better government decision-making
• Shortens disaster response time and improves decision-making
• Enhances customer service.
• Increases technology return on investment
• Improves data accuracy, accessibility, and integrity.
• Provides better resource and asset management

Currently, RAK Government intends to take up a project for an Enterprise GIS solution that would
not only encapsulate the existing image maps but also develop unique GIS applications for

• As a part of the GIS project , RAK government has established

• A GIS Infrastructure

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

• Digitization of existing maps and development of comprehensive Land

Information system
• Development of some applications for different departments for making effective
use of GIS. Currently RAK has identified five departments as part of the project
and envisages GIS to be used by other departments in future
• Data standards are being developed for the storage of spatial data
• The following applications are envisaged to be part of the GIS application
• General Map Handling
• Land Information System
• Sewerage Network Management
• No Objection Certificate
• Integrated Site Plan
• Project Tracking
• Integration of GIS with CCTV
• Administration
• Planning Conditions Application
• Addressing and Routing Application
• Inspection Of Restaurants
• Automation Of Survey Services
• Sign Boards Application
• Building Permit Application
• Vehicle Tracking System

However, even with a strong positioning of RAK on GIS infrastructure, very little work has been
done on creating applications that would make use of this data. Moreover, this need to be done in
the near future as GIS data is prone to becoming outdated and it would be easier to regularly
update the data rather than conduct a fresh survey after the current data becomes outdated. The
following table depicts RAKs maturity levels in the various components of GIS.

Table 6: GIS Assessment

Complete updated Map system High
Transform existing spatial data to single
Data standards for spatial data Medium
Departmental GIS Applications Low

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

3.2.6Payment Gateway

Many government services require payments, and when services are delivered over
unconventional channels such as portals, mobiles, etc., secure methods of financial transaction
need to exist. A payment gateway would provide facilities for citizens, visitors, and businesses to
make secure payments to the government using the electronic channels available. The facility
would leads to complete fulfilment for service, and would reduce transactional costs incurred by
payees in traditional modes of payments. With the payment gateway facility, users can make their
payment through credit cards etc. from any part of the globe. Especially, businesses, and visitors
to Ras-Al-Khaimah would benefit though this. Following is an indicative list of services where
payment gateway would play major role in providing convenience to users.

 Payment of utility bills

 Informational Services Related Payment
 Transactional Service Related Payment, etc.

With this facility, a lot of business to citizen services can be availed with ease. Those services
could be booking of travel tickets, booking of hotels, online payment of mobile bill, purchases etc.

Payment gateway has been made available on the eGovernment portal to facilitate payments for
services through the credit card and the e-dirham card. EGA has entered into an agreement with
Ethisalat for using the payment gateway. Government currently bears the fees for using the
payment gateway, but it is planned that at a later date the users will be willing to pay the charges
due to the convenience and security of payment through the portal. Currently, online payment
facility is available for some of the departments like Sewerage, traffic, Municipality (Public
Health), Ethisalat.

3.2.7Disaster Recovery

A policy for disaster recovery and business continuity planning helps to focus on the long-term
survivability of the e-Government initiative, and to reflect upon other options of risk management
which might be available to the government. Perhaps the most important need following a
disaster is staffing of personnel to implement the damage assessment, recovery, and restoration
phases of the plan. It is important that IT disaster recovery plans do not have a myopic focus
which can lead to overlooking other important strategies to protect the initiative. Business
continuity is a process to protect the people, the information, the physical facility, and their means

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

of doing business and not just a plan to manage hazardous materials spills or recover computer
networks following an emergency. The guideline framework should cover these areas:

 Planning for initiative interruption

 Identifying the risks the affect the initiative: not just focusing on the proverbial ‘big-one’
but trying to identify the smaller disruptions that can cause comparable damage.
 Accounting for both internal and external risks
 Detailed information about key internal processes and about services that are planned for
the future
 Details about the policy environment that includes all ICT elements
 People and training: which perhaps is the most important spoke in the wheel of business
continuity and also the single most important factor that can make or break a disaster
recovery plan

Current Assessment

There is no disaster recovery and business continuity plan is existence.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Strategic Area III—Key Enablers

3.3 Key Enablers

One the best practices observed as part of the review of international eGovernment strategies is
the need to have a programme view to eGovernment implementation. It has been observed that
traditionally, effectiveness of eGovernment projects/ programmes has suffered on account of:

 Limitations of funding or project management mechanisms

 Inconsistent approaches to objective setting
 Agency view leading to funding inefficiencies
 Expenditure orientation instead of service focus
 No uniform technical and process standards
 Complex projects with weak project management
 Low effectiveness despite good project design and implementation

1. Addressing these challenges requires a number of initiatives, which the eGovernment

strategy refers to as ‘key enablers’. The strategy identifies six such enablers necessary for
ensuring success of the eGovernment strategy. The following table summarises the current
as-is assessment:

Table 7: Soft Enablers Assessment

Standards & Policies Low
Capacity Building Low
Strategic Control None
Monitoring & Evaluation Low
Marketing & Awareness Low
Institutional Structure Medium

3.3.1Capacity Building

EGovernment projects are not equivalent to conventional IT projects. The focus of the
eGovernment strategy is on service, service levels and sustainability ‘projectization’ and not on
software and hardware. Capacity building seeks to address the skill gaps in the current
system and people. Capacity building in the context of this strategy, refers to the need to adjust
policies and regulations, to strengthen institutions, to modify working procedures and coordination
mechanisms, to increase the skills and qualifications of people, to change value systems and

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

attitudes in a way that meets the demands and prerequisites of implementing the eGovernment
strategy of Ras-Al-Khaimah.

Some of the capacity issues that exist within Ras-Al-Khaimah’s Governmental

departments relate to incomplete training on applications by the vendor, and as a
consequence, departments are highly dependent on vendors.

The following were some of the findings of the assessment:

• Lack of specialized training of staff in areas of eGovernment project

implementation: Most of the staff training has been on the basic computer skills.
Additionally, there are no targeted and structured courses to enhance the skill sets of
employees in the areas of e-Government.
• Inadequate/ poor vendor management: This has manifested itself in various ways:
• Incomplete training on departmental applications by the vendor: There are
various IT applications deployed in the departments, and the training on the
usage of these applications was done at the time of implementation. However, no
Manuals and training tools were observed in any of the departments on the
applications deployed. Therefore, even for existing infrastructure, there is a lack
of capacity within departments.
• High dependence on the AMC and external vendors for normal day to day
operations [Applications, IT infrastructure, User Management, etc]. This
dependence translates to inefficiencies created by waiting for vendor response
even for regular operations. It also indicates a lack of control over the vendors
wherein the vendors were unaccountable for imparting training related to the
applications that were deployed
• No service levels have been defined in the new systems/process implemented.
In effect, there are no performance pressures on the vendors to stick to any
• There is a lack of resources for specific areas of eGovernment projects within the
department. Current capacities are mismatched and stretched. Most of the departments
in RAK have an IT section consisting of a few IT personnel. However, in most of the
departments responsibilities for system administration/network maintenance/project
management/data back up/technical helpdesk are all handled by the same staff.
• Absence of institutionalization of eGovernment capacity building: No institutional
mechanism to provide the required training in eGovernment skills sets.
• There is no ownership of eGovernment projects within the departments to identify,
promote, and implement eGovernment initiatives. Currently EGA and its employees are

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

the primary champions for eGovernment. However steps need to be taken to ensure this
skill percolates to all the other departments as well.
• There is no knowledge sharing mechanism amongst various departments on the
common issues faced during eGovernment program implementation
• There is a lack of dedicated awareness campaigns within the staff and public about
eGovernment initiatives. Some disjointed programs have been undertaken to increase
citizen awareness about the portal. There have also been training programs
undertaken to teach the staff on the usage of software. However, in both the cases, no
consistent follow up actions have been training to ensure sustainability of the campaigns.

3.3.2Common Standards and Policies

This is an important set of components required not only to develop trust and confidence in new
systems but also in ensuring consistency and harnessing synergies accruing through various
projects. Formal policies on meta-data standards, data exchange, knowledge management,
reuse of information need to be developed at the national level while policies on IT Security,
Disaster Recovery, and BCP etc. should be formulated at the departmental level.

• Standards help in the developments of systems for data/information exchange across the
varied technology platforms in different departments.
• Act as guidance to the departments which have lagged to design better systems from the
first day
• Data loss is one of the primary concerns of eGovernment. Properly designed and
implemented systems will reduce the chances of loss of data
• Helps in increasing the awareness on the Information security, which can help in prevent
accidents in future

Currently, there is no defined technology /enterprise architecture framework for the RAK
eGovernment. Some broad issues that came-up during assessment were:

 Weak implementation of policies that have been formed so far: Even though an IT
security policy has been designed in EGA, the policy has not been fully implemented,
and there is no enforcement for the implementation of the same.
 Lack of awareness of policies with the departments: In none of the departments
visited, there was awareness for the requirement of a documented policy.
 Variation in standards across departments for initiatives: Some of the
standardization in hardware and software has been achieved due to centralized

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

procurement by EGA but for projects and initiatives, there are no standards and
 Absence of institutional mechanisms to develop and implement common
standards and policies: No agency has been formally designated the role of drafting/
dissemination of standards and policies.
 Lack of policy analyses that would accompany eGovernment implementation: In
terms of legal architecture that would facilitate the implementation of the strategy, even
though Ras-Al Khaimah has an established eGovernment vision, the policy changes that
the vision induces are not laid out or examined yet.

The following tables depict Ras-Al-Khaima’s status against some of the more specific areas of
policies and standards .

Table 8: Common Standards and Policies Assessment

S. No. Policy RAK Status

1 IT Security Designed but not
2 Meta data standards Do not exist
3 Privacy Do not exist
4 Disaster Recovery and Business Continuity Do not exist
5 Software Architecture Do not exist
6 Training Do not exist
7 Service Level Agreements / Citizen Do not exist
8 eServices SLA Do not exist
9 Software Development Lifecycle Do not exist
10 Middleware Do not exist
11 Hardware Do not exist
12 Change Management Do not exist
13 Marketing & Awareness Do not exist
14 PPP policy Do not exist

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

3.3.3Monitoring and Evaluation

A comprehensive monitoring and evaluation framework would help Ras-Al-Kahiamh improve

performance and achieve results for all strategy components and help in making informed
decision making. The objective of the M&E Framework is to enhance effectiveness of
eGovernment strategy by establishing clear links between past, present and future interventions
and results. Design imperatives for the framework include:

 Providing a common approach to track progress of all strategy components. The M&E
Framework is critical in enabling the monitoring of the progress of all the projects, which
are in different stages of implementation. It will help create an institutional mechanism for
organization, formulation, activation, monitoring, reporting, controlling and dissemination
of M&E results for all the projects
 Measuring customer centric outcomes would help in monitoring the outputs/outcomes of
the projects and measure impact on improvement in citizen satisfaction level quality of
services delivered.
 Learnings from the past would contribute to informed decision making. The M&E
Framework should help in identifying the delay/issues for timely resolution. It would also
help in identifying problems in the performance of projects and provide options for
corrective actions
 Facilitate in-depth monitoring and evaluation of projects that have high relevance for
citizens, residents and businesses.
 The M&E Framework would track changes from baseline conditions to desired outcomes
(achievement of the defined services level) and to validate what results were achieved,
and how and why they were or were not achieved

Currently, Ras-Al-Khaimah ranks low on the development and implementation of

monitoring and evaluation mechanisms for assessing eGovernment initiatives.

• Success criteria or performance parameters for projects have not been defined:
The service levels have not been defined for various services across government
departments and for the services provided through eGovernment channels.
• The government has started a program for Excellence in Governance, as Sheikh Saqr
program for Excellence in Government. As a part of this program, the departments are in
the process of defining their KPI and KPO.
• The current monitoring mechanisms at the departmental level are very limited: the
only monitoring done for the eGovernment is the dash-board which provides the following

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

• No. of e-complaints filed and resolved for each department

• Total payments made using the portal.
• Transaction being tracked for the departments

Furthermore, there is no evaluation of performance, as some department have not

resolved any of the complaints

• As part of evaluation report, a survey was conducted on the uptake of the eServices. The
survey results pointed to very poor uptake of the eServices.

3.3.4Marketing and Awareness

A national awareness, education and marketing campaign is essential to ensure that potential
customers know about the eGovernment services being rolled out, aspire to use them and are
able to conveniently use them. Raising awareness through informational and educational support
is an ongoing activity, but specially designed and timed campaigns will be needed, for example,
to coincide with the launch of specific services or to target a particular customer group. Such
campaigns must serve the overall goal of changing customer attitudes and, critically, their
behaviour in favour of using eGovernment services. A common central strategy is needed to
guide the government-wide branding and marketing initiative within which more focused and
short-lived campaigns can be accommodated.

• Targeted campaigns would serve the goal of changing citizen attitudes in favour of using
e-Government services.---channel migration strategy

• Builds credibility for the e-Government strategy

• Drive higher participation across the various target segments

• Drive confidence amongst businesses to attract investment

Currently, RAK’s maturity level for marketing and awareness is low. There have been some
initiatives undertaken by the government; however they seem to be sporadic in nature.
Concerted, comprehensive campaigns to increase awareness about eGovernment are
missing. More specifically:

 To encourage use of eservices, the government is subsidizing online payments by paying

the payment gateway and credit card charges for financial transactions on the portal.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Though there is no dedicated eGovernment awareness campaign, RAK intermittently

runs a service / project specific advertisement and awareness campaign using pamphlets
and advertisements on hoardings to inform the customers about new services.
 Additionally, there is no intervention in terms of improving the IT literacy and access to
computers and the internet on the emirate level.

3.3.5Strategic Control

Outsourcing of IT functions (Development of applications, maintenance of System ) is a common

trend even on government. However, maintaining a Strategic Control over the IT assets is a
major challenge in such outsourcing models. Strategic Control is defined as the authority of the
Government to have complete control over the strategic assets, (software application, databases
and core infrastructure) and to achieve “real control”. The same includes ensuring that:

i. the application system and the databases are designed, developed, installed, and
managed exactly in conformance with the procedures laid down for delivery of Services,
ii. the system does not perform functions and activities not provided for or contemplated by
the prescribed procedures
iii. the security of the database and application systems is of the highest order following
international standards
iv. no changes are made to the application system and the database without specific
approval of the Government and that the Government has the required access to ensure the
v. the IT vendor operator has no right over the system and also cannot access the system
beyond their prescribed authority
vi. the processes, including legal enablement and capacity within the government are in
place to take takeover the entire system in case of an exit of the service provier (premature or

Current Assessment

The following is the overall assessment of the department on the strategic control:

• Inadequate/ poor vendor management: This has manifested itself in various ways:
• Incomplete training on departmental applications by the vendor: There are various IT
applications deployed in the departments, and the training on the usage of these
applications was done at the time of implementation. However, no Manuals and training

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

tools were observed in any of the departments on the applications deployed. Therefore,
even for existing infrastructure, there is a lack of capacity within departments.
• High dependence on the AMC and external vendors for normal day to day operations
[Applications, IT infrastructure, User Management, etc]. This dependence translates to
inefficiencies created by waiting for vendor response even for regular operations. It also
indicates a lack of control over the vendors wherein the vendors were unaccountable for
imparting training related to the applications that were deployed

3.3.6Institutional structure

For the effective implementation of eGovernment initiatives, a supporting institutional framework

is necessary with the responsibility for guiding and monitoring the direction of the e-governance
activities across the government.

The government of RAK has realized the importance of the need for the centralized institution
mechanism for eGovernment. EGovernment Authority was established in 2004 in conformity with
a crown decree of His High Sheikh Saqr Bin Mohammed Al-Qasimi, Ruler of RAK Emirate. EGA
is the sole party responsible for eGovernment in RAK.

The identified role for the EGA is:

 Daily eGovernment operations

 Providing help and support for eGovernment users
 Providing guidance to other RAK government departments
 Overseeing and/or performing application development
 Setting and imposing technical policies and standards
 Supplying and maintaining the network security and eGovernment infrastructure
 Developing standard architecture guidelines for all departments

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

The approved organization structure for the EGA is depicted in the Figure below:

Figure 3: EGA Organization Structure

The established of the EGA (Electronic Government Authority), a centralized agency to co-
ordinate and implement eGovernment project has been a major step in the establishment of an
institutional structure. However, EGA currently does not fully have the required bandwidth and
skills to drive eGovernment projects. The current Organization of EGA does not have the BPR,
management experts for identification and management of overlaps in functions and core
infrastructure including service delivery mechanisms and integrated services. The following
describes the current scenario in RAK with respect to eGovernment institutional structure.

• All IT related products and services within the government are sourced through the EGA
leading to standardization and consistency in procurement of hardware and software.
However, this has also lead to the perception that EGA is only as a procurement
agency, rather than an eGovernment facilitating agency. Moreover, it is also limited in its
capacity to manage and implement eGovernment projects. It does not have systems and
processes in place for project appraisal, technology and vendor management.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

• No exercises have been undertaken to formulate an EA framework that would set up an

appropriate institutional structure; the solution architecture is largely vendor driven
pointing to the larger issues of vendor management.
• Resources within the EGA are scarce, their capacities are stretched, and there is a
mismatch between their skills and their responsibilities:
• Currently EGA has 22 employees. This also includes the support staff required
for the normal organization functioning and five employees which the department
has provided to the other government departments. Out of the total staff for EGA,
only 5 are directly involved in functions related to main EGA objectives

 The EGA staff is handling multiple responsibilities across unrelated functions

such as project management and procurement, data centre operations and
administrative issues, etc.
 There is no designated staff in the EGA for functions such as the eGovernment
Process improvement, providing training to the staff [Trainers] on IT skills.
 The department also lacks key technical resources like System administrator
required for the management of the common applications.

Organisation architecture here addresses only the IT organisation within the agencies. However,
key personnel responsible for service delivery and senior leadership are also required to form a
part of the overall eGovernment organisation.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Department Assessment

4 Overview of the As-Is Assessment of Departments

As part of the study detailed analysis to assess prioritised departments with respect to the
initiatives taken towards e-Government and ICT, Services delivery mechanism, ICT infrastructure
along with the human resource competency was taken up. Accordingly, a questionnaire was
designed to collect all the relevant information from these departments.

As a part of the information collection process, meetings were conducted with the department to
create basic awareness of e-Government, while giving the background of the project and
explanation of the questionnaires to be filled. Subsequently, multiple visits were made to each of
the respective departments for further clarification, assistance in filling up the questionnaire and
validation of the information captured in the process. Based on the information collected,
department-wise detailed assessment report including the questionnaire has been prepared. A
summary of the same is placed in this section.

All the above mentioned agencies were assessed based on the four dimensions to comprehend
the maturity level of the department. The details of these dimensions along with their assessment
criteria are explained below:

4.1 Services

In order to assess the present capability for delivering the services electronically, 3 parameters
were examined as illustrated in table below:

Table: Services Assessment Criteria

Parameter Assessment Criteria

• Formal citizen charter is available mentioning all the services available for
Citizen Charter
citizen / business with service levels
Service • The department has internal IT systems for automation of work for service
Automation / IT delivery
application • The IT application is ready for online service delivery
Interface with
other • Whether the department has IT system for transfer of data incase service
departments fulfilment requires information/interaction with other departments
Alternate • The department is providing some of the services through channels other
channel for than department channels
Service • Provision for department service online through RAK portal

Citizen Charter:

The department have no formal documentation of their service charter.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Service Automation/IT Service enablement

Most services provided by the Government to the residents or businesses alike are currently far
from being online. The 4 levels of e-readiness (of services) and their interpretation are as given

Levels of Service readiness for Online Delivery

Level 1 Service is ready for Online Provisioning

Level 2 Application needs to be developed / modified for Online Provisioning of

Level 3 Data associated with a Service is in manual form and needs to be digitized
before its Online Provisioning
Level 4 Process / Legal Change required for Online Provisioning

Interface with other department

Once all the services are automated, integration of all these services will be very critical for the
efficient operation of the department. Once integrated, the output of one process should be used
as the input to the next process, thus reducing lot of redundancy and drastically reducing the
operation time. As this is a mature stage of the e-Government implementation, to reach here a lot
of Business Process Re-engineering exercises needs to be carried out.

Based on the above sub-parameters the departments are rated which are given as follows :
Department Service CharterService Alternate Existing Overall
Availability Automation/ ITchannels forinterface withService
application service other deptt. Rating
Civil services Low Low Low Low Low
Court Low Medium Low Low Low
Customs and Ports Low High Low Low Low
Economic Development Low High Medium Low Low
Finance Low Low Low Low Low
Land Low Medium Low Medium Medium
Municipality Department Low Medium Low Low Low
Public Works and Low Low Low Low Low
Services department
Saqr Port Low Low Low Low Low
Sewerage Authority Low Medium Medium Low Low
Town Planning and Low Low Low Low Low

4.2 ICT Infrastructure and Policy

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

One of the major area for which information was collected from the departments is the current
ICT infrastructure they have. Overall assessment of the department was carried out based on the

parameter mentioned in the table below.

Parameter Assessment Criteria

• Availability of Servers / and adequate number of PCs for
Hardware staff with required peripherals.
• Other It support hardware like storage system ec.
• Availability of software packages for regular usage e.g. MS
• IT application for department functions and interface to other
• Availability of LAN
• Connectivity to RAK GIN
• A system for scanning the incoming/outgoing paper
documents for storage and easy retrieval
Standard & Policies • Availability of organizational level policies for e-Governance


It was found that most of the departments have stand alone PCs and server with basic
peripherals like UPS, Printer etc. The departments which have taken some of the eGov initiative
in recent past have hardware like servers, storage devices etc.


Most of the departments use common software like MS Office, and some deparment application
has been developed in some cases..As mentioned earlier, some of the departments have recently
taken steps towards e-Government initiative. These departments particularly have customised
software, server management software, data-base etc.


All the departments have been connected on the RAK GIN and have integerated LAN.

Standard and Policies

In none of the departments, there was any documented standard or policy on IT infrastructure
and security.

On the basis of the above mentioned four sub-parameters all the selected agencies are
rated as follows:

Department Hardware Software Connectivity Document Standard Overall

management/ and Policies Assessment

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Civil services Low Medium Medium Medium Low Medium

Court Medium Medium Medium Low Low Low
Customs and Ports High High Medium Medium Low Medium
Economic Development Medium Medium Medium Low Low Low
Finance Medium Low Medium Medium Low Low
Land Medium Medium Medium Low Low Medium
Municipality Department Medium Low Low Low Low Low
Public Works and Medium Medium Low Low Low Low
Services department
Saqr Port Medium Medium Medium Low Low Medium
Sewerage Authority Low Low Medium Low Low Low
Town Planning and Medium Low Medium Medium Low Medium

4.3 People Capabilities

The departments have been assessed on the following parameters

People Capabilities Assessment Criteria

Parameter Assessment Criteria

• Basic IT literacy of the functional staff
ICT literacy
• Advanced IT skills of the IT sections
• IT section managed by people formally trained in IT project
IT Project management skills
management skills
• Staff in the IT section with the formal trained capability in software
In-house IT Capability
development, network management, system administration, MIS

ICT Literacy

In general, ICT literacy is medium across all the departments / agencies. Wherever there is any
department specific ICT tool / software, in most of the cases, knowledge of these are confined to
system analyst / system department.

IT project management skill

The IT project management skills are at very low level in the department. There are no formal
project review mechanism and reports for the IT project implemented in the departments.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

In-house IT capability

The level of In-house IT capability for developing and maintaining their own IT
infrastructure is assessed to be very low in the departments.
Department ICT IT project In-house IT Overall
Literacy management skills capability Assessment
Civil services Low Low Low Low
Court Low Low Low Low
Customs and Ports Medium Low Medium Medium
Economic Development Medium Low Low Low
Finance Medium Low Low Low
Land Low Low Low Low
Municipality Department Low Low Low Low
Public Works and Services department Medium Low Medium Medium
Saqr Port Medium Low Low Low
Sewerage Authority None None None None
Town Planning and Survey Medium Low Low Medium

4.1 Summary of the Findings of Departmental Assessment:

On the basis of the evaluation done using the four dimensions and their parameters, all the
departments were then rated. The following is a summary of the department assessment:

 The IT applications in most of the department need to be upgraded to provide end to

automation of functions/services
 The departments do not have interface built for information exchange between departments
 The current systems in departments are not designed for online service delivery
 The departments are in urgent need of capacity building to improve IT skills and project
management skills
 There are no documented standards and policies followed across the departments leading to
person dependent processes
 The departments do not have the in-house capability on advanced IT skills and hence this is
leading to excessive dependence on the external vendors and loss of strategic control on the
IT assets of the department

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annex 2- Action Plan

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

eGovernment Portal: Action Plan

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Contact Center: Action Plan

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Mobile Phone: Action Plan

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Common Service Center: Way Forward

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Data Center: Action Plan

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

RAK GIN: Way Forward

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Institutional Structure: Way Forward

Capacity Building: Way Forward

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Marketing and Awareness: Way Forward

Standards and Policies: Way Forward

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Monitoring and Evaluation: Way Forward

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annex 3- Service Prioritization

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. No Description Page

1 Prioritization of services 56

2 Services to be delivered in Year 1 56

3 Services to be delivered in Year 2 63

4 Services to be delivered in Year 3 68

Prioritization of services
During the as-is assessment exercise, undertaken for 14 government agencies, a set of more tan
172 services were identified. An assessment was done for the eGovernment feasibility for this set
of services, and from this, a set of 139 services (88 transactional and 51 informational) services
have been identified for eGovernment enablement after discussion with various agencies.

The services have been classified as follows:

i) Informational Services; includes those services that solely provide information to customers
and does not involve processing of any transactions or documents. For example, information

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

about the processes in the department. Informational services have relatively simple back-
office operations and can be easily be E-Government-enabled.

ii) Transactional Services; includes those services where customers require specific actions to
be taken by the department. For example, issue of a business license. Transactional
services mandate a higher degree of customer interaction and more complex delivery
operations than informational services.

PwC has used a structured approach to arrive at prioritization for the e-Governance enablement
of these services. The services provided by the participating departments were assessed on the
criteria of the Benefits and visibility impact. Based on this analysis, it is recommended that RAK
government undertake the e-Governance enablement of the services in a
phased approach as summarized below.
Year Number of Services
Informational Transactional

1 28 25
2 18 29
3 5 34
51 88
The detail of the services to be provided in each year has been provided in the table below.

Table 1: Services to be delivered in Year 1

S. Service Department Delivery Channel

Informational Services
1. Information on departmental services and All department Portal
Contact Center
4. Information on employment opportunities in RAK Civil Services Portal
government departments CSC
Contact Center
7. Application Download for applying for available Civil Services Portal
employment opportunities
8. Information on rules, eligibility criteria and Civil Services Portal
processes for applying for different positions
Contact Center
11. Information on rules and regulations, eligibility Economic Portal
norms, fees and other obligations to avail different Development
Contact Center
services of Economic Department
14. Information on retirement benefits Finance Portal
16. Finance Portal

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. Service Department Delivery Channel

Providing budgetary reports for all government CSC
18. Submission of reports to the Crown Prince of RAK Finance Portal
as required
20. Information service on property registration Land Portal
process, rules, fees and other regulations
Contact Center
23. Application and Forms download for applying for Land Portal
property registration
25. Encumbrance certificate Land Portal
27. Customer service Land Portal
Contact Center
31. Information on the functioning of various different Courts Portal
courts, their duties and obligations
Contact Center
34. Information on the functioning of Port, its processes Saqr Port Portal
and business enablement services
Contact Center
37. Information on fee details for services provided by Saqr Port Portal
Saqr Port
Contact Center
41. Application form for health card Saqr Port Portal
Contact Center
44. Information service on Building Permit, Municipalities Portal
Advertisement Permit, Health Cards and
Certificates, renewal of shop agreements, etc. Contact Center
48. Fee information, rules and regulations for obtaining Municipalities Portal
Building Permits, Advertisement Permit, Pest CSC
Control Certificate, Health Certificate, etc.
Contact Center

52. Information service on Town Planning departmental Town Planning Portal

rules, fees and other regulations
Contact Center
55. Forms download for Town Planning departmental Town Planning Portal
57. Application download for Issue of Export Certificate, Chamber of Portal
organizing exhibitions and fairs, attesting Commerce
agreements, etc
59. Portal

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. Service Department Delivery Channel

Information service on the functioning of Chamber Chamber of CSC
of Commerce, its processes, rules, fees and other Commerce
61. Naming of experts for inspection, evaluation, Chamber of Portal
pricing, listing, weighing and commodities. Commerce
Contact Center
64. Rules and regulations for obtaining NOC on Public works and Portal
building permit, Domestic Waste Violation, etc services
Contact Center
68. Enquiry on Approved Bills Customs and Ports Portal
Contact Center
72. Forms download for application for issue of Customs and Ports Portal
Customs Clearance and Transport Equipment
74. Real Estate Search Service Existing eServices Portal
Contact Center
78. Etisalat Bill Query Service Existing eServices Portal
Contact Center
Transactional Services
1. Commercial name reservation (Initial approval for Economic Portal
the formation of Company) Development
Contact Center
4. Letters to citizens of RAK Economic Portal
5. Letters to commercial establishment Economic Portal
Contact Center
8. Permission for Sale/Advertisement Economic Portal
10. Payment of fines related to commercial activities Economic Portal
Contact Center
14. provide Documents for property Land Portal
Contact Center
18. Registration of the Cases Courts Portal
20. Building Permit Municipalities Portal

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. Service Department Delivery Channel

22. Advertisement permit For the advertisement site Municipalities Portal
and hoarding
24. Renewing of the shop agreement Municipalities Portal
26. Health certificate for laborers Municipalities Portal
28. Comparing plan Town Planning Portal
29. Request from services - To take new electrical Town Planning Portal
connection / telephone / other services
Contact Center
32. Issuing new Kroaky - allotment of plot Town Planning Portal
34. Renewing Kroaky Town Planning Portal
36. Duplicate site plan Town Planning CSC
37. Duplicate Kroaky plan Town Planning CSC
38. Kroaky plan by HH program Town Planning Portal
Contact Center
41. Processing of applications for organizing Chamber of Portal
exhibitions, fairs, conference, seminars and all Commerce
activities pertinent to economic issues and issuing CSC

of approvals
43. Providing NOC on the building permits application Public works and Portal
45. Issuing importer codes Customs and Ports Portal
Contact Center
48. Payment of Sewerage bills Sewerage Portal
Contact Center
52. Reservation and borrowing of books Documentaries Portal
and Studies Center
53. Real Estate Registration Service Existing eServices Portal
55. Etisalat Bill Payment Existing eServices Portal
Contact Center

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Table 2: Services to be delivered in Year 2

S. No. Service Department Delivery Channel

Informational Services
1. Application Download for Licenses, Economic Portal
establishing commercial establishments, Development
permission for sale / advertisement, etc
2. Publishing of Statistical year book Economic Portal
4. Information to citizens of welfare expenditure Finance Portal
7. Information to individual employees on their Finance Portal
salaries, benefits and other perks as per their
9. Application for employee loans and salary Finance Portal
11. Provide statistical information Finance Portal
Contact Center
14. Information on case pronouncements Courts Portal
16. Complaints tracking and status Courts Portal
Contact Center
20. Forms download for entry passes, Saqr Port Portal
registration of Marine Agents, Birthing,
loading and unloading of goods
22. Notification Tanker Arrival Saqr Port Portal
25. Forms download for applying for Health Municipalities Portal
Cards and Certificates
27. Forms download for licenses for foodstuff, Municipalities Portal
leasing industrial land, Renewal of leasing
agreement with companies, etc
29. Location showing to allot a new Kroaky or Town Planning Portal
Site plan
32. Stating of conditions and specification for Chamber of Portal
defining the professional title of Commerce CSC
businessperson and the preconditions for
Contact Center
conferment on eligible persons

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. No. Service Department Delivery Channel

36. Application download for NOC on building Public works and Portal
permits services
38. Bill Advance Enquiry Customs and Portal
Contact Center
42. Examination recourses ( previous years Existing Portal
papers eServices
44. Questions and Answers Service for students Existing Portal
Contact Center
Transactional Services
1. Receive employment applications for Civil Services Portal
3. Issuance of Business License Economic Portal
5. Citizen's Complaints about price higher than Economic Portal
displayed prices Development
7. Customer Complaints on Business Economic Portal
Establishments Development
9. Payment of salaries and grants Finance Portal
10. Property Registration Land CSC
11. Authentication of the documents Courts CSC
12. Registration of Appeal cases Courts Portal
14. Provide family counseling Courts Contact Center
15. Issue of Marriage and Divorce Certificate Courts CSC
16. Registration of complaints Courts Portal
Contact Center
19. Issue of Port Entry pass Saqr Port Portal
21. Dispatch of monthly invoice to Marine agents Saqr Port Portal
(the invoice can be raised electronically)
22. Registration of Marine agents Saqr Port CSC
23. Tanker Registration Saqr Port Portal
24. Collection of the monthly invoice charges Saqr Port Portal
from the marine agents
Contact Center
28. Collection of fines for construction activities Municipalities Portal
Contact Center
32. Practitioners Registration and renewal Municipalities Portal

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. No. Service Department Delivery Channel

34. Export Food Health Certificate Municipalities Portal
36. Pests control certificate Municipalities Portal
38. Fines against institutions for not following Municipalities Portal
Public health standards following inspections
Contact Center
42. Updating the site plan Town Planning Portal
44. Allotment of plots with respect to area Town Planning CSC
45. Changing Kroaky to site plan Town Planning Portal
47. Issuing of certificates of origin for export and Chamber of Portal
re-export purposes, Commerce
49. Provide No objection certificate to other Public works and Portal
service provider clearing the area (road services
51. Collection of fine from Domestic waste Public works and Portal
violators services
53. Issuing certificate of no objection for activities Customs and Portal
that require the approval from customs Ports
55. Issue of Books from Library Documentaries Portal
and Studies CSC


Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Table 3: Services to be delivered in Year 3

S. No. Service Department Delivery

Informational Services
1. Information on case proceedings and dates Courts Portal
Contact Center
5. Appeals for delayed justice Courts Portal
7. Provide the Cause list of cases to be heard Courts Portal
Contact Center
11. Building regulation Town Planning Portal
Contact Center
15. Gathering and compiling of information, data and Chamber of Portal
statistics concerning issues such as price of Commerce CSC
commodities, services bonds, securities, Mobile
currencies, etc… and processing, evaluations, Contact Center
assessing and preparing of pilot and periodical
Transactional Services
1. Receive complaints from the community Civil Services Portal
members on various issues of civil service CSC
Contact Center
4. Renewal of commercial name Economic Portal
Development CSC
6. Renewal of business License Economic Portal
Development CSC
8. Payments for government entities Finance Portal
9. Registration of Old land without documents Land CSC
10. Mortgage Land CSC
11. Provide copies of the court documents Courts CSC
(Replacing official documents for Court
12. Issue of Port entry passes through Marine Saqr Port Portal
agents CSC
Contact Center
16. Providing the birthing service to the ships Saqr Port Portal
-Request for loading service

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. No. Service Department Delivery

-Request for unloading service
17. Provide the loading service to ships Saqr Port Portal
18. Provide the unloading of goods service on ships Saqr Port Portal
Contact Center
20. Provide the health cards for the employees Saqr Port CSC
through municipality
21. Provide anchorage services to the ships Saqr Port Portal
Contact Center
23. health cards for food handler Municipalities Portal
25. foodstuff establishment licensing Municipalities Portal
27. Spray of insecticide at individual homes on Municipalities Portal
request CSC
Contact Center
30. Collection of Rents for the markets Municipalities Portal
Contact Center
34. Leasing of industrial land Municipalities CSC
35. Renewal of leasing agreement with companies Municipalities Portal
37. Plot demarcation Town Planning Portal
39. Extension of land Town Planning Portal
41. Replacement - Changing plot from one place to Town Planning Portal
another CSC
43. Merging of plots to one Town Planning Portal
45. Exchange between plots - kroakey Town Planning Portal
47. Compensation for property Town Planning Portal
49. Splitting of plot Town Planning Portal
51. New site plan with old ownership Town Planning Portal
53. Registering of all natural and juristic persons Chamber of Portal
licensed to practice activities stated in Article No Commerce CSC

(7) of the chamber organization certificates.

55. Authenticating, attesting and certificating of Chamber of CSC
documents, agreements and signatures of Commerce
member companies and establishments

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. No. Service Department Delivery

56. Rendering of consultation services and advice or Chamber of Contact Center
all issues relative to legal, commercial, technical, Commerce
economic concerns, to help members,
businesspersons and investors foster and
promote their activities
57. Customs Warehouse Bill of Entry Clearance Customs and Portal
(Customs Clearance) Ports CSC
59. Issuing representative cards for customs Customs and Portal
clearance Ports CSC
61. Issuing cards for transport equipment and Customs and Portal
machinery Ports CSC
63. Sale of Books and CDs Documentaries Portal
and Studies

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annex 4- Channel Strategy

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. No Description Page

1 Introduction 74

2 Objectives of a channel strategy 75

3 Multi-channel service delivery 76

4 Channel Selection Framework 78

5 Implementation guidelines 81

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

eGovernment Channel Strategy

1. Introduction

A ‘Channel’ in service delivery context can be defined as ‘a means for organizations to deliver
services to customers.’ Traditionally, Government Offices have acted as the main channels of
service delivery. However, during the last decade, customers have become accustomed to new
means of service delivery in the private sector. Nowadays, customers expect the same level of
variety from the public sector: they want their interactions to be convenient, and they prefer to be
online rather than in line. To meet this expectation, Governments needs to deploy a variety of
channels for service delivery – channels that allow customers to avail services anytime,

In the modern day context of citizen centric approach to Governance, new developments in ICT
allow the government to meet these challenges by adapting new ways of interaction through a
variety of channels, restructured services that accommodate customers’ needs, and re-organized
business processes within and across administrative bodies. Governments around the world are
using a multitude of channels, such as service centers, call centers, internet and mobile, to
deliver a wide range of services to a diverse range of customers. Government agencies continue
to add new channels – such as short messaging service (SMS), interactive voice response (IVR)
and speech recognition options – to their channel portfolios in order to provide customers with a
wider variety of ways to engage with government.

A channel strategy can assist agencies to manage multiple-channel delivery. A channel strategy is
a set of business driven choices about how, and through what means, services will be delivered
to customers. A channel strategy can illustrate the best methods to engage customers, types of
engagements best supported by each channel, and ways in which channels interact with each
other. A channel strategy should focus on ensuring the following:

 Information and experience consistency – although customers may want to continue

to use a variety of channels, they expect consistency in their interactions with the
government, no matter what channel they use

 Cross-channel insight – customers expect each channel to be attuned to recent

interactions and transactions that they have had through alternate channels

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

2. Objectives of a channel strategy

A major challenge faced by the government today is that customers expect faster public service
delivery, companies want administrative burdens to be reduced, and public bodies need to raise
productivity in order to deliver better and faster services.

These challenges mean that government department needs to:

 Improve the manner in which they serve their customers: User-centric services that are
easily accessible for all segments of the community and offer flexibility in terms of how,
when, and where they are accessed. Moreover, they are transparent, efficient and

 Reduce the costs of providing services. The government needs to make their service
processes and their delivery more efficient as they have limited resources. This may
involve a re-organization of their business processes and the structure of their back and
front offices.

A number of competing Government priorities and customer needs influence the channel
decision-making process as shown in Figure 1 below. Consequently, the effects of pursuing one
particular target over another should be assessed. This strategic view of organizational activity is
essential, if the channel strategy is not to be developed in isolation.

Customer requirements

A user’s perception of a service is related to all aspects of the service, i.e. the service (product)
itself, the contacts with the service provider, and service delivery. The general customer
requirements can be broadly classified as follows:

 Flexibility: customers should be able to access services anyhow, anytime, anywhere.

 Accessibility: customers who are entitled to a service cannot be refused; customers

should be aware of services that are of interest to them; services should be findable,
usable and affordable.

 Quality: Services should be based on product specifications; they should be timely and
user-centric, and they should provide value for money.

 Security Services and service delivery should be trustworthy and confidential both
objectively and in the user’s perception.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Government department requirements

Government is committed to bringing services closer to where customers live and work, and in
the public places they use. However, because financial, organizational and technical resources
are not unlimited, it is not possible to deliver services that are tailored to each individual user.
User requirements must, therefore, be in balance with requirements related to the provision of
services. The general government department requirements can be broadly classified as:

 Efficiency: Re-use must lead to cost benefits, and cost-efficiency should not be
detrimental to effectiveness.

 Effectiveness: Channels must connect services with their target groups, target groups
must be able to access the services, and (e-) inclusion must be raised.

 Security The service delivery process should not threaten privacy, security, or
confidentiality of data subjects or contributors.

3. Multi-channel service delivery

A multi-channel approach enables customers to access a service, irrespective of the channel they
prefer to use. Front office applications are integrated and support the service provision with
centrally stored and accessible data. This ensures that available data are identical in all channels
and processes, thus eliminating the need for complex protocols to keep these data attuned.

The multi-channel approach requires that the different channels should be integrated and
coordinated. To enable this, the common data that are used by the front office applications should
be stored centrally so that they can be shared by the applications. Storing data centrally means
that they need to be collected only once and that they can be accessed by back office
applications. The multi-channel architecture suggested for the RAK government is shown below:

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

When data is stored centrally, customers can also access the services they want from the
location(s) they want, as all “contact points” retrieve the relevant data from the same database.
Moreover, electronic and mobile service delivery channels enable administrations to offer fully
automated services that can be provided on a 24*7 basis.

Channels to access public services

Customers and administrations need channels to interact with one another. A general definition of
the term channel reads:

A channel is a means for customers to contact public administrations (inbound) or for public
administrations to contact their customers (outbound) with the aim of acquiring or delivering
public services.

Based on the technological choices available today, readiness levels of various government
agencies, customer preferences and an overwhelming preference of key decision makers for
integrated service delivery, following channels have emerged as the main service delivery
channels in addition to traditional government offices:

1. eGovernment Portal: where customers can use desktop computers to connect to

government’s web site to request services, search for information, make payments, etc

2. Phone (Call Center-); where customers can call RAK’s hot-lines to request services. ‘Phone’
is considered as an electronic delivery channel due to the potential use of ‘Call Center’ and
‘Interactive Voice Response’ technologies.

3. Mobile Gateway; where customers can request services and information through mobile
phones and hand-held digital personal assistants. The department can send to customers
regular alerts on SMS.

4. Common Service Centers: where services like Information dissemination, acceptance of

service requests and delivery of services through the shared citizen service centers is
provided for the customers to get a single point of service delivery. This involves integration of
the backend applications of departments with Common Service centers. The Common
Service center have been taken as an electronic channel of delivery as it will be providing the
services to the various government department through a single interface using the electronic
The table presents the various features of the channels available:

eGovernment portal  can contain very large volumes of information

 suitable for services that are not too complex
 available on a 24*7 basis
 devices needed to access the channel
 parallel or add-on channels such as a call centre can make websites

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

appear more direct: a call centre agent guides the user through his
web session
 accessing device (PC, mobile phone) determines viewing and thus
 phishing12 may discredit the channel
Common service  provides direct and personal contact
Center  suitable for complex services that cannot be provided over self-
service channels
 Requirement of a physical infrastructure
 physical distance and limited opening hours may be a barrier
Call Center  Can handle voice contacts (e.g., telephone), internet contacts (e.g.,
chat, e-mail), written contacts (e.g., faxes, regular mail)
 Can deliver services ranging from simple general information
requests (e.g., self-service through Interactive Voice Response
systems (IVR) to complex transaction services (e.g., in direct contact
with a human agent)
 The use of Computer Telephony Integration (CTI) enables it to be a
 Cheaper to operate than traditional channels
 Can be used as an add-on channel for other channels
 Can be used with Interactive Voice Recognition system (IVRS) for
 Very high penetration levels
Mobile Gateway  enable customers to access services irrespective of location
 offer functions such as SMS, e-mail, access to the internet
(depending on the model), in addition to telephony
 raise inclusion in areas with poorly established fixed telephone line
system by offering telephone, SMS and internet (m-services)
 size of screen is a limiting factor to providing services
 functionality of different devices is converging (e.g., PDAs and
mobile phones)

4. Channel Selection Framework

Services can be delivered through a wide variety of channels. Certain channels are more suitable
than others for meeting particular user requirements. Moreover, factors such as cost and
management make it impractical for an organization to implement all channels. In addition, too
much choice is not always appreciated by the user. A realistic set of channels must, therefore, be

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

selected from the available range of potential channels. The following methodology was used for
the selection of channels for the eGovernment services:

1. Rate the features of the available channels.

Channel features can be classified as follows:

Directness: This feature determines whether the interaction between the user and the
administration can take place synchronously (direct interaction as occurs in face-to-face or
telephone contacts) or asynchronously (indirect interaction as occurs in an exchange of
letters, e-mail, SMS or through an intermediary). A direct channel is required or preferred if a
user has strong feelings about an interaction. In less urgent situations more indirect channels
may be considered. Complex services are more likely to be requested over direct channels

Accessibility & Inclusion: This feature determines:

 whether the entire user population or only specific segments of the population have
access to the channel, and

 whether the channel can play a role in bridging societal divides and hence increase
participation and inclusion.

Accessibility may be measured in terms of physical as well as in psychological distance.

When new channels are added to an existing set of channels, the “social” or “technical”
exclusion of certain user segments can be rectified. For example, the places which are
far-off from the main centers or have low internet connectivity can easily use the call
center and the mobile phone.

Speed This feature determines the time that is required for delivering a service. A user who
needs to act or respond fast will use a channel that instantaneously fulfils his need.
Administrations must sometimes provide time-critical information, such as emergency
information, (near) real-time.

Security & Privacy: This feature determines whether the user and the service provider
accept a particular channel for specific interactions. Interactions that involve sensitive
information or the transfer of money obviously require more stringent security measures than
general information services.

Availability: This feature refers to the “opening hours” of a channel. If the channel involves
direct contact (e.g., face-to-face or by telephone), the opening hours are usually the same as
regular office hours. Channels that do not involve direct contact may have round-the-clock
availability, e.g. websites or Interactive Voice Response systems.

2. Rate the service provision requirements for each service type.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Whereas the general customer requirements focus on the entire service, the manner in which
a service is provided or received, must be seen from the perspective of the user for each
service Naturally, considerations involved in selecting the right channel should be seen in the
context of the general user requirements. However, to be able to match the user
requirements with the channel features, the various requirements for providing the service are
classified in the same way as the channel features.

Directness: This requirement determines whether the user wants an immediate response to
his/her service request or not.

Accessibility & Inclusion: This requirement determines whether the user must have access
to the service over at least one channel.

Speed: This requirement refers to the speed of the service delivery that the user wants in a
particular situation.

Security & Privacy: This requirement determines whether the requested service involves
sensitive information that should not become known to others.

3. Match the channel features and the service provision requirements.

4. Determine whether the remaining channels are technically and organizationally appropriate to
deliver the services.

5. Determine which channels would realize the best public value, based on (expected) costs
and benefits.

Based on the above selection criteria for the RAK government, 139 selected services
were classified for various channels. The following table provides a summary of the
services and channels.

No. of Services
Informational Transactional
eGovernment Portal 51 59
Common Service Center 49 67
Call Center 27 15
Mobile 16 9

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

5. Implementation guidelines

The introduction and implementation of new channels means that customers have more choice in
ways to interact with the Government. On one hand, this makes life easier, because now there
are more ways to contact the administration: over more channels, from more places and at more
times. Customers must be able to identify the channels that are open to them, and be able to
assess their value. And for all available channels the relevant information (such as contact points,
opening hours, ways to identify) must be accessible. Channels should give customers more
choice, but it should be realized that in some cases customers might be better off with limited
rather than unlimited choices.

The main feature of complex, multi-channel service delivery processes is that they involve
multiple sessions and that next steps can be taken up by any available channel that has access
to the central data repository. When the interaction in the service delivery process is resumed, the
status, progress and content data is retrieved into the front office application.

Because success in service delivery depends on a vast range of parameters that cover the
service itself, the means employed to deliver the service, the requirements of the user community
and the objectives of the department providing the service, the first phase of a multi-channel
strategy consists of investigating these parameters.

The following consideration must be kept in mind while design of the service delivery using
various channels:

1. Draw up detailed specifications and possibly develop a prototype. In defining the

specifications take into account the possibilities of generic service steps and possible re-
use of application components. Use the specifications and the prototype in tender
specifications and / or briefing and negotiation with contractors.

2. Obtain the required solution by publishing and awarding a tender or otherwise. Include
extensive testing (from the user’s perspective) and a pilot phase in the solution
development cycle.

3. Carry out awareness creation and promotion to announce the new channel’s launch,
pointing out benefits to customers, etc. Pay attention to web presence (create access
from a portal, and include banners and links from other sites). Pay attention to access
from search engines. If particular usage patterns need to be changed, do so by means of
pricing policies and special promotion activities.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

The following must be the outcome of this phase:

 The key customers have been informed of the new channels of service and the associated

 The service delivery channel is up and running and providing the services in the promised

Once the implementation phase has been completed, solutions are likely to require fine-tuning or
more far-reaching changes. This is why the post-implementation phase must include usage
monitoring and customer satisfaction assessment. The information obtained in this manner must
be used as input for decisions with respect to changes and further improvement of the
implemented solutions.

The key imperatives for the post implementation phase include:

1. Perform regular usage monitoring and customer satisfaction assessment. Take special
notice of potential exclusion groups.

2. Carry out ongoing promotion to keep drawing customers’ attention to the new channels
and, if required, to decrease the usage of old channels that are to be phased out.

3. Analyze whether any changes are needed in the implemented solutions, the
organization’s business processes or structure, to further improve the service delivery

The following are the outcome for this phase:

 Information on the uptake of the service

 the actual benefits and costs as compared with the expected benefits

 Further changes required to the service

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annex 5- Institutional Structure

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. No Description Page

1 Introduction 85

2 Suggested Institutional Structure 86

3 Steps to be taken for successful 87

implementation of eGovernment

4 Sample Project Documentation Templates 89

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Institutional Struture

1. Introduction

For the effective implementation of eGovernance, a supporting institutional framework is

necessary to guide and monitor the direction of e-governance activities. The Institutional
Structure proposed here has been developed based on Ras-Al-Khaimah’s specific needs and
the on accepted conceptual framework for programme management. The institutional
structure would fulfill the following imperatives:

 Play a decision making role, but also instill autonomy across the various government
departments to fulfill their roles.

 Address program management responsibilities for eGovernment projects.

 Have adequate powers and legitimacy to get stakeholders acceptability.

 Flexible enough to adjust to the changing needs of projects

 Address faster decision making and support needs of projects.

 Provide value to the implementation units.

The Institutional Structure for the management of the eGovernment needs to be developed and
managed at two levels as shown in the figure below:

 Program Level: The program management level is required to focus on development

priorities of the emirate, citizen needs, services prioritization, implementation feasibility
and other such issues. The activities that individuals at this level need to undertake
include policy formulation, prioritization, preparation of the implementation framework and

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

monitoring guidelines, take decisions on policy matters and also to give

recommendations on the various issues.

 Project Level: The successful implementation of projects requires project management

skills in the people involved in the day to day management of the projects. The lack of
requisite project management skills is one of the prime reasons for failure of projects. The
activities expected of people at this level are preparation of detailed project reports,
transformation of concepts to implementable architectures, preparation of system
requirements, vendor selection and management, and implementation.

2. Suggested Institutional Structure

The suggested Institutional structure for eGovernment implementation in RAK is

The salient features of this option would be:

1. Programs would have to be approved by the finance and civil service departments.
2. All eGovernment initiatives requiring funding / support would be approved by the
Supreme Committee which would comprise of the Finance department.
3. The supreme committee would provide strategic direction to the eGovernance program,
operationalize the strategy provided by the EGA, and resolve inter-department issues.
4. The supreme committee would be responsible for overall monitoring and coordination of
all projects.
5. Each department would be responsible for project implementation and would have an
identified team for the project
6. The EGA directorate would be the central agency for all eGovernment projects

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

7. Core Component and common delivery channel project managers would be responsible
for coordination with implementers on all issues related to the eGovernment strategy
components (core infrastructure etc.) and common delivery channels.

3. Steps to be taken for successful implementation of eGovernment

Some of the other steps that need to be undertaken for promotion and successful implementation
of eGovernment program in RAK are:

1. Establishment of a Vision and Strategy Group

A group consisting of senior private sector and government functionaries along with IT industry
leaders would be established. The group would:
 Provide inputs on strategic issues and policy level interventions
 Review international benchmarks
 Act as brand ambassadors for RAK e-Government

The main benefits of this group include:

 Proper planning through discussions and validation before undertaking major projects
increases the chances of success for the e-Government program
 Top leadership focus on the e-Government program would be continued
 International experts would bring in learnings from good practices
 Raise the visibility and credibility of the program

2. Organizational and leadership capacity augmentation

In order to enhance the understanding of e-Government and the demands it makes on the
systems and processes within the government, the top leadership needs to be exposed to tenets
of e-Government and international good practices. The following steps should be undertaken:
1. Institutional Framework (as proposed in this strategy) for a transparent institutional
structure for identifying, monitoring, and evaluating projects.
2. Leadership orientation courses should be conducted for the development of
eGovernment champions in the department

Staff Skills Enhancement Programs

Detailed training needs and expectation exercises need to be carried out to ascertain the gaps
between skill sets required by the departmental employees and their current available skill sets.
The results of the study would facilitate the government in drafting courses for targeted training
programs. While the training needs assessment exercise will reveal the full extent of training
requirements, there are certain gaps in skill sets that have been identified during the AS-IS

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

assessment exercise. In order to ensure an effective implementation of the projects and ensure
sustainability of the projects trainings should be conducted in the following areas:
 Project management
 Vendor management
 e-Government program monitoring and evaluation
 Customer orientation and support
 Design and monitoring of Service Level Agreements (SLA)

3. Establish Centres of Excellence

Centres of Excellence for government process re-engineering, public private partnerships,
advanced technologies such as mGovernment, networking, security etc. and solution
experimentation should be set up. These centres would have dedicated staff in respective areas
and should be part of an agency that has done significant work in that area. EGA can set up
these centres or identify an agency to do so on the basis of discussions with the respective
agencies. Whenever an agency needs any help in the areas in which the Centres of Excellence
have been established, the team from the Centre of Excellence could help the respective agency.
While some CoE, like for government process reforms could be run by the government, private
partnership could be utilized for setting up of the CoE for advanced technologies and software
development. Opportunities for collaboration must be explored with other emirates while setting
up these Centres of Excellence. This will help ensure greater economies of scale, higher impact
and visibility.

4. Development of Project Management guidelines for the eGovernment Projects:

Project management is a formalised and structured method of managing change in a rigorous
manner. It focuses on producing specifically defined outputs by a certain time, to a defined quality
and with a given level of resources so that planned outcomes are achieved.
Applying a formalised project management framework or methodology to projects can help to
clarify and agree to goals, identify resources needed, ensure accountability for results and
performance, and foster a focus on benefits to be achieved. In a rapidly changing environment
with diverse opportunities and requirements, project management can support the achievement
of project and organisational goals, as well as give greater assurance to stakeholders that
resources are being effectively managed.
The RAK government needs to develop the project management guidelines along the following
lines for the eGovernment projects:
 Planning and Scoping
 Governance
 Organisational Change Management and Outcome Realisation Planning
 Stakeholder Management
 Risk Management
 Issues Management
 Resource Management

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Quality Management
 Status Reporting
 Evaluation
 Closure
 Documentation

In order to manage a project effectively some documentation is required. The actual amount of
documentation required is primarily dependant on the size and complexity of the project. The
Project Management Templates should be developed to support and capture the results of project
planning processes.
The following are some of the templates that can be used as guides for the use and application,
and should be modified to suit the particular requirements of the project.

4. SAMPLE Project Documentation Templates:

1. Project Brief


This is <release/version> <n.n> of the <Project Title> Project Brief.

The Project Brief is a managed document. For identification of amendments each page contains
a release number and a page number. Changes will only be issued as complete replacement.
Recipients should remove superseded versions from circulation. This document is authorised for
release once all signatures have been obtained.

PREPARED: DATE:___/___/___
(For acceptance) (<Name>, <Project Title> Project Manager)

ACCEPTED: DATE:___/___/___
(For release) (Project Sponsor, <name, title>)

Title: <Project Title>

Provide a brief explanation of the background and/or context of
the project. (Try and keep this to little more than half a page)

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

What is the aim of this project?

A useful way to frame the objective is to answer the question

‘why are you doing the project?’ The result is a one sentence
statement, or series of statements, starting with the word ‘To’

Target Outcomes
Target Outcomes are expressed in the past tense and usually
start with a word ending in 'ed', such as improved, increased,
enhanced or reduced. They are the benefits that the project
intends to achieve.

How will the success of the

project be measured: Describe the measure(s) that will used to indicate that the
project has been successfully completed.
Each measure will be linked to one or more target outcomes.
At the end of the project the measures will help answer such
questions as 'what have we achieved?' and 'how do we know?'

What things will be delivered by the project? Outputs link with
outcomes, in that the outputs are used by the project’s
customers to achieve the outcomes. Outputs are usually
expressed as nouns

Describe the management arrangements that will be put in
place to govern the project and briefly describe the
accountabilities of each party. As a minimum this will include
the name and title of the Project Manager and Project Sponsor.

Reporting Requirements: What is the reporting frequency, format and to whom?

What human resources, internal, external, consultants and/or
working groups will be required for the project?

Is the project is being conducted within existing operational

resources or have specific funds been supplied? If the project
has a specific budget, provide details of the proposed

Stakeholders & Communication

Strategy: List the key stakeholders or stakeholder groups who will impact
the project or be impacted by the project and describe how
they will be engaged.

Assumptions and Constraints:

Provide a list of any underlying assumptions and/or

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Major Risks & Minimization What are the barriers to achieving project success (i.e. the
Strategies: major risks)? For each of these risks, what steps will be
undertaken to minimize them?

Risk Management: What will be the process used to manage risks throughout the
project, particularly in relation to risk identification, review and
reporting? See the Risk Management resource kit at for more information.

Issues Management: What will be the process used to manage issues throughout
the project, particularly in relation to issue identification, review
and reporting?

Related Projects:
List any projects which are dependent on this project, or
projects that are interdependent on this project, or projects
upon which this project is dependent. Briefly describe the

What guidelines, standards or methodologies will be applied
manage the project?

Quality Control:
What levels of review will be undertaken throughout the
development of the project outputs? For example the timing of
output reviews, how the reviews will be conducted and who will
be involved.

Capturing the Lessons Learnt:

Describe any review process (internal or external) to capture
the lessons learnt throughout the project
Project Activities & Milestones:
List the major activities, scheduled start, scheduled finish and who has been assigned
accountability. Milestones are indicated by a blank scheduled start date. The activities
appearing in the predecessor column must be completed before the activity described can
Id Description Who Scheduled Scheduled Predecessor
Start Finish

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

2. Project Status Report

<Project Name>

Status Report No.<n>

File No.: <xxxxxxx>

REPORT FOR: (Optional) eg <Project Name> Steering Committee

PROJECT OBJECTIVE: As stated in the Project Business Plan.

Project Progress Summary:

A brief statement of project performance not covered in the remainder of the report.

This section should reflect any relevant high-level milestones listed in the Business Plan as well
as major milestones and achievements from the Project Work Plan (or Project Execution Plan).
Baseline dates are those outlined in Project Business Plan or other core document.
Table 1 - Milestones scheduled for achievement since last report and performance
against those milestones:

Milestone Baseline Date Target Date Achievement

<Description of milestone> dd-mm-yyyy dd-mm-yyyy dd-mm-yyyy

Table 2 - Impact of achievement / non-achievement of milestones for the remaining

period of the project:

Milestone Impact
Description of affected/amended/changed Briefly describe any changes to the project
milestone schedule required as a result of the amended

Table 3 - Milestones scheduled for achievement over the next reporting period and
changes to those milestones with respect to the previous plan:

Milestone Baseline Date Previous Target Current Target

Date Date
Description of milestone dd-mm-yyyy dd-mm-yyyy dd-mm-yyyy

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

General Information
Include any general comments that may support/enhance/add to the above sections.

Things to note in this section may include:

 Staffing issues, training undertaken
 Update on employment of consultants, eg detail how government purchasing principles
and policies have been applied to each tender process.
 A follow-up assessment of products/services provided against the initial terms of
engagement should be provided in a later Status Report.


Where the project draws on multiple funding sources (eg Commonwealth and State funds),
separate budget analysis should be provided for each source.

Where the project is beginning the transition to program mode, Business Owners need to be
made aware of the level of recurrent expenditure required for ongoing maintenance of the
Table 4 - Funding Sources
Department of … $ 500 000
Department of … (plus) $ 500 000
Total project funding (equals) $ 1 000 000

Table 5 - Project Budget Overview

Total Project funding Example: 4 year $1 000 000
Expenditure for <Financial Year A/B> (minus) $ 200 000
Expenditure for <Financial Year B/C> (minus) $ 250 000
Remaining budget for life of project (equals) $ 550 000
Preliminary allocation for <Financial Year C/D> $ 300 000

Additional comments should be included to indicate reasons for the deficit/overspend or
surplus/under-spend in the monthly budget and anticipated expenditure for the year to date.

Project Risk Management Statement

Identify any changes in risk status to the previous report. See risk grading key below.
Risk Likelihood Seriousness Grade Change
Brief description of the Extreme,
major A and B grade risks or any Low/Medium/Hig Low/Medium/Hig
significant changes in grading, h h
and new risks identified.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Risk Grading Key:

E Extreme
A High/High
B High/Medium or Medium/High
C High/Low or Medium/Medium
D Medium/Low
N Low/Low

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annex 6- Capacity Building Strategy

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. No Description Page

1 Introduction 96

2 Need for Capacity Building 96

3 Capacity Building Plan 97

4 Implementing the Capacity Building Plan – 102

Action Points (Individual Agencies)

5 Issues and Risks 103

Capacity Building and Change Management

4.2 Introduction
EGovernment projects are not equivalent to conventional IT projects. The focus of the
eGovernment strategy is on services, service levels, and project sustainability and not on
software and hardware. Capacity building seeks to address the skill gaps in the current
system and people. Capacity building in the context of this strategy, refers to the need to adjust
policies and regulations, to strengthen institutions, to modify working procedures and coordination
mechanisms, to increase the skills and qualifications of people, to change value systems and
attitudes in a way that meets the demands and prerequisites of implementing the eGovernment
strategy of the Emirate.

4.2.1 Need for Capacity Building

There are a number of important reasons for the Emirate to focus on capacity building. These
 Additional skill sets required for eGovernment projects – Based upon the AS-IS
departmental assessment, it is seen that while government employees are well versed
with usage of computers, there are no targeted courses to enhance the skill sets if
employees in the area of e-government. Concentrated training in areas such as change

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

management, project management, vendor management, customer management, etc

need to be enhanced in order to effectively manage and implement eGovernment
 Complexity of the programme – eGovernment strategy focuses on common policies,
standards and infrastructure components across multiple independent agencies. This is a
huge cultural shift from the traditional silo approach to government wherein each agency
behaves like an independent entity with minimal information flow and coordination.
Institutional mechanisms to address this requirement have to be put in place for the
eGovernment programme to succeed.
 Utilization of funding – Implementing the eGovernment programme will entail additional
financial allocation. It needs to be ensured that systems, processes, institutions and
people are capable of absorbing and using this money optimally to ensure value for the
money spent.

4.3.1 Capacity Building Plan

In order to achieve the expected outcomes from this initiative, the following strategy (capacity
building plan) is proposed:

1. Creation of a central agency for providing government wide IT services

2. Create appreciation and understanding of eGovernment projects amongst decision makers
3. Enhancement in capacities of the ministries to undertake eGovernment projects
4. Development of skill sets amongst customers
5. Effective government wide knowledge sharing and coordination
6. Change management plan Enhancing the role of EGA to act more as an enabler for eGovernment rather that
the Central Procurement Agency
The procurement for IT (both software and hardware) for most of the department is routed
through EGA. This has led to EGA being perceived as a central procurement agency.
In order to overcome this, it is suggested that EGA must prepare an action plan for creation of a
pool of ICT resources available for all government agencies as and when required. EGA needs to
undertake activities like the development of ICT curricula and training models for use throughout
government and provide a knowledge base for all ICT needs linked to a central knowledge
management repository.
Following benefits will be realised through EGA:
 Capacity Balancer: EGA would act as a capacity balancer for departments through the
provisioning of resources for completion of the IT projects.
 Focus on outcomes and timelines: As the EGA staff will be deployed in any department for a
fixed time to complete a project; there would be a higher focus to complete the projects on
 Better staff retention and career planning: A central services group will be big enough to
provide a defined career path and growth opportunities to IT resources. Though the IT

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

resources could work on projects in different departments, they would report to the managers
in the EGA and have a deeper career path in the EGA.
 Diverse skill sets: Due to the aggregation of resources, diverse skills sets would be available
within the EGA to undertake projects. This will enable the group to use most appropriate
people and technologies to provide solutions. Better understanding and appreciation of eGovernment projects amongst

decision makers
Establishment of a Vision and Strategy Group
A group consisting of senior private sector and government functionaries such as the GM of the
key department like EGA, Finance, Civil Services and Municipality along with IT industry leaders
and eminent personalities will be established. The group would:
 Provide inputs on strategic issues and policy level interventions
 Review international benchmarks
 Conduct periodic review of the eGovernment programme and advise on corrective
actions if required
 Act as brand ambassadors for the eGovernment programme and Ras-Al-Khaimah

Main benefits emanating out of the group include:

 Proper planning through discussions and validation before undertaking major projects
increases the chances of success for the project
 Top leadership focus on the eGovernment Programme will be maintained
 International experts will aid the learning process from best practices
 Raise the visibility and credibility of the programme

Organizational and leadership capacity augmentation

In order to enhance the understanding of eGovernment and the demands it makes on the
systems and processes within the government, the top leadership needs to be exposed to the
tenets of eGovernment and international good practices. The following steps should be
3. Programme Management Framework (PMF) for a transparent institutional structure for
identifying, monitoring and evaluating the projects.
4. EGA to set up a training centre to develop courses and training of top government
5. Leadership orientation courses should be conducted
6. Exchange programmes for the top brass of the public sector with various established
centres of excellence for eGovernment learning.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah Enhancement in capacities of the ministries to undertake eGovernment Projects

Staff Skills Enhancement Programs
Detailed training needs and expectation exercises need to be carried out so as to ascertain the
gaps between the skill sets required by the department employees and the currently available
skill sets. The results of the study will facilitate the Emirate in drafting courses for targeted training
programs. While the training needs assessment exercise will reveal the full extent of training
requirements, there are certain gaps in skill sets have been identified during the as-is assessment
exercise. In order to ensure an effective implementation of the projects and ensure sustainability
of the projects trainings should be conducted in the following areas:
 Project management
 Vendor management
 eGovernment programme monitoring and evaluation
 Customer orientation and support
 Design and monitoring of Service Level Agreements (SLAs)

Establish Network of Experts

Network of experts for government process re-engineering, public private partnerships, advanced
technologies such as mGovernment, networking, security etc. and solution experimentation
should be empanelled. These would have a pool of experts in respective areas or should be
part of an agency that has done significant work in that area. Whenever a department needs
any help in the areas in which the network have been established, EGA would contact the pool of
experts to help the department.
EGA should also consider the option of setting up Centres of Excellence (CoE) in these areas.
While the CoE for government process reforms and public private partnership could be run by the
government, private partnership could be utilized for setting up of the CoE for advanced
technologies and software development. Opportunities for collaboration must be explored with
other emirates while setting up the CoEs. This will help ensure greater economies of scale, higher
impact and visibility.

Encourage Third Party Certifications

Employees should be encouraged to augment their skills through third party certifications such as
a Microsoft certified systems engineer, a Cisco certified network associate, and a project
management professional etc. The encouragement could be in the form of providing support in
the form of leave for preparation of exams or payment of examination fees provided the employee
clears the exam. Development of skill sets amongst the customers

Promotion of ICT Education and eGovernment in Schools
The course curriculum in schools must have modules on ICT education and eGovernment.
Children can help their parents in not only accessing services but also in informing them of the

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

introduction of new services. It must be ensured that every school has Internet access facilities
for children.

Marketing and Awareness Campaign

A comprehensive marketing and awareness campaign should be initiated to create awareness
about the various new services and channels that are introduced. This should include specifics
such as the toll free number for contact centre, operation timings for the contact centre and the
CSCs, etc.

Establishment of Self-service Kiosks with an option for assistance at Common Services Centres
Self-service kiosks with an option to obtain assistance could be set up at the Common Services
Centres. This will enable the customers to learn the procedure of availing services online by using
the services with help of well-trained staff.

Targeted Training for Businesses

It is critical to run elaborate training programs that will create awareness and capability amongst
the businesses in using eServices and electronic channels. This will also make the industry in the
emirate more competitive. Government wide knowledge sharing and coordination

Develop a Knowledge Management System and Culture
A Central Knowledge Management infrastructure needs to be created so as to ensure that
learning from the previous projects is inculcated in new projects. This prevents wastage of effort
and money while conforming to planned timelines. As connectivity through RAK GIN is already
available for all departments, a database needs to be developed that would store all the
information and be accessible through the RAK GIN. As important would be encouraging the
employees to share their learning on the system and utilize others’ learning’s while working on
new projects. The project office being set-up as part of the eGovernment strategy can take a lead
in defining the contours of the Knowledge Management System
eLearning tools
eLearning tools could be made available centrally which could be accessed through the RAK
GIN. This will facilitate the employees in enhancing their skills at their own pace. Change Management Plan

The implementation of eGovernment strategy will lead to a major overhaul in the provisioning of
services. This will demand new skills and a paradigm shift in the working of the government. In
order to ensure a smooth transition, a well thought out change management plan is essential.
The various steps involved in developing the change management plan are as shown below:

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Change Management Plan

Build the Ability to to Empower Consolidate

Consolidate Embed
Ability Empower Communicate Generate
guiding change and change agents change vision gainsgains
and & approach in
chanjhhb the change the change shortTerm
Short term produce more departmental
coalition transform produce in org.
Transform agents vision wins Wins
more changes culture

Form the steering

committee Build learning
Replicate the
success stories
 Measures
Org Survey to
measure readiness to  Structures
 Rewards

Survey outcomes to
Align rewards &
 Skills
be used as input for
design phase  Culture

Identify successful change


Finalize change Implement the change

team plan
Train the change
Implement communication strategy
Finalize goals &
Fix accountability

As shown in figure aboveError: Reference source not found, the Change Management Plan is
proposed to be a 7 step process. As the first step, a steering committee would be formed to
oversee, monitor and evaluate the success of the change management plan. This steering
committee could be formed by selecting a 3-5 member team from various departments and the
EGA. A survey within government agencies would then be carried out to understand the
expectations and aspirations of the employees and their understanding of the eGovernment
programme. This would form the basis of the messages that are developed as part of the
communication plan. In order to communicate the communication plan and manage change,
change agents within each organization would be identified and subsequently trained. These
change agents will be accountable for implementing the communication strategy, conducting
workshops and creating awareness and support for the changes being undertaken. Quick win
opportunities will be used to get the buy-in of employees to generate the critical mass required for
Going forward, it is natural that some patterns, messages and projects will be more successful
than the others. These need to be marketed and replicated to increase the support for change.
It is important to consolidate the gains obtained during the first level of change. Once a critical
mass is reached, the initial change agents would become project sponsors in their respective
areas and they will further train and guide the next level of change leaders. The next level will in
turn drive the change efforts in their work area and the cycle will be continued to ensure that the
change reaches down to the last level in a given organization. This self-propagating cycle is
envisaged to transform the government agencies into learning organizations that will ensure the
success of the eGovernment programme.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

4.3.2 Targets for Capacity Building

The Table below summarizes the capacity building targets based upon the proposed capacity
building plan for better monitoring.

Capacity Building Targets

Capacity Building Targets for the RAK government

Year 1

 100% employee awareness regarding the eGovernment programme

 100% computer literacy for all government employees
 Establishment of network of experts for software development and GPR
 Detailed training needs assessment of the government staff
 Identify and train of one eGovernment Champion in each department
 Operationalization of Training centre for eGovernment in EGA
 departmental applications management (system administration) training to at least 2 employees
in each department
 One person trained in IT infrastructure management

Year 2

 Establishment of a centralized knowledge management system

 Leadership training and orientation programme on eGovernment
 Development of eLearning courses for the employees
 Identification of international/third party certification courses; encouragement to employees to
undertake the certification
 eGovernment project monitoring and evaluation training to at least 2 employees
 Identification of international/third party certification courses and encouragement to employees to
undertake the certification. Encouragement could be in the form of re-imbursement of fees for
examination of employees who clear the exam

Year 3

 Refresher training for the eGovernment Champions

 Stabilizing and strengthening the knowledge management system
 Development of eLearning courses for the employees

4.3.3 Implementing the Capacity Building Plan – Action Point (Training

 Create a vision and strategy group to ensure that organisational and leadership capacity is
both developed and exploited

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Create and operate a central knowledge management repository, providing access for all and
an editorial board

 Develop and implement government-wide personnel policies related to capacity building

including training, curricula development, promotion, recruitment, salaries, etc

 Create central group in EGA , with a wide-pool of ICT resources available across all
department, as needed, and develop and implement appropriate training courses

 Support each department in developing and implementing agency-specific ICT training as

well as non-ICT training

 Collaborate with private suppliers (especially ICT suppliers) and with educational/training
organisations, for training and capacity building purposes

 Coordinate internationally for exchange programmes and study visits

4.3.4 Implementing the Capacity Building Plan – Action Points (Individual

 Each agency will be mandated to design and implement its own ICT and non-ICT training and
staff development schedule which, though EGA, should be in congruence with the
eGovernment strategy and the supervision and approval of central bodies.

 Encourage the agency staff to use the Central Knowledge Management repository, as well as
develop local agency versions as required.

 Identify personnel for training and personnel development in, for example:

o Basic ICT skills

o Specialised ICT skills
o Non-ICT skills and competencies
 Each agency will draw up its own budgeted skills and capacity building needs and plans and
get this approved by the central bodies. This will include evaluation and feedback on activities
and impacts.

4.3.5 Issues and Risks

 Buy-in from all involved agencies may not be forthcoming

 Tools, training and necessary expertise may not be available

 Appropriate staff may not be available in the labour market and staff may not be willing and
capable of responding to training

 Monitoring, feedback and evaluation should take place in a timely manner

 Experiences and lessons learnt should be re-cycled and actively used as part of the
monitoring and evaluation process

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annex 7- Marketing and Awareness Strategy

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. No Description Page

1 Introduction 106

2 Target market segments 106

3 Communication and media channel mix 107

4 Message 107

5 Timing 109

6 Development / Approval Process 110

7 Feedback, measurement of effectiveness 110

and improvement

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Marketing and Awareness Strategy


Design of the marketing and awareness campaign will include five key components, each of
which should be defined and described in as much detail as possible during the planning and
design stage:

1. Identifying target market segments

2. Channel (media mix) selection
3. Timing
4. Message development
5. Audience skills and education

1. Target market segments

One marketing medium cannot reach all segments of the community of Ras Al-Khaimah.
Marketing campaigns do best when they define specific target markets and deliver a tailored
marketing program for each target market. Our prior experience with eGovernment awareness
campaigns indicates that billboards and traditional media – such as newspaper and television –
alone will not be sufficient to penetrate the target market with news of the eGovernment services.
We also recommend using the popular FM radio, presentations at meeting of the organizations,
and events to supplement billboards and traditional advertising. Additionally we could also look at
the mosques for distribution of flyers and leaflets. These marketing outlets will provide an
opportunity for the government of RAK to tailor specific messages for the target segment. One
simple segmentation of the customers of the eGovernment services is

 Business
 Citizens and residents
 Visitors
 Government Employees

Within these target segments, these can further classified. Within a particular segment, there may
be groups that will require special targeting. For example, if the RAK launches a web application
that enables applications for scholarships to be submitted online, it may be necessary to market
this service to the students and their parents.

2. Communication and media channel mix

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

An appropriate communication and media channel mix is critical to ensure that everyone in the
target audience receives and understands the campaign messages. Given customer diversity,
any awareness-raising campaign that relies too heavily on just one medium or type of
communication is unlikely to achieve its goals. However, there could be services which might be
targeted at only a small segment of the society which would require targeted campaign through
the channels and media of the choice of that segment. E.g. Pensions is one service that will only
be targeted at the people in the old age, so the campaign will have to be directed through the
medium which is most appealing to the old age segment. Suggested channels for different

segments are illustrated in Table below.



Direct mailers


Business publications


CommerceChamber of
Citizens & Residents      
Businesses      
Students     
Younger Generation      
Non-Arabic speaking     
Government employees       

3. Message

The development of specific messages should be undertaken after the formal adoption of the
eGovernment strategy and implementation plan that specifies the order in which services will
become available, the agencies affected, and other essential details. Since we are
recommending a “phased-in” approach to implementing the eGovernment services, the marketing
plan will need to reflect the planned sequence of operations.

The marketing team within the project office should work with advertising and public relations
professionals to craft specific marketing messages, including both Arabic and non-Arabic
speaking customers. The development of messages should proceed in tandem with refinement of
the overall marketing plan. Creative concepts and material should be tested in focus groups for
clarity, impact, “memorability” and other dimensions.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Specifically, decisions regarding the level of budget available for the marketing campaign will
drive the types of media that can be utilized, which will in turn drive the development of messages
appropriate for each medium.

Working with experts to craft messages requires a disciplined time commitment. Work should
begin on the development of marketing messages at least three months prior to the desired
launch of the marketing campaign. The government must also factor in the additional upfront time

required to select the vendor(s). Figure 12 summarizes the message development component.

Message  Work with the implementation team to track key milestones and likely
Development timing
 Identify generic messages in advance, plan and prepare drafts for
 Work continuously with the implementation team to anticipate
communication/message requirements
 Manage detailed communications plan and work with experts to
determine content and format
Challenges  The timeline for key implementation milestones may change so
mapping key messages to it is a challenge
 Working with authors to craft messages; requires disciplined time
 Tracking and monitoring of messages distributed and to whom
Actions  Proactive planning of generic messages and build ‘database’ of items
ready for publication
 Clearly assign “owners” for content development of messages
 Conduct detailed planning on a rolling 3-4 month basis to reflect shifting
events timeline

There are a number of generic messages that can be pre-planned, prepared and
preapproved. These will serve to raise customer’s awareness, and to answer the basic
questions that they are likely to have about the eGovernment Strategy. Suggested subjects
for these generic messages are listed below.

Communication of the rationale

 What is the vision for eGovernment programme
 Why do we need an eGovernment strategy
 What are the major benefits?
Establish Awareness of the Project
 What is the eGovernment programme about
 Sponsorship – who is the champion?
 Structure & organization
 Implementation approach
 Implementation timeline
 Integration with other RAK government initiatives
 What will change?

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 What will stay the same?

 What has happened so far?
Periodic update on progress
 Achievement of milestones and celebrations of success
 Changes in timeline, scope and/or approach
 Differentiation of this project from others
 Why will this one succeed?
 Lessons incorporated from other projects
Impact on the Government’s functioning
 How will we operate differently?
 How will this be perceived by the “outside” world?

Impact on the Individual Customer

 What will change for me?

Generic, pre approved messages will only partially meet the information requirements of the
government employees. Ad hoc messages may also be needed as the dynamics and events
change through the implementation lifecycle. Ad hoc messages will be needed to address key
developments, issues arising and achievements across all facets of the eGovernment
programme. To capture these, the project office and the eGovernment implementation teams in
various agencies will need to remain in close contact.

4. Timing

Making a noticeable difference in the government’s quality of customer service and increasing
public access to government information and services are intrinsic drivers of the eGovernment
Strategy. The judicious use of the modern customer service technology that will be deployed in
the common channels being created will help to enhance the RAK’s image in the public eye.
While there may be a strong tendency to begin publicity early, the best approach will be to delay
the campaign until sufficient infrastructure is in place to handle a sudden influx of telephone calls,
emails, and service requests. In this manner, the government will avoid the problem of building
expectations that are then unrealized.

Government employees will continue to be responsible for delivering services to residents and
businesses. Employees interface with the public on a daily basis and their understanding of the
eGovernment services is a critical success factor. Moreover, if employees are appropriately
informed, they can serve as ambassadors, helping to spread the word about the new services.
The general rule of “tell them early, tell them often” should be observed with truthful,
straightforward, consistent communications to all Government employees. It is critical that
government employees are fully educated about and supportive of, the eGovernment program.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

5. Development / Approval Process

An explicit communications development/approval process will ensure that communications are

appropriate and consistent. To avoid confusion, it is particularly critical that the meaning of
messages delivered in the internal communications programme be congruent with those that are
used in the external marketing campaign. The marketing team will be responsible for reviewing
draft materials; contributing editorial suggestions, approving the final version and ensuring that
scheduled release dates are met. The EGA should also review and comment on critical internal

6. Feedback, measurement of effectiveness and improvement

For the government internal communications programme, it is critical that feedback be sought
and the effectiveness of communications measured on a regular basis. This will require
scheduling and commitment to respond to constructive feedback and take action to address
issues raised. These assessment efforts will provide valuable insight into whether the generic
messages are reaching the intended audience and provide insights into ad hoc messages
required in the near term. The feedback mechanism envisaged will address two requirements.
The first is quantitative, tracking plan against execution and the delivery of messages to the
intended stakeholder/audience. The second will focus on qualitative data; stakeholder/audience
understanding and engagement or issues generated through communications. Collation of data
will occur on an ongoing basis, and periodic, pre-planned reviews with the marketing team will be
scheduled. It is important that the communication plan be adapted and subsequent behaviors
demonstrate actions in response to feedback collected.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annex 8- Strategic Control Checklist

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. No Description Page

1 Strategic control over the Application 113

2 Application Audit 114

3 Code Signing 114

4 Version Control 114

5 Role Segregation 115

6 Strategic control over Database 115

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

1. Strategic control over the Application

# Strategic Control Requirements Compliance

1. a) RAK EGA shall exercise ownership of the application,

through the Application Ownership and Version Control. To
this end, the applications shall be designed to ensure that
i. The technical personnel of RAK EGA are
associated with the design and development
phases of the Project. Specifically, the SP shall
obtain the sign-off of RAK EGA on the design
ii. The Application System and the Source Code are
deposited with RAK EGA after the initial certification
by a 3rd Party and before the ‘Go Live’.
iii. Any subsequent changes to the application are
incorporated in the Application Repository on an
incremental basis, after the process of approval
prescribed herein is undergone.

2. b) Any changes to the application, required to enhance the

functionality, or to improve performance or to cover security
gaps, shall first be hosted in an application staging
environment, tested for consistency, integrity and
performance by the Application Administrator of the SP.
Thereupon a request shall be preferred to the Application
Administrator(s) of the RAK EGA, to permit the proposed
changes, with clear reasons necessitating the change. The
Application Administrators of RAK EGA shall review the
proposed change and accord their approval or reject the

3. c) RAK EGA may entrust the responsibility to 2 Administrators,

who can exercise the privilege of according a permission or
rejecting a request ONLY JOINTLY.

d) No change to the application shall be effected by the SP

unless the process defined at (b) above is gone through.
Whenever any change is released in Live Environment, SP
will make contingency plan so that in case the change fails
SP will make use of contingency arrangement to start the
application from there

e) To this end, all the actions of the Application Administrator

shall be logged.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

# Strategic Control Requirements Compliance

f) The actions of the application administrator of the SP shall

be kept as few and infrequent as possible. To this end the
enhancements and changes proposed to the application
are planned sufficiently in advance, to the extent possible,
bunched together and implemented at pre-specified

2. Application Audit

# Strategic Control Requirements Compliance

1. a) All changes to application shall be carried out after a review

and pre-audit by the RAK EGA Application Administrators.

b) The system shall be built with capability and functionality

that will allow conducting a post-implementation review and

c) RAK EGA will have the right to undertake comprehensive

application audits at regular intervals and if necessary
through a 3rd party to ensure application functionality and

3. Code Signing

# Strategic Control Requirements Compliance

1. a) All application components shall be digitally signed by using

Software Publishing Certificates (SPC)

b) System shall ensure loading and utilizing (within

applications) only those components that have been
digitally signed with the right SPC to eliminate the
inadvertent use of malicious components.

4. Version Control

# Strategic Control Requirements Compliance

1. a) The application software shall be version controlled,

adopting the industry standard practices like Version
Control System (VCS), Source Code Management System
and Software Configuration Management (SCM) in this

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

# Strategic Control Requirements Compliance


b) The System shall permit the latest versions of the

application and source code to be deposited with the RAK
EGA, with appropriate logs maintained for each change.

5. Role Segregation

# Strategic Control Requirements Compliance

1. a) The roles of different personnel responsible for designing,

coding, accepting the changes and authorizing the changes
to be carried out into the production environment shall be
clearly defined by the SP.

b) The role segregation shall cover all the administrators

involved both in the SP Zone and the RAK EGA.

6. Strategic control over Database

# Strategic Control Requirements Compliance

1. a) RAK EGA shall exercise ownership of the database,

through the Database Control Module and the Government
Secure Repository. To this end, the databases shall be
designed to ensure that
i. The entire database, including the table structures,
schemas and master data are deposited with the
RAK EGA, after the initial certification by a 3rd Party
and before the ‘Go Live’.
ii. Any subsequent changes to the database system
are incorporated in the Database Repository on an
incremental basis, after the process of approval
prescribed herein is undergone.
iii. At the end of every business hour, the transaction
data is mirrored to the RAK EGA Secure
Repository, on an automated basis. To this end,
RAK EGA shall establish a Secure Repository of
appropriate capacity and features to be designed
and recommended by the SP and approved by

b) Any changes to the database structure, required to

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

# Strategic Control Requirements Compliance

enhance the functionality, or to improve performance or to

cover security gaps, and any changes to the master data,
shall first be hosted in a database staging environment,
tested for consistency, integrity and performance by the
Database Administrator of the SP. Thereupon a request
shall be preferred to the Database Administrator(s) of the
RAK EGA, to permit the proposed changes, with clear
reasons necessitating the change. The Database
Administrators of RAK EGA shall review the proposed
changes, test cases used for testing the functionality, and
accord their approval or reject the request.

c) RAK EGA may entrust the responsibility to 2 Database

Administrators, who can exercise the privilege of according
permission or rejecting a request ONLY JOINTLY.

d) No change to the database structure or to the master data

shall be effected by the SP unless the process defined at
(b) above is gone through. To this end, all the actions of the
Database Administrator of the SP shall be logged.

e) The DBA password shall be retained by RAK EGA, with the

designated RAK EGA DBAs, who will authorize the
database administration actions of the SP each time it is
required to be done (i.e. the RAK EGA DBA(s) will supply
the credentials to the SP DBA, to allow performing such

f) Any direct access to database must be avoided and the

database administration activities (especially all those
actions that result in modification of data, schema and
master data) shall be executed through an application
which verifies and audits users, code and actions done on
the database.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Annex 9- Standards and Policies

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. No Description Page

1 Centralized Metadata 119

2 Database Standards and Guidelines 121

3 Application Architecture 127

4 Component ware Architecture 147

5 Application Communication Middleware 151


6 Network Architecture 153

7 Integration Architecture 159

8 Information Security Standards and 178


9 Business Continuity and Disaster Recovery 191


Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Standards and Good Practices

Centralized Metadata

Recommended good practices:

Good practice 1: Use and actively maintain the Centralised Metadata Repository (CMR) to store
metadata definitions

 Storing data element definitions in a central repository incrementally builds the enterprise data
 The repository must be actively maintained (e.g. changes to metadata occur in the repository before
the changes occur in operational applications).
 The repository serves as a centralized data administration tool and helps promote data reusability,
reliability, and sharing across the enterprise.

Good practice 2: When designing or modifying a database, review the CMR for existing standard and
proposed data elements before implementing a new database to ensure data elements are defined
according to CMR standards

 Design reviews are essential to ensure that shared data is defined consistently across all
applications. Design reviews also determine whether data that already exists is consistently defined
and not redundantly stored.
 Design reviews should document the following:
 Where is the application getting its data?
 What other applications are getting data from the application?
 Is data used by the application defined consistently with metadata definitions?
 A design review evaluates the data requirements of a project and identifies the following:
 A data requirement that can be solved by using existing centralised metadata element
 Data not already identified as centralised metadata must be proposed as an agency or nation-wide
standard to become centralised metadata.

Good practice 3: Define existing databases in the centralised metadata repository

 If possible, existing databases should be defined into the database component of the CMR.
 Centralized data management is crucial to the quality and consistency of shared data and requires a
quality assurance and quality control process in place for enterprise data.
 As decentralized databases are implemented across the organization, centralized administration will
be crucial to the quality and consistency of the data. Use of inaccurate and inconsistent data is of
questionable value.

Good practice 4: Identify authoritative sources for centralised metadata

 Authoritative business sources for centralised metadata must be identified, documented, and
actively maintained in the repository. Authoritative business sources are the business units
responsible for the accuracy of the data stored.
 A source of record is an authoritative source for data. Data in a source of record is trusted to be

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

accurate and up-to-date. All other data stores should synchronize to the source of record. The data in
record sources must be actively managed and the data model should be verified by data
administrators. Tools and quality control techniques must be applied to the contents of the data
stores themselves, in order to ensure the quality of the data.
 Each application must identify data sources for all data that it does not originally capture. The
application capturing the original data is the authoritative source, and is responsible for the quality
of the data. All application data models for ongoing projects should be reviewed to ensure that data
existing in authoritative systems is reused and not redundantly stored.

Implementation guidelines:
Guideline 1: Use and actively maintain the CMR

 Avoid defining data elements on an application-by-application basis.

 Agencies must use and actively maintain the information stored in the CMR to maximize
 Establish and document consistent definitions for data elements with anomalies.

Guideline 2: Propose new CMR standards when applicable

 Review data models for new repository standards.

 Propose new repository standards to the metadata element review team.

Each of the metadata elements could be detailed under the following distinct
metadata attributes, given below:
1. URL 2. Element Name 3. Element Definition 4. Element Description

5. Business Format 6. Validation 7. Values 8. Default Value

9. Owner 10. Based On 11. Verification 12. Synonyms

13. Homonyms 14. Comments 15. Version 16. Date

This list is indicative and should be decided based upon business needs.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Database Standards and Guidelines

Data is the essence on which the information systems are developed for processing, storing and
retrieving the data. Agencies typically process and manage large volumes of the customer data in
both manual and electronic format. Moving towards such an initiative of computerizing the
Agencies business processes need adequate planning and care for managing the data and this
section discusses the key aspects of Data management.

Data is organized and managed through a database management system (DBMS). It is

recommended for the Agencies to implement a standard relational database management system
(RDBMS) for its data storage and management. A relational database management system
(RDBMS) is a collection of data organized into related tables so relationships between and
among data can be established. When new databases are implemented in an agency, relational
database technology should be used, because of the efficiency, flexibility, and compatibility
associated with relational technology. Non-relational technology, particularly flat files, should only
be used for unstructured data, textual data, and temporary work storage. In an n-tier design, data
access services are implemented in a separate tier from business rules and user interfaces.

The database structure design, based on the business processes and the data generated by
these business processes of an agency, shall be performed by the vendor selected for the
solution deployment.

Recommended Good Practices

The recommended good practices in this section pertain to designing and implementing a
Good Practice 1: Use a relational database management system (RDBMS).
 Although there is cost and effort associated with an object-relational model, the relational data
model is much more adaptive and understandable. RDBMS allows new relationships and data
mappings to be easily defined.
 As applications and associated databases age, applications tend to depreciate because business
needs change over time, while data and databases appreciate because of the valuable information
contained within.
Good Practice 2: When using a relational database with object-oriented programming, design the
relational data model first.
 Object models are typically more complex than the relational model.
 If the object model is built first, building the relational model that matches it may not be possible.
Good Practice 3: When creating an object-relational mapping between the object model and the
RDBMS, keep it simple.
 Simple relationship mappings between objects and relational databases provide ease of use and
better performance.
 Use the primary and foreign key relationships in the RDBMS to assist in mapping relationships
between objects.
Good Practice 4: Replicate stable data, based on business and performance requirements.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Replication should not be used unless it is required for performance or decision support.
 A replication infrastructure is simpler to design for stable data. If replicated data is updated
frequently (i.e., not stable), it is much more difficult to design and maintain a replication


The standards in this section pertain to database management systems.

Standard 1: New databases must use a relational DBMS supporting ANSI-standard SQL.
 Relational databases offer dependability, flexibility, and compatibility for future data needs.
 Data can be maintained and readily accessed through standard SQL calls. SQL is an industry
standard for the data access tier of an application and for data access tools.
 Use of proprietary extensions creates vendor lock-in.
 Desktop database products are considered end user database access tools and must not be used for
agency wide implementation.
 Non-relational technology such as flat files can be used for temporary work storage and
unstructured data such as textual data. Large-scale use of non-relational technologies must obtain a

Data Security
Agency data is a valuable resource, and establishing a secure data environment is a key
component of the technical architecture. It is critical that the agency data be protected against
any unauthorized access. Data security is designed to protect data against the following threats:

 Unauthorized use of the database or application

 Accidental modifications and deletions

 Confidentiality and integrity breaches for data in data transport and physical storage

 Disasters.

There are various security models that can be deployed when implementing an Internet or a web
based application. The appropriate model to deploy can be determined primarily based on the
security requirements of the data being accessed.

In many applications today, authentication is handled by the application when the user first
connects. This practice is used to minimize user account administration, so a user account is
defined centrally, and accounts and passwords are not maintained in multiple locations. In the
back end, when databases are accessed, a generic user account is used instead of a specific
user account for authorization purposes. When this method is deployed, it is important to
implement an audit process within the application to ensure that the activities of each user are

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

When a generic account is used, the individual account is not automatically communicated to the
database and tracked in the transaction log. Without an audit process in place, when a record or
group of records is updated or deleted, it may not be possible to know which user performed the
modifications. When a true threat is realized, it is important to be able to recover the lost data and
track the user account that was used inappropriately. A best practice for the application is to
capture key information about each user who modifies or deletes records. This information can be
stored in the database, capturing old and new information, or the deleted record, along with
transaction activity for an update or delete of a record. An audit process may not be necessary
during a read-only transaction, as the data is not being modified, unless sensitive data is

Implementing backup and recovery procedures is also a crucial process for data security. A
backup can limit the loss of data that may occur due to disaster, theft, intrusion, or accident. Data
stored on end user systems must also have a backup and recovery plan and key information
must not be stored on end user systems without encryption or password protection.

Protecting a database server is also a consideration when implementing and supporting a

database. A firewall solution shall be used to protect a database server. A firewall can limit the
access to a server by restricting the addresses and/or requests to the database server. For
example, only certain programs can be allowed access to the server, restricting individual ad hoc
usage. Access can be limited to specific application servers or processes as well.

Recommended Good Practices for Data Security

The recommended good practices in this section pertain to data security.

Good Practice 1: Perform a risk assessment for the application database and data elements to
determine level of security required.
 To assure adequate protection of data assets, perform a risk assessment to identify specific security
concerns that must be addressed before development and deployment of an application.
 The security analysis will determine what measures must be put in place to restrict end users and
applications from viewing, modifying, or deleting confidential or private data. The security
analysis may reveal that adequate measures are in place to restrict end users and applications from
viewing, modifying, and deleting low impact and public data.
 Classify users according to their functional data needs (e.g. outside access from citizens /
residents, other agencies, external service providers etc.)
Good Practice 2: Use generic, protected user accounts for direct database access to streamline
administration, ensure scalability, and protect against non-application data access.
 When a generic, protected user account is used, each individual user account is not defined to the
database, so end users are unable to gain ad hoc access to the data. Their only access should be
through the application.
 The individual user account is only defined at the application level, and does not have to be
maintained in more than one place.
 Implementing generic users makes applications scaleable since each process is not tied to a
specific user.
 The generic user account and password used to access data in the back end must be protected and

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

not accessible to end users.

Good Practice 3: Implement data security to allow for changes in technology and business needs.
 Implement security to be a roadblock to unauthorized access, but not a hindrance to access by
authorized users. Implement the minimal number of sign-on or authentication processes if
 An adaptable security infrastructure must be implemented to allow for changes in technology,
business needs, and reactions to intrusions.
 Monitor industry security alerts and recommendations. Security tools and techniques are rapidly
changing and enhancements are being made. Monitor the industry recommendations and
implement changes to security configurations as needed.
Good Practice 4: Handle sensitive data carefully.
 Confidential or private data must not be stored on end user systems without password protection
or encryption. End user systems are vulnerable to loss of data through hackers, thieves, and
accidents. Sensitive data must be secured on a database server with proper policies and procedures
in place to protect the data.
 Ensure that passwords are encrypted both inside application executables and across the transport
 Password and data encryption in databases and end user systems can be provided by third party
 A backup and recovery plan for databases and systems must be in place.
Good Practice 5: Provide measures for systems to backup their data, like zip drives, etc.
 Only non-sensitive data should be stored on a system. If possible, the authoritative source must be
on a server, and data should be replicated to the system.
 When data is stored on a system, provide easy-to-use backup facilities. Implement policies to
ensure and automate backup.
Good Practice 6: Record information about users and their connections as they update and delete
data. Auditing can determine who updated a record and their connection data.
The information that can be captured by the application includes:
 The user account the user logged in with the timestamp.
 The TCP/IP address of the connected user’s workstation
 The certificate information (if using certificates) about that user
 The old values that was stored in the record(s) before the modification
 The new values that were input to the record(s).
Good Practice 7: Implement transaction logging so recovery of original data is possible and protect
the transaction log.
 Transaction logging records activity on the database and can be used to roll back a transaction.
 Protect the transaction log through access control and backup. Only the database should be writing
to the transaction log. All other access should be read only.
 The transaction log should be located on a separate physical disk if possible. If not possible, use
RAID to protect the integrity of the log file.
Good Practice 8: Implement security scanning and intrusion detection at the database level.
 Scan the database and database server for potential weaknesses before they become a problem.
Implement any recommendations of the security management tool. For example, a tool may
advise to disable FTP services on a database server.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Monitor the database for possible intrusions. For example, monitor and alert when multiple invalid
login attempts occur. Intrusion detection protects the database server from attacks from both sides
of the firewall (e.g. internal network, WAN, or Internet).
 Audit logins, user account creation and failed login attempts.
Good Practice 9: Ensure data integrity by securing data movement or data transport.
 When high impact, sensitive data is transported through the LAN, WAN, or Internet, ensure that
the data is encrypted and protected from alterations. This can be accomplished through secured
socket layers (SSL) or virtual private network (VPN).
 Other types of data must be encrypted and protected if there is a risk of the data being altered.
Good Practice 10: Protect database servers from hardware failures and physical OS attacks.
 Database servers must be located in a climate-controlled, restricted-access facility, and preferably
a fully staffed data centre. Uninterruptible power supplies (UPSs), redundant disks, fans, and
power supplies must be used.
Good Practice 11: Protect source code in data access rules, particularly if it contains password
 On the back end, an application needs to store account and password information in order to
authenticate to a database or other application service. Protect the source code from unauthorized
 Store passwords in an encrypted format when possible.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

The solution deployment model for an agency has a direct impact on the over all cost of database
solution. The costing of the database solution is generally performed on a per processor license.
Following options exist for procurement of a database solution for an agency.

i. Database Enterprise Solution with unlimited users

The database enterprise edition offers complete suite of the database services and it is
recommended to implement the database enterprise solution with unlimited user’s option at the
data centre, which hosts the solution.

ii. Database Standard Solution

The database standard solution offers the essential database solution features for storing,
retrieving and management of the data. Deployment of a database standard edition is economic
in locations such as agencies where number of users is relatively low. For selection of a database
solution, it is essential to perform an assessment of total number of users of the solution at each
location. The agency should consider the following factors while arriving at the total number of
solution users, which is useful in performance and cost management:

 Internal users: concurrent system users within the agency

 Other users: from external service providers (e.g. integrated common service centres,
eGovernment Portal, etc.)

 Users from the other government agencies, as applicable

 Future growth in both internal and external users.

Based on the above assessment, agencies need to identify the appropriate database solution for

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Application Architecture

Software Development Methodology

This section discusses various phases of the software development life cycle and guidelines for
each of the phases. As indicated in Figure 4 below, the phases and associated activities are
iterative: for example, changes in the scope or requirements during the development phase will
necessitate repetition of previous phases. Whenever the process returns to previous phases, it
may need to do so under the proper execution of the change control procedure. A project may
cross-over into multiple phases and activities simultaneously.

Following outlines the framework for software development, which can be adopted for
development of the Information systems. Many of the activities in the process described below
may be performed by the vendor identified for solution development. While the tone of the
description in this section reflects bespoke development, the methodology can be adopted with
minor modifications to customization of existing software products too.

Figure 4 Software Development Lifecycle

Requirements Analysis
The purpose of the requirements analysis activity is to document a common understanding
between the Agency and vendor in the form of a requirements document. This outcome
determines and documents the Agency’s requirements, functions and business rules.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

i. Process
The vendor shall conduct a requirements assessment with the members of Project Management
Team (PMT)1 established by the Agency. The goal in this activity is to develop a complete and
unambiguous description of prioritized requirements that the application must address and these
requirements need to be drawn from the Agency’s IT vision, strategy and business requirements.
The PMT and the vendor need to review the completeness and applicability of the functional
requirements for the Agency in the respective state and shall finalize the proposed list of
requirements and begin to schedule requirements analysis meetings. The vendor should review,
in addition to the process description, any existing documentation about how things are done i.e.
as-is processes followed by the Agency, including data used and produced. The PMT should
provide samples of data used (input) or produced (output) to the vendor.
Using the information in the requirements document, the vendor should determine if there are
areas of overlap with the current applications used by the Agency. In these cases, integration
analysis should be conducted during the system design stage. In case an application solution
already exists in the Agency addressing a part of the envisaged requirements, a gap analysis is
required to be conducted by the vendor to identify the additional features required to be
developed. Based on the extent of the gap in the requirements, the technology used for
development of existing applications (e.g. legacy monolithic applications or two tier applications
etc), PMT shall decide to whether to develop a complete new system addressing all the
requirements of the Agency or to continue the existing systems. For Agencies continuing to use
the current application solution and developing a new solution addressing the additional
requirements, an appropriate strategy for effective integration of existing and the new system
needs to be developed (please refer section on Integration Architecture).
At this point, co-ordination/communication with applicable outside data sources or applications
sources should be established by the vendor through coordination from PMT.
ii. Activities / Tasks
 Requirements analysis and planning
 Define/update Agency needs
 Review as-is processes and current information systems
 Determine if similar applications exist and determine feasibility of integration
 Complete/update the requirements document
 Begin planning with owners of outside data sources or applications such as integrated
common service centres / eGovernment Portal. / Contact Centre
iii. Deliverables / Outputs
 System objectives
 Updated requirements definition and preliminary specifications document
 Project revision log.
iv. Validation procedures: Walkthroughs
 When the requirements document is in final draft, vendor shall distribute the document to
PMT, development team, and review team
Agencies shall identify a Project Management Team (PMT) for the successful realization of the project objectives.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Schedule a walkthrough meeting at least two working days after members receive
 Conduct walkthrough
 After walkthrough meeting, vendor shall resolve any defects with document
 Distribute final version of requirements document to original walkthrough team members
 Allow two (min) working days for approval/disapproval evidenced by an email receipt or
through any other formal approval mechanism
 If disapproval, vendor and PMT resolves issue and updates the requirements definition
 Baseline final document; update as necessary.

Systems Design / Customisation Phase

During this phase, the vendor shall use the documented requirements from the requirements
phase to define the physical design of the system. If the Agency already has application software,
which the Agency wishes to continue, the vendor shall perform an analysis of the customization
required to meet the stated requirements in the earlier phase. This outcome and a data
conversion plan are produced during this phase. After a successful walkthrough of the
design/customization document, the project moves to the development phase.

i. Process
The high-level software design/customization (high-level structure) shall be performed by the
vendor and draft user interfaces are created/customized (where applicable) and are identified in
the design document. Upon completion of the preliminary design/customization and prior to
moving to detailed design, a walkthrough of the preliminary design will be conducted by the
vendor with PMT. Based on the outcome of the walkthroughs and discussions, a detailed design
shall be performed by the vendor along with development of unit test plans.
The vendor transforms the conceptual data model created during requirements into a physical
database diagram that represents the physical tables, which will be accessed by the application.
The vendor will determine if any of the required tables already exist or if similar tables exist which
could, with minor modifications, meet the needs of the envisaged solution. If existing tables will
require modification to suit the needs of this application, the vendor shall request the changes in
writing from the personnel who are currently responsible for the tables.
ii. Activities / Tasks
 Develop/customize preliminary design
 Conduct walkthrough of preliminary design
 Develop/customize detailed design including interfaces, sub systems, database etc.
 Initiate test plan (unit, system, and acceptance)
 Conduct walkthrough of the design document
 Update project schedule.
iii. Deliverables / Outputs
 High level and detailed system design documents
 Forms and report specifications
 Draft test plan.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

iv. Validation procedures: Walkthroughs

 When the design document is in final draft, distribute the document to PMT (preferably
high level design document including interface design, report design specifications only),
selected members of the development team and review team
 Schedule a walkthrough meeting at least two working days after members receive
 After walkthrough meeting, vendor resolves any defects/changes with the solution design
 Distribute final version of design document to the original walkthrough team members
 Vendor obtains approval/disapproval evidenced by email receipt or through any other
formal approval mechanism
 If disapproval, vendor and PMT resolves issue identified
 Baseline final document; update as necessary.

Systems Development / Customisation Phase

The application units are developed, customized, tested and modified during the
development/customization phase. The other activities such as physical data structures are
created; tests of the data transition from existing systems are performed. A demonstration of the
user interface, often in the form of a software prototype, must be provided to PMT for evaluation.
In the development phase, the first draft of the application is created based on the results of
previous phases are used as input, such as the documented requirements and design. The key
outcome deliverables produced in this phase relate to the physical nature of the application.
These may include major portions of the code modules as well as technical documentation. It is
vital that the PMT is involved in this phase as the user interface and application logic are taking
shape/customized based on the requirements of the Agency(s).
i. Activities / Tasks
 Create database structure
 Finalize the data dictionary
 Research existing code modules for reusability
 Write/customize and unit test the code based on the detailed design
 Update test plan (system test, acceptance test)
 Conduct unit testing
 Document unit-testing results
 Update acceptance test approach in project plan, if required
 Prepare user manual
 Initiate customer-training plan
 Update project schedule
 Conduct walkthrough.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

ii. Deliverables / Outputs

 Tested units of code
 Technical documentation
 Unit testing results
 Updated user manual
 Finalized system test plan
 Updated acceptance test approach.
iv. Validation procedures: Walkthroughs
At any point in the development/customization process, a walkthrough of the test plan can be
performed. Typically this would occur just before the Testing Phase.
 Distribute the test plan to PMT, selected members of the development team and review
 Schedule a walkthrough meeting after members receive document
 Conduct walkthrough
 After walkthrough meeting, document author(s) resolve any defects with document
 Distribute final version of test plan document to original walkthrough team members
 Baseline final document; Update as necessary.

In absence of skilled resources within the agency, it is recommended to nominate an external

agency for providing the quality assurance and project auditing services on a continuous basis in
order to ensure that the application software developed/customized for the agency is adhering to
the industry good practices in designing, documentation, coding and testing of the solution. This
minimizes the gap in the expectations of the agency and the actual solution delivered by the

Systems Testing Phase

During this phase, the application is installed on a test platform and system level testing is
conducted. The outcomes of this phase include complete functional testing to ensure all
requirements are satisfied by comparing the requirements documented with the actual
functionality of the application. This phase also includes non-functional testing to ensure issues
such as stress; recovery; performance, and reliability are satisfied.
i. Process
The vendor shall deploy a dedicated testing team independent of the development team to
perform the testing activities of the solution. Training shall be conducted by the vendor for the
testers including PMT for performing user acceptance testing, required documentation shall be
provided to the testers. These documents should include the test plans, a place for reviewers'
comments, and a list of items to be tested. The application shall also be tested for its efficiency,
security, and integration across planned hardware platforms and adherence to documented
requirements. Major changes to the functional requirements trigger a reiteration of previous

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

phases. The phase is complete when the test team and PMT agree that the application satisfies
all documented requirements.
At the end of the test period, all test results should be signed off and documented. The test team
signs off on the test plan, indicating that testing has shown the application satisfies all
Other considerations include the details necessary for production migration; for example, dates,
file names and locations of programs that must be run. Continued coordination with database
administration staff and the customer community is imperative. In addition, the user manual and
training plan for the production system need to be completed by the vendor.
In this phase, application testing may take many forms and require different types of testing.
Some of these are discussed briefly in Table 9.

Table 9 Various Types of Software Testing

S. No Types of Testing Description

1. Alpha Testing Testing after code is mostly complete or contains most of the functionality
and prior to users being involved. Sometimes a select group of users are
2. Automated Testing Software testing that utilizes a variety of tools to automate the testing
process and when the importance of having a person manually testing is
diminished. Automated testing still requires a skilled quality assurance
team with knowledge of the automation tool and the software being tested
to set up the tests.
3. Black Box Testing Testing software without any knowledge of the inner workings, structure or
language of the module being tested. Black box tests, as most other kinds
of tests, must be written from a definitive source document, such as a
specification or requirements document.
4. White Box Testing Testing in which the software tester has knowledge of the inner workings,
structure and language of the software, or at least its purpose.
5. Compatibility Testing used to determine whether other system software components such
Testing as browsers, utilities, and competing software will conflict with the
software being tested.
6. Functional Testing Testing two or more modules together with the intent of identifying defects,
demonstrating that defects are not present, verifying that the module
performs its intended functions as stated in the specification and
establishing confidence that the solution meets the agency’s requirements.
7. Integration Testing Testing two or more modules or functions together with the intent of
finding interface defects between the modules or functions. Testing
completed at as a part of unit or functional testing, and sometimes, becomes
its own standalone test phase. On a larger level, integration testing can
involve a putting together of groups of modules and functions with the goal
of completing and verifying that the system meets the system requirements.
8. Load Testing Testing with the intent of determining how well the solution handles
competition for system resources. The competition may come in the form
of network traffic, CPU utilization or memory allocation. Load testing be

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

S. No Types of Testing Description

performed keeping in view the users external to the AGENCY such as

external service delivery channel users providing the agency’s services
through accessing agency’s application logic or data.
9. Performance Testing with the intent of determining how quickly a product handles a
Testing variety of events. Automated test tools geared specifically to test and fine-
tune performance are used most often for this type of testing. Performance
testing be performed keeping in view the users external to the agency such
as external service delivery channel users providing the agency’s services
through accessing agency’s application logic or data.
10. Regression Testing Testing with the intent of determining if bug fixes have been successful and
have not created any new problems. Also, this type of testing is done to
ensure that no degradation of baseline functionality has occurred.
11. Stress Testing Testing with the intent of determining how well a product performs when a
load is placed on the system resources that nears and then exceeds capacity.
12. Acceptance Testing Acceptance testing is generally performed the agency users with the intent
of confirming completeness with respect to the requirements outlined by
the agency and as captured and signed off in the solution requirements
specifications. Acceptance testing shall be performed by the PMT.
Agency can also consider such testing done by an independent auditor in
case the agency does not have the in house capabilities in performing such
13. Security & Testing of controls built into the application surrounding the transactions
Controls Testing (access and authorization controls), accuracy of processes (business process
controls), and data is critical.
Agency need to consider performing such testing in house or through the
acceptance testing performed by an independent auditor.

The system should be readied for implementation upon addressing all the issues identified during
the tests conducted by the vendor and the PMT (user acceptance testing).

ii. Activities / Tasks

 Migrate application to the appropriate test environment
 Conduct training for the test team and agency users or designated external agency (for
User acceptance testing)
 Provide test team with requirements specification, user manual, and test plans
 Conduct system test
 Document results of system test
 Complete user manual
 Update test plan (acceptance test)
 Finalize customer-training plan.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

iii. Deliverables/Outputs
 Successful testing with results recorded
 Updated test plan (acceptance test)
 Any required documentation as identified in project plan
 Customer training plan.

Implementation Phase
The final outcomes during this phase include production installation, acceptance testing and sign-
off, upon Go-Live of the application. All documents including user requirement definition
document, system design documents, test plans with test results, user manuals, system manuals,
training manuals etc shall be finalized for delivery to the agency. Agency sign-off of the application
and all the related documents will be obtained upon successful completion of the acceptance test.
A detailed training shall be conducted by the vendor for the identified personnel and based on the
training plan defined during the project initiation phase and during the execution. Agency shall
adopt “train the trainer” approach, which can be used to train all the agency personnel in a
phased manner. The vendor shall provide all the required documentation in support of the training
such as user manuals, training manuals, and computer based training (CBT) software etc.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

i. Activities / Tasks
 Migrate application/data to the appropriate production environment
 Implementation plan
 Implement customer-training plan
 Document acceptance test results
 Document revisions with revision log
 Obtain customer sign-off of acceptance test
 Cut-over to production
 Agency sign-off
 Conduct user training
ii. Deliverables / Outputs
 Successful acceptance test with results recorded
 Agency sign-off on project
 Training completion form
 Project closeout.

Software Change Management

During the application development phase or during the support phase, there could be several
changes to the solution arising due to changes to the business processes or incomplete user
requirements definition. It is vital to implement an appropriate change management procedure to
address such changes to the system. It is recommended, during the development and post
development, to implement separate instances of the application in the form of development, test,
pre-production and production systems. Any changes to the production systems need to be
forced through the change management process through appropriate approvals from both the
agency and the management of the vendor.
Following outlines the broad change management process, which can be tailored to the
requirements of individual agencies.

S. No Description
1. A change control board (CCB) need to be constituted by the agency with the members from both
the agency and the selected vendor for the project for evaluating and ensuring the successful
implementation of the change to the system.
2. A standard template need to be designed i.e. change request form (CRF) for submitting change
requests for the system.
3. Each change request need to be evaluated by the CCB for applicability and feasibility and shall
accept or reject the change request.
4. Any change request to the solution, irrespective of source of the request, shall be recorded in the
change request log (CRL) by the vendor. The CRL shall capture the change request id, raised date,
raised by, description, size of change, effort, accepted/rejected/on hold, status etc.
5. For each change request an impact analysis shall be carried out by the vendor and the detailed
results of the impact analysis shall be submitted to the CCB. The impact of the changes in terms of

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

schedule, effort and cost are identified and estimates shall be recorded.
6. Based on the impact of the change, change request details including the impact analysis results
shall be submitted to change control board (CCB) as identified for the project. The
approval/disapproval shall be recorded in the change request form.
7. Upon receiving the approval from CCB, the schedule and resources for implementing the changes
shall be planned by the vendor.
8. Upon implementation of the change, the CCB validates the changes to make sure that the change
implementation is properly performed.
9. Upon completion of changes and relevant tests, a sign off need to be obtained from the CCB for
migration of changes to the production environment.
10. Appropriate version management procedures need to be followed before implementing the change
into the production environment.

Software Configuration Management

As the development of the application solution progresses with additional functionality and
features, it becomes increasingly important to effectively manage and control the version
management and distribution management. This section discusses important aspects of
managing the software configuration.
A system is a collection of components organized to accomplish a specific function or set of
functions. The configuration of a system is the function and/or physical characteristics of
hardware, firmware, software or a combination thereof as set forth in technical documentation
and achieved in a solution. Configuration management (CM), then, is the process of identifying
the configuration of a system at distinct points in time for the purpose of systematically controlling
changes to the configuration and maintaining the integrity and traceability of the configuration
throughout the system life cycle. CM is the process of applying technical and administrative
direction and surveillance to identify and document the functional and physical characteristics of a
configuration item, control changes to those characteristics, record and report change processing
and implementation status, and verify compliance with specified requirements.
i. Tool Selection and Implementation
Different types of tool capabilities, and procedures for their use, support the SCM activities.
Depending on the situation, these tool capabilities can be made available with some combination
of manual tools, automated tools providing a single SCM capability, automated tools integrating a
range of SCM (and, perhaps other) capabilities, or integrated tool environments that serve the
needs of multiple participants in the software development process. Automated tool support
becomes increasingly important provides support for:
 the SCM Library,
 the software change request and approval procedures,
 code and change management tasks,
 reporting software configuration status and collecting SCM metrics,
 software auditing,
 performing software builds, and

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Version management including managing and tracking software releases and their
Agencies shall implement the SCM solutions and use of tools in these areas increases the
potential for obtaining product and process measurements to be used for project management
and process improvement purposes. Through the use of SCM tools and enterprise management
system (EMS), agencies can ensure that the same version of the software is being deployed
across all the locations in the state.

The EMS selected for software distribution shall support the following requirements at a
 The software distribution function should provide flexible and scalable delivery,
installation, and configuration of software.
 The software distribution should support customizable distribution schedules, alternate
methods, heterogeneous network protocols, diverse operating systems including UNIX,
and both push and pull distribution modes.
 Compression should be supported while distributing the software across WAN.
 Furthermore, its integration with the event management functions of the EMS should
provide complete tracking logging, automated correction of failures during the delivery
and installation process. In addition, its integration with the security functions of the EMS
should enable administrators to deliver software with peace of mind.
 It should be possible to store images of the servers and desktops and restore images
from the image server. It should distribute the image to the desktops/Servers by using the
booting from image floppies.

Designing and developing Applications

Recommended good practices applicable to designing and developing of applications
Good practice 1: Design for the N-tier service oriented architecture

 While many of the problems inherent in the monolithic and two-tier applications can be overcome
by implementing applications with a three-tier architecture, large, complex projects that are
anticipated to have high usage volumes and/or long life spans will be better served by an N-tier
service oriented architecture.
 N-tier applications are easily modifiable to support changes in business rules.
 N-tier applications are highly scaleable.
 N-tier architecture offers the best performance compared to any other application architecture.
 Any combination of user interfaces (e.g., character, graphical, web browser, and telephone
interfaces) may be implemented in an N-tier application.
 N-tier applications are less expensive to build and maintain because most of the code is pre-built
and shared by other applications.

Good practice 2: Generalize application interfaces

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 The code providing input and output to the user interface should be designed to provide input and
output to as wide a range of interfaces as possible. This should include other applications as well as
other types of user interfaces.
 Do not assume that application components will always be accessed via a graphical user interface
(or any other user interface).
 Avoid assuming a specific page size, page format, layout language or user language whenever

Good practice 3: Assign responsibility for business rules to agency / sub-units

 Assign responsibility for defining and maintaining the integrity of business rules to agency / sub-
 IT staff is responsible for coding and administering the software that implements business rules in
the network.
 The agency / sub-units are responsible for the definition and integrity of business rules, and for
communicating changes in business rules to IT.
 Every business rule should be assigned to a custodian.

Good practice 4: Make business rules platform-neutral

 Implement business rules in a non-proprietary, cross-platform language.

 This approach provides platform independence and portability.

Good practice 5: Implement business rules as discrete components

 Implement business rules as discrete executable components or services.

Good practice 6: Access data through business rules

 Design applications so business rules control access to data.

 Data is created and used by government processes. In computer applications, data must be created,
used by, and managed by the application component that automates the government process.
 Accessing data in any way other than by government processes bypasses the rules of the module
that controls the data. Data is not manages consistently if multiple processes or users access it.
 Centralised data should be used wherever possible to assure data accuracy and simplify data

Good practice 7: Adopt coding standards

 Adopt coding standards, in all languages, on all platforms.

Coding standards makes debugging and maintenance easier and hence should address (but not
be limited to):
 Naming conventions for variables, constants, data types, procedures and functions
 Code flow and indentation
 Error and exception detection and handling

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Source code organization, including the use of libraries and include files
 Source code documentation and comments
 Even the earliest code developed in a project should adhere to the standards

Suggested standards pertaining to application design and development include:

Standard 1: Develop 3-tier or N-tier applications

 All new agency applications should be developed using 3-tier or N-tier architecture in order to
maximize flexibility and scalability.
 Large, complex projects that have high usage volumes and/or long life spans will be better served
by N-tier service oriented architecture.
 Logical separation of the tiers for user interface(s), business rules, and data access code allows for
simple, straightforward additions to each of the three tiers without undue impacts on the others.
 Logical separation of the tiers also allows for changing the platforms where the tiers are deployed,
resulting in a high degree of scalability. As transaction loads, response times, or throughputs change,
a tier can be moved from the platform on which it executes to another, more powerful platform - or
be spread over multiple machines - without impacting the other tiers.
 While many of the problems inherent in the existing monolithic and two-tier applications can be
overcome by implementing applications with three-tier architecture, the goal should always be true
to implement N-tier applications.
 The maximum benefits of an N-tier architecture are realized when many N-tier applications are
deployed across the emirate, sharing common software services and offering multiple user
 Large, complex projects that are anticipated to have high usage volumes and/or long life spans will
be better served by implementing applications with three-tier architecture with access to N-tier
service oriented architecture.
 With three-tier client / server applications, there is less risk in modifying the code that implements
any given business rule.
 Three-tier client / server applications can be made to support multiple user interfaces: character,
graphical, web browser, telephones, and others.

Standard 2: Isolate customizations to purchased software

 Isolate customizations into separate modules from the purchased software itself to improve the
ability to upgrade and move to new releases as required over time. For purchased line-of-business
applications, loosely couple custom developed modules from the standard application software.

Standard 3: Avoid Common Gateway Interface (CGI) for business logic or to publish information to
the web

 CGI does not scale, is not portable and is not easily integrated with application servers. Avoid use of
CGI for information publishing, back-end applications or data access.
 Publishing information to the web with HTML or XML via java servlets reduces overhead and
works in conjunction with EJB-based components.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 The use of ASP or other HTML publishing is acceptable for publishing only (not business logic) but
JSP and servlets are preferred.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Application and Portal Servers

Application and portal servers will form an important component of the overall IT Architecture of
the eGovernment programme, considering the portal based delivery strategy for eServices. This
section gives an overview of application and portal servers, key elements of an application
platform suite which would assist in designing the IT architecture for various eGovernment
An application server is a software layer immediately above the operating system that provides
shared services and functionality for component-based applications, primarily those developed to
the Java 2 Enterprise Edition (J2EE) specification or using the Microsoft .Net Framework. An
enterprise portal server is a collection of server-based software components that run on the
application server and produce, in a browser based windowing environment, modular Hypertext
Mark-up Language (HTML) representations of applications running on the application server.
The two types of application servers are Microsoft Windows, which has its own Component
Object Model for application development, and those that adhere to the J2EE specification.
These platforms are used both for creating interactive public Websites and for building thin client
applications for use inside the enterprise.
Microsoft and vendors of J2EE application servers—including BEA, IBM, Oracle, and
Sun—sell suites of servers that are essentially collections of components that run on the
application server. These components include an integration server, which enables applications to
connect with applications running on other platforms, and the portal server, which is the group of
components that handle the generation of HTML pages.
The portal server enables rapid application development, so thin client user interfaces can be
quickly created to provide access to business logic running on the application server. Portal
servers can also be used to enforce a consistent user interface, so that modular regions of portal
pages generated by portlets present application functionality with a similar look and feel. As with
such consumer portals as My Yahoo, users can add, delete, or rearrange portlets to meet their
needs. Moreover, administrators can use portals as an enterprise gateway, so that when a user
signs on to a portal, that user’s identity and access rights yield an individualized mix of
information and applications.
Vendors’ application server suites are becoming more integrated, which encourages customers to
buy application, integration, and portal servers from a single vendor. This integration manifests
itself in vendor-specific development tools, which enable programmers to draw upon the vendor-
specific features of various servers in the suite that might otherwise need to be built from scratch.
Because such integration shortens development time, this trend is expected to continue.

Elements of an Application platform Suite

Leading vendors, such as IBM, BEA, Microsoft, Oracle, and Sun, now provide their own portal
servers and integration servers on top of their application servers, along with an IDE for
programmers to create component-based applications. (In Microsoft’s case, Windows serves as
both the application server and the operating system.) Enterprise customers can now purchase a
complete set of servers from a single vendor (see Figure 5) Gartner has termed this set of
servers the application platform suite.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Figure 5 Application Server Suite

With Microsoft’s solution, all elements of the suite necessarily come from a single vendor; unlike
the Java community, Microsoft has not published a license-free application server specification
that third parties could implement. But compliance with the J2EE specification among J2EE
application server vendors guarantees at least a modicum of mix-and-match portability, and
enterprises can theoretically build an infrastructure by combining the best servers from different
From the viewpoint of enterprise customers, the leading value propositions of the application
platform suite are simpler, integrated development and deployment frameworks, integrated
systems management, and a lower overall cost of ownership.
An integrated suite can also increase productivity in the design and implementation of software.
Developers’ incorporation and testing of integration capabilities during application development
rather than adding integration later results in faster deployment and more capable applications.
Each of the top five application server vendors—BEA, IBM, Microsoft, Oracle, and Sun— sell
suites that include all servers spanning the entire range of functionality shown in Figure 5. In most
cases, the degree of integration among these layers is rudimentary, but the intent is clearly to
increase integration over time to enhance the functionality offered by the suite and to simplify
application life cycle management.
The following are brief descriptions of each element in the suite.
Portal Server
Portal servers generate Hypertext Mark-up Language (HTML) pages that display within a
browser-based user interface, much like an enterprise version of My Yahoo. By drawing on
business logic running on the application server, portal servers can expose the functionality of
enterprise applications running on various platforms and from a wide variety of other sources
(including Websites, e-mail stores, and document repositories). As a window on the enterprise,
portals offer powerful opportunities to improve productivity, streamline processes, and link
information, resources, and users, particularly when the mix of applications and information is
tailored based on user identity. Most portal servers also come with collaboration capabilities, in
which groups of enterprise users can set up ad hoc intranet sites to share information.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Integration Server
An integration server is a framework and toolset that establishes communications among
applications, which can extend to transaction and business process management. Typically,
integration servers come with components that act as configurable application adapters. These
translate the native APIs and events of packaged applications and database management
systems (DBMSs) into a common syntax and format used by components that handle message
routing and coordination. Integration servers designed as part of an application server suite tend
to lack the advanced features of dedicated enterprise application integration (EAI) software,
particularly those relating to long-running processes. But application server vendors continue to
add more advanced capabilities with every revision.
Identity Server
This server layer provides a framework that enables access control, directory services,
application provisioning, user profile management, and encryption. Identity servers help
organizations manage secure access to Web- and non-Web-based applications on both the
enterprise network and on extranets. Functionality such as single sign-on improves the user’s
experience by eliminating the need for multiple logins using different sets of usernames and
passwords to access multiple resources. Identity servers provide centralized administration of
identities, policies, and services using standards based or vendor-specific authentication
Development and Deployment
All major application server vendors now provide the means for creating and customizing
applications, including programming languages, development frameworks, IDEs, and modelling
tools. IDEs provide the support for the complete edit-compile-debug cycle, as well as full project
management support. IDEs can help developers build applications at all levels in the suite
(integration applications, Web services, security applications, and enterprise portals) with a single
tool. In addition, J2EE IDEs may provide access to proprietary server APIs, which deprive
applications of portability among application servers but provide convenient access to pre-built
functionality. There is a clear trend toward higher-level tools specific to a particular vendor’s suite,
such as BEA’s WebLogic Workshop for building Web services.
Application Server
As the fundamental platform on which application software components execute enterprise
business logic, the application server manages and runs software components— enabling
reliability, availability, and scalability through load balancing, connection pooling, system
monitoring, and other features. Application servers act like operating systems for enterprise
applications, providing shared services related to connectivity, transaction processing, and other
capabilities so that individual applications (and the developers who write them) do not have to. In
addition, application servers provide tools for deploying and managing software components.
Application Server Features
On the Java platform, application server features fall into two broad categories: those that are
specified by J2EE and those that are vendor-specific. Such distinctions do not apply to the
Windows platform, because Microsoft both designs the specification and provides the only
implementation—thus it can add or subtract features without considering compatibility with
anything other than previous software versions. Nonetheless, the types of components and
services offered by J2EE and Microsoft .Net are quite similar:

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Components—In J2EE application servers, most work is done by Enterprise JavaBeans

(EJB), which contains the business logic behind more complex Web applications. Java
servlets generally provide functionality for interactive Web pages, while JavaServer
Pages (JSP) build on the servlet model to make dynamic Web page features easier to
program. On the Microsoft side, Component Object Model (COM) components handle the
business logic, while Active Server Pages (ASP) provide the vehicle for building and
deploying interactive Web pages.
 Application integration—In server suites from both Microsoft .Net and J2EE vendors,
integration servers provide connectivity to packaged applications, as well as message
brokering and process integration features. (Microsoft actually offers two integration
servers: its Host Integration and BizTalk servers. The latter relies heavily on Extensible
Markup Language [XML] data transformation.) But application servers themselves also
offer basic integration functionality. With .Net, developers are encouraged to use Web
services to integrate components running on the application server with other enterprise
applications. J2EE servers also provide Web services tools, but another technology, the
Java Connector Architecture (JCA), enables developers to build adapters that can
connect with most other applications.
 Database connectivity—Java developers use the Java Database Connectivity (JDBC)
specification to enable applications to access relational databases. Microsoft has ActiveX
Data Objects (ADO) .Net, which also provides access to relational databases, but adds
the capability to perform XML data interchange as well.
 Messaging—On an application server, messaging capability is supplied primarily for
communications with conventional message-oriented middleware. In the Java world,
Java Messaging Service (JMS) does the job; on .Net, it is Microsoft Message Queue
Server (MSMQ). In addition, both platforms enable developers to implement Simple
Object Access Protocol (SOAP) messaging, which provides the envelope for Web
services messages.
Another important development in application servers is the ability to expose software
components as Web services without requiring developers to write XML code or have a detailed
knowledge of such Web services specifications as SOAP or Web Services Description Language
(WSDL). Microsoft .Net places easy development and deployment of Web services at the centre
of its value proposition for developers.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Managing Applications
Due to the emirate’s dependency on computer applications, applications must be managed as
carefully as any other business-support infrastructure. Application management is a necessity, not
an option. Application management requirements are as important to the enterprise as an
application’s functional requirements. Therefore, management requirements for an application
should be documented during the requirements phase of the project.

Recommended good practices pertaining to managing applications include:

Good practice 1: Design for end-to-end management

 Manage the application as a whole entity by managing every component of the application and
everything each component depends on. Application developers must instrument every component
of the application to facilitate its management.
 Application dependencies include infrastructure (e.g., middleware, databases, and networks), other
applications, and shared software components. Application teams must specify these dependencies
when an application is deployed.

Good practice 2: Design for proactive – rather than reactive – application management

 Proactive application management supports the business better. With proactive management,
applications report potential problem conditions at predefined thresholds, before errors occur. This
gives system administrators the opportunity to take corrective action to prevent an application from
 While applications can be managed by administrators responding to errors, ideally management is
automatically undertaken by SNM tools, and is proactive.
 Use thresholds to provide early alert to possible error conditions. For example, rather than sending
an alarm when an application fails because its database table is full, send an alarm when the table is
90% full, so corrective action can be taken to prevent a business-impacting outage.
 Reactive application management is better than no application management at all. Reactive
management is when administrators respond to errors and outages reported by applications after
they have occurred.

Good practice 3: Instrument applications to report the information necessary to manage them

 Applications should report status, performance statistics, errors, and conditions. Status events that
an application should report to users (e.g., erroneous input), to application managers (e.g., database
table 90% full) and to both (e.g., can’t find needed file) are to be decided during design.
 Operations staff must be provided procedures for dealing with all conditions that are detected and
reported. For example, if an application reports it can no longer access its database, operations staff
must have instructions for handling the situation. At the time of design, decide the specific reporting
requirements of an application module. Different applications may have different management
needs, depending on their respective impact on the business the applications support.
 Applications should only report. Interpreting the reports and deciding on the appropriate response

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

should be performed external to the application

 Application reporting should include run-time tracing to assist trouble-shooting operational
problems. Tracing should be able to be turned on and off by administrators.

Good practice 4: Instrument applications to facilitate administration

 Instrument applications to receive and process commands from administrators.

 Design applications to read and respond to commands from system administrators. Commands may
include, but are not limited to, shut down, shutdown and restart, reconfigure, and turn tracing on or
 Make application configurations parameter-driven, so applications can be reconfigured without
recompiling and redistributing code.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Component ware Architecture

Component Reuse
A successful implementation of an N-tier, reusable component service oriented architecture is not
solely dependent on the ability to develop reusable components. Success also depends on the
ability to provide the tools and management of the components for reuse. Following a reuse
methodology and understanding reuse techniques are critical to developing and managing
government-wide reusable components.

Recommended good practices pertaining to reusable components include:

Good practice 1: Establish a reuse methodology for the identification and implementation of

 A methodology that supports reuse contains following steps:

 Classify business requirements by service type (e.g., application, interface, support, or core).
 Search repository for reusable components that support business or functional requirements.
 Analyze candidate components to ensure they fully meet requirements.
 Incorporate selected components into new or re-engineered application using standard IDL’s.
 Harvest new components from new or existing applications that have not been componentized
yet by placing new component information into the repository.
 Incorporate reuse methodology into the system development life cycle.
 To successfully implement component ware architecture, the network and middleware
architecture must be in place.

Good practice 2: Establish a component review board to identify common components

 Components used by multiple agencies / sub-units must be commonly understood and consistently
referenced by all users.
 Component development can be achieved through the context of projects.
 The review board should start with small, achievable, and strategic projects.
 In order to create reusable components, cooperation is needed among the process owners.
 A framework needs to be put in place that allows for:
 Centralized management of reusable, shareable components.
 Design reviews of new and existing projects for reusable components.
 Enterprise access to information about reusable components.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Good practice 3: Establish a repository for maintaining the information about available reusable

 The repository provides a place to store documentation about the component API’s.
 The repository should be made available to all application developers as a tool for performing their

Good practice 4: Every component must have a published API

 A published API defines the public interface for a component or service. The API is how other
applications will communicate with the component. Documentation should include input and output
parameters, which parameters are required, which parameters are optional, and the lengths and types
of the parameters.
 The API should be entered into the component repository that is available to all application

Good practice 5: Harvest components from existing applications to initially build the component

 Legacy applications are a good resource for building a component repository.

 There is no need to reinvent a process or piece of functionality if software already exists that
performs the desired function.
 If feasible, develop a wrapper that defines the API for the service and allows the legacy application
to become a reusable component.

Suggested standards pertaining to component reuse include:

Standard 1: No vendor proprietary API calls for infrastructure security services - use GSS-API or
CDSA-compliant API calls and products

 Applications requiring security services prior to CDSA products or services being available can use
the GSS-API.
 GSS-API is an Internet Engineering Task Force (IETF) standard (RFC 2748, released in January
2000, obsoletes RFC 1508 and RFC 2078) and supports a range of security services such as
authentication, integrity, and confidentiality.
 It allows for plug-ability of different security mechanisms without changing the application layer.
 It is transport independent, which means it can be used with any underlying network protocol.
 Applications using GSS-API can be retrofit to a CDSA foundation without major modifications,
therefore providing an interim step to CDSA based services.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Component Services
A service completes a task requested by an application. The service itself may call one or more
components to complete the task. To the calling application, however, it appears as a single task.
Typically, a service is created when it is identified as a common task that would be (repeatedly)
coded by several applications.

Recommended good practices pertaining to component services include:

Good practice 1: Component services should be callable by any component-based application or any
other component

 Components must be designed and developed with the understanding that the process that invokes it
may or may not be developed in the same language or in the same environment.
 A component should be callable from any supported language on any supported platform.

Standards pertaining to component services include

Standard 1: Custom developed application components must be written in a portable, platform-
independent language, such as C, C++, or Java

 Application components written in a portable language are easier to move from one platform to
another because they require fewer modifications to conform to the new host.
 This portability allows an application to be more adaptive to changes in platform technology.

Standard 2: Government-wide infrastructure services must be at least CDSA version 2.0 compliant

 The CDSA v2.0 architecture is an open group specification for providing security services in a
layered architecture and managed by a Common Security Services Manager (CSSM). CDSA
provides a management framework necessary for integrating security implementations. Version 2.0
of the specification is a cross-platform architecture, which includes a testing suite for inter-
operability testing.
 A wide range of vendors has announced support for the specification and products for a broad set of
platforms can be expected.
 Security protocols such as SSL, S/MIME, and IPSec can all be built from the CDSA base.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Object-oriented Components
Object-oriented components encapsulate both business logic and data accessed by business
logic. They have the potential to become intelligent, self-managing entities, allowing for more
simplified management.

Recommended good practices pertaining to object-oriented components include:

Good practice 1: Government’s application developers should develop enterprise components using
EJB-based object technology - Agencies should enter an appropriate object-oriented analysis and
design lifecycle prior to the implementation

 Object-oriented programming starts with the definition of objects and hence analysis and design is
 Object-oriented design and development is well understood by many developers and the software
industry often provides solutions based on objects rather than APIs.
 EJB together with servlets hide most of the required infrastructure service requirements
programming for web-based applications. Where sharing of services is desirable, agencies can
offload the burden of such programming and can focus on the business logic rather than
communication code.

Suggested standards pertaining to object-oriented components include:

Standard 1: Purchased applications must be CORBA 2.0 or later and IIOP compliant

 CORBA and IIOP standards are open standards devised for platform independence.

Standard 2: Build or purchase enterprise solutions on an EJB, servlet model and application servers
should be compliant with EJB 1.1 or better

 Enterprise solutions benefit from reduced requirements to code underlying services and can focus
on business logic.
 Vendors provide solutions based on an EJB model. These solutions can be purchased and used
without customization.

Standard 3: Avoid OLE / DCOM and the windows DNA object model for applications with enterprise
or strategic implications

 OLE / DCOM standards do not scale well and run only on windows platforms.
 OLE / DCOM applications are not easily portable or integrated into enterprise-wide solutions.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Application Communication Middleware Architecture

Application Communication Middleware

Recommended good practices applicable to application communication middleware types
Good practice 1: When possible, design applications to use asynchronous communication

 Message-oriented middleware supports asynchronous communications.

 Asynchronous messaging requires a distinctly different design. It is implemented with a very basic
set of message oriented middleware commands.
 Message-oriented middleware provides a reliable form of communication.
 Asynchronous communication offers more flexibility than synchronous communication. The
downstream application has more control over its operation.

Good practice 2: Use RPCs when message-oriented middleware is not available

 RPCs provide an acceptable, albeit limited, method of communication between software

 RPCs require synchronous communication and are less efficient in the use of resources; they tie up
resources from both the client and the server until the service has been provided.
 Synchronous communication requires error handling in the client application if the request is made
while a server is unavailable.

Application Communication Middleware Brokers

For communication external to the application or access to common services, another technology
component called a “broker” is required to establish the relationship between the applications.
This broker performs the same function as a real estate broker or stock broker - brings parties
together. Brokers are built on top of other communications middleware (e.g., RPC and MOM).

Implementing an Object Request Broker (ORB) would very likely require a significant investment.
An ORB solution would require integrating message-oriented middleware, communication
protocols, or operating systems in order to provide a complete, government-wide solution.

Service brokers are a proven technology. However, there are no industry-standard service broker
products available. Successful implementations of service brokers usually require the interface to
be developed specifically for the organization. Like other organizations using a service-oriented
architecture, the emirate must invest in the development and maintenance of the service broker’s
generic interface.

Since object technology promises the greatest gains in productivity and adaptability, the emirate
will ultimately transition software development to a fully object-oriented approach. Requests for

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

service will be conveyed by an ORB. In the meantime, the emirate will use a service-oriented
architecture, with requests conveyed by a service broker.

To assure their long-term contribution to Emirate, it is important that services developed to

support the service-oriented architecture be designed in such a way that they can be accessed
via either a service broker or an ORB.

The recommended good practices in this section pertain to application communication

middleware brokers.

Good practice 1: Manage a emirate-wide broker as a strategic infrastructure component

 Service broker is a critical part of the distributed computing environment because it allows the
technical architecture to meet the three goals of efficiency, sharing of information and agency
 Strategic infrastructure benefits all agencies and should be centrally managed.

Good practice 2: Be sure a Emirate-wide broker is independent of code development tools

 The purpose of service broker is to facilitate communication in a multi-platform, multi-language

environment. If the service broker is tied to a single vendor’s product, then the goal of facilitating
communication in a diverse environment has not been met.
 Implementing a service broker that supports multiple vendors’ products helps protect the Emirate
from being negatively impacted by market forces.
 A best-of-breed approach should be taken when selecting the application communication

Good practice 3: Develop inter-application middleware, the service broker interface, for inter-
application communication between agency-developed applications - for interfaces with other
applications, such as purchased packages or applications owned by other entities, use the interface

 Developed applications gain performance and flexibility by using service broker for inter-
application communication.
 In-house or out-sourced custom-developed applications requiring inter-application communication
should be capable of using a service broker. Applications sharing or requiring services from external
application systems should provide capability to use the standard inter-application communication
middleware architecture.
 In instances where the application code cannot be modified, such as purchased applications where
the Emirate does not have rights to source code, use interface engine.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Network Architecture

Local Area Network (LAN) Architecture

Recommended good practices assist government personnel in planning, design,
implementation and expansion, administration, maintenance, and support of LANs. They
are based on experience and proven results. They employ standards and practices
designed to support a uniform LAN.
Good practice 1: Networks must be positioned for future growth in traffic and expansion of services
such as voice and video

 The increasing investment of funds in network infrastructures dictates that the life span of each
additional component or enhancement be as long as possible. This can be accomplished if the
design supports current needs but includes an anticipated growth potential. For example, installing
Category 5 cabling today to run a 10 Mbps network positions a site to upgrade to a 100mbps speed
in the future without replacing the cabling.
 As businesses expand, networks expand. A flexible, open network design will allow a business to
minimize the costs and disruptions of configuration management while providing timely and
responsive network changes when and where required.

Good practice 2: Configure all servers supporting mission critical applications, including desktop
applications, to minimize service interruption

 Select a computer constructed to perform as a highly available, highly reliable, fault tolerant server
with such features as redundant disk arrays, network cards, power supplies, and processors.
 Select a server with sufficient growth capacity to accommodate the anticipated increase in
application requirements over time.
 Formalize security, disaster recovery, and backup procedures to ensure the integrity of both the
server and the application. Test those practices on a regularly scheduled basis.

Implementation guidelines for LAN architecture include:

Guideline 1: Configure the topology (physical wiring) in a star pattern

 Star topology uses a central hub/switch to which each network device is connected.
 Problems with a connection in a star network only affect that one device.
 A star topology provides the capability to easily add and remove devices as necessary.
 A star topology responds well to dynamic infrastructure changes in order to meet the growing
demands of data movement. With ever increasing demands of information movement, more data,
secure paths, new paths, and faster access, a star topology allows different, changeable, connections.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Guideline 2: Use switched multi-segment design with managed hubs

 The hub is an ideal point for network management due to its central location and because all
network traffic flows through it.
 Network switches provide the ability to break a network up into smaller sub-network segments.
 Switches can be used in conjunction with hubs. They improve LAN performance. With switching,
network traffic is balanced across multiple segments thus reducing resource contention and
increasing throughput capacity.
 Switching allows networks to assign increased speed or performance capability to particular
segments in order to respond to heavy usage or application requirements.

The following standards have been established to assist agencies in the implementation of
LANs. The goal is to employ only open systems based on industry approved standards,
but a full complement of open standards does not yet exist for all components of LANs.
Therefore, a combination of industry standards, de-facto industry standards, mutually
agreed upon product standards, and open standards are currently required to support the
Emirate’s heterogeneous operating environment. All standards will be periodically
Standard 1: LAN cabling standard

 The standard for LAN cabling is Category 5, 6, or 7 Unshielded Twisted Pair (Cat 5 UTP, Cat 6
UTP, or Cat 7 UTP). Unless specific needs exist, such as high EMI or long distances, UTP should
be considered for the horizontal runs in cable layouts.
 CAT 5/6/7 UTP can be certified to carry 10/100/1000 MBPS of data.
 It is an industry standard wiring plan and has the support of the IEEE.
 Wiring, cable, connector, and equipment vendors have standardized on this cabling.

Standard 2: Standard for link layer access

 The standard for standard link layer access protocol is Ethernet, IEEE 802.3 CSMA/CD access
 Widely accepted format.
 Reliable, the protocol has been used for years and is very stable.
 Scaleable, faster versions are currently emerging to help manage the increase of data flow.
 1000BaseT Gigabit Ethernet has the bandwidth necessary to support the needs of future voice
and video requirements.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Network-Centric Applications
This section describes recommended good practices for planning, designing, and managing
applications and application components in a networked environment.

Good practice 1: Include network expertise on the requirements and design teams

 Including network expertise ensures correct planning, documentation, and standard practices
are followed.
 Requirements definition should include application performance, as well as capacity planning
for network usage (based on the predicted number and size of transactions).
 Define any special networking requirements or constraints and perform the associated network
design before development tools are selected. Otherwise, the tools used may not support the
network architecture required to support the business.
 The network can be modified (upgraded) while applications are under development.
Performance and the cost to move information should be balanced during application design.
Multiple perspectives of a cross-functional group can ensure all viable options are considered.

Good practice 2: Design network-neutral applications

 Isolate the application code from the network specific code so business rules and data access
code can be redeployed on a different platform, if necessary.
 Code to a middleware API, not to the network API.
 For a network to remain scaleable and portable, applications must be developed without regard
to the type of network (i.e. WAN or LAN) they are to be deployed on.
 Network-specific design (e.g., wireless or guaranteed high-bandwidth) should only be
performed when business requirements dictate.

Good practice 3: Minimize data movement

 When possible, schedule heavy network use for off-peak hours. For example, where
requirements for data freshness permit, perform database synchronization at night.
 Data warehouses typically are used for decision support applications requiring large amounts of
data to be transferred through the network.
 When replicating databases, consider partitioning and distributing subsets, rather than
duplicating the entire master database.
 Decoupling the application layers provides the most efficient use of network resources by
allowing the data access layer to be placed near the data.

Good practice 4: Consider the impact of middleware on network utilization

 Perform all transaction commits locally, between the resource manager and the queue.
Asynchronous store and forward messaging can limit the scope of a transaction.
 Decouple transactions as allowed by business rules. Reconcile data at low-cost times.
 Using store and forward, work can occur at a site even if the network link is down.

Good practice 5: When data has to be distributed to multiple points (e.g., software and content

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

distribution), move it once and only once across each data link

 Use push technology, rather than using client polling. It overloads servers and network links to
 Use multicast, rather than broadcast, to distribute messages to multiple points.

Good practice 6: When designing distributed applications, make no assumptions about the speed of
the network on which the application will be deployed

 Since bandwidth is unpredictable at design time:

 Minimize the amount of data to be moved between components. This will enhance
performance regardless of the speed of the network on which the application is deployed.
 Use asynchronous rather than synchronous communications between application
components (except in cases where business rules require synchronous communications).
This will prevent application components waiting for a response from a server.
 For users and application requests that may be intermittently connected, use store-and-
forward messaging to communicate with application components.
 When multiple, independent units of work must be performed, initiate all so they can be
performed in parallel, rather than waiting for the completion of one before initiating the

Good practice 7: Perform performance measurement and load testing on distributed applications
before deployment

 Measure application performance often, especially before and after any component is moved to
a different platform. This helps quantify the performance impact of the redeployment, and helps
isolate any problems associated with a network link or platform.
 Use load testing tools that simulate many users accessing the application. This testing method
will provide information that will not surface during single user test scenarios.
 Load testing will identify network bottlenecks (and application bottlenecks) before the
application is deployed in the production environment.

Good practice 8: Deploy heavily used data sources “close” to the applications using them

 “Close” does not imply physical proximity. It means deployed on platforms that have high-
bandwidth connections between them. Do not perform heavy data movement across the WAN
during peak hours.
 One of the biggest cost factors in designing a network is transmission of data over the
communications system.
 For applications requiring very large amounts of data movement, try scheduling execution of
these queries to run during off peak hours to minimize impact on network performance.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Implementation guidelines include:

Guideline 1: Use asynchronous rather than synchronous communications between application

components (except in cases where business rules require synchronous communications)

 Asynchronous communications will allow faster application processing, because the

application is not waiting on a server response.
 Asynchronous communications will allow applications to be used on “slower” WAN links.
 Work can occur at the application site even if the network links is down.

Guideline 2: Where business rules allow, use off-peak hours for scheduled data transfers

 Allows better utilization of network resources.

 Keeps large data transfers from impacting normal operations and WAN/LAN traffic.
 Will allow commits of a day’s worth of work to be processed at one time increasing server

Guideline 3: Code applications to middleware APIs where there are no specific business requirements.
(e.g., wireless)

 Makes application network neutral.

 It isolates the application code from the network specific code so business rules and data access
code can be redeployed on different platforms, if necessary.
 Allows networks to remain scaleable and portable.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Integration Architecture

Application Integration
An approach to integrating independently developed applications, such as legacy applications,
purchased applications, and new client/server systems is through application integration.
An application interface can provide the following services:
 Data translation and mapping – Application integration interface translates different
communications and data interchanges between two applications.
 Transaction explosion – If configured properly, an application integration interface can
take one client transaction and spawn multiple transactions in remote applications.
 Front-ending other applications – An interface can provide a single front end for
integrating multiple application systems.

Recommended good practices pertaining to application integration include:

Good practice 1: Use application integration strategy for Online Transaction Processing (OLTP)
application systems, not Decision Support Systems (DSS)

 Data warehouses or other solutions should be used in decision support applications.

Good practice 2: Design an integration solution that does not write directly to an operational database

 Existing application logic or business rules should be used when updating an application database.
An external user or application could inadvertently corrupt operational data.

Good practice 3: Recommended priority of using components of application integration are interface
engine first, middleware systems second, direct program-to-program interface as third and last

 This will reduce integration effort substantially.

 The recommendation assumes that all three alternatives are applicable in a given situation.

Good practice 4: Use direct program-to-program interfaces for high transaction volumes

 Direct program-to-program interfaces pass only the required information between applications, so
performance and throughput is at the optimal level.

Good practice 5: When designing an application integration solution using an interface engine, give
careful consideration to the design and planning of the application interfaces and connectivity

 At the beginning of the design stage, involve application developers who are knowledgeable in the
business rules and interfaces to each system that needs to be accessed.
 Some application systems may have multiple entry or exit points that can be used. If a non-invasive
solution is selected, capitalize on using the entry or exit points that best apply to your application

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Suggested standards pertaining to application integration include:

Standard 1: Clearly define application interfaces

 To integrate applications for which the Emirate has no source code rights, application interfaces
must be clearly defined in order to allow reliable communication between applications.
 To facilitate purchase of best-of-breed software while easing application integration issues, the
application interfaces must be clearly defined.

Standard 2: Message structure must be documented

 A message or transaction is the mechanism for extracting data from an application or sending data
to an application.
 Programmers integrating applications need to know record length and type (i.e., whether it is a
variable or fixed length record, and if it’s variable, the delimiting characters used to separate the
fields), and know which fields are optional versus required.
 A description of the data for each field is also necessary.
 Explanations and examples of record formats and field descriptions are helpful and should be

Standard 3: Application must be able to transmit and receive messages using a client/server model

 Client is the process that sends or originates the message. Server is the process that receives the
 Clients and servers may communicate using TCP/IP and sockets, or other communication protocols,
such as serial and ftp, as long as they perform the same transmit and receive functionality.
 Packetization characters, which identify start and end block strings, and message acknowledgment
format, must also be provided.

Standard 4: Purchase line-of-business application software rather than custom developing it whenever

 Purchasing line-of-business application software can permit the Emirate to respond to business
needs in a timelier manner than custom developing software.
 Published API’s are insufficient because their use requires custom development of applications and
it may be impossible to interface two purchased applications. Use of an interface engine provides
greater flexibility.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Data Access Integration

Data access is the accessing and sharing of data between legacy, new, and packaged
applications. It can be accomplished through several types of data access including data
extraction, data replication, and data sharing.

Recommended good practices pertaining to data access integration include:

Good practice 1: Use as few middleware layers as possible when implementing a database gateway

 Additional layers of middleware in between an application and the database gateway could hinder
performance of mission critical applications. For example, an application that needs to access a
database gateway can implement an ODBC middleware layer that ultimately accesses the gateway
middleware. Application performance can be increased if the application was written to make direct
calls to the gateway middleware, omitting the ODBC layer.
 If there are fewer middle conversion tiers, there are less operational layers to maintain in the event
of maintenance or upgrades. For example, if there is a change to an application database location, or
an upgrade or maintenance update to the middleware software, it can affect all end user
workstations and servers that access that application.

Good practice 2: Keep the integration strategy as simple as possible

 The more complicated the strategy, the more difficult it is to maintain and change.

Good practice 3: Code data integrity verification rules into the DBMS whenever possible, particularly
when external users and programs will be writing data directly to the DBMS

 Since most DBMS vendors can code triggers and rules into the database, it is recommended to use
this technology wherever possible in order to ensure data integrity.

Good practice 4: Separate DSS from OLTP databases, whenever feasible

 If this practice is feasible, it will reduce the impact of ad hoc and large queries from decision
support systems onto production operational application databases that are used by online users for
day-to-day operations.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Once the best method for data access has been selected, the following implementation
guidelines may apply:
Guideline 1: Implement a hub topology as opposed to distributed data access topology, whenever

 The distributed data access topology is where each point-to-point connection makes sense by itself,
but the infrastructure as a whole is a “tangled” mass of connections.
 The star or hub technology is less complex and easy to maintain.

Guideline 2: Use a database gateway technology to combine queries of SQL data with non-SQL data

 A gateway allows an application to query legacy data.

Guideline 3: Do not use any vendor specific extensions when using a database gateway that uses SQL

 Use the industry standard of ANSI Standard SQL.

Guideline 4: Once the database gateway product is selected for use as an integration tool, use the
gateway from the central IT location whenever possible, particularly in situations where the
requirement is to access application data from the central systems/locations

 Expertise is centralized so application developers do not have to duplicate efforts and relearn the
gateway technology in each agency. The agencies also do not have to retain personnel with gateway
expertise in addition to hardware and software experts to maintain the system.
 Security is centralized and controlled in a unified manner for all agencies. With centralized security
administration, the effort to limit access to authenticated users of an application is reduced.
 Dedicated gateway servers can be used that are easily administered, monitored and controlled,
which facilitates performance monitoring, error recovery and disaster recovery.
 The Emirate has to establish a central license agreement that would simplify addition of users and
allows agencies to share the cost of gateway more economically.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

XML (Extensible Mark-up Language) has developed as the de-facto standard for business to
business exchange of data on the internet. It is extensible because it allows users to define their
own data and document types. It is a mark-up language like HTML. A mark-up language is a
mechanism used to identify the structure. The language requires special markers called tags to
be added to text documents to give some added meaning to the document.

Recommended good practices for XML include:

Good practice 1: Choose XML as a preferred mode for all application integration for new systems,
wherever possible

 It is a global standard, meaning that tools and solutions to be used for developing applications will
either be complying with it already or will comply in their future releases.
 This will significantly reduce the cost and effort for building and maintaining interfaces between
applications when compared with similar non-standards based tools.
 Apply the normal cost/benefit analysis criteria while using XML.

Good practice 2: Developing the DTD / schemas can be a top down as well as a bottom up approach

 Some of the DTD / schema can be defined based on metadata. However, while developing and
implementing other applications, a number of DTD / schemas are likely to be defined and can be
made available. These can be added to the standard DTD / schemas.

Implementation guidelines can include:

Guideline 1: Check available / accepted schemas before developing them bottom up

 Globally, a number of initiatives are underway towards defining DTD / schemas. These are initiated
by various industry groups and address industry specific need for exchange of information.
Considerable effort can be saved if some of these schemas can be found to be deployable by the
Emirate, either as-is or with some modifications.

Guideline 2: Develop organisation and associated processes for developing and maintaining Emirate-
wide DTD / schemas

 Developing DTD / schemas and maintaining them, updating them in view of changing needs of the
Emirate will be an ongoing process that will require constant monitoring
 Compliance and enhancements can be enforced better if the responsibility is centralised by the
creation of a repository and an organisation to maintain it.

Guideline 3: Rely on the network other security infrastructure for building and enforcing necessary
secure environment for exchange of data

 The XML standard addresses data transformation only. Hence, it relies on other systems for security

Guideline 4: Monitor developments on the XML standards development forums

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 A number of initiatives are underway on the standards development front. By closely monitoring
them, it will be possible to incorporate expected changes into future plans of the Emirate.

Guideline 5: Clearly define and publish DTD / schemas

 This will facilitate their use and re-use.

 Give reference to those DTD / schemas which have been developed based on any other globally
defined schema, since this will allow incorporation of future changes.
 Wherever the DTD / schemas apply for intra-ministerial application, and are not expected to be
shared in the public domain, adequate care needs to be taken in publishing them.

Common XML Protocols

XML is supported by a set of protocols that enable developers to read and manipulate documents
in a consistent manner. These methods also allow comparison and translation of elements in
different XML documents using schema.

XML Path (XPath): The XPath specification provides a way to address objects in an
XML document hierarchy by creating a tree of element nodes and a Uniform Resource Identifier
(URI) addressing scheme. (Every file accessible over the Internet has a URI; the most common
example is the Uniform Resource Locator [URL] for Web pages.) XPath’s pattern-matching
syntax is used by other XML extensions, such as XPointer and Extensible Stylesheet Language
Transformations (XSLT), to locate and identify data.
XML Pointer (XPointer): XPointer helps applications break XML documents into addressable
segments. XPointer uses XPath to identify a data node in an XML document and select it for
processing. Because XML documents can become large and unwieldy, XPointer can be used to
search for data based on specific criteria to yield a subset for processing.
XML Linking (XLink): XLink offers a standard way to create and describe links among resources
in XML documents, similar to hyperlinks used in HTML. For example, XLink can be used to
declare link types and enforce the order in which they can be traversed.
Extensible Stylesheet Language Transformations (XSLT): The XSLT specification defines an
XML-based language that can be used to map data elements between different XML documents
or between XML documents and other document types such as HTML. XSLT is most commonly
used to convert XML documents into HTML documents, but it is also widely used to convert one
type of XML document into another type.

For XML Security protocols refer following section on Services Oriented Architecture.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Related Information – Organisation for the Advancement of Structured Information Standards
that creates XML standards and – Source of information on XML standards, schemas, tools – Information on XSL – Source for work on business reporting using XML – Source of information on HR-related XML schemas

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Services Oriented Architecture

Web services definition - IBM’s definition of web services states that “web services are self-
contained, modular applications that can be described, published, located and invoked over a
network generally, the World Wide Web”.

To enable the program-to-program communications that are the essence of Web services,
additional XML-based specifications are needed to define the services, the interfaces to the
services, and the mechanisms for finding and invoking the services (see Figure 6).

Figure 6 Web Services Protocol Stack

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Figure 7 SOA: Foundation standards overview

The three key Web services standards are the Simple Object Access Protocol (SOAP), the Web
Services Description Language (WSDL), and Universal Description, Discovery, and Integration

SOAP: SOAP is an XML-based protocol for document-based messaging and remote procedure
calls across distributed computing environments. SOAP-based messages are transport
independent: designed for use over HTTP, SOAP also can be used with other transport
mechanisms, such as the Simple Mail Transfer Protocol (SMTP), that may be required when
traversing corporate firewalls. SOAP is used by applications to invoke remote object methods and
functions using an XML request that is routed to a remote SOAP server, typically over HTTP.
When remote execution completes, an XML-formatted response is returned to the calling
application. A SOAP message has three sections: a general message container, called an
envelope, that is used to specify the encoding style of the message data; the body containing the
actual message data; and an envelope header designed to carry additional transaction specific
information, such as authentication, routing, and scope detail.

WSDL: WSDL is an XML Schema used to describe a Web service’s abilities, grammar, and
communication interfacing requirements. It provides an abstract description of the characteristics
and capabilities of a given Web service. This includes the specific data types used and the
methods implemented by the Web service and the ports and specific Internet addresses for
accessing and receiving messages. WSDL lays out the ground rules for developers who seek to
build applications that make use of a particular Web service, providing a blueprint that describes
how applications can interact with the Web service. The protocol is analogous to the Interface
Definition Language (IDL) used to define distributed services in Common Object Request Broker
Architecture (CORBA) development and is capable of describing both procedure- and document-
oriented information that can be mapped to any language, object model, or messaging
infrastructure. Simple extensions to existing Internet infrastructure enable Web services to

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

interact directly with an application developed using CORBA, COM, JMS (Java Message
Service), or COBOL, as well as with a Web browser.

UDDI: UDDI is a directory services protocol, first developed by Microsoft, IBM, and Ariba, for
classifying, cataloguing, managing, and querying Web services. It is the basis for a telephone
directory-like listing in which Web services are advertised, discovered, and engaged
programmatically. A UDDI directory has three parts: the White Pages list company-specific
information on the services provider; the Yellow Pages provide details such as industry codes,
functionality, and location-based data; and the Green Pages contain the WSDL for each service.
UDDI was conceived with the expectation that it would lead to the creation of directories through
which services could discover each other without manual intervention, enabling on-the-fly
integration. In practice, UDDI has been best used inside enterprises, where Web services are
being used to enable application integration or private e-marketplaces. UDDI Version 2 was
approved as an OASIS standard in April 2003 and Universal Description, Discovery and
Integration v3.0.2 (UDDI) was approved as an OASIS standard in February 2005.

Additionally the Reference Model for Service Oriented Architecture 1.0 – was approved as an
OASIS Standard on 12 October 2006. This Reference Model is an abstract framework for
understanding significant entities and relationships between them within a service-oriented
environment, and for the development of consistent standards or specifications supporting that
environment. It is based on unifying concepts of SOA and may be used by architects developing
specific service oriented architectures or in training and explaining SOA.

Security Protocols
The need to secure XML and Web services applications and architectures requires provisions for
authentication, message integrity, and confidentiality. These security functions may need to span
several parties inside or outside the enterprise in the course of executing a single, long-running
transaction. Similar technologies, such as electronic data interchange, use value-added networks
and virtual private networks to ensure security, but Web services’ provision for transport over the
Internet by means of HTTP requires a new set of specifications for securing transactions.

The basic Web services building blocks—SOAP, WSDL, and UDDI—do not address security. By
design, XML is a human-readable protocol, so the data being transported in an XML-based SOAP
message is also readable. It is possible to encrypt a complete XML document, confirm the
sender’s authenticity, and test the integrity of the document, but the methods available cannot
contend with high-level document processing.

Therefore, authentication and non-repudiation need to be applied on a fine-grained basis that

potentially involves many users across disparate organizations in situations in which it may be
necessary to encrypt and authenticate a transaction in arbitrary sequences. In addition, the ability
to provide identity management capable of spanning multiple organizations will be essential to
high-level business-to-business transactions.

At present, there are several fundamental XML-related security mechanisms available, including
Security Assertion Markup Language (SAML), XML Signatures, XML Encryption, XML Key
Management Specification (XKMS), and XML Access Control Language (XACL). In addition,

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Microsoft, IBM, and VeriSign jointly published WS-Security 2, and submitted it to the Organization
for the Advancement of Structured Information Standards (OASIS) for ratification as a standard.
The specification describes a set of techniques for protecting the confidentiality of data that would
enable developers to make the exchange of SOAP messages more secure. Additional building
blocks based on WS-Security have also been released that include provisions for broader
security using trust and policy mechanisms.

General XML Security

SAML: OASIS has ratified SAML 2.0 in March 2005, providing a specification for an XML-based
security framework able to create a federated network for interoperation across distributed hosted
services and Websites. SAML 2.0 provides secure interchange of authentication and
authorization information by using Transport Layer Security (TLS) with existing core Web services
standards such as XML and SOAP. SAML also offers suggestions and best practices for the use
of XML Signatures and XML Encryption with SAML messages. SAML’s benefits include single
sign-on, which is the ability to authenticate once and then allow access to other resources with
similar authentication requirements. SAML 2.0 includes a profile for ECP: Enhanced Client or
Proxy. This requires a client similar to the Windows CardSpace Identity Selector.

SAML was developed by OASIS’s Security Services Technical Committee, with contributions from
IBM, HP, BEA, Sun, VeriSign, Netegrity, RSA Security, and public key infrastructure companies
Baltimore and Entrust. Initially, there was concern that the SAML specification might vie with WS-
Security, which is backed by Microsoft and IBM. However, the two specifications are quite
complementary, and vendors are committing to SAML for forthcoming Web access management

XML Signatures: The W3C and the Internet Engineering Task Force (IETF) developed XML
Signatures, a set of rules and syntax for XML digital signature processing; it was approved as a
W3C recommendation in February 2002. XML Signatures describes methods of digitally signing a
document; it does not address the process of actually obtaining keys, leaving specifics like
cryptographic strength and key negotiation to the implementing infrastructure. XML Signatures
helps secure compound SOAP documents that contain data from multiple sources and often
require multiple, non-inclusive signatures, without breaching the validity of security in document

XML Encryption: XML Encryption is a specification for the actual encryption of XML document
data; it was approved as a W3C recommendation on 10 December 2002. Also in 2002,
companies such as RSA Security introduced integrated software development kits that enabled
digital signatures and data encryption within XML documents for deployment in Web services

XML Key Management Specification: XKMS defines how Web services can register and
manage cryptographic keys used for digital signatures and encryption of inter-application
communication. Drawing on early work by both the XML Signatures and XML Encryption working
groups, Microsoft, VeriSign, and webMethods submitted the XML Key Management Specification
for the W3C’s consideration in the first quarter of 2001. Combined with a Web services security
framework, such as WS-Security, XKMS helps make it possible to deploy Web services securely

Draft specification for Web services security, in the second quarter of 2002

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

on the Internet. XML Key Management Specification (XKMS 2.0) Version 2.0 was approved as a
W3C Recommendation on 28 June 2005

Extensible Access Control Markup Language: Extensible Access Control Markup Language
(XACML) defines management policies that restrict access to distributed resources based on
submitted credentials. XACML would be an appropriate mechanism, for example, to manage
access to sensitive product data in collaborative commerce applications like supply chain
management. XACML 2.0 and all the associated profiles were approved as OASIS Standards on
1 February 2005. In addition to providing a specification, XACML includes a suite of tools that
assist developers with interoperability and compliance testing. XACML overlaps many of the
capabilities being proposed by the WS-Security models described in the following section.

Web Services Security

Microsoft, IBM, VeriSign, and RSA Security developed the Web services security protocols
discussed in this section. The other protocols described here build on WS-Security.

WS-Security: WS-Security stipulates a set of enhancements to the SOAP messaging protocol

intended to protect message integrity, confidentiality, and authentication. Building on XML
Signatures and XML Encryption, WS-Security further outlines how digital credentials and their
associated trust semantics can be securely associated with SOAP messages. Building on
SOAP’s existing transport capabilities, WS-Security defines methods for embedding
authentication, encryption, and security directly into the message to provide an end-to-end
security solution for the life span of a message. Designed to be extensible, WS-Security can
accommodate a broad range of security models delivered in a transport-neutral manner. The
specification also outlines a framework for XMLbased tokens and key encryption and describes
how to encode binary security tokens such as X.509 certificates and Kerberos tickets. WS-
Security is a working draft. Web Services Security v1.1 was approved as an OASIS standard in
February 2006.

WS-Trust: The WS-Trust specification was released as a public draft by Microsoft, IBM, and
VeriSign in the fourth quarter of 2002 as an extension to WS-Security. The specification’s
extensions facilitate the request and issuance of security tokens in the management of trust
relationships. WS-Trust’s goal is to allow applications to build trust mechanisms directly into the
exchange of SOAP messages between Web services providers and consumers. The specification
does not define an explicit security protocol, as it is designed to support a range of protocols. WS-
Trust works in conjunction with other protocols in the security stack, such as WS-Security and
WS-Policy, to ensure that a service requester is properly authenticated and granted appropriate
resource access. WS-Trust 1.3 has been released as an OASIS Technical Committee Draft on 06
September 2006.

WS-SecureConversation: WS-SecureConversation builds on WS-Security to provide secure

communication. The specification defines mechanisms for deriving and passing session keys, as
well as for establishing and sharing security contexts. Microsoft, IBM, VeriSign, and RSA Security
released the initial working draft of WS-SecureConversation 1.0 in the fourth quarter of 2002.
Further WS-SecureConversation 1.3 was released as an OASIS Technical Committee Draft on 06
September 2006

Web Services Policy Framework (WS-Policy): WS-Policy provides a model and an XML
expression syntax that allow Web services providers, partners, and consumers to define rules of

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

information privacy and usage. WS-Policy works in conjunction with the WS-Security
mechanisms to enforce access and usage rights to Web services and is defined for use and
discovery through WSDL and the UDDI repository. The WS-Policy specification relies on
additional policy building blocks, such as the Web Services Policy Assertions Language (WS-
Policy-Assertion), which provides a common language for representing individual requirements
and preferences, and the Web Services Policy Attachment (WS-PolicyAttachment), which defines
three different attachment mechanisms (that is, methods of associating policy definitions with
WSDL and UDDI entities). Developed by Microsoft, IBM, BEA, and SAP, the WS-Policy draft was
released in the fourth quarter of 2002. Currently Web Services Policy 1.2 - Framework (WS-
Policy) is a public draft release and is provided for review and evaluation only by W3C.

Business Process Protocols

In addition to security protocols, a number of groups are working on business process protocols
to improve XML and Web services communications capabilities and interoperability. Business
process protocols are designed to manage multipart business processes, such as long-running
transactions that occur between trading partners that last hours, days, or months. These
processes require a reliable means of tracking to ensure they are dependably managed and
processed to completion. In addition, lowlevel business process protocols are being proposed
that describe the details of Web services messaging behavior under a variety of conditions.

As with security protocols, proposed business process standards can be divided into two groups:
protocols concerned directly with the enablement of Web services and general XML protocols.
The trend in business process standards for Web services is toward a modular, interlocking set of
protocols, with each protocol addressing a specific function. The more ambitious XML business
process protocols, such as Electronic Business XML (ebXML) or the Business Transaction
Protocol (BTP), tend to be complex specifications that address broader functionality.

Web Services Process Specifications: So far, Web services have been used primarily for
simple point-to-point application integration. Process integration, which requires that messages
be exchanged among applications according to a set of predefined business rules in situations in
which it can’t be assumed that participating applications are always available, requires a more
complex set of specifications. Most of these draft specifications have been proposed by IBM and
Microsoft and their allies, but some have been proposed by Sun and its allies. In some cases,
such as that of WS-Reliability and WS-ReliableMessaging, the standards from these two camps
compete directly. More often, they overlap and may someday be used as complements to one

WS-Coordination: Introduced by IBM and Microsoft in August 2002, the WS-Coordination

specification describes an extensible framework of protocols designed to help coordinate
distributed Web services applications. WS-Coordination is particularly useful when multiple
organizations or services are involved in the completion of a complex task.

The protocol offers a standard means of ensuring that simultaneous transactions execute
correctly across disparate systems. Developers can drill down into a transaction and monitor and
manage the operations as they relate to a particular business activity. WS-Coordination also
enables Web services applications to negotiate the terms of agreement among participants on
the fly and without human intervention.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Web Services Choreography Interface (WSCI): WSCI is intended to pick up where WSDL
leaves off, providing a specification for the construction of detailed self-descriptions of how
individual Web services behave when exchanging messages. It can also describe the flow of
messages exchanged by a group of Web services. BEA Systems, Intalio, SAP AG, and Sun
codeveloped the WSCI 1.0 specification, which was submitted to the W3C in mid-2002. Microsoft
had not yet joined the W3C’s WSCI working group.

WS-Transaction: WS-Transaction describes the specific options available to coordinate

distributed processes, such as those outlined by WS-Coordination, to ensure consistent outcome
and to shape the workflow process. Drawing on work BEA has done on the Business Transaction
Protocol, WS-Transaction was introduced in draft form by IBM, Microsoft, and BEA in August

WS-Transaction supports two types of transactions: atomic transactions (ATs) and business
activities (BAs). ATs provide an all-or-nothing approach to a transaction, allowing participants to
be notified of a transaction’s status at various checkpoints and providing for rollback if the entire
transaction does not complete successfully. BA participants are notified of progress and will
receive an error message in the event of failure, but transactions are committed immediately
without the possibility of rollback. WS-Transaction ensures non-repudiation and integrity of a Web
services transaction; the transaction occurs only once and is properly compensated in the event
of an error. The specification does not dictate a specific transaction protocol, allowing flexibility
in deployment.

Business Process Execution Language for Web Services (BPEL4WS): BPEL4WS provides a
structure for the formal specification of business processes and business interaction protocols.
BPEL4WS supports complex transactions, ensuring that disparate business processes are able
to communicate effectively. The specification defines a method for automating business
processes based on collections of Web services interfaces that can be combined in sequence
and bundled to create complex containers of reusable business workflows.

BPEL4WS represents an amalgamation of Microsoft’s XLang for BizTalk Server and IBM’s Web
Services Flow Language (WSFL), which are used to model services orchestration and data flow
using conditional triggers and routing controls. XLang and WSFL have been superseded by the
BPEL4WS specification.

WS-Routing: WS-Routing (formerly SOAP-RP) defines a format for describing the path of a
SOAP message, from the original sender through a variety of intermediaries to the final recipient,
including the return path. WS-Routing allows intermediaries to distribute messages to multiple
destinations and, as required, to build complex workflows. WS-Routing encapsulates the routing
parameters within the header of the SOAP message, so they are unaffected by any underlying
transport protocols.

WS-Referral: WS-Referral works with WS-Routing to optimize delivery of SOAP messages in

real time by altering a message’s path. By enabling message paths to be dynamically
reconfigured using if-then rules, WS-Referral ensures that information is delivered efficiently and
reliably to the best SOAP node for processing.

WS-Reliability: The WS-Reliability 1.0 specification was released and presented to OASIS in the
first quarter of 2003 by Sun, Fujitsu, Hitachi, NEC, Oracle, and Sonic Software. Further WS-
Reliability v1.1 was approved as an OASIS standard in November 2004. The SOAP based

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

protocol provides guarantees that messages will be delivered between endpoints in the proper
order and without duplication. WS-Reliability borrows from the ebXML messaging service to
address requirements for reliable messaging over HTTP. There is some functional overlap among
WS-Reliability, Reliable HTTP (HTTPR), WSCI, and BPEL4WS.

WS-ReliableMessaging: Introduced by BEA, IBM, Microsoft, and TIBCO, WS-

ReliableMessaging competes directly with WS-Reliability. (It was proposed a month after the
latter’s introduction.) WS-ReliableMessaging ensures that messages will be delivered between
distributed applications without fail, even if network or system failure intervenes. It is expressly
designed to work in concert with other WS messaging protocols backed by IBM and Microsoft.

Xml Process Schemas and Specifications: XML business processes may address horizontal
processes, including pricing, billing, and shipment confirmation, as well as processes within
vertical industries, such as the processes developed by RosettaNet for the IT and electronic
components industries.

Electronic Business XML (ebXML): ebXML was developed as a joint effort of OASIS and
United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) in 1999. The
ebXML initiative provides standards for XML-based communications capable of automating many
details of a trading relationship. ebXML outlines methods for defining and registering available
business profiles in a centralized registry. Similar to UDDI, ebXML includes profiles, agreements,
and core components necessary to participate in the exchange of XML-based Web services.
Going beyond the capabilities of UDDI and other serviceoriented standards, ebXML enables
companies to define specific business roles, relationships, and responsibilities during Web
services transactions. Entire messaging workflows can be described to interpret real-world
transaction scenarios, allowing detailed routing between services, sequencing of complex
payloads, and insurance against transactional repudiation.

In the fourth quarter of 2002, the ebXML Collaboration Protocol Profile and Agreement (CPPA
2.0), a key component of ebXML for automating partner agreements, was ratified as a standard
by OASIS. ebXML has gained support from companies such as TIBCO, Sun, and SAP and is one
of the messaging profiles supported by the Java API (application programming interface) for XML
Messaging (JAXM).

BizTalk Framework3: BizTalk Framework is a set of publicly available XML Schemas for
modelling business-to-business processes. Made available as part of Microsoft’s BizTalk Server,
it allows automation of process integration among business and trading partners. The public
availability of the XML Schemas makes it possible for anyone to communicate using these
protocols, regardless of whether Microsoft infrastructure is deployed. BizTalk Framework specifies
encryption and security, attachment handling, routing, and non-repudiation. Using the BizTalk
Framework’s visual modelling tools, developers can connect existing applications to Web
services, as well as link disparate Web services.

Business Process Modeling Language (BPML): BPML, a metalanguage for modelling

business processes, has been under development since August 2000 and has the backing of
BEA, EDS, IBM, SAP, SeeBeyond, Sun, webMethods, and other prominent business integration
and enterprise software vendors. BPML represents business processes as a matrix of control

BizTalk™ and Biztalk Framework™ are registered trademarks of Microsoft Corporation.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

flow, data flow, and event flow processes. It also specifies parameters for business rules, security
roles, and transaction procedures.

RosettaNet PIP: RosettaNet, a consortium of more than 400 companies, has developed a set of
processes and standards for conducting electronic business transactions. Developed for use as a
vertical XML Schema for the computer industry, the RosettaNet Partner Interface Process (PIP)
defines standards for conveying information such as order and inventory management to allow
inter-business communications along supply chain channels.

Business Transaction Protocol (BTP): BTP was developed by an OASIS committee in

conjunction with Bowstreet, Interwoven, and Sun to provide a two-phase commit procedure to
ensure that all necessary endpoints and systems among trading partners are updated
appropriately during the course of any transaction. BEA has implemented BTP in its WebLogic
platform. BTP offer capabilities comparable to those found in developing standards such as WS-
Coordination, WS-Transaction, and BPEL4WS. OASIS announced the approval of its Business
Transaction Protocol Version 1.1 as a Committee Draft in December 2004. BTP Version 1.1
represents a revision of the Version 1.0 specification in the light of feedback and implementation

Universal Business Language (UBL): UBL is an XML Schema-based library of standardized

business documents such as purchase orders and invoices. Universal Business Language (UBL)
v1.0 was approved as an OASIS standard in November 2004. UBL follows in the footsteps of
electronic data interchange by attempting to simplify document communication among
organizations and providing a launching pad for XML usage in the enterprise. 4

Web Services Conversation Language (WSCL): WSCL complements the service descriptions
of WSDL with essential elements to describe the flow of a business process between partners.
WSCL adds to the specifications held in a UDDI registry to provide additional business process
information, such as the document formats available for exchange and the specific sequence of
transactions required to complete an activity. WSCL’s choreography capabilities overlap those of

Industry- and Process-Specific XML Vocabularies: XML’s growing acceptance has produced a
flurry of activity in the development of industry-specific DTD and schema definitions. These
standardized vocabularies are essential to ensuring transactional integrity within the business
processes of vertical industries they’re designed to serve. Although it is not a comprehensive
survey of all current activity, Table 10 illustrates the variety of efforts under way.

Table 10 Industry- and Process-Specific XML Vocabularies

Vocabulary Description
Commerce XML cXML is a specification that provides basic consistency in
communication of business documents between procurement
applications, e-commerce hubs, and suppliers.
Financial XML FinXML is a framework for data interchange between capital
markets. It is interoperable with existing financial protocols such
as FIX and SWIFT Net and with standards such as BizTalk and
Further Universal Business Language Naming & Design Rules v1.0 (UBL NDR) was approved as an OASIS standard in January

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Financial Information FIX is a protocol-messaging standard for real-time electronic

Exchange exchange of securities transactions.
Financial Products Markup FpML is a business information exchange standard for
Language processing and dealing in financial derivatives instruments.
Human Resources HRMML is a standard suite of XML specifications for human
Management Markup resources-related data exchanges, including benefits enrolment,
Language staffing, resume processing, and general employee profiling.
Interactive Financial IFX is a specification covering the exchange of bill presentment
Exchange Forum and payment, credit card statements, direct debits, and other
information between financial institutions and their suppliers
and customers.
International XML Retail IXRetail is a digital receipt schema for standardizing sales
Cooperative transaction information, including point-of-sale, inventory, and
customer service channels.
Legal Information LegalXML specifications cover electronic court filing, court
Exchange documents, legal citations, transcripts, and criminal justice
intelligence systems.
Market Data Definition MDDL is a standard interchange mechanism for trading and
Language market-related information, including economic and social
Mortgage Industry MISMO data standards cover credit, underwriting, mortgage
Standards Maintenance insurance applications, and real estate service request processes.
Open Financial Exchange OFX is a retail-oriented specification for the electronic
exchange of financial data between financial institutions,
businesses, and consumers over the Internet.
Real Estate Transaction RETML is a standard for exchanging real estate transaction
Markup Language information.
Research Information RixML is used to categorize, aggregate, compare, sort, and
Exchange Markup distribute global financial research.
Extensible Business XBRL is a specification for the publication and exchange of
Reporting Language companies’ financial reports.
XML Common Business XCBL business documents are made available as a set of SOX
Library (Commerce One’s Schema for Object-Oriented XML).
XML Payment XMLPay is a specification developed to help Internet merchants
Specification process a range of Web-based payment types, including
credit/debit card, purchase card, and automated clearinghouse
payments for business-to-business and business-to-consumer e-

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Information Security Standards and Guidelines

Identification is used to distinguish one user from all others. Identification techniques provide a
means of gaining entry to agency / government resources such as workstations, networks and
applications. Identification is closely linked to authentication. Authentication is the process of
verifying the identity of a user and is covered in the following section.

The most commonly used form of identification is a user-id. A user-id is associated with a
password to identify and authenticate a user. Techniques to improve the security of user-ids and
passwords have been developed. These techniques include smart cards, biometrics, tokens etc.
Several identification techniques can be combined to increase the level of security. Today’s
environment is primarily based on user-id identification and password authentication.

Authentication is the act of verifying the identity of a user or process. Authentication answers the
question: “Are you who you say you are?” The most common method used to authenticate a user
is a password. A password is a secret series of characters and numbers associated with an
individual user id by the owner/user.

A sign-on process to authenticate the user accepts a password and a user-id. The sign-on
process matches the password given, with a stored password for that user. If they match, the
system has verified the user's identity. Passwords are inexpensive and widely integrated into
today’s systems. Passwords have various weaknesses. User passwords are often poorly chosen
and present a danger of passwords being intercepted and read over unsecured communication

Electronic business transactions have stricter requirements on uniquely identifying and

authenticating the sender or recipient of electronic information. These can be satisfied with a
‘digital signature,’ which is the equivalent of a handwritten signature. Authentication techniques
such as public key certificates have been developed to address the strict authentication
requirements of electronic business processes. This technology is based on cryptography, which
is discussed later in the section. The implementation of digital signatures for online or real-time
transactions needs to be based on the guidelines defined in the eTransactions Law 2003 (and
related Bylaws) and further amendments, if any.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Recommended Good Practices for User Identification and Authentication Services

The recommended good practices in this section pertaining to security authentication are
given below:

Good Practice 1: Authenticate users prior to accessing services.

 Access to the application systems and the supporting IT Infrastructure should not be provided
without user authentication.
 Authenticating users provides accountability for the transactions/activities performed within the
Good Practice 2: Use Public Key/Private Key technology for authenticating the users for providing
access to the sensitive transactions
 Agencies need to perform a risk assessment of the services/transactions processed using the
Information Systems.
 For the critical and sensitive online transactions (e.g. submission of tender response in e-
procurement), PKI based authentication shall be used.
 Digital signatures are most useful for transactions requiring high degree of authentication and
 Agencies can also consider the usage of digital certificates/biometrics for authentication of users
performing critical transactions in the system (e.g. for performing changes to the tax related values
(master tables in the system), PKI/biometrics based authentication can be used).
Good Practice 3: Use token-based or strong password based authentication where public key
certificates are not feasible.
 Token-based systems are an improvement over passwords.
 Where token-based identification and authentication is not possible, a password policy based on
best practices can provide an acceptable level of security.

Implementation Guidelines for Authentication Services

The implementation guidelines in this section pertain to security authentication. Guideline 1: Make use of strong user id and password controls for Information Systems.
 Access to the information systems of and agency without a user id and password should be
 Each access request to the Information systems need to be routed through the designated authority.
User ids shall be created and activated in the system only upon receiving a formal approval from
the relevant authority. A standard user id creation/deletion form and procedure should be
implemented to ensure that relevant approvals and documentation is maintained for each user id
created in the system.
 Strong password usage is a minimal requirement for authentication.
 The password controls shall at a minimum include:
o Passwords must be a minimum of eight (8) characters in length, non similar to the user id and
be comprised of letters, numbers, and special characters to the extent possible
o Users with access to information classified as “SECRET” must have passwords that are a

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

minimum length of ten (10) characters and conform to password standards

o Users must be forced to change passwords every sixty (60) days. System Administrators must
enforce this through technical means by configuring password aging on systems. Where
technically possible, user-ID access must be disabled upon sixty (60) days of inactivity. In
addition, user account lockout features need to be implemented to disable the user id after three
unsuccessful login attempts
o Where technically feasible, new users must be forced by the system to change their initial
password to one that meets password guidelines
o Where technically feasible, systems must use password history techniques to maintain a
password history of users. These forces users not to re-use passwords repeatedly when
forced to change the password. The password history file must be stored in an encrypted
form. The history file must contain the last six (6) previous passwords of users, and store them
in encrypted form
o Passwords must not be visibly displayed on the screen when being entered and must be stored
in encrypted format only.
o All computers, databases or applications that store user-ID and password information must be
secured in the strictest manner. Access to the user-ID tables must be restricted to authorized
persons only
o All default passwords supplied by vendors must be changed following the installation of the
o Passwords related to the administrator user/super user id shall be only with the system
administrators and should not be distributed to the general users. Guideline 2: Make use of industry products for applications requiring public key certificate
 Widely accepted products are available for public key authentication.
 Web-based applications are the best-understood uses of certificates.
 Certificates for Web applications are provided by a number of major vendors.
 Use of proprietary certificate extensions must be avoided to ensure later inter-operability.

Authorisation and Access Control

Authorization answers the question: “Are you allowed to do what you are asking or trying to do?”
Requirements for use and prohibitions against use, of resources vary widely across the agencies.
Some information may be accessible by all users, some may be accessible by several groups,
and some may only be accessible by a few individuals. Access to applications, the data they
process and database modifications must be carefully controlled. Authorization is the permission
to use an information resource. Access is the ability to do something with an information
resource. Access controls are the technical means to enforce permissions. They allow control
over what information a user can use, the applications they can run and the modifications they
can make. Access controls should be built into the application software used by the agency,
operating system and can be implemented in add-on security packages that are installed into an
operating system. Access controls can help protect:
 Application software from unauthorized access to the business functions and the related

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Operating systems and other system software from unauthorized modification and
thereby help ensure system integrity and availability
 The integrity and availability of information by restricting the number of users and
processes with access
 Confidential information from being disclosed to unauthorized individuals. Authorization
and access control can be applied internally to the agency’s information systems. They
can also be used to protect agency-information systems from unauthorized external
access. Internal authorization and access control are implemented:
o At the platform
o To stored information
o To information in transit
o For distributed applications.

In the application software, access to perform the business processes/transactions shall be

provided based on the role and responsibilities designated for the employee. The application
software should facilitate for controlling the access for the agency employees and other users of
the system to the individual modules/functions in the modules based on the designated role. Such
access to the module/transactions shall be provided through an approval process, which shall be

Internal Access Control

Internal access control protects information from access points internal to the agency. Internal
access control applies at points in an agency where potential damage may occur. This ensures
the agency’s ability to perform its functions by allowing only authorized access to the information
infrastructure. The internal access control shall address the following:
 Access to the application software should be restricted to only authenticated and
authorized users
 Direct access to the backend database should be restricted to only the authorized
 Access to the servers operating systems/data and other supporting infrastructure such as
routers, switches, firewalls in an agency should be restricted only to the authorized

External Access Control

External access controls are a means of controlling interactions between agency information
resources and outside people, systems, and services. External access control should permit
authorized remote access by employees of the agency, citizens, and external service providers to
the agency information systems. External access control must also ensure that confidential
information transported outside the agency is protected from unauthorized access. External
access controls use a wide variety of methods including physical devices.

Protecting the agency from unauthorized external access can be accomplished by:
 Secured mode of user identification using user id/password or using digital certificates for
critical transactions.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Perimeter defences such as firewalls

 Defining the access control lists in the network components (routers and switches) and in
the firewall.
 Secure communications from the agency to external authorized parties (e.g. virtual
private network (VPN))
 Online detection and termination of unauthorized activities in the agency network using
intrusion detection system (IDS)

Recommended Good Practices for Authorization and Access Control

The recommended good practices in this section pertain to authorization and access
Good Practice 1: Authorize users based on least privilege.
 Authorize users to the minimum set of resources appropriate to their role.
 Authorizing users on least privilege minimizes the impact of security violations.
 Authorizing users to a minimum set of resources necessary to their function makes it easier to
establish accountability.
Good Practice 2: Use appropriate security service levels for each part of the technical infrastructure
according to agency-wide standards.
 Identifying the necessary security service levels allows appropriate choice of a security mechanism.
 A subdivision of infrastructure along security requirements will minimize security management and
response to changes.
 A basic level of communication security will reduce the number of applications that must be
Good Practice 3: Use open standards-based security solutions.
 Security implementations vary widely. Use of proprietary solutions may make it difficult to adapt to
advances in security and standards development.
 Security management across the agency requires a consistent and open standard based
implementation of security solutions.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Implementation Guidelines for Authorization and Access Control

The implementation guidelines in this section pertain to authorization and access control.

Guideline 1: Secure transmission of data where appropriate.

 Data in transit to and from the agency must be protected in compliance with legal requirements for
confidentiality and privacy.
 Web-enabled applications must protect confidential or critical data from unauthorized access.
 Use secure server-to-server communication to protect confidential or critical data transmission.
Guideline 2: Avoid virtual private network (VPN) solutions for connecting other agencies/ service
providers outside the agency that are not IPSec compliant.
 VPN solutions today are proprietary. All other agencies/external service providers are unlikely to
use the same or similar technology.
 Most transactions can be done with SSL.
 VPN solutions should be chosen on compliance with IPSec and inter-operability among IPSec
compliant VPNs.
Guideline 3: Web-enabled applications that require user authentication should use SSL with client
authentication and client public key certificates where appropriate.
 For certain payments over the Web, SSL without client authentication is sufficient protection for
client and server confidentiality.
 For the online transactions, which mandate user authentication, SSL with client authentication
should be used.
Guideline 4: Use encryption for stored data or email only when appropriate.
 Encrypted data incurs management and performance overhead.
 Encrypted data incurs high overhead to encrypt and decrypt.
 Managing encrypted or archived encrypted data requires effective key recovery and escrow
Guideline 5: Services provided through the Internet (Web-enabled applications, FTP, Mail, DNS etc)
must be placed on the DMZ or proxied from the DMZ.
 Application services must be protected from unwanted external access and must be located on a
DMZ or proxied from the DMZ.
 All communication from servers on the DMZ to internal applications and services must be
 Remote or dial-in access to the agency systems must be authenticated at the firewall or through
authentication services placed on the DMZ.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

The standards in this section pertain to authorization and access control.

Standard 1: Secure sockets layer (SSL)

 SSL is the most commonly supported protocol for communication between Web Server and
 It authenticates the web server and optionally authenticates the user browser.
 Current implementations allow for client authentication support using the services provided by
certificate authorities.
Standard 2: IP Protocol security extension (IPSec)
 IPSec is an extension to the IP communications protocol, designed to provide end-to-end
confidentiality for packets travelling over the Internet.
 IPSec has two modes: sender authentication and integrity but not confidentiality through the use of
an authenticating header (AH), and sender authentication and integrity with confidentiality through
the use of an encapsulating payload (ESP).
Standard 3: Cryptography must be based on open standards
 Cryptographic services identified in this document are based on open, industry accepted, standards.
Standard 4: Use S/MIME for securing email communications.
 S/MIME provides a consistent way to send and receive secure email including MIME data.
 S/MIME defines a protocol for encryption services and digital signatures.
 Email clients should be evaluated for support of the standard and for interoperability.

All organizations, including government agencies, experience change. Keeping security systems
synchronized with that change is essential. For example, employee additions, transfers and
resignations must be reflected rapidly. Administration of security in a distributed environment is a
complex task. This task includes the means to administer user accounts, privileges,
authentication and security policy implementation. The complexity of administering security can
be reduced by:

 Structuring responsibility for security e.g. creating an organization structure with defined

 Simplifying the complexity of security requirements, e.g. role-based administration vs.

user-based administration

 Creating security domains with common security requirements and policies

 Tools for performing administrative functions.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Recommended Good Practices for Security Administration

The recommended good practices in this section pertain to security administration.

Good Practice 1: Because security control impacts the entire government and each agency, its
implementation must be easy to administer, verify, and sustain.
 Administration of user identification, authentication and authorization is required to protect the
 In order to sustain security it must be easy to administer.
 The security implementation must be verifiable to ensure continued reliability of the agencies IT
Good Practice 2: Identify security policy domains.
 An agency is one security policy domain with a specific security policy that must be implemented.
 Establishing security domains simplifies the analysis of security requirements and focuses attention
on security policy requirements.
 Identifying security domains allows policies to be applied at the appropriate locations in the
 Security policies may vary between domains requiring protective measures or gateways to traverse
differences in policies.

The security architecture must provide the capability to track and monitor successful and
unsuccessful interactions with the information infrastructure of an agency. Accountability for
interactions must be tied to specific users. The architecture/systems should facilitate audit of all
significant security events including authentication, accessing of services and security
administration. The auditing capabilities need to be built into various layers of the agency’s
infrastructure including application software, operating system, database, network, firewall etc.
Following are the details of the guidelines for auditing of systems deployed by an agency.

 Agencies should perform an IT system audit including security and controls review of
application software, supporting IT infrastructure and general computer controls review.
The security and controls review of application software shall include the review of
following controls built into the application software:
o Input Controls: To ensure that inputs to the system are authorized, complete,
accurate and not duplicated. Also, to ensure that the rejected transactions are
isolated, analyzed, corrected and resubmitted in a timely manner
o Processing Controls: To ensure that data is processed by the system accurately and
completely in the proper accounting period
o Output Controls: To ensure that the system outputs are adequately reviewed for
accuracy and are distributed to authorized persons only and on time
o Interface Controls: To ensure that system interfaces operated in a manner such that
data is transferred accurately and completely and in the proper period and rejected
transfers are isolated, analyzed, corrected and re-submitted in a timely manner

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

o Standing Data Controls: To ensure integrity of data and existence of adequate

controls to enable only authorized changes to be made to master files, parameter
files and standing data files
o Audit Trials: To ensure generation of audit trails that make the transactions entered in
the system transparent, enable assigning of responsibility for actions committed
through the computer and review security violations. The auditing capabilities built
into the application software should address the requirement such as user
authentication attempts and failures, login/logout time, transaction time stamping with
user id, changes to the application software, version changes etc.
 Agencies should implement Intrusion Detection Systems (IDS) at all the critical network
points, both internal and external, for monitoring and addressing the unauthorized access
attempts and the malicious activities in the network.
 Information and communications systems handling sensitive agency information must log
all security relevant events. Examples of security relevant events include, but are not
limited to:
o attempts to guess passwords,
o attempts to use privileges that have not been authorized,
o modifications to production application software,
o modifications to operating systems,
o changes to user privileges, and
o changes to logging subsystems.
 Procedures must be established for monitoring the use of information processing
facilities. Level of monitoring must be determined as a result of a risk assessment
 The active user ids in the system need to be continuously reviewed by the designated
personnel to ensure unused user ids beyond a specified period (e.g. 60 days) are
deactivated or deleted through appropriate procedures.
 Computer and communications systems handling user access must be monitored for the
user-id, type of event, time and date of event, files and objects accessed, and the
program or utility used for access. Other relevant security issues, such as users switching
ids, attempts to guess passwords, failed logon attempts, policy violations for gateways
and firewalls, alerts from intrusion detection systems, and attempts to use unauthorized
privileges, must also be monitored.
 Computer and communications systems handling privileged user operations must be
monitored for use of supervisor user-id, system start-up and shut-down, and I/O device
 Computer and communications systems handling system alerts and failures must be
monitored for console messages or alerts, system log exceptions, and network
management alarms.
 Log records must be reviewed frequently according to the risk factors involved. Areas
that need to be considered are the criticality of the application processes, the value of the

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

information, the past experience of system misuse, and the extent of the system inter-
 System administrators must perform system monitoring as part of their daily work routine.
This includes, but is not limited to, monitoring system usage, processing and input/output
performance, and availability of network services.
 Software tools or utilities shall be used that will programmatically summarize log entries
or associate actions with log file entries. This will help to summarize important log events
generated in log files. (E.g. top 10 FTP users, top 10 denied FTP users, top 10
telnet/rlogin users, top 10 denied telnet/rlogin users, top 10 failed user authentication,
usage statistics by proxy services like ftp) 
 The logs will be accumulated for one week and then archived to a location, which is
independent of the firewall system. The archive backups will be stored for at least six
 System administrators should continuously monitor for the latest patches/antivirus
updates/releases for the system software deployed by the agencies. Such updates
should be implemented for all the IT resources deployed by the agency.

A portal solution is among the key requirements of the envisaged solution for the agencies and
following outlines, in addition to what has been discussed in this section, security guidelines for a
portal solution.

Portal Solution Security Requirements

The portal solution should provide the ability to map together two sources of user information. For instance,
LDAP is very good at storing largely static data about users, however if there is some data about users that is
highly dynamic, it can be more efficient to store such information in an RDBMS, and retain the static data in
LDAP. The solution should provide a method for linking the two. For example a users ID and contact details
are largely static, whereas transactional information relating to the user (i.e. service registration details) are
liable to frequent changes.
Browser based password change service for users with enhanced password management
Features such as minimum password length, minimum number of numeric characters, forced password
change with optional grace logins, non-dictionary words, password history etc.
Access control to information
The security solution must be able to support a variety of ways to restrict access for specific users to only
certain resources in the solution. The System must provide single sign-on to all functional areas.
Scalable and portable solution
The security solution must provide scalable access services for the Portal solution, including scalability in
terms of number of users, user groups, resources, and access control policies.
Open and extensible security platform
The solution must provide a robust and customizable security solution that meets the application
requirements of the solution. It is hard to anticipate all present and future requirements. An open, extensible
architecture and documented application programming interfaces (APIs) enable developers to customize an
access control system to their specific requirements. A platform that will grow with additional application
deployment and scales as user traffic grows, while providing the highest level of reliability is required.
Uninterrupted security services /automated load balancing to backup services

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

The security solution must provide for load balancing to enable a fully scalable solution. It should also
enable continued service on failure of one or more of its component parts.
Secure storage of critical items
The security solution must provide for the ability to securely store critical data within the LDAP or other user
directory structure or any user related databases so that database administrators or any unauthorized users do
not have access to such items as passwords and other critical documents of any oration.
Detailed session management abilities
The security solution must provide for session settings such as idle or max session time-outs, concurrent
sessions and other session control settings

5 Web Access Filtering

6 The security solution must examine all traffic to all services/pages being protected by
the solution. All access attempts to the web server/application should be intercepted
and examined for authentication and authorization requirements.
Security Monitoring
The security solution must be capable of comprehensive logging of the traffic through the network and
applications under its control. It should be capable of logging unauthorized access attempts in to the network
and the internal resources, and attempts to login that fail. It should also be capable of notifying appropriate
parties including the agency users/security administrators etc of suspicious activity.
Configuration Management
The security solution should provide a way of controlling changes to configuration, if a major change to
configuration is made then a way of recording this change must be provided with the possibility of rolling
back through previous configurations in the case of problems.
The portal environment, including the documents uploaded by the users, needs to be adequately protected
against viruses.
Security- User profiles
For an administrator - The system should provide two layers of access control over the creation/modification
of user profiles.
For the first login by a user, the system should prompt the user to change his password.
When a user logs-in, the system should show him the date & time of last login
The System must restrict user access based on the privileges assigned to the user
The system should maintain a log of all the activities carried out by a user along with a date and time stamp.
The System must maintain a log of all activities carried out by an administrator.
Other Security Services
The sensitive and confidential information and documents of the users must be stored in an encrypted format
in the database.
The system should support 128-bit encryption for transmission of the data over the internet.
All the systems in solution network should run most up-to-date anti-virus software to avoid malicious
programs to cause damage to the systems
Any access to the solution database should only be via application/portal authorization
Physical security for the solution should address securing all information assets from physical access by
unauthorized personnel. For example, the data centre server infrastructure should not be physically
accessible by anyone other than the persons responsible for on-site maintenance of the systems
The technology solution should comply with BS7799 standards. Security certification process shall include
audit of network, server and application security mechanisms.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

PKI Service Requirements

For providing online and real-time transactions to the citizens and businesses requiring
high degree of user authentication and security, agencies should implement a PKI based
solution. For e.g. an e-procurement module should facilitate online submission of tender
responses by the vendors. For such transactions, agencies can implement digital signature
based authentication services. Agencies need to carryout an exercise to identify such
sensitive and critical transactions, and should make use of PKI services for performing
such transactions. Following outlines certain guidelines with respect to implementation of
PKI Services.
PKI Services Requirements
The solution should support digital certificates issued by licensed CA’s in Emirate / GCC and should accept
digital certificates based on criteria (Issuer, Class, Policy Identifiers).
Client digital certificates based authentication should be used for access to the services as identified by the
The digital signatures used in for the agencies solution must be compliant to standards laid down by the
eTransactions Law (and related bylaws) and further amendments, if any.
Automatic validation of digital certificates used for authentication and digital signatures is required. The
validation must include check for acceptance criteria (Issuer, Class and Policy Identifiers), validity period,
and current CRL based revocation checking.
Digital signing and encryption of attachments (documents) compliant to PKCS standards is required.
XML digital signatures compliant to W3C XML-Signature syntax and processing
( are required for transactions.

Directory Services
The government agencies are planning on conducting their business processes in an electronic
environment and developing closer electronic interface with citizens/residents, businesses, other
agencies and service providers. This requires a secured means of identification, authorization
and administration of agency information users and effective security administration of agency
information resources. To meet these goals, a directory services infrastructure must be in place.
Such information can also be maintained in any standard relational database system. But,
directory services provide effective and efficient administration facilities over RDBMS in this

X.500 is an international telecommunications union telecom (ITU-T) standard for directory

services that defines a global solution for the storage, distribution, and retrieval of directory
information. A directory service allows a user, administrator, or program to locate objects on a
network and obtain information about them. A key component of a directory service is the
directory, a type of database that stores information. Directories often are displayed in a GUI as
trees with branches. A directory service is a database that provides a mechanism to inventory,
administer, and access resources in the network. These resources include users, groups of
users, applications, data, printers, servers, and other physical devices throughout the network. A

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

properly designed and implemented directory service can present a central point for
authentication (log-in) and a view of all available resources on the network.

Additionally, this facilitates authorization, also known as access control, which determines the
rights that are associated to a particular resource and enforces them.

Recommended Good Practices

It is necessary to implement a directory services strategy in order to improve communications
between disparate systems. When planning a project that includes directory services, the strategy
must be based on the following good practices to assure its success.

Good Practice 1: Implement a fault tolerant solution to provide 24-hour, 7-day availability to the
enterprise directory.
If the directory becomes inaccessible, the resources to which a user has rights become unavailable.
Therefore, a directory must be available at all times to accept authentication requests. This can be
accomplished with a planned fail-over strategy to ensure that, if one server fails, another backup server can
pick up the requests. This should include a replication strategy with hardware solutions that include disk or
system duplexing, disk or system mirroring, disk arrays.
Good Practice 2: Purchased applications and operating systems should be directory-enabled.
Securing applications and their operating environments is a significant challenge. Security is a natural
environment for the use of a directory. Applications can authenticate users to an external source by being
directory enabled. The directory is better suited to provide information on the level of security necessary.
Applications can be further enhanced when they are enabled to obtain an expanded set of information from
the directory as appropriate. Thus making applications more modular and consolidating administration to a
central location. For example, an application can gather employee information from the user object in the
directory. This facilitates user authentication and authorization by making the resources on that platform
available to the agency, when the appropriate rights are in place.

Implementation Guidelines

The implementation guidelines in this section pertain to directory services.

Guideline 1: Ensure that new software and operating systems are directory-enabled whether
purchased or developed in-house.
Authentication and authorization functionality may be available in each of the existing and planned
applications. Rather than building these same services into each application, these services should be
obtained from the enterprise directory. Purchased applications and operating systems should also utilize
the enterprise directory for user authentication and authorization. This prevents redundant administration
and user authentication. Furthermore, when current systems are undergoing significant change this
functionality should be built in.
Guideline 2: Discontinue propagation of proprietary products that do not conform to standards.
Proprietary products that do not utilize industry standards prevent our systems from being interoperable.
Accessibility to our enterprise directory from other systems provides a mechanism for central

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

administration and user authentication, directory lookups, synchronization, public key retrieval, and
others. LDAPv3 is the current industry standard for this functionality.
Guideline 3: Use the enterprise directory for authentication and authorization of network and
application users.
The primary function of directories today is user authentication. Applications should be directory enabled
to allow authentication to be performed by the enterprise directory. The directory is better suited to
provide security and it allows us to consolidate administration to a central source. This is not the only
capability of directories. Directories are being expanded to support policy-based networking, DNS,
among other functionality.

Business Continuity and Disaster Recovery Guidelines

In recent years, added emphasis has been placed on the continuation of business functions in the
face of potential disasters. Such disruptive acts may be natural disasters such as earthquakes,
severe storms, flooding or deliberately caused by man (bombings, arson and sabotage). The
government is looking forward to improve the service delivery through business process
reengineering and infusion of Information Technology into service delivery. The Emirate is also
planning to use IT as the key enabler in providing the services to the citizens/residents,
businesses which leads to heavy dependence upon its information processing capabilities in
order to support its service delivery. Only through effective advance planning and preparation can
we ensure that critical service delivery functions and activities will continue in the event of a

With such a strategic priority given to the IT, it is mandatory for the government to review and
address all the issues and risks surrounding the IT and to plan for the continuity of the services in
case of unforeseen events. This section of the document highlights standards and guidelines in
designing the business continuity and disaster recovery plan.


Business continuity plan: A plan that sets out the processes that are to be followed for an
organization to continue to function and deliver essential services in the event of a significant

Disaster recovery plan: A plan that sets out the processes that the government needs to follow
in order to continue to deliver essential services in the event of a significant disruption to, or
degradation of government IT resources

Guidelines for Development of BCP & DRP

The automation of governments business process and processing and storage of transactions
through information systems result in a greater dependence on information systems. As a result,
information processing is a nerve centre for the success of any eGovernment initiative. As
dependence on automated business processing increases, so does the risk associated with a
loss of processing capability. Preparation of an overall business recovery plan gives the
government an excellent opportunity to alleviate or minimize potential problems that would disrupt
the service delivery and operations.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

 Flexibility is a crucial concept in continuity planning. No amount of detailed planning can

accommodate every contingency. Instead, the government / individual agencies should
plan to have the personnel, training, information, and resources in place to respond to the
broadest variety of contingencies. Planning for flexibility in no way reduces the need for a
detailed plan with "hot / cold site" provisions, back-up files, personnel scheduling.

 Continuity plans should encourage management initiative by decentralizing decision-

making authority within the bounds of formalized goals and objectives. Clear statements
of both disaster-specific continuity goals and objectives that apply to all continuity-
disrupting events should provide management with both the confidence and the authority
to remain flexible.

The continuity planning process should cover these main areas:

 Business Planning - determines which aspects of the services and operation of the
government / an agency are the most critical and create the justification for the overall
plan. This preliminary analysis phase of a project should assess the potential risk and
impact on the service delivery and operations; identify recovery requirements and list
alternative strategies.

 Technical Support - determines the feasibility of the plan from a technical standpoint and
ensures that all critical alternate locations have the equipment and technical support to
continue the services and operations. Details of the functions that must be carried out
must be provided, both prior to and following a disaster, to minimize the loss and improve
the chances of quick recovery

 Implementation - ensure that agency / government personnel will be able and willing to
implement the plan. The plan should take personnel changes into account, to avoid the
situation where only one person knows about the systems

 Maintenance and Testing - the Business Continuity Plan is a dynamic document that must
reflect the continuing changes in the processes. Constant testing and adjusting are
needed in order to ensure its continued viability.

The plan should consider various types of disasters and varied durations of operations
interruption. It should detail the actions to be taken based on the level of damage, rather than an
individual type of loss. Exceptions to this rule will be regional disasters, such as earthquakes, in
which case the plan should detail specific actions.

Following outlines the guidelines for designing and implementing the business continuity and
disaster recovery plan for the government.

a) Organize and Manage the BC & DRP Project

i) The government / agencies should establish a dedicated contingency

planning team.

The government / agencies should develop the detailed work plan and schedule for development
of BC & DRP.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

ii) Agencies should review the current backup facilities and insurance for the
information systems and evaluate the relevance and reliability of such

b) Perform impact analysis

i) Agencies should develop a process/service evaluation criterion identifying

the individual business processes and the services offered by the agency,
criticality and uptime or availability requirements of the services and potential
impact to the process and/or service in case of failure in the Information
Systems or related enablers

ii) Agencies should perform the impact analysis based on the evaluation criteria
developed and shall prioritize the critical processes/services.

c) Determine minimum processing requirements and Recovery Point and Recovery Time
Objectives (RPO and RTO)

i) Agencies should define the normal operating requirements for each critical
process/service and application (s) identified in the previous step.

ii) Define the minimum operating requirements for each critical


iii) Define Recovery Point Objectives (RPO) i.e. the point in time to which
systems and data must be recovered after an outage as determined by the
agency and Recovery Time Objectives (RTO) for each service and the
enabling Infrastructure i.e. timelines within which the information systems
need to be recovered.

d) Identify and analyze risks

i) Agencies should analyze the risk associated with IT and other resources
enabling the service delivery shall prioritize the resource needs.

ii) Agencies should identify the scenarios of resource loss situations, which
might have impact on the service delivery.

e) Analyze alternatives and select strategy

i) For the identified critical resources enabling the key services and processes,
agencies should identify the recovery alternatives available.

ii) Agencies should evaluate each recovery alternative identified for the critical
resources and based on the minimum processing requirements and
RPO/RTOs appropriate recovery strategy shall be defined.

f) Agencies should develop a detailed plan based on the identified recovery strategy as
discussed above.

g) Agencies should develop the appropriate test scenarios for verifying the effectiveness of
the recovery plan and based on the test results, the recovery plan shall be updated.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

h) Technological advances and changes in the business process and service delivery
requirements of an agency will necessitate periodic revisions to policies, standards, and
guidelines. Routine maintenance of these is essential to keep them current. Major policy
changes will require appropriate approval from the officials concerned.

Other guidelines while developing a Business Continuity Plan:

i) There should be a clear definition of individual responsibilities, including who has the
authority to declare a disaster and initiate the BCP procedures.

j) There should be instruction on when, where and how to use the backup site including,
but not limited to:

i) Procedures for establishing Information Systems processing in an alternate

location including arrangements for office space

ii) Replacement equipment

iii) Telecommunications

iv) Supplies

v) Transportation etc.

k) A list of contacts of key personnel with work, home and cellular phone numbers as
appropriate should be maintained.

l) Identification of vital system software documentation should be stored at the backup site.

m) The procedures for retrieving and restoring information and data from the off-site storage
facility shall be documented.

n) A list of vendor contact personnel should be made available.

o) Documentation detailing the complete listing of IT Infrastructure including software and

hardware shall be maintained.

p) The interim procedures to be followed until systems are restored, and procedures for
catching up when systems are back in operation shall be documented.

q) There should be an evaluation of maximum outage tolerable for each system and a
restoration priority listing indicating the order in which to restore systems.

r) A copy of the Recovery Plan shall be stored off-site.

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah

Critical Infrastructure Considerations for Disaster Recovery Planning

a) Disaster Recovery Site

Establishment of an alternate data centre i.e. disaster recovery centre which shall be
available in the event of a major event impacting the main data centre. An agency can
establish their own DR site or such services can be contracted with external data centre
service providers or a central DR site can be established. The delivered hardware should
have the same capacity or at least 50 % of the capacity required for performing the agency

b) Infrastructure

Appropriate redundancy shall be provided in the critical IT Infrastructure including Servers,

firewalls, switches and routers etc. Various options exist for providing the redundancy in the
Infrastructure supporting agency operations.

i) Clustered Solution, implementation of two nodes with fault tolerant and

automatic fail-over features

ii) Remote failover Solution, implementation of clustered nodes with a remote

node availability in the government owned DR site

iii) Disaster recovery service contract; implementation of clustered nodes with

remote node availability in a DR site owned and operated by a third party
service provider i.e. ISP.

iv) Stand-by system; to be implemented in case of a failure in the primary

infrastructure servers. This option does not provide real time fail over

c) Network

Availability of communication channel across the government is critical in service provisioning

and continuation of day-to-day operations. Appropriate redundancy should be built into the
connectivity between the locations based on the bandwidth requirements.

d) Data

The security and availability of the data is critical in continuation of the operations and service
delivery. Agencies should implement appropriate data storage and archiving policies to
ensure availability of the data in the event of a disaster. Agencies should design a data
backup policy to capture data items for backup, frequency of data backup, data restoration
procedures etc. A secure and fireproof data storage vault should be used for storing the data
backup locally. Access to the data backup should be restricted for authorized personnel only.
A secured off-site storage facility and the backup of the data, preferably in the encrypted
format, should be stored in the offsite location. In addition to the business data, the
application software, system design documents, user manuals, database structures,
operating system, database and other critical data should be stored in the secured offsite

Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah