e-Governance Blueprint for India

A Concept Note

July 2004

5th Floor, Press Trust of India Building

4, Parliament Street
New Delhi 110 001
 e-Governance Blueprint for India

Table of Contents

1 INTRODUCTION............................................................................................................. 1
1.1 Governance vs. Government............................................................................................. 1
1.2 Information Types............................................................................................................... 1

2 E-GOVERNANCE STRATEGY................................................................................................2
2.1 Citizen-Focused Government............................................................................................ 2
2.2 Accessible Services........................................................................................................... 3
2.3 Inclusiveness...................................................................................................................... 3
2.4 Managing Information........................................................................................................ 3
2.5 Managing Change............................................................................................................... 3

3 ARCHITECTURAL MODEL.............................................................................................5
3.1 Business Architecture........................................................................................................ 6
3.2 Data Architecture................................................................................................................ 7
3.3 Application Architecture.................................................................................................... 8
3.3.1 Conceptual/Process Model............................................................................................ 8
3.3.2 Interoperability Model.................................................................................................. 10
3.4 Technology Architecture.................................................................................................. 15

4 SUGGESTED APPROACH............................................................................................17
4.1 Driving Principles............................................................................................................. 17
4.2 Key Attributes................................................................................................................... 18
4.3 e-Gov Solution Framework.............................................................................................. 18
4.3.1 Business Architecture................................................................................................. 19
4.3.2 Data Architecture.......................................................................................................... 19
4.3.3 Application Architecture.............................................................................................. 20
4.3.4 Technology Architecture.............................................................................................. 20
4.4 Suggestions for e-Gov Initiatives in India............................................................................22

TCS Confidential i
 e-Governance Blueprint for India

1 INTRODUCTION

1.1 Governance vs. Government

"Governance" is a way of describing the links between government and its broader
environment political, social, and administrative. Governance is distinct from government in
that it concerns longer-term processes rather than immediate decisions. Governance is a set
of continuous processes that usually evolve slowly with use rather than change dramatically
(as with a change of government).

There are three categories of processes to cover the interactions between the government,
the public service, and the citizenry. The engagement process covers the interaction
between citizens and government; the consultation process covers the interaction between
public servants and citizens; and the implementation process covers the interaction between
the government and the public service.

1.2 Information Types

Information is a central resource for all staff and for all activities in government. It is the basic
ingredient in managing resources, executing functions, measuring performance and in
delivering service. The nature of work in government is information-intensive and the
following four main types can classify formal information.

Information to support public administration and regulation. This includes information

on various activities, people, enterprises, etc.
Information made publicly available, for example gazettes, notification, press
releases, published statistics, white papers and web sites.
Information to support internal management. It includes information about personnel
and financial management.
Information to support public services. This includes information on health (patient
records), public utilities (customer billing), transport (passenger reservation system), etc.

The following sections describe an overall e-Governance Strategy and

Architecture Model that can meet the needs of the citizens for e-Governance
services at time and location of their choice as well as the delivery channels (for
example, physically challenged citizens will need services to be delivered in a
manner suitable to them). The models proposed have taken into account best
practices from similar initiatives in different parts of the world.

TCS Confidential 1
 e-Governance Blueprint for India

2 E-Governance Strategy

Around the world, governments are transforming themselves to meet rising

public and business demands for more accessible and responsive services at an
affordable cost. The Information Age revolution has already brought huge
changes to both manufacturing and service industries all over the world. It has
driven down costs, brought suppliers closer to customers, and made them more
responsive to their needs. The use of information and communication
technology, especially Internet / Intranet based technology, has substantially
changed the operating environment for governments. The new technology offers
a number of tools to help cope with the change and to support real leaps forward
in service delivery. The term e-Governance is generally used to imply the use
and impact of information and communications technology, in governance.

The e-Governance should create a Service Oriented Environment (SOE) wherein

Citizens, Businesses and Global Stakeholders could transparently seek
governmental services through a single window or portal without the need to
pursue different wings of the central/state governments separately. Such a
consolidated service-delivery environment requires great deal of integration in
cross-governmental work processes. For this reason, e-Governance involves
much more than computerisation. Governmental processes should be
rationalised, wherein similar tasks are combined, redundant tasks eliminated and
overall service delivery process automated for completion in a deterministic
timeframe.

Such an integrated e-Governance environment needs a paradigm shift towards

an IT architecture designed to integrate most of the government
ministries/departments on a nation-wide scale. This architecture should be
capable of integrating existing systems as well as new projects planned to be
implemented in the coming years.

e-Governance has four guiding principles:

(a) Building services around citizens choices

(b) Making government and its services more accessible
(c) Social inclusion
(d) Using information better.

2.1 Citizen-Focused Government

When people interact with government they want to do so on their own terms.
They want high quality services, which are accessible, convenient and secure.
People should not need to understand how government is organised, or to know
which department or agency does what, or whether a function is exercised by
central or local government. The government needs a strategy that will provide
this - by helping departments and agencies, central and state governments, co-
operate in new partnerships that will offer their services in ways that make sense
to the customer. The governments need to form partnerships with innovators in
the private sector who can find new ways of meeting changing patterns of
demand.

TCS Confidential 2
 e-Governance Blueprint for India

2.2 Accessible Services

