Nadie podría imaginar actualmente la construcción de un gran edificio sin tener un trabajo previo de arquitectura muy consolidado y metódico que consiga satisfacer los objetivos del negocio (por ejemplo, servir de sede central de la compañía, preservando el medio ambiente y maximizando la comodidad de uso) y que alinee a todos los players que intervienen a la hora de su construcción, sabiendo que todos ellos son tremendamente heterogéneos (albañiles, electricistas, fontaneros, etc.).

El software que da soporte a un negocio, a diferencia de un edificio (que también da soporte al negocio), es intangible y no se puede ver, lo que incrementa su dificultad, pero al igual que el edificio, requiere de una buena arquitectura que garantice tanto que se consiguen los objetivos de negocio como que la forma en la que se va construyendo es coherente y ordenada, dado que, como en el caso del edificio, esta construcción es a base de sistemas muy heterogéneos.

En Kynetia proporcionamos a nuestros clientes soluciones de Enterprise Architecture (EA) que van desde la gestión y planificación de las iniciativas EA dentro de la empresa, hasta la implantación de modelos de Governance, frameworks/metodologías o herramientas.

El acercamiento que desde Kynetia hacemos a Enterprise Architecture está respaldado por la dilatada experiencia que hemos acumulado a lo largo de los años proporcionando a nuestros clientes soluciones de arquitecturas reales y tangibles.

Como empresa independiente, es importante destacar que no estamos directamente vinculados a ninguno de los frameworks o metodologías existentes en el mercado, si bien, nuestra experiencia y la cualificación de nuestros arquitectos nos permite trabajar con los más importantes del mercado, como TOGAF o ZACHMAN. En el caso de TOGAF, somos miembros de Open Group y participamos activamente con éste en diferentes eventos internacionales sobre esta metodología, como la Enterprise Architecture Practitioners' Conference San Diego o la Enterprise Architecture Practitioners' Conference Paris.

Nuestro objetivo es adaptarnos a las necesidades de nuestros clientes y, por tanto, proporcionales las soluciones que requieran en cada momento, por eso, no somos partidarios de centrar nuestros esfuerzos en una única metodología y proporcionar así a nuestros clientes la flexibilidad, incluso, de trabajar con la que ellos mismos hayan diseñado en función de sus necesidades.

En este sentido, en ocasiones se hace inviable abordar el diseño de una EA desde el principio hasta el final, y se necesita abordar soluciones de arquitectura parciales, que permitan resolver los problemas que se presentan en un momento dado, pero pensando en un futuro poder albergarlos bajo el paraguas de una EA completa. En Kynetia ayudamos a nuestros clientes a resolver las necesidades de hoy, pensando en la dinámica que éstas puedan tener mañana. Realizamos junto a él un análisis del estado-actual / estado-futuro y diseñamos de forma conjunta la que consideramos mejor arquitectura que en este momento resuelve el problema puntual, pero que permite anticiparse a las necesidades de negocio que se producirán mañana, de acuerdo con la estrategia de su negocio.

Para que una Enterprise Architecture pueda ir mucho más allá de un buen número de documentos sin mucha utilidad, la metodología utilizada para abordar todo el análisis, creación, implantación y evolución de la misma es clave. Sin una metodología pragmática, basada en escenarios conceptuales claros, los beneficios de una buena Enterprise Architecture se desvanecerán en el despacho del CIO en forma de documentos sin utilidad alguna. Por este motivo, la experiencia que acumulamos en Kynetia la utilizamos para trabajar de forma conjunta con nuestros clientes y plantear escenarios de trabajo realistas, prácticos y que, de la forma más ágil posible, aporten una solución de éxito.

Metodología

Componentes básicos de una Enterprise Architecture

Desde un punto de vista genérico, sin centrar el escenario en ninguno de los frameworks existentes en el mercado, de cara a realizar una Enterprise Architecture, en Kynetia abordamos el estudio de los cuatro componentes básicos de una EA: Negocio, Aplicaciones/Usuarios, Información y Tecnología, todo ello bajo el paraguas de un modelo de Governance que permita una implantación con garantías de éxito de la arquitectura.

