¿Qué es TOGAF?
TOGAF es un acrónimo de The Open Group Architecture
Framework (o Esquema de Arquitectura del Open Group, en español) es
un esquema (o marco de trabajo) de Arquitectura Empresarial que
proporciona un enfoque para el diseño, planificación, implementación y gobierno
de una arquitectura empresarial de información. Esta arquitectura está
modelada, por lo general, en cuatro niveles o dimensiones: Negocios, Tecnología
(TI), Datos y Aplicaciones. Cuenta con un conjunto de arquitecturas base que
buscan facilitarle al equipo de arquitectos cómo definir el estado actual y
futuro de la arquitectura.
Definición de Arquitectura y de Esquema de Arquitectura
La definición de arquitectura de sistemas basados en software
dada por el estándar ISO/IEC/IEEE 42010 se puede resumir como:
"la organización fundamental de un sistema, representada por sus
componentes, sus relaciones entre ellos y con su entorno, y los principios que
gobiernan su diseño y evolución."
No obstante, TOGAF tiene una definición propia de lo que es una
arquitectura, que en resumen es "una descripción formal de un sistema, o
un plan detallado del sistema a nivel de sus componentes que guía su
implementación", o "la estructura de componentes, sus
interrelaciones, y los principios y guías que gobiernan su diseño y evolución a
lo largo del tiempo."
Un esquema de arquitectura es un conjunto de
herramientas que puede ser utilizado para desarrollar un amplio espectro de
diversas arquitecturas. Este esquema debe:
·Describir una metodología para la definición de un
sistema de información en términos de un conjunto de bloques constituitivos
(building blocks, en inglés) que encajen entre sí adecuadamente.
·Contener un conjunto de herramientas.
·Proveer un vocabulario común.
·Incluir una lista de estándares recomendados.
TOGAF cumple estos requisitos.
Dimensiones de una Arquitectura Empresarial
TOGAF se basa en cuatro dimensiones:
1. Arquitectura
de Negocios (o de Procesos de Negocio), la cual define
la estrategia de negocios, la gobernabilidad, la estructura y los procesos
clave de la organización.
2. Arquitectura
de Aplicaciones, la cual provee un plano
(blueprint, en inglés) para cada uno de los sistemas de aplicación que se requiere
implantar, las interacciones entre estos sistemas y sus relaciones con los
procesos de negocio centrales de la organización.
3. Arquitectura
de Datos, la cual describe la estructura de los datos
físicos y lógicos de la organización, y los recursos de gestión de estos datos.
4. Arquitectura
Tecnológica, la cual describe la estructura
de hardware, software y redes requerida para dar soporte a la implantación de
las aplicaciones principales, de misión crítica, de la organización.
Componentes de TOGAF
· Architecture Development Method
(ADM)
· Enterprise Continuum (EC)
· Architecture Capability Framework
Architecture Development Method (ADM)
El proceso es iterativo y cíclico. Cada paso inicia con la
verificación de los requerimientos. La fase C involucra una combinación de
Arquitectura de Datos y Arquitectura de Aplicaciones.
Cualquier información adicional relevante que se pueda recopilar
entre los pasos B y C ayudarán a perfeccionar la Arquitectura de Información.
A fin de estandarizar de documentación, es necesario contar con
un Modelo documental de Definición de Arquitectura (Template for Architecture
Definition = Plantilla para Definición de Arquitectura -TDA-)
Las prácticas de Ingeniería del Desempeño se utilizan
en la fase de requerimientos, lo mismo que en las fases de Arquitectura de
Negocios, de Arquitectura de Sistemas de Información y Arquitectura
Tecnológica. Al interior de la Arquitectura de Sistemas de Información se
utiliza tanto la Arquitectura de Datos como la de Aplicaciones.
Características
Consiste en un número de fases.
Es un proceso iterativo, en todo el proceso y dentro de las
fases.
Cada fase usa activos generados en fases previas.
Cada fase genera activos a que se utilizan en fases posteriores.
Es un Método Genérico que se puede adaptar a cualquier
organización.
Agnóstico de cualquier tecnología.
Tiene en cuenta variables geográficas, sectores verticales y
distintos tipos de industria.
Se puede modificar o extender a necesidades particulares de una
organización.
Método de Desarrollo de Arquitecturas (ADM) propuesto por el Open
Group
Las actividades en el método de desarrollo de arquitecturas son de
forma iterativa y todas basadas en los requisitos establecidos, llegando a
cumplir los objetivos planteados en la transformación de la empresa.
Este método proporciona las siguientes fases:
Fase Preliminar
Fase A – Visión de Arquitectura
Fase B – Arquitectura de Negocios
Fase C – Arquitectura de Sistemas de Información
Fase D – Arquitectura de Tecnología
Fase E – Oportunidades y Soluciones
Fase F – Planificación de Migración
Fase G – Gobernanza de la Implementación
Fase H – Gestión de Cambios de Arquitectura
A continuación una pequeña reseña de cada una de las fases, a
nivel general.
Fase Preliminar
En esta etapa se define el ámbito de la organización afectado por
la iniciativa de EA, así como el equipo de EA y los principios de la
arquitectura aplicables. Por último, deben implementarse las herramientas
necesarias para el desarrollo de la arquitectura.
Fase A – Visión de Arquitectura
Se deben identificar las partes interesadas, sus inquietudes y
requerimientos de negocio. En esta fase, es el momento en el que también se
deben confirmar los principios de arquitectura y desarrollar el documento de
visión de arquitectura para poder proporcionar una visión general de los
cambios que se llevarán a cabo en la organización como resultado de la
iniciativa de EA.
Fase B – Arquitectura de Negocios
Fase C – Arquitectura de Sistemas de Información
Fase D – Arquitectura de Tecnología
En estas tres fases, se desarrolla la línea base de arquitectura
(AS-IS Architecture) y la arquitectura final (es decir, la arquitectura
objetivo de la iniciativa de EA, TO-BE Architecture) para cada dominio de
arquitectura (negocio, datos, aplicaciones y tecnología).
Tras realizar las arquitecturas AS-IS y TO-BE, se debe realizar el
gap analysis entre ambos para producir la hoja de ruta de arquitectura (Roadmap
Architecture) para llegar a la arquitectura objetivo. El entregable principal
de esta etapa es el documento de definición de arquitectura.
Fase E – Oportunidades y Soluciones
En esta fase, se define la planificación inicial para la puesta en
marcha de la arquitectura objetivo, se identifican y agrupan los principales
paquetes de trabajo necesarios, así como las posibles arquitecturas de
transición (es decir, arquitecturas intermedias hacia la arquitectura
objetivo). Además, debe definirse la estrategia de alto nivel para la
implementación y la migración a la arquitectura TO-BE.
Fase F – Planificación de Migración
En esta fase, los proyectos de migración identificados en la etapa
anterior son priorizados. Para ello, se debe realizar la evaluación
coste/beneficio, análisis de riesgo y la asignación del valor para el negocio
que se obtiene con ellos. Además, la hoja de ruta de arquitectura debe ser
confirmada, el documento de definición de arquitectura debe ser actualizado y
el plan de implementación y migración debe ser finalizado.
Fase G – Gobernanza de la Implementación
En esta fase, se confirma y supervisa el alcance y las prioridades
de los proyectos de implementación. También, se realizan las revisiones de
cumplimiento de EA, así como las revisiones de post-implementación para validar
cualquier proyecto respecto a la arquitectura definida.
Fase H – Gestión de Cambios de Arquitectura
En esta fase, “se revisa que la arquitectura resultante alcanza el
valor para el negocio que se había establecido como objetivo. Además, también
deben estar establecidos los procedimientos necesarios para poder gestionar el
cambio, tanto el proceso para la implementación del cambio como el seguimiento
y la gestión de riesgos”
Se puede apreciar que cada una de las fases son iterativas y están
relacionadas a muchos procesos de la vida empresarial e incluso al ciclo de
vida de desarrollo de software.
Enterprise Continuum (EC)
El Continuum Empresarial consiste tanto del Continuum
Arquitectónico como del Continuum de Soluciones. Continuum Arquitectónico
especifica la estructura de los artefactos arquitectónicos reutilizables,
incluyendo reglas, representaciones y relaciones de los sistemas de información
disponibles en la organización. Continuum de Soluciones describe la
implementación del Continuum Arquitectónico mediante la definición de bloques constituitivos
de solución (solution building blocks, en inglés).
Architecture Capability Framework
Conjunto de recursos, guías, plantillas, etc. Que son provistos
para ayudar al arquitecto a establecer una práctica arquitectónica dentro de
una organización.
Recursos
Building Blocks (BB)
· Es un paquete de funcionalidad
definido para satisfacer necesidades de negocio
· Un BB publica sus interfaces para
acceder a su funcionalidad
· Un BB puede inter-operar con otros BB
Características de un buen BB:
· Se considera su implementación y uso,
utiliza tecnología y estándares.
· Se puede ensamblar con otros BB.
· Se puede des-ensamblar en otros BB.
· Puede tener múltiples
implementaciones, aunque con diferentes BB.
El "Open Group"
TOGAF ha sido desarrollado por Forum
Arquitectónico del The Open Group y ha evolucionado
continuamente desde mediados de los años 90. La versión más reciente es la 9,
aprobada el 23 de octubre de 2008. La versión anterior es la 8.1.1, la cual
está documentada en detalle en TOGAF 8.1 Enterprise Edition.
La versión 9, abarca los tres mayores componentes de TOGAF:
· Método de Desarrollo de la
Arquitectura (Architecture Development Method, ADM, en inglés),
· El Continuum Empresarial,
· El repositorio de la Arquitectura.
Los siguientes aspectos han sido mejorados para la nueva versión:
· Mejor usabilidad
· Mejor enfoque al cambio empresarial
· Salidas más consistentes
The Open Group provee TOGAF sin costo para toda
organización que desee utilizarlo para sus propios propósitos internos no
comerciales.
Ventajas
de TOGAF
· Establecer un enlace entre TI y el
negocio
· Reducción de costos: Ya que tenemos
una clara visión sobre a dónde queremos llegar, por tanto, disminuirá el valor
de las inversiones y el retorno de las mismas será más rápido.
· Reducción de riesgos: Al identificar
los objetivos del negocio y sus involucrados, es fácil determinar los riesgos y
cómo se deben manejar.
· Identificación de oportunidades: La
fase E del ADM está encargada de identificar oportunidades en cada proyecto de
TI, con base en ciertos análisis y puntos.
· Flexibilidad y adaptación:
Considerando la transformación continua de las empresas, TOGAF se puede adaptar
fácilmente a los proyectos sin permitir que se pierda la calidad de las
arquitecturas diseñadas.
· Lenguaje común: Se modela la
arquitectura de cada área, para que sea sencillo para cada implicado comprender
el desarrollo y construcción de las diferentes aplicaciones, esto, por medio
del repositorio de documentos y modelos que ofrece.
Desventajas
de TOGAF
· Permite un nivel alto de personalización
que a menudo puede convertirse en un problema.
· La documentación tiene un lenguaje
inadecuado que complica el entendimiento
Conclusiones
TOGAF
posee una facilidad natural para absorber estándares de manera dinámica gracias
a su alto nivel de abstracción, esta característica le permite incorporar a su
repositorio artefactos construidos a partir diferentes estándares o métodos de
la industria.
Referencias Bibliográficas
Hola, excelente trabajo, muy a detalle que promueve el entendimiento completo de TOGAF.
ResponderEliminar