Comentarios al documento Arquitectura para los gobiernos municipales electrónicos

Transcripción

1 Comentarios al documento Arquitectura para los gobiernos municipales electrónicos Estrategia versus arquitectura En este momento la arquitectura tiene una lista de supuestos implícitos sobre p.e. factibilidad de colaboración interinstitucional sin problemas, conectividad sin interrupciones, capacidades institucionales y alto valor de componentes reutilizables, que no coincide con lo que se observa en Nicaragua en este momento. Es fundamental establecer un consenso sobre estos supuestos antes de entrar en discutir los detalles técnicos. Mi propuesta es para no perdernos en detalles técnicos primero discutir estrategia y después definir aspectos técnicos. Los pasos metodológicos debería ser: 1. Análisis de la situación actual de gobierno electrónico municipal (GEM) 2. Definir estrategia para avanzar hacia GEM (considerar p.e. roles institucionales, financiamiento, relaciones con gobierno central y otras instituciones, prioridades para automatizar, recursos disponibles, grado de colaboración interinstitucional factible, conectividad probablemente inestable) 3. Definir arquitectura y/o marco de interoperabilidad La diferencia entre la arquitectura propuesta y lo que hace el Programa TIC MUNICIPAL está fundamentalmente en el análisis de la situación actual, y la estrategia a seguir. No estamos dudando lo deseable de los aspectos técnicos de lo propuesta, pero el análisis de la realidad y la factibilidad de diferentes opciones estratégicos nos han llevado a conclusiones muy diferentes. Definición de Gobierno Electrónico Municipal El Programa TIC MUNICIPAL usa la definición: Gobierno electrónico municipal es todo uso de tecnologías de información y comunicación en los gobiernos municipales La ventaja de esta definición es que el análisis incluye todo el uso de TIC en las alcaldías. La arquitectura propuesta no presenta una definición y la lectura del documento indica lo siguiente: a. El enfoque principal es sobre servicios y tramites en gobiernos municipales b. Pero a veces se limita a los sistemas externos (comunicación con ciudadanos o gobierno central c. Y a veces también incluye sistemas internas como p.e. admin-financiera

2 d. No incluye administración de documentos que actualmente es 90 % del uso de computadoras en las alcaldías Es importante incluir todos los principales uso de TIC y sobre todo el último punto sobre administración de documentos, dado que en el futuro previsible será el principal uso. La consecuencia de no considerar este aspecto por ejemplo se puede observar cuando se compare centros de computación regional con soluciones locales. Correr aplicaciones regionales no resuelve los problemas de respaldos automáticos de datos de los PC, lo que en la actualidad es una de los principales problemas en las alcaldías. Grado de colaboración interinstitucional factible Nicaragua es un país con un bajo nivel de colaboración interinstitucional, y hay una tradición de las instituciones de ver sus sistemas y registros como propiedad de ellos mismos. Y también de utilizar datos como un elemento de la lucha de poder, y no como un bien común. No cabe duda que el principal obstáculo para lograr interoperabilidad en Nicaragua es la falta de voluntad de colaboración interinstitucional. Es importante resaltar que la lucha de poder y problemas de colaboración interinstitucional entre diferentes partes del estado, son comunes en todo el mundo, y ningún país ha logrado superar eso. La arquitectura propuesta tiene un supuesto clave que es una colaboración plena entre instituciones tanto en intercambio de datos, metodologías de trabajo, servicios y software etc es factible. Este supuesto lamentablemente no se cumple y no se cumplirá en el futuro previsible. Obviamente hay ejemplos aislados donde se logre superar estos problemas, pero frecuentemente es más por amistades profesionales y no como algo institucionalizado. El poder y los recursos necesarios para realizar una estrategia esta en las instituciones y se tiene que contemplar esta realidad. Cambiar el supuesto de plena colaboración tiene implicaciones drásticos sobre la arquitectura propuesta, pero si no se cambie la propuesta es un sueño. Un supuesto más real es que colaboración interinstitucional es difícil lograr y a corto y mediano plazo solamente se logrará en algunas áreas selectas. La implicancia de cambiar este supuesto es que en lugar de maximizar el uso de colaboración, se debe minimizar la necesidad de colaboración y/o interoperabilidad, y solamente utilizarlo cuando realmente es necesario o cuando los beneficios son enormes. Una forma de hacer eso es enfocarse en un Marco de Interoperabilidad, y no aspirar a una arquitectura común en este momento (véase abajo). Capacidades y roles institucionales La arquitectura habla de los niveles departamentales y nacionales como si eran instituciones, pero no lo son. A ambos niveles existe una multitud de instituciones con roles y capacidades diferentes. El tema de soporte técnico y las dificultades en obtener datos son las cuellos de botella más importante para avanzar hacia un gobierno

3 electrónico municipal este análisis es de suma importancia. El documento sobre la línea base discute este tema. Algunos temas a considerar son: a. Hay pocas capacidades institucionales en TIC en el sector municipal, y hay muchos conflictos entre las instituciones. b. Algunas instituciones como MHCP, DGI, INETER, y CSE tiene datos y capacidades TIC con un alto valor potencial de las alcaldías. Como potencializar este? c. El tema de soporte técnico a las aplicaciones municipales no se ha resuelto en Nicaragua. En la sección 5.9 se menciona el problema, pero no hay propuesta de solución. d. El modelo implícito del documento es una dependencia completo de los consultores responsables de desarrollar y-o implementar los sistemas, lo que no es aceptable. En algunos lugares se habla de minimizar las dependencias de empresas específicos, pero si no se resuelve el tema institucional, la consecuencia será lo contrario. La estrategia no se puede definir independientemente del análisis de las capacidades y roles institucional, así como considerando la factibilidad de colaboración. Valor limitado de componentes reutilizables La estrategia hace mucho énfasis en Componentes Reutilizables, y hasta que a veces confunde los términos SOA y componente reutilizable. Este concepto no es nuevo, y cualquier desarrollador de software lo aplica dentro de su propio de trabajo y con sus colegas. No obstante, la reutilización de componentes en forma más general es difícil lograr, y más que todo se logra en los casos donde son componentes grandes con muchas funcionalidades o marcos de trabajo enteros. La experiencia con el Marco Conceptual de Gobierno Electrónico en Nicaragua soporte esta experiencia general. El producto tangible de la estrategia de enfocarse en componentes reutilizables apenas son 10 componentes o lo que equivale a aproximadamente una persona trabajando a medio tiempo en el tiempo que ha existido la estrategia, y algunos de los componentes se realizaron antes que existía la estrategia. Los 10 componentes reutilizables representan menos del 1% del esfuerzo de desarrollo de software del gobierno en el tiempo que ha existido el marco conceptual. Los proyectos donde se ha implementado el marco ha sido casos donde se ha involucrado el mismo grupo de consultores o donde se han tenido relaciones personales o profesionales. Un problema serio a considerar con la reutilización es que crea dependencias entre aplicaciones y este puede volverse una pesadilla al tratar de actualizar sistemas. En Windows el fenómeno es conocido como dll hell (infierno de dll) por las dificultades de tener múltiples aplicaciones utilizando los mismos funciones. Cuando no se cambie los

4 componentes funcione bien, pero al cambiar algo, las problemas de interdependencias se puede volver un problema serio y siempre hay cambios. El uso de componentes reutilizables sobre todo es relevante en temas donde favorecen la interoperabilidad entre sistemas. Para funciones internos en los sistemas el valor es limitado, y los costos de transacción de coordinar y actualizar bien pueden superar el valor. Éxito limitado del marco conceptual de gobierno electrónico nacional El documento caracteriza el grado de éxito del marco conceptual elaborado anteriormente para el nivel nacional como limitado, y el ejemplo arriba sobre los componentes reutilizables indica que el impacto práctico ha sido limitado. Pareciera que aunque muchas profesionales conocen al menos en términos generales el marco conceptual, no lo aplican en la práctica en su trabajo. A pesar del éxito limitado el marco conceptual para el nivel municipal es prácticamente idéntico que el marco nacional. Los capacidades informáticos en el sector municipal son aún menores que en el gobierno central, y sería sorprendente si una estrategia que has sido un éxito limitado con el gobierno central puede funcionar en el sector municipal. Desarrollo de sistemas versus sistemas existentes de fuentes abiertas. La arquitectura tiene un supuesto general de que sea necesario hacer desarrollo de sistemas versus usar sistemas existentes. Todo el documento esta formulado en base de hacer desarrollo nuevo, y solamente en la última sección se comienza una discusión sobre las diferentes posibilidades para adquirir sistemas. Si se acepta la utilización de sistemas de fuentes abiertas como una opción válida este tiene implicancias en muchas partes de la arquitectura, y drásticamente cambie por ejemplo los conceptos de componentes reutilizables y las metodologías de trabajo. Como señalado en la Línea Base el Programa TIC MUNICIPAL ya tiene identificados sistemas de fuentes abiertas que pueden cubrir muchas de las necesidades municipales. Un ejemplo es el sistema administrativa financiera donde el marco conceptual preparado por INIFOM estima el tiempo de desarrollo en 250 meses consultor. Con un sistema de fuentes abiertas este tiempo y costo se reduce drásticamente. El concepto componente reutilizable es diferente con sistemas de fuentes abiertas dado que es una reutilización de sistemas enteros y no solamente de componentes. Además el mantenimiento del sistema es compartido internacionalmente. El principio fundamental para lograr interoperabilidad con sistemas de fuentes abiertas es utilizar wrappers para proveer servicios SOA o similar. Por ejemplo en Brasil se utiliza muchas aplicaciones de fuentes abiertas, y de estos se construye interfaces con el marco de interoperabilidad del gobierno. La estrategia de gobierno electrónico municipal debe requerir que antes de hacer cualquier desarrollo de sistemas nuevas se debe investigar si existen sistemas de

5 fuentes abiertas maduras que cumplen las necesidades identificados. Un sistema de fuentes abiertas madura tiene por ejemplo documentación, muchas implementaciones operando, un grupo de desarrollo de múltiples instituciones, varios años de funcionar, soporte técnico en foros pero también por medio de varios empresas privadas. La gran mayoría de los sistemas de fuentes abiertas no son maduras, pero algunos pocos lo son, y la propuesta es escoger entre estos los más adecuados. Marco de interoperabilidad de gobierno versus Arquitectura nacional. Interoperabilidad en gobierno electrónico se puede lograr por medio de la adopción de estándares acuerdos entre diferentes partes de cómo realizar una tarea o por medio de arquitectura la organización fundamental de un sistema incluyendo los componentes y sus relaciones entre si y hacia el entorno, así como los principios dirigiendo el diseño y desarrollo. Lograr interoperabilidad por medio de estándares implica establecer un Marco de Interoperabilidad de Gobierno, MIG (Government Interoperability Framework en ingles): Un número de estándares y lineamientos que el gobierno usa para especificar la forma preferida en que las instituciones, los ciudadanos y los socios interactúan entre sí. La propuesta de arquitectura es como dice el titulo del documento un ejemplo de una arquitectura. La propuesta implica un nivel de colaboración interinstitucional extrema y muy detallada, con respecto a datos, metodologías de trabajo, software etc. Este nivel de colaboración es muy lejos de la realidad existente, y las dificultades en implementar el Marco Conceptual para el Gobierno Central demuestran eso. También se supone la existencia de un MIG y hasta que un Infraestructura Orientado a Servicios, IOS (Service Oriented Infrastructure), que es lo que en el documento se denomine Conector común. La realidad actual es que no existe un IOS, por lo cual los SOA propuesta, no tienen la infraestructura clave para poder interconectarse. Establecer un IOS y MIG es una meta mucho más alcanzable que establecer una arquitectura común. Considerando las dificultades de colaboración interinstitucional y las capacidades extremadamente limitadas en TIC en el sector municipal pareciera mucho más factible enfocarse sobre la IOS y MIG, pero no aspirar a una arquitectura común actualmente. Establecer un MIG y un IOS no es un tema municipal, pero es algo que debe hacer el gobierno central, dado que estos aplicarán a todo el sector gobierno y también en la comunicación con ciudadanos y otros. El eping en Brasil es un buen ejemplo de esta estrategia. Centros de computación departamental En la arquitectura se toma como un supuesto que centro de computación departamental es la mejor opción para las aplicaciones municipales, sin embargo, el análisis es subestima la infraestructura TIC necesario en cada alcaldías de cualquier forma.

6 1. Cada alcaldía necesita tener un RAL, y seguridad adecuada independiente de la solución. 2. Es necesario actualizar el software periódicamente en las PCs 3. Un gran parte del uso de las computadoras será con ofimática, y sistemas de respaldo automático es clave. 4. Realizar los tres primeros puntos es más fácil con un servidor que sin un servidor. Aun más importante no se considera adecuadamente que algunas aplicaciones como sobre todo el sistema administrativa financiera y la recaudación debe funcionar 100 % del tiempo y con la calidad de la conectividad en zonas rurales en Nicaragua este es poco probable con una solución regional. La solución regional depende de establecer un tipo de empresa informática regional colaborativo, lo que actualmente no existe, y no es un tema trivial de establecerlo. De ninguna forma es malo experimentar con una solución departamental, pero los riesgos y las necesidades de infraestructura TIC en las alcaldías deben ser más claros. En TIC MUNICIPAL se experimentará con soluciones locales, y después se puede compartir experiencias. Las capacidades institucionales es un tema que no hemos resuelto y es válido probar diferentes soluciones. Priorizar áreas a automatizar Este es más un tema de estrategia y no tanto de arquitectura, pero para avanzar en forma ordenada sería clave definir las prioridades a automatizar. La línea base incluye un análisis de este tema. Calidad y estabilidad de conectividad La arquitectura tiene un supuesto implícito de conectividad de buena calidad y estabilidad, por ejemplo en el uso amplio de SOA y de centros departamentales. Un supuesto más real es que tengamos conectividad por ejemplo 90 % del tiempo y es preferible que el uso de SOA sea asincrónico y para intercambio interinstitucional indispensable (minimizar dependencia), y las aplicaciones de uso frecuente deben correr localmente.