Si bien podemos abordar sin ningún framework específico la realización de una Enterprise Architecture, lo recomendable es adaptar alguna de las metodologías existentes a las necesidades puntuales de nuestros clientes. Si no se tiene predefinido un framework o metodología específico, asesoramos en la adopción de aquél que mejor se adapte a sus necesidades, o bien, en la creación de uno específico para que cubra de la mejor forma sus necesidades.

El objetivo consiste en crear la arquitectura mediante fases que compongan ciclos completos de ejecución y, de este modo, cuando se ha completando un ciclo, se comience uno nuevo que permita mejorar lo realizado en el anterior. De hecho, no sólo normalmente es iterativo el ciclo completo, sino que es iterativa cada una de las fases que componen el ciclo. Este carácter iterativo otorga una fuerte pragmaticidad y permite que los resultados de la creación de la Enterprise Architecture se vayan viendo con relativa celeridad.

Antes de comenzar el trabajo de iteración de las distintas fases, en Kynetia hacemos un ejercicio previo que nos permita sentar las bases del trabajo, sobre todo, lo referente a la determinación de los diferentes principios que regirán el resto del trabajo. También nos aseguramos de que el cliente tenga claros los objetivos del negocio, el grado de granularidad que quiere dar al trabajo, así como la ventana temporal que, a su juicio, sería la más conveniente para abordar el proyecto. Una vez que se han establecido de forma conjunta estos primeros pasos preliminares, se comienza con el trabajo referente a cada una de las fases que dependerán del framework finalmente seleccionado.

Fases del Proceso

Fases utilizadas en TOGAF

Aunque las fases del proceso de creación de la arquitectura dependen de la metodología seleccionada, a título de ejemplo se describen las que se llevarían a cabo en caso de optar por TOGAF, si bien, simplemente es un ejemplo para que aquellos se estén introduciéndose en el ámbito de EA puedan hacerse una idea a grandes rasgos de cuáles serían las fases de trabajo.

Phase A: Architecture Vision
El objetivo de la primera fase es determinar exactamente el trabajo que se abordará desde el punto de vista de arquitectura. Se trata de definir fundamentalmente el alcance del proyecto y las distintas partes involucradas (consiguiendo su aprobación). Desde un punto de vista muy genérico, se documenta el estado actual y el estado futuro.

Phase B: Business Architecture
Se trata de determinar con profundidad los diferentes aspectos de negocio involucrados en el proyecto. Se abordan los mapas estratégicos, las políticas corporativas, los objetivos de negocio, se realiza la descomposición funcional, los modelos organizativos y se documentan los procesos, tanto los estándares como los que afectan al core-business de la compañía. No sólo se trata de modelar el estado actual, sino también el estado futuro, de ahí que los mapas estratégicos sean un aspecto fundamental, pues determinarán los requisitos de futuro. Como fruto de este trabajo, se obtiene un Gap Analisys que permite ver cuán de lejos se encuentra el objetivo a conseguir con respecto a lo que existe en la actualidad.

Phase C: Information System Architecture
A lo largo de esta fase se analiza tanto la capa de aplicaciones como la de datos. Con respecto a las aplicaciones, se traza el mapa de las existentes (tanto de las aplicaciones pertenecientes a terceras partes, como las aplicaciones hechas a medida), las interfaces existentes entre las ellas y los enlaces (tanto internos como externos a la compañía). Eso describe el estado actual, pero también se proyecta el estado futuro con una aproximación a lo que será el Enterprise Service Bus.

Phase D: Technology Architecture
Es aquí donde se desarrolla la arquitectura tecnológica que implementa tanto el negocio como las arquitecturas de información que se han elaborado durante las fases B y C. Al igual que sucedía con anteriores fases, se crea un baseline de la tecnología actual, analizando el modelo de hardware, modelo de red (LAN y WAN), el software de infraestructura existente (sistema operativo, servidor de aplicaciones, servidor de datos, etc.), etc. A partir de ahí, se crea el estado futuro y se proyecta la arquitectura tecnológica más óptima. Con todo eso en la mano, se realiza el correspondiente Gap Analisys que nos permitirá ver lo lejos que se encuentra nuestro objetivo de lo que existe en la actualidad.

