Aquellos de nosotros que tenemos la tarea de trabajar en temas de alto nivel, como la Arquitectura y la Estrategia Empresariales, tememos cuando se nos hace la simple pregunta: «¿Qué haces?»Cuando los entregables carecen de claridad y claridad, las respuestas a esta pregunta dejan al interrogador aturdido y casi apenado por el encuestado. Un término común lanzado en la respuesta, como marcador de posición para la incertidumbre y la incompletitud, es arquitectura de referencia.
Este término puede significar muchas cosas o nada para diferentes personas. Si se deja indefinido, da la impresión de esponjosidad y borrosidad que genera frustración y desperdicio. Los encargados de la implementación pueden cuestionar su capacidad para fundamentar conceptos y pensamientos en la realidad y la concreción. Por lo tanto, las definiciones son útiles. Esta es mi definición de arquitectura de referencia:
La articulación de consideraciones, opciones y estándares conocidos para guiar el diseño de un producto, solución o sistema, basado en observaciones de encuestas, experiencia y experimentación, en un lenguaje y formato visual familiar para el público objetivo.
La verdad es que, una vez que la intención, el valor y el contexto de uso se aclaran para un público determinado, no importa tener una definición formal.
La verdadera pregunta es—
«¿qué es lo que queremos hacer?»
En segundo lugar—
«¿qué queremos que haga la gente (quienquiera que sea)?»
Tener respuestas claras a estas preguntas es el comienzo de desenfocar el significado y la entrega de la arquitectura de referencia. La intención, el contenido, la audiencia y el valor deben ser claros. La palabra «referencia» sugiere que el producto proporciona orientación y normas a partir de la observación, la experiencia y la experimentación, en lugar de una definición de lo que se va a construir. Una «arquitectura» sugiere que es estructurada, coherente y verificable.
Hay varias definiciones de arquitectura de referencia en Internet, pero la regla de claridad anterior (intención, contenido, audiencia, valor) se puede encontrar en cada una de ellas. Considere una definición alternativa a la mía que aparezca como el resultado principal en una búsqueda de Google:
(1) Aclarar el medio y el formato de lo que va a ser entregada por ejemplo, «un documento». Esto determina las herramientas necesarias, la naturaleza del trabajo a realizar y el conjunto de habilidades de los contribuyentes que participarán. Otras formas de prestación de servicios podrían ser una presentación o una base de conocimientos con capacidad de consulta.
(2) Acordar la estructura y la escala de lo que se va a entregar, por ejemplo, «un conjunto de documentos». Un producto puede ser insuficiente, pero la escala del dominio del sistema en cuestión puede requerir que el producto se descomponga en varios documentos.
(3) Identificar la audiencia principal y las partes interesadas, por ejemplo, «gerente de proyecto». Tener una comprensión del tipo y el formato de la información que consumen regularmente. El statu quo también podría desempeñar un papel en este sentido. En algunos casos, la arquitectura de referencia se «transmite» a las líneas jerárquicas como política, mientras que en otros casos se trata como un» bien de tener», con la expectativa de que describa la mejor manera y las alternativas a considerar.
(4) Identificar a otras partes interesadas que podrían necesitar utilizar la arquitectura de referencia. Es necesario crear diferentes vistas o capas? ¿Hay necesidad y espacio para capacitar a otros sobre cómo interpretar y aplicar la arquitectura de referencia?
(5) Deje claro lo que el público/ lector debe hacer con el documento, p. ej. «refiérase a las mejores prácticas.»Los resultados deben entregar lo que dicen en la portada, incluidas las pruebas y los enlaces a las fuentes para la validación. Una arquitectura de referencia también podría ofrecer «aprendizaje» a partir de la experimentación de una manera coherente y procesable.
(6) Aclare el dominio de relevancia. Una arquitectura de referencia sin un dominio específico es una filosofía de principios rectores de nivel superior más que una arquitectura. Una arquitectura, incluso una arquitectura de referencia, necesita estar vinculada a un dominio. Cuanto más pequeño sea este dominio, más relevante y procesable será la arquitectura de referencia.
(7) Se debe comunicar el valor pretendido de la arquitectura de referencia, ya que esto ayuda a la audiencia a juzgar su propósito y limitaciones, por ejemplo, «seleccionar el mejor método de entrega.»Los equipos de implementación saben a dónde ir cuando se necesita tomar esta decisión.
(8) Tener ejemplos del dominio e indicar las tecnologías relevantes, ayuda a aclarar el contexto de la arquitectura de referencia.
(9) Las alternativas y las fuentes de componentes y capacidades que se tengan en cuenta, al implementarlas, deben estar bien documentadas y vinculadas.
Una arquitectura de referencia no es necesariamente un bloqueador antes de que se inicie un proyecto de tecnología. Se puede desarrollar en paralelo o después del parto, sirviendo como documentación de una autopsia y lecciones aprendidas. Si se crea antes de que comience un proyecto, entonces requiere encuestas, ensayos y experimentos para fundamentar las buenas prácticas. A continuación se sugiere una taxonomía de posibles clases de arquitectura de referencia, dependiendo de la audiencia, la solución y la brecha de conocimiento actual dentro de una organización o equipo de proyecto.
El acrónimo de los cinco aspectos diferentes de una arquitectura de referencia es MÚSICA, que ha demostrado ser memorable en conversaciones en cualquier nivel organizacional o dominio de comprensión:
- embership: la lista y categorización de elementos de arquitectura considerados relevantes para el dominio.
- sage: historias de usuario, casos de negocio, procesos, flujos de trabajo y medios para explicar las actividades en el dominio.
- tructure: cómo los diversos elementos de un dominio están interconectados para apoyar su uso.
- nteraction (o Integración): las interfaces y los mensajes intercambiados entre los elementos de la arquitectura durante el uso.
- ontrols: las restricciones y políticas usadas para gobiernan las interacciones.
Ahora bien, esto no sugiere que todas las arquitecturas de referencia necesiten entregar 25 documentos o subsecciones, que cubran cada una de las áreas identificadas. Esto ilustra que probablemente hay 25 áreas diferentes donde las consideraciones, opciones y responsabilidades deben articularse en una organización o proyecto. Esto cambiará dependiendo de tu audiencia. Las arquitecturas de referencia no son borrosas ni esponjosas. Son el resultado de un esfuerzo exploratorio y son los resultados tangibles de la investigación aplicada a corto plazo.