Arquitectura: el eslabón perdido (II)

Discutíamos en la primera parte del post sobre el origen de las especies y el posible papel de la arquitectura de empresa como el metafórico eslabón perdido entre la estrategia de negocio y la estrategia tecnológica. Es parte del trabajo que hemos hecho con Lluis Olivella para la asignatura de Dirección Estratégica de Sistemas de Información. Repasábamos una lista de lecciones aprendidas de nuestra experiencia, la investigación académica del CISR y un resumen que hacen Rivard y otros en un recomendable libro que intenta resolver el “management puzzle” del alineamiento estratégico.

Imagen bajo licencia GFDL en Wikipedia

1. El diseño y la construcción de arquitecturas es un trabajo técnico, sofisticado, lento y permanente. No hay un remedio rápido, una solución de mercado, una biblioteca de Alejandría donde están todos los códigos ni un lenguaje universal, al menos todavía. Es un proceso, con algunos criterios y principios generales, como el urbanismo civilizado, más que un proyecto con un resultado. Durante tiempo conviven y convivirán lo reciente y lo viejo (las legacies) y, a veces, añadiremos cosas nuevas (modelos de empresa, en sí mismos, como los ERPs) que añaden otras complicaciones rígidas y propietarias. Hace falta una hoja de ruta flexible y se hace camino al andar.

2. La gente cuenta: ¡arquitectos! De una forma parecida a lo que decíamos de los profesionales de la inteligencia de negocio, se necesita una clase de tecnólogo con visión del negocio, los sistemas y los productos, con cicatrices de pruebas fracasadas, con un cierto amueblamiento mental un poco germánico y a la vez sentido práctico. Un urbanista cansado de ver mapas y de patear la calle, las dos cosas, y de relacionarlas: un “arquitecto jefe”.

3. Pero no es sólo un trabajo técnico y de los técnicos. El modelo de operaciones y la arquitectura técnica están relacionados íntimamente. Se necesita una visión de la empresa en su conjunto y sus flujos de relación internos y externos; de los procesos y su estandarización (quién hará qué, dónde, cuándo y sobre qué herramientas); de las necesidades de datos, información y conocimiento (dónde residen y quién y cómo los usarán); y una visión de las aplicaciones y su relación con los procesos y los usuarios.

4. Cada arquitectura de empresa es única, porque cada empresa es única y funciona de forma diferente. No se puede copiar, no se puede replicar desde el conocimiento externo (aunque los consultores y los productos pueden ayudar). No hay arquitecturas estándar, al menos para las empresas medianas y grandes de cierta complejidad. (A veces organizaciones pequeñas y medianas, o con prisa y falta de recursos, pueden importar un “modelo de empresa” con la incorporación de un ERP y pequeñas integraciones departamentales, es verdad).

5. El objetivo principal tiene que ser la flexibilidad y la capacidad de adaptación. Las consideraciones de elegancia técnica, coste, riesgo, amigabilidad, rendimiento, etc., aunque importantes, son secundarias. La arquitectura es el fundamento de la estrategia y de la ejecución (dicen Ross, Weill y Robertson), el lugar donde, al mismo tiempo, se encuentran la misión y los procesos fundamentales y permanentes del negocio y donde deben encajar los cambios y las iniciativas futuras. Por eso la sencillez, la descomposición, el “desacoplamiento” y la visión por servicios son los principios básicos de la arquitectura técnica, Olivella dixit.

6. La estandarización es crucial. Y también muy difícil de alcanzar, sobre todo la estandarización del modelo operativo, de los datos y procesos de negocio. El diseño de servicios estandarizados y la vigilancia permanente y un poco autoritaria de este nivel de estandarización es lo que permite a largo plazo la conectividad e interoperabilidad entre los procesos y aplicaciones, internamente y con el exterior. Y lo que facilita la portabilidad entre diferentes entornos técnicos o delante de cambios organizativos. Es también la condición para mantener la libertad e independencia con relación a los proveedores externos de productos y servicios.

Quizá, como ocurre con el  eslabón perdido, no hemos encontrado el Pithecantropus erectus de Dubois, pero sí una manera de producir especies aún imperfectas que permiten relacionar tecnólogos y directivos, monos y hombres, hombres y monos.

Nota: La obra de hoy es el complejo del Congreso Nacional de Brasil en la ciudad de Brasilia. Oscar Niemeyer (1907-2012), muerto la semana pasada, lo imaginó como una ciudad imaginaria dentro de otra ciudad inventada.

CC BY-NC-SA 4.0 Arquitectura: el eslabón perdido (II) por Jose Ramon está licenciado bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.

Trackbacks/Pingbacks

  1. Bitacoras.com - Información Bitacoras.com... Valora en Bitacoras.com: Discutíamos en la primera parte del post sobre el origen de las especies y…
  2. Qué poco sabemos (II) | iNFoRMáTiCa++ - [...] Hay cosas que deberían ser más estructurales y permanentes. Una es la arquitectura de datos, procesos, sistemas y servicios,…

Comentar

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Leer entrada anterior
¿Qué tienen que ver los coches con el Open Source?

La respuesta a la pregunta que da título a esta entrada seguramente es “aparentemente nada”. Pero es sorprendente como el...

Cerrar