Cómo crear un repositorio de Arquitectura Empresarial (AE) que la Gente Realmente Utilice.

La mayoría de los repositorios de arquitectura empresarial terminan convirtiéndose en herramientas de documentación. Si bien esto no es inútil, no es suficiente. Una colección bien organizada de diagramas y objetos no se utilizará si no ayuda a comprender cómo funciona realmente la organización.

El problema suele radicar en la falta de conexiones. El software del sistema da soporte a las aplicaciones. Estas aplicaciones son utilizadas por departamentos específicos para habilitar ciertas funcionalidades. Dichas funcionalidades existen para ayudar a la organización a alcanzar sus objetivos. Cuando el repositorio no refleja estas relaciones, se convierte en un archivo: un lugar donde se almacenan cosas, no un lugar al que se acude para comprender algo.

Es necesario que las personas puedan partir de un objetivo empresarial y rastrear cómo las capacidades, las aplicaciones y las tecnologías contribuyen a alcanzarlo . Esto requiere que el repositorio tenga sentido a un nivel superior, no que simplemente catalogue lo que existe.

También es fundamental que se mantenga actualizado. Las organizaciones cambian, las prioridades varían y un repositorio que no se actualiza pierde credibilidad rápidamente. Sin una clara responsabilidad sobre quién mantiene qué, la información se vuelve fragmentada y poco fiable, y una vez que la gente deja de confiar en ella, deja de usarla.

Un repositorio de arquitectura empresarial no es un sistema de almacenamiento. Debe ser el punto de referencia central para su cartera de proyectos, algo que las partes interesadas consulten cuando necesiten comprender cómo se integran la estrategia, las capacidades, las aplicaciones y la tecnología.

Eso significa ser capaz de responder preguntas prácticas:

• ¿Qué aplicaciones admiten una funcionalidad específica?
• ¿Qué ocurre si se reemplaza un sistema?
• ¿Qué objetivos se ven afectados por un cambio en un proceso determinado?

Otro objetivo importante es  la transparencia . Los distintos grupos de interés ven la organización desde perspectivas diferentes. Dado que ninguna perspectiva es necesariamente más importante que otra,  su repositorio debe ofrecer vistas adaptadas a las necesidades de cada grupo . Los ejecutivos pueden centrarse en los objetivos y las capacidades, mientras que los equipos de TI probablemente estarán interesados ​​en las aplicaciones y la infraestructura. Un repositorio bien estructurado conecta estas perspectivas en lugar de tratarlas como mundos separados. 

A medida que la organización cambia, también lo hace su arquitectura. Las aplicaciones se retiran, los objetivos se modifican y surgen nuevas iniciativas. Estos cambios deben reflejarse en el repositorio, y sin una estructura definida, la situación se complica rápidamente. Se añaden nuevos elementos, los antiguos pierden relevancia y es necesario actualizar las relaciones entre ellos.

Al mismo tiempo, la estructura no se trata solo de mantener el orden, sino que también ayuda a los usuarios a orientarse dentro del repositorio. Los distintos interesados ​​llegan con diferentes puntos de entrada : algunos se interesan por la estrategia y los objetivos, otros por los datos, las aplicaciones o la tecnología. Un repositorio bien estructurado hace visibles estas perspectivas y facilita la navegación, permitiendo a los usuarios comenzar por lo que más les importa. A partir de ahí, las relaciones entre las capas deben permanecer transparentes, para que los usuarios puedan seguir cómo la estrategia se conecta con las capacidades, las aplicaciones y la tecnología subyacente cuando lo necesiten.

Por eso es sumamente importante mantener tu repositorio estructurado . Esto no implica una estructura en particular, sino una que deberás seguir.

Los elementos individuales, como las aplicaciones, las capacidades o las tecnologías, tienen un valor limitado por sí solos. Lo que hace que un repositorio sea realmente útil es cómo se conectan esos elementos:

• Capacidades vinculadas a los objetivos que apoyan.
• Aplicaciones mapeadas a las capacidades que habilitan
• Tecnologías vinculadas a las aplicaciones en las que se ejecutan.

Esto permite a los usuarios alternar entre la estrategia general y los detalles técnicos sin perder el hilo. Además, facilita el análisis de impacto. Cuando algo cambia, se puede rastrear qué más se ve afectado, y eso es lo que diferencia un repositorio que fundamenta las decisiones de uno que simplemente las registra.

