Categorías
Administración Electrónica

¿Debería cobrar la Red Sara por los servicios que ofrece?

No hace mucho, era noticia la intención de la Comunidad de Madrid de establecer peajes en sus autovías, hasta ahora de uso gratuito, ya que «… no podemos pagar su mantenimiento«. Seguramente esto no le habrá hecho mucha gracia a todos los que las usan a diario para ir desde su domicilio en la periferia de Madrid hasta el centro, sobre todo porque hasta ahora siempre daban por supuesto de que eran «gratis» (lógicamente descontando los costes del combustible, compra y amortización del vehículo, etc.).

Esta semana, en el evento de Socinfo «Simplificación y Seguridad Jurídica en la Administración Electrónica», el Subdirector General de Programas, Estudios e Impulso de la Administración Electrónica, Aitor Cubo Contreras, al tiempo que explicaba los aspectos técnicos de la Seguridad de las aplicaciones de Administración Electrónica, ofrecía a los presentes, muchos de ellos personal TI perteneciente a los Ayuntamientos y CCAA, al explicar el Sistema de Interconexión de Registros, la posibilidad de utilizar sus servicios, bien interconectándose al sistema SIR, o bien a través de una aplicación gratuita en modo Software as a Service (SaaS) usando para ello el servicio ORVE (Oficina de Registro Virtual de Entidades Locales).

Desde luego, muchas Entidades Locales y, quizás también Comunidades Autónomas, están muy interesadas en la utilización de este tipo de servicios gratuitos, puesto que sus presupuestos han bajado notablemente en los últimos tiempos.

Este caso no es un caso puntual. Desde hace tiempo, están disponibles en la Red Sara un buen número de servicios, que desde luego entrarían en la categoría de servicios comunes, para su utilizacion por los diversos organismos de la AGE y también por el resto de Administraciones, de los cuales el más conocido es el servicio de validación de certificados de la plataforma @firma, que, según el OBSAE, en 2011 fueron más de 66 millones.

Sin embargo, la pregunta es, ¿está también la AGE, en particular la DG de Modernización administrativa, procedimientos e impulso de la administración electrónica, en condiciones de seguir aumentando la prestación de estos servicios gratuitos, y con un prespuesto también cada vez más reducido?.

Debo decir de antemano que estoy a favor de la «factorización» en las AAPP, es decir de eliminar duplicidades, y por ello la creación y mantenimiento de servicios comunes es una necesidad. Pero también tengo serias dudas sobre su viabilidad si no existe un «modelo de negocio» que soporte estas iniciativas. Este fué el peligro que ya expresamos en este blog no hace mucho en el artículo ¿Puede morir de éxito la Administración Electrónica?.

Este punto en concreto es un tema candente. Hace poco lo comentaba Joseche en su artículo Achtung!, peligro. ¿Cuál va a ser el papel de RED.ES en los servicios TIC de la AGE?, el origen del cual es la posibilidad de que sea Red.es quien diseñe, implante y ofrezca estos servicios comunes a todas las Administraciones. En este caso se plantea una posible financiación de los servicios, acudiendo a la figura de la encomienda de gestión. Puede opinarse si es una mejor o peor idea, pero la alternativa (es decir mantener el modelo de todo gratis) es para mí simplemente inviable a medio plazo y quizás también a corto plazo.

En cuanto a la posibilidad de utilizar la encomienda de gestión como herramienta que permita a cualquier órgano administrativo «contratar» el acceso y uso de esos servicios comunes, bien sea a Red.es o a otra entidad, en en cualquier caso algo que desde luego requiere un estudio en profundidad. A esos efectos, extraigo del interesante análisis La doctrina “in house providing” y las encomiendas de gestión en el ordenamiento jurídico español de Aída Mª Conde Quintano, los requisitos que debe tener toda encomienda de gestión:

a) La entidad encomendante, poder adjudicador, debe ejercer sobre su medio propio un control análogo al que puede ejercer sobre sus propios servicios.

b) La entidad encomendada (medio propio) debe, a su vez, realizar la parte esencial de su actividad con la entidad encomendante.

c) El encomendado puede ser un ente, organismo o entidad del sector público.

d) Las encomiendas de gestión han de ser de ejecución obligatoria para el encomendado, de acuerdo con instrucciones fijadas unilateralmente por el encomendante.

e) El encomendante aprobará unas tarifas en base a las cuales se calculará la retribución a percibir por el encomendado.

f) El encomendado deberá reconocer en sus estatutos o en sus normas de constitución, su condición de medio propio y servicio técnico determinando las entidades respecto de las cuales tiene esta condición y precisando el régimen de las encomiendas que se le pueden conferir.

g) El encomendado no podrá participar en licitaciones públicas convocadas por los poderes adjudicadores de los que sea medio propio, sin perjuicio de que, cuando no concurra ningún licitador, pueda encargársele la ejecución de la prestación objeto de la misma.

Categorías
Administración Electrónica

El navegador del ciudadano

Google Chrome a punto de superar a Internet Explorer
Google Chrome a punto de superar a Internet Explorer

Ya es oficial: muy pronto, a lo largo del año 2012, el navegador Google Chrome superará a Internet Explorer como herramienta más utilizada para navegar la web. Hasta el punto que por ese motivo recomiendan a Facebook desarrollar su propio navegador para luchar contra la estrategia de Google, que facilitará a sus usuarios la utilización por defecto de su red social, Google Plus.

Estamos ante una batalla más en la famosa guerra de los navegadores. La contienda empezó con el desarrollo del primer navegador, basado en Mosaic, en 1993, en los albores de Internet. Netscape Navigator fué el navegador dominante durante varios años, hasta que Microsoft contraatacó con Internet Explorer, cuya versión 4 acabó por desbancar a Netscape en 1998. La hegemonía de Explorer ha durado hasta nuestros días, aunque ahora empieza a estar amenazada seriamente.

El navegador es tan importante porque es la herramienta básica de acceso a Internet. Si hacemos un símil administrativo, diríamos que el navegador cumple la función del formulario y el bolígrafo, luego reemplazados por la máquina de escribir, que han sido usados para las relaciones formales con la Administración durante mucho tiempo. Pero hay importantes diferencias entre el papel y el bolígrafo y el navegador de internet: diferencias de carácter tecnológico y diferencias de funcionamiento que afectan a la compatibilidad, fiabilidad, rapidez y sencillez de uso para los diversos trámites, consultas y actuaciones diversas en modo electrónico que están habilitados actualmente en España en virtud de la Ley 11/2007.

Además, a diferencia del resto de medios de que dispone la Administración, el navegador del ciudadano está completamente fuera de nuestro control. Cada usuario utiliza el que prefiere, e incluso usará varios, según sus preferencias o los dispositivos que en cada momento utilice. Si la Administración Pública quiere ofrecer un buen servicio público electrónico al ciudadano, debe ser compatible con los principales navegadores utilizados, que actualmente, si hacemos caso de las estadísticas publicadas, son cuatro, por este orden: Microsoft Internet Explorer, Google Chrome, Mozilla Firefox y Apple Safari.

La compatibilidad con todos ellos puede ser fácil en determinados casos, como una simple consulta de información en modo anónimo, y bastante difícil en otros, como puede ser la realización de trámites electrónicos que precisan firma electrónica basada en certificado de clave pública. Esto es así porque las tecnologías que permiten la ejecución de código que habilita el trámite son diversas (ActiveX, Java, …) y muchas veces están ligadas al sistema operativo subyacente sobre el que se ejecuta el navegador (Windows, Linux, OSX,…)

De modo que la maximización de la compatibilidad con el navegador del ciudadano va a requerir, o bien un enorme esfuerzo tecnológico de desarrollo, validación, explotación, y soporte de todas las plataformas y sus diversas combinaciones, o bien una simplificación generalizada de la tecnología que permita compatibilizar con todos ellos en base a una factorización tecnológica.

Así por ejemplo, pensemos que la utilización de tecnologías de firma electrónica basadas en certificados de clave pública (eDNI, Ceres, …) son muy seguras, pero también complicadas y costosas. Puede ser que su uso esté justificado en determinados trámites, cuyo impacto potencial, económico o jurídico, lo precise. Pero quizás haya una gran mayoría de trámites para los que puedan tener validez tecnologías más simples, como el tradicional usuario/password, o el uso de claves concertadas, complementado si queremos con un tercer medio de verificación, como el SMS al móvil con un código temporal de un solo uso, que es la operativa utilizada actualmente por la mayoría de los bancos. De especial interés es la reciente Resolución de 17 de noviembre de 2011 de la AEAT, por la que se aprueban sistemas de identificación y autenticación distintos de la firma electrónica avanzada, que es un buen ejemplo de cómo podemos aplicar el principio de proporcionalidad entre los medios y los fines, simplificando la vida a todos, administración y ciudadano, cuando no sean imprescindible aplicar medidas de muy elevada seguridad.

Por otra parte, la estadística de navegadores señalada anteriormente ofrece un dato curioso, que es el alto grado de utilización de Safari, el navegador de Apple. Si los MAC representan menos del 8% del total de ordenadores en el mundo, ¿cómo es posible que su navegador supere el 13% de uso en la red?

La respuesta es que se debe a que Safari es el navegador usado también en los dispositivos móviles de Apple: iPOD, iPAD e iPHONE. Según Deloitte , en 2011 la venta de Tablets + Smartphone habría superado a la venta de PC. Lo cual nos lleva a la siguiente pregunta: ¿Está la Administración Electrónica preparada para dar servicio en movilidad?.

La Administración Electrónica en movilidad es un tema desde luego complejo, ya que no sólo hay que tener en cuenta el navegador y el sistema operativo, además hay que considerar las características del dispositivo (no es lo mismo un smartphone que un tablet), así como la plataforma de movilidad, de las que habrá que soportar las principales que se utilizan hoy día. Además, no debemos olvidar que los modos de uso de estos dispositivos no son los mismos que los del PC de escritorio. Para algunas cosas usamos uno, para otras cosas otro, y para otras, ambos.

eAdmon: Todos los servicios en tu manoEstamos empezando este camino también, pero cabe duda de que tendremos que recorrerlo hasta el final. Por eso son muy interesantes las iniciativas a seguir como el desarrollo de la aplicación «eAdmon, servicios en tu mano«, disponible para plataformas Android e iOS.

