Architecture
&
Standards for e-Government
J Satyanarayana
CEO, NISG
Contents
• Architecture for e-Government
• Open Standards

• What are open Standards?
• Why Open Standards?
• Role of Open Standards in National Action Plan

• Open Source Software

• What is OSS?
• Open Standards & Open Source

• Interoperability
• Building Standards for eGov
Why Architect ?
When You want to build your house ….
You go to an Architect first …
Not to an engineer… not to a builder ..
Reason?
You don’t want to make and break walls ..
You want the house to be more livable !

Same is the case with an e-Government Project
Scope of Architecture
• Architecture is not about Technology alone
• We need architectures in other areas too
• Process Architecture
• People Architecture
• Resource Architecture

• In this session we deal mainly with Technology
Architecture
Levels of Architecture
• Architecture can be at different levels
–
–
–
–
–

Project Level
Program Level
Enterprise Level
State level
National Level

• We need increasing care & detail in
architecting as we go up the level.
How does Architecture help?
• Helps align different components of eGov
•
•
•
•

Technology Architecture to meet business needs
Process Architecture to exploit technology
People Architecture to use technology & new processes
Resource Architecture to use technology & process in
providing cost-effective services

• Promotes interoperability
• Ensures Scalability
• Enables planning the degrees of security and
reliability
• Insulates against disruptive changes in
technology, process and people
Enterprise Architecture bridges Strategy
& Implementation

Business Architecture
Information Architecture
Application Architecture
Technology Architecture
Security Architecture

Business Strategy

Implementation

Business Drivers
Business Goals
Business Policy
Trends Analysis

Business Processes
Application Systems
Tech. Infrastructure
Organizational Structure
Value of EA
• Provides business with a systematic approach to describing
their business:
– common language (e.g., “client”, “service”, “goal”) to describe the
business
– identify gaps in service delivery

• Highlights the interdependencies in service delivery across
organisation boundaries:
– across ministries
– within ministries across traditional service delivery boundaries

• Identifies gaps in business requirements early in design cycle
• Lays foundation for re-use of data, applications and
technology
• Introduces discipline in developing, documenting and
disseminating standards (data, applications, technology,
security)
• Facilitates cross-project communications
US Federal Enterprise Architecture
(FEA)
• A Unified Framework for eGov
• Templates for all federal government EA
• Creates one vocabulary for federal EA
– Easy to share data, concepts, products,
information

• Five models, to describe different aspects
–
–
–
–
–

Performance Reference Model (PRM)
Business Reference Model (BRM)
Service Component Reference Model (SRM)
Technical Reference Model (TRM)
Data Reference Model (DRM)

• More details at http://www.feapmo.gov
Open Standards
for
e-Government
What are Open Standards?
• Open Standards are technology specifications
•
•
•
•

developed collaboratively
followed universally
address common requirements and goals
relate to
» product stacks & products
» components
» interfaces and protocols

• Open Standards are based on commonly
accepted Principles & Practices
Principles & Practice of Open
Standards
1. Availability
•
•
•

Free download via the Internet
Should not cost not more than a college text book
Commercial exploitation allowed

•

Wide range of implementations

•

To prevent ‘Embrace & Enhance’ tactics by predominant
vendor

1. Maximize end-user choice
1.
2.
3.
4.

No royalty
No discrimination
Extension or Subset allowed
Predatory Practice discouraged
Types of Standards
• De Jure Standards set by
• Standards Organizations

» e.g - HTML, XML, Web Services, TCP/IP, 802.11

• Government

» Technologies related to health, drugs, energy, environment

• Proprietary Standards

• Java, Adobe PDF, WIN32 APIs

• De Facto Standards
• Java, Adobe

• Product Standards

• Linux, Java, Windows
Standards Organizations
•
•
•
•
•
•

W3C
IETF
IEEE
OASIS
ETSI
ECMA

•
•
•
•
•
•

WIFI
WS-I
PCI-SIG
PCMCIA
RosettaNet
HL7
Why Open Standards?(1)
• Optimize options of products & components
• Multiple vendors offering the same interfaces
• Mix & Match possible due to ‘Hot Swappability’
• Choices can be made incrementally

• Reduce Risk
• Vendor independence
• Assurance of continued support in future

• Reduced Cost
•
•
•
•

Lower costs due to competition
Reduced cost of changing products/vendors
Increased ROI
Shorter learning curve for developers, maintenance staff
Why Open Standards?(2)
• Inter-operability
• Components with standard interfaces
• Simpler & quicker integration
• Integration across the entire chain
» of internal departments
» external entities, customers, departments

