A continuación comparto un breve resumen de un material denominado Lecciones de arquitectura para no arquitectos de Jorge Villalobos.
Conceptos
Modelo: una representación abstracta que nos permite abordar un problema de ingeniería y construir una solución (Ej. Puente -Ingeniero Civil-, Proceso de producción -Ingeniero Industrial-, una aplicación -Ingeniero de Sistemas-, entre otras).
Dominio: Los modelos suelen expresarse por simplicidad por dominios. Es un punto de vista o dimensión que participa de la solución. En una solución de Software, por ejemplo, los dominios -tecnológicos- son: software, datos, infraestructura, seguridad e integración (con otras aplicaciones). En las soluciones empresariales normalmente convergen adicionalmente dominios no tecnológicos, que se derivan de ajustes del negocio, plantear nuevos procesos de negocio, cambios en el modelo organizacional, entre otros.
No es solo hacer software… la solución debe tener un modelo para cada uno de los dominios involucrados – Jorge Villalobos
¿Qué es Arquitectura?
Conjunto de modelos de alto nivel que involucran diferentes dominios. Utiliza un nivel de abstracción apropiado para problemas complejos y al final, permite expresar de manera precisa una solución deseada.
A partir de allí y por refinamiento, se llega a los modelos detallados que se necesitan para la implementación, teniendo presente que se pueden tener soluciones sin involucrar tecnología.
Mito: La Arquitectura es un tema meramente tecnológico. Jorge Villalobos.
Arquitectura implica abordar y resolver problemas empresariales complejos en los que participan de manera simultánea múltiples dominios, posiblemente algunos relacionados con tecnología.
El modelo As Is describe la situación actual. El modelo objetivo o To Be, prescribe la solución en todos los dominios involucrados. A este alto nivel se estudian y resuelven los problemas. Si bien puede en un primer momento estar definida de manera abstracta y en un alto nivel, de ninguna manera es vaga o da espacio a grises.
La arquitectura es simplemente ingeniería a un más alto nivel de abstracción que produce modelos que no se implementan directamente – Jorge Villalobos
Los arquitectos de dominio, profundizan en la manera de construir esos modelos: Procesos, negocio, Software… Para ser un buen arquitecto de un dominio de TI se requiere antes ser un buen ingeniero de TI en ese mismo dominio.
Por lo anterior debe acompañar el proyecto en su implementación y entender el resto de niveles que de el dependen; debe poder tocar sin problemas los dominios de nivel tecnológico que se necesiten en dicho dominio.
Al inicio de un proyecto con cierto nivel de complejidad (Ej. Migrar aplicación a la nube, cambiar el sistema core transaccional, hacer reingeniería del proceso de compras para tener mejoras de tiempos del 50%, un nuevo negocio digital, mejorar la experiencia del usuario, inteligencia artificial, tecnología inestable heredada o vieja…) un arquitecto debe realizar las siguientes tareas:
- Identificar los dominios involucrados en el problema y la solución. y conformar un equipo de trabajo: Arquitecto de Negocio, Integraciones, Nube, Datos…
- Identificar la situación actual de la empresa. Construir un modelo por dominio (AS-IS). Los dominios están relacionados entre si, por tanto se debe especificar como se conectan.
- ¿Cómo deben ser los modelos de cada dominio?
- ¿Cómo cambian los modelos en función de la altura?
- ¿Qué lenguaje utilizar para expresar esos modelos?
Si por ejemplo el dominio es el de procesos, el modelo sería un proceso de negocio de la empresa; si el dominio es datos, el modelo sería el diseño de las tablas de una base de datos relacional o la especificación de un conector de extracción de datos. Los modelos se materializan en artefactos.
No basta preguntarle al negocio. Se requiere profundidad en la comprensión del problema antes de lanzarse a dar una solución. La arquitectura de negocio (del dominio no tecnológico), con sus modelos de estrategia, financieros, operativos, de procesos, entre otros <<<se relaciona>>> con la arquitectura de TI (del dominio tecnológico) y sus modelos de aplicaciones, datos, integraciones, seguridad entre otras.
La relación Negocio – TI
Muchas dificultades surgen de las manera en que se involucran estos dos mundos y la manera en que se tratan de mantener alineadas.
Hay consecuencias que solo aparecen con el paso de los años y el costo puede ser muy alto.
La forma en que nos relacionamos con el negocio es demasiado frágil – Jorge Villalobos.
Tradicionalmente se han usado los requerimientos y estos tienden a ser parciales, incompletos, basados en descripciones. Por eso como área de TI nos cuesta tanto alinearnos.
Los modelos de negocio, los planos del negocio, no se construyen con la formalidad que requiere TI, lo cual da pie a interpretaciones subjetivas, cuando el negocio sabiendo que es lo que quiere, no lo sabe explicar. Lo anterior origina que se entreguen soluciones sin entender como encajan integralmente, basados en requerimientos imperfectos, muchas veces levantados de manera intuitiva a partir de entrevistas.
En el camino, vamos acumulando y conectando nuevas aplicaciones, asegurándonos que operen correctamente, pero sin una visión holística integradora. Esto nos lleva con el tiempo a una arquitectura de TI frágil, con múltiples aplicaciones y silos independientes con problemas al integrar la información.
Al final se obtiene un área de TI reactiva, con procesos más lentos y tecnología envejecida.
Es interesante ver como los problemas de comunicación no solamente se presentan entre negocio y tecnología. Hay un caso documentado, en donde se logró llegar a tener una exitosa campaña de comunicación, cuando se estableció un lenguaje común que le permitió al negocio y la agencia publicitaria entenderse con claridad y sin ambigüedad.
Deja un comentario