Ejemplo de un repositorio estructurado en ADOIT

Que más personas contribuyan al repositorio es positivo, pero una participación más amplia requiere una clara responsabilidad. Sin ella, la información se vuelve inconsistente rápidamente. Los diferentes ámbitos, como las capacidades empresariales, las aplicaciones y los componentes tecnológicos, deben tener a alguien responsable de mantenerlos actualizados.

Esto no implica centralizar todas las actualizaciones en el equipo de arquitectura. En cambio, la responsabilidad debe distribuirse entre quienes mejor conocen los dominios, con el equipo de arquitectura empresarial brindando orientación y supervisión. De esta manera, se garantiza que la información se mantenga precisa y actualizada, respetando estándares consistentes.

La gobernanza también desempeña un papel fundamental a la hora de definir cómo se introducen los cambios. Cuando se añaden nuevas aplicaciones o se modifican las existentes, el repositorio debe actualizarse como parte del proceso, y no como una medida posterior.

Consejo: descubre cómo los Workspaces en ADOIT democratizan la colaboración en Arquitectura Empresarial en nuestro webinar gratuito.

El repositorio debe evolucionar a la par que la organización. Las capacidades cambian, las estrategias se modifican y una imagen que era precisa hace seis meses puede resultar engañosa. Las revisiones periódicas evitan la acumulación de elementos obsoletos y garantizan que las novedades se reflejen antes de que se conviertan en deficiencias.

La gente utiliza herramientas en las que confía, y esa confianza proviene de que el repositorio refleje la realidad de forma consistente.

Un repositorio solo es valioso si la gente lo usa. Para lograrlo, debe ser comprensible y accesible para los diferentes grupos de interés . Las explicaciones demasiado técnicas pueden desmotivar a los usuarios de negocio, mientras que las demasiado abstractas podrían no ser útiles para los equipos de TI.

La buena noticia es que las perspectivas personalizadas pueden coexistir en un mismo repositorio. Los ejecutivos navegan por mapas de capacidades vinculados a objetivos estratégicos, los arquitectos analizan en detalle las dependencias de las aplicaciones y ninguno tiene que ceder.

El uso también depende en gran medida de la visibilidad. Cuando los usuarios ven que el repositorio les ayuda a tomar una decisión importante o a descubrir una dependencia que nadie había notado, empiezan a comprender su utilidad. Eso es lo que convierte a los usuarios ocasionales en habituales.

La pregunta que responde un repositorio útil no es «¿ qué tenemos ?», sino «¿ qué deberíamos cambiar y por qué ?».

Eso requiere priorizar la relevancia sobre la exhaustividad. Las relaciones y dependencias clave deben ser claras y estar actualizadas; no es necesario que cada detalle, por pequeño que sea, esté al tanto.

Esto es precisamente lo que marca la diferencia entre un repositorio que la gente ignora y uno que realmente utiliza.  Cuando las partes interesadas pueden usar el repositorio para comprender las consecuencias de un cambio antes de comprometerse con él, este se convierte en parte del proceso de toma de decisiones, en lugar de ser un simple registro de decisiones ya tomadas .  Las personas recurrirán a él de forma natural cuando necesiten realizar análisis, evaluar impactos o preparar decisiones, porque saben que les ayuda a comprender el panorama general y a tomar decisiones más informadas. 

Crear un repositorio que la gente realmente use se reduce a una cosa: que valga la pena su tiempo . Eso significa mantenerlo conectado, actualizado y accesible para más personas que solo el equipo de arquitectura.

La mayoría de los repositorios empiezan bien y poco a poco se desvían. El mantenimiento pierde prioridad, la propiedad se vuelve confusa y, en algún momento, el repositorio deja de reflejar cómo funciona realmente la organización.

Ahí es donde las herramientas adecuadas marcan la diferencia. ADOIT está diseñado para respaldar precisamente este tipo de práctica: relaciones estructuradas entre objetos, propiedad clara, flujos de trabajo de gobernanza y vistas adaptadas a los diferentes grupos de interés. No reemplaza la disciplina organizativa necesaria, pero facilita considerablemente su mantenimiento a gran escala.