Propuesta de arquitectura para los gobiernos municipales electrónicos. Yves Chaix. (Borrador) Noviembre del 2008

Propuesta de arquitectura para los gobiernos municipales electrónicos Yves Chaix (Borrador) Noviembre del 2008 1. INTRODUCCIÓN...2 2. EL ALCANCE Y EL ÁMBITO DEL PROBLEMA...3 2.1 EL ÁMBITO DE LOS GOBIERNOS MUNICIPALES...3 2.2 EL ÁMBITO DEL GOBIERNO ELECTRÓNICO...4 2.3 LA NECESIDAD DE POLÍTICA INFORMÁTICA...5 3. METODOLOGÍAS PARA EL DESARROLLO DE UNA PROPUESTA DE ARQUITECTURA...5 3.1 COMO DISEÑAR LA ARQUITECTURA?...6 3.1.1 Perspectiva de los problemas a solucionar- solución institucional-solución TI...6 3.1.2 Perspectiva: demanda<=>oferta de servicios...7 3.1.3 Perspectiva: ciclo de desarrollo...7 3.1.4 Perspectiva "análisis orientado a servicios...7 4. SOA, ARQUITECTURA ORIENTADA A SERVICIOS...8 4.1 PRINCIPIOS DE MODELACIÓN DE UNA ARQUITECTURA CONCEPTUAL ORIENTADA A SERVICIOS...10 4.2 DEFINICIONES SOA...11 4.3 DISEÑO Y DESARROLLO DE SOA...11 4.4 LENGUAJES DE ALTO NIVEL...12 4.5 DIFERENCIAS CON OTRAS ARQUITECTURAS...12 4.6 BENEFICIOS...12 5. CONSTRUCCIÓN DE UNA ARQUITECTURA INSTITUCIONAL BASE...12 5.1 LOS PROBLEMAS QUE PRETENDEN SOLUCIONAR LOS GOBIERNOS MUNICIPALES...12 5.2 LOS SISTEMAS Y ARQUITECTURAS TECNOLÓGICAS ACTUALES...13 5.3 EL PARADIGMA DE LOS SERVICIOS DEL GOBIERNO MUNICIPAL ELECTRÓNICO...13 5.3.1 Aspectos arquitectónicos...13 5.3.2 Servicios institucionales...14 5.4 IDENTIFICACIÓN DE REQUERIMIENTOS ORGANIZACIONALES...16 5.4.1 La autonomía municipal y la estrategia digital...16 5.4.2 Rastreabilidad de las decisiones tomadas y del manejo de los datos institucionales...17 5.4.3 Conformación con los meta modelos propuestos en el marco conceptual del gobierno electrónico...17 5.4.4 Requerimiento del uso de servicios web para la comunicación entre servicios (comunes reutilizables),...17 5.4.5 Apoyo al desarrollo económico TIC del departamento...18 5.4.6 Entorno del mantenimiento futuro de los componentes...19 5.5 LA ARQUITECTURA INSTITUCIONAL META...19 5.5.1 Arquitectura de datos...19 5.5.2 Arquitectura de aplicaciones...21 5.5.3 Las interacciones entre componentes reutilizables...24 5.5.4 El impacto de los componentes reutilizables sobre las aplicaciones locales...26 5.5.5 Necesidades de replicación entre bases de datos como tecnología para propagar los cambios en los datos generados localmente hacia todo el territorio...28 5.5.6 Arquitectura tecnológica...29 5.6 ARQUITECTURA LOCAL DE LOS SISTEMAS...30 5.6.1 El modelo general del conector común en el ámbito departamental...31 5.6.2 El modelo de los servicios municipales...31

5.6.3 La interacción entre los diferentes servicios...34 5.6.4 La matriz de conexión entre las aplicaciones...38 5.7 ADMINISTRADOR DE BASE DE DATOS...43 5.8 PLATAFORMA DE DESARROLLO...43 5.8.1 Uso de motor de flujo de trabajo de estado para la orquestación de las actividades y el manejo de los procesos tramitales de las instituciones...44 5.9 LA ORGANIZACIÓN TI PARA EL GOBIERNO MUNICIPAL ELECTRÓNICO...45 6. PLAN DE TRANSICIÓN...45 6.1 SECUENCIA DE DESARROLLO DE APLICACIONES...45 6.2 INSTRUMENTOS DE LA ARQUITECTURA INSTITUCIONAL...45 6.2.1 Planeación y control de la inversión...45 6.2.2 Modelo técnico de referencia (MTR)...45 6.3 ALTERNATIVAS TECNOLÓGICAS Y EVALUACIÓN TÉCNICA...46 6.3.1 Definición del entorno de operación de las aplicaciones...46 6.4 LA UBICACIÓN FÍSICA PROPUESTA PARA LOS SISTEMAS...47 6.4.1 Ubicación de los componentes reutilizables...49 6.4.2 Ubicación de las aplicaciones...50 6.5 COMPRAR? REUSAR? DESARROLLAR?...50 1. Introducción 1. El reto presentado por el proyecto de gobierno municipal electrónico de Estelí de TELCOR-UCP-Banco Mundial, combinado con los retos paralelos de otros proyectos de gobierno municipal electrónico, y, algún día, el del gobierno electrónico central, nos obliga a considerar un marco formal, tanto para la definición del problema como para la presentación de posibles soluciones. 2. El problema se podría circunscribir al mero proyecto de Estelí, considerado como un proyecto aislado, pero entonces se negaría la capacidad potencial del mismo proyecto de convertirse en un modelo replicable para todas las alcaldías y/o departamentos del país, la cual además ha sido contemplada en los términos de referencia como uno de los objetivos primordiales del proyecto, particularmente cuando hay otras iniciativas que pueden discrepar con la concepción preliminar que se tiene de la posible arquitectura del futuro gobierno municipal electrónico. 3. Los municipios y departamentos tienen desde mucho tiempo ya, la necesidad de un modelo que pueda guiar y apoyar el desarrollo de un gobierno municipal electrónico en el entorno nacional, que sea replicable y sostenible a largo plazo y que resulte alineado con los requerimientos de servicios TIC, pero también con los requerimientos de organización de los mismos gobiernos locales y con su arquitectura institucional. 4. Tal vez el problema principal es que no existe un planteamiento documentado de las necesidades de servicios IT, no existen políticas ni marcos conceptuales, existen pocas contrapartes con las cuales debatir de los temas, ni están claramente identificadas ni organizadas, o no tienen capacidad de convocatoria ni, en la mayoría de los casos, el poder político para hacer efectivas sus recomendaciones. 5. Entonces, es una realidad inevitable que cualquier conclusión a la cual puedan llegar los actores interesados, sólo se puede imponer por su justeza y por la calidad del proceso de reflexión por medio del cual se llegó a la misma. 6. Esto obliga a la adopción de una metodología de trabajo estricta, documentada, que garantice la rastreabilidad en el proceso de reflexión. Además, el mismo proceso de reflexión y las conclusiones que resulten deben ser sometidos a la evaluación seria y objetiva por pares con credenciales suficientes para suscitar el respecto de la mayoría de los interesados futuros.

