Integrabilidad

Esta página es de solo lectura. Puedes ver la fuente pero no puedes cambiarla. Pregunta a tu administrador si crees que esto es incorrecto.
====== Manual del Capacitador de Integrabilidad ======


\\ 
\\
{{ :wiki:manualdesarrolladorpage1.jpg?nolink&200 |}}
====== Iniciativa de Integrabilidad ======
 


===== Introducción =====


La Iniciativa de Integrabilidad es un enfoque que busca crear un modelo de desarrollo y transformación para facilitar la construcción de una COMUNIDAD CONECTADA. (Ver Anexo: White Paper INTEGRABILIDAD)


Para comprender la magnitud del problema, al que nos enfrentamos, debemos pensar tan solo en que el modelo debe poder cubrir todo el ciclo de vida del ciudadano. Esto hace evidente la imposibilidad de creer que con un desarrollo basado en el paradigma del sistema integrado, hecho por alguien, alguna vez se pueda lograr semejante objetivo. Cuando múltiples sistemas y servicios de innumerables organizaciones deben confluir en la vida de un ciudadano, solo un enfoque que parta de nuevas premisas puede hacer posible pensar en una solución sustentable.

{{ :ciclodevidaciudadano.jpg?nolink&300 |}}

Solo una arquitectura de INTEGRABILIDAD eficiente, eficaz y sustentable ante cambios; organizacionales, políticos y tecnológicos, puede permitir su construcción.


La Iniciativa de INTEGRABILIDAD presenta un abordaje para resolver los múltiples problemas de comunicación que se plantean en los distintos niveles de la complejidad organizacional. Los mencionaremos como fases, etapas o niveles que deben ser cubiertos en el proceso de transformación


  * //fase 1:// **Comunicación inter-institucional** //→// //interoperabilidad // 


  * //fase 2:// **Comunicación inter-áreas** //→// //procesos// 


  * //fase 3:// **Comunicación entre sistemas y entre proveedores de software** //→// //SOA (Service Oriented Architecture) // 


===== El gran problema – El Gobierno Des-Conectado =====

\\ 
**El gran problema que padecemos es el Gobierno DES-CONECTADO**

{{ :wiki:burocracia.jpg?nolink&300 |}}

El Gobierno des-conectado, nos hace peregrinar por muchas ventanillas. Un gobierno des-conectado está formado de compartimentos aislados, que actúan como silos y es el ciudadano el que con su peregrinar por las ventanillas de las innumerables reparticiones públicas los va conectando. Es el peor escenario posible de interoperabilidad.

{{ :wiki:huellas_del_ciudadano.jpg?nolink&300 |}}

No importa cuánto invierta un organismo, ni cuan desarrollado este su portal con las últimas tecnologías web 2.0, encontraremos que hasta los que han instrumentado una “Guía de Trámites”, pedirán: “traer original y fotocopia de…” haciendo inviable poder completar los trámites en la web, cuando para los mismos se requiere controlar varios requisitos generados por otros organismos o reparticiones.

El Gobierno des-conectado no es problema de un organismo, es problema de la comunicación entre los organismos y solo resolviendo esta comunicación interinstitucional se puede avanzar.

\\ 
**La solución es construir un Gobierno CONECTADO** 

{{ :wiki:ventanillaunica.jpg?nolink&300 |}}

\\ 

La gran diferencia, el gran impacto positivo para **ciudadanos**, **empresas**, **organismos públicos ** es poder pasar de:

{{ :wiki:gobdesconectadoconectado.jpg?nolink&300 |}}

El resultado de poder realizar esta comunicación interinstitucional se materializa en la siguiente frase:


**//“Si // ****//un organismo del estado conoce algún dato sobre el ciudadano, ningún otro organismo del estado se lo puede // ** 


**//volver a preguntar o pedir” // ** 

\\ 
===== Manifiesto del Modelo de INTEGRABILIDAD =====


La INTEGRABILIDAD es un modelo que busca liberar a la sociedad de los altos costos que está pagando por no poder usar efectiva y eficientemente la **información**, de la que incluso es su dueña.


-En todo lo esencial y general debemos lograr la **UNIDAD ** de la **SOCIEDAD**.


-En lo part icular, debemos soportar la **DIVERSIDAD ** de los **INDIVIDUOS**.


-En el vínculo, asegurar una forma de **COMPARTIR ** que sea **SUSTENTABLE**.


Para lograr esto, la INTEGRABILIDAD ofrece una plataforma que permite compartir la información de una forma totalmente transparente, segura y confiable, respetando los derechos individuales y, a la vez, beneficiando a la sociedad en su conjunto. **Así gana el individuo y gana la sociedad** 


Se presentan a cont inuación los principios que permiten pasar de la situación actual a un modelo de INTEGRABILIDAD en operación real.


1. Respetar un modelo esencial y sustentable de intercambio de **información ** en un mundo de intereses diversos e incluso contrapuestos. Esto implica la necesidad de un **modelo equilibrado de comunicación sustentable.** 


2. La libertad de poder compartir **mi información, ** sin tener que preocuparme de las herramientas con que la misma fue producida. Necesitamos operar con **neutralidad tecnológica.** 


3. La libertad de poder construir nuevos usos; construir “**mi última milla”**en función de mi **necesidad particular, ** sin afectar los sistemas existentes. **Poder completar mi diversidad funcional sin restricciones.** 


4. La libertad de poder **controlar y auditar ** el uso seguro y adecuado de **mi información**. nica forma de poder **compartir en forma segura mi información.** 


\\ 
===== ¿Qué es la Iniciativa de INTEGRABILIDAD?: =====
 


La Iniciativa de Integrabilidad puede verse desde distintas perspectivas que deben ser conjugadas para poder hacerla realidad.


  * **Es un Cambio de Paradigma **→para pasar de Integrado a Integrable
  
  * **Es un Modelo de Actores **→Una estructura de poder equilibrado y de total transparencia.

  * **Es una Metodología de Cambio **→Pensar en Grande, Comenzar en pequeño y Crecer rápido.
 
  * **Es una Métrica **→Para poder identificar a los sistemas que cooperan de aquellos que entorpecen.

\\ 
===== La INTEGRABILIDAD en 3 ejes =====


Relac ionamos los 3 ejes del Modelo de Integrabilidad con 3 grandes reclamos que todo ciudadano tiene, para reforzar las tres fases que nos llevan a transitar por la Iniciativa de INTEGRABILIDAD:


  - **NO QUEREMOS PEREGRINAR NUNCA MAS, BASTA DE FOTOCOPIAS! ** 
  - **NO QUEREMOS HACER MAS COLAS, QUEREMOS PODER HACER LOS TRAMITES __COMPLETOS__ Y RAPIDOS POR INTERNET ! ** 
  - **NO QUEREMOS TANTAS VENTANILLAS “UNICAS”, TODO LO QUE NECESITO, LO QUIERO, DESDE UN SOLO PORTAL UNIFICADO! ** 


Se presenta a continuación un proceso de cambio gradual que permite pasar de la situación actual a un modelo de INTEGRABILIDAD en operación real.


Pensando en las características de nuestra cultura definimos los pasos necesarios para lograr el cambio de paradigma, un cambio donde debe primar el sentido común:


  - **Ventanilla única Física: ** Conectar los organismos entre sí informáticamente, basta de fotocopias, basta de hacer peregrinar al ciudadano. (comunicación interinstitucional – interoperabilidad)
  - **Ventanilla nica Digital: ** Rediseñar los procesos internos de cada organismo para tener Portales del organismo que permitan tramites completos y optimizados. (comunicación interáreas – procesos)
  - **Ventanilla Unificada: ** máxima simplificación de todos los tramites del ciudadano con organizaciones público - privadas. (comunicación entre sistemas – SOA)
   

\\ 
====== ACTORES del Modelo de INTEGRABILIDAD ======


La existencia de los distintos actores del modelo de Integrabilidad responde principalmente a la necesidad de establecer un real equilibrio de poder sustentable y un esquema de total transparencia para todos ellos.


Los actores son:


 0. **Autoridad Certificante:** Tercera parte confiable para todos, sobre la que descansa todo el modelo de intercambio seguro de información.  


 1. **Autenticador:** Es la guardia de entrada a la ciudad digital. Sólo si un usuario esta correctamente identificado puede operar dentro del modelo.


 2. **Coordinador:** Es el que, aplicando las normas legales que correspondan, solo deja acceder a los registros a los que se tiene derecho.  


 3. **Fuente Auténtica:** Mantiene y provee sus registros para compartir con el resto de los actores en un modelo acuerdos multilaterales.


 4. **Sistema Cliente:** Sistema que brinda sus servicios consumiendo registros de una o más fuentes auténticas del modelo.


 5. **Involucrado:** Ciudadano u organización sobre la que se refieren los registros que se transfieren entre un sistema cliente y las fuentes auténticas.

{{ :wiki:distribuciondelpoder2.jpg?nolink&300 |}}
\\ 
===== Autoridad Certificante =====


Es la que actúa como tercera parte confiable. Todo el modelo de Integrabilidad descansa sobre la Infraestructura de Clave Pública (PKI) **P**ublic **K**ey **I**nfrastructure.


Como condición indispensable para poder operar en el modelo todos los actores deben acudir a la Autoridad Certificante y seguir los procedimientos respectivos para solicitar su Certificado Digital. Los pasos básicos son:


 El usuario genera el par de claves (pública y privada).


 El usuario almacena en forma encriptada y protegida por contraseña su clave privada en algún equipo digital.


 El usuario envía su clave pública a la Autoridad Certificante, quien la incluye en un certificado digital con su propia firma y se lo envía al usuario.


 El usuario recibe también el certificado de la autoridad certificante, con el cual podrá verificar todos los certificados públicos emitidos que circularán por el modelo.

\\ 
===== Autenticador =====

Los usuarios también deberán registrarse en el Servidor Autenticador. Este registro contará con datos básicos para la operación como por ejemplo; Username, Password, Certificado Digital, №. de celular (para autenticación por dos factores), etc.


**Conceptualmente:** el Autenticador controla la identidad de los usuarios, que representan a los ciudadanos, las empresas y los organismos públicos (incluidos sus sistemas) que pueden ingresar y operar dentro de la “ciudad digital”. Solo los usuarios que tengan identidad conocida podrán operar en el modelo. Esto requiere no solo de la aplicación de pasos de registración, ya mencionados, sino también los necesarios para el mantenimiento y actualización de dichos registros.


**Tecnológicamente:** el Autenticador se materializa mediante un software (Server Autenticación) que mantiene en un directorio centralizado la identificación de todos los usuarios, para este fin, el Servidor Autenticador utiliza un Protocolo Ligero de Acceso a Directorios, (LDAP) **L**ightweight **D**irectory **A**ccess **P**rotocol .


El Autenticador, utilizando los registros de este directorio, proveé servicios de autenticación por 1 o 2 factores. El Primer factor es algo que el usuario debe saber, la ‘Password’, mientras que el segundo factor es algo que el usuario debe tener al momento de ingresar, como pueden ser un “e-token”, una tarjeta con chip, un teléfono celular. (Ver Anexo: Servicios de Autenticación – LDAP)


El Autenticador también puede servir de repositorio de los Certificados Públicos de los distintos actores para facilitar su disponibilidad en las operaciones de confirmación de la firma digital o de encriptamiento, en el envío de mensajes.

\\ 
===== Coordinador (Autorizador y Auditor) =====


**Conceptualmente:** El Coordinador asegura el cumplimiento de los acuerdos de confidencialidad. Representa la aplicación de las leyes emanadas de cada nivel de autoridad y debe reflejar o espejar la estructura del poder, esta es la clave para poder generar un equilibrio de poder sustentable. En países unitarios, con un Coordinador centralizado alcanza, en países federales como Argentina deberían existir al menos tres tipos de coordinadores, uno a nivel nacional, uno por cada provincia y uno por cada municipio. También pueden existir otros enfoques complementarios como son los coordinadores temáticos.

Todo Coordinador tiene la responsabilidad de hacer cumplir las normas legales de su nivel, es así que un usuario determinado sólo podrá acceder a los recursos a que esté autorizado por alguna norma legal. Algunas de estas autorizaciones son estáticas indefinidas en el tiempo y otras son dinámicas, tienen validez por cortos períodos de tiempo y bajo ciertas circunstancias.

Si bien todo pasa por el Coordinador, éste está tecnológicamente impedido para ver el contenido de los envíos, esto debe ser así para evitar posibles abusos por la simple posesión de información por acumulación. Esta imposibilidad está basada en un mecanismo de “doble sobre”, el sobre interior está firmado digitalmente y encriptado para ser visto solamente por el cliente que lo solicitó, de esta manera se asegura la confidencialidad del contenido del sobre interior de extremo a extremo. Los datos del sobre exterior son encriptados con la clave del Coordinador para que los utilice en sus operaciones de ruteo y registros de auditoría.


**Tecnológicamente:** Se materializa por un software (Server Coordinador), mediante un modelo de asignación de recursos basados en atributos de varios niveles (MABAC) **M**ulti level **A**ttribute **B**ased **A**ccess **C**ontrol (ver anexo White Paper MABAC). Este modelo de autorización fue creado para facilitar la definición, el mantenimiento y el control de los accesos de gran cantidad de usuarios internos a las organizaciones y externos, en un contexto tan complejo y diverso como es el gobierno electrónico.

Para permitir acciones de auditoría el coordinador registra los parámetros de cada pedido, el éxito o fracaso de la solicitud, con la fecha y hora de ejecución (Timestamp).

