• Author / Uploaded
• crc025

• Categories
• Marco de software
• Informática
• Tecnología
• Software
• Es / Ciencias de la Computación

Citation preview

TOGAF 9.1

Índice de Contenido Resumen ..........................................................................................................................ii I.

Introducción .............................................................................................................. iii

II. desarrollo .................................................................................................................. 1 TOGAF9.1 ....................................................................................................................... 1 Descripción del Framework.......................................................................................... 1 Conceptos importantes y contenido del Framework ................................................. 2 BIBLIOGRAFÍA ............................................................................................................. 10

i

Resumen

El dinamismo en que están insertas las organizaciones, hace que estas deban luchar férreamente para mantener, y más aún, expandir sus fronteras tratando de minimizar sus costos. Este panorama hace que deban configurar su forma de operar. Ahora bien, las tecnologías de información juegan un gran papel en esto, ya que sirven tanto para proveer productos y servicios como para transportar y resguardar la información generada por la empresa. Bajo este esquema, una correcta alineación de estas tecnologías con los proceso de negocio a los cuales apoyan, permiten cumplir sus objetivos estratégicos. Como parte de esto, aparece el concepto de “arquitectura empresarial”, que es el esquema mediante el cual se representan todos los componentes, procesos y políticas del negocio, a través de modelos que permitan alinear las reglas y objetivos de negocio con la tecnología, sistemas de información e infraestructura disponible, por lo que es de suma importancia gestionarla de manera apropiada. Ahora bien, el proceso de modelado de una arquitectura empresarial, si bien es complejo dada la naturaleza de las organizaciones, puede ser asistido usando herramientas como TOGAF, que es un marco de trabajo para la gestión de arquitecturas empresariales, el cual puede ser usado conjuntamente con COBIT de manera de contextualizar la arquitectura respecto a la organización en su conjunto. El presente documento pretende que el lector pueda tener una visión general tanto del marco de desarrollo arquitectónico TOGAF como de su relación con COBIT, describiendo la forma en que estos se complementan para llevar a cabo la compleja tarea de desarrollar la arquitectura empresarial.

ii

I.

INTRODUCCIÓN