Categorías
Administración Electrónica Tecnologías de la Información

Planificando y Diseñando el Almacenamiento Corporativo en las AAPP

¿Qué es el almacenamiento corporativo?

El almacenamiento es una de esas tres variables fundamentales que se manejan en las infraestructuras de todo servicio TI. Las otras dos son, por supuesto, el procesamiento y las comunicaciones. El almacenamiento es esencial en tanto en cuanto contiene la información, nuestra información, la información de la organización a la que pertenecemos. Sin información no hay TI. Por lo tanto el almacenamiento es necesario para contener esa información, de forma que pueda ser procesada y transmitida a los lugares donde debe ser utilizada.

Podremos definir el almacenamiento corporativo como el espacio que se destina a almacenar la información corporativa, la cual es, primariamente los datos relacionados con el funcionamiento del negocio: ficheros en formatos variados (PDF, DOC, Audio, Vídeo, etc.), información estructurada almacenada normalmente en bases de datos relacionales, aunque también a veces en simples tablas Excel, e información no estructurada, que puede estar almacenada en sitios como por ejemplo los buzones de correo electrónico.

Existen ciertos datos que podríamos considerar en principio que no son información corporativa, como por ejemplo los sistemas operativos y aplicaciones que residen en los servidores y en los ordenadores personales (dispositivos móviles incluidos) de la organización. Si lo son o no dependerá de cuánto estén ligados a los datos que manejan, es decir, si son absolutamente necesarios para acceder y procesar la información corporativa, o la información puede accederse desde otros sistemas compatibles. En principio estos datos no los vamos a considerar parte de la información corporativa, aunque hay algunos matices, que son de detalle y no abordaremos aquí.

También vamos a considerar que la información de usuario almacenada en los PC no es parte de la información corporativa per se, en el supuesto de que la organización dispondrá de políticas que evitan que la información de negocio resida en este tipo de dispositivos.

Dada la importancia del almacenamiento, es conveniente que cada organización disponga de su propio Plan o Proyecto de Almacenamiento Corporativo, en el cual, como en todo proyecto TI debe pasar por una fase de análisis, una de diseño, y una de ejecución, procediendo periódicamente a realizar procesos de revisión y adaptación tanto a las necesidades del negocio como a la optimización de los costes y recursos necesarios.

El problema del crecimiento desmesurado

Según estudios de IDC, la tasa de crecimiento anual de toda la información digital generada, capturada y replicada en 2009 fué un 60% superior a la del año anterior. Y se espera que el tamaño de la información en 2020 sea 44 veces la de 2009, alcanzando 35 Zettabytes.

Los motivos de esta explosión de datos son diversos, pero concurrentes: el número de dispositivos digitales que generan información aumenta constantemente, sobre todo los dispositivos móviles, que actualmente ya superan en número a los PC; también se espera una explosión de dispositivos no atendidos inteligentes, los cuales a su vez generan cada vez más información, y en ambos casos información que consiste en muchos ficheros no excesivamente grandes, y con contenidos poco estructurados. Por otro lado los ficheros de audio y vídeo generados por los usuarios son cada vez de mayor tamaño porque se generan y almacenan con mayor calidad; y para terminar, es necesario conservar todo lo existente (¿quién toma la decisión de que algo se puede borrar?), que se añade a lo nuevo.

El enorme crecimiento de toda esta masa de información genera además otros problemas y necesidades, como los sistemas de indexado y búsqueda que nos permitan analizar y encontrar la información deseada (BIG DATA), y las necesidades de protección de la información (privacidad, confidencialidad, autenticidad, etc.)

A estas circunstancias, conocidas desde hace tiempo, se añade un hecho nuevo: los presupuestos disponibles para las unidades de TI son cada vez más ajustados, particularmente en el caso de las Administraciones Públicas. Como consecuencia, si la tasa de crecimiento de la información generada es del 60%, la tasa de crecimiento de los sistemas de almacenamiento es inferior, a pesar de que el precio por TB es constantemente decreciente. Según estimaciones de IDC, en 2020, el 60% de la información generada no podrá almacenarse, pues no existirá espacio de almacenamiento suficiente.

¿Cómo abordar este problema?. Desde luego ya no es posible mantener una política de crecimiento vegetativo del almacenamiento corporativo, aprovisionando el espacio a medida que se vaya necesitando, sino que habrá que establecer un conjunto de políticas que hagan uso de las tecnologías y servicios disponibles para maximizar el espacio disponible para los servicios de almacenamiento y recuperación, al tiempo que minimizamos el coste. Para ello es imperativo diseñar y aplicar nuestro Plan de Almacenamiento Corporativo.

¿De qué estamos hablando?. Dame un ejemplo.

Supongamos el siguiente caso:

Un archivo histórico tiene un conjunto de documentos (unos 10.000) de bastante antiguedad (algunos de más de 100 años) que son consultados con cierta frecuencia para fines de investigación. Cada documento tiene una media de unas 10 páginas, que se componen de texto manuscrito y algunos gráficos. Se pretende digitalizar los documentos, de forma que puedan ser consultados electrónicamente por los investigadores, evitando de este modo su deterioro. También se pretende publicar algunos los documentos en la web, en resolución reducida, en la página del museo histórico de la entidad, así como su venta en la tienda electrónica, en formato de alta calidad, a posibles interesados.

Analicemos el problema en términos de almacenamiento. En primer lugar, estamos hablando de unas 100.000 páginas de información, que han de digitalizarse y almacenarse en modo imagen para su posterior procesamiento.

¿Cuánto espacio ocupará toda esta información?. En primer lugar, las DIRECTRICES PARA PROYECTOS DE DIGITALIZACIÓN del Ministerio de Cultura (2002) recomiendan almacenar los archivos originales en formato TIFF sin compresión, aunque no ofrece orientación sobre la resolución (DPI) a utilizar. En cambio, la Norma Técnica de Interoperabilidad de Digitalización de Documentos indica que la resolución mínima a emplear será de 200 píxeles por pulgada. Sin embargo, en este caso, al tratarse de documentos manuscritos y dibujos a mano alzada, se ha optado, para asegurar la legibilidad y la conservación de los detalles, digitalizar a 300 DPI. El tamaño de una página DIN-A4 digitalizada a 300 DPI y 24 bits por punto es de unos 25 Megabytes.

Tenemos que prever por tanto al menos 100.000 x 25 MB = 2,5 Terabytes de espacio para las imágenes originales. También hay que almacenar las imágenes procesadas, y puesto que los ratio de compresión superan fácilmente 10:1 supondremos que bastará con 250 Gbytes. Y además necesitamos espacio para la base de datos donde catalogar e indexar toda la información. En total, podemos calcular que el espacio aproximado necesario es de unos 3 Tb.

Si almacenamos toda esta información en nuestra SAN corporativa replicada de altas prestaciones, cuyos precios por TB rondan los 10.000 euros, el precio del almacenamiento necesario para este proyecto puede alcanzar los 30.000 euros. ¿Está justificado?. Quizás no. Pero, ¿es necesario usar una calidad de almacenamiento tan alta para toda la información utilizada en este proyecto?. Lo sensato es categorizar la información según sus características y tipo de utilización, y luego utilizar el tipo de almacenamiento apropiado para cada caso.

Así, por ejemplo, una solución podría ser la siguiente:

Información Almacenamiento (TB) Tipo de almacenamiento Coste/TB Coste total
BBDD 0,1 Premium 10.000,00 € 1.000,00 €
Imágenes procesadas 0,25 Standard 2.000,00 € 500,00 €
Imágenes originales 2,5 Low Cost 200,00 € 500,00 €
TOTAL 2.000,00 €

¿Porqué hemos realizado estas elecciones?

  1. La base de datos precisa un sistema de almacenamiento que sea de altas prestaciones (discos FC o discos de estado sólido SSD), no sólo para las funciones propias de utilización y gestión de los expedientes, sino porque la información contenida está enlazada con otros sistemas corporativos a través de Web Services. Además, precisa de alta disponibilidad pues está integrado en el sistema corporativo replicado en un nodo lejano que asegura la continuidad del negocio.
  2. Las imágenes procesadas se acceden regularmente por los usuarios y por varios sistemas enlazados. No obstante, los tiempos de acceso no son críticos, se espera disponer del archivo en cuestión de segundos, por lo que podemos usar discos SATA, más baratos, aunque si precisa redundancia RAID para cubrir posibles averías. No se precisa replicación en vivo ya que la recuperación frente a desastres se realiza mediante restauración de las copias de seguridad.
  3. Las imágenes originales se generan una vez y se almacenan, y se recuperan muy raramente. Los tiempos de acceso admisibles son los de tratamiento manual: se miden en minutos. Esto nos permite acudir a almacenamiento terciario (DVD/cintas DLT) o bien a servicios de almacenamiento en la nube privada, en su caso.

Al realizar este escalado de almacenamiento, basado en la categorización de la información, hemos conseguido pasar de un coste de almacenamiento inicial de 30.000 euros a unos 2.000, es decir, hemos dividido por 15 el coste.

Lógicamente, no es un análisis en profundidad. No hemos entrado en los necesarios recursos de gestión y administración, ni en los costes de mantenimiento. Las interrelaciones con otros sistemas no se han analizado, aunque todo ello sí debería entrar en un estudio de caso real.

Diseñando el Plan de Almacenamiento Corporativo

