Treinta y siete términos que aparecen en toda conversación de arquitectura, explicados en español y con su nombre en inglés — porque en la sala se dicen en inglés y en el contrato se escriben en español. Las definiciones marcadas vienen del capítulo 2 del estándar Open Agile Architecture de The Open Group.
Son palabras que usted ya usa, pero que en arquitectura significan otra cosa. Confundirlas hace que dos personas crean que están de acuerdo cuando no lo están.
En arquitectura no es Windows ni Linux. Es operating system en el sentido de negocio: la combinación de activos y procesos necesaria para entregar un producto o un servicio. Cuando el estándar dice «cambiar el sistema operativo de la empresa», habla de cómo opera, no de infraestructura.
No es solo software ni algo que se empaqueta. Es un conjunto de servicios y/o bienes que se ofrece a clientes. Una cuenta bancaria es un producto. Una póliza es un producto. Por eso «pasar de proyectos a productos» aplica igual en banca que en manufactura.
No es el diagrama. Es los conceptos y propiedades fundamentales de un sistema en su entorno, encarnados en sus elementos, sus relaciones y los principios de su diseño y de su evolución. Esa última palabra es la que casi siempre se olvida, y es la que obliga a mantenerla viva.
Los conceptos o propiedades fundamentales de un sistema en su entorno, encarnados en sus elementos, sus relaciones y los principios de su diseño y su evolución.
Una arquitectura sin estado final, diseñada para evolucionar y sostener las necesidades cambiantes de la empresa digital. Es lo contrario del entregable que se firma y se archiva.
Una arquitectura que soporta cambio guiado e incremental en múltiples dimensiones. El estándar la trata bajo el nombre de reestructuración arquitectónica.
Un conjunto deliberado de enunciados, modelos y decisiones que representan un estado arquitectónico futuro. Es la parte que sí se piensa por adelantado — y que el estándar pide tratar como supuestos por verificar, no como verdades.
Una habilidad que posee una organización, una persona o un sistema. En el nivel del modelo operativo, es el criterio con el que se parte la empresa.
El diálogo entre la dirección y los equipos sobre los recursos y el tiempo que hay y los que se necesitan para alcanzar una meta. Una vez fijados los objetivos grandes, la planeación deja de ser solo de arriba hacia abajo y se vuelve un ida y vuelta.
La frontera dentro de la cual un modelo de dominio y su vocabulario significan una sola cosa. Fuera de esa frontera, la misma palabra puede significar otra — y eso está bien, siempre que la frontera sea explícita y el contrato entre contextos también.
Metodología de solución creativa de problemas que arranca por entender necesidades del cliente que hoy nadie satisface.
La acumulación de decisiones de diseño que envejecieron mal y que hoy encarecen cada cambio. No es lo mismo que la deuda técnica de una clase mal escrita: ésta no se paga refactorizando un archivo, sino reestructurando.
El enfoque que representa el conocimiento del dominio en un modelo rigurosamente organizado. El estándar aclara algo útil: no es necesariamente un diagrama — puede vivir en código escrito con cuidado o en un texto bien redactado.
La comunidad de organismos y su entorno funcionando como unidad. Con una observación que vale para empresas: en la matemática de los ecosistemas dinámicos, mientras más alineados los objetivos de los componentes, más sano el sistema.
Una historia de usuario grande que no cabe en una sola iteración, o que es lo bastante grande como para partirse en historias más chicas.
Un conjunto coordinado de restricciones que limita los papeles de los elementos arquitectónicos y las relaciones permitidas entre ellos. Hexagonal y orientada a eventos son estilos.
La identificación de eventos de dominio, comandos, personas y entidades para facilitar una conversación estructurada sobre el dominio. Se trabaja con eventos porque lo pasado es de lo único de lo que se puede estar casi seguro: «esto ocurrió».
Un meta-requerimiento no funcional cuyo propósito es evitar que los demás requerimientos se degraden con el tiempo. Es la propiedad que se pierde primero y se nota al final.
La totalidad de cómo los clientes se relacionan con la empresa y la marca — no en una foto de un momento, sino a lo largo de todo el arco de ser cliente.
El conjunto de extremo a extremo de actividades —las que agregan valor y las que no— que producen un resultado para un cliente o un interesado. Su variante lean distingue el flujo de desarrollo (de concepto a lanzamiento) del de operación (de pedido a entrega).
Un enunciado breve de intención que describe algo que el sistema necesita hacer para el usuario. La plantilla habitual: como [tipo de usuario] quiero [hacer algo] para poder [obtener un beneficio].
La propiedad de un sistema cuyos elementos se comportan de forma consistente como un todo. Es el polo opuesto de la modularidad, y el estándar dedica una sección al balance entre ambas: más modular es más flexible, más integral suele rendir mejor.
Lo que el cliente espera lograr. «Trabajo» es abreviatura de lo que una persona realmente busca conseguir en una circunstancia dada — no el producto que compra, sino para qué lo contrata.
Trazar la experiencia completa del cliente de principio a fin. El recorrido del cliente es la serie de interacciones con la empresa mientras persigue un objetivo específico.
La propiedad de un sistema cuyos elementos presentan alta independencia respecto de los demás.
Las decisiones de diseño que deben tomarse antes de poder trabajar en módulos independientes. Cada módulo se caracteriza por conocer una decisión de diseño que oculta a todos los demás, y su interfaz se elige para revelar lo menos posible.
Una organización estructurada alrededor de equipos permanentes, por oposición a equipos temporales o proyectos. Es el axioma 15 del estándar y la condición sin la cual la arquitectura no se puede mantener viva.
Un personaje ficticio construido a partir de investigación, que representa a un tipo de usuario. Ojo: es un producto de investigación, no una invención de junta.
El código, los componentes y la infraestructura que ya existen y que permiten construir las funcionalidades del corto plazo sin rediseño ni retraso excesivos. Cuando la pista se acaba, cada nueva función cuesta el doble.
Un sistema de software compuesto de aplicaciones e infraestructura que puede reconfigurarse rápidamente con DevOps y cómputo nativo de nube.
Un enunciado cualitativo de intención que la arquitectura debe cumplir.
Un conjunto de servicios y/o bienes que se ofrece a clientes. Tiene funcionalidades: los atributos que definen cómo funciona y qué beneficio entrega.
La serie de interacciones entre un cliente y una empresa que ocurren mientras el cliente persigue un objetivo específico.
Cambiar un sistema de software de modo que no se altere el comportamiento externo del código pero mejore su estructura interna. Es una forma disciplinada de limpiar que minimiza el riesgo de introducir defectos.
La obligación de demostrar el logro de una tarea y responder por el desempeño conforme a lo acordado. Se distingue de la responsabilidad, que es la obligación de llevar la tarea hasta su conclusión — y que trae consigo la autoridad para tomar las acciones necesarias.
Un dato que parece aleatorio o desconectado —ruido de fondo— pero que al mirarse desde otro marco, o al cruzarse con otros datos, resulta ser parte de un patrón significativo.
Un conjunto de entidades y sus relaciones, cuya funcionalidad es mayor que la suma de las entidades individuales.
No es Windows ni Linux. Es la combinación de activos y procesos necesaria para entregar un producto o un servicio: los recursos humanos y de capital que agregan valor o son necesarios para procesar y entregar.
Las personas, su comportamiento, sus creencias culturales, sus habilidades, y cómo se forman e interactúan los equipos — junto con el liderazgo, la estrategia, la estructura y las políticas de la organización. El estándar insiste en desarrollarlo al mismo tiempo que el sistema técnico.
Participantes humanos y/o máquinas que ejecutan procesos y actividades usando software, hardware y otros recursos para entregar productos o experiencias.
El tiempo entre el inicio y la terminación de un proceso. Su variante admisible es el tiempo disponible entre arrancar y terminar para que el cliente quede satisfecho — y cuando el real supera al admisible, hay un problema de arquitectura, no de esfuerzo.
El uso de prácticas digitales apoyadas en tecnologías digitales para lograr un cambio en el modelo de negocio, la propuesta de valor, el sistema operativo o el sistema de distribución, con el fin de mejorar radicalmente la relación con clientes, la rentabilidad y los procesos internos.