Ciclo ADM de TOGAF para estructurar proyectos de arquitectura empresarial

Un proyecto de arquitectura empresarial se organiza en etapas. La primera establece la capacidad de arquitectura, los principios de trabajo y las responsabilidades. La segunda define la visión, el alcance y los interesados. Las siguientes desarrollan las arquitecturas de negocio, de sistemas de información y de tecnología. En cada dominio se documenta la situación actual, el estado objetivo y las diferencias que requieren intervención.

Después se identifican oportunidades y soluciones, y se planifica la migración. El gobierno verifica que la ejecución respete las decisiones arquitectónicas. La gestión del cambio determina cuándo corresponde iniciar otra iteración. La gestión de requisitos mantiene la trazabilidad entre las necesidades identificadas y las decisiones adoptadas.

El registro de formación acreditada de The Open Group identifica cursos basados en TOGAF Standard, 10th Edition, y en los requisitos de conformidad del programa de certificación, versión 4.0. El registro incluye las modalidades TOGAF Enterprise Architecture Foundation y Practitioner. Contiene acreditaciones iniciales desde el 17 de octubre de 2022. (The Open Group, 2022) La formación acreditada sirve de referencia para el personal. La organización define por separado los criterios de aprobación de sus entregables.

• Preparación y alcance: gobierno, visión y límites del proyecto.
• Dominios: arquitecturas actual y objetivo de negocio, datos, aplicaciones y tecnología.
• Migración: soluciones, dependencias y secuencia de ejecución.
• Gobierno: conformidad de la ejecución y administración de los cambios.
• Requisitos: registro de necesidades, decisiones y modificaciones durante todo el ciclo.

Un proyecto de arquitectura requiere definir qué decisiones se aprueban antes de comprometer recursos. La visión de arquitectura delimita los procesos incluidos, los resultados esperados y las restricciones presupuestarias. El patrocinador valida las prioridades del negocio. Los responsables técnicos documentan las alternativas y sus consecuencias. Así, una decisión de plataforma no sustituye la evaluación del proceso.

En la arquitectura de negocio se documentan capacidades, actividades, responsables y relaciones entre áreas. La arquitectura de datos identifica la información relevante, los responsables de su calidad y las necesidades de intercambio. La arquitectura de aplicaciones establece qué capacidades se mantienen, se integran o se reemplazan. La arquitectura tecnológica describe los servicios de infraestructura, disponibilidad y seguridad que sostienen el diseño.

Los artefactos incluyen catálogos de aplicaciones, matrices de responsabilidades, diagramas de integración y análisis de brechas. Un catálogo sin propietario pierde vigencia cuando cambia una aplicación. Una matriz de interfaces sin criterios de control dificulta ubicar el origen de los errores de intercambio.

La hoja de ruta convierte las brechas en iniciativas con dependencias y responsables. Cada iniciativa necesita criterios de aceptación verificables durante la ejecución. El gobierno de arquitectura conserva el registro de excepciones y sus autorizaciones. Los cambios de alcance quedan vinculados con sus efectos sobre costos, procesos y continuidad operativa.

El Decreto Supremo N.° 085-2023-PCM aprobó la Política Nacional de Transformación Digital al 2030. Se publicó el 28 de julio de 2023. Su ámbito comprende las entidades de la administración pública y, en cuanto corresponda, empresas públicas, sector privado, academia, sociedad civil y ciudadanía. La política no prescribe el uso obligatorio del ciclo ADM de TOGAF. (Presidencia del Consejo de Ministros, 2023)

La política establece seis objetivos prioritarios: conectividad digital, economía digital, gobierno digital, talento digital, confianza digital e innovación digital. El objetivo prioritario 2 vincula la economía digital con los procesos productivos sostenibles. El objetivo prioritario 5 aborda la identificación, gestión, tratamiento y mitigación de riesgos de seguridad digital. (Presidencia del Consejo de Ministros, 2024) Estas materias sirven de referencia de alineamiento cuando una iniciativa de arquitectura involucra capacidades productivas o gestión de riesgos.

El Decreto Supremo N.° 075-2023-PCM se publicó el 20 de junio de 2023. Modifica el Reglamento del Decreto Legislativo N.° 1412, aprobado mediante Decreto Supremo N.° 029-2021-PCM. También establece disposiciones sobre las condiciones, los requisitos y la utilización de tecnologías y medios electrónicos en procedimientos administrativos. (Presidencia del Consejo de Ministros, 2023) En proyectos con entidades públicas, el análisis normativo distingue las obligaciones aplicables de las metodologías que la organización usa para diseñar su arquitectura.