Así pues, para el diseño del plan seguiremos los siguientes pasos:

  1. Recopilación de la información sobre los diversos tipos de información de que dispone la organización, sus características, su tamaño, su propietario, y sus usuarios.
  2. Categorización de la información en términos de valor para el negocio, evaluando aspectos como el rendimiento, disponibilidad, rendimiento, confidencialidad, siempre en colaboración y de acuerdo con el propietario de la información. Puede resultar de gran ayuda aplicar, donde se pueda, el Esquema Nacional de Seguridad.
  3. Análisis de las alternativas de almacenamiento para cada tipo de información, partiendo siempre de las infraestructuras disponibles y del presupuesto, así como de las prioridades establecidas por el negocio para los diversos sistemas de información y servicios TI.
  4. Diseño del plan, que especificará las soluciones adoptadas para cada tipo, su evolución a lo largo del tiempo, el diseño de los servicios de almacenamiento, de las medidas específicas de seguridad, confidencialidad, disponibilidad, rendimiento, la interoperabilidad interna y externa necesaria para la información (Ficheros de cada tipo, BBDD, webservices, etc.). El diseño debe contemplar también las políticas de copias de seguridad y retención de la información, las políticas de borrado y eliminación, y las medidas necesarias para la cobertura de los Planes de Contingencias y la Continuidad del Servicio.
  5. Implantación del plan por fases (podrían coincidir con anualidades), incluida la contratación o adquisición de infraestructuras (HW y SW) o servicios, la implantación de los mismos, la puesta en servicio, la obtención de metricas para la evaluación del funcionamiento y la resolución de incidencias y problemas que pudieran surgir.
  6. Y por supuesto la Revisión periódica del plan, comparando los resultados esperados con los obtenidos, revisando los requisitos cambiantes del negocio y la evolución de las soluciones de almacenamiento disponibles en el mercado, así como los presupuestos disponibles.

¿Qué nos depara el futuro?

Hemos planteado aquí el desarrollo de un Plan de Almacenamiento Corporativo de corte bastante clásico que debería tener una vigencia aproximada de una legislatura, es decir, unos cuatro años. Sin embargo, existen cuestiones a medio y largo plazo que pueden incidir en nuestro plan, obligándonos a revisarlo o cambiarlo. Entre ellas pueden estar:

  • Evolución de las soluciones tecnológicas: Las necesidades de almacenamiento están produciendo una constante evolución de las soluciones tecnológicas disponibles, muchas de ellas ya ofertadas, como el aprovisionameinto dinámico, la deduplicación on-line, la estratificación automática en función de parámetros configurables, la virtualización en todo o en parte de los sistemas, etc. Es obvio que los diseños de soluciones de almacenamiento de un momento concreto pueden resultar obsoletos poco tiempo después si surgen innovaciones tecnológicas rompedoras, y por ello el Plan debe estar también en fase de contínua adaptación tecnológica.
  • Evolución de los servicios de almacenamiento: como contrapartida o alternativa a las soluciones de almacenamiento autogestionadas, surgen cada vez con más fuerza los servicios de almacenamiento «en la nube»,  bien sean en «nube pública» o en «nube privada». Con independencia de que estas soluciones tienen todavía una aplicabilidad muy limitada para las necesidades de almacenamiento corporativo en las AAPP, la intensa presión hacia la reducción de costes y del presupuesto hará que estas soluciones cobren cada vez más importancia. Habrá que estudiar su aplicación siempre que sea posible manteniendo los objetivos y requisitos de negocio y sin comprometer las funciones esenciales que deben realizar las AAPP.
  • Modificaciones organizativas, que podrían producir o habilitar iniciativas como una hipotética Concentración de CPD de la AGE: Si en algún momento el Gobierno decide acometer este proyecto, lógicamente el Plan de Almacenamiento debería ocupar un lugar principal, y para su diseño se debería contar con las potenciales unidades u organismos usuarios del mismo.
Categorías
Administración Electrónica

El proyecto Alfa: ¿qué podemos aprender?

La OEPM presenta la candidatura del proyecto Alfa a los premios ASLAN 2012. La documentación que acompaña al proyecto es el artículo que escribimos para su presentación al Tecnimap 2010, titulado «El proyecto ALFA – Gestión de invenciones de la Oficina Española de Patentes y Marcas«. Este documento se escribió a principios de 2010, hace casi ya dos años. Han cambiado cosas importantes, entre ellas, que el sistema ha sido puesto en marcha y lleva ya funcionando más de un año. Por ello, como revisión del desarrollo de las etapas finales de la concepción y las iniciales de su alumbramiento, me he decidido a escribir este artículo.

Érase una vez…

El sistema Alfa se concibió para reeemplazar el anterior sistema de información operativo en la OEPM para la Gestión de Invenciones: SITADIN. Este sistema databa de mediados de los 80, y se desarrolló sobre una plataforma Bull GCOS8 y fué programado principalmente en COBOL y PACBASE. 25 años son una vida larga para un sistema de información. Cuanto un sistema de información tiene tal edad, suceden varias cosas un tanto inusuales, sobre todo para los que estamos acostumbrados de cambiar de sistema operativo cada 5 años:

  • Muchos usuarios han crecido con el sistema. Por tanto han adaptado su mente al funcionamiento del sistema. Querrán que el nuevo sistema funcione «como el antiguo».
  • Los constructores iniciales del sistema puede que ya no estén con nosotros. Parte del conocimiento necesario para entender su funcionamiento ya no lo tenemos, o es muy difícil de extraer de las miles y miles de líneas de código.
  • Los nuevos sistemas han ido creciendo a su alrededor, como una especie de capas tecnológicas estratigráficas sucesivas, parecidas a las que vemos en las excavaciones arqueológicas.
  • La interrelación y comunicación entre el antiguo sistema y los nuevos se realizó con los medios disponibles en la época, en muchos casos manuales, en otros por los clásicos procesos Batch. La integración on-line de los procesos ha llegado mucho más recientemente. A pesar de ello, las necesidades de comunicación e intercambio de datos han aumentado fuertemente en la última década.

Hay que reconocer que las circunstancias hacen que la elaboración de un proyecto de estas características es sin duda costosa. A la dificultad técnica de tratar de emular funciones antiguas con nuevos sistemas, se añade la dificultad cultural la resistencia al cambio. Quizás ello explica que el proyecto Alfa no fué el primer intento de modernizar el sistema de gestión de Invenciones. Hubo otros intentos antes, pero fracasaron. Solamente cuando se convenció todo el mundo de la necesidad de reemplazarlo, cuando apareció la urgencia del cambio, fue posible acometerlo con éxito.

El diseño de la transición

Una cuestión importante es el diseño de la transición. Generalmente, hay dos aproximaciones a la transición. La primera es una transición progresiva, con los dos sistemas solapándose en el tiempo, y trasladando progresivamente las funcionalidades del antiguo al nuevo, hasta que toda la funcionalidad está transferida. La segunda es la denominda comunmente migración, en la que el antiguo sistema permanece completamente operativo hasta que el día D se detiene el servicio, se realiza una migración de los datos existentes al nuevo sistema, y una vez finalizada se arranca el nuevo. En Alfa se optó por esta segunda opción.

Generalmente, la transición progresiva es menos arriesgada, permite una mejor acomodación de los usuarios al nuevo sistema, permite arreglar posibles desperfectos y funcionalidades a medida que se avanza, y tiene una más fácil vuelta atrás, en caso de problemas graves. Sin embargo, no siempre es posible, por problemas de compatibilidad técnica. También es más cara y requiere más recursos, pues supone mantener durante un tiempo ambos sistemas en marcha, así como los subsistemas que sincronizan los datos entre ambos, que luego además serán descartados una vez finalizada la transición.

La migración «de una vez» tiene por contra la ventaja de que es más rápida, necesita menos recursos, por lo que es más barata, y reduce el peligro de una vuelta atrás por presiones de los usuarios a los que no les gusta el nuevo sistema. Sin embargo es más arriesgada; requerirá por lo tanto de un mayor y más intenso periodo de pruebas; no será posible probar en real el sistema antes de su entrada en explotación, porque de manera inevitable algunas cosas no se podrán probar bien, y surgirán errores y problemas que habrá que corregir después, con el sistema ya en marcha.

La integración

El sistema de Gestión de Invenciones constituye uno de los dos núcleos de negocio de la OEPM (el otro es la gestión de Signos Distintivos) y fué el primero en automatizarse. Como vimos antes, los sistemas periféricos, al principio manuales, fueron automatizándose también, pero con un bajo nivel de integración, muchas veces manual. De hecho, uno de los principales objetivos de Alfa era lograr esa integración de los sistemas de información y por tanto de los procesos, obteniendo netas ventajas des de el punto de vista de la calidad de la información, y de la agilidad de los procesos, lo que redunda entre otros en el acortamiento de los plazos que la OEPM logra en la tramitación de las solicitudes. La integración también ha permitido simplificar y acortar la publicación del BOPI, eliminando la necesidad de un postprocesado de la información que, anteriormente a Alfa, se contrataba externamente, con el consiguiente ahorro.

Pero la integración no es fácil. De hecho, durante la fase de desarrollo, y debido a dificultad o incluso inexistencia en algunos casos de plataformas de preexplotación de los sistemas con los que se había de integrar, y en otros de la carencia o inmadurez de estándares en los interfaces, los desarrollos se hicieron sobre interfaces simulados. Eso permitió avanzar a buen ritmo las labores de desarrollo, pero retrasó notablemente la última fase del proyecto, la fase de integración. En algunos casos, ni siquiera estuvo claro, hasta fases muy avanzadas del proyecto, el reparto de funciones a ambos lados del interfaz.

Otro problema derivado es que finalmente no se han logrado todavía definir de forma estandar y unívoca todos los interfaces. Esto hace, por ejemplo, que existan diferentes formatos para intercomunicar unos y otros sistemas con Alfa, aunque intercambien la misma información.

De modo que, para mí, la moraleja es clara: los interfaces son una parte integral de un proyecto ya desde el principio, al igual que es el diseño funcional. No podemos minimizar ni tampoco dejar de definir, diseñar y probar los interfaces para el final del proyecto, so pena de encontrarnos con retrasos inesperados, sobrecostes y problemas de interoperabilidad que pueden persistir mucho tiempo después de que el sistema ha entrado en explotación.

Los usuarios y las especificaciones funcionales

Cuando un proyecto como éste se extiende durante tanto tiempo, se parte de unas especificaciones, más o menos definidas, con las que se diseña. Pero es inevitable que los requisitos iniciales vayan cambiando, del mismo modo que avanza la tecnología. Esto, si no es que aparecen cambios normativos de obligado cumplimiento, como fué la ley 11/2007.