The Governments intention should be that that all services, which can be
electronically delivered, should be done so. The strategy should be that the
services should be accessible over the Internet and through mobile devices, TV
and call centres as well as through personal computers. The mix for any service
will be determined in relation to demand. Electronic service delivery does not do
away with the need for personal contact and this must be better supported.
Services should be tailored to individuals needs.

New ways of doing business will change the relationship between individuals and
government. Access to information will be firmly established and government
organisations will be more responsive to citizens views. At the same time, it will
be vital to make sure that people can trust the systems used, by ensuring that
their personal data is protected and that systems are secure.

2.3 Inclusiveness

New services must be developed so that they are available to all and easy to
use. TV and mobile phones will become increasingly important as a means of
accessing the Internet. The Government should be committed to making it easier
for all people to get access, whether individually or through community facilities.
The telephone will remain a preferred means of contact for many. Call centres
must be improved by giving their staff access to information networks that will
enable them to provide better service. Better information systems will support
the work of those who have face-to-face contact with the public.

Online public services must be well designed and accessible to all. This includes
providing services for multiple linguistic groups and those with disability or
limited mobility. e-Governance is an opportunity to enhance the services, which
are provided to all citizens who wish to do business with the governments.

2.4 Managing Information

The Governments knowledge and information are valuable resources. At the

heart of the e-Governance program is the need for the public sector to make the
best use of them. Implementing the strategy requires organisations and
departments to adopt coherent and compatible information policies in support of
better policymaking, better service delivery and more efficient working.

2.5 Managing Change

The strategy should encourage innovators in government to identify new ways of

working in partnership with the private sector. It identifies the need for a strong
lead and effective support from the centre.

To following framework describes the various building blocks of an e-Governance.

TCS Confidential 3
 e-Governance Blueprint for India

Figure 1: Building Blocks for e-Governance1

The following sections describe an overall architecture model that can meet the
needs of the citizens for e-Governance services at time and location of their
choice as well as the delivery channels (for example, physically challenged
citizens will need services to be delivered in a manner suitable to them).

1
European Union Approach

TCS Confidential 4
 e-Governance Blueprint for India

3 ARCHITECTURAL MODEL

e-Gov initiatives require a comprehensive yet flexible architectural model that supports
development of complete requirements when planning, designing, and building major
systems. This is essential if the government is to achieve the following objectives:

(a) Leverage information technology investments and avoid unnecessary duplication of

infrastructure and major components

(b) Link business processes through shared, yet sufficiently protected information
systems

(c) Leverage disparate business processes, services and activities that are located
outside agency boundaries

In tune with this a four-layer segmented structure has been developed, and shown in Figure
2 below:

Figure 2: Layered Architectural Model for e-Gov Solutions2

(a) Business Architecture: This presents the Business Reference Model that
systematically identifies the business functions of the government.

(b) Data Architecture: This proposes the use of the Extensible Markup Language
(XML), which is key to e-Gov solutions.

(c) Application Architecture: This defines the major application components common
to e-Gov solutions, and includes two models:

2
Federal Enterprise Architecture (FEA) Approach

TCS Confidential 5
 e-Governance Blueprint for India

o Conceptual/ Process Model This provides the bridge between the

business view of the Business Reference Model and the systems view of the remaining
models.
o Interoperability Model This describes the common technical components
of an e-Gov solution and how they interoperate within and across various e-Gov
solutions.

(d) Technology Architecture: This provides pragmatic implementation guidance for e-

Gov initiatives in the form of a Technical Model for major components of an e-Gov
Solution and a Technical Reference Model.

3.1 Business Architecture

The Business Reference Model (BRM) provides an organized, hierarchical construct for
describing the day-to-day business operations of the government. The BRM is the first layer
of the proposed Architecture. It is the main viewpoint for the analysis of data, applications
and their capabilities, and the implementation of technologies to support reuse and
standards. This framework should be used by various departments when identifying and
building e-Gov architectures to ensure that investments leverage existing components,
applications, and services across the government.

The overall architecture addresses all of the following potential access methods to ensure
that the same comprehensive, consistent services are available no matter how access is
achieved:

(a) Personal Contact such as face-to-face, voice (telephone, interactive voice

response), videoconference

(b) Electronic such as facsimile, web browser, kiosk, system-to-system

(c) Delivery Channels such as through use of localized languages and services
delivered to meet needs of the citizens, including physically challenged citizens

(d) Paper such as traditional mail

(e) Service Providers such as commercial vendors, private/public partnerships,

procuring services against revenue expenses rather than buying infrastructure as
part of capital expenditure

The BRM identifies three Business Areas (Figure 2) that provide a high-level view of the
operations that the government performs:

(a) Services for Citizens: describes the mission and purpose of the government in
terms of the services it provides, both, to and on behalf of the citizens. It includes the
delivery of citizen-focused, public, and collective goods and/or benefits as a service
and/or obligation of the government to the benefit and protection of the nation's
general population.

(b) Support Delivery of Services: provides the critical policy, programmatic and
managerial foundation to support government operations.

(c) Management of Government Resources: refers to the back office support activities
that enable the government to operate effectively.

TCS Confidential 6
 e-Governance Blueprint for India

Figure 3: Business Architecture Model3

The upper two tiers address user access to the functions of the government defined in the
BRM. A key consideration for e-Gov initiatives is the potentially wide variety in users, the
kinds of interactions they need, and the kind of access methods they use.

3.2 Data Architecture

The Data Architecture defines the major types of data needed to support the business, its
meaning, and form. Common data vocabulary and definitions are especially critical for e-Gov
solutions, which frequently cross traditional, organizational, functional, and system
boundaries. This not only includes operational data, but also analytical data, and web
content.