2. El alcance y el ámbito del problema 2.1 El ámbito de los gobiernos municipales 7. No se conoce en la actualidad un documento formal que proponga una arquitectura para el gobierno municipal electrónico, aunque si se analizan las diferentes iniciativas históricas y actuales, resulta obvio que existen muchas opiniones, a veces hasta contradictorias. En todos los casos, el evento reciente organizado por DGTEC/CONICYT para evaluar arquitecturas de gobierno municipal electrónico dejó en evidencia que existe un serio problema en este ámbito. 8. Por un lado, el proyecto "TIC municipal" 1 en curso de implementación en los departamentos de Boaco, Chontales y la Región Autónoma del Atlántico Sur, propone la selección, desde el Internet, de un sistema administrativo financiero por seleccionarse desde varios centenares o miles de productos similares disponibles como software libre, como una manera de implementar el reuso de software. 9. El proyecto TELCOR-Banco Mundial para Estelí, por su parte, propone los primeros esbozos de una arquitectura para el gobierno electrónico municipal, basado en la arquitectura SOA ubicada más bien en el ámbito departamental y propone también el desarrollo de varios sistemas para conformar el gobierno municipal electrónico, incluyendo el desarrollo posible de un sistema administrativo financiero. Para este proyecto, el reuso de software se basa en la interoperabilidad y el desarrollo de componentes reutilizables diseñados para el entorno nacional, propone la instalación de una VPN en el entorno departamental, hace un fuerte uso del Internet, e impulsa la incorporación del sector TIC de las MIPYME en el programa de implementación. 10. Por su parte, el INIFOM presenta un plan de implementación del sistema administrativo financiero en base a un prototipo desarrollados con financiamiento de la GTZ para el municipio de San Juan del Sur, para ser instalado en los 153 municipios del país. No se sabe mucho sobre este sistema. 11. En fin, el mismo MAGFOR ofrece gratuitamente también un sistema administrativo financiero. No se tienen detalles sobre su plataforma de desarrollo y su funcionalidad. 12. Concretamente, la multiplicación actual de propuestas sólo perpetúa algo que se inició a partir de los años 1990: iniciativas disgregadas, generalmente arraigadas en proyectos de cooperación con recursos económicos cuantiosos, donde las acciones han sustituido con frecuencia a la reflexión previa, o sea programas que daban la primacía de la ejecución de proyectos sobre la elaboración e implementación de políticas 2. 13. Creemos también que una importante laguna de los esfuerzos históricos de desarrollo de sistemas de información para los gobiernos municipales se debe a una falta de visión holística de las interacciones entre los gobiernos municipales y las instituciones del estado desconcentradas incluyendo la carencia de actividades de planificación territorial por un lado, y de las necesidades de integración de las acciones de desarrollo económico y humano de los propios municipios lo cual, si bien no es necesariamente un problema meramente informático, se traduce por requerimientos parciales, incompletos, disgregados, a veces contradictorios y duplicados. 14. Es innegable que consideraciones de orden político pueden afectar la capacidad de los municipios de colaborar entre sí, sin embargo, consideramos que la mayoría de los problemas presentados pueden ser resueltos bajo enfoques técnicos, relativamente libres de interferencia política, y que a su vez, la solución técnica de problemas técnicos coadyuvará a facilitar la colaboración proactiva entre los municipios. De hecho, en su mayor parte, los problemas técnicos son ignorados por los cuadros políticos superiores, los cuales optan generalmente por delegar a los cuadros técnicos intermedios la responsabilidad de buscar soluciones técnicas. 1 MHCP-Cooperación Finlandesa-AIN 2 Quizás sea conveniente analizar el historial de los proyectos, y no solamente de los proyectos informáticos, y preguntarse hasta qué punto esta situación refleja a la preponderancia, para los proyectos, de los indicadores de desempeño (o sea la eficiencia de los mecanismo de desembolso) sobre los indicadores de resultados y de impacto.

15. Ahora, se presenta por primera vez, la oportunidad de proponer una alternativa en la forma de un documento conceptual que sirva de guía a todas las futuras iniciativas de desarrollo de proyectos informáticos o de iniciativas informáticas en el ámbito de los gobiernos municipales electrónicos. 2.2 El ámbito del gobierno electrónico 16. La propuesta de un marco conceptual para el gobierno electrónico elaborada entre los años 2003 y 2005 3 ha tenido un éxito limitado, a pesar de haber recibido cierto impulso en el ámbito del gobierno central, por medio de la Comisión de gobierno electrónico 4, pero tampoco puede considerarse como un fracaso: ha tenido una difusión nacional superior a la casi totalidad de otros proyectos o estudios similares, solamente superada por la difusión del Plan Nacional de Desarrollo, Demostró su fortaleza al servir de guía para el desarrollo de por lo menos tres proyectos bajo los lineamientos planteados en el marco conceptual, con la existencia a la fecha de más de 10 componentes reutilizables, demostró su validez en cuanto a sus principios básicos (en particular, la interoperabilidad) que han resultado ser adoptados también por el libro blanco sobre gobierno electrónico de ealc2007 de la CEPAD. Esta siendo retomado por la DGTEC, en el marco de su elaboración de políticas y normas tecnológicas para todo el Estado. 17. Considerando la carencia total en el gobierno central de aval de alto nivel y de apoyo al gobierno electrónico, no deja de ser alentadora la difusión espontánea que ha tenido el marco conceptual entre una parte de los profesionales de la informática nacional, y en particular entre los cuadros intermedios del gobierno. 18. El marco conceptual del gobierno electrónico establece una serie de lineamientos y principios que son todos aplicables a lo que será el marco conceptual del gobierno municipal electrónico 5, y propone, entre otros una serie de principios o de delineamientos generales : La identificación de los problemas que pretende solucionar el gobierno electrónico y la rastreabilidad entre los problemas y las soluciones propuestas. el uso de meta modelos para modelar los procesos de la administración pública, una descripción de los conceptos de interoperabilidad dentro de la administración pública, arquitectura orientada a servicios y conceptos de componente reutilizables, un modelo alterno de implementación del gobierno electrónico para países con bajo nivel de tecnificación, una descripción del alcance de la reingeniería de la administración pública y de sus respectivos ámbitos de acción, un marco para la implementación del gobierno electrónico dentro del marco del plan nacional de desarrollo, una extensión del marco conceptual del gobierno electrónico nicaragüense a un modelo de integración de los gobiernos electrónicos regionales, etc. 19. Es por lo tanto inevitable que una propuesta de marco conceptual para el gobierno electrónico municipal deba apoyarse sobre el marco conceptual del gobierno central, aunque reconociendo algunas diferencias entre ambos. Las diferencias tienen que ver con importantes aspectos, tales como : el fuerte peso del uso de las TIC en el desarrollo económico y humano de los municipios (un tema considerado solo parcialmente bajo este enfoque por el marco conceptual del gobierno electrónico central); la contradicción potencial entre el concepto de autonomía municipal y el de desarrollo central de aplicaciones o la custodia de datos de las alcaldías en una repositorio centralizado; la necesidad de tomar en cuenta las características de la conectividad nacional, presente y futura; 3 [CHAROIZ01], Marco conceptual para un gobierno electrónico para Nicaragua, UCRESEP-TELCOR-BM, 2004. 4 GOBeNIC, www.gobenic.gob.ni 5 De hecho, la Carta Iberoamericana firmada en Chile por la mayoría de los gobiernos de América Latina y el Caribe en el 2007, no hace ninguna diferencia entre el gobierno municipal electrónico y gobierno electrónico central: los llama a ambos gobiernos electrónicos y la casi totalidad de su contenido coincide con el contenido del documento sobre principios del gobierno electrónico aprobado por la Comisión GOBeNIC en el 2006.