Otra cosa que también sucede es que es muy dificil conseguir de los usuarios una especificación definida y detallada. Incluso cuando se consigue, puede suceder también que la interpretación no era la correcta. También sucede que determinados usuarios (determinado perfil de usuario) tiene unas necesidades, y otros tipos de usuario tienen otras, que no siendo incompatibles con las anteriores, complican sin embargo el trabajo de diseño y de poner la aplicación «al gusto de todos». Por ello, siempre que sea posible, es preferible diseñar sistemas con un ciclo de vida corto, lo cual permite poner en marcha unas primeras funcionalidades mínimas, que posteriormente se irán refinando, mejorando y ampliando.

Pero esto es relativamente fácil para un sistema nuevo; no es tan fácil para un sistema, como Alfa, que reemplaza a un sistema anterior. Esta sería una de las consideraciones que habrá que tener en cuenta, también, cuando se decide el modelo de transición comentado anteriormente.

La parametrización

Muy relacionado con el asunto anterior está la capacidad de parametrización. Suele ser el gran olvidado en el diseño, quizás porque cuando se diseña con unas especificaciones dadas se piensa que todo va a ser así siempre, que es obvio. Uno de los ejemplos más evidentes es el logotipo. Si se diseña Alfa para la OEPM, que es dependiente del Ministerio de Industria, Turismo y Comercio, no es frecuente pensar que cualquier día ese Ministerio se extinga, y se reemplace por otro denominado Ministerio de Industria, Energía y Turismo. Suena parecido, pero no es igual.

La existencia de una función de parametrización de estos datos facilita muy grandemente los cambios, ya no solo por el tiempo que se tarda, los cortes de servicio que se ahorran, sino porque si no está parametrizado, seguramente habrá que hacer una labor «de chinos» revisando todo el código a ver donde se llama al logotipo, o al texto «Ministerio de Industria, Turismo y Comercio» para reemplazarlo por su nuevo equivalente. Y eso contando con que aún tenemos al programador que codificó el sistema, pues si es al cabo de 10 años, ¿quién sabe dónde andará?. Lo mismo podemos decir de los cambios en las plantillas de documentos, los cambios en el diseño de los flujos de trabajo, etc. todo lo que sea configurable mejora sin duda el sistema a largo plazo.

La testeabilidad

Me atrevo a utilizar este palabro (en lugar de «probabilidad» que no es aplicable en este caso, y la que sería aplicable «comprobabilidad» no existe en el diccionario RAE) para indicar la capacidad de ser probado de un sistema. La testeabilidad implica que en el diseño se tengan en cuenta las necesidades que tiene el sistema de ser probado para ver si cumple las especificaciones, tanto funcionales como operativas, así como para, durante su fase de explotación, para obtener indicadores internos que arrojen los parámetros importantes para el negocio, de forma que permita evaluar su correcto funcionamiento sin necesidad de llamar continuamente al que lo diseñó para que lo pruebe.

Al igual que los interfaces, la testeabilidad (también se oye testabilidad) no se pueden dejar para el final. Tienen que abordarse desde las fases iniciales del diseño. Eso implica que los ingenieros de pruebas tienen que participar en las fases iniciales del proyecto. Es probable que parezca que los requisitos que se imponen adicionalmente a los de diseño funcional sean un plus innecesario, o que se puedan dejar para el momento en que el sistema va a ser pasado a explotación.

Sin embargo, como en el caso de la integración, no es fácil, y a veces incluso imposible, añadir estas funcionalidades al final. Y si el sistema no es adecuadamente comprobable, será muy dificil verificarlo, por lo que las pruebas serán más costosas, y además no lo probaremos totalmente, por lo que una serie de fallos subsistirán cuando el sistema esté en producción.

Y del mismo modo, hay que prever los indicadores y variables que vamos a querer obtener del sistema (por ejemplo las longitud de las colas de trabajo en los procedimientos, para detectar los cuellos de botella) pues tan importante como que el sistema funcione es tener indicadores de cómo está funcionando. Si no tenemos los indicadores apropiados es como si conducimos un coche sin tablero de mandos.

La seguridad

No podemos hablar de un proyecto como éste sin hablar de la seguridad… pero no creáis que voy a decir en público como esta diseñada e implantada la seguridad de Alfa. Todo lo que diré por el momento es que me parece adecuada a las necesidades del sistema.

No obstante, si quiero abordar un par de puntos importantes sobre la seguridad. El primero se refiere al error común de creer que porque un sistema es sólo de uso interno, ya está suficientemente protegido por la seguridad perimetral. Alfa es un sistema de trastienda (backoffice) y no es accesible desde el exterior. Podríamos creer que con eso hemos reducido en su inmensa mayor parte los problemas de seguridad, pero es un error. Entre el 60% y el 80% de los incidentes de seguridad en las organizaciones provienen de usuarios internos, según el Computer Security Institute (CSI) de San Francisco.

Lo cual nos lleva al segundo asunto importante de la seguridad: está en manos de los usuarios. Servirá de poco todos los mecanismos de control que pongamos, si los usuarios no los utilizan y colaboran activamente. E igualmente de los directivos, quienes tienen que asumir, cada uno en las áreas de negocio que les competa, que la seguridad no es responsabilidad de TI, sino de todos y cada uno de los empleados, y tienen que transmitírselo directamente a las personas a su cargo.  De modo que, en seguridad, las palabras más importantes son: formación y concienciación.

Planificando el final

Finalmente, hay algo que raramente se contempla, y es la fase final de un sistema en explotación. Su extinción o traslado a otro sistema. Porque es inevitable que ningún sistema, por bueno que sea, va a durar eternamente. Especialmente importante es la elaboración de utilidades de exportación de todos los datos en los formatos estándares (por ej. XML) que permitan su importación en otro sistema distinto, junto con la documentación necesaria para entender y explotar esta información.

En fin, en todo proyecto se aprende algo, espero que estas ideas sacadas de un proyecto felizmente en explotación pero con extremos mejorables sean útiles para nuestros lectores. Si habéis llegado hasta aquí, y os ha servido para algo, quizás os apetezca 😉  votarnos a los premios ASLAN (en la categoría Administración Central)… y poder recuperar fuerzas para seguir adelante.

Categorías
Administración Electrónica Mejora de la Administración

Una nube para la Administración General del Estado

El viernes pasado por la mañana, y gracias a una invitación que, a través de Twitter, nos llegó de Pepe Olalla, CIO del BBVA, celebramos una reunión «conspirativa» según el calificativo de @Mitinman:

Eso se llama conspiración RT: @carlos2mar: Reunido con @PepeOlalla, @raquelponcela, @feserdel y J. Viñuales hablado de #Infraestructuras

La reunión tenía por objeto conocer de primera mano el proyecto de BBVA (BBVA se sube a la nube de Google) para dotar a todos sus empleados de un conjunto de servicios horizontales estándar basad0s en el modelo SAAS (Software como Servicio) contratando para ello la oferta de Google Apps for Business.

¿Porqué tres funcionarios de a pie se interesan por este proyecto de un banco?. Lógicamente, no se trata de mera curiosidad científica. El hecho es que las características de este proyecto tienen un gran paralelismo con la situación en la AGE. Entre ellas:

  • Dimensión: BBVA prestará servicios por medio de este proyecto a 110.000 empleados. La AGE tiene actualmente del orden de 250.000 empleados, si se excluyen las fuerzas y cuerpos de seguridad del estado.
  • Naturaleza de su actividad: Por la naturaleza de sus actividades, un banco trabaja primariamente con la información. Del mismo modo, gran parte de la actividad de la AGE se apoya o pertenece al ámbito de la gestión de la información, ahora que los servicios más pegados al terreno están transferidos a las CCAA y EELL
  • Situación de partida: La situación tecnológica y organizativa del BBVA tiene también paralelismo con la de la AGE, aunque por diferentes motivos. En el BBVA se origina en su carácter de empresa global, por lo que su presencia en cada país configura un nodo de actividad con relativa independencia. En la AGE, esos nodos de actividad se estructuran en torno a los Ministerios (actualmente 13).

Por supuesto, hay importantes diferencias, pero de eso hablaremos más tarde.

¿Porqué adopta BBVA esta solución?. En primer lugar, lo que se persigue es un aumento de la productividad de sus empleados con el menor coste y en el menor plazo posible. En segundo lugar (aunque quizás debería ser el primero) se busca no sólo una optimización sino una transformación de la forma de gestionar el negocio, según figura en la nota de prensa del BBVA:

La nueva intranet global de BBVA es el proyecto principal que va a potenciar y transformar el uso de todos los entornos colaborativos de Google. Así, pasa de  ser un espacio corporativo de comunicación y de procesos de gestión interna a convertirse en el lugar común de trabajo de todos los empleados donde compartir, colaborar y gestionar el conocimiento de forma global. Además, se creará la primera red social de empleados BBVA, que mejorará la comunicación y explorará nuevas formas de trabajo.

Lo que buscamos es apoyarnos en la tecnología, no sólo para hacer las cosas más rápido, sino de forma totalmente diferente a como se hacían hasta ahora”, afirma José Olalla, CIO (Chief Information Officer) de BBVA. “La suite de Google, integrada con nuestras herramientas de colaboración propias, nos permitirá poner en marcha una nueva forma de trabajo, en la que el empleado tendrá toda su información a un clic, independientemente del lugar donde esté, ofreciéndole posibilidades de colaboración muy avanzadas”.

