Post on 13-Feb-2016
description
rakan
Government of Ras-Al-Khaimah
Annexes
*connectedthinking
Ras Al-KhaimaheGovernment Strategy
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Annexure No.
Description Page No
1 AS-IS Report 3
2 Action Plan 413 Service Prioritization 54
4 Channel Strategy 725 Institutional Structure 83
6 Capacity Building 947 Marketing and Awareness Plan 104
8 Strategic Control 1119 Standards and Policies 117
2
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
3
Annex 1- AS-IS Assessment
*connectedthinking
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S.No Description Page No
1 Introduction 5
2 Approach and Methodology 6
3 Strategic Dimensions 7
4 Overview of the As-Is Assessment of Departments
36
4
PricewaterhouseCoopers
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.
5
PricewaterhouseCoopers
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 through:
o meetingso Interviewso AS-IS assessment questionnaireo focus group discussions
Assessment of the eGovernment requirements based on the best practices.
Benchmarking of the RAK eGovernment (submitted as separate report)
6
PricewaterhouseCoopers
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
1.
Se
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
7
Enabling EnvironmentStandards & Policies
Core InfrastructurePayment Gateway
Capacity Building
Marketing &
Awareness
Security Infrastructure RAK GIN Common
Data Center
Strategic Control
Citizen, Business, Visitor and Government Employee
GIS
eGovernment Portal Common Services Centers MobileContact Center
Delivery Channels
IT ApplicationsCommon & Department Apps
Monitoring &
Evaluation
Government Process
Reengineering
ServicesLife-Cycle Event Based
Defined Service Levels
Grievance Redressal System
139 Services
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
b. RAK GIN
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
transformation.
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).
8
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Table 1: As-Is Assessment: e-readiness ScoringDescription Rating
E-Readiness for all the sub - parameters evaluated for the dimension are satisfactory and little room exists for further improvement. High
Significant progress has been made for some sub-parameters however gaps remain in other important sub-parameters Medium
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
9
PricewaterhouseCoopers
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 www.rak.ae 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
10
PricewaterhouseCoopers
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
detail:
Table 2: Service Delivery Channel Assessment
3.1.1. Call 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
are:
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.
11
PricewaterhouseCoopers
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
planned.
3.1.2. Common 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
infrastructure.
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.
3.1.3. Mobile
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.4. E-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.
12
PricewaterhouseCoopers
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 (www.rak.ae) 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.
PARAMETER` MATURITY
User Friendliness Medium
Content Low
Delivery of e-Services Low
User-Friendliness
Most departmental portals can be accessed from the www.rak.ae 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.
13
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Majority of the departments provided FAQ links, many of which however did not work.
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
eServices.
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
14
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
online-- application for new customs clearing representative card. The Saqr Port
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 Rak.ae gov
portal. This leaves the user with very little faith in portal to deliver timely and relevant
services.
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 AssessmentDepartment Website Maturity
Civil services NoneCourt Phase ICustoms and Ports Phase IIIEconomic Development Phase IIFinance Phase ILand Phase I
Municipality Phase IIPublic Works and Services Phase I
15
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Department Website MaturitySaqr Port Phase IIISewerage Authority NATown Planning and Survey English Version NA.
16
PricewaterhouseCoopers
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
place:
Data Center (DC)
Ras-Al-Khaimah Government Information Network (GIN)
Security Infrastructure
Payment Gateway
Disaster Recovery
Common Applications
Departmental Applications
GIS
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 AssessmentCOMPONENT` MATURITY RAK GIN Medium Data Center Low Security Infrastructure None Disaster Recovery None Payment Gateway HighGIS MediumCommon Applications LowDepartmental Applications Medium
3.2.1. Common 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
17
PricewaterhouseCoopers
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.2. RAK 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
18
PricewaterhouseCoopers
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. Specifically,
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
19
PricewaterhouseCoopers
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.3. Common 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
20
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
application however is limited because it is not directly liked to the payroll of finance
department.
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
machinery.
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
departments.
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.
21
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Table 5: Common Applications Assessment
3.2.4. Security 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.
Specifically:
There no documented security policy in any of the departments.
22
PricewaterhouseCoopers
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.
3.2.5. GIS
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
governance
• As a part of the GIS project , RAK government has established
• A GIS Infrastructure
23
PricewaterhouseCoopers
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 AssessmentCOMPONENT` MATURITY
Complete updated Map system HighTransform existing spatial data to single framework
Medium
Data standards for spatial data MediumDepartmental GIS Applications Low
24
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
3.2.6. Payment 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.7. Disaster 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
25
PricewaterhouseCoopers
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.
26
PricewaterhouseCoopers
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
COMPONENT` MATURITY
Standards & Policies Low
Capacity Building Low
Strategic Control None
Monitoring & Evaluation Low
Marketing & Awareness Low
Institutional Structure Medium
3.3.1. Capacity 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
27
PricewaterhouseCoopers
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
standards.
• 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
28
PricewaterhouseCoopers
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 www.rak.ae 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.2. Common 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
29
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
procurement by EGA but for projects and initiatives, there are no standards and
guidelines.
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 implemented
2 Meta data standards Do not exist
3 Privacy Do not exist
4 Disaster Recovery and Business Continuity Planning
Do not exist
5 Software Architecture Do not exist
6 Training Do not exist
7 Service Level Agreements / Citizen Charters
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
30
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
3.3.3. Monitoring 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
information
31
PricewaterhouseCoopers
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.4. Marketing 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.
32
PricewaterhouseCoopers
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.5. Strategic 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
same
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
planned
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
33
PricewaterhouseCoopers
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.6. 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.
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
34
PricewaterhouseCoopers
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.
• 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.
35
CEO
Head-Projects
Manager-Administration
Deputy CEO
Manager-Marketing & Awareness
Manager-KM/ Capacity Bldg.Manager-Audit/
Monitoring & Evaluation
Manager-Standards,
Policies/ SLA Management
Manager-Dept. Support - 3
Manager-Infrastructure
RAK GIN & Data CenterManager-
Channels
Deputy Manager-Web
Portal
Sr. Executive-Call Center,Mobile, CSC
Asst. Manager-Finance
Asst. Manager-
Procurement & Vendor Mgmt - 2
Secretary
Secretary
Support Staff-Driver,Office
Assistant - 3
Solution Architect
Tech Support Common
Applications
Technical Pool Staff/Outsource10
Sr. Executive-HR
Executive Coordintion
CEO
Head-Projects
Manager-Administration
Deputy CEO
Manager-Marketing & Awareness
Manager-KM/ Capacity Bldg.Manager-Audit/
Monitoring & Evaluation
Manager-Standards,
Policies/ SLA Management
Manager-Dept. Support - 3
Manager-Infrastructure
RAK GIN & Data CenterManager-
Channels
Deputy Manager-Web
Portal
Sr. Executive-Call Center,Mobile, CSC
Asst. Manager-Finance
Asst. Manager-
Procurement & Vendor Mgmt - 2
Secretary
Secretary
Support Staff-Driver,Office
Assistant - 3
Solution Architect
Tech Support Common
Applications
Technical Pool Staff/Outsource10
Sr. Executive-HR
Executive Coordintion
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
• 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.
36
PricewaterhouseCoopers
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
Citizen Charter • Formal citizen charter is available mentioning all the services available for citizen / business with service levels
Service Automation / IT application
• The department has internal IT systems for automation of work for service delivery
• The IT application is ready for online service deliveryInterface with other departments
• Whether the department has IT system for transfer of data incase service fulfilment requires information/interaction with other departments
Alternate channel for Service
• The department is providing some of the services through channels other than department channels
• Provision for department service online through RAK portal
Citizen Charter:
The department have no formal documentation of their service charter.
37
PricewaterhouseCoopers
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
below:
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
Services
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 Charter
AvailabilityService Automation/ IT application
Alternate channels for service delivery
Existing interface with other deptt.
Overall Service 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
Services department
Low Low Low Low Low
Saqr Port Low Low Low Low Low
Sewerage Authority Low Medium Medium Low Low
Town Planning and
Survey
Low Low Low Low Low
38
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
4.2 ICT Infrastructure and Policy
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
Hardware • Availability of Servers / and adequate number of PCs for
staff with required peripherals.• Other It support hardware like storage system ec.
Software
• Availability of software packages for regular usage e.g. MS Office
• IT application for department functions and interface to other applications
Connectivity • Availability of LAN• Connectivity to RAK GIN
Document Management/Archival system
• A system for scanning the incoming/outgoing paper documents for storage and easy retrieval
Standard & Policies • Availability of organizational level policies for e-Governance
Hardware
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.
Software
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.
Connectivity
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:
39
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Department Hardware Software Connectivity Document management/
Archival system
Standard and
Policies
Overall Assessment
Civil services Low Medium Medium Medium Low Medium
Court Medium Medium Medium Low Low LowCustoms and Ports High High Medium Medium Low MediumEconomic Development Medium Medium Medium Low Low LowFinance Medium Low Medium Medium Low LowLand Medium Medium Medium Low Low MediumMunicipality Department Medium Low Low Low Low LowPublic Works and Services department
Medium Medium Low Low Low Low
Saqr Port Medium Medium Medium Low Low MediumSewerage Authority Low Low Medium Low Low LowTown Planning and Survey
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
ICT literacy• Basic IT literacy of the functional staff
• Advanced IT skills of the IT sections
IT Project management skills • IT section managed by people formally trained in IT project management skills
In-house IT Capability • Staff in the IT section with the formal trained capability in software 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.
40
PricewaterhouseCoopers
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
Literacy IT project management skills
In-house IT capability
Overall Assessment
Civil services Low Low Low Low
Court Low Low Low LowCustoms and Ports Medium Low Medium MediumEconomic Development Medium Low Low LowFinance Medium Low Low LowLand Low Low Low LowMunicipality Department Low Low Low LowPublic Works and Services department Medium Low Medium MediumSaqr Port Medium Low Low LowSewerage Authority None None None NoneTown Planning and Survey Medium Low Low Medium
4.4Summary 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
41
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
42
Annex 2- Action Plan
*connectedthinking
Program milestone 0-3 Months 4-6 Months 7-9 Months 10-12 Months Year 2 Year 3 OngoingCore TeamForm a core team from different departmentsDevelop Charter to support service through PortalFormalize monitoring and review mechanisms Formalize Reporting Mechanisms
Pilot ServicesPrioritization and selection of 8 servicesProcess changes required for quick enablement of servicesRedesign services for online enablementImplement online security and roll out services
Citizen SurveySeletion of Third Party Survey VendorFinalize Citizen survey questionnaireComplete Survey & Publish Results
Service Enablement: First Set of 45 Services(Portal) Feasibililty Assessment of services Process redesign for online service delivery Identification & Implementing channel migration incentivesImplementation of Online Security InfrastructureStandardization of Departmentals WebsitesRoll out of services
Egovernment Portal Strategic Dimension : Channel Enhancement
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
eGovernment Portal: Action Plan
43
Program milestone 0-3 Months 4-6 Months 7-9 Months 10-12 Months Year 2 Year 3 OngoingService Enablement: Second Set Services(Portal) Feasibililty Assessment of services Process redesign for online service delivery Identification & Implementing channel migration incentivesImplementation of Online Security InfrastructureStandardization of Departmentals WebsitesRoll out of services
Service Enablement: Third Set Services(Portal) Feasibililty Assessment of services Process redesign for online service delivery Identification & Implementing channel migration incentivesImplementation of Online Security InfrastructureStandardization of Departmentals WebsitesRoll out of services
Outcomes8 Pilot services made available
online
First set of departmental
services made available online.
Second set of services made
available online.
Third set of services made
available online.
Strategic Dimension : Channel Enhancement Egovernment Portal
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
44
Program milestone 0-3 Months 4-6 Months 7-9 Months 10-12 Months Year 2 Year 3 OngoingCore TeamForm a core team from different departmentsDevelop Charter to support service through Contact CenterFormalize monitoring and review mechanisms Formalize Reporting Mechanisms
Citizen SurveySeletion of Third Party Survey VendorFinalize Citizen survey questionnaireComplete Survey & Publish Results
Identification of Implementation VendorRFP for selection of vendor for Contact Center operationsIdentification of Vendors & Issue of RFPReceipt & Evaluation of Vendors BidsSelection & Contract FinalizationContact Center / services implementation by VendorGo Live of Pilot Services
Service Enablement: First Set of ServicesFeasibililty Assessment of services Process redesign for delivery through Contact CenterIdentification & Implementing channel migration incentivesTraining of Contact Center StaffDesign & Publish FAQs of Departmenal ServicesRoll out of services
Strategic Dimension : Channel Enhancement Contact Center
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Contact Center: Action Plan
45
Program milestone 0-3 Months 4-6 Months 7-9 Months 10-12 Months Year 2 Year 3 OngoingService Enablement: Second Set ServicesFeasibililty Assessment of services Process redesign for delivery through Contact CenterIdentification & Implementing channel migration incentivesTraining of Contact Center StaffDesign & Publish FAQs of Departmenal ServicesRoll out of services
Service Enablement: Third Set ServicesFeasibililty Assessment of services Process redesign for delivery through Contact CenterIdentification & Implementing channel migration incentivesTraining of Contact Center StaffDesign & Publish FAQs of Departmenal ServicesRoll out of services
Outcomes
Identified departmental
services made available through
contact center
Second set of services made
available through
contact center
Third set of services made
available
Strategic Dimension : Channel Enhancement Contact Center
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
46
Program milestone 0-3 Months 4-6 Months 7-9 Months 10-12 Months Year 2 Year 3 OngoingCore TeamForm a core team from different departmentsDevelop Charter to support service through PortalFormalize monitoring and review mechanisms Formalize Reporting Mechanisms
Citizen SurveySeletion of Third Party Survey VendorFinalize Citizen survey questionnaireComplete Survey & Publish Results
Service Enablement through mobileFeasibililty Assessment of services for mobile provisionSelection of Vendor for Mobile Gateway ImplementationDesign of the content for the mobile phone deliveryImplementation of mobile gateway and service provisioningPilot ServicesIdentification & Implementing channel migration incentivesRoll out of services
Outcome Feasibility Assessment
Pilot Set of Services
Final Set of Services
Strategic Dimension : Channel Enhancement Mobile Phone
Program milestone 0-3 Months 4-6 Months 7-9 Months 10-12 Months Year 2 Year 3 OngoingCore TeamForm a core team from different departmentsDevelop Charter to support service through CSCsFormalize monitoring and review mechanisms Formalize Reporting Mechanisms
Citizen SurveySeletion of Third Party Survey VendorFinalize Citizen survey questionnaireComplete Survey & Publish Results
Identification of Implementation VendorDesign RFP for selection of vendor for CSC operationsIdentification of Vendors & Issue of RFPReceipt & Evaluation of Vendors BidsSelection & Contract FinalizationCSC / services implementation by VendorGo Live of Pilot Services
Service Enablement: First Set of ServicesFeasibililty Assessment of services Process redesign for delivery through CSCsIdentification & Implementing channel migration incentivesTraining of CSC Staff in processing different serviecsDesign quality processes for delivery through CSCsRoll out of services
Strategic Dimension : Channel Enhancement Common Services Center
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Mobile Phone: Action Plan
47
Program milestone 0-3 Months 4-6 Months 7-9 Months 10-12 Months Year 2 Year 3 OngoingCore TeamForm a core team from different departmentsDevelop Charter to support service through CSCsFormalize monitoring and review mechanisms Formalize Reporting Mechanisms
Citizen SurveySeletion of Third Party Survey VendorFinalize Citizen survey questionnaireComplete Survey & Publish Results
Identification of Implementation VendorDesign RFP for selection of vendor for CSC operationsIdentification of Vendors & Issue of RFPReceipt & Evaluation of Vendors BidsSelection & Contract FinalizationCSC / services implementation by VendorGo Live of Pilot Services
Service Enablement: First Set of ServicesFeasibililty Assessment of services Process redesign for delivery through CSCsIdentification & Implementing channel migration incentivesTraining of CSC Staff in processing different serviecsDesign quality processes for delivery through CSCsRoll out of services
Strategic Dimension : Channel Enhancement Common Services Center
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Common Service Center: Way Forward
48
Program milestone 0-3 Months 4-6 Months 7-9 Months 10-12 Months Year 2 Year 3 OngoingService Enablement: Second Set ServicesFeasibililty Assessment of services Process redesign for delivery through CSCsIdentification & Implementing channel migration incentivesTraining of CSC Staff in processing different serviecsDesign quality processes for delivery through CSCsRoll out of services
Service Enablement: Third Set ServicesFeasibililty Assessment of services Process redesign for delivery through CSCsIdentification & Implementing channel migration incentivesTraining of CSC Staff in processing different serviecsDesign quality processes for delivery through CSCsRoll out of services
Outcomes
Identified departmental
services made available
through CSC
Second set of services made
available through CSCs
Third set of services made
available through CSCs
Strategic Dimension : Channel Enhancement Common Services Center
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
49
Program milestone 0-3 Months 4-6 Months 7-9 Months 10-12 Months Year 2 Year 3 OngoingFinalize Data Center requirements and costs for RAK Identification of Implementation VendorDesign RFP for selection of vendor for Call Center operationsIdentification of Vendors & Issue of RFPReceipt & Evaluation of Vendors BidsSelection & Contract FinalizationPrioritization of departments for data migrationMigration of application/ data of first batch of departmentsServer/ hardware sizingDevelop SLAs Establish WAN connectivity b/w departments and data center through RAK GINPlanned migration of data to the data centerParallel run/ data access from both data centers and departmentsEstablish change controls, archival, DR and security Control Go Live
Migration of application/ data of second batch of departments
Server/ hardware sizingDevelop SLAs establish WAN connectivity b/w departments and data center through RAK GINPlanned migration of data to the data centerParallel run/ data access from both data centers and departmentsEstablish change controls, archival, DR and security Control Go-LiveData Center OpertionsSLA and performance monitoring
Strategic Dimension : Core InfrastructureData Center
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Data Center: Action Plan
50
Program milestone 0-3 Months 4-6 Months 7-9 Months 10-12 Months Year 2 Year 3 OngoingBandwidth Requirements AssessmentDevelop a revised Architecture of RAK GINDesign Technical Specifications
Identification of VendorVendor Evaluation and SelectionDevelop SLAs
Implementation of upgrade funtionality - RAK GIN
Implementation of Network monitoring system
SLA monitoring
Strategic Dimension : Core InfrastructureRAK GIN
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
RAK GIN: Way Forward
51
# Activity Description
1 Formation of the Supreme committee
2 Approval and adoption of the eGovernment Action Plan
3 Formalize resources, funding and technical expertise needed to drive the actin plan
4 Regular meetings for monitoring the eGovernment Program progress
5 Re-organization and fitment of the current EGA staff
6 Hiring of the staff for the EGA
7 Setup performance appraisal system around KPI for staff
# Activity Description
1 Employee awareness programs on eGovernment
2 Computer literacy for all government employees
3 Establishment of network of experts for software development and GPR
4 Detailed training needs assessment of the government staff
5 Identify and train eGovernment Champions in each department
6 Operationalization of Training centre for eGovernment in EGA
7 Establish centralized knowledge management system
8 Development of eLearning courses for the employees
9 Identification of international/third party certification courses for employees
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Institutional Structure: Way Forward
Capacity Building: Way Forward
52
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Marketing and Awareness: Way Forward
Standards and Policies: Way Forward
# Activity Description
1 Design and adopt Marketing and Awareness strategy for eGovernment
2 Formal appointment of Marketing and Awareness manager in EGA
3 Selection of a Marketing and Awareness agency for promotion of eGovernment initiatives
4 Identification of Target groups, and consequently, selection of media channels
5 Development of an inter-government communication strategy
6 Seminars for Businesses/ international fairs/ events
7 Impact assessment of awareness exercises
8 Circulation of progress reports amongst stakeholders
# Activity Description
1 Formation of Standards and Policies committee to design and oversee implementation of common standards
2 Identify and develop standards and policies to be implemented
3 EGA to participate and affiliate with International Standards Agencies and Bodies
4 Procurement of all IT services and products to meet guidelines
5 Third Party Certification to be obtained for applicable IT and security standards
6 Monitoring and evaluation to ensure compliance with mandated polices/ standards
7 Annual review of standards and policies
53
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Monitoring and Evaluation: Way Forward
# Activity Description
1 Formal appointment of Monitoring and Evaluation manager in EGA
2 Development of a Monitoring and Evaluation framework including financial and non-financial indicators
3 Include M&E as part of Supreme Council's functions
4 Establish MIS to track project progress
5 Regular Customer Satisfaction Index surveys
6 Regular SLA monitoring
7 Independent Audit of eGovernment performance
8 Financial progress reporting
54
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No Description Page No
1 Prioritization of services 56
2 Services to be delivered in Year 1 56Annex 3- Service Prioritization
*connectedthinking 55
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
3 Services to be delivered in Year 2 63
4 Services to be delivered in Year 3 68
Prioritization of servicesDuring 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.
56
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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 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. No.
Service Department Delivery Channel
Informational Services
1. Information on departmental services and
processes
All department Portal
CSC
Contact Center
2. Information on employment opportunities in RAK
government departments
Civil Services Portal
CSC
Contact Center
3. Application Download for applying for available
employment opportunities
Civil Services Portal
57
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No.
Service Department Delivery Channel
4. Information on rules, eligibility criteria and
processes for applying for different positions
Civil Services Portal
CSC
Contact Center
5. Information on rules and regulations, eligibility
norms, fees and other obligations to avail different
services of Economic Department
Economic
Development
Portal
CSC
Contact Center
6. Information on retirement benefits Finance Portal
CSC
7. Providing budgetary reports for all government
departments.
Finance Portal
CSC
8. Submission of reports to the Crown Prince of RAK
as required
Finance Portal
CSC
9. Information service on property registration
process, rules, fees and other regulations
Land Portal
CSC
Contact Center
10. Application and Forms download for applying for
property registration
Land Portal
CSC
11. Encumbrance certificate Land Portal
CSC
12. Customer service Land Portal
CSC
Mobile
Contact Center
13. Information on the functioning of various different
courts, their duties and obligations
Courts Portal
CSC
Contact Center
14. Information on the functioning of Port, its
processes and business enablement services
Saqr Port Portal
CSC
Contact Center
15. Information on fee details for services provided by
Saqr Port
Saqr Port Portal
CSC
Mobile
Contact Center
58
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No.
Service Department Delivery Channel
16. Application form for health card Saqr Port Portal
CSC
Contact Center
17. Information service on Building Permit,
Advertisement Permit, Health Cards and
Certificates, renewal of shop agreements, etc.
Municipalities Portal
CSC
Mobile
Contact Center
18. Fee information, rules and regulations for
obtaining Building Permits, Advertisement Permit,
Pest Control Certificate, Health Certificate, etc.
Municipalities Portal
CSC
Mobile
Contact Center
19. Information service on Town Planning
departmental rules, fees and other regulations
Town Planning Portal
CSC
Contact Center
20. Forms download for Town Planning departmental
services
Town Planning Portal
CSC
21. Application download for Issue of Export
Certificate, organizing exhibitions and fairs,
attesting agreements, etc
Chamber of
Commerce
Portal
CSC
22. Information service on the functioning of Chamber
of Commerce, its processes, rules, fees and other
regulations
Chamber of
Commerce
Portal
CSC
23. Naming of experts for inspection, evaluation,
pricing, listing, weighing and commodities.
Chamber of
Commerce
Portal
CSC
Contact Center
24. Rules and regulations for obtaining NOC on
building permit, Domestic Waste Violation, etc
Public works and
services
Portal
CSC
Mobile
Contact Center
25. Enquiry on Approved Bills Customs and
Ports
Portal
CSC
Mobile
59
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No.
Service Department Delivery Channel
Contact Center
26. Forms download for application for issue of
Customs Clearance and Transport Equipment
cards
Customs and
Ports
Portal
CSC
27. Real Estate Search Service Existing eServices Portal
CSC
Mobile
Contact Center
28. Etisalat Bill Query Service Existing eServices Portal
CSC
Mobile
Contact Center
Transactional Services
1. Commercial name reservation (Initial approval for
the formation of Company)
Economic
Development
Portal
CSC
Contact Center
2. Letters to citizens of RAK Economic
Development
Portal
3. Letters to commercial establishment Economic
Development
Portal
CSC
Contact Center
4. Permission for Sale/Advertisement Economic
Development
Portal
CSC
5. Payment of fines related to commercial activities Economic
Development
Portal
CSC
Mobile
Contact Center
6. provide Documents for property Land Portal
CSC
Mobile
Contact Center
7. Registration of the Cases Courts Portal
CSC
60
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No.
Service Department Delivery Channel
8. Building Permit Municipalities Portal
CSC
9. Advertisement permit For the advertisement site
and hoarding
Municipalities Portal
CSC
10. Renewing of the shop agreement Municipalities Portal
CSC
11. Health certificate for laborers Municipalities Portal
CSC
12. Comparing plan Town Planning Portal
13. Request from services - To take new electrical
connection / telephone / other services
Town Planning Portal
CSC
Contact Center
14. Issuing new Kroaky - allotment of plot Town Planning Portal
CSC
15. Renewing Kroaky Town Planning Portal
CSC
16. Duplicate site plan Town Planning CSC
17. Duplicate Kroaky plan Town Planning CSC
18. Kroaky plan by HH program Town Planning Portal
CSC
Contact Center
19. Processing of applications for organizing
exhibitions, fairs, conference, seminars and all
activities pertinent to economic issues and issuing
of approvals
Chamber of
Commerce
Portal
CSC
20. Providing NOC on the building permits
application
Public works and
services
Portal
CSC
21. Issuing importer codes Customs and
Ports
Portal
CSC
Contact Center
22. Payment of Sewerage bills Sewerage Portal
CSC
61
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No.
Service Department Delivery Channel
Mobile
Contact Center
23. Reservation and borrowing of books Documentaries
and Studies
Center
Portal
24. Real Estate Registration Service Existing eServices Portal
CSC
25. Etisalat Bill Payment Existing eServices Portal
CSC
Mobile
Contact Center
62
PricewaterhouseCoopers
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,
establishing commercial establishments,
permission for sale / advertisement, etc
Economic
Development
Portal
2. Publishing of Statistical year book Economic
Development
Portal
CSC
3. Information to citizens of welfare
expenditure
Finance Portal
CSC
Mobile
4. Information to individual employees on their
salaries, benefits and other perks as per
their eligibility
Finance Portal
CSC
5. Application for employee loans and salary
advances
Finance Portal
CSC
6. Provide statistical information Finance Portal
CSC
Contact Center
7. Information on case pronouncements Courts Portal
CSC
8. Complaints tracking and status Courts Portal
CSC
Mobile
Contact Center
9. Forms download for entry passes,
registration of Marine Agents, Birthing,
loading and unloading of goods
Saqr Port Portal
CSC
10. Notification Tanker Arrival Saqr Port Portal
CSC
Mobile
11. Forms download for applying for Health
Cards and Certificates
Municipalities Portal
CSC
63
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No. Service Department Delivery Channel
12. Forms download for licenses for foodstuff,
leasing industrial land, Renewal of leasing
agreement with companies, etc
Municipalities Portal
CSC
13. Location showing to allot a new Kroaky or
Site plan
Town Planning Portal
CSC
Mobile
14. Stating of conditions and specification for
defining the professional title of
businessperson and the preconditions for
conferment on eligible persons
Chamber of
Commerce
Portal
CSC
Mobile
Contact Center
15. Application download for NOC on building
permits
Public works and
services
Portal
CSC
16. Bill Advance Enquiry Customs and
Ports
Portal
CSC
Mobile
Contact Center
17. Examination recourses ( previous years
papers
Existing
eServices
Portal
CSC
18. Questions and Answers Service for
students
Existing
eServices
Portal
CSC
Mobile
Contact Center
Transactional Services
1. Receive employment applications for
positions
Civil Services Portal
CSC
2. Issuance of Business License Economic
Development
Portal
CSC
3. Citizen's Complaints about price higher than
displayed prices
Economic
Development
Portal
CSC
4. Customer Complaints on Business
Establishments
Economic
Development
Portal
CSC
5. Payment of salaries and grants Finance Portal
6. Property Registration Land CSC
7. Authentication of the documents Courts CSC
64
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No. Service Department Delivery Channel
8. Registration of Appeal cases Courts Portal
CSC
9. Provide family counseling Courts Contact Center
10. Issue of Marriage and Divorce Certificate Courts CSC
11. Registration of complaints Courts Portal
CSC
Contact Center
12. Issue of Port Entry pass Saqr Port Portal
CSC
13. Dispatch of monthly invoice to Marine
agents (the invoice can be raised
electronically)
Saqr Port Portal
14. Registration of Marine agents Saqr Port CSC
15. Tanker Registration Saqr Port Portal
16. Collection of the monthly invoice charges
from the marine agents
Saqr Port Portal
CSC
Mobile
Contact Center
17. Collection of fines for construction activities Municipalities Portal
CSC
Mobile
Contact Center
18. Practitioners Registration and renewal Municipalities Portal
CSC
19. Export Food Health Certificate Municipalities Portal
CSC
20. Pests control certificate Municipalities Portal
CSC
21. Fines against institutions for not following
Public health standards following
inspections
Municipalities Portal
CSC
Mobile
Contact Center
22. Updating the site plan Town Planning Portal
CSC
65
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No. Service Department Delivery Channel
23. Allotment of plots with respect to area Town Planning CSC
24. Changing Kroaky to site plan Town Planning Portal
CSC
25. Issuing of certificates of origin for export and
re-export purposes,
Chamber of
Commerce
Portal
CSC
26. Provide No objection certificate to other
service provider clearing the area (road
connected)
Public works and
services
Portal
CSC
27. Collection of fine from Domestic waste
violators
Public works and
services
Portal
CSC
28. Issuing certificate of no objection for
activities that require the approval from
customs department
Customs and
Ports
Portal
CSC
29. Issue of Books from Library Documentaries
and Studies
Center
Portal
CSC
66
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Table 3: Services to be delivered in Year 3
S. No. Service Department Delivery
Channel
Informational Services
1. Information on case proceedings and dates Courts Portal
CSC
Mobile
Contact Center
2. Appeals for delayed justice Courts Portal
CSC
3. Provide the Cause list of cases to be heard Courts Portal
CSC
Mobile
Contact Center
4. Building regulation Town Planning Portal
CSC
Mobile
Contact Center
5. Gathering and compiling of information, data
and statistics concerning issues such as price
of commodities, services bonds, securities,
currencies, etc… and processing, evaluations,
assessing and preparing of pilot and periodical
reports.
Chamber of
Commerce
Portal
CSC
Mobile
Contact Center
Transactional Services
1. Receive complaints from the community
members on various issues of civil service
Civil Services Portal
CSC
Contact Center
2. Renewal of commercial name Economic
Development
Portal
CSC
3. Renewal of business License Economic
Development
Portal
CSC
4. Payments for government entities Finance Portal
5. Registration of Old land without documents Land CSC
6. Mortgage Land CSC
67
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No. Service Department Delivery
Channel
7. Provide copies of the court documents
(Replacing official documents for Court
documents)
Courts CSC
8. Issue of Port entry passes through Marine
agents
Saqr Port Portal
CSC
Mobile
Contact Center
9. Providing the birthing service to the ships
-Request for loading service
-Request for unloading service
Saqr Port Portal
10. Provide the loading service to ships Saqr Port Portal
11. Provide the unloading of goods service on
ships
Saqr Port Portal
Contact Center
12. Provide the health cards for the employees
through municipality
Saqr Port CSC
13. Provide anchorage services to the ships Saqr Port Portal
Contact Center
14. health cards for food handler Municipalities Portal
CSC
15. foodstuff establishment licensing Municipalities Portal
CSC
16. Spray of insecticide at individual homes on
request
Municipalities Portal
CSC
Contact Center
17. Collection of Rents for the markets Municipalities Portal
CSC
Mobile
Contact Center
18. Leasing of industrial land Municipalities CSC
19. Renewal of leasing agreement with companies Municipalities Portal
CSC
20. Plot demarcation Town Planning Portal
CSC
21. Extension of land Town Planning Portal
68
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No. Service Department Delivery
Channel
CSC
22. Replacement - Changing plot from one place to
another
Town Planning Portal
CSC
23. Merging of plots to one Town Planning Portal
CSC
24. Exchange between plots - kroakey Town Planning Portal
CSC
25. Compensation for property Town Planning Portal
CSC
26. Splitting of plot Town Planning Portal
CSC
27. New site plan with old ownership Town Planning Portal
CSC
28. Registering of all natural and juristic persons
licensed to practice activities stated in Article
No (7) of the chamber organization certificates.
Chamber of
Commerce
Portal
CSC
29. Authenticating, attesting and certificating of
documents, agreements and signatures of
member companies and establishments
Chamber of
Commerce
CSC
30. Rendering of consultation services and advice
or all issues relative to legal, commercial,
technical, economic concerns, to help
members, businesspersons and investors
foster and promote their activities
Chamber of
Commerce
Contact Center
31. Customs Warehouse Bill of Entry Clearance
(Customs Clearance)
Customs and
Ports
Portal
CSC
32. Issuing representative cards for customs
clearance
Customs and
Ports
Portal
CSC
33. Issuing cards for transport equipment and
machinery
Customs and
Ports
Portal
CSC
34. Sale of Books and CDs Documentaries
and Studies
Center
Portal
69
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Annex 4- Channel Strategy
*connectedthinking 70
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No Description Page No
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
71
PricewaterhouseCoopers
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,
anywhere.
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
72
PricewaterhouseCoopers
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
secure.
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.
73
PricewaterhouseCoopers
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:
74
PricewaterhouseCoopers
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 integration.
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
75
PricewaterhouseCoopers
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
services
phishing12 may discredit the channel
Common service
Center
provides direct and personal contact
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
one-stop-shop
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
self-service
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
76
PricewaterhouseCoopers
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.
77
PricewaterhouseCoopers
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.
ChannelsNo. of Services
Informational Transactional
eGovernment Portal 51 59
Common Service Center 49 67
Call Center 27 15
Mobile 16 9
78
PricewaterhouseCoopers
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.
79
PricewaterhouseCoopers
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
benefits:
The service delivery channel is up and running and providing the services in the promised
manner.
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
80
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Annex 5- Institutional Structure
*connectedthinking 81
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No Description Page No
1 Introduction 85
2 Suggested Institutional Structure 86
3 Steps to be taken for successful implementation of eGovernment
87
4 Sample Project Documentation Templates 89
82
PricewaterhouseCoopers
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
83
PricewaterhouseCoopers
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
84
PricewaterhouseCoopers
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 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:
85
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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 Quality Management Status Reporting Evaluation
86
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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
DOCUMENT ACCEPTANCE and RELEASE NOTICE
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>
Background/Context:Provide a brief explanation of the background and/or context of the project. (Try and keep this to little more than half a page)
Objective: 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’
87
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Target OutcomesTarget 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?'
Output(s): 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
Governance: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?
Resources: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 expenditures.
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 constraints.
Major Risks & Minimization Strategies:
What are the barriers to achieving project success (i.e. the 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 www.egovernment.tas.gov.au for more information.
88
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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 relationship.
Guidelines/Standards: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 begin.Id Description Who Scheduled
StartScheduled
FinishPredecessor
2. Project Status Report
<Project Name>
Status Report No.<n>
<dd-mm-yyyy>File No.: <xxxxxxx>
REPORT FOR: (Optional) eg <Project Name> Steering Committee
PROJECT MANAGER: <Name>
PROJECT OBJECTIVE: As stated in the Project Business Plan.
89
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Project Progress Summary:A brief statement of project performance not covered in the remainder of the report.
MilestonesThis 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 milestone
Briefly describe any changes to the project schedule required as a result of the amended milestone(s).
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 Date
Current Target Date
Description of milestone dd-mm-yyyy dd-mm-yyyy dd-mm-yyyy
General InformationInclude 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.
Budget:
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 outputs.
90
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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 project
$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
Comments: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 Grad
eChange
Brief description of the Extreme, major A and B grade risks or any significant changes in grading, and new risks identified.
Low/Medium/High
Low/Medium/High
Increase/Decrease/New
Risk Grading Key:
GradeE Extreme
A High/High
B High/Medium or Medium/High
C High/Low or Medium/Medium
D Medium/Low
N Low/Low
91
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No Description Page No
1 Introduction 96
2 Need for Capacity Building 96
Annex 6- Capacity Building Strategy
*connectedthinking 92
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
3 Capacity Building Plan 97
4 Implementing the Capacity Building Plan – Action Points (Individual Agencies)
102
5 Issues and Risks 103
Capacity Building and Change Management
1.1 IntroductionEGovernment 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.
93
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
1.1.1 Need for Capacity Building There are a number of important reasons for the Emirate to focus on capacity building. These include:
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 management, project management, vendor management, customer management, etc need to be enhanced in order to effectively manage and implement eGovernment projects.
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.
1.2
1.2.1 Capacity Building PlanIn 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
1.2.1.1 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:
94
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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 time.
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 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.
1.2.1.2 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 undertaken:
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 functionaries.
95
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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.
1.2.1.3 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.
96
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
1.2.1.4 Development of skill sets amongst the customersPromotion 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 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.
1.2.1.5 Government wide knowledge sharing and coordinationDevelop 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 toolseLearning 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.
1.2.1.6 Change Management PlanThe 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:
97
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Change Management Plan
Ability to chanjhhbghghghge &
Transform
Empower the change
agents
Communicate the change
vision
Generate Short Term
Wins
Consolidate gains & produce
more changes
Embed new approach
in org. culture
Replicate the success stories
Align rewards & processes
Implement the change plan
Identify successful change patterns
Fix accountability Finalize goals & timelines
Survey outcomes to be used as input for design phase
Implement communication strategy
Finalize change team
Org Survey to measure readiness to change
Form the steering committee
Train the change agents
Empower change agents Communicate
change vision Generate short term wins
Consolidate gains and produce more changes
Embed new approach in departmental culture
Build learning Organization
Measures Structures Rewards Skills Culture
Build the guiding coalition
Ability to change and transform
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 change.
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.
98
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
1.2.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
1.2.3 Implementing the Capacity Building Plan – Action Point (Training institute)
Create a vision and strategy group to ensure that organisational and leadership capacity is both developed and exploited
99
PricewaterhouseCoopers
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
1.2.4 Implementing the Capacity Building Plan – Action Points (Individual Agencies)
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.
1.2.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
100
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
101
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Annex 7- Marketing and Awareness Strategy
*connectedthinking
102
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No Description Page No
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 and improvement
110
103
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Marketing and Awareness Strategy
Introduction
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.
104
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
2. Communication and media channel mix
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.N
ewsp
aper
s
TV Bill
boar
ds
Dire
ct
mai
lers
Mal
ls
Bus
ines
s pu
blic
atio
ns
Cha
mbe
r
of
Com
mer
ce
Mos
que
Wor
ksho
ps
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.
105
PricewaterhouseCoopers
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 Development
Work with the implementation team to track key milestones and likely timing
Identify generic messages in advance, plan and prepare drafts for publication
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 commitment
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? What will stay the same?
106
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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.
107
PricewaterhouseCoopers
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
communications.
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.
108
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No Description Page No
1 Strategic control over the Application 113
2 Application Audit 114Annex 8- Strategic Control Checklist
*connectedthinking 109
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
3 Code Signing 114
4 Version Control 114
5 Role Segregation 115
6 Strategic control over Database 115
110
PricewaterhouseCoopers
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 documents.
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 request.
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.
111
PricewaterhouseCoopers
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 intervals.
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 audit.
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 integrity.
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
112
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
# Strategic Control Requirements Compliance
regard.
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 RAK EGA.
b) Any changes to the database structure, required to
113
PricewaterhouseCoopers
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 actions).
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.
114
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Annex 9- Standards and Policies
*connectedthinking 115
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No Description Page No
1 Centralized Metadata 119
2 Database Standards and Guidelines 121
3 Application Architecture 127
4 Component ware Architecture 147
5 Application Communication Middleware Architecture
151
6 Network Architecture 153
7 Integration Architecture 159
8 Information Security Standards and Guidelines
178
9 Business Continuity and Disaster Recovery Guidelines
191
116
PricewaterhouseCoopers
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 model.
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
117
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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 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 collaboration.
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 distinctmetadata 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.
118
PricewaterhouseCoopers
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 database.
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.
119
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Good Practice 4: Replicate stable data, based on business and performance requirements.
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 infrastructure.
Standards
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
waiver.
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
120
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
implement an audit process within the application to ensure that the activities of each user are captured.
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 involved.
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
121
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
specific user. The generic user account and password used to access data in the back end must be protected and
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 possible.
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 layer.
Password and data encryption in databases and end user systems can be provided by third party products.
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.
122
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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.
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 information.
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 viewing.
Store passwords in an encrypted format when possible.
123
PricewaterhouseCoopers
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 deployment.
124
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Application Architecture
Software Development MethodologyThis 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
Industry Standards and best practices
• COBIT management guidelines
• ITIL
• COBIT
• Alignment assessment
• COBIT compliance check
• Benchmarking, surveys
• ISO20000
• ISO 17799
• CobiT compliant etc
• Finalise migration preparation
• Prepare new procedures
• Migrate data
• Finalise migration effort
• Project completion
• Complete testing plans and material
• Prepare testing environments
• Perform Tests
• Transfer to production system
• Conduct user acceptance testing
• Prepare development framework
• Develop system databases
• Conduct detailed design
• Establish operations functions
• Complete migration design
• Code and test development components
• Develop logical design models
• Design interfaces
• Design subsystems
• Complete system support specifications
• Specify data conversion system
• Cost benefit analysis
• Analysis planning and initiation
• Define user needs
• Current system review
• Prototyping
• Functional specifications development
• Cost benefit analysis
• Request for proposal
• Evaluate tenders
• Solution definition
• Project scoping and evaluation
• Define project boundaries and milestones
• Develop work breakdown and structure
• Prepare project schedules and budgets
• Prepare project team and additional resources
• Prepare project plan
ImplementationTestingDevelopmentDesignRequirement Analysis
Project Initiation
Industry Standards and best practices
• COBIT management guidelines
• ITIL
• COBIT
• Alignment assessment
• COBIT compliance check
• Benchmarking, surveys
• ISO20000
• ISO 17799
• CobiT compliant etc
• Finalise migration preparation
• Prepare new procedures
• Migrate data
• Finalise migration effort
• Project completion
• Complete testing plans and material
• Prepare testing environments
• Perform Tests
• Transfer to production system
• Conduct user acceptance testing
• Prepare development framework
• Develop system databases
• Conduct detailed design
• Establish operations functions
• Complete migration design
• Code and test development components
• Develop logical design models
• Design interfaces
• Design subsystems
• Complete system support specifications
• Specify data conversion system
• Cost benefit analysis
• Analysis planning and initiation
• Define user needs
• Current system review
• Prototyping
• Functional specifications development
• Cost benefit analysis
• Request for proposal
• Evaluate tenders
• Solution definition
• Project scoping and evaluation
• Define project boundaries and milestones
• Develop work breakdown and structure
• Prepare project schedules and budgets
• Prepare project team and additional resources
• Prepare project plan
ImplementationTestingDevelopmentDesignRequirement Analysis
Project Initiation
Requirements AnalysisThe 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.
125
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
i. ProcessThe 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
1 Agencies shall identify a Project Management Team (PMT) for the successful realization of the project objectives.
126
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Schedule a walkthrough meeting at least two working days after members receive document
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 PhaseDuring 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. ProcessThe 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.
127
PricewaterhouseCoopers
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 document
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 PhaseThe 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.
128
PricewaterhouseCoopers
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: WalkthroughsAt 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 team
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 vendor.
Systems Testing PhaseDuring 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. ProcessThe 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
129
PricewaterhouseCoopers
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 requirements.
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 TestingS. 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 involved.
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
Testing used to determine whether other system software components such 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.
130
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
S. No Types of Testing Description
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 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
Testing with the intent of determining how quickly a product handles a 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 tests.
13. Security & Controls Testing
Testing of controls built into the application surrounding the transactions (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
131
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Conduct system test
Document results of system test
Complete user manual
Update test plan (acceptance test)
Finalize customer-training plan.
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 PhaseThe 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.
132
PricewaterhouseCoopers
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 ManagementDuring 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
133
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
terms of 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 ManagementAs 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 ImplementationDifferent 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
134
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Version management including managing and tracking software releases and their distribution.
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 minimum.
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 ApplicationsRecommended good practices applicable to designing and developing of applications include:
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
135
PricewaterhouseCoopers
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 possible.
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-units.
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 management.
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
136
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Code flow and indentation
Error and exception detection and handling
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 interfaces.
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
137
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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.
The use of ASP or other HTML publishing is acceptable for publishing only (not business logic) but JSP and servlets are preferred.
138
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Application and Portal ServersApplication 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 projects.
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 SuiteLeading 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.
139
PricewaterhouseCoopers
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 vendors.
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 ServerPortal 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.
140
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Integration ServerAn 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 ServerThis 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 architecture.
Development and DeploymentAll 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 ServerAs 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 FeaturesOn 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:
141
PricewaterhouseCoopers
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.
142
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Managing ApplicationsDue 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 failing.
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
143
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
applications support.
Applications should only report. Interpreting the reports and deciding on the appropriate response 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 off.
Make application configurations parameter-driven, so applications can be reconfigured without recompiling and redistributing code.
144
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Component ware Architecture
Component ReuseA 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 components
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.
145
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Good practice 3: Establish a repository for maintaining the information about available reusable components
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 jobs.
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 developers.
Good practice 5: Harvest components from existing applications to initially build the component repository
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.
146
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Component ServicesA 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.
147
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Object-oriented ComponentsObject-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 critical.
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.
148
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Application Communication Middleware Architecture
Application Communication MiddlewareRecommended good practices applicable to application communication middleware types include:
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 components.
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 BrokersFor 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
149
PricewaterhouseCoopers
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 autonomy.
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 middleware.
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 engine
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.
150
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Network Architecture
Local Area Network (LAN) ArchitectureRecommended 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.
151
PricewaterhouseCoopers
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 reviewed.
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 method.
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.
152
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Network-Centric ApplicationsThis 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.
153
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Good practice 5: When data has to be distributed to multiple points (e.g., software and content 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 servers.
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 next.
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.
154
PricewaterhouseCoopers
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 response.
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.
155
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Integration Architecture
Application IntegrationAn 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 alternative
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-
156
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
invasive solution is selected, capitalize on using the entry or exit points that best apply to your application needs.
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 included.
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 message.
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 possible
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.
157
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Data Access IntegrationData 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.
158
PricewaterhouseCoopers
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 possible
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 calls
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.
159
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
XMLXML (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
160
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
security services.
Guideline 4: Monitor developments on the XML standards development forums
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 ProtocolsXML 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.
161
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Related Informationwww.oasis-open.org – Organisation for the Advancement of Structured Information Standards that creates XML standards
www.xml.org and www.w3.org/xml – Source of information on XML standards, schemas, tools
www.w3.org/tr/xsl – Information on XSL
www.xbrml.org – Source for work on business reporting using XML
www.hr-xml.org – Source of information on HR-related XML schemas
162
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Services Oriented ArchitectureWeb 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
163
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Figure 7 SOA: Foundation standards overview
UDDIRegistry
WSDL
WebServiceSOAPService
Consumer
Points to description
Points to serviceFindsService
Communicates withXML Messages
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 (UDDI).
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
164
PricewaterhouseCoopers
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,
165
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Microsoft, IBM, and VeriSign jointly published WS-Security2, 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 solutions.
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 subsections.
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 applications.
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
2 Draft specification for Web services security, in the second quarter of 2002
166
PricewaterhouseCoopers
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
167
PricewaterhouseCoopers
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 another.
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.
168
PricewaterhouseCoopers
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 2002.
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
169
PricewaterhouseCoopers
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
3 BizTalk™ and Biztalk Framework™ are registered trademarks of Microsoft Corporation.
170
PricewaterhouseCoopers
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 experience.
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 BPEL4WS.
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 VocabulariesVocabulary 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
4 Further Universal Business Language Naming & Design Rules v1.0 (UBL NDR) was approved as an OASIS standard in January 2005.
171
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
and cXML.
Financial Information Exchange
FIX is a protocol-messaging standard for real-time electronic exchange of securities transactions.
Financial Products Markup Language
FpML is a business information exchange standard for processing and dealing in financial derivatives instruments.
Human Resources Management Markup Language
HRMML is a standard suite of XML specifications for human resources-related data exchanges, including benefits enrolment, staffing, resume processing, and general employee profiling.
Interactive Financial Exchange Forum
IFX is a specification covering the exchange of bill presentment and payment, credit card statements, direct debits, and other information between financial institutions and their suppliers and customers.
International XML Retail Cooperative
IXRetail is a digital receipt schema for standardizing sales transaction information, including point-of-sale, inventory, and customer service channels.
Legal Information Exchange
LegalXML specifications cover electronic court filing, court documents, legal citations, transcripts, and criminal justice intelligence systems.
Market Data Definition Language
MDDL is a standard interchange mechanism for trading and market-related information, including economic and social indicators.
Mortgage Industry Standards Maintenance Organization
MISMO data standards cover credit, underwriting, mortgage 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 Markup Language
RETML is a standard for exchanging real estate transaction information.
Research Information Exchange Markup language
RixML is used to categorize, aggregate, compare, sort, and distribute global financial research.
Extensible Business Reporting Language
XBRL is a specification for the publication and exchange of companies’ financial reports.
XML Common Business Library
XCBL business documents are made available as a set of SOX (Commerce One’s Schema for Object-Oriented XML).
XML Payment Specification
XMLPay is a specification developed to help Internet merchants 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-commerce.
172
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Information Security Standards and Guidelines
Identification
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
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 links.
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.
173
PricewaterhouseCoopers
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 system.
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 authorization.
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.
1.2.5.1.1 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 restricted.
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
174
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
minimum length of ten (10) characters and conform to password standardso 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 software
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.
1.2.5.1.2 Guideline 2: Make use of industry products for applications requiring public key certificate authentication.
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 ControlAuthorization 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 data
175
PricewaterhouseCoopers
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 documented.
Internal Access ControlInternal 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 administrators
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 administrators.
External Access ControlExternal 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. Perimeter defences such as firewalls
176
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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 ControlThe recommended good practices in this section pertain to authorization and access control.
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
security-aware.
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.
177
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Implementation Guidelines for Authorization and Access ControlThe 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
schemes.
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 controlled.
Remote or dial-in access to the agency systems must be authenticated at the firewall or through authentication services placed on the DMZ.
178
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
StandardsThe 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 browser.
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.
Administration
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 responsibilities
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.
179
PricewaterhouseCoopers
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 agencies.
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
infrastructure.
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
architecture. Security policies may vary between domains requiring protective measures or gateways to traverse
differences in policies.
Audit
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
180
PricewaterhouseCoopers
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 analysis.
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 attachment/detachment.
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 information, the past experience of system misuse, and the extent of the system inter-connections.
181
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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 months.
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 managementFeatures 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 informationThe 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 solutionThe 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 platformThe 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 servicesThe 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.
182
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
Secure storage of critical itemsThe 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 abilitiesThe security solution must provide for session settings such as idle or max session time-outs, concurrent sessions and other session control settings
2 Web Access Filtering
3 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 MonitoringThe 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 ManagementThe 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
183
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
audit of network, server and application security mechanisms.
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 RequirementsThe 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 agencies.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 (http://www.w3.org/TR/xmldsig-core/) 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 context.
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,
184
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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 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.
185
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
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 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 disaster.
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.
Definitions:
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 disruption.
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
186
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
government an excellent opportunity to alleviate or minimize potential problems that would disrupt the service delivery and operations.
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.
187
PricewaterhouseCoopers
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 facilities.
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 process/application.
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.
188
PricewaterhouseCoopers
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.
189
PricewaterhouseCoopers
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 operations.
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 capabilities.
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 location.
190
PricewaterhouseCoopers
Annexes – eGovernment Strategy for Government of Ras-Al-Khaimah
191