Unified Modeling Language (UML) could be used for documenting these data models and
common requirements. This helps foster consistency and integration across e-Gov
initiatives.

The eXtensible Markup Language (XML) provides a critical foundation for e-Gov data
architectures. XML is emerging as the industry and government standard for moving and
sharing information both among different entities and systems, and even among
components of a system.

3
FEA Representation

TCS Confidential 7
 e-Governance Blueprint for India

All e-Gov initiatives should define and implement an approach for using XML. Where new
development or re-development are pursued, XML should be considered for use as the
default format for highly structured data as well as relatively less structured information,
particularly at the User Interface layer and also at the Enterprise Repositories level. For
legacy repositories that do not directly support XML, legacy to XML mapping and data
transformation can be used to support interoperability across the data architecture.

The power of e-Gov solutions to integrate data across traditional stovepipes and directly
interact with the public also increases potential privacy concerns. e-Gov initiatives need to
identify privacy sensitive data elements in advance of deployment to ensure that they are
handled and safeguarded according to applicable regulations. For highly sensitive data such
as citizens fingerprints, e-Gov initiatives should also include a privacy impact analysis,
which attempts to scrutinize the impact of any breach of confidentiality of sensitive data.

e-Gov solutions often require data that comes from multiple back-end systems and
databases associated with multiple organizations and functional areas. There is no single
right answer to providing integrated data. The appropriate architecture will depend on the
type, volume, and nature of the information being shared:

(a) Analytical data might be combined from multiple operational data stores into a
hierarchy of data warehouses using a variety of data extraction and movement tools.
Or, it could be supported through virtual databases, which leave the data in its
original location, but provide the appearance of an integrated database.

(b) High transaction volume interaction of operational data might be supported through a
message broker infrastructure that links e-Governance and legacy applications. A
distributed message broker infrastructure could combine message brokers into wider
levels of integration.

(c) An interactive e-Gov solution might require extracting parts of legacy operational
databases and combining them into a new hybrid operational database with
synchronization to the underlying operational systems.

As e-Gov initiatives define their Data Architectures they should ensure that the Data
Architecture can be deployed effectively and that appropriate data integration infrastructure
is identified and implemented.

3.3 Application Architecture

The Application Architecture defines the applications and supporting capabilities to

effectively manage the data and information needed to support business and performance
objectives.

3.3.1 Conceptual/Process Model

The Conceptual/Process Model provides the bridge between the purely functional view of
the BRM and the more system / technology focused models that follow. The architectures for
e-Gov initiatives should address all layers of the Conceptual/ Process Model.

Figure 3 represents the application architecture model and the following sections describe
each of its elements.

TCS Confidential 8
 e-Governance Blueprint for India

Figure 4: Application Architecture Model4

End users represent the variety of users described in the BRM. e-Gov initiatives should
understand their target user population and the ways in which they will use the e-Gov
solution (e.g., information access vs. financial transactions)

Access Portal represents the web/internet based access approaches such as web
browsers, system-to-system, and emerging devices such as Personal Digital Assistants and
e-capable phones. e-Gov initiatives should determine which access methods are needed
both now and in the reasonable future. They should also determine which non e-Gov access
methods (e.g., phone, regular mail) provide similar support for similar users and determine
where e-Gov and non e-Gov solutions can leverage a common back-end infrastructure.

Cross Cutting Requirements are common to all e-Gov application components in order to
meet regulatory requirements and user expectations:

(a) Single sign-on (access control) using secure authentication to all needed e-Gov
applications

(b) Disclosing use of privacy sensitive data and providing users appropriate control over
the use of their data in e-Gov solutions

(c) Maintaining records in unaltered form for as long as necessary to protect the rights of
citizens as well as to provide access to the valuable information gathered and
created using government systems

Web Platform application components support interactions with users:

(a) Application Services components provide common web capabilities such as portal
access with personalization for individual users and collaboration either
synchronously through conferencing or asynchronously through email and discussion
groups

4
FEA Representation

TCS Confidential 9
 e-Governance Blueprint for India

(b) Analysis components provide the capabilities for users to flexibly analyze and report
on data beyond the capabilities implemented in specific functional applications

(c) Content Management components provide e-Gov solutions with the ability to create,
deploy, and control the broad range of textual and multimedia content typical of many
e-Gov solutions

Applications Interface components provide a scalable mechanism for integrating the Web
Platform with enterprise repositories and operational systems that serve business
applications. The goals of the Applications Interface layer are to minimize the requirements
for development of multiple customized point-to-point integration solutions and to minimize
the impact to existing and future applications. The Applications Interface must be scalable to
accommodate anticipated processing needs and include robust security functionality to
prevent compromise of other systems it integrates with. A key for e-Gov solutions is the
Applications Interface components ability to reach outside of the agency or even
government and connect with other government, industry, or local government systems. For
example, several application architectures in India include Gateways for routing XML
formatted messages. The Gateways also provide secure conduits to integrate with other
government departments.

Enterprise Data and Applications components provide the core of the governments data
and business logic, including:

(a) Operational and analytical data

(b) Major legacy and e-Governance applications

Accessing and unlocking the power of these Enterprise Data and Application components is
critical for the success of many e-Gov solutions.

3.3.2 Interoperability Model