Hay una serie de características que distinguen la solución adoptada y que son cruciales para justificar la elección:

  • Ubicuidad: el acceso a los servicios está disponible desde cualquier terminal: PC, SmartPhone (iPhone incluido), Tablet (iPad incluído), …. Se puede usar en cualquier momento y lugar en el que exista una conexión a Internet/Intranet.
  • Inmediatez: El despliegue de la solución es muy rápido, no requiere reformas o adaptaciones de los sistemas existentes, y el periodo de formación y adaptación de los usuarios es muy corto, pues muchos de ellos ya conocen y usan las herramientas de Google
  • Flexibilidad: una de las características más interesante del SAAS es que el servicio y el cliente está constantemente actualizado de forma completamente transparente. Las nuevas versiones aparecen automáticamente al usuario cuando están disponibles, generalmente con la opción de «seguir con la versión antigua» si en ese momento tenemos prisa y no queremos aprender la nueva funcionalidad.
  • Seguridad: Los servicios contratados se acogen a la legislación sobre protección de datos española y europea mediante el acuerdo de «Puerto Seguro» (Safe Harbor) a la cual está actualmente adherido Google. Para proceder a implementar este proyecto, el BBVA ha recibido la autorización del Banco de España, como es preceptivo.
  • Y, por supuesto, Coste. Diversos estudios fijan en torno a los 100 dólares por año el coste de cada buzón de correo corporativo cuando se implementa con medios propios, pero para volúmenes de usuarios a partir de 10.000. Sin embargo, si el número de usuarios desciende por debajo de 10.000, los costes aumentan rápidamente. Así, para 100 usuarios un estudio calcula un precio de más de 300 dólares al año. Frente a ello, la solución de correo corporativo de Google tiene un coste de alrededor de 40 € por usuario y año.
  • Y no olvidemos que esta solución no es sólo correo. Incluye también todas las herramientas de ofimática en línea de Google: Documentos, Hoja de cálculo, Presentaciones. A la hora de comparar costes, debemos poner en el debe de la solución in-house el coste de adquisicion y amortización de las herramientas ofimáticas usadas en la casa. Por no hablar también de otras posibilidades como el chat, audio y video conferencia en línea incluidas en la solución.

De modo que, sin entrar en detalles de las opciones manejadas por el BBVA para su elección, parece que ésta está basada en sólidos argumentos, está bien diseñada, no sólo desde el punto de vista tecnológico y económico, sino también desde el punto de vista cultural, con una adecuada planificación en fases, la formación y soporte a los usuarios, y la gestión de los servicios.

¿Cómo podemos aplicar esta solución en la AGE?

Actualmente, la AGE parte de una situación en la cual existen múltiples sistemas de correo, normalmente al menos uno por cada Ministerio, y además uno por cada Agencia u Organismo dependiente. Desgraciadamente, no disponemos de informes analíticos del coste de estos servicios en la AGE. Sin embargo, según el Informe Reina 2009, en la AGE hay 330 Órganos Directivos que cuentan con un total de 860 Unidades Informáticas. Unos pocos superan el millar de usuarios por cada sistema de correo. La mayoría están entre 100 y 1000 usuarios por sistema, o incluso menos. Extrapolando los estudios antes mencionados, podemos suponer que el coste medio por buzón de correo en la AGE está sin duda entre 100 y 300 euros por usuario y año.

Además la solución de Google incluye el acceso a los servicios de ofimática. De nuevo tampoco hay datos pero es facil suponer que a estas cifras habría que sumar entre 50 y 100 euros/año por puesto de trabajo en concepto de compra, instalación, actualización y soporte de las herramientas ofimáticas. De modo que, económicamente, no hay muchas dudas. La adopción de una solucion única y global de correo y ofimática para toda la AGE, incluso teniendo en cuenta un coste adicional de entre 30 y 50 euros de migración y formación por buzón, permitiría reducir la factura de estos servicios entre un 50% y un 75% del coste anual anterior.

Técnicamente, el proyecto es viable. Para ello necesitamos una infraestructura de soporte, para lo que contamos con la red SARA, así como un directorio único de usuarios con interfaz LDAP, el cual actuaría como punto de validación y acceso a los servicios. Actualmente el portal funciona.es ya cumple esa función. El servicio LDAP global de la AGE ya existe, precisamente el que usa el portal funciona. De modo que el control y validación de acceso de los usuarios a los servicios ya lo tenemos resuelto.

Dada la flexibilidad y los escasos requisitos de acceso desde el punto de vista del cliente, parece que no es necesaria ninguna inversión y actividad adicional, más allá de la ya señalada de la planificación, migración y formación de los usuarios. Cualquiera de los terminales actuales usados en la AGE, PC con Windows o con Linux, teléfonos Apple o Blackberry, o Android por supuesto, cualquiera de las Tablets actuales del mercado, sirven y funcionan, y estan soportadas.

Además hay que señalar que la implantación de este proyecto no afecta para nada ni impacta en las actividades y servicios actuales de los organismos y ministerios. Las aplicaciones verticales, portales web, registros electrónicos, etc. de la AGE siguen funcionando como hasta ahora.

Son bastante claros los «beneficios colaterales» para la AGE de este proyecto:

  • Unico dominio de correo para todos los empleados, inalterable por reorganizaciones o modificaciones estructurales
  • Unico directorio de correo de todos los empleados, continuamente actualizado
  • Posibilidad de Chat o Videoconferencia instantánea, en base a los servicios de directorio, con cualquier otro empleado, sea de mi mismo organismo o de otro cualquiera.
  • Documentos colaborativos en línea: varias personas pueden trabajar al mismo tiempo desde lugares distintos sobre el mismo documento. Se evita el envío y circulación de documentos por correo electrónico. Sólo hay una versión, no varias dispersas por los buzones.
  • Un importante paso adelante para facilitar el acceso a los servicios en movilidad, así como para la implantación de servicios de teletrabajo.

Hasta aquí, las posibilidades y ventajas. Vamos a entrar ahora en las dudas y dificultades.

En primer lugar, están las cuestiones de la seguridad de la información y de la disponibilidad del servicio. Estos son las principales pegas que se pueden poner a esta solución basada en nube pública, y precisamente los principales argumentos a favor de una nube privada.

Con respecto a la seguridad de la información, ¿es suficiente con la que proporciona «Safe Harbor»?. En otras palabras, ¿podemos dormir tranquilos los responsables de informática sin saber exactamente dónde están los datos?. No soy un experto, pero parece que la cobertura legislativa de puerto seguro es o debería ser suficiente también para la aplicación de estos servicios en la Administración Pública española.

Además, la gestión, control y validación de usuarios no se externaliza: puesto que se utiliza un servicio LDAP interno de la AGE, el proveedor de servicios no podrá, aunque quiera, crear o modificar cuentas de usuario. Todo el acceso está bajo el control de los sistemas de información propios de la AGE.

Con respecto a la disponibilidad y continuidad del servicio, estamos hablando fundamentalmente de un SLA y del grado de confianza que nos ofrece la empresa proveedora del servicio de cumplir un SLA. A este respecto, no olvidemos que cualquier solución de nube privada va a depender también de los SLA que se contraten y de cómo esos SLA se aplican en la práctica. De modo que, en este aspecto, para mí, hay empate.

Existe también la cuestión del archivo y la recuperación de los datos, y, llegado el caso, de la transición del servicio a otro posible proveedor. Aquí también nos encontramos con que, tanto en las soluciones de nube privada como en las de nube pública, son cuestiones a resolver. No es que estén muy claras, pero no veo en ellas un argumento de peso a favor de una u otra solución.

Pero por otro lado, las soluciones de nube privada son por lo general más caras y más lentas de poner en marcha, y sobre todo, menos escalables. El momento en el que empiezan a ser efectivas las ventajas de la nube privada llegan mucho más tarde en el cronograma proyecto que en el caso de l nube pública, la cual resulta eficaz y es escalable desde la primera instalación. Por ello, el riesgo técnico/económico para el proyecto de adoptar una nube pública es muy inferior al de la nube privada, lo que para mi decanta definitivamente el peso de la decisión a favor de la nube pública.

Por otra parte, alguien puede temer la adopción de una solución «predefinida» en la cual no es posible adaptar la funcionalidad de las herramientas a las necesidades propias de cada organismo, o de cada tipo de trabajo. Pero estamos hablando de herramientas horizontales que, ya hoy dia, se nos entregan así. ¿Alguien, de entre los lectores, se ha puesto a solicitar una funcionalidad nueva de Outlook o de Word?. Como nos decían nuestros colegas del BBVA, «Es como cuando cambias de coche. Quizás los interruptores de las luces están en otro sitio, o a lo mejor el antiguo tenia un indicador que el nuevo no tiene. Pero tras el periodo de adaptación, sirve perfectamente para ir de un sitio a otro.»

Así que, en resumen, tenemos sobre la mesa una propuesta que es técnicamente viable, segura, que permite simplificar y al mismo tiempo mejorar los servicios TI horizontales actuales de la Administración General del Estado, ofrecer servicios nuevos no existentes hasta ahora, y al mismo tiempo conseguir unos ahorros que podrían rondar entre los 25 y los 50 millones de euros (a confirmar, obviamente, por un estudio económico más detallado) si aplicamos esta solución a los 250.000 empleados de la Administración General del Estado.

Dicho esto, no esta todo claro, ni mucho menos. Al igual que yo, muchos de vosotros tendréis dudas, y con seguridad opiniones diferentes en alguno de los aspectos considerados. Una importante cuestión, sin la cual el proyecto no es viable, y que para mí aún no está resuelta, es la organizativa. La principal diferencia entre el caso del BBVA y el de la AGE es que el primero tiene un CIO; el segundo, no. Ni siquiera tenemos un punto claro de competencias dentro de la Administración sobre el que articular el proyecto. La toma de decisiones, necesaria si queremos que el proyecto sea único, y no una amalgama de soluciones diferentes parcialmente conectadas, debe ser también única, aunque se realice compaginando lo mejor posible los intereses de todos (pero sobre todo los intereses del servicio a la Administración). Contablemente, tampoco está resuelto ni mucho menos. No sabemos muy bien cómo se repartirían e imputarían los costes. ¿Y la forma de contratación?.

En fin, para mí, la nube de la Administración es una interesante idea, pero a medida que nos acercamos a ella se parece cada vez más a una niebla. ¿Alguien tiene unos faros antiniebla para poder seguir navegando en ella?.

Categorías
Administración Electrónica

Steven VanRoekel y el #CIOAGE

A finales del pasado año, propuse el hashtag #CIOAGE como marca de idea para debatir un concepto, un concepto relacionado con una figura que debería representar un papel importante en la estructura de la nueva Administración que, algunos al menos, queremos.

En uno de los recientes debates en twitter, se ha llegado a decir por @pepsetra que «¿#CIOAGE? Ahora mismo no significa nada«. Para mí, las ideas siempre tienen un significado, y en este caso además un significado concreto. Para ilustrarlo, se me ha ocurrido trasladar a este blog las palabras de Steven VanRoekel, actualmente el CIO Federal del gobierno USA. Estas palabras están extraídas y traducidas del artículo A Year of Change in Federal IT, publicado el mes pasado en el Blog de la Casa Blanca.

