Para la gran mayoría, el trabajo de diseño se refiere a la parte estética de cosas que podemos ver y tocar, sin embargo desde hace 40 años hay un pequeño grupo de gente hablando, pensando y escribiendo acerca de cómo diseñar software (que resulta muy difícil ver o tocar, y a veces hasta es difícil entender y hasta utilizar). Con frecuencia a aquellos que se dedican a diseñar, los llamamos arquitectos.
Hoy en día nadie pensaría en construir un artefacto complejo (como un edificio, un puente, una locomotora, o una computadora) sin diseñarla antes. Pero el diseño no es solo forma o estética, también es función, utilización e interacción con el entorno. En general el diseño de un artefacto complejo debe definir clara y precisamente qué queremos construir, cómo, para quienes, dónde, cuándo y porqué. Esto puede resultar en una gran cantidad de diagramas, tablas, planos, y modelos. Estas son herramientas que utilizamos para describir y especificar el artefacto en cuestión, son representaciones descriptivas del artefacto.
Las representaciones descriptivas que utilizamos no sólo son útiles para construir el artefacto, también, y sobre todo, son herramientas de pensar. Los planos, diagramas y modelos han sido diseñados para ayudarnos a pensar en las diferentes perspectivas del o los artefactos en cuestión. Obviamente, entre más temprano y fácil sea encontrar y corregir errores de diseño, más valiosas son las herramientas de diseño (representaciones descriptivas).
Ciertamente, una vez construido un artefacto complejo, nadie en su sano juicio le haría modificaciones sin consultar la documentación (las representaciones descriptivas) ya que el riesgo de afectar partes y aspectos no intencionados es muy grande, cuando no se conocen los detalles del diseño del artefacto que queremos modificar. Si modificar un edificio sin tener los planos es altamente riesgoso, modificar un avión sin tener los planos es, además altamente irresponsable.
El pasado 16 de enero, el Club de Investigación Tecnológica realizó un seminario ejecutivo con John Zachman, uno de los padres de la Arquitectura Empresarial. En este seminario Zachman presentó con lujo de detalle el Zachman Framework for Enterprise Architecture. Este marco de referencia fue publicado por primera vez hace más de 20 años en IBM Systems Journal, como un marco para la arquitectura de sistemas de información. Zachman considera que el nombre inicial que le dio al marco de referencia fue muy desafortunado, ya que la mayor utilidad de este marco de referencia es en el diseño y o la arquitectura de empresas.
Las empresas modernas son de las cosas más complejas jamás realizadas por el ser humano, sin embargo muy pocas (si acaso alguna) han sido diseñadas. Las empresas nada más suceden, con el tiempo se van haciendo más complejas, su enfoque varía con el tiempo, los productos y servicio varían cada vez más, el mercado y la sociedad en que se desenvuelven cambian casi a diario. Todo esto obliga a hacer constantes cambios en las empresas, sin contar con representaciones descriptivas de lo que queremos cambiar (tal vez esto explica la disfuncionalidad de tantas empresas).
Zachman nos dice que el diseño de una empresa tiene por fuerza 6 abstracciones, estas abstracciones responden a las preguntas: qué, cómo, dónde, quién, cuándo y porqué. Estas abstracciones las podemos hacer equivaler a:
Datos (cuáles son las cosas que le interesan a la empresa), entidades – qué.
Función (cuáles son los procesos que la empresa ejecuta sobre las entidades) – cómo.
Red (en cuáles localidades opera la empresa) – dónde.
Gente (cuáles son las organizaciones importantes para la empresa) – quién.
Tiempo (cuáles son los ciclos de eventos importantes para la empresa) – cuándo.
Motivación (cuáles son los objetivos y estrategias de la organización) – porqué.
Esto suena complejo, pero todavía falta. Para todos es obvio que hay diferentes perspectivas desde las cuáles podemos ver la empresa. Zachman nos asegura que hay exactamente 5 perspectivas: el planificador, el dueño, el diseñador, el constructor, y el contratista. Cada una de estas perspectivas ve la empresa a un nivel de detalle diferente y por lo tanto requiere de representaciones descriptivas diferentes.
El diagrama adjunto es la representación que Zachman hace de su marco de referencia. En cada intersección entre las abstracciones y las perspectivas tenemos una representación descriptiva que nos define de manera clara y precisa un aspecto de la empresa.
Zachman expone y defiende el caso de que producir la arquitectura de una empresa (es decir el conjunto de descripciones descriptivas) no solo es deseable sino que es necesario y urgente. Esta aseveración está basada en el hecho de que la agilidad empresarial es, hoy en día un requisito de sobrevivencia.
Las empresas modernas dependen se su capacidad de cambio para sobre vivir. Las empresas deben adoptar nuevas tecnologías, deben desarrollar nuevos productos y servicios, deben atender nuevos mercados, deben implementar procesos cada vez más eficientes y efectivos. Es claro que la capacidad de cambio a ciegas (es decir sin contar con la arquitectura – las representaciones descriptivas) es altamente riesgoso, por no decir irresponsable.
Como casi ninguna empresa ha sido meticulosamente diseñada antes de construirse, la única alternativa que nos queda es hacer ingeniería reversa para producir la arquitectura de la empresa en funcionamiento. La ventaja de esto es que es bastante probable que la arquitectura sea una fiel representación descriptiva del artefacto (la empresa), el reto es mantener dicha representación actualizada, es decir cada vez que se hace un cambio en la empresa debe hacer el cambio respectivo en la arquitectura (la documentación – las representaciones descriptivas).
Las buenas noticias es que hay bastante herramientas disponibles, así como técnicas y metodologías para lograrlo. Las malas noticias es que todavía no hay herramientas comprensivas que sirvan para todo el conjunto completo de representaciones y, sobre todo, que garanticen que la documentación siempre es una fiel representación de la implementación – esto último solo se logra cuando la implementación es el resultado de transformaciones automáticas de las representaciones.
Lo que en definitiva es cierto es que no hay ninguna razón para hacer toda la arquitectura de una sola vez, se puede (y debe) ir haciendo paulatinamente, escogiendo las herramientas y las metodologías apropiadas para cada caso. A lo que solo me resta decir: Buena suerte.
Artículo publicado en la revista Blue Tech