\\ 
===== Fuente Auténtica =====

Conceptualmente: Según la ley, existen organismos que son responsables de la creación y mantenimiento de algún tipo de registro y por lo tanto son la **F**uente **A**uténtica (FA) de dichos registros//. // Es importante distinguir éste rol de FA que se ocupa de la creación y mantenimiento de los registros, de otro rol como es el ser el “dueño” de los datos. Estos dos roles no siempre coinciden.

El proceso de identificación de las Fuentes Auténticas, requiere aplicar el sentido común buscando siempre “poner la responsabilidad donde más corresponde”.

Ser Fuente Auténtica significa mantener un determinado registro, esto implica lograr:


• Datos **Correctos** 


• Datos **Completos** 


• Datos **Vigentes**.


Entender el porqué de la necesidad de compartir datos, es la clave para evitar los actuales problemas de calidad de datos.


  Si el dueño de una Fuente Auténtica no comparte ‘legalmente’ sus datos, obligará a otros actores a crear copias o sus propios registros para poder realizar sus operaciones. Esto inevitablemente provocará la aparición de registros paralelos de mala calidad, nada ni nadie lo podrá evitar.

  La primera causa de la mala calidad de los datos es su propio aislamiento, la falta de verificación por el uso. Compartirlos legalmente es la clave para mantener su calidad en el tiempo.


Entonces podemos af irmar que si un organismo del Estado es Fuente Auténtica de algún registro sobre el ciudadano, el resto de los organismos que lo requieran, lo obtendrán consultando al organismo competente
 o Fuente Auténtica, en lugar de solicitárselo nuevamente al ciudadano.


**Tecnológicamente:** Se materializa por dos piezas de software que componen el Server Fuente Auténtica:


  **Hacia afuera **: Cumple con las funciones de seguridad, la firma digital y la encriptación de los envíos, mantiene un dialogo completamente seguro con el resto de los actores del modelo.


  **Hacia adentro **: Establece la conexión con las bases de datos de las fuente auténtica mediante sentencias SQL parametrizadas, o con web services provistos por los sistemas que administran dichas bases de datos. Este modelo permite la rápida implementación de los web services de Fuente Auténtica con mínimos o nulos requerimientos de programación.


===== Sistema Cliente =====

**Conceptualmente:** Es todo sistema que para lograr sus resultados deba consumir información de una o varias fuentes auténticas.

Un ejemplo de Sistema Cliente es que denominamos “e- Fotocopia”, que es utilizado para la generación de documentos electrónicos con timbre digital. Estos documentos los genera a partir de los datos registrados en una o varias fuentes auténticas, por ejemplo el Certificado de Alumno Regular. Estos documentos con timbre digital permiten reemplazar a las fotocopias exigidas como requisitos en los trámites. (Ver caso real más adelante).


**Tecnológ icamente:** es un sistema desarrollado para interactuar mediante Web Services con el resto de los actores del modelo de Integrabilidad. Una serie de componentes de desarrollo para distintas plataformas permiten la rápida incorporación de las funcionalidades necesarias y sin demasiados esfuerzos de programación. Las funcionalidades más importantes que se incorporan son: la autenticación del usuario por 1 o 2 factores, la obtención del catálogo de los servicios a los cuales el usuario está autorizado, los mecanismos de firma digital, encriptación y el manejo del dialogo (protocolo de seguridad) con el resto de los actores del modelo.


===== Involucrado =====

Serán los ciudadanos, empresas u organismos sobre los cuales se están transfiriendo información (sobre los que se habla). Los involucrados pueden no estar presentes, pero en el caso que la ley lo requiera deberán prestar su consentimiento (on-line) y quedar registrado, para que la transferencia de información se pueda concretar.


===== El dialogo seguro entre actores: =====

El diseño de este dialogo seguro entre los actores del modelo lo realizó el Departamento de Ciencias de la Computación de la Facultad de Economía y Administración de la Universidad Nacional del Comahue. (Ver Anexo: Arquitectura para la Integrabilidad de Servicios sobre el protocolo HTTP basado en PKI)


==== Análisis de la necesidad: ====

Si bien existen soluciones disponibles que a través del uso de la Transport Layer Security (TLS), envían mensajes sobre HTTPS de forma segura. Esta técnica no alcanza en nuestro caso dado que los mensajes necesitan pasar por el Coordinador (que actúa de proxy), de usar esta solución el Coordinador estaría habilitado a ver el contenido de los mensajes, con HTTPS, en realidad, solo podemos garantizar la seguridad punto a punto; (FA↔Coordinador) y (Coordinador↔Cliente).


En la iniciativa de Integrabilidad se planteó garantizar la seguridad extremo a extremo (FA↔Cliente) independientemente de tener que pasar por el Coordinador, esto significa asegurar que ningún componente centralizado de administración tenga la más mínima posibilidad de acceder al contenido de los datos confidenciales. Esta garantía de seguridad se alcanza con un modelo de “doble sobre”, concepto muy utilizado en procesos electorales, para la votación de personas que residen en el exterior de un país. El sobre externo sirve para certificar el acto mismo en el ‘coordinador’ del comicio, mientras el sobre interno mantiene la confidencialidad de los datos de la elección. Para que esto sea posible, el armado de los sobres debe necesariamente ser realizado en el extremo, o sea en el sistema que actúa como Fuente Autentica en nuestro caso.


Otro punto, de vieja discusión en temas de seguridad de transferencia de datos, es: ¿Debemos proteger los canales de comunicación o los datos que circulan por ellos?


En Estonia[4] utilizan una analogía para explicar muy bien este concepto, preguntándose: ¿Qué necesitamos proteger, al Rey (persona) o el camino del bosque (donde el Rey se mueve)? y la respuesta con sentido común, es proteger al Rey (los datos) porque las estadísticas indican que muchos de los ataques provienen del interior de las organizaciones, por personas mal intencionadas o por virus y programas troyanos que logran instalarse dentro de nuestro supuesto ‘entorno seguro’.

En el próximo capítulo “Fase 1 de INTEGRABILIDAD- Ventanilla nica física” se describen las fuerzas que dan forma al modelo de actores. Tan solo las enumerarlas ahora y son; la complejidad sistémica, las estructuras de poder, como garantizar la total seguridad para los actores.

Dadas estas restricciones, se planteó un diseño del protocolo desde cero para el diálogo entre los actores del modelo de Integrabilidad. La solución se encontró apoyándose solamente en la Infraestructura de Clave Púbklica (PKI), logrando así asegurar la total integridad y confidencialidad de los datos, extremo a extremo.


==== Ejemplo de diálogo ====

Recorramos un dialogo simplificado para ver cómo interactúan los actores entre sí. Podemos imaginar que somos ciudadanos de una ciudad digital:

O Para poder ingresar tenemos que presentar nuestra identificación ante el Guardián de la puerta de la ciudad. Este guardián es el actor **Autenticador**.


  *  El Autenticador valida la pass del usuario con el LDAP.

  *  Genera un ticket de validez temporal para que el usuario puede operar.
 

O Una vez que estamos dentro del perímetro digital, habrá servicios que podemos querer utilizar, pero para poder hacer uso de los mismos debemos tener la correspondiente autorización. Esta autorización es administrada por el actor **Coordinador**, y a él se le debe pedir el servicio.


  *  El Coordinador verifica la validez del ticket con el LDAP

  *  En vía la lista de servicios autorizados al Cliente.

  *  El Cliente solicita el Certificado digital de la Fuente Auténtica con la que operará.

  *  El Coordinador le envía el Certificado digital de la FA

  *  El Cliente firma y encripta la solicitud del servicio que requiere.


O Este Coordinador trasladará la solicitud a la **Fuente Auténtica** correspondiente (organismo del estado o empresa privada).

  *  La Fuente Auténtica verifica la validez del ticket del Coordinador en el LDAP

  *  La Fuente Auténtica resuelve la consulta y envía la respuesta al Coordinador

O El pasaje de nuestro pedido y la respuesta quedará registrada en el Coordinador para poder realizar acciones de Auditoria. El Coordinador sabe quien pidió, que pidió, a quien se lo pidió y también cuando recibió la respuesta, si esta fue satisfactoria o no, pero no podrá nunca conocer el contenido de la información solicitada.

  *  El Coordinador rutea la respuesta al Sistema Cliente asegurando confidencialidad extremo a extremo.

  *  El Coordinador registra información de auditoría, “sobre externo” mas tiempos.

O La Respuesta llegará al Sistema Cliente firmada digitalmente por la Fuente Auténtica y encriptada para que solo el cliente solicitante pueda leerla.

O Todos los actores podrán auditar los intercambios de información realizados:

  *  El **Coordinador:** todo el movimiento de información y el nivel del servicio.

  *  La **Fuente Autentica:** que servicios ha brindado a los Clientes

  *  El **Sistema Cliente: ** podrá analizar qué servicios ha solicitado o consumido.

  *  El **Involucrado (ciudadano):** quiénes han estado solicitando información de su persona.


==== Protocolo completo entre actores: ====

{{ :wiki:protocolocompleto.jpg?nolink |}}

\\ 


====== Fase 1 de INTEGRABILIDAD - Ventanilla única física ======


La fase 1 tiene por objetivo implementar una infraestructura de comunicación entre todos los actores, es instalar “un sistema que opera entre los sistemas”.


El siguiente gráfico muestra el resultado que logra la fase 1, pasamos de tener un modelo de interoperabilidad basado en papeles transportados por “ciudadanos itinerantes”, a una plataforma de interoperabilidad segura que le permite al ciudadano presentarse sin papeles y sólo con su identificación en la ventanilla del organismo donde debe realizar un trámite.

{{ :wiki:ventanillaunicaintegrabilidad1.jpg?nolink&300 |}}

La arquitectura de esta plataforma de interoperabilidad debe tener en cuenta las distintas exigencias que operan en la realidad de un modelo de gobierno electrónico:


O **La complejidad sistémica :** que genera la diversidad y cantidad de sistemas que deben interoperar. Aquí se plantean dos modelos extremos, uno mediante acuerdos bilaterales y otro mediante acuerdos multilaterales

O **La estructura de poder :** que debe acompañar necesariamente a la estructura formal de gobierno, en países federales varios niveles distribuidos, en países unitarios modelos más centralizados.

O **La garantía de seguridad para los actores :** La imposibilidad física de violar la integridad y confidencialidad de los datos por un lado y el mantener el control permanente (sin ninguna sesión) de la parte que le compete a cada actor.


===== Interoperabilidad =====
 


==== La complejidad sistémica ====


Existen en uso dos modelos sistémicos extremos de acuerdos entre los actores:


{{ :wiki:acuerdosmultibilaterales.jpg?nolink |}}


 **Acuerdos Bilaterales **: Implica vinculaciones/interfaces sistema a sistema para todos aquellos que requieran intercambiar información, estamos hablando de cientos o miles de sistemas. Este enfoque obliga a cada actor a tener que construir múltiples interfaces para soportar la heterogeneidad de casos.

  * Altísimo costo en el desarrollo y alto impacto ante la modificación que genera de cualquier alteración de alguno de los sistemas.

  * Difícil modelo de operación y control que impide asegurar la confidencialidad y seguridad en el intercambio de información.


 **Acuerdos Multilaterales **: En este caso cada sistema heterogéneo solo tiene que establecer una sola interface estándar con el modelo multilateral.


  * Menor costo inicial y mínimo impacto ante la modificación de cualquiera de los sistemas.

  * Facilidades de operación y control ya que pueden realizarse en forma centralizada.


Si tomamos conciencia de la escala tanto en cantidad, como en diversidad que debe atender una implementación de gobierno electrónico, la conclusión lógica es que sólo el enfoque de **Acuerdos Multilaterales ** es un modelo viable.


=== Primera conclusión: ===


  * La iniciativa de Integrabilidad soporta la complejidad sistémica con un modelo de **Acuerdos Multilaterales** 



==== La estructura de poder ====


A la hora de montar el modelo de Acuerdos Multilaterales, se puede pensar en implementarlo en forma totalmente **centralizada ** mediante un solo coordinador para todos los sistemas (si es que eso es técnicamente viable por el volumen de transacciones y criticidad que se genera), pero lo que aquí realmente entra a jugar es otra dimensión del problema y no es tecnológica, es un problema de la estructura del poder.

Como dice Carlos Matus [6] se debe tratar de descentralizar por el criterio de “**alto valor**”. En un sistema totalmente centralizado el coordinador está obligado a decidir sobre problemas y temáticas de bajo valor para él, esto termina haciéndolo mal y a destiempo, pero por otro lado estos problemas de “bajo valor” para el coordinador central son temas de alto valor para otros potenciales coordinadores, quizás de niveles inferiores. El punto justo y equilibrado del nivel de descentralización requerido se logra cuando todos deciden sobre temas de “alto valor”.

Esto implica que en una estructura de gobierno federal con tres niveles, el nacional, el provincial y el municipal con sus estructuras normativas legales administradas en cada uno de ellos, la estructura de pensar en un Coordinador Nacional, Coordinadores Provinciales y Coordinadores Municipales.

Dada la existencia de temas transversales que afectan por igual a todos los niveles de la estructura de poder, como pueden ser, por ejemplo, temas de la Salud, se requerirán de otros coordinadores que llamaremos “Coordinadores Temáticos” para dotar de las capacidades de coordinación en dichas temáticas que son comunes a todos los niveles de gobierno.


=== Segunda conclusión: ===


  * La iniciativa de Integrabilidad soporta la estructura de poder, espejando la estructura formal con **múltiples Coordinadores ** de acuerdo a la misma.


