4of4_Annex_v4.0

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



3

Annex 1- AS-IS Assessment

*connectedthinking



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



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



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



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



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



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



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

http://www.rak.ae/



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



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



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

http://www.rak.ae/

http://www.rak.ae/



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



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



Department Website MaturitySaqr Port Phase IIISewerage Authority NATown Planning and Survey English Version NA.

16



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



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



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



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



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



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



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



• 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



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



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



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



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



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

http://www.rak.ae/



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



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



• 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



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



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



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



• 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



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



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



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.


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



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


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



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



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



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



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


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



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


available through

contact center


available

Strategic Dimension : Channel Enhancement Contact Center



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


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


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



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


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




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


available through CSCs


available through CSCs




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



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



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


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



Institutional Structure: Way Forward

Capacity Building: Way Forward

52



Marketing and Awareness: Way Forward

Standards and Policies: Way Forward


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


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



Monitoring and Evaluation: Way Forward


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



S. No Description Page No

1 Prioritization of services 56

2 Services to be delivered in Year 1 56Annex 3- Service Prioritization

*connectedthinking 55



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



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


57



S. No.


4. Information on rules, eligibility criteria and

processes for applying for different positions


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



S. No.


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.


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


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



S. No.


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



S. No.


8. Building Permit Municipalities Portal

CSC

9. Advertisement permit For the advertisement site

and hoarding


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


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



S. No.


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




S. No. Service Department Delivery Channel


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


CSC

63




12. Forms download for licenses for foodstuff,

leasing industrial land, Renewal of leasing

agreement with companies, etc


CSC

13. Location showing to allot a new Kroaky or

Site plan


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


1. Receive employment applications for

positions


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




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


CSC

Mobile

Contact Center

22. Updating the site plan Town Planning Portal

CSC

65




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




S. No. Service Department Delivery

Channel


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


1. Receive complaints from the community

members on various issues of civil service


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




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


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




Channel

CSC

22. Replacement - Changing plot from one place to

another


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



Annex 4- Channel Strategy





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



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



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



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



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



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



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



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



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



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



Annex 5- Institutional Structure





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



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



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



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



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

http://www.egovernment.tas.gov.au/themes/project_management/?a=13494












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





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

http://www.egovernment.tas.gov.au/



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



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



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




1 Introduction 96

2 Need for Capacity Building 96

Annex 6- Capacity Building Strategy




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



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



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



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



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



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



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



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



101



Annex 7- Marketing and Awareness Strategy

*connectedthinking

102




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



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



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



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



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



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




1 Strategic control over the Application 113

2 Application Audit 114Annex 8- Strategic Control Checklist




3 Code Signing 114

4 Version Control 114

5 Role Segregation 115

6 Strategic control over Database 115

110



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




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


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


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


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




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


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


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




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



Annex 9- Standards and Policies





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



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



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



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



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



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



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



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



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



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


• 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


• Analysis planning and initiation

• Define user needs

• Current system review

• Prototyping

• Functional specifications development


• 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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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

http://www.w3.org/TR/xmldsig-core/



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



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



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



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



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



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



191

4of4_Annex_v4.0

Documents

Transcript of 4of4_Annex_v4.0