El Plan de Gobierno Digital 2024-2026 del Ministerio de Economía y Finanzas identifica 38 normas y documentos relacionados con gobierno y transformación digital. Las entidades estatales deben considerarlos para desarrollar sus capacidades digitales. Esa cifra corresponde al inventario normativo del plan y no a las fases de TOGAF. (Ministerio de Economía y Finanzas, 2024) La Secretaría de Gobierno y Transformación Digital publicó el material Arquitectura Digital en el Estado Peruano. El documento relaciona la arquitectura digital con el Decreto Legislativo N.° 1412 y otras disposiciones nacionales. (Presidencia del Consejo de Ministros / Secretaría de Gobierno y Transformación Digital, 2024) Ni la política ni ese material acreditan una obligación general de aplicar TOGAF ADM. (Presidencia del Consejo de Ministros, 2023; Presidencia del Consejo de Ministros / Secretaría de Gobierno y Transformación Digital, 2024)

La planificación comienza con un inventario de capacidades existentes y la identificación de brechas respecto del estado objetivo. Cada brecha se vincula con un proceso afectado y una decisión pendiente. Cuando varias aplicaciones comparten información, la secuencia considera las dependencias de datos y la continuidad de las operaciones. Los responsables del negocio aprueban el orden de ejecución.

La hoja de ruta organiza las iniciativas por incrementos verificables. El primer incremento puede resolver inconsistencias de información que afectan procesos posteriores. Otro puede establecer mecanismos de integración antes de sustituir una aplicación. La secuencia depende de las restricciones operativas, del riesgo de transición y de la capacidad de adopción de los equipos.

El gobierno de la implementación define puntos de control asociados con entregables aprobados. Antes de autorizar una transición se verifican la integridad de la información, las responsabilidades operativas y los procedimientos de recuperación. Las desviaciones respecto de la arquitectura objetivo se registran con su justificación. La aceptación técnica y la aceptación del proceso requieren evidencias distintas.

El método DMG-RT de Dmunoz Group orienta el diagnóstico, la selección y la integración con un indicador de negocio por cada intervención tecnológica. Ninguna configuración, automatización o tablero entra al plan sin un indicador que lo justifique y una línea base medida. La línea base es reproducible y la aprueba el área de finanzas del cliente.

La precalificación F0 dura una semana y verifica que exista un problema medible y un patrocinador. El diagnóstico F1 dura tres semanas, equivalentes a 15 días hábiles. Entrega una carta de hallazgos y oportunidades y una línea base preliminar. El diseño F2 define el proceso y la solución tecnológica que mueven el indicador. Su duración típica va de 2 a 6 semanas. Produce la línea base firmada y el plan de medición. Estas fases son propias del método y no equivalen a las fases del ADM.

Cada oportunidad lleva una fórmula de beneficio, una fuente de datos, supuestos y un rango. Una oportunidad sin fuente de datos se reporta como cualitativa. Todo indicador comprometido se calcula con una consulta o un tablero repetible. La medición manual se admite solo en la línea base.

En un caso hipotético de operaciones, el indicador es el tiempo de ciclo de servicio y el problema son colas sin visibilidad. El diagnóstico mide primero ese tiempo y ubica dónde se generan las esperas. Luego evalúa una mesa de ayuda con acuerdos de nivel de servicio y asignación automática, apoyada en un ERP o en automatización.

El gobierno de arquitectura requiere responsabilidades permanentes sobre los procesos, la información y las decisiones tecnológicas. El comité responsable establece quién autoriza las excepciones y quién verifica su resolución. Los responsables de proceso participan en las pruebas de aceptación y en la revisión de resultados.

La arquitectura objetivo necesita mecanismos de actualización. Los cambios de proveedor, las nuevas integraciones y las modificaciones del proceso alteran los supuestos originales. Un registro de decisiones permite identificar qué componentes dependen de cada supuesto. La revisión periódica se concentra en las diferencias que afectan la operación o los compromisos aprobados.

El método DMG-RT prevé que los indicadores, las acciones correctivas y las actas se registren en el sistema de gestión del cliente, sea un ERP u otra plataforma. También prevé responsables de indicador nombrados y revisiones de sostenibilidad a los 3, 6 y 12 meses.