==== La garantía de seguridad para los actores: ====


**La imposibilidad de violar la confidencialidad de los datos: ** toda la plataforma de interoperabilidad, que se precie de tal, se debe basar en un modelo inviolable. Hoy el estado del arte en materia de seguridad indica que sólo una plataforma que se base en la infraestructura de clave pública (PKI) puede asegurar esta inviolabilidad. La Iniciativa de Integrabilidad utiliza a la PKI como el núcleo a partir del cual se construye todo el modelo.

Como ya se comentó en el capitulo anterior, la estrategia de “doble sobre” nos permite garantizar la seguridad extremo a extremo.

También como vimos, el protocolo prioriza la seguridad de los datos por sobre la seguridad de los canales para poder operar en internet abierta.

Este último punto es clave para un gobierno electrónico que debe funcionar sobre internet abierta para todos los actores y proveedores de servicios que intervienen y la necesidad que todos los ciudadanos puedan operar en el modelo.


**Mantener el control permanentemente: ** Este concepto de mantener el control permanente (sin sesión) de la parte que le compete a cada actor, se basa en la necesidad de mantener el control total de forma autónoma de cada organismo. Cada organismo debe mantener el poder de autorizar o des-autorizar a cualquiera de los coordinadores del modelo. Esto exige que el control sea local en cada Fuente Auténtica.



=== Terceras conclusiones: ===


  * La iniciativa de Integrabilidad garantiza la seguridad y protección de los datos por sobre los canales y ejecutando las actividades de control de accesos y de firma y encriptamiento en forma local.


==== Conclusiones Finales para la arquitectura de interoperabilidad: ====

Esta serie de exigencias deja pocas posibilidades sobre cual es una implementación viable de la iniciativa de Integrabilidad , dado que:


Por el lado de la complejidad sistema se requiere un modelo de:


  * **Acuerdos Multilaterales** 


Por el lado de la estructura de poder se requiere de:


  * **Múltiples Coordinadores ** (Nacional, Provinciales, Municipales y Temáticos)


Por el lado de la garantía de segur idad para los actores se requiere:


  * Priorizar la **protección de los datos ** por sobre los canales y ejecutar el **control de accesos y de firma y encriptamiento en forma local**.

\\ 
===== Interoperabilidad en la nube =====


Otra forma de visualizar la estructura de actores de Integrabilidad es utilizando el concepto de la “nube de internet”.

Los actores conforman una especie de “nube baja”, creando sobre la conectividad una infraestructura que permite compartir información de calidad en forma flexible y segura, realizando esto en forma armónica con las estructuras de poder.

Veamos gráficamente el esquema donde se representan múltiples Fuentes Auténticas, el Autenticador, los distintos tipos de Coordinadores y varios Sistemas Clientes.


(**Proveedores **) ↔ (**Autenticación**–**Autorización **) ↔ (**Clientes **)

{{ :wiki:interoperabilidadenlanube.jpg?nolink&300 |}}
 
Un simple giro de 90° permitirá visualizar la “nube baja” de interoperabilidad segura

{{ :wiki:interoperabilidadenlanube2.jpg?nolink&300 |}}
 
Como puede observarse la solución es un modelo equilibrado de coordinación centralizada como primera prioridad, pero distribuida en múltiples coordinadores, según la estructura de poder y donde cada Fuente Auténtica mantiene el control de las autorizaciones de sus propios servicios:


Cada Servidor de Fuente Auténtica puede:


 Parametrizar mediante consultas SQL los servicios de consulta a los registros que administra (cero programación), especialmente indicado para sistemas legados que no pueden ser modificados


 Definir nuevos servicios mediante el desarrollo de Web Services, modalidad más indicada para nuevos sistemas a adquirir o desarrollar.


 Administrar y controlar localmente las autorizaciones de sus propios servicios a los distintos Coordinadores.


Cada Servidor de Coordinación puede:


 Autorizar a múltiples sistemas clientes los accesos a las Fuentes autenticas que, según las normas legales, tienen derecho a consultar.


El Servidor de Autenticación puede:


 Asegurar la identificación de todos los actores que participan del modelo.

\\ 
==== Plataforma para múltiples canales ====


Esta “nube baja” de interoperabilidad segura es la plataforma para un “nube alta” donde se pueden brindar múltiples Servicios de valor a la Comunidad, por todos los canales.

{{ :wiki:multiplescanales.jpg?nolink |}}

==== Guía de trámites 2.0 ====


En la actual idad una “Guía de Trámites 1.0”, indica la lista de requisitos (fotocopias con sus correspondientes originales) que se deben presentar en la ventanilla de un organismo.


Ahora completando la fase 1 de Integrabilidad podemos hablar de requisitos que se deben cumplir y que son de probación on-line. Esto significa que, si cumplo con los requisitos sólo me tengo que presentar con mi identificación, pero sin llevar las famosas fotocopias.


La ventanilla de un organismo o el mismo ciudadano puede obtener sus “e- fotocopias con timbre digital” de cualquiera de las Fuentes Auténticas.


Debe observarse que esto no tiene impacto en los procedimientos y sistemas que se encuentren en uso, es de rápido despliegue y la mejor manera de comenzar con Integrabilidad.


**Guía de trámites 1.0                  vs                   Guía de trámites 2.0 ** 


  * <del>Fotocopia del D.N.I</del>                       por Tener identificación personal

  * <del>Fotocopias del Certificado de Escolaridad</del> por Ser alumno regular

  * <del>Fotocopias de Recibos de Sueldos</del>          por Ser empleado

  * <del>Fotocopias de Libre de Deuda</del>              por No tener deudas con el estado 

  * <del>Fotocopias del Certificado de domicilio</del>   por Vivir en la localidad 

  * . . .                                                por 
===== Consideraciones de la fase 1: =====


–No exige cambio alguno en ninguno de los sistemas actuales, ni en las leyes, ni en las reglamentaciones vigentes a nivel de requisitos.


–Solo impacta en la operación de las mesas de entrada y la normativa de aceptación del documento con timbre digital.


–Pero t iene un alto impacto simplificando la vida del ciudadano


–Aumenta efectivamente la calidad de los datos por el uso de cada uno de los sistemas involucrados. A más uso → más control → más cal idad.


–Simplifica la comunicación interinstitucional (contexto on-line)


–Es el próximo paso para una guía de trámites → automat izando los requisitos de los trámites (e-fotocopia con timbre digital).


–Da soporte al cumplimiento de la ley de Habeas Data. (consentimiento) (ver Anexo: Soporte a la Ley 25.326 - Habeas Data)


–Conforma una capa de seguridad en la nube, creando un modelo integrando con los sistemas aislados y diversos.


===== Resultados de la fase 1 =====


**Conclusión**: Cada Organismo se alinea accediendo a los registros que no produce (fuera de su competencia) y agrega valor registrando los que produce (su competencia). Todos los registros son compartidos, según la ley con los demás organismos del estado.


**Resultado**: Ningún organismo del Estado le puede pedir al ciudadano datos que el “Estado” como conjunto ya tiene de él.


===== Caso real de aplicación fase 1: =====


A continuación se muestra las pantallas de un Sistema Cliente (e- fotocopia) que, montado sobre la nube baja de interoperabilidad, permite brindar servicios de información reemplazando las fotocopias en los requisitos de trámites mediante un documento digital (símil papel, cuya impresión lo reemplaza de ser necesario) con timbre digital:

{{ :wiki:casorealfase1.jpg?nolink&300 |}}
\\ 
Sigamos paso a paso su uso, en el cuadrante superior derecho se indica con que actor del modelo de Integrabilidad está dialogando el sistema Cliente:


**Autenticación** 

{{ :wiki:casorealautenticacion.jpg?nolink |}}

**Autorización y Acceso al servicio de la Fuente Autentica “A”** 

{{ :wiki:casorealaccservicio.jpg?nolink |}}
{{ :wiki:casorealconsultaservicio.jpg?nolink |}}
{{ :wiki:casorealimprefotocopia.jpg?nolink |}}
\\ 
**Autorización y Acceso al servicio de la Fuente Autentica “B”** 

{{ :wiki:casorealcertescolaridad.jpg?nolink |}}
{{ :wiki:casorealcertregularidad.jpg?nolink |}}
{{ :wiki:casorealimprregularidad.jpg?nolink |}}
\\ 
**Autorización y Acceso al servicio de la Fuente Autentica “Coordinador”** 


En función de quien sea el actor que lo solicita, el Servidor Coordinador entrega los registros de auditoría sobre el tráfico de solicitudes y respuestas que le competen en un período temporal determinado.


**Fuente Auténtica **: Todos los registros de los servicios entregados.


**Involucrado**: Todas los registros de los servicios que lo tienen como involucrado


**Sistema Cliente **: Todas los registros de los servicios solicitados

{{ :wiki:logauditoriaciudadano.jpg?nolink |}}
{{ :wiki:logauditoriaciudresultado.jpg?nolink |}}
\\ 
====== Fase 2 de INTEGRABILIDAD - Ventanilla única digital ======
 


Una vez que la información requerida de otros organismos esta accesible por la fase 1 del modelo de Integrabilidad, esto significa que todo el trámite se puede hacer en un solo punto o ventanilla, el siguiente paso (fase 2) es llevar esa ventanilla física a una ventanilla totalmente digital.

{{ :wiki:ventanillaunicadigital.jpg?nolink&300 |}}

La mayoría de los requisitos que otros deben proporcionar para realizar un trámite serán obtenidos (on-line) por la interoperabilidad lograda en de la fase 1, entonces ahora la próxima mejora pasa a ser problema del propio organismo. En este punto se cae en la tentación de tratar de resolverlo tecnológicamente, pero lamentablemente no es así, los problemas internos de procesos seguirán vigentes.


Poner en la web los trám ites de un organismo sin mejorar o rediseñar los procesos internos es uno de los errores más comunes de esta etapa.

\\ 
===== Patologías que tenemos que evitar: =====
 

A continuación se muestran dos imágenes que representan con claridad dos patologías muy comunes en la que quedan atrapadas la mayoría de las organizaciones:


\\ 
**Cáscara web **: donde se presenta información e incluso interacción en la web pero que no está soportada por los procesos internos, los cuales continúan desorganizados e ineficientes. A pesar de lo vistoso que pueda ser el sitio, los trámites no podrán ser completados rápidamente vía web y sufrirán las mismas o semejantes demoras que antes.

{{ :wiki:gobiernoineficiente.jpg?nolink&300 |}}

**Informatizar la ineficiencia **: muchas de las metodologías de desarrollo de aplicaciones de software se basan en los “casos de uso”, esto está muy bien, está alineado con las necesidades del “usuario”, el problema es que o están basadas en procesos ineficientes y/o no hay una visualización colectiva y compartida por parte de los usuario de los nuevos procesos que se podrían implementar, por lo cual se definen a partir de visiones muy parciales de la realidad.


\\ 
{{ :wiki:redisenocaneriasprocesos.jpg?nolink&300 |}}
===== Rediseño Participativo de Procesos =====



Solo es posible evitar estas patologías, si se rediseñan los procesos antes de informatizarlos. Veamos cómo podemos pasar de un estado actual a uno deseado en forma participativa, segura y minimizando la resistencia al cambio.

{{ :wiki:redisenoantesydespues.jpg?nolink |}}
\\ 
La metodología de “Rediseño Participativo de Procesos” facilitará el nivel de transformación que solo la inteligencia colectiva puede lograr


==== Introducción ====


El “Rediseño Participativo de Procesos”, [5],[10] es una metodología de reingeniería de procesos que tiene por objetivo mejorar los servicios que un organismo brinda a su comunidad. Trabajando sobre los trámites administrativos y modificando las micro-prácticas de trabajo, se logra una real transformación de los procesos incrementando fuertemente la eficacia y eficiencia en los servicios que presta el gobierno local.


Existen diferentes modelos para mejorar los Procesos


  * **(Copiarlo): **Adopto un proceso que ya funciona, por ejemplo una "Buena Práctica" 
  * **(Un experto): **A lguien analiza y define un buen proceso a medida del caso. 
  * **(Un equipo de cambio) **Se constituye un equipo que analiza alternativas y definen los nuevos procesos. 
  * **(Los involucrados): ** **// REDISEÑO PARTICIPATIVO // **donde se hace __emerger el mejor proceso posible__, minimizando la resistencia al cambio. \\  


Este último modelo es el seleccionado para lograr resultados sustentables en organizaciones del estado.


Mediante la realización de talleres con todos los actores involucrados, el Rediseño Participativo de Procesos permite que los participantes transiten por una serie de etapas completamente acotadas y controladas para que puedan:


 Crear una visualización compartida de la situación actual.

 Definir objetivos de cambio; alineados un Marco Límite del Cambio definido con los decisores y enfocados desde las necesidades del ciudadano.

 Encontrar nue vas formas de operar que respondan a las reales necesidades de todos los actores, internos y externos.

 Operar y monitorear los nuevos procesos de forma inmediata.


Aprovechando el conocimiento de todos los involucrados (administración, decisores y público en general), aportando con expertos el conocimiento faltante, la metodología permite alcanzar mejoras altamente innovadoras que logran una mayor celeridad y eficiencia en la gestión de los servicios a los ciudadanos, agregando la posibilidad de monitorear los procesos y soportar su operación.


A su vez, al permitir la activa participación de los implicados, no se producen resistencias frente a la modificación de los procesos, ya que todos consideran el cambio como necesario y son ellos mismos los que producen e impulsan el cambio.


