Directive № 2/ 2010 INTEGRABILITY and Metrics

DIRECTIVE Nº 002GE-2010-SGPyC 01-07-2010

1

INTEGRABILITY GUIDE AND METRICS APPLIED TO FORMULATION, DEVELOPMENT AND IMPLEMENTATION OF IT APLICATIONS

I. OBJECTIVE

To define infrastructure, methodological stages and metrics to be used during the implementation of the Integrability Model for formulation, development and implementation of IT applications, following the E-Government Master Plan standards.

One of the most important goals to achieve for the Integrability Model, is that if a Government Body, which is an Authentic Source of data about a citizen and/or a company data, this data can be obtained by other Government Bodies that require it by consulting the relevant Government Body, instead of requesting the information again from the citizen and/or company.

II. SCOPE

This directive is to be used and adhered to by all Centralized and Descentralized Bodies of the Province Executive Authority.

III. LEGAL BASIS

• IT Provincial Policy, Decree N° 0405/1991.

• Neuquén Province E-Government Master, version 3.0, November 2003.

• Ministeries Organic Law 2571, article 24°, Functions of Public Management and Government Contracts Secretary (SGPyCE). 2007 y decrees 1772/09 and 336/10.

• Law Nº 2.307. Action of Habeas Data

• Directive 001GE-2008-SGPyCE - Integrability

• Decree 2223-08 IT Security.

• Law 2578 Digital Signature.

• Law Nº 2577 To promote Software Industries and Decree 0448/10

IV. CONCEPTUAL FRAME

INTEGRABILITY:

Concept: Capacity to be part of a network of systems in which each one is provider of its own Authentic

Source data, and with regard to the others, client for data it doesn’t produce itself. All data are shared with

the other systems of the network following regulations.

Tecnology: IT capacity to be part of an integrated systems network of data providers or owners which

operate of different platforms and are developed using different languages, without the need for changes

or customization.


2

ACTORS MODEL

The creation of an a model of actors for Integrability is a response to the necessity of establishing and a

balance between supportable power and a totally transparent schema for everyone, in other words clear

and fair rules of the game. Similar schemes of actors can be found in some successful cases of E-

Government, in particular the European Union.

The necessary actors are:

0=>Certifying Authority, 1=>Authenticator, 2=>Coordinator, 3=>Authentic Source, 4=>Client system,

5=>Involved User.

0. Certifying Authority:

Conceptually: This is the trustable for all third part, in which the secure information interchange model is based on.

Technologically: It uses Public Key Infrastructure (PKI), respecting agreements with ONTI (National IT Government Bureau).

1. Authenticator: (Structure: Authentication Authority) Conceptually: The Authenticator checks all the users´ identity (people, companies, government bodies and client systems). Also it provides 1 or 2 factors authentication services it only has basic operational data, for example: Username, Password, Digital Certificate, Mobile Phone Number (used by 2 factors authentication).

Technologically: The Authenticator is located in a server (Authentication Server) which stores in a centralized directory all model actors’ identification data. This task is executed through Lightweight Directory Access Protocol (LDAP).

2. Coordinator: (Structure: Integrability Coordination) Conceptually: The Coordinator assures compliment to legal regulations and confidentiality agreements. It continues the hierarchical structure generating sustainable balance.

Technologically: The Coordinator is situated in a Server called Coordinator Server, and which main tasks are to define, maintain, and controlling all users´ access, internal or external, to organizations. For auditory reasons, the coordinator server registers the request public parameters, successful or failed requests and finally execution time stamping.


3

3. Authentic Source: (Structure: Integrability Responsible Body X –TIC Authentic Source Assistant )

Conceptually: Each Organization or Government Body, depending on its competencies, is in charge of the processes to create and maintain some kind of data registration, so it becomes the Authentic Source of those registers. In the Authentic Source role, it is important to distinguish between the “registration process” and being the “data owner”. Not always both roles are unified. Being Authentic Source means to hold a particular record, that requires to come from Correct, Complete and Updated Data.

Technologically: It is supported by servers distributed through different IT areas, that could belong to Organizations or Government dependencies, which work as Authentic Sources. It relays on 2 main components: o Security Component: It deals with security matters, digital signature, and messages encryptation,

holding secure communication with the rest of the actors. o Access Component: it connects to the Authentic Source Databases by means of SQL sentences, or

registering web services provided by third parts.

4. Client System: (Structure: Integrability Organization X Responsible – Cliente System TIC Assistant)

Conceptually: it is all system, that to get results (services), has to consume information from several Authentic Sources. An example of Client System is “e-Photocopy”, this is used to make electronic documents with digital signature. Those documents are created from registered data coming from several Authentic Sources.