It describes the primary application components supporting the Conceptual/Process Model
and how they interoperate within and across e-Gov solutions. This includes interoperability
at the user, data, and application levels. The Interoperability Model reflects commonly found
industry representations, embracing industry standards and best practices. Many
components of the e-Gov Interoperability Model will be required for all e-Gov initiatives.
However, the business requirements of each e-Gov initiative will determine which
components are most critical or central to that initiative. e-Gov initiatives should identify the
critical components for their business requirements and ensure that those components are
robustly supported in their architecture.

Figure 4 represents the interoperability model and the following sections describe each of its
elements.

TCS Confidential 10
 e-Governance Blueprint for India

Network

Other Government,
Public Sector,
Business sites and
applications

Figure 5: The Interoperability Model5

(a) Web Browser provides a standard user interface to e-Gov capabilities for most
users. Initiatives that support public access should strive for compatibility with a wide
set of browser products and user machines by avoiding proprietary extensions and
mobile code that may be blocked by users.

(b) Devices such as Personal Digital Assistants and web enabled cellular phones
provide a growing capability for access to e-Gov capabilities from anywhere at
anytime without requiring a traditional Personal Computer (PC). There is a
tremendous variety in available capabilities (processing power, screen sizes, input
buttons) and connectivity options (different wireless network standards). Thus, it is
critical that e-Gov initiatives understand what kind of devices need to be supported
and how they will be used.

(c) Device Independence components isolate e-Gov solutions from the complexity of
the different devices and wireless networks and allow different devices to plug into
the same underlying e-Gov capabilities.

(d) Portals represent the leading concept for integrating many different information
sources into a single mechanism for interacting with the user. They also facilitate
providing services in a secured manner. Multiple e-Gov initiatives can share a portal,
and multiple portals can be linked to integrate even more information sources and
applications.

(e) Requestor Applications support the user interaction with e-Gov applications. This
includes interaction with the portal, generating web pages for display on users
browsers, managing the user interaction, and accessing needed applications and
data. The Requestor Applications and/or the Transaction Services, described below,
also maintain the users state (e.g., using cookies, hidden fields, extended URLs) to
overcome the underlying stateless nature of web interactions.
5
FEA Representation

TCS Confidential 11
 e-Governance Blueprint for India

(f) Transaction Services provide core business logic and performance, scalability, and
reliability capabilities needed to support high volumes of transactions. They can be
used to support reusable business components based on widely available industry
component models.

(g) Content Management provides capabilities to manage the large volume of web
content (textual and multimedia) typical of many e-Gov initiatives. This includes
creation, storage and management of multiple versions of content along with
branding and appearance templates to standardize the appearance of the content.
One potential future trend is towards Enterprise Content Management that integrates
Content Management, Data Management, and Records Management into one set of
components.

(h) Collaboration provides for both synchronous (e.g., video/audio conferencing, shared
applications/whiteboard) and asynchronous (e.g., email, discussion groups)
collaboration among users both internal and external to the government.

(i) Business Intelligence provides capabilities to flexibly analyze and report on

structured data beyond the capabilities built into specific functional applications. This
can range from ad hoc reporting, to Online Analytical Processing (OLAP) of multi-
dimensional data, to sophisticated data mining or statistical analysis. For e-Gov
initiatives which cross traditional functional, organizational, or system stovepipes, this
may require creation of an analytical data store combining data from multiple existing
data warehouses or operational systems.

(j) Common Services include directory, time, naming, and other services required for
an interoperable distributed systems environment. They may also include specific
services to support cross cutting requirements such as security (e.g., access
controls, privacy rules, logging, and e-Authentication services).

(k) Intra/Inter Enterprise Integration (Figure 5) provides the backbone linking e-Gov
solutions to other e-Gov solutions and legacy applications and data, both, within and
outside the government. Many e-Gov initiatives involve value chains that cross
existing functional, organizational and system boundaries. This may require
integrating multiple systems (in multiple organizations) on a near real-time basis, and
with transactional robustness. The resulting e-Gov solution is really a composite
application that combines processing and data capabilities of multiple systems into
one end-to-end solution. Intra/Inter Enterprise Integration Components must support
connectivity to commercial applications (such as Enterprise Resource Planning
packages), web/e-Commerce vendor solutions, communications standards (such as
SMTP and http), middleware, commercial database packages, and a variety of older
and sometimes antiquated agency legacy applications. Since the late 1990s,
Message Brokers have been the dominant architecture for this kind of integration
within enterprises, especially where high volumes of transactions were required.

Message Broker architectures have also been extended to inter-enterprise

integration using XML and web transport standards. XML Web Services are an
emerging Intra/Inter Enterprise Integration approach to allow one application to
discover and use the capabilities of another application. (In some cases these
technologies are combined with Message Brokers using XML Web Services to
connect with e-Gov applications.) Web based e-Gov solutions can also be integrated
directly at the Portal or Requestor Application component level without going through
a robust Intra/Inter Enterprise Integration component. Finally, virtual data base

TCS Confidential 12
 e-Governance Blueprint for India

architectures can provide e-Gov initiatives with access (typically read-only) to

multiple operational data bases if this level of data integration is all that is required.

(l) Other e-Gov Applications will be involved in creating composite applications that
combine capabilities and data from multiple e-Gov initiatives. These other e-Gov
applications might be integrated through the Portal or Requestor Application
components, as well as through the Intra/Inter Enterprise Integration component.
Other e-Gov applications might also share common components such as Portals,
Authentication Services, or Message Broker backbones. Operational data in other e-
Gov applications may also be externalized and aggregated/transformed in data
warehouses (marts, cubes, etc.) to support sophisticated analyses.