Phase E: Opportunities and Solutions
Nos encontramos ante la fase de análisis probablemente más importante de todo el proceso. Con todas las arquitecturas actuales y futuras definidas en las anteriores fases, ahora corresponde analizarlas y ver cuáles son exactamente los bloques que permitirán construir la nueva arquitectura, cuáles se podrán reutilizar, cuáles será necesario reemplazar y cuáles se tendrán que proporcionar, bien mediante adquisición de los mismos (en caso de procesos estándares) y mediante el desarrollo a medida (para procesos core-business).

Phase F: Migration Planning
A lo largo de la fase E se ha establecido el conjunto de bloques que darán lugar a la arquitectura a implementar. Lógicamente, no todos se implementarán al mismo tiempo, pues eso supondría un tremendo caos. Por tanto, es necesario priorizar y, por tanto, establecer el orden en el que se realizará la implantación de todo lo acordado. Por tanto, se establecerá el plan de migración hacia la nueva arquitectura.

Phase G: Implementation Governance
Durante esta fase es el momento de crear las directrices que asegurarán que tanto los desarrollos que se encuentran dentro del ámbito de la arquitectura, como aquellos que se encuentran fuera de ella, se ajustan exactamente a la arquitectura destino que se pretende crear. Además de todo el modelo de Governance, se establecen los principios arquitectónicos, los principios de seguridad, la metodología que se utilizará en todos aquellos proyectos que se desarrollen, etc. Al final, se trata de conseguir un contrato de arquitectura, que sea firmado por todas las partes que vayan a trabajar en los proyectos de desarrollo.

Phase H: Architecture Change Management
En un entorno tan dinámico como el de un negocio, es prácticamente imposible que una arquitectura estática dé respuesta a todas las necesidades que se irán generando. Precisamente gestionar la dinámica de la arquitectura es el objetivo de esta fase. A lo largo de la fase H se monitorizan las propuestas de cambio y se determinan si se procede y cómo se procede a incorporarlas. Dependiendo de la naturaleza de los cambios será necesario traerlos a esta fase o no. Por ejemplo, una simplificación de un proceso normalmente puede ser gestionada mediante una buena política de gestión de cambios y no es necesario traer ese cambio a esta fase. Cambios como la modificación de estándares o nuevas tecnologías, pueden requerir una rearquitectura parcial, que se consigue accediendo a la fase D. Otros cambios más profundos, como por ejemplo, la modificación severa de procesos de negocio, sí requieren de volver a comenzar desde la fase A.

Enterprise Continuum

Finalmente, es muy importante destacar el papel que desempeña la creación de repositorio para albergar todos los modelos, patrones, artefactos, etc. que vayan apareciendo a lo largo de las diferentes iteraciones del proceso de desarrollo de la arquitectura.

Conceptualmente, siguiendo el modelo propuesto por TOGAF, Enterprise Continuum se subdivide a su vez en: Architecture Continuum y Solutions Continuum. El primero aloja los modelos, patrones, etc. que se producen. El segundo contiene la forma en la que se han obtenido esos modelos, patrones, etc. Dado lo pragmático del modelo, se comienza por lo más general, pero también se aborda lo más específico, de forma que sea claramente de utilidad.

Conclusión

En Kynetia creemos que la única forma de abordar la construcción de una base tecnológica sólida que esté alineada con el negocio es mediante la creación de una Enterprise Architecture, que siga una metodología estricta y que alinee a todos los players que intervienen.

La casuística tecnología de la empresa debida tanto a los sistemas heterogéneos heredados como a las dinámicas de crecimiento del negocio, así como la intangibilidad del software, hace que más que en ninguna otra creación de ingeniería, la arquitectura sea un componente esencial. Las metodologías actuales de EA representan una gran oportunidad para las empresas a la hora de abordar la construcción de una buena arquitectura que incorpore los sistemas actuales y los futuros. En Kynetia, ayudamos a nuestros clientes a conseguirlo.