• Higher Quality resulting from
• Open competition
• Broader participation of peer groups
• Early identification & resolution of bugs
Open Standards
&
Open Source Software
What is OSS/FS?
• Open Source Software
•
•
•
•

Source code available to the user
Free redistribution permitted
Unrestricted use of the software
Integrity of the author’s code to be protected

• Free Software
• Source code available to the user
• Freedom to run the program for any purpose
• Freedom to modify, improve and redistribute
Open Standards & Open Source
Attribute

Open Standard

Open Source

Nature

A Set of technology
specifications

Software Product

Openness of
interface

By definition

By design

Interoperability

Assured

Can not be
assumed

Licensing regime

Does not apply

BSD, GPL

Neutrality

Neutral to all
Not necessarily
development models
Interoperability
• Interoperability is the capability of the
components to function together to share in the
fulfillment of a process
• Components can be
• Within a system OR
• Spanning across disparate systems/ enterprises

• Interoperability enables us to
• automate processes that transcend technologies,
platforms, languages and customizations.
e-Services Development Framework of UK
GCIM

GMRM

GDSC

Government
Common
Information
Model

Government
Data Standards
Catalogue

e-GIF

Government
Message
Reference
Model

e-Government
Inter-operability
Framework

High Level Architecture Models
High Level Architecture Models

Reusable
Business
Processes

Coding Schemes
&
Vocabularies

Reusable
Design
Components

Reusable
Technology
Components

Reusable Elements
Reusable Elements

Requirements

Design

e-Service Development
e-Service Development

Implementation
Developing Standards for eGov
Standards Life Cycle

1

Identify Areas
For
Standardization

3
Testing
&
Certification

Standards
Infrastructure

2
Develop
Standards
Methodology
Output can be
Standards
Software
Tools

Prepare
Draft
Standards

Accept
Work
Area

olo
od
et h
sM
ard
nd
Review &
Sta
Adopt

Conduct
Public
gy Inquiry

Standards
Publish
Standards

Output can also be
Policies
Guidelines
Specifications
Standards ++
• Standards are necessary..
– but not sufficient

• e-Government is more than technology
• Process, People, Resources

• We need Models, Frameworks & Guidelines
• Models – Business Models, Process Models
• Frameworks – PPP, Capacity Building, KM,
Assessments
• Guidelines – Procurement, Evaluation
Target Areas for Standard-setting
Working
Gro
up
1

Area

Technology Standards
Interoperability – Networking, Platforms, Service
access & Delivery, Security, Database
E-Governance Architecture – Middleware, Front
ends
Gateways
Adoption and Enforcement

2

Meta Data and Data Definitions
Common Data Formats for generic data
elements used in e-Governance
applications Application specific Data elements (land records,
Transport etc)
Spatial and non-spatial Data including GIS

Specifications/
Guidelines/Standards

Timelines

High Priority
standards and guidelines

(High Priority – Next
1 year)

guidelines

Standards, policy guidelines
Guidelines
Medium to High Priority
standards and guidelines

To be in place in the
next 1 year

standards and guidelines

Next 2 years

standards and guidelines

To be in place in the
next 2 year
Target Areas for Standard-setting
Working
Group
3

Area
Processes
Common re-usable processes and services
in egov applications (Registration,
authentication, etc)

GPR Models
a. As Is Study
b. To Be
c. Gap Analysis
d. Functional Architecture
4

Localisation
Local Language Interface

Adoption and Enforcement

Specifications/
Guidelines/Standards

Timelines

High Priority
standards & guidelines

(High Priority –
Next 1 year)

Guidelines

(High Priority –
Next 1 year)

High Priority
standards and Guidelines

Guidelines

(High Priority –
Next 1 year)
Target Areas for Standard-setting
Working
Group
5

Area
Documentation
Program Management
Guidelines on Preparation of RFPs

Specifications/
Guidelines/Standards
Medium to High Priority
Standards & guidelines
guidelines

PPP Models for egov applications
Design Guidelines for Websites

guidelines

Record Management, archival and retrieval
6

guidelines and successful
examples

Standards

Quality

Medium Priority

Acceptance, Testing and Certification

Standards & Guidelines

Quality assurance

Standards & Guidelines

Security

Standards & Guidelines

Timelines
Functional Model of eGSI
eGSI = eGov Standards Institution

Standards
Approval Body

eGS
I

OUTPUTS

Working Draft

WG1

WG2

Guidelines

WG6

6

Interest
Groups

6 Working Groups

Specifications