El presente documento trata acerca del marco de trabajo para el desarrollo de arquitecturas empresariales conocido como TOGAF 9.1 (The Open Group Architecture Framework); el cual puede a su vez ser complementado con COBIT 5 para lograr una arquitectura empresarial acorde a los objetivos de negocio requeridos por cualquier tipo de organización que haga uso de tecnologías de información (que es el ámbito abarcado tanto por COBIT como por TOGAF. Principalmente, la realización de este documento busca que el lector conozca y comprenda el marco de trabajo TOGAF. Los objetivos específicos a cubrir son los siguientes: -

Comprender el concepto de Arquitectura Empresarial. Comprender el marco TOGAF Comprender la relación general existente entre COBIT y TOGAF Entender de qué manera TOGAF complementa el proceso de gestión de arquitectura propuesto por COBIT. Entender cómo afecta la evaluación de riesgos de TOGAF Entender la relación existente entre TOGAF y el proceso COBIT APO01

iii

II.

DESARROLLO

TOGAF9.1 Descripción del Framework Basado en TAFIM (Tecnical Architecture Framework for Information Management), TOGAF es un marco de arquitectura de tecnologías de información empresarial, el cual contiene tanto un conjunto de herramientas acompañadas de un método de desarrollo de arquitectura, el cual puede ser utilizado libremente por cualquier organización. Es desarrollado y mantenido por miembros de The Open Group, y su versión actual es la 9.1, la cual fue liberada en 2011. La estructura del documento está dada por el siguiente esquema:

Figura 1 Estructura del documento TOGAF.

1

En el apartado presentado a continuación, el lector encontrará un resumen de los conceptos clave tratados por TOGAF, de manera de guiar una aproximación al framework. Conceptos importantes y contenido del Framework

1. Arquitectura: De acuerdo a TOGAF, este concepto tiene dos definiciones con la misma validez, ya que depende del contexto. La primera expresa que una arquitectura es “una descripción formal de un sistema, o un plano detallado del mismo a nivel de sus componentes para orientar su implementación”. La segunda definición dice arquitectura corresponde a “la estructura de componentes, sus interrelaciones, y los principios y guías que gobiernan su diseño y evolución a través del tiempo”. En palabras simples una arquitectura trata de entregar una perspectiva global de cómo funcionan las los componentes a nivel de la organización, alineándolas entre sí, describiendo las relaciones importantes y proveyendo de una perspectiva superior de manera de abstraerse de la complejidad de cada uno de los componentes. TOGAF cubre 4 tipos de arquitectura, a saber: -

Arquitectura de negocio: La estrategia de negocio, gobierno, organización y procesos clave de la organización

-

Arquitectura de datos/ información: Estructura de datos lógicos y físicos que posee una organización, y sus recursos de gestión de datos

-

Arquitectura de aplicación: Corresponde un plano (blueprint) de las aplicaciones a implementar, sus interacciones y sus relaciones con los procesos de negocio principales de la organización

-

Arquitectura tecnológica: Las capacidades de hardware y software requeridas para apoyar la implementación de servicios de negocio, datos y aplicación. Incluye infraestructura TI, capa de mediación (middleware), redes comunicaciones, procesamiento y estándares.

2

2. ADM (Parte II) : El Método de Desarrollo de Arquitectura (Architecture Development Method), documentado en la parte II del framework, corresponde a la parte más importante de TOGAF, ya que describe cómo obtener una arquitectura empresarial específica para una organización de manera que responda a sus requerimientos específicos de negocio. La forma en que el ADM desarrolla la arquitectura es mediante fases, las cuales se llevan a cabo en un círculo iterativo, que a medida que transcurre genera contenido arquitectónico y gobierna su desarrollo hasta el punto deseado. A continuación se describen las fases que le componen: Fase Preliminar: Prepara la organización para llevar a cabo exitosamente proyectos relacionados con TOGAF. Describe las actividades de iniciación y preparación requeridas para crear la capacidad arquitectónica y definición de principios de arquitectura. Fase A - Visión de Arquitectura: Describe la fase inicial de un ciclo de desarrollo de arquitectura. Establece el alcance, las limitaciones y expectativas de un proyecto TOGAF. Crea la visión de arquitectura, identifica a los interesados, valida el contexto de negocio y obtiene aprobaciones para proceder con el desarrollo de la arquitectura, Fase B – Arquitectura de Negocio: Describe el desarrollo de arquitecturas de negocio en concordancia con la visión de arquitectura acordada en la fase A. Fase C – Arquitecturas de Sistemas de Información: Describe el desarrollo de arquitecturas en concordancia con la visión de arquitectura acordada en la fase A. Fase D – Arquitectura Tecnológica: Describe el desarrollo de una arquitectura tecnológica en concordancia con visión de arquitectura acordada en la fase A. Fase E – Oportunidades y Soluciones: Realiza y conduce la planificación de la implementación inicial y la identificación de las formas de entrega para las arquitecturas definidas en las fases anteriores (B, C, D). Fase F – Plan de Migración: Desarrolla el plan detallado de la implementación y migración que aborda cómo moverse de la arquitectura inicial (arquitectura de línea base) a la arquitectura de destino. Fase G – Gobierno de la Implementación: Proporciona supervisión arquitectónica para la implementación, prepara y publica contratos de arquitectura y asegura que el proyecto de implementación se encuentra en conformidad con la arquitectura. Fase H – Gestión de Cambios de la Arquitectura: Establece procedimientos para gestionar los cambios hacia la nueva arquitectura, para asegurar que ésta responda a las necesidades de la empresa y que se maximice el valor que ésta entrega al negocio. 3

Gestión de Requerimientos: Examina los procesos de gestión de requerimientos de arquitectura a través del ciclo completo del ADM, ya que cada etapa de un proyecto TOGAF está basada en requerimientos, lo cual incluye su validación. En esta etapa se identifican, almacenan y se gestionan al ingreso y egreso de las fases del ciclo. Además se priorizan, abordan y/o eliminan los requerimientos según corresponda. La figura 2 muestra la estructura básica que relaciona las fases del ADM.

Figura 2 Ciclo del ADM

Para poder implementar el ADM, TOGAF provee de una serie de herramientas para adaptarlo a diferentes escenarios, estilos arquitectónicos a desarrollar, estilos de procesos, etc., además de describir algunas técnicas que asisten en el desarrollo de las diferentes tareas que deben realizarse al interior del método. Estas herramientas se encuentran especificadas en la parte III del framework: Guías y

4

Técnicas del ADM, cuyo contenido más importante se muestra a continuación. 3. Guías para Adaptar el ADM Conociendo que la arquitectura empresarial puede ser construida a través del ADM, lo siguiente que se debe realizar es revisar el proceso y sus salidas, para luego ajustarlas a las circunstancias empresariales correspondientes. Muchas son las razones por las cuales se debe hacer esto, a continuación algunas de las más importantes. - El orden de las fases puede ser definido por los principios arquitectónicos que guían la empresa, así como las reglas que rigen al negocio. Por ejemplo, los principios de negocio de una empresa podrían dictar que la empresa necesita ajustar sus procesos de negocio para responder rápidamente a los cambios en el mercado. Para este caso la arquitectura de negocio (fase B) debiera implementarse en conjunto con la arquitectura de SI (fase C) - El ADM es uno de muchos procesos corporativos que conforman el modelo de gobierno corporativo de una empresa. El ADM es complementario y apoya la consecución de otros programas estándar de gestion de procesos. De esta manera, el ADM debe ser adaptado para que refleje las relaciones con otros procesos de gestión. - Una empresa podría querer usar el ADM en conjunto con otro framework de arquitectura, que tiene un conjunto de entregables específicos para un sector determinado: Gobierno, Defensa, Comercio Electrónico, Telecomunicaciones, etc. Aplicando iteraciones al ADM El ADM admite varios conceptos que pueden ser considerados como iteraciones, que permiten ir desarrollando un paisaje arquitectónico comprensivo, estos tienen relación con: Proyectos que iteran a través del ciclo completo del ADM, comenzando en la fase A. Cada ciclo del ADM será limitado por una petición de trabajo arquitectónico. La salida arquitectónica irá creando el paisaje arquitectónico, ya sea extendiéndolo en caso que ya hayan descripciones previas o modificándolo en caso de ser necesario. Proyectos separados podrían trabajar con sus propios ADM, los cuales podrían estar relacionados entre sí en caso que los proyectos tengan alguna relación Un proyecto podría gatillar el desarrollo de otro proyecto, Tipicamente esto sucede cuando iniciativas arquitectónicas de alto nivel identifican oportunidades 5

o soluciones que requieren arquitectura mas detallada, o cuando un proyecto identifica impactos a nivel de arquitectura más allá del ámbito de su petición de trabajo arquitectónico.

4. Entregables, Artefactos y Bloques de Construcción: A continuación se describirán las salidas producidas como resultado de la aplicación del ADM. TOGAF provee un modelo estructural para contenido arquitectónico, que permite que los productos de trabajo producido sean presentados de manera estructurada y consistente. TOGAF utiliza 3 categorías para describir los tipos de contenido arquitectónico generado; los cuales son: -

-

-

Entregable: Un producto de trabajo especificado contractualmente, el cual es revisado, acordado y firmado por los Stakeholders. Representan la salida de los proyectos, y aquellos que están en forma de documentos típicamente serán archivados al finalizarlo, o pasarán a formar parte de un repositorio arquitectónico, ya sea como un modelo de referencia, un estándar o una captura del panorama arquitectónico en un instante dado. Artefacto: Es un producto resultante del trabajo arquitectónico que describe un aspecto específico de la arquitectura. Generalmente se clasifican en catálogos (listas de elementos), matrices (muestran la relación entre los elementos) y diagramas (dibujos de cosas). Como ejemplos de lo anterior se tienen, respectivamente: los catálogos de requerimientos, matrices de interacción de negocios, y diagramas de casos de uso. Bloque de construcción: Representan un componente potencialmente reutilizable de negocios, TI o capacidad arquitectónica, que pueden ser combinados con otros para entregar arquitecturas y soluciones. Se pueden definir en varios niveles de detalle dependiendo de la etapa de desarrollo arquitectónico en la que se encuentre el proyecto. Por ejemplo: En etapas tempranas, un bloque de construcción puede contener simplemente un nombre y una descripción asociada. En etapas más avanzadas, un bloque de construcción puede ser descompuesto en otros, tal vez acompañados de una especificación completa. Los bloques de construcción pueden ser de 2 tipos: “de arquitectura” o “de solución”. o Bloques de Construcción de Arquitectura (ABBs): Aquellos que describen una capacidad (necesidad) requerida. Dan forma a los Bloques de Construcción de Soluciones (SBBs) . Por ejemplo: una capacidad de servicio requerida por un comprador, o Bloques de Construcción de Soluciones (SBBs): Representan los componentes requeridos para implementar la capacidad requerida. Para 6

el ejemplo anterior: La capacidad de servicio, requiere ser satisfecha por muchos SBBs, tales como procesos, datos y software de aplicación. Las relaciones existentes entre entregables, construcción se muestran en la figura 3.

artefactos y bloques de

Figura 3 Relación entre entregables, artefactos y bloques de construcción.

A continuación en la figura 4 se presenta un ejemplo que aterriza las relaciones entre los elementos discutidos anteriormente.

Figura 4 Ejemplo de relación entre entregables, artefactos y bloques de construcción.

7

5. Continuo Empresarial (Enterprise Continuum): El continuo empresarial es una vista del repositorio arquitectónico provisto por TOGAF, que entrega métodos de clasificación de arquitectura y artefactos de solución a medida que se va evolucionando desde arquitecturas genéricas a específicas para una organización en particular. De manera más amplia, se puede concebir el continuo empresarial como un concepto que establece un contexto amplio para una arquitectura, y explica la forma en que soluciones genéricas pueden ser niveladas y especializadas en función de los requerimientos de una organización en particular. La figura 5 muestra una vista general su estructura y contexto.

Figura 5 Vista general del Continuo Empresarial (Enterprise Coninuum)

Repositorio Arquitectónico: Es, en palabras simples, el lugar definido por TOGAF donde se pueden almacenar el contenido generado por las salidas (independiente del nivel de abstracción) del ADM. De esta forma, se facilita el entendimiento y la cooperación tanto de los stakeholders como de los profesionales responsables de su desarrollo en los diferentes niveles. Por medio de los conceptos de Repositorio Arquitectónico y Continuo Empresarial se pretende que los arquitectos aprovechen de buena forma todos los recursos y bienes

8

arquitectónicos relevantes en el desarrollo de una arquitectura específica para la organización. Los principales componentes del repositorio arquitectónico se describen a continuación -

-

-

-

-

Metamodelo Arquitectónico: Describe el marco de arquitectura ya ajustado a la organización, e incluye un metamodelo de contenido arquitectónico. Capacidad Arquitectónica: Define los parámetros, estructuras y procesos que apoyarán la gestión del repositorio. Paisaje Arquitectónico: Corresponde a la representación arquitectónica de los activos utilizados en la organización en un instante de tiempo. Puede existir en múltiples niveles de abstracción, para ajustarse a los objetivos arquitectónicos propuestos por la empresa. Base de Información estándar (SIB): Contiene las normas que las nuevas arquitecturas desarrolladas deben cumplir, y dentro de las cuales se encuentran las normas de la industria en general, los productos seleccionados y los servicios prestados por los proveedores, servicios ya desplegados al interior de la organización. Librería de Referencia: Provee de guías, templates, patrones, entre otros tipos de material de referencia que puede ser utilizado para acelerar la creación de las arquitecturas deseadas (evitando partir de cero). Apuntes de gestión: Mantiene un registro de la actividad de gestión a lo largo de la arquitectura.

La figura 6 muestra la repositorio arquitectónico.

relación entre los distintos componentes del

Figura 6 Estructura del Repositorio Arquitectónico

9

BIBLIOGRAFÍA ISACA®, “Framework-Spanish COBIT5 ”, 2013 ISACA®, “Enabling Processes COBIT5 ”, 2013

10

11