Como saben los tecnólogos del sector privado, cuando el dinero es escaso, es a menudo la tecnología la que nos permite hacer más con menos. En un entorno fiscal de estrechez, las organizaciones buscan formas de aprovechar los recursos existentes y usar los últimos avances y herramientas para lograr lo que parece imposible: mejorar y expandir servicios al tiempo que rebajamos los costes. No es diferente en la Administración Federal. Para lograr el compromiso del Presidente de una Administración eficaz y eficiente, estamos aprovechando los últimos avances en tecnología para ahorrar dinero de los contribuyentes y reducir el dinero malgastado. Trabajamos con decisión para abordar el reto de hacer más con menos, y ya vemos resultados reales.

Manteniendo los proyectos TI bajo control, identificamos eficiencias y eliminamos desperdicios para entregar soluciones tecnológicas antes y a menor coste. Este año hemos llevado a cabo nuestras rigurosas sesiones de rendición de cuentas Techstat y hemos abierto el modelo, dando a las agencias las herramientas para cerrar o cambiar proyectos fallidos. Como resultado, las agencias han identificado casi mil millones de dólares de ineficiencias, alcanzando un total de eficiencias de Techstat de cuatro mil millones de dólares en dos años.

También es importante contar con la gente adecuada. Con el fin de asegurar que tenemos los gestores con experiencia y talento que tienen que supervisar estas grandes y complejas inversiones en TI y maximizar el retorno de dinero de los contribuyentes en cada paso en el proceso, hemos creado un nuevo rol para los directores de TI con requisitos más rigurosos. También hemos puesto en marcha el Programa Presidencial de Becarios en Tecnología este otoño para atraer a nuevos talentos al equipo de TI federal mediante la reducción de barreras de entrada de profesionales de TI jóvenes y con talento.

Para aprovechar al máximo las inversiones que hacemos en la tecnología, tenemos que ser más inteligentes en la forma en que gastamos nuestro dinero. Nos hemos centrado en los CPD – los devoradores de energía de los inmuebles federales que se extendieron rápidamente (e ineficientemente) en la última década. A finales de 2012, la Administración Federal ha cerrado más de 472 CPD. Y este año hemos ampliado la iniciativa para incluir los centros de datos de cualquier tamaño, con el objetivo de cerrar cerca de 1.000 centros de datos a finales de 2015.

También estamos comprando de forma más inteligente, y empezamos a aprovechar el poder de compra al por mayor de la Administración Federal para obtener los mejores precios para los contribuyentes estadounidenses. Muchas agencias, oficinas y sucursales tienen necesidades similares, y en lugar de comprar tecnología y servicios de forma separada como cientos de empresas de tamaño medio, tenemos que compartir servicios para ahorrar dinero de los impuestos. Este año pusimos en marcha primer servicio compartido para alentar a los organismos para hacer precisamente eso y hemos anunciado esta iniciativa. Durante el próximo año vamos a empujar a las agencias a buscar soluciones compartidas a través de la estrategia de servicios compartidos, que proporcionará la hoja de ruta a las agencias para hacerlo.

Hasta ahora no habíamos podido aprovechar estas herramientas para hacer más con menos. Con la política de «primero-nube» y las migraciones en la nube previstas en el Plan de Reforma de TI, el cloud computing se ha convertido en una parte integral del ADN de TI del gobierno. Con nuestra iniciativa First Cloud  las agencias han identificado 79 servicios a pasar a la nube con el fin de obtener ahorros y mejoras en el servicio. Este año, las agencias han migrado 40 servicios a la nube y fueron capaces de eliminar más del 50 sistemas heredados para ahorrar dinero de los contribuyentes al tiempo que se amplia la capacidad. Como parte de este esfuerzo, las agencias han creado seis servicios en la nube que antes no eran capaces de proporcionar. Con la posibilidad de ampliar la capacidad de un momento a otro sin tener que recurrir a nuevos servidores, agregar nuevos centros de datos, o contratar nuevo personal, la nube es la clave de la capacidad de la Administración Federal para ser flexibles a medida que cambian las necesidades.

A medida que la Administración migra a la nube, tenemos el compromiso de hacerlo de una manera que sea rentable y garantice la seguridad y fiabilidad de nuestros datos. Hasta ahora, cada agencia ha tenido que ejecutar multiples pasos que tardan entre 6 y 18 meses e incontables horas hombre para evaluar correctamente y autorizar la seguridad de un sistema antes de que se otorgue la autorización para avanzar en una transición a la nube. El manejo de cada una de estas transiciones por separado, sin un conjunto de estándares comunes y mejores prácticas, no sólo nos cuesta tiempo valioso del personal, sino que también representa una carga que puede disuadir a los contratistas de competir por nuestro negocio y malgastar millones de dólares de los contribuyentes.

Hoy, estamos lanzando el Programa Federal de Gestión de Riesgo y Autorización (FedRAMP), que cambiará fundamentalmente la forma en la nube se asegura y provisiona por la Administración Federal. FedRAMP permite a las agencias el despliegue de tecnologías cloud, mientras que aplica las eficiencias de escala para reducir sustancialmente los costos y el tiempo de transición.

Desarrollado en colaboración durante los últimos dos años con el aporte de las agencias, el Consejo de CIO y los órganos de trabajo, tales como el Comité de Gestión de la Seguridad de la Información y la Identidad (ISIMC), las Administraciones estatales y locales, el sector privado, expertos académicos y organizaciones no gubernamentales, FedRAMP presenta un enfoque de políticas innovadoras para el desarrollo de relaciones de confianza entre las agencias y proveedores de servicios cloud.

Con FedRAMP, hemos establecido un enfoque estandarizado para la evaluación de seguridad, autorización y supervisión continua de los productos y servicios cloud que  cada agencia deberá usar. Este método utiliza el marco de referencia «haz una vez, usa muchas veces» que ahorrará costes, tiempo y personal necesario para llevar a cabo evaluaciones redundantes de la seguridad para que nadie tenga que reinventar la rueda. El año pasado, las agencias gastaron cientos de millones de dólares en este tipo de actividades. Gracias a FedRAMP, el gobierno puede llegar a ahorrar entre un 30% y un 40% de estos costes cuando se utiliza una solución que ha sido sometido a FedRAMP.

Al reflexionar sobre mi primeros 120 días como CIO Federal, es asombroso contemplar todo el trabajo increíble que cada organismo ha llevado a cabo dentro del Plan de Reforma de TI y en otras partes. Tuve mucha suerte de haber entrado en una oficina con una agenda que tenía un gran impulso y socios con liderazgo que estaban impulsando reformas agresivas en cada una de sus agencias. Contamos con una gran visión de futuro de la TI Federal que se basa en estos logros, pero los elogios por los logros difíciles y numerosas que se han producido en el último año se apoyan firmemente en las manos de cada organismo, cada CIO y los miles de empleados federales que han ejecutado las reformas en el último año. Espero poder seguir construyendo sobre este conjunto de logros para permitir a nuestra Administración entregar al pueblo estadounidense de manera más eficiente y productiva.

Resumiendo:

  • En un contexto de ajuste, las TI son la solución para hacer más con menos
  • Hay que gestionar adecuadamente los proyectos TI e identificar ineficiencias
  • Selección de los mejores profesionales para la dirección de proyectos TI y reducción de las barreras de entrada de los nuevos profesionales TI
  • Consolidación de Centros de Proceso de Datos
  • Aprovechar el poder de compras al por mayor de la Administración
  • Estrategia de servicios compartidos
  • Migración a la nube: ahorrar dinero, ampliar capacidad, aumentar flexibilidad
  • Migración a la nube: gestión del riesgo y la disponibilidad mediante estandarización de procedimientos de evaluación de seguridad, autorización y supervisión.

Ya sabemos que USA no es España, que hay muchas diferencias importantes, de tamaño y posición, pero sobre todo de cultura. Que sus soluciones no tienen porqué ser las nuestras. Pero seguro que leyendo estas palabras hay muchas cosas que os suenan. Ideas que podríamos aplicar aquí si al menos hubiese una figura que las centralizase y coordinase.

CIOAGE no es una persona ni tampoco es un cargo. Es una idea organizativa, que pretende mejorar la Administración Española mediante la gestión coordinada de las TI situadas en el nivel apropiado para aprovechar verdaderamente todo su potencial.

Los Estados Unidos de América no son los únicos que tienen esta figura. Otros muchos países la tienen: Reino Unido, Francia, Canadá, Australia, Japón, Singapur, incluso países como Malta… Cuando uno se fija sólo en si mismo, muchos problemas parecen no tener solución. Pero cuando uno mira fuera, ve que otros tienen problemas parecidos, pero adoptan otros caminos para resolverlos.

¿Es el CIOAGE una solución para España?. Yo así lo creo. Pero no soy el que toma las decisiones. Hasta que el que toma las decisiones piense lo mismo, seguirá siendo sólo una propuesta. Hasta entonces…

Categorías
Administración Electrónica Mejora de la Administración

Ministerios Marca Blanca

Pasaron las elecciones, y llega el momento en el que se constituye el nuevo gobierno, debidamente aprovisionado de sus correspondientes carteras Ministeriales. Probablemente habrá unos cuantos cambios. Los hay siempre: en cada cambio de legislatura, aunque no cambie el partido gobernante, e incluso dentro de la propia legislatura.

Así pues en esta época, quien más quien menos, los trabajadores TIC de la Administración Pública empiezan a prepararse para las posibles remodelaciones. Las remodelaciones afectan a multitud de servicios básicos: nueva página web, nuevas direcciones de correo electrónico (cambia el dominio), nuevas unidades: Secretarías de estado, Subsecretarías, Subdirecciones, etc., nuevo logotipo, con lo que eso implica en papelería y cartelería, etc.

Llegados a este punto, siempre pienso lo bueno que sería tener preparados todo ese conjunto de servicios TI básicos empaquetados en forma de KIT marca blanca, a falta únicamente de aplicarle la marca concreta de cada Ministerio, para empezar a funcionar de forma eficiente y eficaz desde el primer día y al menor coste posible.