Software

Tools

SG1

SG2

2 Support Groups

2

Internet
Conclusion
• Developing Enterprise Architecture is an essential
first step in eGov Panning.
• Promotion of Open Standards is imperative for
progress on a large e-Gov program
• Interoperability
• Cost & Time saving
• Better Competition

• Creation of a National Level Institution for
Architecture & Standards is quite pivotal to achieve
notable success
Thank You
ceo@nisg.org

E governance and enteerprise architecture

  • 1.
  • 2.
    Contents • Architecture fore-Government • Open Standards • What are open Standards? • Why Open Standards? • Role of Open Standards in National Action Plan • Open Source Software • What is OSS? • Open Standards & Open Source • Interoperability • Building Standards for eGov
  • 3.
    Why Architect ? WhenYou want to build your house …. You go to an Architect first … Not to an engineer… not to a builder .. Reason? You don’t want to make and break walls .. You want the house to be more livable ! Same is the case with an e-Government Project
  • 4.
    Scope of Architecture •Architecture is not about Technology alone • We need architectures in other areas too • Process Architecture • People Architecture • Resource Architecture • In this session we deal mainly with Technology Architecture
  • 5.
    Levels of Architecture •Architecture can be at different levels – – – – – Project Level Program Level Enterprise Level State level National Level • We need increasing care & detail in architecting as we go up the level.
  • 6.
    How does Architecturehelp? • Helps align different components of eGov • • • • Technology Architecture to meet business needs Process Architecture to exploit technology People Architecture to use technology & new processes Resource Architecture to use technology & process in providing cost-effective services • Promotes interoperability • Ensures Scalability • Enables planning the degrees of security and reliability • Insulates against disruptive changes in technology, process and people
  • 7.
    Enterprise Architecture bridgesStrategy & Implementation Business Architecture Information Architecture Application Architecture Technology Architecture Security Architecture Business Strategy Implementation Business Drivers Business Goals Business Policy Trends Analysis Business Processes Application Systems Tech. Infrastructure Organizational Structure
  • 8.
    Value of EA •Provides business with a systematic approach to describing their business: – common language (e.g., “client”, “service”, “goal”) to describe the business – identify gaps in service delivery • Highlights the interdependencies in service delivery across organisation boundaries: – across ministries – within ministries across traditional service delivery boundaries • Identifies gaps in business requirements early in design cycle • Lays foundation for re-use of data, applications and technology • Introduces discipline in developing, documenting and disseminating standards (data, applications, technology, security) • Facilitates cross-project communications
  • 9.
    US Federal EnterpriseArchitecture (FEA) • A Unified Framework for eGov • Templates for all federal government EA • Creates one vocabulary for federal EA – Easy to share data, concepts, products, information • Five models, to describe different aspects – – – – – Performance Reference Model (PRM) Business Reference Model (BRM) Service Component Reference Model (SRM) Technical Reference Model (TRM) Data Reference Model (DRM) • More details at http://www.feapmo.gov
  • 10.
  • 11.
    What are OpenStandards? • Open Standards are technology specifications • • • • developed collaboratively followed universally address common requirements and goals relate to » product stacks & products » components » interfaces and protocols • Open Standards are based on commonly accepted Principles & Practices
  • 12.
    Principles & Practiceof Open Standards 1. Availability • • • Free download via the Internet Should not cost not more than a college text book Commercial exploitation allowed • Wide range of implementations • To prevent ‘Embrace & Enhance’ tactics by predominant vendor 1. Maximize end-user choice 1. 2. 3. 4. No royalty No discrimination Extension or Subset allowed Predatory Practice discouraged
  • 13.
    Types of Standards •De Jure Standards set by • Standards Organizations » e.g - HTML, XML, Web Services, TCP/IP, 802.11 • Government » Technologies related to health, drugs, energy, environment • Proprietary Standards • Java, Adobe PDF, WIN32 APIs • De Facto Standards • Java, Adobe • Product Standards • Linux, Java, Windows
  • 14.
  • 15.
    Why Open Standards?(1) •Optimize options of products & components • Multiple vendors offering the same interfaces • Mix & Match possible due to ‘Hot Swappability’ • Choices can be made incrementally • Reduce Risk • Vendor independence • Assurance of continued support in future • Reduced Cost • • • • Lower costs due to competition Reduced cost of changing products/vendors Increased ROI Shorter learning curve for developers, maintenance staff
  • 16.
    Why Open Standards?(2) •Inter-operability • Components with standard interfaces • Simpler & quicker integration • Integration across the entire chain » of internal departments » external entities, customers, departments • Higher Quality resulting from • Open competition • Broader participation of peer groups • Early identification & resolution of bugs
  • 17.
  • 18.
    What is OSS/FS? •Open Source Software • • • • Source code available to the user Free redistribution permitted Unrestricted use of the software Integrity of the author’s code to be protected • Free Software • Source code available to the user • Freedom to run the program for any purpose • Freedom to modify, improve and redistribute
  • 19.
    Open Standards &Open Source Attribute Open Standard Open Source Nature A Set of technology specifications Software Product Openness of interface By definition By design Interoperability Assured Can not be assumed Licensing regime Does not apply BSD, GPL Neutrality Neutral to all Not necessarily development models
  • 20.
    Interoperability • Interoperability isthe capability of the components to function together to share in the fulfillment of a process • Components can be • Within a system OR • Spanning across disparate systems/ enterprises • Interoperability enables us to • automate processes that transcend technologies, platforms, languages and customizations.
  • 21.
    e-Services Development Frameworkof UK GCIM GMRM GDSC Government Common Information Model Government Data Standards Catalogue e-GIF Government Message Reference Model e-Government Inter-operability Framework High Level Architecture Models High Level Architecture Models Reusable Business Processes Coding Schemes & Vocabularies Reusable Design Components Reusable Technology Components Reusable Elements Reusable Elements Requirements Design e-Service Development e-Service Development Implementation
  • 22.
  • 23.
    Standards Life Cycle 1 IdentifyAreas For Standardization 3 Testing & Certification Standards Infrastructure 2 Develop Standards
  • 24.
    Methodology Output can be Standards Software Tools Prepare Draft Standards Accept Work Area olo od eth sM ard nd Review & Sta Adopt Conduct Public gy Inquiry Standards Publish Standards Output can also be Policies Guidelines Specifications
  • 25.
    Standards ++ • Standardsare necessary.. – but not sufficient • e-Government is more than technology • Process, People, Resources • We need Models, Frameworks & Guidelines • Models – Business Models, Process Models • Frameworks – PPP, Capacity Building, KM, Assessments • Guidelines – Procurement, Evaluation
  • 26.
    Target Areas forStandard-setting Working Gro up 1 Area Technology Standards Interoperability – Networking, Platforms, Service access & Delivery, Security, Database E-Governance Architecture – Middleware, Front ends Gateways Adoption and Enforcement 2 Meta Data and Data Definitions Common Data Formats for generic data elements used in e-Governance applications Application specific Data elements (land records, Transport etc) Spatial and non-spatial Data including GIS Specifications/ Guidelines/Standards Timelines High Priority standards and guidelines (High Priority – Next 1 year) guidelines Standards, policy guidelines Guidelines Medium to High Priority standards and guidelines To be in place in the next 1 year standards and guidelines Next 2 years standards and guidelines To be in place in the next 2 year
  • 27.
    Target Areas forStandard-setting Working Group 3 Area Processes Common re-usable processes and services in egov applications (Registration, authentication, etc) GPR Models a. As Is Study b. To Be c. Gap Analysis d. Functional Architecture 4 Localisation Local Language Interface Adoption and Enforcement Specifications/ Guidelines/Standards Timelines High Priority standards & guidelines (High Priority – Next 1 year) Guidelines (High Priority – Next 1 year) High Priority standards and Guidelines Guidelines (High Priority – Next 1 year)
  • 28.
    Target Areas forStandard-setting Working Group 5 Area Documentation Program Management Guidelines on Preparation of RFPs Specifications/ Guidelines/Standards Medium to High Priority Standards & guidelines guidelines PPP Models for egov applications Design Guidelines for Websites guidelines Record Management, archival and retrieval 6 guidelines and successful examples Standards Quality Medium Priority Acceptance, Testing and Certification Standards & Guidelines Quality assurance Standards & Guidelines Security Standards & Guidelines Timelines
  • 29.
    Functional Model ofeGSI eGSI = eGov Standards Institution Standards Approval Body eGS I OUTPUTS Working Draft WG1 WG2 Guidelines WG6 6 Interest Groups 6 Working Groups Specifications Software Tools SG1 SG2 2 Support Groups 2 Internet
  • 30.
    Conclusion • Developing EnterpriseArchitecture is an essential first step in eGov Panning. • Promotion of Open Standards is imperative for progress on a large e-Gov program • Interoperability • Cost & Time saving • Better Competition • Creation of a National Level Institution for Architecture & Standards is quite pivotal to achieve notable success
  • 31.