(m) Legacy Applications contain the vast majority of the governments detailed
business logic and operational data. Integrating the business functionality and/or data
from these systems will be the key to many e-Gov initiatives. In some cases this can
be accomplished through periodic extraction of data into data warehouses or
combined operational data stores. However, in many cases, near real-time
application level integration will be required to support composite e-Gov solutions.
Many legacy systems were not architected and implemented with this type of
integration in mind. Thus, some sort of integration interface component may be
required for these systems to interoperate with the Intra/Inter Enterprise Integration
components.

(n) Analytical Data components represent data warehouses (data marts, etc) of
aggregated and transformed data from operational systems. Often there will be a
hierarchy of data warehouses of progressively higher functional or organizational
scope. Cross functional/organizational e-Gov Initiatives may be able to use existing
data warehouses directly or need to aggregate their own layer of analytical data for
the Business Intelligence component.

Four components of the Interoperability Model, as shown in Figure 5, reflect cross cutting
requirements to meet regulatory requirements and user expectations. The components are
described are further described in the following sections.

Security Architecture

The Security Architecture must be addressed from the beginning for every component of the
Interoperability Model, from:

(a) Authentication Common Services

(b) Single sign on through the Portal
(c) Access control by Requestor Application and Transaction Services
(d) Encryption of network communication to the Browser
(e) Logging of Intra/Inter Enterprise Integration messages and Legacy System database
updates
(f) Firewalls that protect the physical environment

An appropriate security management plan, including items such as risks analysis, standard
operating procedures, proper access controls, and business continuity, should be completed
at all levels of the enterprise. In order to properly manage security, a risk assessment and
risk mitigation strategy should be developed, and the owner at each level of the enterprise
architecture needs to understand and accept the residual risk. This process should be an
integral part of the certification and accreditation of all e-Gov solutions.

Privacy Architecture

TCS Confidential 13
 e-Governance Blueprint for India

Privacy similarly pervades the components of the Interoperability Model. For user interaction
components, it means explaining Privacy policies and what data will be used for and giving
users the option to control use of their data. For application components it means controlling
the access to Privacy Sensitive data and maintaining the integrity of that data. For
integration and analytical components, it means sensitivity to the privacy concerns of
aggregating data from previously separate systems and organizations with potentially
different privacy policies and safeguards.

Accessibility Architecture

Accessibility of e-Gov solutions is a requirement for all user-facing components of the

Interoperability Model (as well as supporting components such as documentation and
training.).

It is this component that meets the varying needs of user groups including the physically-
challenged ones who may need suitable model of delivering e-Gov Services.

Records Management

It ensures records (including email and increasingly multi media) are securely maintained in
unaltered form for as long as necessary to protect the rights of citizens as well as to provide
access to the valuable information gathered and created using government systems. The
applicable records in all e-Gov data stores need to be identified, stored, scheduled,
retrieved, transferred, destroyed, and securely controlled.

The boundaries of the different Interoperability Model components are not rigid. For
example, some Intra/Inter Enterprise Integration capabilities may be present in the
Transaction Services component. The components of the Interoperability Model reflect
logical capabilities, which may be implemented through a variety of products and
technologies. Some existing COTS/GOTS or new development products may directly
address a specific component (e.g., a Portal product). Others may combine parts or all of
several components within a specific product.

There is no one right mapping of Interoperability Model components to specific products. e-

Gov initiatives should consider several factors in defining specific products to support the
components of the Interoperability Model:

(a) e-Gov Initiatives should identify the most critical/central components given their
business requirements and consider selecting existing products or developing new
products whose strength is focused on those components;

(b) Care should be taken in implementing existing products that cover multiple
components just to use limited parts of their functionality (e.g., implementing an
integrated Customer Relationship Management product for its automated email
capabilities). While these products are becoming more modular, their key benefit is in
their integration of a wide range of application components. The cost of implementing
a robust product and integrating it into the architecture may outweigh the benefits of
the limited functionality needed from the product; and

(c) Initiatives should look not just at how well a product supports a given component or
set of components, but also how well it interoperates with all of the other
Interoperability Model components and products required for the solution.

TCS Confidential 14
 e-Governance Blueprint for India

An even more fundamental concern is which components of the Interoperability Model

should be addressed at the individual e-Gov initiative level, and which should be addressed
as common capabilities across e-Gov initiatives. In most instances it is not preferable to
have all of these components defined, architected, designed, and implemented on an
Initiative-by-Initiative level. Instead many should be defined and/or implemented at higher
levels in the chain. Some redundancy may prove necessary, but shared use of technologies
is better for interoperability, usability and smart investment.

3.4 Technology Architecture

The Technology Architecture defines the enabling hardware, software, and their physical
locations to support the business applications/data and functions.

Technology Models provide examples of how different components of the Interoperability

Model could be implemented with existing COTS/GOTS or new development.

Figure 6: Technology Architecture Model6

6
FEA Representation

TCS Confidential 15
 e-Governance Blueprint for India

The major components of the Technology Model are:

