TOGAF & ZACHMAN FRAMEWORK - …auditoriauc20102miju02.wikispaces.com/file/view/Togaf... · togaf & zachman framework leidy yoana roman torres docente: carlos hernÁn gÓmez asignatura:

TOGAF & ZACHMAN FRAMEWORK LEIDY YOANA ROMAN TORRES DOCENTE: CARLOS HERNÁN GÓMEZ ASIGNATURA: AUDITORIA DE SISTEMAS UNIVERSIDAD DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA EN SISTEMAS Y COMPUTACIÓN MANIZALES, 20010

Contenido

INTRODUCCIÓN ............................................................................................................................. 3

TOGAF & Zachman framework ....................................................................................................... 5

TOGAF ........................................................................................................................................... 7

HISTORIA Y EVOLUCIÓN ............................................................................................................. 7

DESCRIPCIÓN GENERAL DE LA TEMÁTICA ................................................................................... 8

El papel de TOGAF .................................................................................................................. 8

TOGAF y Arquitectura de Gobierno ........................................................................................ 9

DESARROLLO DE LA TEMATICA ................................................................................................. 10

El ciclo de desarrollo de la arquitectura (ADM) ..................................................................... 10

Estructura básica .................................................................................................................. 11

Contínuum Empresarial ........................................................................................................ 24

Repositorio de la Arquitectura .............................................................................................. 24

Comparación con COBIT ........................................................................................................... 25

ZACHMAN FRAMEWORK .............................................................................................................. 26

DESCRIPCIÓN GENERAL DE LA TEMÁTICA ................................................................................. 30

DESARROLLO DE LA TEMÁTICA ................................................................................................. 30

Vistas o Filas ......................................................................................................................... 30

Enfoques o Columnas ........................................................................................................... 32

Modelos o Celdas ................................................................................................................. 33

COMPARACIÓN CON COBIT ...................................................................................................... 35

RESUMEN DEL TRABAJO............................................................................................................... 36

CONCLUSIONES Y OBSERVACIONES. ............................................................................................. 39

BIBLIOGRAFÍA .............................................................................................................................. 40

INTRODUCCIÓN

Existieron hechos que marcaron pautas en el uso interdisciplinario del término "arquitectura" y más aún en el mundo de la computación. Uno de estos hechos fue la Teoría General de Sistemas, planteada por Bertalanffy en 1931 en la Universidad de Chicago. Estos principios teóricos influyeron en las proposiciones de Diseño y Análisis Estructurado durante los años 80.

Otro hecho fue el desarrollo del Estructuralismo como orientación metodológica, que entre sus principios presuponía "el avance desde la organización primaria de los hechos observables en el marco de la tarea de investigación hacia la clarificación de la estructura interior del objeto (su jerarquía y conexiones entre los elementos de cada nivel)" (Diccionario de Filosofía, 1984).

Un hecho que recibió la influencia de los anteriormente descritos y que a la vez aportó mucho a la arquitectura informática fueron los métodos de análisis y diseño estructurado. Los Métodos de Análisis y Diseño de Sistemas Estructurados tuvieron autores relevantes que hicieron importantes aportes al diseño de los sistemas de información. Entre los más importantes se encuentran: Larry L. Constantine, Wayne P. Stevens, Glenford Myers y Edward Yourdon (Senn, 1997).

El primer enfoque de la arquitectura informática, en la década del 70, se focalizaba en el problema básico de la desorganización de la información que nos rodea, cuya solución consistía en proporcionar un orden a dicha información en el naciente entorno computacional.

Las empresas durante esta época, ante el desarrollo de la computación, comienzan a utilizar la misma para la gestión de los datos resultantes de los procesos internos. O sea, para crear sistemas de información independientes entre sí, pero que resolvieran problemas específicos. El uso primario que tuvieron las computadoras en las empresas fue para crear bases de datos que permitían el procesamiento de los mismos para generar nueva información.

Para definir qué se hace en una arquitectura informática algunos autores plantean: "El proceso se inicia desde una vista conceptual de alto nivel, luego es sucesivamente refinado hasta el nivel más bajo en el que la base de datos física puede ser implementada" (BRANCHEAU & WETHERBE, 1996). Aquí se evidencia el criterio de diseño de lo general a lo particular.

En otro artículo (BRANCHEAU, SCHUTER, & MARCH, Buinding and implementing an information architecture, 1996) afirman que: "Una arquitectura de información proporciona un marco en el que la planificación del desarrollo de aplicaciones pueda realizarse en el grupo y niveles del proyecto. Una arquitectura de información puede guiar decisiones acerca de qué aplicaciones deberían ser construidas".

Y más adelante sobre el método de hacerla nos apuntan:

"Primero, deben ser identificadas y definidas las funciones básicas del negocio. Esto implica determinar el modelo de negocio de la organización y determinar qué funciones necesitan ser desarrolladas para ser un negocio competitivo. Segundo, se deben hacer mapas de las estructuras de negocio en relación con las funciones del negocio. Esto implica determinar qué gerentes son responsables de (o desempeñan un rol en) cada función del negocio. El mapa es útil para determinar quiénes deben estar involucrados en el desarrollo de la arquitectura. Tercero, se deben hacer mapas de la información sobre aplicaciones existentes con respecto a las funciones de negocio. Esto implica reunir información sobre las funciones proporcionadas por los sistemas existentes y cómo de bien son convenientes para las necesidades de información de la organización." (BRANCHEAU, SCHUTER, & MARCH, Buinding and implementing an information architecture, 1996).

Es interesante cómo estos autores plantean, como una herramienta para hacer la arquitectura informática, la realización de matrices a través de tabulación de contenidos; el uso de un Modelo Global de Datos (que es muy similar a los diagramas de caso de uso de UML); y la descripción y definición de las entidades descritas en el mapa.

De acuerdo a lo anterior, existen varios marcos para la elaboración de la arquitectura informática de las empresas, dos de ellos que se especificaran en seguida son TOGF y Zanchman Framework.

TOGAF & Zachman framework

La relativa complejidad de la ejecución del programa de arquitectura empresarial depende de factores como el nivel de compromiso de la organización, la disponibilidad de recursos y el tamaño de orientación, la complejidad del modelo de negocio de la organización, y la agilidad de la organización. La realidad es que muchas organizaciones simplemente no son capaces de implementar y mantener un programa de arquitectura empresarial en un tiempo mínimo, y sirve para centrarse en mejorar las técnicas de procesos que hagan hincapié en la eficiencia en lugar de la eficacia.

Existen dos enfoques generales de la aplicación de arquitectura empresarial, que corresponden aproximadamente a los dos tipos de marcos disponibles.

Los primeros proyectos están enfocados en los artefactos organizativos y procesos en el marco de la meta-estructura. Las organizaciones que favorecen este enfoque suelen elegir Zachman o un marco equivalente. Uno de los peligros de este enfoque es que la estructura del marco puede limitar la creatividad y añadir burocracia al proceso de aplicación de la arquitectura empresarial. El otro problema con este tipo de marco se deriva de la grave escasez de orientaciones para la aplicación.

Por otro lado, el segundo enfoque se basa en la creencia de que un programa de arquitectura de la empresa tiene que ser basada en procesos. Este enfoque se centra principalmente en las actividades en lugar de los artefactos, puede ser más fácil de entender y la vinculación con las metodologías existentes y las técnicas de solución de la empresa.

Si bien ambos métodos tienen sus pros y sus contras, una solución de compromiso podría ser el uso de un proceso impulsado por la actividad global, mientras que la aplicación de una meta-marco como una estructura de soporte o para su análisis.

Éstos son algunos de las actividades básicas que deben tener lugar como parte de cualquier implementación de arquitectura empresarial.

• Estudio de las prácticas de negocios. Entender el modelo de negocio de su organización y, como mínimo, sus procesos de negocio de alto nivel es una condición previa para iniciar la implementación de la arquitectura de la empresa.

• Participar con la alta dirección para entender la i ntención estratégica. La alta dirección tiene una clave para interpretar la visión estratégica. Entender la visión es fundamental para los fines de elaborar la hoja de ruta de la arquitectura de la empresa.