Los servicios básicos que, pienso, debería tener ese «KIT Ministerial marca blanca TI» serían:

  • Página WEB completa, basada en un gestor de contenidos estándard, con su correspondiente dominio asociado al Ministerio.
  • Sede Electrónica con su correspondiente Registro Electrónico y sistema de Notificaciones Electrónicas.
  • Correo Electrónico corporativo.
  • Directorio de la Organización, en el que se pueda configurar de forma rápida la estructura orgánica.
  • Servicios de ficheros compartidos en red, con carpetas y permisos predefinidos en función de la estructura orgánica.
  • Servicio telefónico, integrado en el directorio de la organización (tanto móviles como fijos).
  • Servicio de acceso a Internet, con sus correspondientes sistemas de proxy, filtrado, etc. y con acceso a la Red Sara.
  • Servicio de Intranet de soporte a empleados; con espacios para publicar la información necesaria para el funcionamiento interno, incluidas las plantillas de los documentos oficiales, y con su correspondiente gestión de peticiones internas, vacaciones, moscosos, etc.
  • Papelería virtual: plantillas de documentos y presentaciones con el nuevo logotipo del Ministerio.
  • Web colaborativa interna 2.0: wiki, blogs, anuncios/foros, etc.
  • Gestión económica interna, incluida la nómina.
  • Servicio de configuración automática de los escritorios de los usuarios a los nuevos servicios y estructura ministerial.
  • Servicio de soporte a usuarios, con su correspondiente CRM.
  • Y todos estos servicios, por supuesto, con sus correspondientes Medidas de Seguridad y Acuerdos de Nivel de Servicio (SLA) predefinidos.

Quizás también sería interesante un servicio de importación/exportación de usuarios, individualmente o en grupos, junto con su información asociada, que permitan mover rápidamente la información y los permisos entre organizaciones, simplificando esta operación que sin dudar se realizará con frecuencia.

Obviamente, se trata de una lista a vuelapluma. Seguro que a vosotros se os ocurre algún servicio más, pero creo que más o menos lo esencial está recogido. Está claro que se trata de servicios horizontales; los servicios puros de negocio no están ni pueden estar recogidos, pues son específicos y diversos para cada Ministerio, Secretaría de Estado, y en algunos casos hasta de una Dirección General.

Hace ahora un año escribíamos un artículo titulado «Hacia la virtualización de la Administración«. Está claro que las tecnologías de virtualización, y los servicios cloud, debidamente aplicados, podrían y deberían facilitar la creación de este Kit Ministerial Marca Blanca, el cual idealmente podría estar basado en servicios ubicados en una posible Nube Privada de la Administración.

Así por ejemplo, el acceso de los usuarios a los servicios se podría acelerar muchísimo con la adopción de una solución VDI, que estaría preconfigurada con los nuevos servicios. Esta solución además proporciona una característica muy deseable de ubicuidad, pues los funcionarios pueden trabajar en su nuevo ministerio sin levantarse de la silla, únicamente conectandose mediante su cliente de escritorio remoto a los servicios «marca blanca» de su nuevo Ministerio.

De este modo accedemos a otro importante ahorro derivado de la eliminación de la necesidad de los traslados habituales del personal, junto con sus enseres, muebles, sillas, ordenadores, documentos y archivos, que se suelen hacer habitualmente para «juntar» a las personas que trabajan en el nuevo Ministerio.

También podemos tener una importante ventaja desde el punto de vista de la disponibilidad y continuidad del servicio, si diseñamos adecuadamente el sistema de forma redundante, permitiría al personal seguir trabajando incluso en caso de desastre (incendio, inundación) o incidencia grave (obras, traslados) que les impida acudir a su centro de trabajo habitual.

Por último y para terminar la creación de estos servicios sin dudarlo permitirá ofrecer una imagen de funcionalidad, modernidad y eficacia, pero al mismo tiempo de austeridad por los ahorros que se logran, al nuevo gobierno elegido por las urnas.

Categorías
Administración Electrónica Mejora de la Administración

El papel de las Tecnologías de la Información en la Administración Pública

En un artículo anterior preguntábamos si puede morir de éxito la Administración Electrónica. En otras palabras, si es sostenible un crecimiento contínuo de los servicios TI internos y externos de las Administraciones, con un constante decrecimiento de los fondos y recursos que la soporta.

Desde luego, la respuesta no es fácil. Lo sé. Una aproximación lineal al problema nos lleva sin dudarlo a la catástrofe. Por eso, es necesario pensar en otros términos. Para encontrar líneas de solución a la pregunta, no tenemos más remedio que dedicarnos a pensar fuera de la caja.

Para ello, haremos un poco de historia.

Entré en la Administración en el año 1993. A mi llegada al Ministerio de Industria, bastante avanzado para la época, cada funcionario tenía un ordenador con Windows 3.11, conectado a una red local con servicios comunes de ficheros e impresoras. Había varios servidores Unix, a los que se accedía por medio de un programa de emulación de terminal, a través de una pasarela. Incluso teníamos un Mainframe, un UNIVAC 1100, que ocupaba medio CPD. Pero Internet no existía, y el correo electrónico estaba en sus comienzos. Los expedientes se manejaban siempre en papel.

La «Administración Electrónica» no existía.

Desde luego, la informática de entonces a hoy en la Administración Pública ha cambiado mucho. Ahora tenemos Internet y Correo electrónico, tenemos aplicaciones de tres capas, y gestionamos documentos virtuales presentados en ventanillas virtuales y firmados electrónicamente.

Tenemos una ley que da validez legal a todas estas operaciones electrónicas, con un importante desarrollo reglamentario, que además incluye los Esquemas Nacionales ENI y ENS.

Tenemos un importante despliegue de servicios internos y externos, y un confínuo incremento de uso de los mismos.

Todo esto lo tenemos, pero, ¿ha cambiado algo el papel que desempeñan estas tecnologías, y su gestión, en la Administración Pública?

A mi me parece que no.

Cuando hemos pasado del expediente «papel» al expediente electrónico, hemos hecho una correspondencia entre ambos, prácticamente literal. Del mismo modo usamos la firma electrónica, como un reemplazo de la firma y sello manual.

Los procedimientos y los trámites se realizan exactamente igual que antes, solo que ahora son «electrónicos». Seguimos teniendo un Registro Electrónico por cada organismo, al igual que hay un registro físico de ventanilla. Los Ministerios y organismos siguen teniendo su CPD con su informática corporativa, como antes, y gestionada por las unidades con rango de Subdirección General, exactamente igual que hace 18 años.

Las leyes, reglamentos y normas se siguen elaborando ignorantes de sus posibilidades de aplicabilidad tecnológica, exactamente igual que si tal tecnología no existiese. Eso sí, luego se elaboran leyes de «equivalencia» entre el mundo físico y el mundo electrónico, para pemitir su aplicación mediante TI.

Pero esto no es ni mucho menor sorprendente; de hecho, yo ya sabía lo que podía pasar cuando entré en la Administración (aunque me he resistido a creerlo durante mucho tiempo). Os cuento.

Cuando estudié la oposición, me compré un libro titulado «Management Information Systems» (segunda edición, Keneth C. Laudon and Jane P. Laudon, 1991) el cual en su capítulo 4.5 «La resistencia de las organizaciones al cambio» dice (se trata de una traducción libre actualizada):

Sucede a  menudo que la puesta en marcha de un sistema (conseguir que el sistema funcione como está diseñado), es mucho más difícil de lo previsto. De hecho, muchos fallos del sistema son debidos a la exitosa resistencia organizacional.

Todos los modelos descritos en esta sección tienen una característica en común: la conclusión de que la aplicación de los sistemas es difícil puesto que implica cambios en la organización. En pocas palabras:

• Las organizaciones no innovan a menos que haya un cambio sustancial del entorno; las organizaciones adoptan las innovaciones sólo cuando se ven obligadas a hacerlo.

• Las fuerzas de la resistencia al cambio están arraigadas en las estructuras, los valores y los grupos de interés (la cultura) de la organización.

• La innovación organizacional es mucho más difícil y compleja que la simple compra de tecnología. Para cosechar los beneficios de la tecnología, debe ser utilizada y administrada correctamente. Esto, a su vez, implica cambios en los valores, normas, y las alineaciones de los grupos de interés de la organización. El cambio real siempre implica una lucha sobre quién hace qué, dónde, cuándo y cómo.

• Los líderes deben aprovechar las circunstancias externas para afianzar su fuerza y usar las oportunidades externas para inclinar el conflicto interno de una organización y conseguir el desarrollo exitoso de las agendas.

En definitiva, y ahora en mis propias palabras:

  • Si queremos que la Administración mejore por medio de las Tecnologías de la Información, es imperativo replantearse ya seriamente su papel.
  • Este replanteamiento debe llevar aparejados importantes cambios organizativos y de cultura sobre el funcionamiento de las Administraciones.
  • Es preciso que el cambio sea dirigido por líderes fuertes y con visión.
  • Este cambio necesariamente se planteará a medio y largo plazo.

Pero ¿cómo hacerlo?.

Daremos algunas ideas en próximos artículos.

Categorías
Administración Electrónica

¿Puede morir de éxito la Administración Electrónica?

En Consejo de Ministros del pasado 16/09/2011 se presentó el Informe del grado de avance en implantación de Administración Electrónica, cuyo resumen ejecutivo está disponible aquí. De la nota de prensa, extraigo los siguientes párrafos:

En estos momentos existen ya más de 24 millones de DNIe y la previsión es alcanzar a toda la población en 2015. La Agencia Tributaria, la DGT y la Seguridad Social usan ya la notificación electrónica, que entre otras ventajas permite ahorrar 100 millones de euros al año. Una de cada dos declaraciones de la Renta se presentó este año por medios telemáticos, un 15% más que el año pasado, y el servicio 060 de atención al ciudadano, ya sea en sus ventanillas virtuales o en la atención telefónica, gana actividad.

Según las últimas estadísticas de Eurostat, la relación de los españoles con las administraciones a través de Internet ha alcanzado ya la media europea, y en el caso de los jóvenes la posición es superior. El reto es mejorar estos resultados, para lo que se están llevando a cabo medidas y campañas para impulsar el conocimiento y uso de la administración electrónica por parte de los ciudadanos y las empresas.