(a) Internet Application Server supports the presentation and interaction with the user;
transactional business logic; and supporting services that provide high security,
performance, scalability, availability, and connectivity to existing operational data and
systems. The dominant industry architectures for these types of these servers are:
The J2EE (Java 2 Enterprise Edition) architecture from SUN, which provides
portability across multiple operating systems and hardware
The .NET architecture from Microsoft, which is currently focused on Microsoft
operating systems running on Intel hardware

Leading Internet Application Server COTS products encompass many of the

web/application layer components of the Interoperability Model. Alternatively,
separate products are available for components such as the Portal or Web.

As described in the discussion of the Interoperability Model, e-Gov Initiatives must

carefully consider which components of the Interoperability Model they address in an
integrated product and which they address by combining multiple more focused
products. In general, integrated products or suites of tools may be preferred where
several tools are needed to establish the functioning web application, whereas less
integrated or single purpose tools may be appropriate if the proposed solution only
requires a few functions.

(b) Web Content Management Server allows the site manager(s) to automate,
manage, and control various aspects of content creation and formatting. They push
this managed content out to an organizations Internet Application Servers, often in
different formats supporting various browsing devices. At their core, web content
management systems address the issues of: change management, dynamic content,
workflow, design templates, repositories, replication and deployment, personalization,
security management, scalability, and integration and development tools. Web
Content Management solutions may be focused on content creation, content delivery,
or business analytics. A complete solution almost always includes features from all
three areas. There are a wide variety of integrated COTS Web Content Management
Server products available. Alternatively, basic Web Content Management Server
capabilities may be bundled into another enabling product such as an Internet
Application Server, or a business product such as a Customer Relationship
Management product.

TCS Confidential 16
 e-Governance Blueprint for India

4 SUGGESTED APPROACH

4.1 Driving Principles

The principles, which drive the approach emphasizing their applicability and importance to
this e-Gov guidance are:

Standards: Establish interoperability standards.

The government should adopt and use voluntary industry standards in which the
interrelationships of components are fully defined by interface specifications available to the
public and maintained by group consensus. For e-Gov solutions the focus of interoperability
is moving towards Internet and Web standards, XML, portals, new integration models such
as Message Brokers and XML Web Services, and increasing use of hosting or Application
Service Providers.

Investments: Coordinate technology investments with the business and architecture.

Investment decisions must be based on business and architectural decisions that are
aligned with the business needs of the government. Since the power of e-Gov solutions
often comes from integration across existing functional and organizational boundaries,
investments must also be looked at in this context. For e-Gov projects that reach out to the
masses, there must be a clear model for financial sustainability.

Data Collection: Minimize the data collection burden.

Data standardization, including a common vocabulary and data definition, will be difficult to
achieve but is critical. A common organization eliminates redundancy and ensures data
consistency. This is particularly important for e-Gov solutions that cross traditional
organizational and functional boundaries that previously represented separate islands of
data. Thus, the principle of enter once, use often must be addressed in a wider context
than in the past.

Security: Secure information against unauthorized access.

Appropriate security monitoring and planning, including an analysis of risks and
contingencies and the implementation of appropriate contingency plans, must be completed
to prevent unauthorized access to information. The requirements for information security
cannot be achieved merely by establishing a "trusted network." In the case of highly
sensitive information, each electronic record must be secured individually from alteration and
inappropriate access.

Functionality: Take advantage of standardization based on common functions and

customers.
Departments should develop or design reusable components, or purchase architecture
components, recognizing that these items are designed to obtain a particular functionality.
Standardization on common functions and customers will help departments implement
change in a timely manner. For e-Gov solutions, this applies both to components that
support common e-Gov functions across departments, and components that are needed to
support multiple e-Gov functions.

Information Access: Provide access to information.

The government should encourage a diversity of public and private access methods for
government public information. This should include multiple access points, and support for
informational, transactional, and analytical access. Accessibility involves the ease with which
users obtain information. Information access and display must be sufficiently adaptable to a

TCS Confidential 17
 e-Governance Blueprint for India

wide range of users and access methods, including formats accessible to those with sensory
disabilities.

Proven Technologies: Select and implement proven market technologies.

Systems should be developed based on global data classes and process boundaries.
Systems should be de-coupled to allow maximum flexibility. Incorporating new or proven
technology with full consideration to risk mitigation strategies will help agencies to cope with
change.

4.2 Key Attributes

The following points are the key attributes contributing to the solution:
Ensuring empowerment of all segments of the society and encouraging consensus
building and enhanced transparency
Creating a cost-effective, replicable, economically self-reliant and financially viable
model for taking the benefits of information technology to the masses
Improving the quality, speed and sensitivity of the state delivery apparatus towards
the needs of the local citizens
Enhanced participation in community affairs and governance through creative use of
information technology
Implementing a new grass-root entrepreneurial model with participation of groups of
non-traditional entrepreneurs
Encouraging public-private sector partnerships

4.3 e-Gov Solution Framework

Transforming the Architectural Model, described in Section 3, into a solution specific to a

government requires detailed analysis of the current environment in terms of IT
infrastructure, computer applications as well as future strategy. Such an analysis will also be
important due to the fact that different governments are at varying stages when it comes to
the implementation of e-Gov services. Moreover, Indian states differ greatly in terms of
regional languages, geographical terrain along with the availability of data communication
infrastructure. The following diagram summarizes an approach towards defining e-Gov
solutions.

Financial
Approach

Reduced Government New

up-front
costs
Improvement revenue
sources
Innovation
Utility
Payments Digital
Licenses
and Experience
Technologies Permits

