e-governance

1. Architecture
&
Standards for e-Government
J Satyanarayana
CEO, NISG

2. 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

3. 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

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 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

7. 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

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 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

10. Open Standards
for
e-Government

11. 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

12. 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

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. Standards Organizations
•
•
•
•
•
•
W3C
IETF
IEEE
OASIS
ETSI
ECMA
•
•
•
•
•
•
WIFI
WS-I
PCI-SIG
PCMCIA
RosettaNet
HL7

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. Open Standards
&
Open Source Software

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 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.

21. 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

22. Developing Standards for eGov

23. Standards Life Cycle
1
Identify Areas
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
et h
sM
ard
nd
Review &
Sta
Adopt
Conduct
Public
gy Inquiry
Standards
Publish
Standards
Output can also be
Policies
Guidelines
Specifications

25. 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

26. 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

27. 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)

28. 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

29. 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

30. 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

31. Thank You
ceo@nisg.org