Arquitecturas empresariales en el sector público

La Arquitectura Empresarial, es similar a los planos de la ciudad, en el cual se establece la red de calles, redes de energía y sistema de agua

Hoy en día existen varios marcos de trabajo para desarrollar una Arquitectura Empresarial (EA por sus siglas en inglés) de las organizaciones, desde el enfoque de J.A Zachman desarrollado hacia fines de los 80’s  hasta los modelos más recientes como el desarrollado por la consultora Gartner, pasando por TOGAF y FEA desarrollada por y para el gobierno federal de los Estados Unidos.  Incluso han aparecido otros enfoques más acotados y que tienen una orientación más fuerte a la tecnología como es el caso del modelo de IBM, sobre el cual escribí hace ya un tiempo.

En el ámbito de las instituciones públicas, es poco frecuente encontrar organizaciones que cuenten con un modelo de arquitectura definido, las más avanzadas y/o maduras en estas materias, tienen algunos elementos iniciales de su arquitectura con un foco en los aspectos fundamentalmente tecnológicos.

Recordemos la definición de Arquitectura Empresarial, para lo cual voy a utilizar la definición (metáfora) desarrollada hace ya algún tiempo por el Gobierno de Ontario, la cual me parece útil:

La Arquitectura Empresarial, es similar a los planos de la ciudad, en el cual se establece la red de calles, redes de energía y sistema de agua. Es el marco general para el equipamiento computacional, aplicaciones, sistemas y gestión de información que entrega el Gobierno de Ontario, la arquitectura permite:

1. establecer las normas para la gestión de la información y la tecnología de la información
2. identificar las tecnologías que deberá trabajar juntas y las que no permiten establecer una infraestructura común.
3. contribuir a la seguridad TI
4. promover la coherencia la gestión y apoyo TI

En la medida que los servicios públicos se hacen más complejos, el desafío planteado por contar con un modelo arquitectónico se hace cada vez más urgente, ya que confluyen múltiples tecnologías y además estas deben dar cuenta de un negocio cada vez más complejo en términos de cobertura, procesos y alcance.

En los últimos años hemos visto un proceso de digitalización muy acelerado de los servicios públicos, pero se trata más bien de un modelo basado en la premisa:

Tengo un problema que automatizar, entonces compro y/o desarrollo un software que lo resuelva

Se ve poco una mirada más sistémica, tanto a nivel de una institución en particular, como desde el Estado en su conjunto, de forma que el soporte tecnológico tenga mayor coherencia y aumente el valor del gasto TI por parte del Estado.  Es por ello, relevante que las instituciones públicas, aborden el desafío de modelar sus arquitecturas actuales, y establezcan un modelo deseado a futuro, ello les permitirá establecer un plan de digitalización acorde con esa visión futura, en términos de prioridades, iniciativas, costos y proyectos asociados.

Algunos de los elementos que atentan contra tener un proceso más sistemático de desarrollo e implementación de una arquitectura empresarial en organizaciones del mundo público que al menos visualizo son:

• Presión por tener resultados visibles en poco tiempo (tiempos políticos no coinciden con los tiempos técnicos).
• Presupuestos definidos y estructurados con lógica anual, cuando en muchos casos se requiere una mirada y por ende inversiones que estén orientadas al largo plazo.
• Modelos y normativas de contratación pública presionados por comprar al más barato y no buscando el mejor valor del gasto.
• En muchos países se hace difícil mantener equipos altamente capacitados en el sector público, ya que es habitual la migración hacia el sector privado, o bien cambios productos de la entrada de nuevas administraciones.
• Cambio frecuente de autoridades, lo que hace que prioridades se estén revisando frecuentemente.
• Se percibe poco valor institucional a contar con una arquitectura.

Sin perjuicio de lo anterior, las organizaciones más maduras han avanzado en la dirección de contar al menos con algunos elementos que permitan tener los lineamientos de su arquitectura.

Cualquier enfoque de EA que se adopte, puede resolver el tema, ya que cada uno de los enfoques mencionados más arriba tienen sus ventajas y desventajas.  En la evaluación de los cuatro enfoques realizada por Roger Sessions en 2007 en el documento: “A comparison of the Top Four Enterprise-Architectures Methodologies”, se hace un análisis bastante detallado de los atributos de cada uno llegando al siguiente resultado final, en términos de una evaluación cuantitativa por diferentes criterios, que en opinión del autor son relevantes a la hora de evaluar una arquitectura:

Nota: la escala corresponde a: 1 – muy pobre, 2 – algo desarrollado, 3 – aceptable, 4 – muy robusto.

Al ponderar estos resultados en función de los criterios que a mi modo de ver son los más relevantes para el sector público y usando la misma escala se obtiene que:

Una vez que se haya tomado la decisión de cual enfoque adoptar, incluso puede ser una mezcla de ellos, se debe hacer un análisis de las componentes que se van a utilizar, ya que debemos recordar que estos modelos están pensados para todo tipo de instituciones, desde organizaciones muy pequeñas hasta grandes instituciones, por lo que no necesariamente todos los artefactos son requeridos.

A la hora de pensar por donde partir (como lo han consultado), diría que lo primero que se debe hacer es nombrar un “Arquitecto Institucional”, el cual deberá liderar el proceso, idealmente, debe ser alguien que entienda el negocio, más que la tecnología, por ejemplo debe alinearse la arquitectura con la Misión del negocio, lo cual plantea que los énfasis de las tecnologías preponderantes deben estar acordes con el tipo de rol de la institución.  Adicionalmente el rol de ese arquitecto es mostrar a las autoridades de la institución el valor de un proceso de estas características y lograr el apoyo de estas.

Otro elemento que se debe tener en cuenta, es que el proceso para llegar desde la línea base (situación actual) hasta el modelo de referencia va a tomar tiempo y durante bastante tiempo se va a tener que convivir con elementos que están fuera de las definiciones de la arquitectura, por lo que hay que estructurar un plan de acción con resultados intermedios y que reduzcan la presión por mostrar resultados de corto plazo.

El proceso debe ser sostenido en el tiempo, ya que, en caso contrario, la institución quedará a mitad de camino de ninguna parte, alineando las iniciativas de la institución.  Lo cual plantea que las tecnologías que se adopten, se mantengan en el tiempo y no nos ocurra la práctica habitual de descubrir el hilo negro cada vez que se produce un cambio de administración.  Esto también implica tomar decisiones que orienten los procesos de externalización del soporte TI, con proveedores y productos que realmente sean un aporte al proceso de implementación de esa arquitectura.