el nivel técnico de los recursos económicos y humanos en los municipios; la evolución de la tecnología TIC mundial, y en particular la introducción masiva de la telefonía celular en las zonas remotas, en complemento de la red telefónica tradicional. 2.3 La necesidad de política informática 20. Si bien el éxito del proyecto Estelí podría convertirlo en su propia fuente de política informática, extendible a todos los municipios del país, el conjunto de las actividades del proyecto, las reflexiones del grupo de trabajo y la propuesta de política TIC para el gobierno para el gobierno central 6, deberían representar insumos importantes para adelantar una reflexión a nivel nacional conduciendo a la elaboración de tales políticas. No es el objetivo ni el papel de este grupo de reflexión elaborar políticas informáticas gubernamentales, pero si éstas no existen, la efectividad de las recomendaciones se reduce debido a: Que no se definen los intereses vitales hacia los cuales se deben dirigir los esfuerzos en el desarrollo de la tecnología de información dentro de las instituciones (estatales). Por ello la metodología no podrá abordar las necesidades específicas que deberían figurar en una política estatal. No se establecen las acciones para regular el uso discrecional de los recursos financieros, humanos, y temporales en el desarrollo de la tecnología de información, aspectos que son de vital relevancia en países como el nuestro. Por ello la metodología no puede proponer unidades organizacionales eficaces para su aplicación. Tampoco se puede especificar con exactitud el nivel requerido de documentación que debería de proporcionar la metodología, pues está claro que mientras más documentación de soporte se elabore durante el esfuerzo metodológico, se incurre en mayores costos. No obstante, debe existir un equilibrio entre los costes de la burocracia y la rastreabilidad en el proceso que permita garantizar la rendición de cuentas. 7 3. Metodologías para el desarrollo de una propuesta de arquitectura 21. Sin una clara conciencia de que el gobierno municipal electrónico requiere, como cualquier edificio complejo, un trabajo conceptual previo de diseño arquitectural, cualquier acción futura correrá la misma suerte de los esfuerzos e iniciativas hasta la fecha. Es necesario aclarar que el término de arquitectura no describe lo que los informáticos conocen como "arquitectura de dos o tres capas", sino que el conjunto de técnicas, tecnologías, actividades, mejores prácticas, herramientas y materiales a utilizarse para construir un conjunto de soluciones coherentes, eficientes y eficaces, para solucionar los problemas de una población meta. 22. Otra definición describe la arquitectura (empresarial u organizacional) como un acercamiento a la administración de los activos de una organización para administrar sus sistemas de información y su relación con la organización y como la apoya. A la base de este acercamiento descansa un modelo arquitectural que incorpora conceptos como componentes de software, conectores, funciones, información, procesos institucionales, unidades organizativas y actores. 6 Enrique Silva e Yves Chaix, Marzo-Abril del 2007 7 página 119

3.1 Como diseñar la arquitectura? 3.1.1 Perspectiva de los problemas a solucionar- solución institucional-solución TI Ciudadano Problema del ciudadano Solución ofrecida utiliza Identificación del servicio a suministrar Catálogo de trámites y servicios Servicio municipal a ofrecer Servicio requerido requerimiento de solución institucional Actor institucional Servicio TIC a suministrar Diseño de la arquitectura institucional Servicio TIC esperado Organización de los servicios institucionales utiliza crea, modifica y borra requerimiento de solución tecnológica genera y mantiene Actor tecnológico Diseño de la arquitectura tecnológica genera y mantiene Aplicación institucional crea, modifica, actualiza y lee Servicio Común Reutilizable Registro institucional Ilustración 1: las diferentes capas de la arquitectura organizacional 23. En esencia, la arquitectura se origina en los actores que presentan problema(s) a resolver u objetivos a lograr. En el caso del gobierno municipal, el ciudadano. La Institución a su vez, asume la función de convertir los problemas en la necesidad de proveer aquellos servicios que solucionen los problemas detectados o que tienen un mandato constitucional (detección de los problemas y de las soluciones posibles). 24. A partir de los servicios identificados, el gobierno municipal identifica la organización interna (arquitectura institucional) necesaria para suministrar los servicios (funciones administrativas). 25. En fin, le corresponde a la arquitectura de sistemas diseñar los servicios IT a proveer para apoyar el suministro eficiente de los servicios TIC necesarios para la arquitectura institucional. 26. Este modelo está esencialmente orientado a la solución de problemas, tanto del ámbito del ciudadano como del ámbito de la institución, y es particularmente apto para la reingeniería institucional. Por esta razón, no se puede abordar la arquitectura de sistemas sin entender la arquitectura institucional y los servicios que ésta debe suministrar a la ciudadanía. De hecho, los sistemas administrativos financieros de las alcaldías deben ser vistos como el apoyo a los servicios de rendición de cuentas, de compras, de contratación, de planificación, etc., que a su vez dan

una respuesta a las necesidades de la población de saber en que se utiliza sus impuestos, disponer de infraestructura, y participar en la elaboración de los planes de la alcaldía. 27. En fin, un análisis más detallado de las necesidades de servicios TIC mostrará que los sistemas propios de las alcaldías no operan en el vacío, sino que se enlazan con los sistemas de los demás actores municipales y departamentales, tanto del sector privado como del sector público. 3.1.2 Perspectiva: demanda<=>oferta de servicios 28. Esta perspectiva es la del planificador, ya que establece estrategias sectoriales para cumplir con metas estratégicas, supuestamente definidas inicialmente en un Plan Nacional de Desarrollo Económico y Humano, el cual identificó en alguna fase de su elaboración los problemas individuales de la ciudadanía, y al final de la cadena, el resultado será un plan de acción que generará un conjunto de demandas para servicios digitales, suministrados a la administración municipal por medio de aplicaciones (TIC). El conjunto de la demanda de servicios digitales será retomado para elaborar a su vez una estrategia de suministro de dichos servicios, tanto a lo interno como afuera de las alcaldías. La implementación de esta estrategia conducirá idealmente a la oferta de los servicios digitales esperados para satisfacer la demanda. En este modelo, se puede perder la rastreabilidad entre las acciones estratégicas IT y las necesidades o problemas de la población a satisfacer. Este tipo de modelo es generalmente utilizado en los ejercicios de planificación de alcance territorial. El ejemplo a continuación o de la una muestra de estrategias sectoriales diseñadas en respuesta a metas estratégicas del plan nacional de desarrollo no definidas específicamente. Metas estratégicas Estrategia sectorial: la Educación Misión Visión FODA Objetivos estratégicos Plan Departamental de Desarrollo Estrategia sectorial: el Desarrollo industrial Misión Visión FODA Objetivos estratégicos Estrategia sectorial: Competitividad departamental Misión Visión FODA Objetivos estratégicos Estrategia sectorial: El sector privado Misión Visión FODA Objetivos estratégicos Plan de Acciones y Recursos Plan de Acciones y Recursos Plan de Acciones y Recursos Plan de Acciones y Recursos Plan estratégico transversal: servicios TIC Transformación de las acciones en demanda de servicios Misión Visión FODA y Objetivos estratégicos Metas estratégicas Plan de Acciones y Recursos Demanda de servicios TIC Demanda de servicios TIC Demanda de servicios TIC Oferta departamental de servicios TIC MIPYME del sector TIC del departamento Demanda de servicios TIC 3.1.3 Perspectiva: ciclo de desarrollo 29. En esta perspectiva, más orientada a los actores tecnológicos, el enfoque principal será sobre los procesos a llevar a cabo para construir las arquitecturas. En esta perspectiva, se priorizará el análisis del entorno operativo físico existente, sistemas heredados, bases de datos históricas, plataforma de desarrollo y capacidad de los recursos humanos existentes, costos de licenciamiento y de posesión, tendencias tecnológicas, ciclo de vida de los productos informáticos, etc. 30. Esta perspectiva representa el punto de vista de la implementación de los servicios. Si fue bien ejecutada, fue alimentada desde el inicio con los requerimientos de servicios TIC a suministrar, requerimientos funcionales y no funcionales, que guiarán la construcción de la arquitectura tecnológica. 3.1.4 Perspectiva "análisis orientado a servicios 31. En esta perspectiva, se considera la estructura actual de los trámites y servicios del Estado implementada a través del componente reutilizable (o SCR) "Catálogo de Trámites y Servicios" y se le somete a dos operaciones de análisis y diseño, bajo el enfoque de arquitectura orientada a servicios: se desagregan -donde posible- los trámites y servicios en elementos atómicos para identificar:

servicios institucionales de bajo nivel de granularidad que pueden ser invocados por múltiples trámites dentro de cada institución como sub procesos de los trámites y servicios definidos en el giro de la institución, reutilizables internamente y, servicios o componentes de tipo utilitarios, reutilizables afuera de la institución y candidatos a ser compartidos entre múltiples instituciones. Se agregan, donde posible, los trámites y servicios del giro institucional en meta servicios, con un alto nivel de granularidad, con la capacidad de ejecutar servicios completos y eliminando la intervención del ciudadano como mensajero involuntario para el transporte de documentos físicos entre múltiples instituciones. 32. Todas estas perspectivas corresponden específicamente a las disciplinas de análisis y diseño orientadas a servicios, y puede combinarse con las demás perspectivas presentadas anteriormente. 33. A esta altura, debe ser posible identificar algunos criterios excluyentes. Por ejemplo, se podría establecer que salen del ámbito de la metodología de definición de una arquitectura para el gobierno municipal electrónico: las aplicaciones donde la base de datos reside en la misma computadora del usuario, las aplicaciones cuyo ámbito de uso es puramente el de un municipio (las operaciones no son compartidos por ningún otro municipio), y por lo tanto no son reutilizables y tendrán que ser desarrolladas a la medida por el municipio propiamente dicho, las aplicaciones cuyos datos son generados y utilizados en un único municipio, y por lo tanto no necesitan intercambiarse ni integrarse con ningún repositorio nacional, las soluciones tecnológicas cuya plataforma no está en uso en el país y/o para las cuales no existen recursos capacitados (aunque sean gratuitas). 34. Es evidente que la reutilización de los procesos y de los datos es un criterio prioritario de selección de soluciones, aunque no sea el único. 35. La bibliografía mundial reconoce en forma general que la introducción de las tecnologías de la información y de la comunicación (TIC) puede ser un factor importante de desarrollo económico y humano. Sin embargo, la cantidad de fracasos mundiales en proyectos similares puede igualar, o superar, la cantidad de éxitos. Por tratarse de tecnologías emergentes, aún no existe una cultura y un conocimiento profundo de las condiciones que propician el fracaso o el éxito de este tipo de proyectos y, desgraciadamente, muy pocos actores tienen la voluntad de reportar fracasos y documentarlos. 36. Aún no se sabe a ciencia cierta por qué un proyecto de introducción de las TIC en un país, o en una zona de un país, puede resultar exitoso mientras el mismo proyecto en otra zona o en otro país fracasa. Sin embargo, sí parece existir un consenso alrededor de que un proyecto TIC, si es exitoso, puede traer grandes beneficios a la población. 37. Cuando un país carece de recursos, como Nicaragua, las decisiones de inversión deben ser cuidadosamente evaluadas para minimizar las probabilidades de fracaso. Además, en nuestros países, una experiencia fracasada y no correctamente documentada, casi seguramente hipotecará las posibilidades de repetir la experiencia. Es parte de la cultura de la supervivencia el no tomar riesgos con nuevas tecnologías, por la escasez de recursos económicos y humanos que obligan a minimizar las pérdidas. 4. SOA, arquitectura orientada a servicios 38. Los conceptos básicos del SOA se establecieron hace 20 años y ha tenido éxitos por encima de otras tecnologías Cuál es la razón? Primera tecnología que utiliza los servicios sueltos donde cada uno es económico de construir y mantener. Utiliza una tecnología definida en un estándar universal en servicios Web y XML. Los servicios compartidos son necesarios para utilizar SOA

Utilizar SOA significa un cambio en el estilo de programar. Muchos desarrolladores utilizan equipos diferentes para resolver problemas de manera independiente para cada aplicación. En SOA se necesita escribir aplicaciones para ser re-utilizadas, usando códigos existentes, a los cuales se podrá tener acceso constantemente. 39. SOA define las siguientes capas de software: Aplicaciones básicas: Sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad; De exposición de funcionalidades: Donde las funcionalidades de la capa aplicativas son expuestas en forma de servicios (servicios Web). De integración de servicios: Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración. De composición de procesos: Define el proceso en términos del negocio y sus necesidades, varía en función del negocio; De entrega Esta relacionado a los servicios desplegados a los usuarios finales. 40. La bibliografía existente sobre la SOA describe principalmente servicios empresariales, con un alto nivel de granularidad, lo cual contrasta con los servicios actualmente identificados e implementados en diferentes proyectos del país (Intendencia de la Propiedad, VUI, proyecto TELCOR-BM-Estelí). Este documento no pretende describir en forma detallada en que consiste la Arquitectura Orientada a Servicios y se refieren los lectores a la bibliografía existente. 41. Por la obligación coyuntural de implementar una SOA institucional "desde abajo", por medio de iniciativas individuales, los servicios implementados tienen una baja granularidad y califican probablemente como servicios atómicos, en las definiciones de la bibliografía. 42. Sin embargo, la implementación de un proyecto coherente y consistente de gobierno municipal electrónico provee un reto interesante para elevar el nivel de granularidad y analizar las aplicaciones tradicionales de uso en el ámbito municipal como servicios. De esta manera, en primer análisis, se puede identificar los servicios siguientes: Servicio de participación ciudadana Servicios de recaudación municipal Servicio de registro de contribuyentes Servicios administrativos-financieros municipales Servicios de administración de proyectos Servicios de estadísticas e indicadores Servicios de emergencias y de prevención de desastres Servicios de planeación territorial Trámites y servicios municipales Trámite y servicios del gobierno central canalizados por el gobierno municipal Servicio de entrega a domicilio Etc. 43. Y es relativamente fácil elaborar una matriz de interacción entre los diferentes servicios, o entre estos servicios y componentes reutilizables ya desarrollados. Por ejemplo, El servicio de trámites y servicios municipales y del gobierno central invocan el catálogo de trámites y servicios del estado, las operaciones de caja del sistema administrativo financiero, el servicio de administración de documentación entrante y saliente, el registro de las personas y el servicio de entrega de productos tramitales a domicilio. El servicio de participación ciudadana se alimentará del servicio de planeación territorial, del servicio de administración de proyectos, el de estadísticas e indicadores y podrá alimentar a su vez el servicio de los trámites y servicios municipales o del gobierno central, etc.. 44. La bibliografía mundial está de acuerdo en identificar y enfatizar características muy específicas de diseño como por ejemplo:

organización en componentes acoplamiento: relajado o estrecho bases de datos compartidas o dedicadas aplicaciones con o sin estados distribución reutilización seguridad/privacidad custodia de los datos centralizada o distribuida custodia de las aplicaciones centralizada o distribuida propagación de los datos niveles de calidad de servicio 45. Los componente reutilizable de la SOA del gobierno electrónico central implementados hasta la fecha en los proyectos nacionales parecen caer en la categorización de servicios de infraestructura: 46. Dentro del marco de la automatización, no existe siempre la necesidad de asociar una lógica con un modelo o un proceso institucional. De hecho puede ser altamente benéfico de establecer deliberadamente un contexto funcional que no está centrado en la lógica institucional. Esto resulta esencialmente en una capa de servicios distinta, orientada a la tecnología. El modelo de servicios utilitarios logra esto. Se dedica a proveer funcionalidades de utilitarios de uso transversal, reutilizables, tal como la bitácora de eventos, las notificaciones y el manejo de excepciones. Es idealmente una capa agnóstica de las aplicaciones en la medida que puede consistir de una seria de operaciones que se derivan de sistemas y recursos de múltiples aplicaciones, al mismo tiempo que hacen esta funcionalidad disponible dentro de de un contexto muy específico de procesamiento. Estos servicios utilitarios son también conocidos como servicios de aplicaciones, servicios de infraestructura o servicios de tecnología. 47. Nota: los modelos de servicios de entidad, tarea y utilitarios son intencionalmente genéricos en su naturaleza en la medida que se aplican a prácticamente cualquier tipo de empresa o institución. Se pueden desarrollar variaciones adaptadas a cada caso para satisfacer tipos específicos de dominios. 48. La SOA es un modelo arquitectónico también agnóstico en cuanto a la plataforma tecnológica. Eso le da a las empresas e instituciones del país, la libertad de continuamente perseguir las metas estratégicas asociadas con la computación orientada a servicios, palanqueando los avances tecnológicos del momento. En el mercado actual, la plataforma tecnológica más asociada con la realización de arquitectura orientada servicios es la de los Servicios Web. 49. Los Servicios Web se derivan de dos estándares: plataforma de primera generación de servicios Web que cubre las tecnologías nucleares siguientes: WSDL, XSD, SOAP, UDDI y el perfil básico WS. Esta plataforma ha sido ampliamente adoptada por la industria, pero tiene una serie de limitaciones que condujeron a la plataforma siguiente: Servicios Web segunda generación: extensiones WS-*: ejemplo WS-Policy, WS-Security, WS-Addressing. 4.1 Principios de modelación de una arquitectura conceptual orientada a servicios 8 50. Una arquitectura conceptual ofrece diferentes perspectivas a la implementación de software orientados a servicios. Describe un entorno tecnológico donde elementos interactivos colaboran para solucionar un problema. ( ) Antes de que una arquitectura física para un proyecto o una iniciativa más grande pueda ser desarrollada, una arquitectura conceptual debe existir. Estas abstracciones tecnológicas son análogas a un mapa de alto nivel que ofrece direcciones generales para lograr ciertos objetivos, al mismo tiempo que provee una orientación tecnológica de mucho valor. 51. La transferencia tecnológica de los principios de modelación de una arquitectura conceptual orientada servicios deberá ser transferida en el futuro a los actores interesados en implementar esta propuesta y no puede pretender describirse en forma detallada en este documento. 8 [BELL001]Service Oriented Modeling, Service Analysis, Design, and Architecture, Michael Bell, 2008, John Wiley and Sons

52. Según Wikipedia, la Arquitectura Orientada a Servicios (en inglés Service Oriented Architecture), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio. Permite la creación de sistemas altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma estándar de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios Web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros. SOA define las siguientes capas de software: Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad; De exposición de funcionalidades - Donde las funcionalidades de la capa aplicativas son expuestas en forma de servicios (servicios Web); De integración de servicios - Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración; De composición de procesos - Que define el proceso en términos del negocio y sus necesidades, y que varia en función del negocio; De entrega - donde los servicios son desplegados a los usuarios finales. 53. SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación. 4.2 Definiciones SOA Término Definición / Comentario Servicio Orquestación Sin estado Proveedor Consumidor Una función sin estado (Existen servicios asíncronos en los que una solicitud a un servicio crea, por ejemplo, un archivo, y en una segunda solicitud se obtiene ese archivo), auto-contenida, que acepta una(s) llamada(s) y devuelve una(s) respuesta(s) mediante una interfaz bien definida. Los servicios pueden también ejecutar unidades discretas de trabajo como serían editar y procesar una transacción. Los servicios no dependen del estado de otras funciones o procesos. La tecnología concreta utilizada para prestar el servicio no es parte de esta definición. Secuenciar los servicios y proveer la lógica adicional para procesar datos. No incluye la presentación de los datos. Equivalente: Coordinación. No mantiene ni depende de condición pre-existente alguna. En una SOA, los servicios no son dependientes de la condición de ningún otro servicio. Reciben en la llamada toda la información que necesitan para dar una respuesta. Debido a que los servicios son "sin estado", pueden ser secuenciados (orquestados) en numerosas secuencias para realizar la lógica del negocio. La función que brinda un servicio en respuesta a una llamada o petición desde un consumidor. La función que consume el resultado del servicio provisto por un proveedor. 4.3 Diseño y desarrollo de SOA 54. La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementación. Para que un proyecto SOA tenga éxito, los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos de planificación, herramientas e infraestructura. 55. Cuando la mayoría de la gente habla de una arquitectura orientada a servicios están hablando de un juego de servicios residentes en Internet o en una intranet, usando servicios Web. Existen diversos estándares relacionados a los Servicios Web. Incluyen los siguientes: XML, HTTP, SOAP, WSDL, UDDI. Hay que considerar, sin embargo, que un sistema SOA no necesariamente necesita utilizar estos estándares para ser "orientado a servicios" pero es altamente recomendable su uso.

56. En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayoría de las definiciones de SOA identifican la utilización de Servicios Web (empleando SOAP y WSDL) en su implementación, no obstante se puede implementar SOA utilizando cualquier tecnología basada en servicios. 4.4 Lenguajes de alto nivel 57. Los lenguajes de alto nivel como BPEL o WS-Coordinación llevan el concepto de servicio un paso adelante al proporcionar métodos de definición y soporte para flujos de trabajo y procesos de negocio. 4.5 Diferencias con otras arquitecturas 58. Al contrario de las arquitecturas orientado a objetos, las SOA están formadas por servicios de aplicación débilmente acoplados y altamente inter operables. Para comunicarse entre sí, estos servicios se basan en una definición formal independiente de la plataforma subyacente y del lenguaje de programación (por ejemplo, WSDL). La definición de la interfaz encapsula (oculta) las particularidades de una implementación, lo que la hace independiente del fabricante, del lenguaje de programación o de la tecnología de desarrollo (como Plataforma Java o Microsoft.NET). Con esta arquitectura, se pretende que los componentes software desarrollados sean muy reusables, ya que la interfaz se define siguiendo un estándar; así, un servicio desarrollado en el entorno Microsoft.Net, C #, podría ser usado por una aplicación Java. 4.6 Beneficios 59. Los beneficios que puede obtener una organización que adopte SOA son: Mejora en los tiempos de realización de cambios en procesos. Facilidad para evolucionar a modelos de negocios basados en tercerización. Facilidad para abordar modelos de negocios basados en colaboración con otros entes (socios, proveedores). Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el proceso de negocio Facilidad para la integración de tecnologías disímiles 5. Construcción de una arquitectura institucional base 9 5.1 Los problemas que pretenden solucionar los gobiernos municipales 60. Los problemas que pretenden solucionar los gobiernos municipales, se presentan tanto en el ámbito de la ciudadanía como en el ámbito de los interesados/actores de las alcaldías y de los gobiernos municipales. Los problemas típicamente reportados por la ciudadanía en su relación con los gobiernos municipales o con las delegaciones departamentales o municipales del gobierno central son: la dificultad y el costo de personal para solicitar y ejecutar trámites y servicios municipales. Por ejemplo: El ciudadano no sabe dónde debe ejecutar su trámite y tiene que recurrir a un gestor o intermediario, lo cual tiene un costo El ciudadano no es informado adecuadamente de los requisitos de sus servicios o trámites y de los documentos probatorios que debe presentar. La consecución de dichos documentos probatorios es una fuente de gastos adicionales y de pérdida de tiempo. la carencia, en algunos casos, de los trámites o servicios necesarios y la necesidad de buscarlos en otra parte o de vivir sin ellos. Por ejemplo: Carencia de servicios que afecta la calidad de vida de la población 9 extraído y resumido de la obra citada

