ArchitectureStandardsforeGovtJS5Nov06 (1).ppt

Architecture and standards for e government. it looks into the insights of architectural guidelines followed on E government.

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. Business Architecture
Information Architecture
Application Architecture
Technology Architecture
Security Architecture
Business Strategy
Business Drivers
Business Goals
Business Policy
Trends Analysis
Implementation
Business Processes
Application Systems
Tech. Infrastructure
Organizational Structure
Enterprise Architecture bridges Strategy
& Implementation

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
2.Maximize end-user choice
•Wide range of implementations
3.No royalty
4.No discrimination
5.Extension or Subset allowed
6.Predatory Practice discouraged
•To prevent ‘Embrace & Enhance’ tactics by predominant
vendor

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 interfaceBy definition By design
Interoperability Assured Can not be
assumed
Licensing regime Does not apply BSD, GPL
Neutrality Neutral to all
development models
Not necessarily

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. High Level Architecture Models
e-Services Development Framework of UK
GDSC
Government
Data Standards
Catalogue
GCIM
Government
Common
Information
Model
GMRM
Government
Message
Reference
Model
e-GIF
e-Government
Inter-operability
Framework
Reusable Elements
Coding Schemes
&
Vocabularies
Reusable
Business
Processes
Reusable
Design
Components
Reusable
Technology
Components
e-Service Development
DesignRequirements Implementation

22. Developing Standards for eGov

23. Standards Life Cycle
Testing
&
Certification
Standards
Infrastructure
Identify Areas
For
Standardization
1
3 2
Develop
Standards

24. Methodology
Output can be
Standards
Software
Tools
Accept
Work
Area
Prepare
Draft
Standards
Conduct
Public
Inquiry
Review &
Adopt
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
Area Specifications/
Guidelines/Standards
Timelines
1 Technology Standards High Priority
Interoperability –Networking, Platforms, Service
access & Delivery, Security, Database
standards and guidelines (High Priority –Next
1 year)
E-Governance Architecture –Middleware, Front
ends
guidelines
Gateways
Standards, policy guidelines
Adoption and Enforcement
Guidelines
2 Meta Data and Data Definitions Medium to High Priority
Common Data Formats for generic data elements
used in e-Governance applications -
standards and guidelines To be in place in the
next 1 year
Application specific Data elements (land records,
Transport etc)
standards and guidelines Next 2 years
Spatial and non-spatial Data including GIS
standards and guidelines To be in place in the
next 2 year

27. Working
Group
Area Specifications/
Guidelines/Standards
Timelines
3 Processes High Priority
Common re-usable processes and services
in egov applications (Registration,
authentication, etc)
standards & guidelines (High Priority –
Next 1 year)
GPR Models
a.As Is Study
b.To Be
c.Gap Analysis
d.Functional Architecture
Guidelines (High Priority –
Next 1 year)
4 Localisation High Priority
Local Language Interface
standards and Guidelines (High Priority –
Next 1 year)
Adoption and Enforcement
Guidelines
Target Areas for Standard-setting

28. Working
Group
Area Specifications/
Guidelines/Standards
Timelines
5 Documentation Medium to High Priority
Program Management
Standards & guidelines
Guidelines on Preparation of RFPs
guidelines
PPP Models for egov applications
guidelines and successful
examples
Design Guidelines for Websites guidelines
Record Management, archival and retrievalStandards
6 Quality Medium Priority
Acceptance, Testing and Certification Standards & Guidelines
Quality assurance Standards & Guidelines
Security Standards & Guidelines
Target Areas for Standard-setting

29. Functional Model of eGSI
Working Draft
Guidelines
Specifications
Software
Tools
WG1 WG6WG2
6 Working Groups
SG1 SG2
2 Support Groups
Interest
Groups
Internet
Standards
Approval Body
2
6
OUTPUTS
eGS
I
eGSI = eGov Standards Institution

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
[email protected]