• Conectar con la comunidad de negocios para descubri r las necesidades urgentes. Mientras que la alta dirección puede imaginar el estado futuro de la organización, la comunidad empresarial tiene más respuestas sobre su estado actual. Su objetivo es extraer los hechos y el nivel con las expectativas establecidas por la visión estratégica.

• Construir una comprensión panorámica del entorno de la tecnología existente. La tecnología es un habilitador importante de los procesos de negocio, lo que implica que no irá demasiado lejos sin la comprensión adecuada de su herramienta principal.

• Dibujar el plan de mejora del trabajo. Tener los datos recogidos de diversas fuentes, crear un plan de trabajo para asesorar a las partes interesadas - incluidos los altos directivos, empresas y líderes de la tecnología - sobre cómo va a actuar sobre las necesidades que han comunicado a usted.

• Mantener la arquitectura empresarial actualizada. Después de crear la hoja de ruta para la arquitectura de la empresa y recibir la aprobación de las partes interesadas en él, usted debe hacer el mejor esfuerzo para actualizarlo con el tiempo.

Las metodologías de la empresa y los marcos que existen en la actualidad varían significativamente en el rango de problemas a resolver y los enfoques que toman. Algunos de los marcos más conocidos están TOGAF, EUP, (FEAF), el Marco de Gartner EA, Marco (DoDAF), el Spewak EA Metodología de Planificación, y el Marco Zachman .

TOGAF

HISTORIA Y EVOLUCIÓN

TOGAF es un marco de arquitectura para empresa que surgió durante las dos últimas décadas con el objetivo de convertirse en un estándar para el desarrollo de la arquitectura empresarial.

Fue creado por los miembros del consorcio Open Group, TOGAF no siempre ha incorporado un enfoque holístico de arquitectura empresarial, puesto que inicialmente, sólo se incluye en TOGAF las arquitecturas técnicas (versiones 1 a 7), sin embargo, recientemente, el dominio de la arquitectura de negocios fue implantado en el marco (v. 8, Enterprise Edition), que fue impulsado rápidamente entre las opciones de marcos para arquitecturas empresariales de hoy en día (ver Figura 1).