Ciertos servicios no son accesibles en el municipio, sino que en la cabecera departamental o, a veces, solamente en Managua. Carencia de transparencia en la gestión municipal y de participación ciudadana en la toma de decisión El gobierno electrónico (municipal o central) no me conoce, no maneja información acerca de mi y me obliga a buscarla, pero no sé a dónde. 61. Los gobiernos municipales a su vez se enfrentan a una serie de problemas para poder cumplir con la satisfacción de las necesidades y la solución de los problemas de la ciudadanía: Carencia de infraestructura para incentivar la inversión y la competitividad empresarial Insuficiencia de recursos financieros para ejecutar proyectos de infraestructura. Carencia de la información georeferenciada y alfanumérica para planificar correctamente los proyectos de infraestructura; esto incluye también información obsoleta, inexacta o falsificada. Carencia de personal capacitado para administrar herramientas de tipo TIC, carencia de infraestructura informática adecuada, carencia de recursos económicos para equiparse. Los costos de transporte siguen subiendo y consumen una parte creciente del presupuesto municipal. 5.2 Los sistemas y arquitecturas tecnológicas actuales 62. Si bien en el pasado se desarrollaron más de una docena de sistemas informáticos para los gobiernos municipales, son muy pocos los que han perdurado y que pueden ser considerados como rescatables, porque carecen de condiciones mínimas de seguridad, son tecnologías totalmente obsoletas y muchos de ellos no cumplen con prácticas mínimas de ingeniería de software. Es notorio, por ejemplo, que todos los sistemas que manejan de una manera u otra recursos financieros, son desarrollados en plataformas que no ofrecen seguridad mínima de acceso por parte de personas mal intencionadas (en la mayoría de los casos utilizan bases de datos Fox Pro, y en el mejor de los casos, Microsoft Access) 10. 63. Adicionalmente, las limitaciones antes mencionadas hacen que los datos históricos generados por estas aplicaciones presentan poco potencial para su rescate, su confiabilidad, integridad referencial o exactitud son dudosos. El nivel de soporte técnico ofrecido por el INIFOM para estas aplicaciones es de mínimo a nulo. Algunos sistemas tienen funcionalidades que se traslapan. No están hechos para trabajar en redes en la mayoría de los casos, mucho menos para entorno Internet, WAN o LAN. Para resumir, no existe arquitectura definida actualmente en el ambiente de los sistemas municipales, sino que una colección de aplicaciones de tecnología obsoleta, sin posibilidad de rescate. 64. Esta situación tiene poco o ninguna posibilidad de mejorarse a mediano y largo plazo, por lo cual es necesario un mecanismo alterno, basado en una arquitectura aprobada como concepto común, que permite a todos los proyectos de agrupar sus recursos con una estrategia común para el desarrollo de aplicaciones únicas, y habilitar las organizaciones municipales para implementar y administrar estas aplicaciones en forma sostenible, apoyándose en el sector privado de las TIC MIPYME locales. 5.3 El paradigma de los servicios del gobierno municipal electrónico 5.3.1 Aspectos arquitectónicos 65. El paradigma de servicios adoptado por este grupo de trabajo descansa en la identificación de servicios que suministran las instituciones del Estado y los gobiernos municipales a la ciudadanía, y que estos servicios se pueden implementar como servicios digitales o servicios comunes reutilizables (SCR), con las características siguientes: Los servicios comunes reutilizables son "cajas negras", para las cuales sólo se necesita conocer las interfaces que se pueden invocar, los parámetros que se deben proveer y los productos que suministran. Los servicios comunes reutilizables pueden invocarse mutuamente: un servicio puede invocar otro y, a la vez, puede ser invocado. 10 Y aún así, se siguen impulsando proyectos con financiamiento internacional para extender la funcionalidad de algunos de estos sistemas, sin estudios previos de la viabilidad del objetivo.

Los servicios deben ser ofrecidos bajo un mecanismo contractual que garantice su disponibilidad permanente (si un servicio no es confiable, los servicios que lo utilizan no van a poder garantizar su propia confiabilidad). Los servicios deben ser "agnósticos" en cuanto a la información que administran: no es responsabilidad de un servicio guardar información acerca de qué servicio lo consume, cuando, y en qué condiciones. Los servicios de tipo "catálogo o "maestro" pueden generar datos en el ámbito municipal, departamental o nacional que pueden ser replicados para propagación horizontal. Los servicios consumidores son responsables de asegurar la persistencia local de los registros generados en los servicios de tipo maestro o maestro. Por ejemplo, el componente de administración de expedientes digitales (ADX) puede administrar expedientes de N instituciones, pero es responsabilidad de cada institución consumidora de crear su propio registro de los expedientes generados en ADX. Los servicios deben ser diseñados para garantizar la interoperabilidad y la estandarización de la información dentro del la administración pública Toda institución consumidora de servicios tiene la responsabilidad de aportar al patrimonio de servicios digitales del Estado, diseñando otros servicios para que sean reutilizables a su vez por otras instituciones. Los servicios deben ser universales en término de los productos que suministran, independientemente de la plataforma en la cual corren o de la aplicación consumidora. Si un servicio Web se implementa por medio de una capa de envoltura ("wrapper ), tiene la libertad de ofrecer adicionalmente su API para aquellas aplicaciones de su misma plataforma, para ofrecer un mejor desempeño. 5.3.2 Servicios institucionales 66. Ya a esta altura, se puede identificar una serie de servicios institucionales en el ámbito de los gobiernos municipales electrónicos, los que se pueden agrupar de la manera siguiente: Servicios municipales a la población 11 : Registro Civil de las Personas Registro de contribuyentes Matricula empresarial Normatividad municipal para la operación de las actividades económicas Registro de fierro, ganado y movimientos de ganado Tren de aseo Locataria de mercados Pago de impuestos/recaudación fiscal Catastro municipal Servicios básicos: agua y saneamiento, energía eléctrica, caminos y carreteras Documentación urbanística: mapas, planos y políticas Reglamentación y permisos de construcción municipales Uso de suelo, derecho de vía, fallas sísmicas y aspectos legales Servicios sociales de emergencia Apoyo al desarrollo de las MIPYME locales Derechos de uso de infraestructura municipal Servicios de valor agregado Inspecciones e investigaciones en el terreno Sistema de direcciones normalizadas Mantenimiento integrado de la infraestructura municipal Mantenimiento integrado del parque vehicular municipal Participación ciudadana y gobernanza: Participación en los planes de inversión Divulgación y Rendición de cuenta Quejas, reclamos y sugerencias (correo electrónico, atención telefónica, etc.) 11 Estos servicios se pueden ofrecer desde diferentes interfaces, de manera a alcanzar la mayor cantidad posible de la población y reducir el impacto de la brecha digital, utilizando interfases posibles: Ventanilla municipal única de servicios, Front Office para trámites en línea, Atención telefónica a la población, Atención presencial, Pantallas táctiles, telefonía móvil o celulares, etc.

Portal ciudadano Simulación de la planificación municipal Servicios del gobierno central (ofrecidos desde la Ventanilla Municipal Universal de Servicios por medio de un enlace a los trámites y servicios del gobierno central) Ventanilla única de inversiones Registro mercantil Registro de importador/exportador, registro de exportaciones, certificaciones de origen Asesoría sobre mercados, protección a la exportación y los mecanismos de pago Monitoreo de las cuotas de importación Registro de la propiedad intelectual DGI (registro nuevos contribuyentes, declaración en línea, pagos fiscales) Permisos especializados por actividad económica Permisos ambientales Normatividad para la operación de las actividades económicas Aprobación de proyectos Permiso de construcción ministerial Seguro social Registro de contratista del Estado Registro de inversión extranjera en el MIFIC Apoyo al sector MIPYME industrial Apoyo al sector agropecuario Permisos/importación de productos controlados Declaración de mercancía Inspección y pago de impuestos de internación Servicios médicos Inspecciones e investigaciones Inscripción de diplomas Orientación y búsqueda laboral Catastro físico Catastro fiscal Registro público de la propiedad y bienes inmuebles y muebles Asesoría financiera Historial crediticio Fuentes de financiamiento Hipotecas y prendas Registro de títulos, valores, bonos, acciones etcétera. Información de registro de notarios y protocolos Registro fitosanitario y zoosanitario Registros de agroquímicos y productos de uso veterinario Mantenimiento integrado de la infraestructura del Estado Mantenimiento del parque vehicular del Estado etc. Servicios administrativos financieros propios del gobierno municipal Presupuesto Activos Recursos humanos y planilla Contabilidad Tesorería (Caja y bancos) Cuentas por Cobrar Cuentas por Pagar Compras y Contrataciones Seguimiento de proyectos Planificación urbana