La metodología combina tres disciplinas troncales:


 El Comportamiento Humano

 La Gestión de Calidad

 El uso de Tecnologías de Información y Comunicación


==== Etapas de la Metodología ====
 


Esta metodología consta de una ser ie de etapas donde se producen diferentes tipos de negociación entre los actores que van convergiendo en el proceso buscado.


O //Etapa 1: //**Radiografía** 


O //Etapa 2: //**Marco límite del Cambio ** y **Acuerdos Externos** 


O //Etapa 3: //**Rediseño Participativo ** 


O //Etapa 4: //**Gestor de Compromisos ** 


O //Etapa 5: //**Gobierno de Procesos ** 

\\ 

=== Etapa 1: Radiografía ===


Se busca la foto radiográfica del estado actual del proceso, esto se logra sumando las visiones individuales de los involucrados y ajustando las inconsistencias.

{{ :wiki:etapa1radiografia.jpg?nolink |}}

**Radiogradia →****Negociación 1 ** (Acuerdo interno con mis pares sobre proceso actual a nivel de intercambios entre los roles)


 Posibles resultados de la negociación


  * 0 - Todo esta OK (acuerdo)

  * 1 - No neces ito (eliminar) 

  * 2 - Omisión (agregar)

  * 3 - Problema de nombre (ajustar)

  * 4 - No hay acuerdo (ayuda el facilitador)
\\ 
**Resultados de la Radiografía**:


 Imagen (especie de socio-grama) de las relaciones que se generan por el proceso en estudio acordado por todos los participantes.


 Grupo de personas preparadas para el cambio, se genera una urgente necesidad colectiva de cambiar el proceso actual.

\\ 

=== Etapa 2: Marco límite del Cambio y Acuerdos Externos===


**Marco Límite del Cambio: ** 


En paralelo con la Etapa 1 la dirección debe definir el Marco Límite del Cambio [8], [9]. Esto se construye explicitando el rumbo bajo cuatro tipos de premisas:


  * Las que expresan los **Valores esenciales y creencias ** que se deben seguir.

  * Las que expresan los **Riesgos que deben evitarse, ** para ponen límites sobre lo que no debe hacerse, pueden ser límites éticos y también límites estratégicos.

  * Las que expresan **Objetivos Críticos ** que deben lograrse de forma eficaz y eficiente. Esto permite definir indicadores y realizar controles basados en métricas claras.

  * Las que expresan **Proactividad en la incertidumbre**, para sacarnos las dudas y permitir prepararnos para posibles situaciones.


La etapa de Radiografía prepara al grupo humano para poder trabajar con las siguientes prioridades:

{{ :wiki:etapa2prioridades.jpg?nolink&300 |}}

EL Marco Límite del Cambio es una herramienta para el alineamiento


**Marco Límite del Cambio →****Negociación 2 ** (Acuerdo Dirección - Personal)


 Lograr el alineamiento, comprender lo que se quiere lograr


  * Presentar el Marco Límite del Cambio

  * Evaluar factibilidad de las metas entre todos

  * Definir recursos necesarios

  * Ajustar objetivos de ser necesario

  * Al inearse con el Marco Limite acordado


**Resultados del Marco Límite del Cambio **:


Un conjunto de premisas acordadas que fijan la dirección y serán respetadas como leyes en las próximas etapas.


Al marco límite lo llamamos **“El potenciómetro del cambio”**dado que es el instrumento de control que tiene la dirección de cuánto y hacia donde quiere que la organización cambie.


**Acuerdos Externos ** 


Conociendo el proceso actual (radiografía) y el Marco Límite del Cambio se convoca a participar a los Externos involucrados en el proceso (externos de la organización e internos que si bien interactúan con el proceso quedan fuera del alcance definido)


**Acuerdos Externos →****Negociación 3 ** (Acuerdo con externos)


 Esta fuera del área de control


  * Aprender a escuchar reclamos

  * Recibir sugerencias

  * Negociar alternativas

  * Crear nuevas alternativas


**Resultados de Acuerdos Externos**:


Surgirán nuevas formas de interactuar (momentos de la verdad) que están concordantes con la necesidad del cliente y dentro del Marco Límite del Cambio definido por la dirección.

{{ :wiki:etapa2acuerdosexternos.jpg?nolink |}}

Estos nuevos momentos de la verdad configuran los resultados que deberá producir el nuevo proceso a diseñar en la próxima etapa – el rediseño.


Conocemos los inputs y los outputs del futuro proceso, ahora entre todos debemos encontrar (rediseñar) ese proceso.


\\ 
=== Etapa 3: Rediseño Participativo===


El rediseño participativo utiliza una modalidad de facilitación que evita quedar bloqueados en lo que siempre hemos hecho. Se aplica una estrategia basada en las necesidades que como lo plantea Carlos Matus [6] se genera el máximo nivel de innovación posible, él define 3 niveles de innovación:

\\ 
Nivel 1: Exige el análisis y enfrentamiento de un Problema.

  * Analiza el problema existente.

  * No cuestiona el tipo de producto o servicio. 

\\ 
Nivel 2: Exige disolver el Problema

  * Cuestiona y sustituye el producto o servicio.
 
  * Mantiene como una constante la Necesidad. 
\\ 

Nivel 3: Redefine el Problema

  * Analiza la vigencia de la necesidad

  * Intenta substituirla


Dado que contamos con las nuevas necesidades externas que debe cumplir el proceso, el facilitador realiza preguntas a los participantes haciéndolo desde la salida final del proceso hacia atrás, como si estuviera “rematando necesidades”.


Las preguntas son:


//1////) //**//¿Quién debería entregarlo? // **//→////permite identificar a la persona responsable de la salida, la necesidad objeto de las preguntas. // 


//2////) //**//¿Cuál es su agregado de valor? // **//→////logra que la persona identificado, focalice en la necesidad y plantee con toda su experiencia el agregado de valor más pertinente. // 


//3////) //**//¿Qué necesita para hacerlo bien? // **//→////conociendo el agregado de valor la persona plantea sus propias necesidades para poder realizar su tarea. // 


Recursivamente se va encontrado el árbol de necesidades que satisfacen todos los requerimientos del proceso.

{{ :etapa3arbolnecesidades.jpg?nolink&300 |}}
\\ 
En la imagen se puede observar que al cambiar las necesidades se “podan” ramas completas de los procesos actuales. Esto produce cambios muy significativos pero, al mismo tiempo, muy seguros ya que son generados por las mismas personas que posteriormente lo aplicarán.

{{ :wiki:etapa3revisionparticipativa.jpg?nolink |}}

El árbol de necesidades encontrado puede redibujarse en forma secuencial, lo que da origen al flujograma del nuevo proceso. Luego de esta pasada hacia atrás, se obtiene la línea principal del proceso, con algunas pasadas hacia adelante se completan las secuencias condicionales y finalmente se lo puede robustecer, exponiendo el nuevo proceso a casos de excepción y completándolo con las acciones necesarias para atender dichos casos.


\\ 
**Rediseño Participativo →****Negociación 4 ** (Alineamiento desde la necesidad del Cliente interno o externo)


 Remate de neces idades y oferta de soluciones


  * Escuchar la necesidad

  * Ofrecer (servicio / producto)

  * Identificar agregado de valor

  * Definir las necesidades propias


\\ 
=== Etapa 4: Gestor de Compromisos===


El proceso identificado debe ser ahora implementado en un workflow para que entre lo antes posible en operación. Si bien no entraremos en detalles sobre este tipo de herramientas, estamos hablando de motores totalmente configurables donde:


• Las actividades o tareas simples no requieren programación, solo parametrización.

• Las actividades o tareas son complejas puede requerir:

  * Desarrollos especiales comunicándose mediante Web Services con el motor de workflow.

  * Integrar sistemas legados para que puedan ser convocados por el workflow.


\\ 

=== Etapa 5: Gobierno de Procesos ===


Con el proceso en operación, ahora resta el monitoreo y seguimiento de sus instancias para poder mantenerlo bajo control y detectar desvíos que puedan requerir ajustes puntuales o replanteos (nuevos rediseños). Aquí existen múltiples herramientas como tableros de control por excepción, trazabilidad de instancias etc.


**Características distintivas de esta metodología participativa: ** 


En lo COMPORTAMENTAL:


  * Permite EXPERIMENTAR y ADUEÑARSE del CAMBIO (VER-SENTIR-CAMBIAR).

  * Las personas generan el CAMBIO EN FORMA COLECTIVA Y COLABORATIVA, teniendo en cuenta todos los puntos de vista.

  * Los tiempos de cambio respetan los tiempos humanos de la organización (FLUIDEZ DEL CAMBIO).

  * El cambio es totalmente controlado, de bajo riesgo y sustentable.


En los PROCESOS


Cambiando la forma de hacer las cosas – dejando de hacer lo que no sirve.

  * Triangulando los lineamientos políticos de la alta dirección y las necesidades planteadas por la situación de contexto (ciudadanos, empresas, etc.)
 
  * Cuestionando las necesidades, el proceso se piensa desde el final hacia atrás, podando las actividades innecesarias sin dolor.


En la TECNOLÓGICA


  * Haciendo lo que sirve más rápido y aprovechando mejor los recursos.

  * Graficando automáticamente los Flujogramas, Árboles de Necesidades, Redes de trabajo en la misma reunión de trabajo grupal.

  * Usando las TICs para guiar la transformación y soportar la posterior operación.

\\ 
===== Consideraciones de la fase 2:=====


¿Porqué las metodologías de desarrollo de sistemas más modernas no logran aún resolver las reales necesidades de los procesos?


– Porque trabajan por funciones, mientras la realidad opera por procesos.


– Porque se apoyan en la interpretación de un analista y para cada uno de ellos la realidad puede ser algo diferente.


– Porque la me jor solución depende primordialmente del contexto.
\\ 

===== Resultados de la fase 2: =====


– Permite encontrar la mejor solución posible para la situación planteada integrando las necesidades de todos los actores.


– Evita informatizar la ineficiencia porque rediseña los procesos antes de automatizarlos.

\\ 
===== Caso real de aplicación fase 2: ===== 


A modo de ejemplo se presentan las imágenes de un proceso real rediseñado: 

Maraña de Relaciones entre los actores ANTES de aplicar el Rediseño Participativo de Procesos 

{{ :wiki:casorealfase1actoresinteracciones.jpg?nolink |}}

Red de Relaciones acordadas DESPUÉS del Rediseño Participativo de Procesos 

{{ :wiki:casorealfase1postrediseno.jpg?nolink |}}

Flujograma del proceso ANTES de Rediseño Participativo de Procesos 

{{ :wiki:casorealfase1flujograntes.jpg?nolink |}}

Flujograma del proceso DESPUÉS de Rediseño Participativo de Procesos 

{{ :wiki:casorealfase1flujogrpost.jpg?nolink |}}

Y si observamos esta misma transformación desde el punto de vista del contribuyente, podemos ver una importante simplificación de los trámites:

{{ :wiki:casorealfase1antesydespues.jpg?nolink |}}
\\ 
===== Relación de impacto entre la fase 1 y fase2 =====

Como puede verse el mejor proceso es siempre “el mejor proceso para un contexto dado”. Podemos mejorar el contexto en alguna medida en la etapa “acuerdos externos”. Esto marca la importancia de esta etapa, dado que cuanto mas simplificaciones se logré con los externos, siempre dentro del Marco Límite del Cambio, más eficiente y eficaz será el nuevo proceso rediseñado. Pero por otro lado la capacidad de cambio que tenemos en estos acuerdos externos es bastante limitada y focalizada al caso que estamos analizando, esto es, son cambios locales que no tienen alto impacto en los otros procesos.


Identificar estas relaciones causa efecto es clave para comprender el poder de apalancamiento que existe en la secuencia de las fases 1 y 2 de la Iniciativa de Integrabilidad. Si primero mejoramos y automatizamos las relaciones de intercambio interinstitucional (fase 1), el contexto se agiliza, se automatiza y entonces con el mismo esfuerzo en las actividades de rediseño participativo (fase 2), el proceso resultante es muchís imo más eficiente y eficaz.


\\ 
====== Fase 3 de INTEGRABILIDAD - Ventanilla Unificada ======


La fase 3 al igual que las dos primeras es también un problema de comunicación, en esta etapa le llega el turno a los sistemas de aplicación de los distintos organismos. Esta fase busca que todos estos sistemas puedan participar en los mismos procesos y presentarse con una sola interface unificada al ciudadano.

{{ :wiki:fase3ventanillaunificada.jpg?nolink&300 |}}

 En la fase 1 el foco estaba puesto en los datos distribuidos en las distintas Fuentes Auténticas, no duplicar datos.


 En la fase 2 el foco estaba en reordenar los circuitos de trabajo dentro de cada organismo, atendiendo sus diversas particularidades.


 En la fase 3 el foco esta en el aprovechamiento de los sistemas de aplicación cuyas funcionalidades ya se encuentran distribuidas en múltiples organismos. Aquí también aplica el concepto de alinear las funcionalidades con las competencias propias de cada organismo. Las funcionalidades troncales deben ser usadas por todos y no estar implementada de manera semejante en varios sistemas. Las funciones particulares deben ser fácilmente agregables a la solución.


En la administración pública se trató siempre de crear sistemas centrales o troncales como: gestión financiera y contable, compras y suministros etc., para que fueran utilizados en todos los organismos. Estos sistemas terminaron resultando rígidos para muchas administraciones, lo que dio lugar y argumento para la aparición de múltiples de sistemas aislados donde se superponen o solapan dichas funcionalidades.


