Modelos de referencia frente a frente (I): Frameworx versus TOGAF

Modelo de referencia es una palabra relativamente ambigua que me sirve para enmarcar una serie de modelos que en la industria se recogen con términos como framework, arquitectura, modelo, modelo de referencia, marco…

En el artículo ‘¿Para qué vale un modelo de referencia? Ocho buenas razones.‘ improvisaba una definición que repito a continuación

Si ahora vuelvo los ojos específicamente hacia el mundo de los procesos de negocio y la arquitectura empresarial, englobaría bajo este paraguas cosas como ITIL, Frameworx, TOGAF, etc

El concepto, lo reconozco, es algo ambiguo, pero creo que todo aquel que trabaje con este tipo de modelos entenderá a qué me refiero.

Y la ambigüedad no es sólo del concepto sino, en cierto sentido, de la la aplicación práctica de esos modelos. O, quizá, más que de su aplicación práctica, de su adecuado entendimiento en un entorno donde existen una serie de modelos que compiten entre sí, que comparten rasgos comunes pero también aspectos distintivos.

Cuando un consultor o gestor inicia una actividad que puede enmarcarse dentro de uno de esos modelos es lógico sentir una cierta desorientación. ¿Cuál elegir? ¿En qué se parecen y diferencian? ¿Son complementarios o compiten entre sí? Si son complementarios… ¿cómo utilizarlos conjuntamente?

La respuesta no suele ser evidente. Los diferentes modelos suelen surgir de forma independiente, liderados por consorcios, fabricantes o asociaciones con unos ciertos intereses y que, una vez establecido su modelo, prefieren mantenerlo antes que adoptar el desarrollado por terceros. Además, las fronteras conceptuales no suelen estar claras y no es trivial establecer claramente las diferencias y los puntos en común.

Hoy he leído (lo tenía en lista de espera desde hace bastante tiempo), un largo white paper titulado ‘Exploring sinergies between TOGAF and Frameworx‘. que pone frente a frente a dos de estos ‘colosos’. Por un lado, Frameworx, un marco establecido por el TeleManagement Forum (antiguamente Network Management Forum), asociación que agrupa a Operadores, Fabricantes y empresas de tecnología del sector de las telecomunicaciones y, por otro, a TOGAF, el marco establecido por The Open Group para la definición de arquitecturas empresariales.

No pretendo resumir todo lo que ese largo documento, que me ha parecido bastante objetivo y meticuloso, establece, pero sí entresacaré alguna idea básica que pudiera orientar al lector.

Decir que Frameworx lo que prácticamente establece es un modelo de arquitectura empresarial genérico para operadores de telecomunicaciones. En ese modelo se establece, fundamentalmente, aunque no únicamente, el marco de procesos (eTOM – extended Telecom Operations Map),  el marco de información (SID – Shared Information and Data model), el marco de aplicaciones (TAM – Telecom Applications Map) y un marco de integración.

Por su lado, TOGAF, más que en la definición de una arquitectura empresarial, y mucho menos la de un sector específico ofrece método y herramientas para la definición de una arquitectura empresarial, siendo la pieza central de TOGAF aunque ni mucho menos la única, el conocido como ADM (Architecture Development Method).

Dicho esto, diría que la diferencia fundamental es clara: mientras que TOGAF es principalmente un método, Frameworx es fundamentalmente un resultado. Mientras TOGAF uniformiza y ayuda en la forma de definir una arquitectura empresarial, Frameworx es una arquitectura ya definida (aunque de forma genérica para un sector, no para una empresa). Por cierto, aclarar que en la definición (aún en curso) de Frameworx no se utilizó ADM ni, en general, las propuestas de TOGAF.

El white paper profundiza, repasando cada elemento de TOGAF, si está contemplado en Frameworx y cómo, si se puede beneficiar Frameworx de conceptos TOGAF y viceversa.

Solo comentaría el que quizá es el resultado más claro.

En el artículo de repasan cada una de las fases de ADM y cómo encajan con Frameworx. La conclusión, a grandes rasgos es que Frameworx encaja razonablemente bien con las primeras etapas, en concreto, las etapas A, B y C. Así, el mapa de procesos eTOM encaja aproximadamente con la fase B (‘Business architecture’), mientras que SID y TAM se encuadrarían fundamentalmente en lo que sería la fase C (‘Information Systems architecture’), La fase A se cubre débilmente en Frameworx mediante ciertas definiciones en relación a la estrategia de la empresa.

Frameworx no cubre el resto de las fases de TOGAF lo cual resulta lógico, puesto que las siguientes fases de TOGAF cada vez se introducen más en los aspectos específicos de una arquitectura concreta y su implantación, tratando aspectos como la arquitectura tecnológica, la migración o la gestión del cambio, mientras que Frameworx aspira a ser neutral y válido para cualquier operador (o fabricante de soluciones para operadores). Además, esas fases ponen mayor énfasis en el método en sí mismo que, como comentamos, no es objeto fundamental de Frameworx.

El artículo en que me baso es algo antiguo (Abril de 2011) pero creo que estas ideas fundamentales no han cambiado mayormente.

Se observa que TOGAF y Frameworx tienen orígenes diferentes y enfoques diferentes. El diferente enfoque (método versus resultado) paradojicamente abre puertas a una colaboración fructífera, puesto que ‘no se pisan’ demasiado. Sin embargo, al tiempo, el diferente origen y en parte el enfoque, hace que no sea inmediato aunque sí posible el combinar ambos mundos.

¿Cómo evolucionarán estos modelos? ¿Se producirá un acercamiento?¿Una convergencia?¿Un alejamiento?

Creo que no es muy probable la convergencia. Creo que se mantendrá ‘la relación amistosa’ pero que el uso conjunto de TOGAF y Frameworx será más una decisión individual de las compañías que que vean valor en la conjunción de ambos y opten por esa solución unificada..