Dentro del enfoque de ADM, como primera etapa teníamos la fase preliminar. Es justo allí donde empieza el desarrollo de la arquitectura. Vamos a definir como podemos dividir la complejidad de la organización en partes mas pequeñas, que realmente podamos reusar. Esto porque es muy difícil trabajar con la organización desde el inicio en su estado total. No podemos trabajarla correctamente si no hacemos la labor de ingeniería inversa.
Para entender la complejidad de una organización se puede dividir en segmentos. Según la escala podríamos hablar de países, sucursales, departamentos, etc. Hasta llegar a un punto en donde nos sentimos cómodos y ponemos iniciar con el análisis.
Estos segmentos se analizan teniendo en cuenta el tiempo. Y como a través de el se descompone la capa estratégica en bloques de construcción. Que pueden tener tantas versiones como sea necesario, hasta el punto en que se pueda generar un componente ejecutable. Lo trato de decir es que en realidad buscamos es ampliar el nivel de detalle. Pasamos de conceptos abstractos (estrategias) a descomponerlo en los espacios de capacidad. Este proceso de descomposición lo logramos gracias a las iteraciones que vamos ejecutando del proceso de ADM sobre cada una de las capas. Esto permite una disciplina y consistencia durante la creación de la arquitectura.
Se van creando los bloques de manera orgánica. Ya que al llegar a la visión arquitectónica vamos a identificar las unidades necesarias para este bloque. Lo cual me genera la necesidad de descomponer en bloques mas pequeños. Es decir que vamos a tener varios procesos ADM anidados.
Cuando identificamos los aspectos y características necesarias en la fase de visión arquitectónica, se genera un documento de visión de la arquitectura. Que explica que es lo que se trata de hacer, en qué nivel (capa) se encuentra y algunos otros factores de los que depende.
También identificamos las piezas de Tecnología de Aplicación de Datos de Negocios (BDAT), las cuales necesitan ser ensambladas para generar esa estrategia con la que estamos trabajando. Otro elemento importante que se tiene en cuenta, son los cambios que se deben hacer o la preparación que se debe tener para lograr la estrategia. Y, por Último, pero no menos importante. Detalla quienes son los interesados y de qué forma intervienen.
Otro dato importante que muestra este documento es el tiempo, costo y esfuerzo. Pilares fundamentales para la gestión de proyectos. Este documento se firma y es, podríamos llamarlo, el primer contrato dentro de la visión arquitectónica.
Anteriormente mencionamos que son varios procesos ADM anidados, pero son los primeros, en donde tomamos las estrategias, los que se convierten en el motivador empresarial. Es decir, son mis macroproyectos y rutas a seguir. Los demás me sirven para modelar como tal la arquitectura y generar mis bloques de procesos y funciones. Los primeros documentos que surgen de la visión arquitectónica, por lo general son los que utiliza la gerencia de la organización. Ya que estos contienen el lenguaje y recursos que estos necesitan.
La descomposición por medio del marco ADM de TOGAF me debería dar como resultado la definición de la organización en una jerarquía descendente. Es decir, primeramente, la visión, luego las metas, objetivos, tácticas, etc.
La motivación empresarial (visión) es importante definirla y alinearla con las actividades propias del negocio y la base tecnológica de la organización. Para luego, lo que se desprende de ella se encamine a desarrollarla. Lo que quiere decir es que los objetivos que se definan para cada uno de estos procesos deben ser inteligentes (específicos, medibles, accionables y realistas en el tiempo).Los interesados. Que son, cualquier persona que se vea afectada por el por el resultado del proceso. Son quienes definen la visión y viabilidad de la arquitectura. En el anterior post ya habíamos hablado un poco sobre los puntos de vista y como se utiliza. Así que no profundizare mucho en este tema. Pero recordemos que nos generan una lista de preocupaciones y necesidades. Con las cuales se evalúan los modelos arquitectónicos que se van generando. Y estos modelos deben contestar a esa lista de uno a uno. Es decir, no se permiten mas ni menos características de las que los interesados requieren.
Entonces, tenemos nuestro documento de puntos de vista, los interesados y algunos bloques de construcción definidos. Lo que se hace es tomar la descripción de estos puntos de vista y los bloques necesarios para ensamblar y desarrollar la visión que se tiene. Por ejemplo, el interesado, llamémoslo gerente, requiere de un reporte donde se muestre cierta información. Tenemos nuestro requisito definido y ahora tomamos las vistas disponibles, es decir gráficos, tablas, etc. En donde se pueda mostrar los componentes que el gerente requiere, que en este caso seria los datos que solicitó. Podríamos definir hasta ahora los siguientes pasos:
- Documento de puntos de vista
- Identificación de modelos de referencia
- Inicio de proceso arquitectónico (Evaluación de estado actual)
- Definición del estado futuro
- Cambios que debo implementar para pasar de la condición actual a la deseada (brecha)
Ahora, toquemos un concepto que es muy importante y es la planificación de escenarios de negocio. Que engloba como tomamos los requisitos del negocio, como se modela y como planificamos con ellos en una serie de escenarios.
La planificación del escenario de negocio, inicia en la fase de visión arquitectónica dentro del proceso de ADM y nuestro objetivo es pasar dentro del escenario de un espacio problemático a uno con una solución que encaje en nuestro modelo de motivación. Este paso requiere un proceso, y es muy importante documentar desde el problema hasta su solución para alimentar nuestra librería de conocimiento.
- Se debe definir el problema y comprenderlo.
- Se debe identificar el medio en el que se desarrolla. Es decir, el momento, interesados, lugar y condiciones en que está ocurriendo. Ya que esto afecta a la estrategia y tácticas a usar.
- Usar modelos para documentar la brecha. Podemos utilizar casos de uso, modelos de notación, etc.
Una vez tenemos identificadas las piezas necesarias que apoyan nuestro negocio. Comenzamos a construir con los bloques definidos esa solución. Y lo hacemos a través de la creación de un modelo de anclaje de negocio. Que como resultado genera nuestra visión del modelo de desarrollo de la arquitectura de negocio. Que está comprendido por:
- Modelo de mercado: Se enfoca en los clientes y la relación con ellos.
- Modelo de productos y servicios: Mira cuales son mis propuestas de valor en el mercado (Productos y servicios).
- Modelo operativo: Como trabaja la organización.
La idea es tomar la problemática y solucionarla por medio de la eficiencia y eficacia. Es decir, generando esos objetivos inteligentes de los que habíamos hablado. De estos objetivos surgen los artefactos clave dentro de la arquitectura. Y estos artefactos son el modelo de anclaje del negocio. Que es lo que permite hacer frente a las diversas dificultades y cambios que enfrente la organización.
Ahora podemos comenzar a generar nuestro producto y ver como se vincula a nuestra área tecnológica. Trabajaremos sobre el dominio de aplicación y el dominio de datos. Si ya se tiene el dominio de datos, se puede iniciar a partir del documento de especificación de arquitectura de datos. Aunque realmente este documento se puede generar antes o después de la arquitectura de la aplicación.
En la arquitectura de la aplicación se necesita identificar que se debe desarrollar. Por ejemplo, una nueva plataforma de software o en el caso de los datos una nueva base de datos o simplemente tablas o campos que se deben agregar. Pero nunca perder el foco, es decir tener siempre presente los requisitos y vistas que dieron los interesados. También se debe conocer cual es la pieza que desarrollo, ¿es una función o un proceso? Con esto logramos crear una relación entre la capacidad y el proceso o función.
Ahora que tenemos la capacidad de poner en marcha esa aplicación debemos relacionarla con el negocio. Es decir, como el nuevo producto tecnológico trabaja con los datos que se obtienen de los procesos de negocio y se alinean para generar los resultados esperados. Esto es lo que llamamos arquitectura de datos. Una aplicación puede estar conformada por varios de los bloques de procesos de la arquitectura. Y hablando a nivel de informática, se puede orientar a una arquitectura por servicios. Donde cada servicio podría apuntar a un bloque de la arquitectura empresarial.
Hasta ahora solo habíamos definido la especificación del producto. Que característica iba a tener, como se iba a comportar frente al negocio y como se vincularía a nuestra plataforma tecnológica. Pero ahora llegan las preguntas de ¿Cómo se va a usar?, ¿Cómo se va a desarrollar?, es mas , muchas veces no es necesario desarrollar el producto, ya existe y es ver como lo puedo implementar, ya que, ya tengo claro cuál es el producto que necesito. Por ejemplo aquí podríamos integrar La Biblioteca de Infraestructura de Tecnologías de Información (ITIL). Para que nos ayudase a gestionar e identificar los recursos tecnológicos.
Hemos llegado a una parte importante dentro del proceso de ADM. Por ahora vamos a dejar hasta aquí. Pero antes recordar que en cada etapa del proceso ADM generamos uno o varios entregables. Que como mencionamos TOGAF suele trabajar con diferentes marcos, así que de estos depende los documentos o salidas que generamos.