¿Cuál es el verdadero problema?:


 Algunos organismos de control o rectores en determinada materia buscan uniformar los procedimientos funcionales de cómo se deben hacer las cosas, si bien es un principio aparentemente básico de orden, ocurre que al no atender adecuadamente la diversidad terminan fracasando. Su uso solo es posible mediante un modelo de imposición por la fuerza de la ley, pero los resultados distan mucho de mostrar un adecuado aprovechamiento de la información y la tecnología utilizada.


 Otros tratan de flexibilizar sus sistemas centrales complejizándolos y agregándoles excepciones hasta el punto de desvirtuar en parte la razón de su función y a un costo que se incrementa hasta hacer imposible continuar con él.


Como ya se comento al analizar las estructuras de poder, aquí debemos volver a aplicar el modelo de equilibrio entre **centralización ** y **descentralización ** por el criterio de “alto valor” definido por Carlos Matus[6].


Si analizamos los argumentos esgrimidos para no usar el sistema central y desarrollar otro particular notaremos que se basan en:


  * El proceso presenta demasiada burocracia para mi caso particular.

  * Los tiempos que insume un determinado proceso no son compatibles con las necesidades de mi caso particular.

  * Hay un montón de necesidades que no son contempladas en el sistema central y no puedo obligar al usuario a saltar de un sistema a otro permanentemente.

  *  . . .


Una mirada más profunda nos muestra que:


  * La gran mayoría de los argumentos se refieren a problemas en los procesos.

  * Casi nunca hay discusión sobre los registros o las transacciones individuales.

  * Como los procesos son transversales, utilizan funcionalidades de múltiples sistemas tanto de los troncales o como de desarrollos particulares.


La causa raíz de estas complicaciones están dadas por la imposibilidad (es mental, no tecnológica) de que una determinada transacción de un sistema central sea utilizada en otro sistema en forma transparente.


Esto requiere que las “transacciones centrales” deban ser provistas como web services para que otro desarrollador complete la **‘ultima milla’**uniformando su uso con otras funcionalidades particulares de su caso.


Es así que el objetivo del sistema central se cumple


La fase 3 de Integrabilidad resuelve este tipo de problemas.

\\ 
===== Evolución de la tecnología informática=====

La evolución del paradigma de integración puede ser representada por el siguiente cuadro comparativo del mundo físico y el mundo digital creado por Ken Orr.

{{ :wiki:evolucion.jpg?nolink&300 |}}

El concepto de “sistema integrado” nos puede llevar a crear sistemas cada vez más abarcativos, que pretenden ser “únicos”, pero que al mismo tiempo están limitados por las competencias propias del organismo, áreas o empresa para la cual fueron creados. Son sistemas que se auto-sirven, pero al mismo tiempo se aíslan de los sistemas de otros organismos o empresas, generando las famosas islas informáticas.


En un modelo de servicios, hacia donde convergen los nuevos desarrollos, el concepto de **sistema integrado**, evoluciona al de **sistema integrable**. Integrable significa ser capaz de convivir (interactuar) con otros sistemas que pueden ser heterogéneos en cuanto a tecnologías y/o tipos de software (libre, propietario, SaaS). En este nuevo paradigma la capacidad de comunicación con los otros a través de estándares es lo importante.


Al igual que en el mundo real, las metodologías y técnicas que utiliza un arquitecto para la construcción de una casa, no alcanzan para poder construir una ciudad, se necesita atender temas más estructurales, urbanísticos y de servicios básicos.


La “ciudad digital” requiere de una Arquitectura Orientada a los Servicios (SOA) para dar soporte a todos los componentes funcionales, tanto de software existentes, como a los futuros por desarrollar.


El modelo de sistemas integrables, aunque más no sea como visión, busca replicar el concepto de “plug & play” que se está desarrollando en el mundo del hardware.


Integrado e Integrable son dos caras de la misma moneda

{{ :wiki:integradovsintegrable.jpg?nolink&300 |}}
\\ 
Una arquitectura de soluciones Integrables tiene un alto valor para las organizaciones, permitiéndoles:


1) Minimizar los tiempos de puesta en marcha.


2) Contar con soluciones flexibles ante cambios en sus procesos.


3) Lograr soportar sin límites la diversidad de sus propios casos. (última milla)


4) Lograr importantes mejoras en la calidad de los datos y la información.


5) Preservar al máximo toda la inversión en sistemas ya realizadas.


La arquitectura necesaria para lograr este perfil de prestaciones se viene delineando con la evolución del software, paradójicamente para poder crecer en complejidad y funcionalidad los sistemas vienen sufriendo una serie de fracturas, fragmentándose paulatinamente cada vez más. Cada fractura representa un grado de evolución en el dominio de alguna temática en particular, lo que normalmente ocurre es que la parte fracturada se convierte en una nueva “herramienta” parametrizable que no requiere programación, algo que hasta ese momento era solo alguna funcionalidad desarrollada a medida dentro de algún sistema integrado.


Desde los programas monolíticos de hace no más de 20 años, pasando por los clientes servidores de bases de datos, los servidores de aplicaciones, los servidores web, los motores de workflow y los servicios de inteligencia de negocio, para mencionar las fracturas más significativas, la tendencia continua. En los últimos años SOA agrega una dimensión más que es la diversidad tecnológica y la diversidad de proveedores de tecnología. Todo lo que sirve puede participar de la construcción de este nuevo tipo de sistemas. Si bien los tecnólogos prefieren trabajar con uniformidad tecnológica, los administradores de las organizaciones prefieren trabajar con uniformidad en el modelo de gestión y no tener que estar saltando de sistema en sistema para poder operar.

{{ :wiki:curvaevoluciontecnologica.jpg?nolink |}}
\\ 
Si algo está claro es que estas fuerzas de fractura surgen casi naturalmente por el nivel de complejidad alcanzado por la informatización de la realidad y no de los planes estratégicos de las empresas de software, los intentos por contradecir estas fuerzas evolutivas solo logran la desaparición de muchas empresas o proyectos de software.


Otro eje no menos importante a considerar, es el aspecto temporal; la velocidad de los ciclos tecnológicos frente a los ciclos de desarrollo, mientras los primeros son cada vez más rápidos, los segundos se vuelven más lentos por el nivel de complejidad alcanzado. Esto hace que la convivencia de desarrollos heterogéneos sea una necesidad incuestionable.


En la actualidad una solución INTEGRABLE debe soportar las siguientes fracturas o capas:


1) **Capa web ** de Interfaces unificadas, simples y amigables


2) **Capa de Procesos ** totalmente flexibles y parametrizables.

 
3) **Capa de Negocios ** con componentes robustos y eficientes.


4) **Capa de Datos ** Integrables con otras aplicaciones ya existentes.

{{ :wiki:modelodecapas.jpg?nolink&300 |}}

Transformaciones requeridas y modelo de operación muti-capa desde abajo hacia arriba:


  * Los datos de todas las Fuentes Auténticas están disponibles y son consumidos por cualquiera de las capas superiores, bajo el control del Coordinador.

  * Los sistemas troncales, se transforman en proveedores de servicios, para que puedan ser utilizados por las capas superiores.

  * Los workflows coordinan las autorizaciones dinámicas que se generan entre las distintas transacciones de los sistemas troncales y los sistemas particulares.

  * La capa de presentación unifica bajo un modelo de interacción estándar el acceso a todos los procesos, sistemas y datos que requiera el ciudadano.

\\ 
Las cuatro capas se necesitan para poder atender distintas complejidades


1) **Capa web **: es una de las fronteras más dinámicas y calientes del modelo, donde las innovaciones en las interfaces de interacción con el usuario no dejan de avanzar, la clave aquí es poder cambiarla (renovarla) rápidamente sin afectar el resto de los componentes del sistema (los procesos, las funciones de negocios, las fuentes de datos).


2) **Capa de Procesos **: es la clave para lograr la flexibilidad. La capa de procesos articula las necesidades de la organización, con las funcionalidades de los sistemas de registración y calculo. Los sistemas funcionales se vuelven obsoletos y fracasan por tener los procesos “hardcodeados”. Los workflows amortiguan los cambios y extienden la vida del resto de los componentes (las funciones de negocios, las fuentes de datos)


3) **Capa de Negocios **: la capa de negocios es la más “a medida” que se requiere en un proyecto. Los desarrollos requieren tiempo para poder se estabilizarlos, por lo que podemos asegurar que cuanto más viejo y utilizado es un sistema más robusto es.


4) **Capa de Datos **: esta capa tiene dos desafíos; la calidad de los datos que logra a través del uso reiterado de los mismos y la frontera de la seguridad en permanente estado de alerta.


\\ 
===== Requisitos para los nuevos sistemas =====
 
{{ :wiki:modelodecapascaracteristicas.jpg?nolink&300 |}}

Las aplicaciones y sistemas informáticos que se encuentran en desarrollo y los que se desarrollarán, deberán cumplir con los siguientes requisitos para entrar en el modelo de INTEGRABILIDAD:


• **Autenticación**: El sistemas deberá poder autenticar el ingreso de los usuarios mediante el uso de directorios LDAP.

• **Proveer Registros de Fuente Auténtica **: El sistema como fuente auténtica de determinados registros deberá proveer Web Services para que otros sistemas debidamente autorizados puedan consultarlos, (WS de consulta).


• **Consumir Registros de Fuente Auténtica **: El sistema deberá poder consumir los registros que necesite de otras fuentes autenticas.


• **Integrabilidad a nivel front-end **: Proveer Web Services donde se implementan transacciones completas para ser integradas en un front-end de otro proveedor conjuntamente con otros WS de otras aplicaciones.


• **Capas funcionales: ** El sistema deberá poder operar con capas funcionales de otros proveedores, estas capas son el Front-end, los procesos, las aplicaciones y los datos.


  * **Capa web: ** Front-end, interface con el usuario.

  * **Capa de Procesos: ** Workflow para administrar los flujos de trabajo.

  * **Capa de Negocios: ** Transacciones de las funcionalidades del sistema.
 
  * **Capa de Datos : ** Motores de base de datos y accesos a Fuentes Autenticas.


En este nivel de INTEGRABILIDAD cada proceso puede combinar y reutilizar transacciones de distintas aplicaciones las cuales son expuestas en las actividades del workflow mediante la utilización de servicios web transaccionales. El usuario opera un front-end, el que a su vez interactua con varias aplicaciones y varias bases de datos.


===== Consideraciones de la fase 3 =====


¿Porqué, aunque desarrollemos sistemas web no lograremos la ventanilla unificada?


  * Porque la ventanilla unificada requiere poder integrar varias aplicaciones de diferentes proveedores bajo una misma interface de usuario.

  * Porque en las etapas de un proceso puede ser necesario interactuar con varios organismos que tienen distintas aplicaciones.


===== Resultados de la fase 3: =====

– Opera por procesos integrando a todos los actores.

– Simplifica la vida porque todo está en un solo lugar no importa si es del ámbito público o privado.


\\ 
====== Proceso de Transformación completo ======


Ahora podemos visualizar el proceso completo:

{{ :wiki:procesocompletoenfoques.jpg?nolink |}}
===== Resultados del modelo de Integrabilidad =====


El resultado: permitir una forma segura, legal y confidencial de compartir información entre múltiples sistemas y organismos.


  * **Autenticidad: ** asegurar que los datos proviene de su correspondiente FUENTE AUTENTICA.

  * **Legalidad: ** asegurar que solo los usuarios AUTORIZADOS POR LA LEY accederán a los datos.
 
  * **Confidencialidad: ** asegurar que solo el solicitante podrá ver el contenido de los datos.
 
  * **Transparencia: ** asegurar que todos los accesos pueden ser AUDITADOS POR CADA ACTOR.
 
  * **Calidad: ** asegurar el permanente control, por uso, de la calidad los datos y por parte del que conoce su valor real.
 
  * **Disponibilidad:** asegurar que los datos residentes en la Fuente Autentica estarán disponibles al momento de ser solicitados
 
  * **Neutralidad Tecnológica:** todos los sistemas independientemente de la tecnología en que fueron construidos pueden participar del modelo.
 
 
\\ 
===== Conclusiones finales=====


==== Manejo de las Prioridades====


Aunque intuitivamente sabemos que hay cosas que hacer antes que otras, la realidad de la mayoría de los casos de implementación de proyectos de gobierno electrónico se desarrollan justamente en la secuencia inversa de lo que plantea la Iniciativa de Integrabilidad. Empezamos haciendo sistemas aislados donde lo mas importarte es la coherencia tecnología, a veces partimos de casos de uso sobre procesos que no se han rediseñado, otras tratando de imponer alguna buena práctica que fue creada para otro contexto y como estamos limitados por el alcance de un proyecto en particular, el resto de los temas como por ejemplo la interoperabilidad, los cambios de precesos, seguramente quedan para más adelante. Creo que sería realmente muy extraño si no surgieran los conocidos problemas.

Pareciera ser que hay que elegir entre dos estrategias que dependen de las prioridades, que es mas importante; la armonía en la gestión de múltiples organizaciones o la armonía tecnológica cualquiera sea ella:


  * Las fases 1,2,3 de la iniciativa de Integrabilidad nos llevarán a una razonable armonía organizacional, pero con una alta diversidad tecnológica.

  * Los esquemas normales de abordaje nos llevarán a una infraestructura tecnológica armónica, pero el modelo organizacional será heterogéneo y de compleja administración.

\\ 
==== Mantener el equilibrio ====


