Las casas no se empiezan por el tejado, y un departamento de arquitectura que deba constituirse, tampoco. Cuando uno toma decisiones o hace algo de la forma ‘A’ en vez de hacerlo de la forma ‘B’ es porque, en ese proceso de decidir o de hacer, algo lo guía. ¡Genial! Pues hablemos de una de las bases en una arquitectura: los principios de arquitectura.
Qué es un principio
Un principio es
Fundamento, aseveración fundamental que permite el desarrollo de un razonamiento o estudio científico», es decir, una proposición fundamental que sirve de base para un sistema de crrencias, comportamientos o para una cadena de razonamiento.
RAE
Resumiendo; un valor, regla o código de conducta que debe seguirse.
Los principios están destinados a ser duraderos y rara vez enmendados; informan y respaldan la forma en que una organización se propone cumplir su misión.
En un departamento de arquitectura podemos verlas son un conjunto de declaraciones breves que reflejan un nivel de consenso en toda la organización de las TIC respecto de sus prioridades y el espíritu de pensamiento y acción.
No, aquí no cabe esa famosa frase de los hermanos Marx «Estos son mis principios; si no le gustan, tengo otros». Tenemos unos principios, son los que son, y punto.
Para qué le sirven los principios a un arquitecto
Los principios de arquitectura forman la base para la toma de decisiones de los arquitectos. Rigen el proceso de la arquitectura y afectan el desarrollo, el mantenimiento y el uso de la arquitectura empresarial.
Los principios de arquitectura deben ayudar al arquitecto a tomar decisiones arquitectónicas que den lugar a soluciones limpias y mantenibles. Definien las restricciones necesarias en el diseño de un sistema sin definir prescriptivamente todos los detalles del diseño y ayudan a establecer los límites y las prioridades sin microgestionar la forma en que cada uno realiza su trabajo.
Ojo, que esta última frase es muy importante: «sin microgestionar». Si todos los arquitectos cumplimos con los principios, en teoría no hay que estar encima de las decisiones que se adoptan en las arquitecturas que elaboremos.
En mi caso, los principios, junto con otros ‘inputs’, me han guiado en la definición de la arquitectura de referencia de la empresa en que trabajo (tema del que hablaremos en otro artículo), arquitectura que debe permitir cambiar la forma en que se diseñan y construyen las soluciones para solventar los problemas de negocio a los que la actual arquitectura no es capaz de dar respuesta.
Dominios de los principios de arquitectura
¿Os acordáis del artículo en el que hablábamos de los pilares de la arquitectura? Eran 4: negocio, aplicación, información y tecnología. Pues si 4 son los pilares, 4 son los dominios en los que categorizo cada principio.
Hay uno más a tener en cuenta, que creo que debe contemplarse junto con esos 4: la seguridad.
Así pues, los principios arquitectónicos los articularemos en esos 5 dominios, creando un catálogo.
Qué principios contemplar
A ver, que esto no son los 10 mandamientos de Moisés. No hay un libro con el catálogo de principios que toda empresa debería aplicar.
Según la cultura de empresa, sus objetivos, problemas, necesidades, etc, tus principios pueden ser unos u otros. Pueden ser una larga lista o una de corta; puede haber muchos en uno de los dominios y pocos en otro de ellos, o tener un reparto equitativo en cada uno de ellos.
En defintiva, eso depende de ti pero, por favor, define alguno en todos y cada uno de los dominios, y hazlo antes de tomar decisiones, porque las decisiones que adpotes se fundamentan en tus principios.
Cómo articular los principios
Un principio de arquitectura, según recoienda TOGAF, se divide en 4 partes:
- Nombre: Es como el titular de un artículo. Debe ser claro, conciso y preciso… y fácil de recordar.
- Enunciado: Es como la entradilla de un artículo. Generalmente se trata de una frase que indica claramente lo que es el principio.
- Razón: Es la explicación de por qué el principio es importante, qué justifica su existencia.
- Implicaciones: Es una lista de lo que se necesita para llevar a cabo con éxito este principio y cómo podría afectar a la empresa.
Ejemplos
En esta sección os doy 5 ejemplos reales de principios que usamos en el área de arquitectura, de los 80 que constituyen el catálogo completo, uno para cada uno de los 5 pialres mencionados antes.
| Dominio | Nombre | Enunciado | Razón | Implicaciones |
|---|---|---|---|---|
| Negocio | Uso común de aplicaciones | Se potenciará el uso de soluciones comunes a todas las áreas de negocio en lugar de dotar de soluciones similares o duplicadas, a fin de evitar la proliferación y heterogeneidad de las mismas. | La duplicación de soluciones supone un importante incremento de costes, esfuerzos de integración y puede llevar a la existencia de datos desfasados o contradictorios entre ellas, violando el principio de integridad de datos. | 1) Las unidades de negocio que dependen de una solución que no sirve a toda la empresa deben cambiar a una solución de reemplazo que se haya dispuesto para toda empresa (abandonar soluciones particulares) 2) No se permitirá que las unidades organizativas requieran soluciones para su propio uso que sean similares o que dupliquen las ya establecidas para la empresa; de esta manera, se reducen costes y entropía en el ‘landscape’ de servicios. 3) La información utilizada en los sistemas de ‘business intelligence’ incrementa su nivel de estandarización a nivel de toda la compañía, es más fiable y está más controlada. |
| Aplicación | Separación de responsabilidades | Separar una aplicación en distintas secciones (módulos, componentes o servicios), de modo que cada sección aborde una inquietud separada (paquete de funcionalidad definido para satisfacer las necesidades de negocio) y gestione en exclusiva su información. | Al aplicar una política de divide y vencerás, cada módulo se vuelve más simple, entendible, y fácil de mantener y evolucionar. Podremos proporcionar un modelo de composición de aplicaciones basadas en servicios autónomos. | 1) La separación de intereses requerirá proveer de mecanismos a nivel del módulo/aplicación que permita a otros módulos/aplicaciones comunicarse con dicho módulo/aplicación. 2) Los servicios deberán ofrecer acceso a su funcionalidad a través de una interfaz, de forma sincronía o asíncrona. |
| Información | Confidencialidad | La información deberá ser convenientemente protegida para que no sean accedida / divulgada de forma no autorizada | El intercambio abierto de información y la divulgación de información en cumplimiento de la legislación pertinente deben equilibrarse con la necesidad de restringir la disponibilidad de información confidencial y clasificada. Las leyes y regulaciones existentes exigen la protección y la privacidad de la información, al tiempo que debe facilitarse el acceso a quien realmente lo requiera. | 1) La agregación de datos, tanto clasificados como no, requerirá procedimientos de revisión y desclasificación para mantener un control adecuado. 2) El acceso a la información basado en una política de «necesidad de saber» obligará a realizar revisiones periódicas del cuerpo de información (conjunto de datos que es manejado como una unidad). 3) Se debe determinar el etiquetado del grado de sensibilidad de la información. 4) Los sistemas, los datos y las tecnologías deben protegerse contra el acceso y la manipulación no autorizados. |
| Tecnología | Servicios monitorizados | Todo sistema y componente tecnológico deberá estar convenientemente monitorizado. | Se necesita entender como están funcionando los distintos sistemas y componentes tecnológicos, así como poder detectar de forma automatizada cualquier error o problema de rendimiento, a fin de poder resolverlo rápidamente. | Se necesitará una herramienta que automatice la monitorización de los sistemas y componentes tecnológicos, tanto a nivel de infraestructura como de aplicación, en toda la telemetría (logs, métricas y trazas) y la capacidad de llevar a cabo ‘Health checks’. |
| Seguridad | Usar el mínimo privilegio posible | Al acceder a un sistema, solución o componente tecnológico, se deben asignar los mínimos privilegios requeridos para operar correctamente. | El concepto de limitar el acceso, o «mínimo privilegio», consiste simplemente en no proporcionar más autorizaciones de las necesarias para realizar las funciones requeridas. Su objetivo es reducir el riesgo limitando el número de personas con acceso a los controles de seguridad críticos del sistema o capacidades de los mismos. | 1-)Todos los programas y usuarios deben funcionar invocando el menor número de privilegios posible, siempre atendiendo a las funciones que debe desarrollar cada uno de ellos, no limitando o afectando a la productividad. 2) Tener varios administradores con acceso limitado a los recursos de seguridad sin otorgar permisos de «superusuario». |
Conclusión
Sin principios no hay nada, no al menos en mi mundo profesional.
La arquitectura empresarial es una práctica para dirigir el cambio y evolución necesarios en las empresas a fin de que materialicen sus estrategias, y esta dirección requiere aplicar principios y prácticas de arquitectura, y no ir dando tumbos, cambiando de rumbo e improvisando.
Así pues, antes de ponerte a andar, cálzate unas chanclas, o lo sea, pero cálzate con unos buenos principios.