Land
Internet
Kiosk Expertise
Records Smart Card
Others Procurement
Information
Mgmt
Tax Collection

Leakage
Containment Incentives

Figure 7: e-Gov Solution Framework

TCS studied the e-Governance Strategy Documents prepared by the Government of

India. Although prioritization of e-Gov applications should be determined by the officials

TCS Confidential 18
 e-Governance Blueprint for India

responsible for the governance of India, various architectures defined in the project report
should be defined before the implementation of any of the applications. For example,
architectures for application, middleware and integration should be finalized before
implementing any e-Gov application.

In line with the e-Gov action plan of the Government of India, the IT activities mentioned
have been mapped to the architectural model described in this Concept Paper.

4.3.1 Business Architecture

The proposed re-engineering effort of various departments and government services should
focus on the 3 tiers depicted in Figure 2. These tiers include Services to Citizens, Support
Delivery and Internal Operations / Infrastructure.

End users of e-Gov applications may need to be accessed across multiple channels. Hence
any proposed architecture must take into account all possible modes of delivery of services
to stakeholders, including citizens, businesses and government bodies. In fact, e-Gov
services are generally designed to serve a global audience.

It is recommended that as a first activity, a list of all departments in question be drawn and
the services offered by these various departments finalized. This is very important since the
proposed development of applications and the requisite infrastructure would directly depend
on the services to be offered. The re-engineering effort should focus on the relevant
departments and the most efficient and cost effective way to provide services. IT as a tool to
enable the service delivery as appropriate would then need to be finalized. The services and
information to be made available through the proposed portal would be driven by this effort.
The re-engineering effort could also focus on the content creation and maintenance of the
portal. Based on the findings of the re-engineering effort, priorities could be assigned to the
applications to be developed and a phased approach worked out.

Once the services to be delivered are finalized, the support systems needed for delivery of
services and the infrastructure needed could be drawn up. A key point to address is
interoperability of departments and the ability to support exchange of information with other
government bodies.

4.3.2 Data Architecture

A data architecture meeting the requirements specified in the business architecture can be
built based on a universally accepted standard like XML. Use of universal data architecture
across applications developed would help maintain homogeneity.

Data exchange using XML-based standards has enabled heterogeneous computing

environments to share information over the Internet. XML itself has evolved from the
structured representation of information to the structured representation of inter-application
messaging. Web services take this evolution a step further with XML-based mechanisms for
invoking services of software components using SOAP. These services can be deployed
across any number of physical machines connected to the Internet.

TCS Confidential 19
 e-Governance Blueprint for India

4.3.3 Application Architecture

Building a process model helps visualize the technology aspects and is critical from an
application architecture standpoint. Cross cutting requirements like single sign-on affect all
applications that would be developed and it helps in having a global approach to address
these requirements.

The India Portal and content creation project describes the application capabilities to a large
extent. Two-way services mentioned would also warrant use of robust workflow and
collaboration tools. Use of intelligent eForms and a Document Management System is also
recommended to provide user-friendly services in a timely manner.

Security is a key component of the application architecture and should be addressed by

appropriate PKI / Smart Card infrastructure wherever needed. There are quite a few
departments mentioned which would use the infrastructure put in place. In this regard, it
would help design a robust gateway providing the security services which in turn could be
used by all departments. Such a gateway could support the PKI services and other security
protocols, which may need to be implemented by various projects.

The interoperability model should also address interactions between departments within the
government as well as between governments.

4.3.4 Technology Architecture

Based on the application architecture that has been put in place, a technology architecture
with various components as depicted in Figure 8 can be used.

TCS Confidential 20
 e-Governance Blueprint for India

Figure 8: Technology Architecture Solution for the Government of India

TCS Confidential 21
 e-Governance Blueprint for India

4.4 Suggestions for e-Gov Initiatives in India

e-Governance includes, besides computerisation, re-engineering and automation

of processes. Businesses and Citizens should be able to seek governmental
services as a single, consolidated process rather than having to worry about
multiple wings of the government involved in the service delivery process.

Such an integrated e-Governance environment requires consolidated IT

Architectures (data networks, common data model, application integration
architecture), planned and designed centrally and implemented by different
ministries/departments of central/state governments.

TCS has been engaged with various e-Gov initiatives of central and state
governments. Based on this experience, TCS makes the following suggestions:

(a)Design and Build Data Communication Network for India The

Government should design fault-resilient and industrial-strength data
communication network for interconnecting 35 States/UTs and 593
Districts, with dial-up or slow-speed links to 5470 sub-districts 7. Other
networks, if any, should eventually merge into this IndiaNET. State
Governments and other PSUs may also use IndiaNET. The network
infrastructure should be designed to support the whole set of Mission
Mode Projects and existing applications of central/state governments,
although the implementation phases should be aligned with the
deployment of applications. For example, data communication facilities to
a city will be provided only when mandated by the roll out of some Mission
Mode Project in that city. The network Infrastructure, just like other
components of e-Gov solution, will evolve and upgrade to improved
technologies if deemed necessary to support newer applications.

(b)Implement Enterprise Application Integration (EAI) Before

developing any e-Gov application, EAI architecture should be defined to
facilitate smooth integration at data and application levels. Such
integration is mandatory to implement the India Portal due to the fact
that portal, by definition, will integrate with all citizen-centric applications.
The integration layer must be built into all applications, be it GIS
applications or other Ministry/Department applications.