Por otro lado debemos mantener el equilibrio entre lo que se debe centralizar de lo que se debe distribuir. Aquí la clave es usar el concepto de ‘alto valor’. Este criterio sumado al sentido común que nos indica donde debe residir cada cosa, más por su naturaleza y dinámica de cambio que por el interés de los involucrados, nos asegura tomar buenas decisiones.


Por otro lado los s istemas troncales que por definición deben ser utilizados por casi todos los organismos, a pesar de tener fuerza de ley, ven frenado su despliegue por las características particulares de cada caso, las cuales generan, a estos sistemas, una complejidad de desarrollo de carácter exponencial, como resultado, nunca se pueden terminar.


El modelo en capas fac ilita en gran medida el cumplimiento de estas reglas de procesamiento troncal. Estas transacciones centrales por un lado deben permitir ser utilizadas por todo proceso que las requiera, y por otro deben ser utilizadas por todos los procesos que las requieran. Si los sistemas troncales son las llantas de una rueda, los procesos y la última milla son las cubiertas que hacen más suave el andar.

\\ 
==== Los nuevos nombres ====


Para facilitar la introducción de estos cambios de paradigma se plantea migrar algunos nombres y denominaciones de uso común.


**de Gobierno Electrónico a Gobierno Conectado** 


**de Integración a Integrabilidad** 


**de Ventanilla nica a Ventanilla Unificada** 


\\ 
====== Anexo: White Paper INTEGRABILIDAD ======



by Ken Orr & Gustavo Giorgetti (diciembre 2007)


**Integrabilidad ** una nueva dimensión de la calidad funcional de las aplicaciones que debe tenerse en cuenta al momento de priorizar los proyectos de desarrollo o incorporación de las mismas .


**Introducción:** 


Cuando:


  * Cientos o miles de organismos públicos tienen sistemas y aplicaciones desarrolladas durante varios años sobre distintas tecnologías y plataformas…

  * La velocidad del desarrollo de los grandes sistemas es ampliamente sobrepasada por los ciclos de avances tecnológicos, donde no hay forma de actualizarlas….

  * Los nuevos proyectos de IT que se generan están limitados a las competencias del propio organismo que lo promueve…

  * Los intentos para lograr interoperabilidad se frenan con desafíos y particularidades propias de cada caso y los casos son miles, con perspectiva a aumentar…
 

Se descarta por tecnológicamente obsoleto aquello que todavía es funcionalmente apto, en vez de buscar la manera de aprovecharlo y ponerlo a disposición de los demás organismos.


Y conociendo que en la actualidad:


  * Los estándares de los grandes modelos de e-government descansan mucho más sobre las interconexiones que sobre las plataformas, sistemas de base, lenguajes utilizados o modelos de licenciamiento de software aplicados.

  * En los foros informáticos se habla de Interoperabilidad, de Arquitectura Orientada a Servicios (SOA).

  * La interoperabilidad parte de una situación real de diversidad y trabaja para lograr que los sistemas trabajen juntos, esto esta muy bien para el pasado, pero no alcanza para el mejorar el futuro.

  * Hay gran cantidad de nuevos proyectos para la automatización de las funciones de diversos Organismos.


Se advierte un escenario es de alta complejidad, porque están en juego estructuras de poder e intereses comerciales que permanentemente dificultan y entorpecen la instrumentación de un modelo estable, auto- controlable y sustentable.


\\ 
Es claro que algo está faltando:


  * Debemos tener la posibilidad de calificar los próximos sistemas a adquirir, desarrollar o incorporar en función de una nueva métrica, la **INTEGRABILIDAD**, que no es otra cosa que la propia predisposición de un sistema para integrarse con otros de diferentes dueños, proveedores u organismos.

  * No alcanza con trabajar en Interoperabilidad es necesario poder identificar los sistemas que están predispuestos a “trabajar en equipo”, el futuro nuevo escenario así lo exige, debemos priorizar los proyectos de desarrollo también en función de esta métrica.

  * Aplicar la Integrabilidad como métrica de evaluación trae beneficios inmediatos al desarrollo de una plataforma de e- government, no solo solucionando los problemas y ciclos viciosos antes mencionados, sino generando ciclos virtuosos de oportunidades para el desarrollo y evolución, ya que liberan el potencial de la innovación focalizada a problemas determinados, justamente cuando la tecnología de las TICs están en la máxima pendiente de evolución.

  * En el mundo del Hardware, mucho más maduro que el del Software, la integrabilidad es ampliamente aplicada, vemos como innumerable cantidad de proveedores se integran en un solo equipo y su máxima expresión la encontramos en conceptos como Plug and Play. La creación de conectores estándar como el USB han permitido una explosión de nuevos periféricos disponibles para beneficio de todos los usuarios.

  * Pero en Software el tema es muy diferente, la restricción es del propio paradigma establecido, donde se confunde “integrado” con “todo del mismo proveedor” o “todo en la misma plataforma”. El problema con este paradigma radica en que muchas son las plataformas, muchos son los proveedores y no alcanza con seleccionar al aparentemente mejor, la realidad es que hay mucho hecho en la diversidad y mucho más por hacer que seguramente lo harán proveedores que hoy no existen en plataformas que aun no se han pensado…


El objetivo de este trabajo es permitir mirar desde otra óptica el problema de la integración de sistemas, podemos asegurar que si este material es realmente comprendido se llegará a la siguiente conclusión paradójica.


  * Integrado e Integrable son dos caras de la misma moneda.

  * Muchos de los sistemas considerados Integrados no son Integrables.

  * Muchos de los sistemas Integrables no son considerados Integrados.


**Definición de una nueva métrica ** 


Toda nueva dimensión requiere definir una métrica de aplicación general que permita determinar puntos de comparación estables o invariantes que la hagan válida para el universo de aplicación y el rango temporal de vigencia.

\\ 
===== Determinación de los componentes claves del modelo:=====


En los años 1970’s Jean Dominique Warnier//[1]// definió un modelo lógico de base de datos para organizar los registros que genera una relación “cliente – proveedor” de una organización.


La relación cliente- proveedor sigue siendo la misma que en aquel momento y si bien el planteo original estaba pensado en una empresa, un simple cambio en el nombre de los actores (ciudadano / cliente y Estado / Empresa) lo permite aplicar a un modelo de relación entre el Estado y el ciudadano.

{{ :wiki:componentesegov.jpg?nolink |}}

//[1] (J.D .Warnier, Práctica de la Contrucción de un Conjunto de Datos – Guía L.C.S. editores técnicos asociados s.a. 1977)//

\\ 
Vamos a introducir una clasificación simbólica del tipo de Componentes que esquematizan el modelo:


  * **Componentes Clase A **: los que sirven para identificar a todos los **actores ** del modelo. Por ejemplo; los ciudadanos, las empresas, los organismos del estado, etc.
 
  * **Componentes Clase B **: los que identifican los **productos ** o servicios que se transfieren entre los actores y son el motivo de la relación. Son los objetos de intercambio. Por ejemplo; Certificado Libre Deuda, Licencia Comercial, Certificados de Inscripción, etc.

  * **Componentes Clase C **: los que identifican los pasos del trámite, serie de actividades o transacciones que hacen posible que el intercambio entre los actores se concrete. En el Estado estas acciones están regidas por leyes o normativas que pueden ser auditadas.


Este modelo tiene la suficiente generalidad como para poder representar cualquier relación de un ciudadano con un organismo estatal.


Otro concepto que introdujo J.D.Warnier es que dada la existencia de múltiples casos del modelo anterior, se terminan generando múltiples relaciones entre las bases de datos de cliente y proveedores (cada elemento C1,C2..Cn..P1,P2..Pn del gráfico siguiente representa un nuevo caso de una base de datos lógica cliente-proveedor).

{{ :wiki:relacionesclientesproveedores.jpg?nolink&300 |}}

J .D.Warnier planteó la necesidad de simplificar las múltiples relaciones bilaterales entre clientes y proveedores que generan múltiples relaciones entre las distintas bases de datos, por relaciones multilaterales que simplifican y hacen viable el modelo, introduciendo el concepto de una entidad de vinculación, centralización y administración del flujo de información.

{{ :wiki:relacionesclientesproveedorescoordinador.jpg?nolink&300 |}}
\\ 
===== El comercio globalizado=====


Por otra parte, y sin evidencia registrada de haberse tenido en cuenta los trabajos que J.D. Warnier de los 70’s , el mundo comercial en su proceso de globalización guiado en Europa por la European Article Number (EAN) y por otra parte en Estados Unidos por la Uniform Commercial Code (UCC), organizaciones que terminaron confluyendo y fusionándose en la Global Standard conocida como (GS1), llegaron a las mismas conclusiones estructurales en el modelo que se utiliza hoy en día para poder soportar todo el comercio global y su logística, o sea las mismas clases de registro A, B, y C.

{{ :wiki:componentesmodelocomercialglobal.jpg?nolink |}}
\\ 
La organización GS1 materializa la implementación de los acuerdos multilaterales del modelo de J.D.Warnier administrando los Componentes Clase A, ya que todos los actores deben estar registrados unívocamente a nivel global con **Componentes Clase A = GLN**. Por otra parte todos los productos deben estar definidos por un **GTIN = Componentes Clase B**, donde se reservan rangos de códigos de identificación de productos que están subordinados a cada GLN y finalmente los envíos logísticos o mensajes, **Componentes Clase C = SSCC ** que identifica unívocamente a cada paquete o palet de envío y cuya administración corre por entera cuenta de los actores involucrados en la cadena de valor.


===== Buenas Prácticas de e-government =====


En Europa encontramos muchos países con complejas estructuras políticas conformadas por regiones y comunidades no siempre jerárquicamente coincidentes. El desafío es mayor si miramos a la propia Unión Europea que debe lograr integrarlos a todos en un “espacio europeo común”.
Si analizamos los casos considerados por la Comisión Europea como modelo de referencia y de buenas prácticas de infraestructura de e- government, podremos observar que muchos han desarrollado modelos de integración que implementan el esquema de relaciones multilaterales, entre otros podemos mencionar el **Crossroads Bank ** de Bélgica o el **X-Road ** de Estonia. El siguiente análisis lo haremos sobre el modelo X-Road dada su simpleza conceptual lo que ayudará a visualizar rápidamente los conceptos buscados sobre Integrabilidad.

{{ :wiki:xroads.jpg?nolink |}}
\\ 
Amén de los detalles técnicos de la plataforma X-Road desarrollada en Estonia para integrar y compartir datos de organismos públicos y el sector privado, podemos volver a identificar claramente las zonas, módulos o sistemas encargados de soportar a cada uno de esa clase de Componentes A, B y C.

{{ :wiki:xroadscomponentes.jpg?nolink |}}

En este caso podemos señalar que:

  * El **Componente Clase A ** que es administrado por un organismo independiente y que utilizando parte de la información del organismo “registro de personas” más los propios organismos y empresas registra todos los actores en forma única (directorio). Esto permite la correcta **autenticación ** en el sistema.

  * Cada **Componente Clase B ** tiene solo un organismo del estado responsable __del proceso de su creación y mantenimiento __ (**fuente auténtica**). Son los Componentes de los productos o servicios que requieren los ciudadanos. Hay que comprender que estos Componentes son lo que se obtienen al final de un proceso, el cual no estamos viendo en este nivel de análisis.

  * El Centro X-ROAD es el administrador del modelo multilateral de las relaciones, mantiene los **Componentes clase C**. Contiene un esquema de macro procesos y autorizaciones más los registros “log” de: Quien, Cuando y Que Componentes Clase B se usaron. Todos los organismos se alinean; autenticando con Componentes clase A y consumiendo, según las leyes, todos los Componentes clase B que necesitan para sus actividades.


Es importante remarcar que a diferencia de los Componentes clase C identificados por J.D.Warnier que es a nivel detallado de todas los mensajes entre cliente y proveedor, los Componentes clase C soportados por el modelo de Estonia son solamente los que generan relaciones cliente-proveedor entre los sistemas de los mismos organismos del estado. Entonces podemos decir que existen otros Componentes clase C correspondientes a las relaciones entre los usuarios y los procesos internos de los propios organismos. También se observa el propio centro de administración del X-Road que se encarga de materializar un modelo de servicios con relaciones multilaterales. Este rol es independiente y no puede ser ejecutado por ninguno de los otros organismos que operan en el modelo.

{{ :wiki:xroadsrelacionesmultilaterales.jpg?nolink |}}

Pero el caso de Estonia va más lejos y resuelve el problema de la calidad de los datos y la transparencia de la información al ciudadano.


===== CALIDAD DEL DATO =====


Otro de los problemas muy importantes que aquejan a los grandes sistemas de información es el de la calidad de los datos. En este punto el modelo de Estonia soluciona el problema con extrema simpleza.


Las leyes de calidad de datos de Ken Orr son:


  * **Ley #1** - “Los datos que no son usados no son correctos”

  * **Ley #2** - “La calidad de los datos depende más de su uso que de la forma de almacenarlos”

  * **Ley #3** - “La calidad de los datos no será mejor que la de los distintos usos que tenga”

  * **Ley #4** - “Los problemas de calidad de datos crecen con la edad de los sistemas”

  * **Ley #5** - “Cuando existe menos probabilidad de ocurrir un error, más traumático es cuando ello sucede”
 

Leyes de cumplimiento obligatorio para dar calidad, ningún otro artilugio tecnológico ha podido demostrar mayor eficacia y eficiencia.


