Fuente unica de verdad: sistemas a nivel de organizacion que defines una vez y usas en todas partes
Aqui hay un patron que aparece en toda organizacion a partir de cierto tamano. El equipo A documenta su arquitectura. Anaden una caja para el Servicio de Autenticacion — nombre, descripcion, stack tecnologico. El equipo B hace lo mismo en su proyecto. El equipo C tambien. Tres proyectos, tres definiciones separadas del mismo sistema, cada una ligeramente diferente. Una dice "Servicio Auth", otra dice "Plataforma de Autenticacion", la tercera dice "Proveedor de Identidad". Mismo sistema. Tres nombres. Tres descripciones que enfatizan cosas diferentes. Ninguna conexion entre ellas.
Seis meses despues, el equipo de autenticacion renombra el servicio y actualiza su stack tecnologico. El cambio se propaga a cero de esos tres diagramas. La version de la realidad de cada proyecto diverge silenciosamente del sistema real y entre si.
Este es el problema de consistencia. No viene de la negligencia. Viene de herramientas de arquitectura que tratan cada proyecto como una isla. Si la unica forma de representar un sistema es crearlo dentro de un proyecto, entonces cada proyecto que toca ese sistema obtiene su propia copia. Las copias divergen. Eso es lo que hacen las copias.
Construimos los sistemas a nivel de organizacion para resolver esto.
Sistemas que pertenecen a la organizacion, no a un proyecto
Archyl ahora soporta dos alcances para los sistemas C4. Los sistemas de alcance de proyecto funcionan exactamente como antes — pertenecen a un solo proyecto y viven en el diagrama de ese proyecto. Los sistemas de alcance de organizacion pertenecen a tu organizacion. Existen independientemente de cualquier proyecto, y cualquier proyecto puede vincularse a ellos.
La distincion importa porque refleja como funciona la arquitectura real. Algunos sistemas son internos a un proyecto — un microservicio que solo existe dentro de ese contexto delimitado, una base de datos que sirve a una sola aplicacion. Esos pertenecen al proyecto. Pero muchos sistemas cruzan las fronteras de los proyectos — infraestructura compartida, servicios de plataforma, integraciones de terceros, capacidades de negocio centrales de las que dependen multiples equipos. Esos pertenecen a la organizacion.
Cuando creas un sistema a nivel de organizacion, estas haciendo una declaracion: este sistema es una realidad compartida. Su nombre, descripcion, tecnologia y etiquetas se definen una sola vez. Cada proyecto que lo referencia ve la misma definicion.
Como funciona
Crear sistemas de organizacion
Los sistemas de organizacion se crean desde una seccion dedicada en la plataforma. Defines el sistema de la misma manera que lo harias en un proyecto — nombre, descripcion, tipo (sistema de software, sistema externo o persona), tecnologia y etiquetas. La diferencia es que no esta vinculado a ningun proyecto. Vive a nivel de organizacion, visible para todos los equipos.
Vincular sistemas a proyectos
Cuando estas trabajando en el diagrama de un proyecto y quieres referenciar un sistema de organizacion, lo vinculas. Un modal te muestra todos los sistemas de organizacion disponibles con busqueda. Activa los que necesitas — aparecen en tu diagrama inmediatamente.
Los sistemas vinculados se comportan como sistemas nativos en el diagrama. Puedes posicionarlos donde tenga sentido para la disposicion de ese proyecto. Puedes crear relaciones hacia y desde ellos. Puedes profundizar en sus contenedores y componentes. La unica diferencia es que la identidad central del sistema — su nombre, descripcion, tecnologia — proviene de la definicion de la organizacion, no del proyecto.
Cada proyecto almacena su propia posicion para el sistema vinculado, por lo que el mismo sistema puede estar en diferentes lugares en diferentes diagramas. La disposicion es por proyecto. La definicion es compartida.
Desvincular
Si un proyecto ya no depende de un sistema compartido, desvinculalo. El sistema desaparece del diagrama del proyecto pero continua existiendo a nivel de organizacion y en todos los demas proyectos que lo referencian. No se pierden datos. Ningun otro equipo se ve afectado.
Por que esto importa
Consistencia sin coordinacion
El enfoque tradicional para mantener la consistencia de la documentacion de arquitectura es el proceso. Escribes convenciones de nomenclatura. Organizas reuniones de revision. Pides a la gente que verifique como otros equipos nombraron el mismo sistema. El proceso funciona hasta que deja de funcionar — que generalmente es el momento en que alguien tiene prisa, lo cual es la mayoria del tiempo.
Los sistemas a nivel de organizacion hacen que la consistencia sea estructural. Hay una definicion. Los proyectos la referencian. Cuando alguien actualiza la descripcion o el stack tecnologico del sistema, cada proyecto vinculado refleja el cambio automaticamente. Sin mensajes de Slack. Sin "por favor actualicen su diagrama". La arquitectura se mantiene consistente porque el modelo de arquitectura lo impone.
Dependencias inter-proyecto precisas
Cuando multiples proyectos estan vinculados al mismo sistema de organizacion, la plataforma conoce esas conexiones. Esto no es una convencion visual — es una relacion de datos. Impact Radar puede rastrear dependencias a traves de sistemas de organizacion mas alla de las fronteras de los proyectos. Si analizas el impacto de modificar un servicio de plataforma compartido, ves cada proyecto que depende de el, porque todos estan vinculados al mismo sistema en lugar de mantener copias independientes.
Incorporacion y descubrimiento
Los nuevos miembros del equipo que se unen a un proyecto ven los mismos nombres de sistemas, descripciones y etiquetas de tecnologia que todos los demas proyectos usan. No hay momento de "cual es este Servicio Auth?". El sistema de organizacion lleva su identidad consigo, y esa identidad es la misma en todas partes.
Duplicacion reducida
Mas alla del beneficio de consistencia, los sistemas de organizacion simplemente reducen el trabajo. En lugar de que cada proyecto documente independientemente la misma infraestructura — el broker de mensajes, el API gateway, el proveedor de identidad, el stack de monitoreo — defines cada uno una sola vez. Los proyectos se vinculan en segundos. El tiempo dedicado a recrear las mismas cajas con etiquetas ligeramente diferentes cae a cero.
Que cambia en el modelo de datos
Bajo el capo, la entidad de sistema C4 ahora soporta dos alcances mutuamente excluyentes. Un sistema pertenece a un proyecto o a una organizacion — nunca ambos, nunca ninguno. Esto se impone a nivel de base de datos con una restriccion.
Una tabla de vinculacion separada rastrea que proyectos referencian que sistemas de organizacion, junto con la posicion por proyecto en el diagrama. Esto significa que el mismo sistema puede aparecer en diez diagramas de proyectos diferentes, cada uno posicionado de manera diferente, cada uno con su propio conjunto de relaciones hacia elementos locales del proyecto.
Cuando cargas el modelo C4 de un proyecto, la plataforma obtiene tanto los sistemas propios del proyecto como cualquier sistema de organizacion vinculado. Se fusionan de manera transparente en el diagrama. La distincion es visible en la interfaz — los sistemas de organizacion llevan un indicador sutil que muestra que son compartidos — pero funcionalmente, participan en el modelo de arquitectura de la misma manera que los sistemas de proyecto.
La vision general
Esta funcionalidad es parte de una direccion mas amplia: hacer que Archyl funcione como las organizaciones realmente funcionan. La arquitectura no es una coleccion de proyectos independientes. Es una red de sistemas compartidos, capacidades de plataforma y preocupaciones transversales. Las herramientas deberian reflejar eso.
Los sistemas a nivel de organizacion son el primer paso hacia un modelo donde la infraestructura compartida se documenta una vez y se referencia en todas partes. Combinados con la vista de Arquitectura Global para visualizacion inter-proyecto y Impact Radar para analisis de dependencias inter-proyecto, ahora tienes una plataforma que entiende tu arquitectura como un todo conectado — no como un conjunto de diagramas desconectados.
Para empezar
Los sistemas a nivel de organizacion estan disponibles ahora. Dirigete a la seccion de organizacion, crea tus sistemas compartidos y luego vincularlos a cualquier proyecto desde la vista de diagrama. Si ya has documentado el mismo sistema en multiples proyectos, esta es tu oportunidad de consolidar — definelo una vez, vinculalo en todas partes y deja que las copias se jubilen.
Tu arquitectura tiene una fuente unica de verdad. Tu documentacion tambien deberia tenerla.
Para mas informacion sobre arquitectura inter-proyecto, consulta Arquitectura Global y Colaboracion en Tiempo Real. Para entender como los cambios en sistemas compartidos se propagan, prueba Impact Radar. Para cambios gobernados en sistemas compartidos, explora las Solicitudes de Cambio de Arquitectura.