(c) Implement India Portal This portal should provide single window for
implementing Government-to-Citizens (G2C) and Government-to-Business
(G2B) applications. All stakeholders will connect to this portal for
interacting with the Government of India and other state governments.
Such an endeavour requires merging of individual web applications into
the India Portal.

(d)Design India Portal for all Mini-Indias The India Portal should
be designed to ensure widespread access to all sections of the society. It
should build support for regional languages, specially designed devices
that will include touch-sensitive displays and support for physically
challenged citizens. The India Portal should also support innovative

7
These numbers, taken from Census of India 2001, might change in the coming years.

TCS Confidential 22
 e-Governance Blueprint for India

delivery solutions such as Infothela, DakNet, Digital Mandi and other

similar efforts in the future.

(e)Complete Registration of Persons (ROP) Precursor to the National

Citizen Database, ROP Database will record all persons living in India,
including all foreign nationals who are legally working in India, as is
normally done in other countries. The ROP Database is envisaged to
provide a common interface between central/state governments and
persons (Indian citizens and foreign nationals). Sufficient information
should be collected to enable government officials to establish citizenship,
followed by the issuance of a Citizen Card of suitable technology. A subset
of the ROP Database should be used to build a Citizen Data Hub and
contain people whose India Citizenship has been established. The Citizen
Data Hub should be designed to also serve citizen-centric departments
such as the Election Commission, Passports and Immigration.

(f) Integrate Ministries/Departments into the India Portal Major

activities touching the lives of the citizens should be performed through
the India Portal. It should include all major administrative and
commercial transactions. For example, all importers and exporters should
be able to connect to the India Portal and file relevant documents.
Similarly, citizens should be able to file applications for procuring
documents issued by state/central governments. Such a comprehensive
provisioning of Governmental Services via the India Portal is likely to
spawn additional activities in Cyber Cafes to serve the citizens who still do
not have access to computers and the Internet.

(g)Develop Data Model for Central/State Governments Institutions

such as NISG could drive efforts in developing common data model for use
by all government applications. Such an effort will facilitate smoother
integration at data and application levels.

(h)Convert Paper Documents into Electronic Format Governments are

likely to be storing billions of pages of paper documents. It should be
possible to convert these paper documents into electronic format and
facilitate accessing via the India Portal. The usage of Electronic Forms
(eForms) should be increase to reduce paper work in government offices.
The India Portal should manage the whole lifecycle of these eForms.

(i) Automate Workflows Across Ministries/Departments The

government should automate workflows for a task rather than a work-item
performed by a ministry/department. Being a true implementation of
Single Window, task could be automatically routed to different ministries
for processing. It will ensure service delivery from a single window
manifested in the India Portal. Such automation will require
enhancements at the ministries and departments involved in delivering
services to the citizens and business community.

(j) Promote Electronic Submissions of Forms/Documents The

government should create eForms as the common interface for citizens
seeking governmental services or completing legal compliance. It should
be possible to consolidate paper forms into one eForm for one type of
activity. For example, registration of a company should result in parallel
execution of automated workflows in all related ministries/departments.

TCS Confidential 23
 e-Governance Blueprint for India

(k)Involve Scientific Research Organisations Project design team

should involve the governments research organisations for vital scientific
inputs. For example, the Indian Institute of Remote Sensing could provide
vital GIS data. Similarly, the Census Commission could help in slicing and
dicing Indian population into homogeneous segments as well as guide in
developing a process for quickly reaching out to the population.

(l) Design e-Gov Solutions for a Global Audience The India Portal,
particularly the G2B component, should be designed to serve a global
audience. Depending on the countries targeted by India, the application
architecture may need to support some foreign languages such as
Japanese, French or German besides supporting international currencies
while making payments for the services being delivered. In addition, some
critical applications should remain accessible to all time zones.

(m) Implement India Data Centre All applications and servers

should be installed at central locations for easier maintenance. For
example, the Indian government could build 4-5 regional data centres for
serving the population, although data architecture will ensure seamless
access to data stored in any location. A Centralised Computing Model will
ensure that government employees concentrate on their primary functions
of serving the citizens without getting bogged down by technology issues.

(n)Implement Enterprise Management System (EMS) Continued

availability of applications, servers and network will be the key to the
successful implementation of e-Gov applications. For this reason, the
government should design and implement EMS as part of the first e-Gov
application.

(o)Enhance Participation of Private Players It is important to define

and, possibly, enhance the participation for private players. Ideally, such
a role definition should happen as part of IT Master Plan which is likely to
be prepared by the Government of India. If open to their participation,
government could give more and more components to private players.
For example, the India Data Centre and IndiaNET Data Communication
infrastructure could be outsourced to private players. Defining and
enforcing Service Level Agreements could guarantee continued availability
and optimal performance of the IT infrastructure. Such services could also
include the Enterprise Management System.

(p)Standardize Technological Components The e-Gov solution should

preferably use homogeneous set of technologies to minimize efforts to
integrate applications. TCS recommends careful analysis of the existing
technologies before finalizing e-Gov solutions, thereby ensuring smooth
transition to the applications being planned for the future. For example,
several state governments have vast installations of Microsoft
technologies while others may have opted for alternatives. It may be
easier and cheaper to manage one set of technologies. At the same time,
e-Gov architecture should build integrations with alternative set of
technologies that may have been implemented by other state
governments. For example, Java and .NET components should be able to
interoperate with each other to facilitate application-level integration
among different state governments.

TCS Confidential 24