Podríamos tomar como regla válida algo que dijera: Dato que no es usado por el que conoce su valor no tiene calidad y por lo tanto es erróneo.


En el caso de Estonia el 80% de los ciudadanos ha revisado **todos los datos ** (los Componentes Clase B) que el estado tiene registrados sobre él en cada uno de los sistemas de los distintos organismos (llamados fuentes auténticas). La calidad de los datos de Estonia es realmente envidiable.

\\ 
===== TRANSPARENCIA =====



La transparencia es otro aspecto clave en un modelo donde existen múltiples propietarios de diferentes conjuntos de datos. En Estonia todos los ciudadanos pueden consultar los Componentes Clase C en que se ven involucrados, pudiendo auditar así, Quién y Qué datos se están usando de él.


El tema de la calidad de datos y el de transparencia requiere disponer de la capacidad para poder integrar en un sólo front-end la información proveniente de múltiples sistemas. A este tipo de Componentes de integración “virtual” los llamaremos Componentes Clase D.

{{ :wiki:xroadscomponentestransparencia.jpg?nolink |}}
\\ 
Hace 100 años en el apogeo del desarrollo rural, era común el desarrollo autosuficiente donde integradamente se atendían todas las necesidades. Aquí el concepto es INTEGRADO, AUTOSUFICIENTE pero al mismo tiempo aISLAdo. En la actualidad el desarrollo Urbano, es totalmente dependiente de la infraestructura de servicios de todo tipo y por ello necesariamente INTEGRABLE.

{{ :wiki:evolucionmundofisico.jpg?nolink&300 |}}

En el mundo material es posible integrar productos de distintos proveedores y conectar cañerías de distintas tecnologías, viejas y nuevas para lograr que los servicios sean prestados. Lo paradójico es que el en mundo virtual donde parece que todo es posible, aplicaciones de distintos proveedores permanecen aun hoy en día aisladas y se insiste en que la única solución es volver a desarrollar todo en nuevas soluciones más integradas que no son otra cosa que islas más grandes. La otra paradoja es que si bien lo que está dentro de su alcance lo integran muy bien, lo que no cubren queda totalmente fuera de posibilidad de ser tratado e integrado.

Otro ejemplo de la falta de Integrabilidad es que tanto las capas funcionales como las bases de datos y las aplicaciones, sus Workflows e interfaces web para el usuario, sólo están siendo utilizadas dentro de cada uno de los propios productos o sistemas isla, pero poco se las aplica para, realmente, dar Integrabilidad a las aplicaciones entre sí, posibilitando un modelo de Integrabilidad en el que los productos se complementen verticalmente y compitan horizontalmente.

{{ :wiki:evolucionmundodigital.jpg?nolink |}}

Este modelo de integrabilidad le brinda al usuario un sistema como “un todo” además de otras características como la flexibilidad y robustez tan necesaria cuando de “sistemas urbanos” estamos hablando.

Este modelo de integrabilidad se puede presentar también a mayor detalle, logrando vincular 3 capas fundamentales como son los procesos, las aplicaciones y los datos.

En este nivel de integrabilidad un proceso puede combinar y reutilizar transacciones de distintas aplicaciones las cuales son expuestas en las actividades del workflow mediante la utilización de servicios web transaccionales. Es así que una actividad del proceso puede estar involucrando varias transacciones soportadas por varias aplicaciones. Estas aplicaciones estarían interactuando con una o varias bases de datos, locales o remotas.

El usuario opera un solo front-end, el que a su vez está interactuando con varias aplicaciones y varias bases de datos.

{{ :wiki:modelodecapaskenorr.jpg?nolink |}}
\\ 
**Conclusiones:**

– Los sistemas se deben alinear en lo que respecta a los Componentes Clase A, los cuales siempre deberían estar administrados en forma “centralizada” por una tercera parte o entidad independiente que cumple exclusivamente este rol. El formato más utilizado de soporte de estos Componentes Clase A es mediante Directorios LDAP (bases jerárquicas, replicables, robustas de alta disponibilidad).


– Los sistemas deben exponer los productos y servicios que brindan mediante Componentes Clase B (fuente auténtica) y consumir los Componentes Clase B de otros para evitar duplicar todo lo que sea posible los datos que no produce. Aquí no estamos analizando la calidad o eficiencia del proceso interno, sino su capacidad de integración.


– Los sistemas deben dejar rastro de los mensajes de entrada y salida fuera de sus límites para fines de control y auditoria de la operación. Estos Componentes (los de Clase C) deben ser administrados por otras terceras partes.


– Los sistemas deben integrarse en un mismo front-end (otro sistema) para presentarse de manera clara y unívoca ante los usuarios propietarios de la información Componentes Clase B y C como mínimo para su control y validación.


\\ 
===== DEFINICIÓN de INTEGRABILIDAD de un sistema: =====


**Funcionalmente: **//Capacidad para formar parte de una red de sistemas en la que cada uno es, hacia los demás, proveedor de los datos que produce (sistema de fuente auténtica) y a su vez es cliente de los demás por los datos que necesita y no produce. Todos los datos son compartidos, según la ley con los demás sistemas integrantes de la red. // 


**Técnicamente**: //Capacidad para formar parte de una red integrada por sistemas de diferentes proveedores o dueños, que operan en diferentes plataformas y están desarrollados en diferentes lenguajes, sin necesidad de cambios o adaptaciones que requieran la intervención del usuario. // 


A continuación se define la métrica para determinar el grado de INTEGRABILIDAD de un sistema, los requisitos de cada nivel incluyen el cumplimiento de todos los requisitos de los niveles anteriores:


**Nivel 1: Inicial – in/out de archivo en formato txt, grandes islas con primitivos puentes.**

  * Acceso directo a las bases de datos sin control de integridad transaccional


**Nivel 2**: **One Login – Componentes clase A** 

  * El sistema se integra al modelo de Autenticación global.

  * Mapea sus códigos Registros Clase A internos con los del Directorio de Autenticación.


**Nivel 3**: **Web Service (consulta) Producto **– **Componentes Clase B** 

  * El sistema es Service Provider de consultas sobre cualquiera de los productos o servicios prestados por la aplicación.

  * El sistema consume Componentes Clase B de las fuentes autenticas definidas, evitando la duplicación de datos no auténticos en las bases propias.

  * El sistema mantiene sus propios mecanismos de autorización.


**Nivel 4**: **Autorización Global **- **Componentes Clase C** 

  * El sistema se integra a un modelo de Autorización centralizada de relaciones multilaterales.
 

**Nivel 5**: **Web Service (transaccional) – Componentes Clase D** 

  * La aplicación ofrece WS que implementan transacciones completas para ser integradas en otro front-end conjuntamente con otros WS de otras aplicaciones.

  * Para el usuario se presentan actividades dentro de un Workflow donde utiliza de manera transparente múltiples aplicaciones.

{{ :wiki:nivelesdeintegrabilidad.jpg?nolink |}}
\\ 
====== Anexo: White Paper MABAC (Multi Level Attribute Based Access Control) ======
 
//by Gustavo Giorgetti & Claudio Vaucheret. (marzo 2008)//

===== Evolución de los Métodos de Autorización =====


**MAC ****→****DAC ****→****RBAC ****→****ABAC ****→****MABAC** 


Desde los s istemas locales con pocos usuarios a los sistemas basados en Internet donde la cantidad de usuarios crecen exponencialmente y las autorizaciones se complejizan, los modelos de autorización de usuarios han evolucionado buscando facilitar las actividades de autorización.


Se desarrolla a cont inuación una mención de las características de cada uno de estos modelos en uso hasta llegar al MABAC (Multi Level Attribute Based Access Control) introducido por PECAS como una innovación necesaria para poder implementar el modelo de INTEGRABILIDAD en infraestructuras de gobierno electrónico.


Los tipos de Control de acceso son:


**Mandatory Access Control (MAC)** 

El administrador define quien está autorizado a operar un recurso, es un modelo Centralizado, rígido y no integrable.

{{ :wiki:controlaccesomac.jpg?nolink&300 |}}
\\ 
**Discretionary Access Control (DAC) ** 

El “dueño” de cada recurso autoriza a operar a otros.
Ej. Sistema Unix. Distribuido, flexible.

{{ :wiki:controlaccesodac.jpg?nolink&300 |}}

**Separación de Deberes SSD/DSD** 

Se mantiene distribuido, pero existen políticas que previenen a un usuario de actividades incompatibles. Permite reglas por Defecto.

{{ :wiki:controlaccesossdydsd.jpg?nolink&300 |}}

**Identity Based Access Control (IBAC) ** 

Los permisos se asocian a un usuario en particular

{{ :wiki:controlaccesoibac.jpg?nolink&300 |}}

**Role Based Access Control (RBAC) ** 

Se separa la asignación,tanto a lo recursos como los usuarios se le asigna una propiedad (Ej . Rol).

{{ :wiki:controlaccesorbac.jpg?nolink&300 |}}

**Attribute Based Access Control (ABAC) ** 

Se generaliza RBAC, permitiendo asignar varias propiedades.

{{ :wiki:controlaccesoabac.jpg?nolink&300 |}}

**LRBAC/HRBAC ** 

Los valores de las propiedades pueden ser un conjunto “parcialmente ordenado”

  * Árboles,Retículos,

  * Arboles invertidos,

  * Secuencias,

  * Estructuras jerárquicas

Permite utilizar por ejemplo <= nivel1 o > director etc.

{{ :wiki:controlaccesolrbacyhrbac.jpg?nolink&300 |}}

**Multi Level Attribute Based Access Control (MABAC)**
**(PECAS) ** 

Generaliza ABAC, permitiendo agrupaciones de recursos, además de usuarios.

{{ :wiki:controlaccesomabac.jpg?nolink |}}
\\ 
**Recursos ** Una instancia de proceso puede asignar dinámicamente un recurso

{{ :wiki:controlaccesomabacrecursos.jpg?nolink |}}
\\ 
**Usuarios ** Una sesión puede asignar dinámicamente a un usuario

{{ :wiki:controlaccesomabacusuarios.jpg?nolink |}}
\\ 
**Conclusiones sobre los modelos**

  * El grado de distribución de la autorización (MAC/DAC) es independiente de las formas de agrupamiento (RBAC/ABAC/MABAC).

  * Los modelos RBAC y ABAC permiten la asignación grupal de permisos. Ej. el cambio de una propiedad en el usuario cambia automáticamente sus permisos.
 
  * Los Atributos “parcialmente ordenados” pueden modelar información organizacional de los sistemas heredados de otros análisis. (organigrama, áreas, comités, grupos, equipos)
 
  * MABAC permite asignación grupal de recursos, extendiendo las ventajas de los modelos anteriores. (paquetes informes, objetivos indicadores, ítems de menú, roles de proceso)

  * La multiplicidad de niveles permite discriminar niveles con
  * asignación dinámica y con asignación estática.

MABAC se implementa en el Servidor Coordinador del Modelo de Integrabilidad.

{{ :wiki:integrabilidadmabac.jpg?nolink |}}
\\ 
===== Multi Level Attribute Based Access Control (MABAC) =====


El modelo MABAC está preparado para atender las necesidades que demanda la administración de Autorizaciones en el mundo de los sistemas operando en Internet donde confluyen usuarios internos y
externos a la organización, en grandes cantidades y donde la autorización de los mismos está subordinada a diferentes fuentes auténticas.

{{ :wiki:inegrabilidadmabaccapas.jpg?nolink |}}
\\ 
El primer paso es separar Autenticación de Autorización, y es uno de los requisitos que debe cumplir todo sistema que pretenda operar en un modelo de Integrabilidad:

  * Integrabilidad exige que todos los sistemas se subordinen a un servidor de Autenticación externo.

{{ :wiki:integrabilidadmabacrelaciones.jpg?nolink |}} 

\\ 
===== Estructura de Usuarios (sujeto)=====


**SUJETO - ATRIBUTOS DEL USUARIO: ** el modelo MABAC utiliza distintos atributos para representar los agrupamientos más comunes que se utilizan emplean en las organizaciones:

{{ :wiki:integrabilidadmabacatributospersonas.jpg?nolink&300 |}}
\\ 
**AUTORIZACION de Usuarios EXTERNOS**

**CASO: ingreso directo de los usuarios externos al Sistema: ** 

• Para un sistema X los usuarios externos son y se agrupan según distintos criterios de pertenencia que se definen en función de uno o varios registros de fuente auténtica de otros sistemas externos u otros módulos de registración internos.

• Se debe definir el CRITERIO DE PERTENENCIA indicando la(s) fuente(s) auténtica(s) a consultar para verificar la existencia y pertenecía del usuario.

• Proceso de autorización:

  * Usuario autentica contra un LDAP de cobertura general

  * El usuario intenta utilizar una funcionalidad del sistema X

  * El protocolo de Autorización MABAC consulta mediante un WS a la fuente autentica indicada la pertenencia o no del usuario a la misma.
 
  * El modelo MABAC permite AUTORIZAR a usuarios externos mediante el uso de WS de fuente Autenticas


Todos los WS de FA utilizados para AUTORIZAR usuarios externos se ejecutan vía el servidor central de coordinación.
\\ 

**CASO: ingreso indirecto vía otro Sistema o Portal Unificador:**

• El usuario externo ingresa a un sistema Y (portal concentrador), para usar otro sistema X.

• El **sistema X autoriza al sistema externo Y** el uso de determinados recursos, mediante el uso de WS de FA en el modelo multilateral, donde publica los recursos ofrecidos.