Technologically: this is a system developed to interact with the rest of the Integrability Model Actors, using Web Services. A set of components for authentication, services catalogue, digital signature, encryptation and security protocol management, allows to incorporate quickly these functionalities and with low programming cost.

5. Involved Users: Conceptually: It could be citizens, organizations or Government bodies, over which client systems and authentic sources exchange information.

Technologically: Involved users could be absent. But when it is required by Habeas Data Law, these users must accept an on-line agreement to allow transferring their information. And also, for auditory reasons the acceptance process will be registered.

FUNTIONALITY LAYERS:

To allow a sustainable Integrability, the minimum requirements are mandatory and sufficient. They are

the basement for the four minimum functionality layers for system development.

INTEGRATED, SIMPLE AND FRIENDLY INTERFACES: From client (user) point of view, it works as

integrated “front-end”. And it interacts with a workflow, which connects to several applications

and databases.

EFICIENT AND FLEXIBLE PROCESSES: Sustainability should allow processes to be redesigned easily,

in concordance with continuing improvement in each organization. The processes should be

supported by a “workflow”, such workflow allows to its tasks to use transactions reusability from

many applications and databases.

EFICIENT AND ROBUST APPLICATIONS: All processing business logic should be strongly reusable,

and protected against changes in processes and technology. And so, the extensive use and

continue improvement of its algorithms will allow to get more efficient and robust components.


4

QUALITY SHARED DATA: the model of distributed data in the Authentic Sources, plus the

continuous control over its different uses, will sustain data quality.

INTEGRABILITY METRICS

The integrability metrics define five (5) maturity levels for a software system, when messuring its integration capacity with other systems. In general, the goals included in each level are independent from each other. Their grouping in incremental levels represents the system maturity level. The goals to achieve in each level are:

o Level 1: Initial File Input/Output in text format (txt). Completed metadata documentation of software manager to allow access to the

Database using SQL queries.

o Level 2: One Login It is integrated without changes to the Provincial Central Authentication. It matches its internal user codes with the Authentication Directory LDAP.

o Level 3: Authentic Sources Interoperability It consumes web services from defined authentic sources, preventing from the

duplication of non authentic data in their own databases. It supplies to other systems with query Web Services on records managed by the

Authentic Source application.

o Level 4: Processes Interoperability Specific system component or functions can be invocated from other provider Workflow. In case of being Workflow, it has to:

Have flexibility in case of changes or process flow redesign, with no programming required.

In process activities, it is allowed to invocate, using Web Services, components or functions from many applications from many providers.

In process activities, it should be possible to operate using Digital Signature at the User Level.


5

o Level 5: Integrated Interface interoperability The Applications provide transactional Web Services that allow to be integrated in other

Front-End along with other Applications Web Services. The integrated interface could facilitate users with functions, which make use of multiple

applications transparently, the last ones controlled for Workflow.

Implementation Method

A three stages method is used to solve distinct communication issues from organizations. To maximize results at the minimum resources cost, it has to be implemented in the indicated sequence. It is due to the leverage between the different stages: – stage 1: Inter-organizational communication → Interoperability

– stage 2: Inter-areas communication → Participative redesign of work Processes

– stage 3: Communication between different system from distinct software → SOA (Service Oriented Architecture) for connected government.

o Stage 1: Interoperability

It focuses on inter-institutional communication, it means inside of the organizational context. The interaction between actors, proposed for the Integrability Model, makes possible to assure transactions transparency, power balance, protection against external and internal attacks, plus data confidentiality (Habeas Data).

As a result of solving inter-institutional communication, it allows to reach one the suggested objectives: “If a government body knows any information about a citizen, no one of the other government body can re-ask for it.”

Stage 1 solves the necessity to share data between the Government bodies: – If a Government body doesn’t share data legally, then it generates for the rest of the

organizations the necessity of creating their own records to operate. – If an Authentic Source Administrator doesn’t share data, then other poor quality records will

come out in parallel. – When the more data reusability is employed, the better quality data is produced.


6

o Stage 2: Participative Redesign of Work Processes

It is focused on the inter-areas communication, which is materialized through the organizational processes. The final quality of the planned IT solutions has direct relationship with the efficiency and efficacy acquired by processes, and also with processes flexibility against context changes and the continuous improvement.

Stage 2 solves the necessity of all the involved people in take part of the definition of “How” new processes have to be redesigned. It is usual to consider that the main issue is the resistance to change, but actually this resistance pops up due to the lack of participation of those involved in changes. Process redesign demands to get control of processes by means of a complete alignment to management, in the same way a coordination from client’s side, and after that it can be possible to optimize people activities. All of that performed as a team work.