Planificación territorial Manejo de sesiones deliberativas Ordenanzas municipales Servicios de estadísticas e indicadores municipales Servicios departamentales Prevención y asistencia sobre desastres y emergencias Planificación territorial departamental 5.4 Identificación de requerimientos organizacionales 67. Este capítulo corresponde al diseño de la arquitectura institucional, y define la organización del gobierno municipal de cara a ofrecer las soluciones a los problemas de la ciudadanía: Los recursos necesarios para implementar el gobierno municipal electrónico exceden, en la casi totalidad de los casos, la capacidad económica y humana de las alcaldías del país, obligando a considerar esquemas parecidos a los centros de interoperabilidad de las municipalidades europeas, para elevar los servicios informáticos municipales al nivel departamental, Una función importante del gobierno municipal electrónico es la planificación territorial, la cual no se puede llevar a cabo dentro del único entorno municipal sino que desborda frecuentemente al ámbito departamental; de hecho, la planificación territorial es alimentada en primera instancia de las metas estratégicas del Plan Nacional de Desarrollo. Gran parte de las instituciones o servicios del Estado están presentes en el ámbito departamental, más que en el municipal, y/o no tienen presupuesto para mantener delegaciones municipales: SINAPRED DGI DGA Catastro Registro mercantil Registro de la propiedad MTI MINSA MECD Impulso de la organización de los municipios en el ámbito departamental 5.4.1 La autonomía municipal y la estrategia digital 68. Los gobiernos municipales invocan con frecuencia a la autonomía municipal para justificar su independencia, particularmente en el ámbito de las tecnologías digitales, donde los financiamientos generalmente provienen de fuentes externas que prefieren tratar en forma bilateral con organizaciones de gobiernos municipales locales. 69. Éstas relaciones bilaterales contribuyen a que muchas veces se confunde la autonomía en términos de políticas de desarrollo con la estandarización o no estandarización de los datos y de las aplicaciones informáticas, resultando en un caos arquitectónico. Si una municipalidad se acoge al argumento de la autonomía municipal para ignorar o desconocer normas, estándares o mejores prácticas, deberá también pagar el precio de financiar sus propios sistemas, y de no compartir el conocimiento ni los recursos comunes en el ámbito nacional 12. 70. La tecnología informática moderna permite sin ninguna dificultad garantizar que los datos de varias alcaldías puedan coexistir dentro de una única base de datos, sin nunca ser accedidos por personas no autorizadas, por lo tanto, téc- 12 Debe ser un ejemplo para los demás municipios del país, que el consejo municipal de la alcaldía de Estelí recomendó, al aprobar el proyecto de gobierno municipal electrónico, que su implementación se hiciera dentro del marco de la asociación de municipios de Estelí (AMUDES).

nicamente, no hay ninguna justificación para invocar la autonomía municipal como argumento para no compartir las pistas aplicaciones y las mismas bases de datos. 71. El presente trabajo desarrolla la tesis que el ámbito departamental provee a los municipios la autonomía deseada, sin perder de vista la necesidad de mantener la consistencia con una visión más amplia que la de un municipio, y de garantizar la sostenibilidad de los servicios digitales que aspira a proveer a su población. Esto es particularmente cierto en el caso de la planificación territorial, la cual, en gran parte, recibe sus metas estratégicas de la planificación nacional, por medio del plan nacional de desarrollo económico y humano, y en la interoperabilidad con los servicios del gobierno central en el ámbito departamental. 72. El compartir metas estratégicas comunes obliga los municipios de un departamento a ejecutar su planificación territorial tomando en cuenta los propios planes estratégicos de los municipios adyacentes. Casi siempre se dará que un proyecto de infraestructura municipal tendrá un impacto, aunque leve, sobre el desarrollo de otro municipio. De la misma manera, es casi inevitable que los proyectos de infraestructura departamental tengan impactos sobre el desarrollo de los departamentos circundantes. 73. Esta interacción inevitable obligará los municipios a colaborar estrechamente, independientemente del color de su partido. Es parte de este modelo que el sistema de información a implementarse en el ámbito departamental contribuirá a reducir los ruidos partidarios y políticos. Es también una consecuencia de este modelo que la mayoría de las decisiones técnicas que se suscitarán podrán ser resueltas sin la interferencia de consideraciones partidarias. La interoperabilidad departamental tiene el potencial para convertirse en el gran unificador de los municipios. 74. Sin embargo, la arquitectura debe permitir a una alcaldía instalar sus propios sistemas de manera insular, y debe ser debidamente informada de los riesgos, costos y consecuencias que deberá asumir. 5.4.2 Rastreabilidad de las decisiones tomadas y del manejo de los datos institucionales 75. La rastreabilidad se aplica tanto a las decisiones tomadas como al manejo de los datos. Las decisiones tomadas deben ser documentadas en todos los ámbitos. Por ejemplo, el ciclo de desarrollo de las aplicaciones institucionales debe ser documentado por ayudas memorias aprobadas por las partes, uso de la metodología de casos de uso, y en general, la documentación de todas las decisiones tomadas. 76. En el ámbito de los datos, a priori ningún registro de ninguna tabla de ningún sistema de la administración pública debe poder ser borrado físicamente sin el soporte de la auditoría de datos necesario. De esta manera, todas las tablas de toda las aplicaciones de la administración pública llevarán un control de las operaciones de creación de los registros, modificación de los campos o atributos de los registros creados y el borrado lógico de los mismos. 77. Las bitácoras correspondientes se manejan a partir del componente reutilizable de Seguridad Integrada, uno de los componentes reutilizables del gobierno electrónico. 78. En el caso de los trámites y servicios de administración pública, éstos son validados exclusivamente con el componente CTS, catálogo de trámite y servicios, con la especificación de los instrumentos legales que los validan. 5.4.3 Conformación con los meta modelos propuestos en el marco conceptual del gobierno electrónico 79. El marco conceptual del gobierno electrónico identificó más de 30 meta modelos, muchos de los cuales ya han sido puestos en práctica en diferentes proyectos y han demostrado su validez como referencia arquitectónica. Los términos de referencia de las aplicaciones informáticas a desarrollarse en el marco del gobierno municipal electrónico deben incluir una descripción de los meta modelos a aplicar y exigir el cumplimiento con los mismos. 5.4.4 Requerimiento del uso de servicios Web para la comunicación entre servicios (comunes reutilizables), 80. Como se describió en el capítulo 5, la arquitectura del gobierno municipal electrónico descansa sobre el modelo SOA, de Arquitectura Orientada a Servicios, con más de una decena de servicios existentes, ajustados al marco del proyecto de gobierno municipal electrónico y para ser implementados y utilizados. 81. El acceso a los servicios comunes reutilizables (SCR) es garantizado de dos maneras: por invocación de servicios Web