• Proceso de autorización:

  * El usuario externo entra al sistema Y autenticando contra un LDAP de cobertura general.

  * El usuario externo intenta utilizar determinados recursos que pertenecen a un sistema X.

  * El esquema de Autorización MABAC del sistema Y valida como en el caso anterior mediante WS FA y autoriza determinados recurso al usuario.

  * El sistema Y consume WS FA necesarios para prestar los servicios solicitados.
 
\\ 
===== MABAC (Sujeto – Atributos – Recursos)=====

{{ :wiki:integrabilidadmabaccomponents.jpg?nolink |}}

A continuación puede verse como se definen los atributos del usuario que permiten representar el organigrama de puestos, Comités, Grupos, Equipos.

{{ :wiki:integrabilidadmabacatributosusuario.jpg?nolink |}}

\\ 
**Recursos de CONTROL: (canal de eventos) ** 

{{ :wiki:integrabilidadmabacatributoscontrol.jpg?nolink |}}

\\ 
**Recursos de INFORMACION: (canal de información) ** 

{{ :wiki:integrabilidadmabacatributosanalisis.jpg?nolink |}}

**Recursos de FUNCIONES: (canal de interacción) ** 

{{ :wiki:integrabilidadmabacatributosfunciones.jpg?nolink |}}
\\ 
**Recursos de PROCESOS: (canal de procesos) ** 

{{ :wiki:integrabilidadmabacatributosprocesos.jpg?nolink |}}

En resumen el modelo MABAC está diseñado para soportar la AUTORIZACIÓN de USUARIOS, con los atributos propios de las organizaciones, con respecto a RECURSOS de información, cubriendo los distintos perfiles funcionales que brindan los sistemas informáticos.

De esta forma se instrumenta una mecánica simple, dinámica y eficaz que permite brindar los servicios de autorización a múltiples sistemas que operen dentro del modelo de Integrabilidad.

\\ 
====== Anexo: Servicios de Autenticación - LDAP ======


Uno de los actores claves del Modelo de Integrabilidad es el Servidor de Autenticación, esta implementado mediante un sistema que utiliza:

  * Servicios LDAP (Lightweight Directory Access Protocol), Protocolo Ligero de Acceso a Directorios, donde se mantienen los datos mínimos necesarios de todos los usuarioS que operan con el modelo. Por ej: nombre, password, certificado público digital, n° de celular (para 2 factores) etc.

  * Servicios de generación de Tickes del usuario que son utilizados en el protocolo de comunicación entre los servidores (actores).

{{ :wiki:autenticacionldap.jpg?nolink |}}

La seguridad de acceso del Modelo de Integrabilidad sigue atentamente las tendencias en materia de seguridad que utilizan las entidades bancarias. Estas instituciones financieras basan su estratégica
de seguridad sobre tres pilares claves:

  * 1. Autenticación de usuarios por dos factores.

  * 2. Autorización de transacciones.

  * 3. Monitoreo de actividades basadas en el riesgo.


En el modelo de Integrabilidad esto se aplica así:

1. **Autenticación de usuarios por dos factores:** se explica a continuación.

2. **Autorización de transacciones:** puede verse en el Anexo: Ley de Habeas Data y es utilizado para “prestar consentimiento” por parte de la persona involucrada.

3. **Monitoreo de actividades basadas en el riesgo:** Un sistemas de alertas puede ser parametrizado para distintas situaciones sospechosas. Ver Monitoreo de Servicios en el manual del Administrador.

Existen distintas implementaciones de Autenticación multifactor actualmente en uso.


Una lista parcial por ejemplo:

{{ :wiki:autenticacionmultifactor.jpg?nolink |}}
\\ 
La utilización de estos mecanismos multifactor agregan complicaciones y molestias en la operación y deben ser analizadas tanto desde el punto de vista de la seguridad como desde la usabilidad.

Por ejemplo: En Home Banking, usar dos factores para todo tipo de operaciones puede no ser lo adecuado. Un modelo equilibrado sería el siguiente: para consultar el salgo de una cuenta bancaria un factor es
suficiente, pero para realizar una transferencia se requiere aplicar el segundo factor.


La elección de los mecanismos de autenticación multi-factor debe considerar las necesidades de **//seguridad // **y **//usabilidad // **. 


\\ 
===== Autenticación de usuarios por dos factores (web sites) =====


En el modelo de Integrabilidad la Autenticación del usuario operador se puede realizar por dos factores y mediante el esquema (OOB) Out Of Band, que al operar con una banda totalmente independiente logra eliminar el ataque conocido como “man in the middle”.

**Autenticación por dos factores:**

1. algo que sé = **password**

2. algo que tengo = **celular**

{{ :wiki:autenticacionoob.jpg?nolink&300 |}}
\\ 
===== Flexibilidad entre la seguridad y la usabilidad =====


Dado el enorme espectro de transacciones que debe soportar el modelo de Integrabilidad se permite operar desde:

  * Punto de vista del Usuario: el usuario decide si utiliza 1 o 2 factores.

  * Punto de vista del Servicio: el coordinador define si el servicio requiere 1 o 2 factores.

La combinación dinámica de ambas perspectivas genera la flexibilidad necesaria.

{{ :wiki:autenticaciondecisionusuario.jpg?nolink |}}
\\ 
===== Autenticación del usuario por dos factores (Servicios SMS) =====


Con el canal de mensajes SMS se puede aplicar el modelo de dos factores:


**Autenticación por dos factores:**

1. algo que sé = **password**

2. algo que tengo = **celular**

{{ :wiki:autenticacionsms.jpg?nolink&300 |}}
\\ 
Autorización del usuario operador (Servicios SMS)

{{ :wiki:autenticacionsmsautorizacion.jpg?nolink&300 |}}
\\ 
Flexibilidad entre seguridad y usabilidad

{{ :wiki:autenticacionsmsusuarioservicio.jpg?nolink |}}
\\ 
 
====== Anexo: Soporte a la Ley 25.326 - Habeas Data ======


El cumplimiento de la ley 25.326 de Protección de Datos Personales es uno de los requisitos legales más importantes que busca soportar el Modelo de Integrabilidad.

Las características básicas del modelo permiten dar soporte a muchas de las obligaciones que plantea la Ley de Habeas Data, a continuación se enumeran las características y los artículos de la Ley que sustentan.

**Datos personales en la fuente:** La arquitectura no requiere de bases de datos concentradoras o de duplicación de registros. Los únicos registros que se transfieren por el modelo de Integrabilidad son los provistos por las Fuentes Auténticas que los mantienen por sus propias competencias legales. Por otra parte los actores Autenticador y Coordinador están tecnológicamente impedidos de conocer el valor del dato transferido, esto asegura el cumplimiento del ARTICULO 3.- (//Archivos de datos - Licitud//) y el ARTICULO 7.- (//Categoría de datos//). Esto no exime a los organismos que actúan como Fuentes Autenticas de realizar el registro de sus bancos de datos, para cumplir con el ARTICULO 21.- (//Registro de archivos de datos. Inscripción//), el ARTICULO 22.- (//Archivos, registros o bancos de datos públicos//), el ARTICULO 23.- (//Supuestos especiales//) y el ARTICULO 24.- (//Archivos, registros o bancos de datos privados//).

**Calidad de datos por uso:** Cuando el dato tiende a no estar duplicado, su reutilización para distintos fines se incrementa, esto asegura que con el solo hecho de permitir mecanismos estándar y gratuitos de feedback hacia las Fuentes Auténticas, éstas podrán ajustarlos, (errores detectados) o determinar otras acciones en función de sus implicancias.Entonces la calidad del dato aumentará continuamente con su uso,
apoyándose el cumplimiento del ARTICULO 4.- (//Calidad de los datos//),
del ARTICULO 16.- (//Derecho de rectificación, actualización o supresión//),
del ARTICULO 17.- (//Excepciones//) y del ARTICULO 19.- (//Gratuidad//).

**Datos personales Firmados y Encriptados:** Los datos son firmados digitalmente por la Fuente Auténtica y encriptados para el usuario solicitante, todo esto utilizando la infraestructura de PKI, dotando de
total autenticidad al dato. Esto permite dar cumplimiento al ARTICULO 9.- (//Seguridad de los datos//).

**Acceso unificado a datos personales:** La construcción de un portal de ciudadano que unifique en un solo punto toda la información que existe sobre él es posible gracias al modelo de Integrabilidad, dando
cumplimiento del ARTICULO 13.- (//Derecho de Información//) y ARTICULO 14.- (//Derecho de acceso//). ARTICULO 15.- (//Contenido de la información//).

**Coordinador multilateral implementador de la ley:** El Coordinador materializa la ley en cuanto a las autorizaciones. Solo usuarios que legalmente requieran acceder a cierta información, la recibirán de las
Fuentes Auténticas. Las distintas normas legales son implementables dentro del modelo MABAC del Coordinador. Esto asegura el cumplimiento de los artículos de la ley que establecen restricciones o
derechos de acceso como el ARTICULO 8.- (//Datos relativos a la salud//), el ARTICULO 18.- (//Comisiones legislativas//), el ARTICULO 25.- (//Prestación de servicios informatizados de datos personales//).

Hay dos artículos que requieren especial tratamiento para ser atendidos y requieren el trabajo interrelacionado de al menos tres actores del Modelo de Integrabilidad; Servidor Autenticador; Servidor Coordinador y la Persona Involucrada.

{{ :wiki:leycoordinadormultilateral.jpg?nolink |}}

Estos artículos especiales son:

**//Artículo 5° - Consentimiento // ** 

{{ :wiki:leyart5consentimiento.jpg?nolink&300 |}}

**//Artículo 11° - Cesión // ** 

{{ :wiki:leyart11cesion.jpg?nolink&300 |}}
\\ 
Como puede observarse de la letra de la ley, se requiere de una acción (dar consentimiento registrable) por parte de la persona involucrada, como hecho previo a la exposición de los datos.

Por ejemplo si una persona está realizando un trámite en la mesa de entradas de una institución privada, la consulta on-line sobre el cumplimiento de requisitos sobre múltiples Fuentes Auténticas no debería realizarse sin el consentimiento de dicha persona. Esto podría generar la necesidad de **firmar algún papel**, cosa que realmente se quiere evitar.

Repasemos por un momento el modelo de autenticación por 2 factores

{{ :wiki:autenticacionoobcompleta.jpg?nolink&300 |}}

El operador del sistema (mesa de entrada) realizó esta operación de autenticación sobre el Servidor Autenticador, y esto le da derechos para acceder a determinados recursos de información entre los que se
encuentran los requisitos del trámite. Si estos recursos están definidos (parametrizados) como recursos que requieren del consentimiento del involucrado (están condicionados a su consentimiento), entonces en
ese preciso momento (cuando se los está solicitando) el Servidor Coordinador utilizando el mecanismo de 2 factores, enviará un mensaje al celular del involucrado para:

  * informarle quien (operador) y que recursos (registros de FA) pretende acceder.

  * solicitarle el consentimiento para permitir el acceso o su denegación.

  * registrar en los registros de auditoría con sellado de tiempo, **Trusted timestamping**, la decisión sobre el consentimiento solicitado.

{{ :wiki:autorizacionoobconsentimiento.jpg?nolink&300 |}}
\\ 
De esta manera el servidor coordinador se convierte en la fuente auténtica del registro de los consentimientos otorgados por las personas para el acceso a su información personal.
\\ 
====== Anexo: Autenticación JOSSO & Coordinación MABAC ======
 

Para mostrar la flexibilidad y facilidad de la tecnología SOA para operar independientemente de las plataformas tecnológicas, se implementaron extensiones en el servidor Coordinador para poder
operar en una instalación que opera con **(JOSSO) Java Open Single Sign-On**, como servidor de Autenticación.
El (SSO) Single sign-on es un mecanismo de autenticación que habilita al usuario para acceder a múltiples aplicaciones web con una sola instancia de identificación. Aplicando una técnica de intercepción de
los intentos de login de a las aplicaciones invocadas.

El diagrama muestra el dialogo entre los actores utilizando el Servidor
Coordinador MABAC.

{{ :wiki:autenticacionjossoymabac.jpg?nolink |}}
\\ 
====== Referencias ======



[1]. Ken Orr & Gustavo Giorgetti: **INTEGRABILIDAD**. White Paper, THINKNET, Diciembre 2007


[2]. Gustavo Giorgetti & Claudio Vaucheret: **MBAC (Multi level attribute Based Access Control)**. White Paper, THINKNET, march 2008.


[3]. Claudio Vaucheret & Jorge Sznek: **Arquitectura para la Integrabilidad de Servicios sobre el protocolo HTTP basado en PKI**, Departamento de Ciencias de la Computación de la Facultad de Economía y Administración de la Universidad Nacional del Comahue. Noviembre 2008.


[4]. Uuno Vallner: **IT Interoperability Framework (Estonia)**, Ministry of Economic Affairs and Communications, September 2007.


[5]. Carlos Altschul, Roberto Carbonel, **TRANSFORMANDO** –, Edudeba 2003.


[6]. Carlos Matus, **LOS TRES CINTURONES DEL GOBIERNO** -: Editorial:Universidad Nacional De La Matanza, 2007.


[7] Chris Anderson, **THE LONG TAIL** -, 2006.


[8] Riaz Khadem, **ALINEAMIENTO TOTAL** -, Editorial Norma.


[9]. Robert Simons, **PALANCAS DE CONTROL**.


[10].Gustavo Giorgetti, **CALIDAD TOTAL EN EL DESARROLLO SISTÉMICO
DE LA ORGANIZACIÓN**, 1993.