o Stage 3: Unifying user’s interface

It is focused on inter-systems communication. Here, it is the Government who fixes priorities, and it is not imposed by providers’ commercial proposals. The use of previous operating developments is the key to build up the connected Government. Technological changes are welcome but it doesn’t mean to retrace their steps. Then, the key is the articulations or layers model, which allows preserving the investment made. The methodology to implement Integrability demands to articulate multi-provider and multi-technology resources to allow:

• Unified interfaces, simple and friendly ones. • Flexible and effective processes. • Robust and effective applications. • High quality shared data.

This stage 3 resolves the needs to release the last mille in systems in order to unify user’s interface. Otherwise a programmer will be obliged to develop in parallel a new complete software, in those cases when a software development doesn’t allow him to work in other language and technology (familiar for him) to complete the services for his system.


7

V. GENERAL AND SPECIFIC REGULATIONS

1. Half-yearly state of art report: The areas of centralized and decentralized Provincial Executive Power

bodies should report every six months to SGPyG regarding the implemented systems, development or

acquisition projects, and also action plans to accomplish all INTEGRABILITY requirements in concordance

with these regulations

2. Temporary goals: The applications and IT systems at development stage and those to be acquired or

developed must to accomplish the following minimum requirements of INTEGRABILITY metrics:

o Current systems in production and maintenance stage: it will be necessary to adapt systems to get certifications in the following minimum levels:

Level 3 on December 2010 Level 4 on December 2011 Level 5 on December 2012

o New systems to be acquired or developed: it will be mandatory the Integrability Certificate to accredit accomplishment of these minimum levels:

Level 3 on December 2010 Level 4 on December 2011 Level 5 on December 2012

Integrability Level Certificates: the IT Faculty of del Comahue University will be asked for the Integrability

level certification for a given software development.

3. Authentic Sources Inter-operability: For the purpose of complying with the methodological requirements

of the first stage of Integrability Process, the next steps have to be followed:

o Data Model definition For every new development project to converge on a Shared Data Model,

semantically coherent with all Provincial Administration, the following activities will be mandatory to

coordinate with the Databases and Integrability Departament of the OPTIC TICs Planning and

Development Directory:

Get informed about the current Shared Data Model.

Select the most adequate Authentic Sources to be used with the new system.

Determine which are the new Authentic Sources generated from the new system.

Minimize data recording from other Authentic Sources on the new application databases,

only allowing that when such application requires historical data.

Update Shared Data Model documentation.

4. PROCESSES Inter-Operability: the methodological requirements to be accomplished at the second stage of

the Integrability Process are:

o Participative Redesign of work Processes: The final quality level of IT solutions is directly proportional to the efficiency and efficacy grades acquired for the new processes and their flexibility against context changes, and continuous improving. To assure the correct Participative Redesign of work Processes, the support actions will be coordinated from the Department Processes layer of the Planning and TIC´s Development at the OPTIC due to:

As a first step for computerization process of activities is to proceed with its Redesign using

certificated in participative methods facilitators.

In case of a new IT development, the documentation produced by redesign will be used at the

requirements engineering stage.

In case of an existent application, participative redesign will be used in order to optimize its

implementation, aligning functionalities and needs.


8

Facilitators´ Training and Certification: The Faculty of Economics and Management at Del Comahue

University or any other organization authorized by SEGPyC, will give formative courses, and issues the

Participative Redesign Process Method certification to facilitators.

o Identifying functional modules: the processing robustness and efficiency of the new system will be directly related to the modules architecture and their coupling level. To avoid unwanted superposition or overlapping, It will be necessary to coordinate actions along with the Department Logic Layer of the Planning and TICs Development Board at OPTIC, which will allow to be in concordance with the next premises:

If there are main modules, they should be reused by the new system, avoiding recoding for the same algorithms.

If the new system brings new reusable modules, then the documentation from available modules catalogue has to be updated.

5. Interoperability of Unified Interface: The method’s requirements at the third stage of the Integrability

process are:

o Unified Interface Definition: Final usability of IT solutions is directly related to coherence and uniformity of the operations interface that is shown to users. To assure a high grade of usability is necessary to coordinate actions along with the Department Presentation Layer of the Planning and TICs development board from OPTIC, in charge of defining the corresponding models.

The organizations have to maintain and develop their independent web sites, but offering the same functionalities by means of transactional web services, and so to be usable on the unified Province Portal.

The Legislative, Courts, Councils from the Province are invited to implement the Integrability Model in order to

achieve secure exchange of information for all the Provincial Government Bodies.

Directive № 2/ 2010 INTEGRABILITY and Metrics

Documents

Transcript of Directive № 2/ 2010 INTEGRABILITY and Metrics