por invocación de RPC (API) propios cuando las plataformas del SCR y de la aplicación cliente son las mismas. 82. En teoría, el sistema operativo donde corren los componentes reutilizables puede ser indiferente, siempre y cuando los SERVICIOS WEB sean libremente accesibles por cualquier aplicación cliente. 83. Hay que notar, sin embargo, que las aplicaciones clientes pueden correr tanto localmente - como aplicación cliente tradicional en la cual los formularios de interfaz con el usuario se implementan localmente - o en forma de aplicación Internet, donde los formularios de captación de datos y la lógica de la aplicación cliente residen en un servidor de aplicaciones y el acceso a la aplicación cliente se hace por medio de un Browser Internet. 84. A continuación un ejemplo de meta modelo de organización del gobierno electrónico, central o departamental y otro ejemplo de meta modelo, para los registros y repositorios nacionales. 85. Es meta modelo permite identificar los grandes componentes del gobierno electrónico, sus aplicaciones tras ventanillas que alimentan los registros, sus fundaciones (la denominación antigua utilizada en el marco conceptual del gobierno electrónico para describir los componentes reutilizables), los subsistemas de infraestructura, la administración de los trámites y servicios en línea y el portal de acceso para la población. 5.4.5 Apoyo al desarrollo económico TIC del departamento 86. Tanto el marco conceptual del gobierno electrónico como este proyecto han establecido el carácter público que debe tener el código-fuente desarrollado para los gobiernos electrónicos, central o municipal. Pero el principio más general es que los proyectos financiados por el Estado deben beneficiar tanto a los ciudadanos receptores de los servicios como a las MIPYME del sector TIC a través de la transferencia tecnológica que le permita incrementar su competitividad fuera del país. 87. El proyecto heredará de los avances tecnológicos acumulados en los diferentes proyectos desarrollados dentro del marco conceptual del gobierno electrónico, lo que abre la puerta para que estos avances tecnológicos sean transferidos (gratuitamente) a las empresas nacionales de este sector aunque, claramente, una cierta reglamentación será necesaria en cuanto al alcance de esta transferencia y de los beneficios a esperar, así como de los compromisos y responsabilidades de los beneficiados de seguir aportando al proyecto nacional. e-gobierno Subsistemas de Infraestructura e-gob.admin e-gob.cons e-gob.com e-gob.ejop b-aplicaciones e-tramites i-aplicaciones Básicas e-fundaciones g-aplicaciones e-pagos e-cap e-sesion Portal e-autenticacion e-apoderamiento i-fundaciones Beneficiario directo (from Actores y Roles)...) Registros Funcionario Publico Diccionario de Datos Tablas de Convalidación Motor de Reglas Seguridad Integrada Catálogo de Trámites y Servicios Agrupaciones Poblacionales Estructura Organizativa (f rom i-fundaciones)

5.4.6 Entorno del mantenimiento futuro de los componentes 88. La naturaleza de la arquitectura orientada a servicios implica la custodia centralizada o parcialmente distribuida de la gran cantidad de componentes reutilizables que generará tanto la plataforma de gobierno electrónico central como la de los gobiernos municipales electrónicos. En la actualidad, ninguna institución ha oficialmente asumido la implementación de la arquitectura orientada a servicios dentro del marco de gobierno electrónico, por lo tanto existe indefinición sobre qué institución tendrá la custodia física y normativa de los componentes reutilizables ya desarrollados, y por desarrollarse o por reescribirse para el proyecto Estelí. 89. Obviamente, las tecnologías a utilizar en la reescritura de los componentes reutilizables afectará grandemente la disponibilidad de recursos y, por lo tanto, la selección de la institución custodia. En otras palabras, existe una interacción inevitable entre la plataforma de los componentes a reescribir y la capacidad de mantenimiento de la futura organización custodia de los mismos. 5.5 La arquitectura institucional meta 90. Representa un mecanismo de orientación para las decisiones tecnológicas de los proyectos. Para ello se vale de la descripción arquitectónica de los datos, las aplicaciones y las tecnologías que debe satisfacer la informática institucional. La arquitectura meta implica transformar la visión estratégica del estado en planes factibles de desarrollo informático para la ejecución de largo plazo. La secuencia para la elaboración de estas arquitecturas debe ser la siguiente: arquitectura de datos arquitectura de aplicaciones arquitectura tecnológica 91. Por otro lado, la experiencia acumulada hasta la fecha en diferentes proyectos en el Estado, basados en la interoperabilidad y en el uso de componentes reutilizables en el marco de la arquitectura orientada servicios, permite identificar una serie de principios básicos: Existe una jerarquía procesal de los datos: por ejemplo, no se pueden generar indicadores ni proponer a aplicaciones gerenciales si no existen los datos fuentes. Bajo este mismo principio, los portales que no ofrecen servicios no tienen vida útil ni son sostenibles: no se vuelve a visitar un portal que ofrece la misma información, que no ofrece servicios ni ejecutar acción alguna. El objetivo del gobierno municipal electrónico es de ofrecer servicios a la población, rápida y económicamente. Los portales que sobreviven son los que son utilizados una y otra vez. 5.5.1 Arquitectura de datos 92. Proporciona un recurso de referencia para determinar la información que el Estado almacena o debería almacenar para su gestión. Tanto la ingeniería de la información, así como otras disciplinas, señalan las necesidades de datos como el origen subyacente de los sistemas de información, debido a su carácter casi invariable en comparación a los procesos, siendo estos últimos (in)mutables debido a la dinámica organizacional, la cual es consecuencia, entre otras cosas de la informatización. 93. La definición de la arquitectura de datos debe al menos lograr un consenso entre los distintos expertos del dominio sobre la definición de las entidades, sus atributos y las funciones institucionales vinculadas al uso de estos datos. Las herramientas de modelación para esta arquitectura son: diagrama de entidades relaciones diagrama de clases matriz entidad-función matriz entidad-unidad organizativa

94. El gobierno electrónico está basado sobre el concepto de repositorios, públicos en la mayoría de los casos. Un repositorio público es la agregación de uno o varios registros básicos, creados por la ley frecuentemente a nivel departamental o municipal: Registros civiles de las personas, con ámbito municipal Registros públicos de la propiedad, con ámbito departamental Registro mercantil, con ámbito departamental Catastro, actualmente con ámbito departamental etc. 95. En este meta modelo, se describe como los repositorios públicos son alimentados de los registros parciales, los únicos que pueden crear nuevos registros (los cuales se agregan en registros del estado). Los repositorios públicos a su vez son la única fuente para crear registros auxiliares, los cuales no pueden generar un registro nuevo si éste no esta previamente contenido en el repositorio público. De esta manera se garantiza que ninguna institución del estado puede incluir en una registro auxiliar una persona o un objeto que no ha sido legítimamente creado en un registro parcial. 1 Repositorio Publico +ElRegistroParcialCustodiado Actualización RCD +TipoRegistro específico n Registro Parcial Crear nuevo registro() Actualizar registro existente() 0..n Registro del Estado (from Custodia de los Datos) 1 Nuevo Registro() 0..n Actualizar Registro() 0..n 0..n 1..n Estructura complementaria Registro Auxiliar (from Registros Basicos y Auxiliares) 96. Actualmente, no existen repositorios en el Estado para consolidar estos registros. Lo más cercano que existe es el padrón electoral del Consejo supremo electoral, con una serie de limitantes, la mayor de ella siendo que solamente contiene los nacionales en edad de votación, no contiene los menores de edad ni los extranjeros residentes. 97. La única manera de crear una entrada en un repositorio público es desde un registro básico. Un repositorio público es el medio para poner a disposición de las diferentes aplicaciones del estado un consolidado de los registros básicos que lo conforman. A partir de un repositorio público, cualquier institución puede crear los registros auxiliares que necesita, con la custodia correspondiente. Si bien se debe poder acceder (navegar) a los datos de un registro básico (cuando es público) desde el repositorio, normalmente los registros auxiliares no son accesibles desde el repositorio central, y son considerados como información privada. 98. Por otro lado, es la ley la que especifica que información se puede guardar sobre los ciudadanos. Si la ley no lo declara específicamente, el estado no tiene la autorización para almacenar esta información de oficio. Por lo tanto, debe existir un mecanismo que permite asociar toda información almacenada en los registros del estado a algún tipo de instrumento legal.