Microsoft powerpoint - m2005-10-28 yefi v1 0.ppt

YEFI – Yesser Framework For Interoperability Kingdom of Saudi Arabia
INTEROPERABILITY FRAMEWORK
Interoperability framework definition
Interoperability framework importance
• Set of policies to be adopted by govern- • If adopted, interoperability framework will ment institutions that standardise the way decrease the effort (time and cost) required for developing the electronic exchange of • Interoperability framework will define institutions, required for successful e-government implementation – Data types and schemas– Metadata element and dictionaries • Shared, broadly adopted standards are the key in ‘decentralised coordinated’approach, as proposed in National Action DOCUMENT CONTENT
Yesser Framework for Interoperability
(YEFI) scope and general policies
SCOPE OF THE FRAMEWORK
The interoperability framework covers the exchange of information and the interactions between• Saudi Arabian government and citizens • Saudi Arabian government and foreign workers/expats with • Saudi Arabian government and business within and outside • Organization/ministries/institutes of the Saudi Arabian government • Saudi Arabian government to other governments (in the future) GENERAL POLICIES
The selection of the technical policy should be
Key general policies decided
driven by
• Alignment with the internet –
• Interoperability – only specifications that are
relevant to systems interconnectivity, data integration and service access are specified the internet and world wide web for all information systems • Market support – the specifications selected
are widely supported by the market in order to • Browser as the key user
reduce cost and risk of the government systems interface – all information are
to be accessible through
• Scalability – the specifications selected have
the capacity to be scaled to satisfy changed demands made on the systems (e.g., data vol- ume, number of transactions, number of users) • Openness – the specifications are documented
• International standards – preference will be
given to standards with the broadest remit DOCUMENT CONTENT
Yesser Framework for Interoperability (YEFI) scope and general policies YEFI components
MAIN COMPONENTS FOR YEFI
Elements Explanation
standards
• Defines attributes to be used to ‘tag’ Metadata
standards
Technical
standards
A THE COMMON PART OF THE DATA ACROSS GOVERNMENT
INSTITUTIONS NEED TO BE STANDARDIZED
• The data schema of the same business object is different • This is a major hurdle for interconnectivity as the diversity directly impacts the effort (cost and time) to establish intersystem connections • In order to avoid that, the common parts of the different schemas should be standardized for all system interfaces for inter-ministry connectivity • Moreover metadata should be introduced as part of the schema and schema versions should be recorded in a repository in order to achieve consistency under changing schemas • A framework/process is proposed to achieve the appropriate THE SCHEMA OF THE SAME BUSINESS OBJECT
IS DIFFERENT ACROSS MINISTRIES
Example: The schema of a citizen across different ministries Ministry of Health
Ministry of Education
Ministry of Interior
Ministry of Labour
Attribute
Attribute
Attribute
Attribute
Attribute
Attribute
Attribute
Attribute
type/format
type/format
type/format
type/format
Specific
additional
attributes
the
schemas
The common attributes have different names and types across ministries A WITHOUT STANDARD THE INTERCONNECTIVITY
EFFORT SCALES NON-LINEAR WITH THE NUMBER
OF INSTITUTIONS
The number of adaptors for the same business object
scales non-linear* with the number of ministries
Ministry A
Ministry C
business object requires an individual adaptor for Organization D
each ministry in order to convert names and types of the attributes * N x (N -1) adapters are needed in this example, if N is the number of ministries A BY STANDARDIZATION THE INTERCONNECTIVITY
EFFORT SCALES ONLY LINEARLY WITH THE
NUMBER OF INSTITUTIONS
The number of adaptors scales only linear in case
of standardization and encapsulation
• A facade adaptor enables standardized interconnectivity
• There is only one facade adaptor per business object for each ministry needed for all in- and outbound calls Ministry A
Ministry C
is needed for the common part of all shared business object across government institution in order to significantly reduce the interconnectivity effort Organization D
effort should be done as part of the interface specification for the integration bus * N adapters are needed in this example, if N is the number of ministries A THE FIRST STEP TO DATA STANDARDIZATION IS CREATION
OF A GOVERNMENT DATA CATALOG
Government Data Catalogue:
• Is a key element in developing schemas for business objects being exchanged, but also can be used by
government institutions to set up the standards to store the data
• Defines the standard for data on logical level, but not on the physical storage or display levels
Data Catalogue content:
Each data element described in catalogue should
be defined through:
• Name of data element
• Business definition
• Format i.e., sequence and meaning of alpha/
• Validation rules
• Verification – business steps required to verify
• XML Schema ID – references to schema (or
• Values list of acceptable values (e.g., male,
• Default value (if any)
• Owner of the standard
• Version
• Acceptance date
A EXAMPLE FOR GOVERNMENT DATA CATALOG ENTRY
Attribute
The date on which a person was born or is officially have been deemed to have been born 1. See Date definition2. Date must not be in the future.
3. Date must not be later than Person Death Date where held.
Level 0: no verificationLevel 1: verified with one of following documents: passport, national id, driver license A DATA SCHEMA CONSIST OF DATA ELEMENTS OF
TYPES DEFINED IN DATA CATALOG
A DATA CONSISTENCY REQUIRES META DATA AS PART OF THE
OBJECT DATA SCHEMA AND A CENTRAL SCHEMA REPOSITORY
A central repository for the standardized schemas
The standardized schema consists of
is required to handle persistent data of outdated
header and data body
Example: Attributes of the business object Schemas will evolve over time. Hence there will be persistent business objects of outdated schemas. In order to convert this object into the latest schema, the latest schema and conversion rules needs to be Repository
Business object with
Business object
outdated schema
converted to the
latest schema
A A STANDARDIZATION PROCESS NEEDS TO BE ESTABLISHED
AS PART OF THE INTEROPERABILITY EFFORT
Develop standard
Sign-off standard by
Identify shared
for common
the government
business objects
attributes
institutions
Activities
standardization to all government institutions Deliverables • Matrix of shared
B METADATA STANDARDS
What is metadata?
“Data about data”
Where it is important?
Content management – describe the content of documents
Why this is important
• Allow for easy access to information and documents (e.g., searching, browsing by category) being published by different government institutions What are typical
• Typically describe goal, origin, content and history of metadata elements?
document, e.g., Addressee, Creator, Contributor, Date issued, Description, Format, Identifier, Language, Publisher, Copyright, Source/URL, Status, Subject, Title, Type B CONTENT MANAGEMENT METADATA IN THE EXAMPLE
Metadata
Information
Outlines the Interoperability framework to be established in thee-Government of the Kingdom of Saudi Arabia Reserved to the Yesser Group, Kingdom of Saudi Arabia This metadata
should be part of each
documentation which
is made available publicly
or exchanged between
government agencies
* Persistent identifiers shall conform to the ANSI/NISO Z39.84 standard http://www.niso.org/ C TECHNICAL POLICIES WILL CONSIST OF 3 SUBSECTIONS
Technical
subsections
Description
• It specifies the integration approach, middleware technologies and standards necessary to integrate the different applications in the different ministries • It specifies network and transport protocols should be used for information exchange, access, and delivery • It specifies the security approaches, technologies, and standards in the different e-government services C IN ADDITION TO THE INTEGRATION STANDARDS A SYSTEM
INTEGRATION STRATEGY NEEDS TO BE OUTLINED
Key elements of an
integration strategy
Description
• The integration approach outlines two things along the Integration
approach
– The topology, e.g. point-to-point, hub-and spoke and bus– The architecture layer of integration, e.g. data, application layer Specification of
• Specification of all technical standards relevant to the integration technology
(see Appendix proposed technical standards) standards
• Application integration: All interfaces/services to be
Specification of
interconnected should be listed, specified and described in order semantics
• Data integration: All major business objects/data to be
transmitted between systems across organization should be specified in order to achieve consistency** * This should be part of the future application architecture** The specification and description of the business data should comply to metadata standards DOCUMENT CONTENT
Yesser Framework for Interoperability (YEFI) scope and general policies YEFI development roadmap
TWO MAIN WORKSTREAMS TO BE LAUNCHED
The goal of workstream
Next steps
metadata
standards
define structures in which data is being exchanged group’) to work on tags definition and dictionaries Technical
standards
groups, e.g., security sub group) to work on technical standards definition ORGANIZATIONAL STRUCTURE OF THE INTEROPERABILITY Committee
Interoperability
Committee
changes of the inter-operability framework All institutions relevant for e-government Project leaders of projects which are relevant for inter- THE MANAGEMENT PROCESS ENSURES THAT
THE FRAMEWORK REMAINS UP TO DATE
Lifecycle of the interoperability standards
Requirement
Decision on changes
Roadmap and
management
to the standards
compliance
Activities • Review changes in the
THE ORGANIZATIONAL STRUCTURE SHOULD GROW
OVER TIME
• Specifications of the most important • Further refinement within the Organization
– 1 for the overall framework– 1 for each of the 5 technical area DOCUMENT CONTENT
Yesser Framework for Interoperability (YEFI) scope and general policies Appendix - Proposed technical standards
GUIDING PRINCIPLES FOR THE SPECIFICATION OF THE FIRST
VERSION OF THE TECHNICAL STANDARDS
Guiding principles
• Outdated available standards should not be considered
• All available standards which are not outdated and in
operations should be considered, e.g. Microsoft .NET, however gradual migration to a narrower set of preferred standards should be started • All state-of-the-art standards should be considered even if they are currently not in operations, e.g. JAR, WML • Technology areas which do not have standards yet and are not in use should not yet have standard policies, e.g. metadata management technology • Localized standards should be taken into consideration, e.g. INTEGRATION TECHNOLOGY STANDARDS
Bold - preferred standard
Resource
Middleware
WebService/
description
technologies
Character sets
XML Technologies
framework
• Data structure: XML
• Data format: XSL
• Web services
– UTF-16
– XML Schema
CONTENT FORMATS
Web content
Document
Compression
Mobile device
Image formats
Audio formats
Video formats
technologies
content formats
• XHTML
INTERCONNECTION STANDARDS
transport
Directory
protocols/
File transfer
Mobile device
WLAN network
outbound
protocols
protocols
services
protocol
network protocol
protocols
• TCP/IP
• IGRP• BGP• IS-IS• SONET• X.25• DNS SECURITY STANDARDS
Encryption algorithm,
Email security
Transport protocol
Network protocol
digital signature

Source: http://www.yesser.gov.sa/ar/BuildingBlocks/Documents/YEFI.pdf