En efecto, el impulso dado a las relaciones entre los ciudadanos y empresas por vía electrónica con la Administración, y especialmente la disponibilidad y utilización del proceso completo electrónico (presentación, pago, tramitación y notificación) ha sido muy notable, en particular a partir de la fecha del 1 de enero de 2010, en la que, según lo dispuesto en la Ley 11/2007, se pusieron a disposición del ciudadano por vía electrónica la totalidad de los procedimientos administrativos de la AGE.

Y es que este hecho, esta fecha, no fue un final, sino un principio. El gran cambio ocurrido en la legislatura, en lo referente a la Administración Electrónica, ha sido pasar de la disponibilidad a la utilización, como muy bien señaló ayer Fernando de Pablo en el evento CIO Directions.

En efecto, si nos fijamos en el Informe de Situación de la Administración Electrónica de noviembre de 2007, observamos cómo hace especial hincapié en la oferta de servicios y trámites disponibles electrónicamente, mientras que el nuevo informe, cuatro años después, ilustra un crecimiento notable en la utilización de esos servicios. Sólo por citar un dato, de los numerosos que ayer dio Fernando, el número de procesos de validación gestionados por la plataforma @firma se duplica cada seis meses. En numerosos ámbitos, ya es mayor el número de trámites realizados electrónicamente que presencialmente, como por ejemplo en la OEPM, lo que se puede comprobar consultando las estadísticas de tramitación de las diversas solicitudes y procedimientos, que están publicadas en nuestra web.

No podemos dejar de estar orgullosos de este avance, pues además sabemos que la relación por medios electrónicos genera importantes beneficios y ahorros, no sólo para la Administración, sino principalmente para la sociedad, para el ciudadano/accionista. Esta ventaja se pone de manifiesto en numerosos estudios, como por ejemplo el que señala el «Método simplificado para la medición de cargas administrativas«, que cifra el coste de 80 euros por trámite presencial contra 5 euros cuando se realiza por medios electrónicos.

Todo esto son sin duda buenas noticias, sobre todo cuando observamos que estos avances se han realizado a pesar del continuo decremento presupuestario. Según el citado Informe de Avance de la Administración Electrónica señala, desde 2008 hasta hoy, se han reducido los presupuestos TIC de la Administración en cifras que rondan el 20%, cifras que son en realidad mayores pues no tienen en cuenta los efectos de la ejecución presupuestaria (que nunca es del 100%), de la inflación y del aumento del IVA al 18%, que afecta también a la Administración en la compra de bienes y servicios.

Sin embargo, cuando observamos ambas tendencias, es decir, el crecimiento constante de la utilización de medios TIC en las Administraciones, y la disminución constante de los recursos para proveerlos, nos entra la duda: ¿será posible mantener ambas tendencias sin que nada se rompa?. En otras palabras, ¿será posible atender un continuo incremento de la demanda, con recursos cada vez más escasos, sin que la calidad del servicio se resienta?.

Hablaremos de ello… más adelante.

Categorías
Administración Electrónica Tecnologías de la Información

El camino hacia IPv6 (I): Un fábula sobre IPv4

Podríamos decir que, en el mundo Internet, el protocolo IP es como el aire que respiramos. Sin él, Internet no existiría. Podría existir otro tipo de interred, por ejemplo basada en el protocolo X.25, dominante a principios de los años 80, o SNA. Pero serían redes completamente diferentes a la que hoy conocemos como Internet (la red de redes).

Hoy día, el aire que respira Internet está empezando a estar viciado. El agotamiento de las direcciones IPv4 que se ha empezado a producir este año ha provocado una oleada de informaciones de alarma y algunas iniciativas de cambio. Esas iniciativas alcanzan también a las Administraciones Públicas, de las cuales forma parte por ejemplo la creación del portal http://www.ipv6.es por el Ministerio de Industria, Turismo y Comercio.

El camino hacia IPv6 es un largo camino, un camino que en realidad ya ha empezado. Para ayudar a entender en qué consiste ese camino y en que nos afecta, voy a publicar una serie de artículos, de los que este es el primero. En este artículo veremos cómo se ha utilizado IPv4 hasta la fecha en las AAPP, ejemplificado en los casos que conozco de cerca, y que he dramatizado un poco dándole forma de un pequeño cuento.

Érase una vez, un Ministerio de Industria y Energía (MIN), quien allá por al año 1995 tenía cuatro redes locales ARCNET de 4 Mbps para sus 700 PC, ya bastante saturadas, y decidió acometer un proyecto de modernización de la red.

Para la nueva red local, el Ministerio decidió utilizar el flamante protocolo TCP/IP. Siguiendo las directrices del Consejo Superior de Informática, se reservaron y utilizaron un conjunto de direcciones IP comprendidas en el rango 10.10.0.0 – 10.10.254.254 que le habían sido asignadas en el Plan de Direccionamiento e Interconexión de Redes de Area Local de la Administración (PDIRALA). Con ese rango de direcciones, los usuarios del Ministerio fueron felices durante muchos años.

Gracias a su nueva red local, el Ministerio pudo ser pionero en la conexión a internet, ofreciendo la página WEB corporativa en el año 1996 y enlazando el correo electrónico de sus usuarios con Internet en el año 1997.

Pero quisieron los hados que en el año 2000, como consecuencia de una remodelación de gobierno, el Ministerio de Industria desapareciese. En su lugar  apareció el Ministerio de Ciencia y Tecnología (MCYT), el cual se compuso con  trozos del Ministerio de Industria, del Ministerio de Educación y Cultura, el Ministerio de Presidencia, y el Ministerio de Fomento.

Estos trozos de Ministerios llegaron por supuesto dotados con sus propios rangos de direcciones IP, según designaba el PDIRALA del CSI. La unión de estos trozos creó una cacofonía de redes que evocaba los lejanos tiempos de la torre de babel.

Para resolverlo, el MCYT, solicitó un rango de direcciones nuevo, el 10.55.0.0, que se aplicó para unir los trozos y acompasar y orquestar todas aquellas redes que se unieron entre sí, volviendo a reinar la armonía entre todos.

Sucedió entonces que el Organismo dependiente Oficina Española de Patentes y Marcas (OEPM) decidió también modernizar su red, IPX/SPX hasta entonces, integrándose en el nuevo protocolo TCP/IP del Ministerio. Tal como mandaba el PDIRALA, generosamente se le asignaron los rangos de direcciones IP de la clase 10.55.0.0 que necesitaba, uniéndose de este modo a la armonía ministerial.

En aquella feliz época fué también cuando se dió el paso definitivo de creación e interconexión de los Ministerios a la Intranet Administrativa (IA), en la cual por fin, y gracias a las bases preparadas por el PDIRALA, toda la Administración General del Estado podría estar completa y estrechamente interconectada por TCP/IP como si de una gran familia se tratase.

Desgraciadamente, la armonía de nuevo duró poco. Vientos de cambio soplaron de nuevo, y el MCYT se esfumó, volviendo a la vida la reencarnación del Ministerio de Industria, pero con otro cuerpo mejorado y aumentado: tras muchos años de ausencia, volvieron varios hijos pródigos: la Secretaría de Estado de Turismo y Comercio, y también la Dirección General de la Pequeña y Mediana Empresa (DGPYME), provenientes del Ministerio de Economía. Otros tuvieron sin embargo que abandonar, como le sucedió a diversas unidades de la Secretaría de Estado de Política Científica y Tecnológica que volvieron a sus cuarteles tradicionales en el Ministerio de Educación y Ciencia (MEC).

A todo esto, la OEPM no cambió de ministerio pero sí de edificio, y aunque conservó aquellas preciosas direcciones IP legadas por el MITYC, descubrió con pena que no le eran suficientes para sobrevivir en el escaso mundo de las direcciones IP de intranet, por lo que tuvo que ampliar en un rango de direcciones reservadas fuera de la ley del PDIRALA.

De este modo, aquel mundo IP perfecto imaginado para la AGE por su creador, se fué llenando de entropía y desorden, y se oyeron voces que clamaban por resolverlo adoptando un milagroso nuevo protocolo, denominado IPv6.

De este cuento o fábula podemos sacar varias moralejas:

  • Las estructuras de las Administraciones, en particular de la AGE, cambian con mucha volatilidad. No parece pues lógico elaborar planes de largo alcance que estén ligados a tales estructuras, so pena de tener que soportar los costes y desajustes de los continuos cambios, o bien de hacer tales planes inaplicables.
  • En su lugar, y en lo que se refiere a infraestructuras (incluidos los direccionamientos IP), parece mucho más lógico diseñarlas y gestionarlas en base al edificio o ubicación física más que al organo administrativo que incidentalmente las ocupa.
  • Podría parecer que los rangos de direccionamiento definidos por el Plan de Interconexión de Redes de Area local de la AGE (PDIRALA) eran suficientes para permitir el crecimiento previsible, pero ya hemos visto que no es así.
  • El diseño de los esquemas de direccionamiento IP de la PDIRALA tenía por objetivo la interconexión de las redes locales entre sí de los diversos Ministerios. Realmente es dudoso que hoy día ese objetivo tenga sentido en sí mismo.
  • En su lugar, hoy día es claro que la interoperabilidad entre las diversas Administraciones debe hacerse a nivel de servicios. La interconexión de tales servicios está resuelta, desde el punto de vista de las comunicaciones, por Internet. Así pues, parece plausible que lo más apropiado para interconectar las diversas Administraciones entre sí no es una Intranet, sino una Extranet.
  • La utilización de los rangos de direccionamiento reservados por IANA para «usos especiales» en las Intranet de la AGE creó un falso sentimiento de seguridad, de saber que «si estamos en nuestra Intranet, estamos seguros».
  • Pero esa sensación de seguridad no es real, como han demostrado con frecuencia las epidemias de virus en los años 90 y los botnet en los años 2000. Sabemos además que muchos de las amenazas a seguridad de la información no provienen del exterior de la redes, sino de su interior. Tampoco podemos basar la seguridad de la red en medios privados de transmisión, por el elevadísmo coste que supondría. La seguridad pues hay que implantarla extremo a extremo, entre el proveedor y el consumidor de servicios.

Bueno, y todo esto, ¿qué tiene que ver con IPv6? Eso lo sabremos en el siguiente artículo…