Figura 1: Arquitectura de dominios TOGAF. (http://www.ibm.com/developerworks/rational/library /jan07/temnenco/index.html)

Actualmente, TOGAF se encuentra en su versión 9, lanzada en Febrero del 2009, esta fue un cambio evolucionario respecto a la versión 8. Este marco es gratuito para organizaciones sin ánimo de lucro.

Línea Temporal Evolutiva.

• 1995: TOGAF V1.0: Prueba de concepto • 1996: TOGAF V2.0: Prueba de aplicación

• 1997:TOGAF V3.0: Relevancia a la arquitectura practica (Bloques de construcción)

• 1998: TOGAF V4.0: Continuum Empresarial (TOGAF en contexto) • 1998: The Open Group se encarga de TAFIM • 1999: TOGAF V5.0: Escenarios de Negocio (Requerimientos de

arquitectura) • 2000: TOGAF V 6.0: Vistas de arquitectura (IEEE Std. 1471) • 2001: TOGAF V7.0 Technical Edition: Principios de Arquitectura, Análisis

de Cumplimiento (Compliance Review) • 2003: TOGAF 8.0 Enterprise Edition: Extensión a la arquitectura

empresarial. • 2003: TOGAF 8.1: Administración de requerimientos; Gobernanza,

Modelos de Madurez, Framework de Habilidades. • 2005: Programa de certificación TOGAF iniciado • 2006: TOGAF 8.1.1: Se aplico la corrección técnica 1 (Technical

Corrigendum 1)

DESCRIPCIÓN GENERAL DE LA TEMÁTICA

El papel de TOGAF

TOGAF en su versión Enterprise Edition sigue siendo lo que siempre ha sido, un marco de arquitectura, un conjunto de métodos y herramientas para el desarrollo de una amplia gama de diferentes arquitecturas de TI. Se permite a los usuarios diseñar, evaluar y construir la arquitectura adecuada para su organización, y reduce los costos de planificación, diseño e implementación de arquitecturas basadas en soluciones de sistemas abiertos.

La clave para TOGAF sigue siendo un método práctico fiable, como lo es el Método de Desarrollo de arquitectura TOGAF (ADM) para definir las necesidades del negocio y el desarrollo de una arquitectura que responda a esas necesidades, utilizando los elementos de TOGAF y otros activos de arquitectura a disposición de la organización.

A pesar de que existen una serie de estructuras empresariales, no existe un estándar aceptado para el método de desarrollo de arquitectura empresarial de la industria. El objetivo de The Open Group con TOGAF es trabajar para que el ADM TOGAF este sólo como un método estándar de la industria, que es neutral respecto a las herramientas y tecnologías, y se puede utilizar para el desarrollo de los productos asociados con un marco empresarial reconocido, como el Zachman

Framework, Federal Enterprise Architecture Framework (FEAF), (TEAF), y Marco C4ISR/DoD.

El ADM TOGAF por lo tanto no prescribe ningún conjunto específico de las prestaciones de arquitectura de la empresa. Por el contrario, TOGAF está diseñado para ser usado con cualquier conjunto de resultados con los que el usuario crea más apropiados. Ese puede ser el conjunto de resultados descritos en TOGAF, o puede ser el conjunto asociado con otro marco, como el Marco Zachman, FEAF, etc.

Con la migración de TOGAF a un marco de arquitectura de la empresa, esta flexibilidad se vuelve aún más importante. TOGAF no pretende competir con otros marcos, sino que está destinado a desempeñar un papel único, en destilar lo que estos marcos ofrecen, y proporcionar un ADM genérico que pueda ser adaptado para su uso con cualquiera de estos otros marcos.

La visión de The Open Group's TOGAF es como un vehículo y depósito de la experiencia basada en información práctica sobre cómo hacer el proceso de arquitectura empresarial, proporcionando un método genérico con el que conjuntos específicos de las prestaciones, modelos de referencia específicos, y otros bienes arquitectónicos relevantes, se pueden integrar.

TOGAF y Arquitectura de Gobierno

Como el gobierno se ha convertido en un requisito cada vez más visibles para la gestión de la organización, la adopción de la gobernanza en el marco TOGAF se alinea con las prácticas comerciales más actuales y también asegura un nivel de visibilidad, orientación y control que apoyará todas las necesidades de los interesados la arquitectura y obligaciones.

Los beneficios de la arquitectura de la gobernanza son:

• Una mayor transparencia de la contabilidad e informe de la delegación de la autoridad

• Gestión de control de riesgos • Protección de la base de activos existentes a través de la maximización de

la reutilización de los componentes actuales de la arquitectura • Control proactivo, monitoreo y mecanismos de gestión • Proceso, concepto, y reutilización de componentes en todas las unidades

de negocio de la organización • La creación de valor a través del monitoreo, medición, evaluación y

retroalimentación • Mayor visibilidad de apoyo a los requisitos de los procesos internos y

externos

En particular, el aumento de la visibilidad de la toma de decisiones en los niveles inferiores supervisado a un nivel apropiado de las decisiones dentro de la empresa que pueden llegar a tener consecuencias estratégicas.

• Mayor valor para el accionista

En particular, la arquitectura de la empresa representa cada vez más la propiedad intelectual central de la empresa.

Los estudios han demostrado una correlación entre el aumento de valor para los accionistas y las empresas bien dirigidas.

• Se integra con los procesos y las metodologías existentes y complementa la funcionalidad mediante la adición de capacidades de control

DESARROLLO DE LA TEMATICA

El ciclo de desarrollo de la arquitectura (ADM) Es importante anotar que, existen otras dos partes principales TOGAF, además de las ADM:

• El Contínuum Empresarial, que se trata de un "marco de trabajo dentro de un marco" que proporciona el contexto para la movilización de activos de la arquitectura relevante y proporciona ayuda de navegación cuando las discusiones se mueven entre los distintos niveles de abstracción.

• El Repositorio de la Arquitectura TOGAF, que se trata de un conjunto de recursos - directrices, plantillas, listas de verificación, y otros materiales detallados - el apoyo al ADM TOGAF.

Los siguientes son los puntos clave sobre el ADM:

• El ADM es iterativo, sobre todo el proceso, entre las fases, y dentro de las fases. Para cada iteración de la ADM, una nueva decisión debe ser tomada como a:

o La amplitud de la cobertura de la empresa a definir o El nivel de detalle que se define o La extensión del horizonte temporal, incluyendo el número y el

alcance de horizontes temporales intermedios o El patrimonio arquitectónico se encuentra en el Contínuum

Empresarial de la organización, incluyendo:

� Los bienes creados en las iteraciones anteriores del ciclo de ADM en la empresa

� Los activos disponibles en otras partes de la industria (otros marcos, modelos de sistemas, modelos verticales de la industria, etc.)

• Estas decisiones deben hacerse sobre la base de una evaluación práctica de la competencia y la disponibilidad de recursos, y el valor que realmente puede ser esperado recibir de la empresa del ámbito de aplicación elegido de la obra de arquitectura.

• Como un método genérico, la ADM está destinado a ser utilizado por las empresas en una amplia variedad de geografías diferentes y se aplica en diferentes tipos de sectores verticales de la industria. Como tal, puede ser, pero no necesariamente tienen que ser adaptadas a necesidades concretas. Por ejemplo:

o Puede ser usado en conjunción con el conjunto de resultados de otro marco, cuando se han considerado más apropiados para una organización específica. (Por ejemplo, muchas agencias federales de EE.UU. han desarrollado marcos individuales que definen las prestaciones específicas a sus necesidades departamentales en particular).

o Puede ser utilizado conjuntamente con el conocido Zachman Framework, que es un esquema de clasificación excelente, pero carece de una disposición abierta, definida metodología bien.

Estructura básica

A lo largo del ciclo de ADM, es necesario que haya frecuentes validación de los resultados contra las expectativas iniciales, tanto los del ciclo de ADM conjunto, y los de la fase específica del proceso.

Figura 2: Arquitectura del Ciclo de Desarrollo

Fase preliminar:

Aquí se describe el marco de la arquitectura y la definición de principios.

Los objetivos de la fase preliminar son:

• Asegurarse de que todos los que estarán involucrados, o se benefician de este enfoque está comprometida con el éxito del proceso arquitectónico

• Definir los principios de arquitectura que se informará a las limitaciones de cualquier obra de arquitectura

• Definir la "huella de la arquitectura" para la organización, donde se encuentran, y sus responsabilidades.

• Definir el alcance y los supuestos (sobre todo en un entorno de arquitectura federada)

• Definir el marco y metodologías detalladas que se van a utilizar para desarrollar arquitecturas de empresa en la organización en cuestión (por lo general, una adaptación de los genéricos ADM)

• Configurar y monitorear un proceso (normalmente incluido un proyecto piloto) para confirmar la idoneidad para el propósito del marco definido

• Si es necesario, definir un conjunto de criterios para evaluar las herramientas de arquitectura, depósitos y gestión de procesos de depósito que se utiliza para capturar, editar y mantener los artefactos arquitectura

Enfoque

Esta fase preliminar es sobre la definición de "cómo hacer arquitectura" de la empresa en cuestión. Hay dos aspectos principales: la definición del marco que se utilizará, y la definición de los principios de arquitectura que va a informar a cualquier obra de arquitectura.

El enfoque de la empresa a la reutilización de los activos de la arquitectura es una parte fundamental tanto de la definición del marco y los principios de la arquitectura. (Por lo general los principios que enuncian la política de reutilización, y el marco se explica cómo la reutilización que se lleva a cabo.)

En las arquitecturas federadas, los requisitos de una arquitectura de nivel superior se manifiestan a menudo como "principios" en el nivel más bajo de la arquitectura.

Principios

La fase preliminar define la arquitectura de principios que formarán parte de las limitaciones de cualquier obra de arquitectura realizada en la empresa. Arquitectura de trabajo es informada por los principios de negocios, así como los principios de la arquitectura.

Los principios de la arquitectura son también normalmente basados en parte en los principios de negocios.

La definición de principios de negocios normalmente se encuentra fuera del ámbito de la función de la arquitectura. Sin embargo, dependiendo de cómo estos principios se definen y promulgada dentro de la empresa en cuestión, puede ser posible para el conjunto de los principios de la arquitectura para reiterar también, o remiten a un conjunto de principios de negocio, los objetivos de negocio, y los conductores de negocios estratégicos definidos en otros lugares dentro de la empresa. (Dentro de un proyecto de arquitectura, el arquitecto normalmente se necesita para asegurar que las definiciones de estos principios empresariales, las metas estratégicas y los conductores están al día, y para aclarar las áreas de ambigüedad.)

La cuestión de la arquitectura de la gobernanza está estrechamente ligada a la de los principios de la arquitectura. El organismo responsable de la gestión pública también suele ser el responsable de aprobar los principios de la arquitectura, y para resolver los problemas de arquitectura.

Marco

El Método de Desarrollo de Arquitectura TOGAF (ADM) es un método genérico, destinado a ser utilizado por las empresas en una amplia variedad de tipos de industrias y geografías. También está diseñado para su uso con una amplia

variedad de otros marcos de arquitectura de la empresa, si es necesario (aunque se puede utilizar perfectamente en su derecho propio, sin adaptación).

La fase preliminar por lo tanto implica realizar cualquier trabajo necesario para adaptar las ADM para definir un marco específico de la organización, utilizando las prestaciones TOGAF o las prestaciones de otro marco.

Entradas

Las entradas para la fase preliminar son:

• Métodos de Desarrollo de Arquitectura TOGAF (ADM) • Otro(s) marco de la arquitectura, si es necesario • Estrategia de negocio, los principios de negocio, los objetivos de negocio y

los impulsores de negocio, pre-existentes • Estrategia de gobierno de TI, pre-existentes • Principios de Arquitectura, pre-existentes • Principios que se están suscritos, derivados de otras arquitecturas,

federados

Pasos

El ADM TOGAF es un método genérico, destinado a ser utilizado por una amplia variedad de diferentes empresas, y en conjunto con una amplia variedad de marcos de cualquier otra arquitectura, si es necesario. No es práctico para definir las medidas concretas de adaptación de las ADM a una variedad tan amplia de los contextos posibles.

Productos

Los resultados de la fase preliminar son:

• Definición del Marco • Principios de la arquitectura • Actualización de, o referencia a los principios de negocio, los objetivos de

negocio, y los conductores de negocios

Visión de arquitectura:

Define el ámbito de la arquitectura, cómo crear la visión, y obtener aprobaciones.

Los objetivos de la fase A son:

• Asegurar que esta evolución del ciclo de desarrollo de la arquitectura tiene un adecuado reconocimiento y la aprobación de la gestión corporativa de la empresa, y el apoyo y el compromiso de la gerencia de línea necesario

• Validar los principios de negocio, los objetivos de negocio, y los conductores de negocios estratégicos de la organización

• Definir el alcance, e identificar y priorizar los componentes de la, el esfuerzo de referencia Arquitectura

• Definir las partes interesadas y sus preocupaciones y objetivos • Definir los requisitos de negocio clave que deben abordarse en este

esfuerzo de la arquitectura, y las limitaciones que deben ser tratados • Articular una visión de Arquitectura que demuestra una respuesta a los

requisitos y limitaciones • Asegurar la aprobación formal para proceder • Entender el impacto en y de, otros ciclos de desarrollo empresarial

arquitectura en curso en paralelo

Enfoque

La fase comienza con la recepción de una solicitud de Arquitectura de trabajo de la organización que patrocina a la organización arquitectura.

Los desafíos de la hora de garantizar el adecuado reconocimiento y la aprobación de la gestión empresarial, y el apoyo y el compromiso de la gestión de la línea.

La fase A también define lo que es y lo que está fuera del alcance de los esfuerzos de la arquitectura y las limitaciones que deben ser tratados. Las decisiones de alcance tienen que hacer sobre la base de una evaluación práctica de la competencia y la disponibilidad de recursos, y el valor que realmente puede ser esperado recibir de la empresa del ámbito de trabajo elegido arquitectura.

Las restricciones que normalmente será informado por los principios de negocios y principios de la arquitectura, que forma parte de la fase preliminar.

Normalmente, los principios de negocio, los objetivos de negocio, y los conductores estratégicos de la organización ya están definidos en otras partes de la empresa. Si es así, la actividad en la Fase A está implicada con la garantía de que las definiciones existentes están al día, y aclarar todas las áreas de ambigüedad. De lo contrario, se trata de la definición de estos elementos esenciales a partir de cero.

Del mismo modo, la arquitectura de principios que informan de las restricciones sobre el trabajo de arquitectura normalmente han sido definidos en la Etapa Preliminar. La actividad en la fase A se ocupa de asegurar que las definiciones de los principios existentes están al día, y aclarar todas las áreas de ambigüedad. De lo contrario, implica la definición de los principios de la arquitectura desde cero.

Arquitectura de Negocio :

Describe el desarrollo de una Arquitectura Empresarial.

Los objetivos de la Fase B son los siguientes:

• Describir la arquitectura de base de negocios

• Desarrollar un objetivo de negocio de Arquitectura, que describe el producto y / o estrategia de servicio, y el de organización, procesos, información funcional y los aspectos geográficos del entorno empresarial, basado en los principios de negocio, los objetivos de negocio, y los conductores estratégicos

• Analizar las diferencias entre las arquitecturas de referencia y de destino de negocios

• Seleccionar los puntos de vista arquitectura pertinentes que permitan el arquitecto para demostrar cómo las preocupaciones de los interesados se abordan en la Arquitectura de Negocios

• Seleccionar las herramientas y técnicas pertinentes para ser utilizado en asociación con los puntos de vista seleccionados

Enfoque

El conocimiento de la arquitectura de negocios es un requisito previo para la obra de arquitectura en cualquier otro ámbito (datos, aplicaciones, tecnología), y por lo tanto la actividad de la primera arquitectura que hay que emprender, si no se recogen ya en otros procesos de organización (planificación de la empresa, planificación estratégica de negocios, de procesos de negocio de re-ingeniería, etc.)

En términos prácticos, la arquitectura de negocios es a menudo necesaria como medio de demostrar el valor comercial de posteriores trabajos de Arquitectura Técnica a los principales interesados, y el retorno de la inversión a las partes interesadas de apoyar y participar en los trabajos posteriores.

La extensión de la obra en la Fase B dependerá en gran medida en el entorno empresarial. En algunos casos, los elementos clave de la arquitectura de negocio se puede hacer en otras actividades, por ejemplo, la misión empresarial, visión, estrategia y objetivos pueden ser documentados como parte de alguna estrategia empresarial más amplia o una actividad de planificación de la empresa que tiene su propio ciclo de vida dentro de de la empresa.

En tales casos, puede haber una necesidad de verificar y actualizar la estrategia de negocio documentado en la actualidad y los planes y / o puente entre el nivel de los conductores de negocios de alto, estrategia de negocios y objetivos, por un lado, y los requisitos de negocio específicos que se pertinentes a este esfuerzo de desarrollo de arquitectura. (La estrategia de negocio normalmente se define lo que para alcanzar - los objetivos y los conductores, y las métricas para el éxito - no cómo llegar allí. Pero eso es el papel de la Arquitectura de Negocios.)

En otros casos, poco o nada de trabajo de Arquitectura de Negocios se pudo haber hecho hasta la fecha. En estos casos, habrá una necesidad de que el equipo de arquitectura a la investigación, verificar, y el aumento de compra en los objetivos clave del negocio y los procesos que la arquitectura es apoyar. Esto se puede hacer como un ejercicio independiente, ya sea desarrollo de la arquitectura anterior, o como parte de la Fase A.

En ambos casos, la técnica de escenarios de negocios de la ADM TOGAF, o cualquier otro método que ilumina los requisitos clave de negocios e indica los requisitos técnicos implícita de la arquitectura de TI, puede ser utilizado.

Un objetivo clave es la reutilización de materiales existentes en la medida de lo posible. En arquitectura ambientes más maduros, no habrá definiciones existentes en la arquitectura, que (con suerte) se han mantenido desde el ciclo de desarrollo de la arquitectura anterior. Cuando las actuales descripciones arquitectónicas existen, estos pueden ser utilizados como punto de partida, y verifica y actualiza si es necesario.

Reunir y analizar sólo la información que permite informó que se tomen decisiones relacionadas con el alcance de este esfuerzo de la arquitectura. Si este esfuerzo se centra en la definición de los nuevos) procesos de negocio, posiblemente (y, a continuación de la fase B necesariamente implican una gran cantidad de trabajo detallado. Si la atención se centra más en las arquitecturas de destino en otros dominios (datos / sistemas de aplicación, la información, infraestructura) para apoyar una esencia existente arquitectura empresarial, entonces es importante para construir una imagen completa en la fase B, sin entrar en detalles innecesarios.

Arquitecturas de sistemas de información

Describe la Arquitectura de Sistemas de Información, incluida la elaboración de datos y arquitecturas de aplicaciones.

El objetivo de la fase C es el desarrollo de Arquitecturas de destino, sea sobre o en ambos (dependiendo del alcance del proyecto) de los datos y los dominios de sistemas de aplicaciones.

El ámbito de aplicación de los procesos de negocio apoyado en la Fase C se limita a aquellos que son apoyados por IT, y las interfaces de los procesos relacionados con la TI a los procesos relacionados con la TI no.

Enfoque

La Fase C consiste en una combinación de datos y aplicaciones de Arquitectura, en cualquier orden. Los defensores existen para ambas secuencias. Por ejemplo, Spewak Enterprise Steven Arquitectura de Planificación (PEA) recomienda un enfoque impulsado por los datos.

Por otro lado, los sistemas de aplicaciones más importantes, tales como los de planificación de recursos empresariales (ERP), gestión de relaciones con clientes, etc., a menudo ofrecen una combinación de la infraestructura tecnológica y la lógica de aplicaciones de negocio, y algunas organizaciones tomar un enfoque impulsado por la aplicación, por el que reconocen ciertas aplicaciones clave que forman el núcleo de apuntalamiento de los procesos de negocio de misión crítica, y tome la implementación e integración de las aplicaciones básicas como el objetivo principal del esfuerzo de la arquitectura (el tema de la integración a menudo constituyen un problema importante).

Arquitectura de Tecnología:

Describe el desarrollo de una arquitectura tecnológica.

El objetivo de la Fase D es el desarrollo de una arquitectura tecnológica que constituirá la base del trabajo de implementación siguiente.

Enfoque

Directrices detalladas para la Fase D, incluyendo las entradas, los pasos, y las salidas.

Oportunidades y soluciones:

Punto de control para verificar la idoneidad para su aplicación.

Los objetivos de la fase E son los siguientes:

• Evaluar y seleccionar entre las opciones de ejecución definidas en el desarrollo de las diversas arquitecturas de destino (por ejemplo, crear frente a comprar frente al utilizar las opciones-re, y sub-opciones dentro de las opciones principales)

• Identificar los parámetros estratégicos para el cambio, y el nivel de paquetes de trabajo-superior o proyectos que se realizarán en el movimiento de la actual entorno a la meta

• Evaluar las dependencias, los costos y beneficios de los diversos proyectos • Generar una aplicación general y la estrategia de migración y un detallado

plan de ejecución

Enfoque

La Fase E identifica los parámetros del cambio, las fases principales en el camino, y el nivel de los proyectos principales que se realizarán en el movimiento del actual entorno a la meta. La salida de la fase E será la base del plan de ejecución necesarios para pasar a la arquitectura. Esta fase también trata de identificar nuevas oportunidades de negocio derivadas de la obra de arquitectura en las fases anteriores.

A veces el proceso de identificar oportunidades de aplicación permite a una empresa para identificar nuevas aplicaciones, y en este caso puede ser necesario para recorrer entre la fase E y las fases anteriores. La Iteración debe ser limitada por el tiempo o el dinero para evitar el desperdicio de esfuerzo en la búsqueda de una arquitectura perfecta.

La Fase E es la primera fase, que está directamente relacionado con la aplicación. La tarea es identificar los principales paquetes de trabajo o proyectos a realizar.

Una manera eficaz de hacer esto es utilizar el análisis de las deficiencias en las funciones de negocio entre el ambiente antiguo y lo nuevo, creado en la Fase D. Las funciones que aparecen como "nuevos" artículos tendrán que ser aplicados (desarrollado o adquirido y desarrollado).

Un poco más difíciles de identificar son los proyectos necesarios para actualizar o reemplazar las funciones existentes que se debe hacer de manera diferente en el nuevo entorno. Una de las opciones a considerar aquí es dejar un sistema existente en el lugar y coexistiendo con el nuevo entorno.

Durante este último paso en la especificación de los bloques de construcción se debe verificar que los requisitos específicos de la organización-se cumplirán. Para ello es fundamental comprobar la razón contra la hipótesis de la conducción del alcance del proyecto. Es importante señalar que el proceso de desarrollo posterior debe incluir el reconocimiento de las dependencias y los límites de funciones y deben tener en cuenta qué productos están disponibles en el mercado.

La estrategia más exitosa para la fase E es centrarse en proyectos que entregará a corto plazo, sobornos y así crear un impulso para continuar con proyectos a largo plazo.

Planificación de migraciones:

Aborda la planificación de la migración, incluyendo la priorización de trabajo, selección de paquetes de trabajo principales, y el desarrollo de un Plan de Migración.

El objetivo de la fase F es clasificar los proyectos de aplicación diferentes en orden de prioridad. Las actividades incluyen la evaluación de las dependencias, los costos y beneficios de los proyectos de migración de varias. La lista priorizada de los proyectos se forma de la base del detallado Plan de Aplicación y el Plan de Migración.

Enfoque

La mayoría de las organizaciones encuentran que un cambio de la arquitectura que se realiza en una sola fase tiene mucho impacto también sobre la organización. La migración a menudo requiere la consideración de una serie de cuestiones técnicas, no por lo de las cuales son las relacionadas con los medios de introducir cambios a los sistemas operativos.

Cuestiones que requieren una consideración especial pueden incluir:

• Operaciones en paralelo • La elección de proceder con la migración en fases, por subsistemas, o por

la función • El impacto de la separación geográfica de la migración

Las decisiones resultantes de estas consideraciones deben ser incorporados en el Plan de Aplicación.

Hay una serie de estrategias para el desarrollo del plan de migración e implementación.

La estrategia básica de mayor éxito es centrarse en proyectos que entregará a corto plazo, sobornos y así crear un impulso para continuar con proyectos a largo plazo.

Un método común consiste en poner en práctica las funciones de negocio en una secuencia cronológica impulsado de datos, es decir, crear las aplicaciones y la

tecnología de apoyo que crean los datos antes de los que procesan los datos, antes de que los que simplemente almacenar, archivar o borrar datos.

Por ejemplo, la siguiente descripción detallada de este enfoque es tomado de la SPE 68794, de ejecución de arquitectura empresarial - Poner calidad de la información en las manos de aceite y el conocimiento de Trabajadores de Gas:

1. Determinar la disposición futura de los sistemas actuales. Cada sistema actual se clasifica como:

o Integrar los sistemas - parte del sistema de información en el futuro. o Contener sistemas - se espera que va a sustituir o modificar en el

horizonte de planificación (tres años). o Reemplazar los sistemas - que ser sustituido en el horizonte de

planificación.

Las decisiones del sistema actual de disposición deben ser hechas por los empresarios, no gente de TI.

2. Las solicitudes se deben combinar o dividir en partes para facilitar la secuenciación y la aplicación. Esta reordenación de las aplicaciones crea una serie de proyectos, un proyecto equivalente a una solicitud o de combinaciones o de partes de las solicitudes.

3. Desarrollar la secuencia de datos para los proyectos descritos en la arquitectura de datos. Uso de CRUD (Crear / Leer / Actualizar / Borrar) matriz desarrollada como parte de la arquitectura de datos, la secuencia de los proyectos de tal manera que los proyectos que crean los datos que preceden a los proyectos de leer o actualizar los datos.

4. Desarrollar un valor estimado de la empresa para cada proyecto. Para ello, en primer lugar desarrollar una matriz basada en una dimensión índice de valor y una dimensión índice de riesgo. El índice de valor incluye los siguientes criterios: el cumplimiento de los principios, que incluye la contribución financiera, la alineación estratégica, y la posición competitiva. El índice de riesgo incluye los siguientes criterios: tamaño y complejidad, tecnología, capacidad organizativa, y el impacto de un fracaso. Cada uno de los criterios tiene un peso individual. El índice y sus criterios y la ponderación se han desarrollado y aprobado por la alta dirección al principio del proyecto. Es importante establecer los criterios de toma de decisión antes de que las opciones se conocen.

Además, habrá factores clave de negocio que deben abordarse, que también tienden a dictar la orden de ejecución, tales como:

• Reducción de los costes • Consolidación de los servicios • Capacidad para manejar el cambio

Implementación de Gobernanza:

Proporciona una arquitectura de supervisión de la aplicación.

Los objetivos de la fase G son los siguientes:

• Formular recomendaciones para cada proyecto de implementación. • Construir un Contrato de Arquitectura para regir la aplicación general y el

proceso de implementación. • Desempeñará las funciones de gobierno que mientras el sistema está

siendo implementado y desplegado. • Asegurar la conformidad con la arquitectura definida por los proyectos de

ejecución y otros proyectos.

Enfoque

Es aquí donde toda la información para la gestión exitosa de los proyectos de aplicación diferentes se reúne. Tenga en cuenta que en paralelo con la fase G no es la realización de un específico proceso de desarrollo de toda la Organización, donde el desarrollo real sucede.

La Fase G establece la conexión entre la arquitectura y la organización de la aplicación, a través del Contrato de Arquitectura.

Detalles del proyecto se desarrollan, entre ellos:

• Nombre, descripción y objetivos • Ámbito de aplicación, los resultados, y las limitaciones • Las medidas de eficacia • Criterios de aceptación • Riesgos y problemas

La aplicación de gobierno está estrechamente vinculada a la arquitectura de gobernanza global.

Un aspecto clave de la fase G es garantizar el cumplimiento de la arquitectura definida (s), no sólo por los proyectos de aplicación, sino también por otros proyectos en curso dentro de la empresa.

Arquitectura de administración del cambio:

Analiza el establecimiento de procedimientos para gestionar el cambio a la nueva arquitectura.

El objetivo de la fase H es establecer un cambio de arquitectura de procesos de gestión de la línea de base de la empresa nueva arquitectura que se logra con la finalización de la Fase G. Este proceso normalmente se encargará de la supervisión continua de las cosas tales como los nuevos avances tecnológicos y los cambios en el negocio medio ambiente, y para determinar si ha de iniciar formalmente un ciclo de evolución de la arquitectura nueva.

La fase H también prevé cambios en el marco y los principios establecidos en la Etapa Preliminar.

Enfoque

El objetivo de un cambio en el proceso de gestión de la arquitectura es para asegurar que los cambios en la arquitectura se gestionen de forma coherente y arquitectura, así como establecer y apoyar la arquitectura de la empresa implementa como una arquitectura dinámica, es decir, uno que tiene la flexibilidad para evolucionar rápidamente en respuesta a los cambios en la tecnología y el entorno empresarial.

El proceso de gestión del cambio, una vez establecido determinará:

• Las circunstancias en las que la arquitectura o partes de ella, permiten el cambio después de su implementación, y el proceso por el cual va a pasar.

• Las circunstancias en las que la arquitectura ciclo de desarrollo que se inició de nuevo la empresa para desarrollar una nueva arquitectura

El cambio de arquitectura de procesos de gestión está íntimamente relacionado con la arquitectura de los procesos de gobernanza de la empresa, y para la gestión del Contrato de Arquitectura entre la función de la arquitectura y los usuarios de negocios de la empresa.

En la fase H es fundamental que el gobierno establezca los criterios para juzgar si se necesita una solicitud de cambio o sólo una actualización de la arquitectura o si amerita iniciar un nuevo ciclo del método de desarrollo de la Arquitectura (ADM). Es especialmente importante evitar la "progresiva elegancia", y el órgano de gobierno debe continuar para buscar los cambios que se relacionan directamente con el valor del negocio.

Directrices para el establecimiento de estos criterios son difíciles de establecer, ya que muchas empresas acepten el riesgo de manera diferente, pero como la ADM se ejerce, el nivel de madurez de los miembros del gobierno va a mejorar, y los criterios se harán evidentes para necesidades específicas.

Contínuum Empresarial

Este concepto se encarga de manejar un amplio contexto para un arquitecto, el cual explica como una solución genérica puede ser utilizada y especializada de tal manera que soporte los requerimientos de una organización individual. El Continuum empresarial es la vista del Repositorio de la Arquitectura el cual provee métodos para clasificar arquitecturas y soluciones, mientras están evolución desde Fundamentos Genéricos de Arquitectura hasta Arquitecturas Especificas para una organización. Este concepto viene acompañado de dos partes complementarias: El continuum de arquitectura y el continuum de soluciones.

Repositorio de la Arquitectura

Brindarle soporte al continuum empresarial es el concepto que el repositorio maneja, por esto, este puede ser utilizado para almacenar diferentes clases de output de la arquitectura a diferentes niveles de abstracción creados por el ADM. De esta manera TOGAF facilita el entendimiento y la cooperación entre inversionistas y practicantes en diferentes niveles.

Herramientas Certificadas de TOGAF 8

Podemos utilizar multiples herramientas de software para soportar el uso de este framework.

• EVA Netmodeler • IDS Scheer • BiZZdesign Architect • Avolution ABACUS 3.x o reciente • Casewise Corporate Modeller 10.3 o reciente • Flashmap Systems IT atlas v1 • Future Tech Systems, Inc. • MEGA International • Metastorm ProVisionEA Version 6 o reciente • IBM Rational System Architect 10 o reciente • Salamander MOOD 2006 o reciente • Troux Metaverse 7.1 o reciente • Sparx Systems

Comparación con COBIT

COBIT (Control objetivo sobre información y tecnologías relacionadas) tiene como objetivo ayudar a las empresas a mapear sus procesos de TI siguiendo los procesos de ISACA (Information Systems Audit and Control Association / Auditoria de Sistemas de Información y asociación de control) la cual es una organización sin ánimo de lucro que se encarga del área de gobernanza del TI. Este se elige comúnmente por la empresa que va a realizar la auditoria informática, sin importar si esta es financiera o de sistemas informáticos.

COBIT contiene 4 Procesos distribuidos en 34 dominios, mientras que TOGAF cuenta con 4 dominios sin procesos directos.

COBIT puede ser orientado de tal manera que sirva de soporte a una auditoria, TOGAF funciona mas como un proceso general para la construcción de una arquitectura empresarial.

Se relacionan porque ayudan para que la TI tenga éxito en satisfacer los requerimientos del negocio mediante las siguientes características:

� Estableciendo un vínculo con los requerimientos del negocio � Identificando los principales recursos de TI a ser utilizados � Definiendo los objetivos de control gerenciales a ser considerados

Una gran fortaleza de TOGAF es que es completamente abierto y trata de ser neutro respecto a les implementaciones, evitando posibles problemas a futuro por ello.

TOGAF no se enfoca en la gobernanza de TI, pues este se sale del alcance de un framework de arquitectura empresarial, COBIT tiene unos excelentes recursos cuando se trata de esto, también podemos destacar el manejo que este tiene con las practicas de control y seguridad.

COBIT, presenta también conceptos de Modelos de Madurez, Factores de Éxito Critico, Indicadores de Metas, entre otros no presentes en TOGAF.

ZACHMAN FRAMEWORK

Zachman Framework es un framework de arquitectura empresarial, el cual provee una manera formal y sumamente estructurada de ver y definir en qué consiste una empresa.

Este fue creado por John Zachman en los 1980’s, quien se encontraba trabajando en IBM en Business System Planning (Sistema de planeación de Negocios o BSP), el cual consistía en un método para analizar, definir y diseñar una arquitectura de información para una organización.

En 1982 Zachman había concluido estos análisis los cuales podían hacer mucho más que automatizar diseños de sistemas y manejar datos en el campo de la planeación estratégica de negocios y la administración. Estos podían ser utilizados en las áreas más problemáticas y ‘esotéricas’ en esas épocas, por ejemplo arquitectura, diseño de sistemas basados en datos, criterio de clasificación de datos y mucho más.

En el artículo de 1987 “A Framework for Information Systems Architecture” (Un framework para una arquitectura de un SI), Zachman resalto como el término ‘arquitectura’ el cual era usado de manera común por profesionales de sistemas de información y como este tenía un significado completamente diferente para planeadores, diseñadores, programadores, entre otros. Por ello, Zachman se dedico a desarrollar un Framework para arquitecturas de información, el analizó el campo de la arquitectura clásica al igual que múltiples proyectos complejos de ingeniería, de esta manera pudo ver que siempre existía una aproximación inicial similar, concluyendo que las arquitecturas existen en múltiples niveles e involucran por lo menos tres perspectivas: Materiales en bruto o datos, funciones de procesos y localizaciones o redes.

Esta arquitectura está diseñada para ser un esquema de clasificación para organizar modelos de arquitectura. Proveía una manera sinóptica de los modelos que se necesita para la arquitectura empresarial. Information Systems Architecture no define en detalle los modelos que debería contener, no reforzaba el lenguaje de modelaje usado para cada modelo y no proponía un método para crearlos.

En 1992 se presento el framework mejorado con sus nuevas extensiones y se demostró como éste podía ser formalizado en la notación de gráficos conceptuales.

En 1997, Zachman aclaro como el framework se le debería llamar “Framework for Enterprise Architecture” (Framework para Arquitectura Empresarial). Como podemos ver existen múltiples propuestas de framework hechas por Zachman, cada vez que se refieren a un ‘Framework de Zachman’ se pueden referir a cualquier de los propuestos por el, los cuales podemos definir de esta manera:

• El framework inicial, nombrado “A Framework for Information Systems Architecture” en 1987

• “The Zachman Framework for Enterprise Architecture” de 1990, año en el cual este fue actualizado y renombrado.

• O una de las versiones recientes, ofrecidas por Zachman International como estándar de la industria.

En 1984, se propuso la primera versión del framework, a pesar del paso del tiempo los conceptos no han cambiado, simplemente se ha refinado la representación grafica.

Figura 3 (www.zachmaninternational.us/index.php)

En 1992, el framework ya era conocido como “Framework for Information Systems Architecture”. Esta versión también consta de 3 columnas ya que no existía el concepto de pensamiento empresarial.

Figura 4 (www.zachmaninternational.us/index.php)

En el 2001, ya se conocía como “Zachman Framework”, contaba con múltiples refinamientos y era ampliamente usada y distribuida.

Figura 5 (www.zachmaninternational.us/index.php)

Esta es la versión del año 2008, la más reciente y que cuenta con múltiples cambios significativos respecto a sus versiones anteriores. Se elimina el modelo global, no se usan adjetivos y es predominante la terminología empresarial. La terminología en azul fue elegida de manera que se incluyeran nombres de ‘Enterprise’ y ‘Normative Zachman Frameworks’.

En general, se han cambiado múltiples aspectos estéticos, pero ¿Qué no ha cambiado?

• La teoría del Framework: Todas las representaciones descriptivas pueden ser expresadas en términos de cosas y sus relaciones

• La Lógica del Framework • Cada celda primitiva contiene dos entidades meta (meta, meta) y una cosa

y una relación • Comprensiva y completa

Figura 6 (www.zachmaninternational.us/index.php)

DESCRIPCIÓN GENERAL DE LA TEMÁTICA

La idea general en el Zachman Framework es que una cosa compleja o ítem puede ser descrita para diferentes propósitos de maneras diferentes usando tipos diferentes de descripciones (textos, graficas). El framework provee 36 categorías necesarias para describir de manera completa cualquier cosa, especialmente, cosas complejas como bienes manufacturados (componentes electrónicos, por ejemplo), estructuras construidas (Edificios) y empresas (la organización y todos sus objetivos, gente y tecnologías). Este contiene seis vistas detalladas o niveles de abstracción desde 6 perspectivas diferentes.

De esta manera, diferentes personas pueden mirar a la misma cosa de manera diferente, esto crea una vista holística del entorno, una capacidad sumamente importante.

DESARROLLO DE LA TEMÁTICA

Vistas o Filas

Cada fila representa una vista total de la solución desde una vista particular. Una fila superior o perspectiva no tiene necesariamente un entendimiento de toda la perspectiva inferior. Cada fila representa una perspectiva única, sin embargo, los contenidos de cada perspectiva deben proveer suficiente detalle para definir la solución al nivel de la perspectiva y estos se deben transferir a la próxima fila inferior.

Cada perspectiva debe tener en cuenta los requerimientos de las otras perspectivas y las limitaciones que estás imponen. Las limitaciones de cada perspectiva se suman. Por ejemplo, las limitaciones de las filas superiores afectan a las inferiores. Las limitaciones de las filas inferiores pueden, pero no necesariamente afectan las filas superiores.

Entender los requerimientos y limitaciones implica conocimiento y entendimiento de perspectiva a perspectiva.

Figura 7 (http://www.zifa.com/framework.pdf

Esta versión simplificada nos servirá para explicar el funcionamiento del framework.

Fila 1: Vista de Planeación / Alcance: El primer borrador de arquitectura es un diagrama de Venn el cual muestra en términos de tamaño, forma, relaciones parciales y elestructura. Corresponde a un sumario ejecutivo para un planeador o inversionista que requiere una perspectiva general del sistema, cuánto costaría y como se relacionaría con el sistema general donde este operaria.

Figura 7 (http://www.zifa.com/framework.pdf)

Esta versión simplificada nos servirá para explicar el funcionamiento del

Vista de Planeación / Alcance: El primer borrador de arquitectura es un diagrama de Venn el cual muestra en términos de tamaño, forma, relaciones parciales y el propósito final de la estructura. Corresponde a un sumario ejecutivo para un planeador o inversionista que requiere una perspectiva general del sistema, cuánto costaría y como se relacionaría con el sistema general donde este operaria.

Esta versión simplificada nos servirá para explicar el funcionamiento del

El primer borrador de arquitectura es un diagrama de Venn el cual muestra en propósito final de la

estructura. Corresponde a un sumario ejecutivo para un planeador o inversionista que requiere una perspectiva general del sistema, cuánto costaría y como se

Fila 2: Vista del Propietario / Modelo Empresarial: Corresponden a los modelos de la empresa/negocio, los cuales constituyen los diseños del negocio y muestran las entidades del negocio y como se relacionan los procesos.

Fila 3: Vista del Diseñador / Modelo de sistema de información: Los planes del arquitecto son la traducción de los dibujos o representaciones detalladas de los requerimientos desde una perspectiva de un diseñador. Ellos corresponden al modelo del sistema diseñado por un Analista el cual debe determinar los elementos de datos, el flujo de la lógica de los procesos y las funciones que representan entidades o procesos de negocios.

Fila 4: Vista del Constructor / Modelo Tecnológico: El contratista debe redibujar los planes del arquitecto para representar la perspectiva del constructor con suficiente detalle para entender las limitaciones de las herramientas, tecnologías y materiales. Los planes corresponden a los modelos tecnológicos, los cuales se deben adaptar al modelo de sistemas de información, estos tienen en cuenta los lenguajes de programación, los dispositivos de I/O u otra tecnología e soporte.

Fila 5: Vista del Subcontratista / Especificación D etallada: Los subcontratistas trabajan desde plantas, en las cuales se especifican los detalles en partes o sub secciones. Estas corresponden a las especificaciones detalladas que se les dan a los programadores que desarrollan modelos específicos sin tener en cuenta el contexto general. Alternativamente pueden representar soluciones COTS o GOTS (soluciones ya listas, empresariales o gubernamentales).

Fila 6: Vista del Sistema Actual / Empresa en Funci onamiento

Enfoques o Columnas

En resumen, cada perspectiva le da enfoque a una pregunta fundamental donde estas se resuelven desde ese punto, creando diferentes representaciones (modelos), lo cual se interpreta desde perspectivas de alto a bajo nivel.

Cuenta con seis categorías con sus respectivas interrogativas:

1. Descripción de datos – ¿Qué?

2. Descripción de función – ¿Cómo? 3. Descripción de Redes – ¿Dónde? 4. Descripción del personal – ¿Quién? 5. Descripción del tiempo – ¿Cuándo? 6. Descripción de la motivación – ¿Porqué?

Modelos o Celdas

Los modelos se hacen explícitos en las intersecciones entre filas y columnas, a estas se les conoce como celdas, las cuales son únicas, su contenido es normalizado según el enfoque de la perspectiva.

Las descripciones de estas utilizan un lenguaje general enfocado a un set específico de objetivos.

Contexto

1. Porqué – Lista Objetivos: Provee objetivos organizacionales de alto nivel 2. Cómo – Lista Procesos: Se listan todos los procesos conocidos 3. Qué – Lista de Materiales: Lista todas las entidades organizacionales

conocidas 4. Quién – Lista de Roles y Unidades: Lista todas las unidades de la

organización, subunidades y roles identificados. 5. Dónde – Lugares Geográficos: Localidades importantes para el negocio 6. Cuándo – Lista Eventos: Lista de disparadores y ciclos importantes para la

organización

Conceptual

1. Porqué – Relación de Objetivos: Identifica una jerarquía de metas que soportan los objetivos primarios.

2. Cómo – Modelo de prácticas: Provee descripciones de los procesos, las entradas y salidas.

3. Qué – Modelo entidad relación: Identifica y describe los materiales organizacionales y sus relaciones

4. Quién – Modelo Relación de Roles: identifica roles de la empresa y sus unidades, al igual que las relaciones existentes.

5. Dónde – Modelo de localidades: Identifica las localidades de la empresa y sus relaciones

6. Cuándo – Modelo de eventos: Identifica y describe eventos y ciclos relacionados por el tiempo.

Lógico

1. Porqué– Diagrama de Reglas: identifica y describe las reglas que tiene restricciones a procesos sin importan la implementación físico-técnica.

2. Cómo – Diagrama de Procesos: Identifica y describe transiciones de procesos expresadas como frases verbo-sustantivo sin importar implementación física-técnica.

3. Qué – Diagrama de Roles: Identifica y describe entidades y sus relaciones sin importar implementación física-técnica.

4. Quién – Diagrama de Relación de Roles: Identifica roles y sus relaciones a otros roles por los tipos de materiales que se obtienen en sus procesos sin importar implementación física-técnica.

5. Dónde – Diagrama de Localidades: Identifica y describe las localizaciones usadas para acceder, manipular y transferir entidades y procesos sin importar implementación física-técnica.

6. Cuándo – Diagrama de Eventos: Identifica y describe eventos que se relacionan de manera secuencial, al igual que los ciclos que ocurren entre eventos, sin importar implementación física-técnica.

Físico

1. Porque – Especificación de Reglas: Expresadas en lenguaje formal, consisten de un nombre de la regla y su lógica estructurada para especificar y probar el estado de la regla.

2. Como – Especificación Función de Proceso: Expresada en un lenguaje específico según su tecnología, los procesos jerárquicos se relacionan por llamadas a procesos.

3. Que – Especificación Entidades de Datos: Expresado en un formato específico según su tecnología, cada entidad se define por nombre, descripción y atributos mostrando sus relaciones.

4. Quien – Especificación Roles: Expresa los trabajos que los roles desempeñan al igual que los componentes del workflow

5. Donde – Especificación Localidad: Expresa la infraestructura física, componentes y conexiones

6. Cuando – Especificación Eventos: Expresa transformaciones de los estados y los eventos de interés a la empresa.

COMPARACIÓN CON COBIT

Zachman como tal no es un framework, es más una taxonomía, con la cual se organizan los artefactos de la arquitectura, es decir documentos de diseño, especificaciones y modelos. Esto tiene en cuenta los objetivos de este y el problema a tratar.

Por esta razón, este framework es destacable para clasificar toda la estructura de una empresa de manera inteligente y ordenada, pero el manejo de procesos es pobre y se trata de manera superficial.

La gobernanza se ignora en múltiples ocasiones y como mencionamos en el comparativo con TOGAF, COBIT se destaca en esta área. Ambos frameworks tienen problemas por la manera en que están diseñados, pues es fácil quedarse atrapado en normas específicas de ambas industrias.

COBIT tiene mejor información disponible, al igual que capacitaciones que Zachman.

RESUMEN DEL TRABAJO

TOGAF

Es un framework de arquitectura que ha sido desarrollado por el Architecure Forum del Open Group y ha evolucionado continuamente desde mediado de los 90.

TOGAF busca ser una aproximación al desarrollo de arquitecturas y al gobierno de manera “Ágil”. No prescribe los modelos que deberían ser usados para representar la arquitectura, guía el proceso cuando esta sea crea. Debido a su escalabilidad, puede ser usado por organizaciones de gobierno, empresas pequeñas, medianas o grandes. Al mirar a los múltiples niveles que puede soportar el framework, TOGAF trata de soportar todos, desde la arquitectura de negocios, hasta arquitectura de datos y tecnológica.

Es muy importante destacar que el framework es modificado por todos sus usuarios, como pasa con un producto Open Source, sin olvidar nunca la retroalimentación y la información obtenida en procesos de la vida real.

Este está compuesto por múltiples herramientas, de las cuales se destacan:

• Método de Desarrollo de Arquitectura (ADM) La ADM puede ser descrita como una secuencia de pasos repetibles con las cuales se define la arquitectura de la empresa, cuenta con 9 fases:

� Fase Preliminar � Fase A: Visión de Arquitectura � Fase B: Arquitectura de Negocio � Fase C: Arquitectura de Sistemas de Información � Fase D: Arquitectura Tecnológica � Fase E: Oportunidades y Soluciones � Fase F: Planeación de Migraciones � Fase G: Implementación de la Gobernanza � Fase H: Gestión de la Arquitectura del Cambio

• Continuum Empresarial

El continuo de la empresa es un conjunto de recursos, tales como modelos, los patrones de solución, y otros activos que pueden ser utilizados como bloques de construcción en todo el proceso de implementación de arquitectura empresarial.

Esencialmente, el proceso continuo de la empresa es análogo a una biblioteca de referencia para profesionales de la arquitectura empresarial y las partes interesadas. Además de las ADM y su continuación en la Empresa, TOGAF provee recursos y referencias adicionales relativas a las técnicas, métodos y soluciones que se pueden utilizar tanto para la planificación e implementación de la arquitectura empresarial.

• Repositorio de la Arquitectura El concepto principal de esta área es brindar soporte a las versiones anteriores, por esto, el repositorio puede ser utilizado para almacenar diferentes clases de output de la arquitectura a diferentes niveles de abstracción creados por el ADM. Creando un terreno medio donde tanto inversionistas como empleados comprendan lo que la empresa está haciendo.

Zachman Framework

Zachman Framework es un framework de arquitectura empresarial, el cual provee una manera formal y sumamente estructurada de ver y definir en qué consiste una empresa.

Este fue creado por John Zachman en los 1980’s, quien se encontraba trabajando en IBM en Business System Planning (Sistema de planeación de Negocios o BSP), el cual consistía en un método para analizar, definir y diseñar una arquitectura de información para una organización. En 1982 Zachman había concluido estos análisis los cuales podían hacer mucho más que automatizar diseños de sistemas y manejar datos en el campo de la planeación estratégica de negocios y la administración.

El framework es descrito por una pequeña tabla la cual ha cambiado poco con el transcurso de los años. Esta contiene unas filas y columnas con las siguientes funciones:

Fila 1: Vista de Planeación / Alcance: Corresponde a un sumario ejecutivo para un planeador o inversionista que requiere una perspectiva general del sistema, cuánto costaría y como se relacionaría con el sistema general donde este operaría.

Fila 2: Vista del Propietario / Modelo Empresarial: Corresponden a los modelos de la empresa/negocio, los cuales constituyen los diseños del negocio y muestran las entidades del negocio y como se relacionan los procesos.

Fila 3: Vista del Diseñador / Modelo de sistema de información: Corresponden al modelo del sistema diseñado por un Analista el cual debe determinar los elementos de datos, el flujo de la lógica de los procesos y las funciones que representan entidades o procesos de negocios.

Fila 4: Vista del Constructor / Modelo Tecnológico: Corresponden a los modelos tecnológicos, los cuales se deben adaptar al modelo de sistemas de información, estos tienen en cuenta los lenguajes de programación, los dispositivos de I/O u otra tecnología de soporte.

Fila 5: Vista del Subcontratista / Especificación D etallada: Estas corresponden a las especificaciones detalladas que se le dan a los programadores que desarrollan modelos específicos sin tener en cuenta el contexto general.

Alternativamente pueden representar soluciones COTS o GOTS (soluciones ya listas, empresariales o gubernamentales).

Fila 6 – Vista del Sistema Actual / Empresa en Func ionamiento

Enfoques o Columnas

En resumen, cada perspectiva le da enfoque a una pregunta fundamental donde éstas se resuelven desde ese punto, creando diferentes representaciones (modelos), lo cual se interpreta desde perspectivas de alto a bajo nivel.

Modelos o Celdas

Los modelos se hacen explícitos en las intersecciones entre filas y columnas, a estas se les conoce como celdas, las cuales son únicas, su contenido es normalizado según el enfoque de la perspectiva.

CONCLUSIONES Y OBSERVACIONES.

Cada framework es un universo a parte el cual fue creado para satisfacer una necesidad de una industria especifica, por ello se deben analizar detenidamente antes de tomar una decisión sobre su uso.

Zachman, es más una manera de organizar una empresa y de delegar responsabilidades y demás. TOGAF es mas practico desde mi punto de vista en los aspectos de creación de una arquitectura solida.

Implementar sabiamente un framework es una decisión crítica, tanto de negocios como de estrategia. Con esta nos aseguraremos de no ignorar ningún aspecto de la organización.

Al elegir un framework se debe analizar la estructura de la empresa al igual que sus procesos, ya que cada framework por su origen no es una plantilla necesariamente genérica.

Ejecutar los pasos y generar la documentación necesaria al implementar un framework es una tarea sumamente importante, por esto, es recomendable tener los servicios de un consultor especializado en el framework para así no caer en errores de principiante que pueden ser letales para nuestra organización.

Existen múltiples alternativas para implementar un framework, por esto, es bueno compararlas y elegir una con base a otras empresas que funcionen de manera similar a la nuestra.

BIBLIOGRAFÍA

BRANCHEAU, J. C., & WETHERBE, J. C. (1996). Information architectures: methods and practice.

Information Processing & Management .

BRANCHEAU, J. C., SCHUTER, L., & MARCH, S. (1996). Buinding and implementing an information

architecture . Summer.

Diccionario de Filosofía. (1984). Rusia: Editorial Progreso.

Group, T. O. (s.f.). TOGAF 9 Manual. Recuperado el 29 de Septiembre de 2010, de

http://www.opengroup.org/architecture/togaf9Adoc/arch/index.html

International, Z. (s.f.). The Zachaman Framework Evolution. Recuperado el 19 de Marzo de 2010,

de

http://www.zachmaninternational.com/index.php/eaAarticles/100AtheAzachmanAframeworkAev

olution

ISACA. (s.f.). COBIT Overview. Recuperado el 19 de Marzo de 2010, de

http://www.isaca.org/AMTemplate.cfm?Section=Downloads&Template=/ContentManagement/C

ontentDisplay.cfm&ContentID=54922

Senn, J. (1997). Análisis y diseño de sistemas de información.

TOGAF or not TOGAF: Extending Enterprise Architecture beyond RUP. Recuperado el 29 de

Septiembre de 2010, de

http://www.ibm.com/developerworks/rational/library/jan07/temnenco/index.