¿Cómo gestionáis los principios de Arquitectura Empresarial y los lleváis a la práctica?

En nuestro caso, los principios existen y son conocidos, pero seguimos explorando cómo hacerlos más accionables en el día a día.
Nos interesa especialmente cómo conectarlos con decisiones reales de arquitectura y con el portfolio, para que no se queden solo como un documento de referencia.

Me gustaría aprender de experiencias donde los principios estén realmente integrados en la gobernanza y no solo en la teoría.

Consideramos los principios de Arquitectura como un elemento estratégico donde apoyar otros elementos.
Tenemos una serie de principios definidos y agrupados en categorías.
Cada principio, siguiendo TOGAF, tiene los siguientes apartados:

• Título - Nombre del principio
• Declaración - Descripción del principio 
• Racional - Explicación del por qué del principio
• Implicaciones - Lo que significa en la práctica su su adopción

Estos principios son los que marcan las reglas para el diseño y construcción de las soluciones y las plataformas y están publicados. Se revisan y aprueban anualmente por el Comité de Estrategia y Arquitectura que es un órgano de gobierno de TI en nuestra organización.

Todas las soluciones que se implementan deben contestar un cuestionario que indica si es necesario su paso por la Autoridad de Diseño. La Autoridad de Diseño vela por que las soluciones que se proponen cumplan con estos principios revisando estas soluciones que deben cumplimentar un documento que las describe.

En LeanIX hemos creado una ficha que llamamos “Estrategia”. Uno de los subtipos es “Principio”. Esta jerarquía de Principios es exactamente el documento de “Principios de Arquitectura“.

Me gustaría saber como hacéis el resto, ya que coincido en que acertar en la forma de llevar estos principios a la práctica hacen que el ecosistema TI sea más robusto y homogéneo. Creemos que evitar la dispersión en la forma de acometer las soluciones es muy importante para la simplificar y gobernar la tecnología.

Gracias ​@Javier Guajardo, muy interesante y muy alineado con buenas prácticas de EA 👍

Me parece especialmente potente el hecho de tratar los principios como un activo estratégico, con gobierno formal y mecanismos claros de aplicación (cuestionario, Autoridad de Diseño). Ahí es donde, se ve que pasáis de la pura teoría a la ejecución real.

En nuestro caso todavía estamos explorando cómo pasar de la definición y comunicación de los principios a una aplicación más sistémica y medible: adherencia, gestión de excepciones, evolución en el tiempo… Por eso experiencias como la vuestra ayudan mucho a aterrizar el cómo.

Me surge además una cuestión ligada a la deuda técnica: los principios no solo como reglas de diseño futuro, sino también como una forma de identificar, trazar y priorizar deuda existente cuando no se cumplen, o cuando se aceptan excepciones de forma consciente. ¿Habéis llegado a enlazar principios con deuda técnica o con decisiones arquitectónicas en LeanIX o en vuestro modelo de gobierno?

Gracias de nuevo por compartir una experiencia tan concreta y “bajada a tierra”. Aunque luego cada organización tenga que adaptarla a su contexto, es un punto de partida muy valioso para todos.

Me alegro de que os pueda ayudar. Me interesa mucho compartir la forma en la que adoptamos los conceptos dentro de la herramienta y de la organización, con la esperanza de que alguien lo esté haciendo de otra forma y nos pueda servir para mejorar nuestro procedimiento.

En cuanto a la Deuda Técnica…. dentro de la ficha de “Iniciativas” hemos creado un subtipo llamado ”soluciones”. Todas las soluciones que se plantean tienen su ficha e indicaciones de si tienen o no que pasar por la Autoridad de Diseño y si tiene “Deuda Técnica” y si son “tácticas o Estratégicas”. La deuda técnica hace referencia a la causa, casi siempre principios de Arquitectura. Cuando se da de alta una deuda técnica es obligatorio poner una fecha de compromiso de resolución. De este modo se puede saber la carga de trabajo que “debe” cada equipo. (Normalmente, cuando se identifica una deuda técnica, se para la solución si se puede evitar o bien se obliga a diseñar la solución “Estratégica” y se acepta la “solución Táctica” con su deuda técnica. No toda solución táctica tiene deuda técnica que corregir. Todo ello se lleva en la ficha “Iniciativas/solución”, al igual que las EUDAS, que se llevan en otro Subtipo dentro de Iniciativa.

 

Gracias Javier, muchas gracias por compartirlo con tanto detalle. Aporta mucha claridad sobre cómo llevar los principios de arquitectura a la práctica.

Veo clave la trazabilidad end-to-end que describes:

principio → excepción → deuda técnica → iniciativa → solución,

y, ya dejo para otro hilo 😊, otra posible factsheet, el riesgo.

Ese encadenamiento, desde mi punto de vista, es fundamental para que los principios no se queden en un marco teórico, sino que influyan de forma real en el diseño, la toma de decisiones y la evolución del ecosistema TI.

La introducción del concepto de “solución” como entidad intermedia me parece también que da para crear un hilo propio. Es justo una de las piezas donde yo veía un vacío: sin esa capa, se pierde trazabilidad o parte del proceso acaba gestionándose fuera de LeanIX. Ver cómo lo habéis resuelto mediante un subtipo específico dentro de Iniciativas ayuda mucho a aterrizar ese punto.

Yo suelo ser bastante reticente a customizar el metamodelo OOTB, por el impacto que pueda tener en futuras evoluciones de LeanIX. A veces dudo entre adaptar el modelo o elevar estas necesidades al roadmap del producto. Dicho esto, también es evidente que sin cierto grado de adaptación aparecen bloqueos reales para implantar un modelo de gobierno efectivo, pero parece que vuestro enfoque demuestra que es posible encontrar un equilibrio si se hace con criterio.

También me parece muy acertado el enfoque de distinguir entre soluciones tácticas y estratégicas, y no asumir automáticamente que toda solución táctica implica deuda técnica. Ese matiz refleja muy bien la realidad del día a día.

Y como decía anteriormente, el único elemento que todavía echo en falta en ese esquema es la gestión del riesgo, no solo la deuda generada sino el riesgo asumido y cómo se gobierna. Quizá ahí todavía haya margen de evolución, dentro o fuera de LeanIX.

En cualquier caso, vuestra experiencia baja el debate a tierra y ofrece referencias muy útiles para quienes seguimos explorando cómo implantar estos conceptos de forma operativa y sostenible. Gracias de nuevo por compartirla.

Por cierto, el término EUDAS es nuevo para mi, se refiere a End User Developed Applications? ¿Shadow IT? Porque esto también daría para otro hilo… 

Es cierto, no estamos contemplando el Riesgo, no lo estamos tratando a ente nivel de momento y es interesante poderlo incluir.

Sí EUDA es lo que dices … todos tenemos en medio de procedimientos de negocio algo tan peculiar como una “Excel” que alguien confecciona manualmente o cosas similares. No dejan de ser carencias de los aplicativos que se han tenido que solventar “de otra manera” Nosotros de alguna manera las ligamos a la deuda Técnica.