martinsalini

En este Informe y se van a resaltar los aspectos más importantes del Texto “Comparison Of The Top Four Enterprise Architecture Methodologies”. Para lo cual se va a hacer un pequeño resumen del campo de la informática que por más de veinte años ha contribuido al mejoramiento y optimización de los procesos dentro de las organizaciones; estamos hablando de la Arquitectura Empresarial. Conforme a lo anterior, es importante aclarar que este campo principalmente comenzó por abordar dos problemas: • La complejidad del sistema: Ya que, por lo general, las organizaciones estaban gastando dinero innecesariamente en recursos que no contribuían al mejoramiento de la organización respectiva. Para lo cual se propuso la construcción de Sistemas Informáticos con el objetivo de mitigar dichos problemas. • Mala alineación del negocio: Las organizaciones, cada vez, se encontraban con mayor dificultad para mantener alineados a las necesidades de negocio los sistemas informáticos que se planteaban (Sistemas cuya implementación y puesta en marcha era muy costoso). De esta manera, lo que se obtenía con la puesta en marcha de dichos Sistemas Informáticos eran una costosa implementación, la cual no reflejaba los resultados esperados (más costos, menos valor). Estos problemas, por primera vez reconocidos durante hace veinte años, hoy en día han alcanzado su punto crítico. El costo y la complejidad manejada para dichos sistemas informáticos vienen incrementándose drásticamente mientras que las posibilidades de obtener un valor real a partir de estos sistemas han decrecido de una manera poco conveniente. El resultado final de hoy en día: aún más costos por mucho menos valor. Las grandes organizaciones ya no pueden permitirse el lujo de ignorar estos problemas, ya que de ser ignorados pueden sufrir las consecuencias de perder su competitividad en el mercado. Y es allí en donde la Arquitectura Empresarial empieza a jugar un papel muy prometedor. Muchas metodologías de Arquitectura Empresarial han ido y venido en los últimos veinte años. Para lo cual la mayoría de organizaciones utilizan alguna de estas cuatro metodologías: • El Zachman Framework para la Arquitectura Empresarial, el cual se describe como una encasillamiento de la Arquitectura Empresarial. • El Grupo Abierto de Arquitectura Empresarial (TOGAF), el cual se define como un proceso. • La Arquitectura Empresarial Federal, que se puede ver como una implementación de la Arquitectura Empresarial o como una metodología prescriptiva para la creación de una arquitectura empresarial. • La Metodología de Gartner, la cual puede ser descrita como una práctica de la arquitectura empresarial. En este informe se van a analizar estos cuatro enfoques de la Arquitectura Empresarial. Para este caso lo hacemos bajo el contexto de una empresa ficticia que se enfrenta a algunos problemas operacionales. Algunos de estos problemas operacionales son la poca usabilidad de sistemas informáticos (costosos de mantener), sistemas informáticos que por lo general no responden a las condiciones actuales y futuras del mercado, mal manejo y poca veracidad de la información. Al examinar cada una de estas metodologías en profundidad, llama la atención el hecho de que cada una de las metodologías mencionadas tiene sus puntos fuertes en algunas áreas y debilidades en otras. No obstante hay organizaciones, las cuales consideran que la implementación de una de estas cuatro metodologías resulte eficiente. Para estas organizaciones, se propone otro enfoque: Metodología Mezclada. La Metodología Mezclada propone elegir fragmentos de cada una de las cuatro metodologías y modificar y combinar de acuerdo a las necesidades específicas de su organización. Vale la pena aclarar que una metodología mezclada solo será buena en la medida que la organización esté dispuesta a realizar los cambios. Este compromiso debe ser impulsado hasta el nivel más alto de la organización. La promesa de reducir los costos y la complejidad del sistema mientras incrementa el valor de los negocios y su eficacia no ha cambiado… mejorar la competitividad de las empresas en un mundo cada vez más competitivo. Introducción Hasta el momento han existido infinidad de metodologías de la arquitectura empresarial. Pero son cuatro las que se han consolidado como las más importantes: El Zachman Framework para Arquitectura Empresarial, El Grupo Abierto para el Framework de la Arquitectura Empresarial (TOGAF), La Arquitectura Empresarial Federal (FEA) y el método de Gartner. El impacto de la Arquitectura Empresarial que se ve reflejado en las organizaciones es proporcional a la motivación con que deseen implementar en la organización un Marco de Arquitectura Empresarial. Si el manejo de la complejidad del sistema y la entrega del valor del negocio son claves importantes para usted, entonces a usted debería importarle todo lo relacionado acerca de las metodologías de la Arquitectura Empresarial. Si usted se centra en el mantenimiento o la reconstrucción, es la credibilidad de su organización, o si usted se esfuerza por promover el uso de las Tecnologías de la Información para mantener la posición competitiva en su industria, entonces debes de seguir leyendo este documento. Si estas cuestiones no responden a sus inquietudes, entonces estas metodologías le pueden ofrecer poco. Como los sistemas se vuelven más complejos, entonces estos requieren de una mayor planificación estratégica. Un ejemplo de lo anterior, lo podemos ver reflejado en los edificios: no es lo mismo crear una cabaña que crear un edificio. La relación entre complejidad y planeación de edificios y ciudades es similar para los sistemas de información. Si usted construye un sistema simple, es posible que no sean necesarios arquitectos. En cambio si usted está encargado, por ejemplo, del sistema de información de una multinacional, es posible que necesite un arquitecto de Bases de Datos, un arquitecto de soluciones, un arquitecto de infraestructura, un arquitecto de negocios y un arquitecto empresarial. En este informe se van a exponer las metodologías necesarias para desarrollar la visión arquitectónica global de una organización. Esta es la responsabilidad del Arquitecto Empresarial, el cual se especializa en la visión más amplia de la arquitectura dentro de la empresa. Este es el arquitecto del arquitecto, el arquitecto que se encarga de coordinar el trabajo de todos los otros arquitectos. No obstante, la contratación de un arquitecto empresarial no garantiza unos resultados exitosos. Hay muchos ejemplos de arquitecturas empresariales que resultaron un desastre total. Las metodologías de la Arquitectura empresarial pueden ayudar, pero solo hasta cierto punto. Historia de La Arquitectura Empresarial El campo de la Arquitectura Empresarial empezó en 1987 con la publicación del artículo de IBM titulado “Un Marco para la Arquitectura de Sistemas de Información”, de JA Zachman. En este artículo Zachman expuso el reto y la visión de arquitecturas empresariales que guiarían el campo durante los próximos 20 años. El reto consistía en gestionar la complejidad de los sistemas cada vez más distribuidos. Como Zachman dijo: “El costo y el éxito del negocio depende cada vez más de sus sistemas de información requieren un enfoque disciplinado para la gestión de estos sistemas.” La visión de Zachman es que el valor del negocio y la agilidad mejor podrían ser realizados por un enfoque integral de la arquitectura de sistemas que explícitamente se veía en cada tema importante desde cualquier perspectiva importante. Su enfoque multi-perspectiva de sistemas arquitectónicos son descritos (originalmente por Zachman) como un marco de arquitectura de sistemas de información y luego renombrado como “marco de arquitectura empresarial”. Zachman fue una influencia importante en uno de los primeros gobiernos de EE.UU., (el Departamento de Defensa) para crear una arquitectura empresarial. Este intento fue conocido como Marco de Arquitectura Técnica para la Gestión de la Información (TAFIM) [03]. TAFIM se introdujo en 1994. La promesa de las arquitecturas empresariales, como TAFIM, para alinear mejor los proyectos tecnicos con necesidad de negocio fue observado por no menos de un cuerpo que el Congreso de EE.UU; esto trajo como consecuencia el futuro prometedor con el que TAFIM se empezó a consolidar, el Congreso en 1996 aprobó una ley conocida como Ley Clinger-Cohen, también conocida como la Ley de Reforma para la Gestión de la Tecnología de la Información, la cual ordenó que todas las agencias federales tomen medidas para mejorar la eficacia de sus inversiones respecto a los sistemas de información. Para tal caso se fundó el Consejo de CIO, conformado por los CIOs de las principales entidades gubernamentales, son el fin de supervisar este esfuerzo. En abril de 1998, el Consejo “CIO” comenzó a trabajar en su primer proyecto de gran envergadura, la Federal Enterprise ArchitectureFramewrok (FEAF). La versión 1.1 de este marco fue lanzado en septiembre de 1999. Este documento contenía algunas ideas innovadoras, como por ejemplo "arquitecturas segmentadas", es decir, de enfoque arquitectónico sobre subconjuntos segmentados de la empresa más grande. Con el tiempo, la responsabilidad de la arquitectura empresarial federal se trasladó desde el Consejo de CIO a la Oficina de Administración y Presupuesto (OMB). En 2002, la OMB evolucionó y cambió el nombre del método FEAF como la Arquitectura Empresarial Federal (FEA). La Federal Enterprise ArchitectureFramewrok (FEAF) se cambió el nombre a Arquitectura Empresarial Federal (FEA). A pesar de la significativa participación de arquitectónica empresarial en el Gobierno Federal (se podría argumentar que ninguna organización ha gastado más dinero para desarrollar una arquitectura empresarial que el Gobierno de los EE.UU.), el progreso ha sido lento e historias de éxito son eclipsados por una cantidad de fracasos. En 2004, ocho años después de que la Ley Clinger-Cohen requiriera la utilización de sistemas informáticos para los procesos de planificación, la Oficina de Contabilidad General (GAO) reportó lo siguiente: “Sólo 20 de las 96 entidades analizadas han establecido por lo menos las bases para la gestión eficaz de la arquitectura. Además, mientras que 22 agencias aumentaron en la madurez desde el año 2001, 24 agencias disminuyeron en madurez y 47 agencias sigue siendo el mismo.” Desde enero de 2005, la Oficina de Contabilidad General ha castigado severamente a un número de agencias de Estados Unidos por fallas en su adopción o el uso de la arquitectura empresarial. En 1998 TAFIM fue entregado a The Open Group. Ellos se transformaron en un nuevo estándar que se conoce hoy como el marco arquitectónico Open Group, más conocido por sus siglas, TOGAF. En 2005, otra organización estaba adoptando medidas para convertirse en una fuerza dominante en el sector privado. Este grupo fue Gartner. Gartner se consolidó rápidamente como una de las organizaciones más influyentes especialistas en consultoría nivel CIO. Sin embargo, en el ámbito específico de la arquitectura empresarial, el grupo de investigación y de asesoramiento más conocido de los sistemas de información no era Gartner, era Meta Group. Gartner había luchado para construir una práctica de arquitectura empresarial, pero nunca alcanzó el estado de Meta Group. Por tal motivo, en 2005, Gartner decidió comprar MetaGroup. Tras la compra de Meta Group, Gartner / Meta pasó un año viendo lo que cada empresa contribuyó a la experiencia de la arquitectura empresarial y sus respectivas metodologías. Las dos compañías discutieron, a menudo, la manera de conciliar sus, muy diferentes, enfoques. Estudio de Caso Para que podamos comparar y contrastar los cuatro enfoques principales para las arquitecturas empresariales, se ilustrará cómo cada uno se acercaría a un escenario similar. Este escenario ficticio es una composición de varias empresas con las que se varias personas experimentadas en el campo han trabajado en los últimos años. Así, mientras que es ficticia, que es muy realista. Para comenzar MedAMmore es una cadena de farmacias. Comenzó como una cadena regional en 1960. En 1995, se desarrolló un sistema de software innovador que le permitió ejecutar las farmacias de manera muy eficiente. Se llamó a este sistema MedAManage o MAM. MAM incorpora algunas ideas a innovar como la gestión de la relación paciente, gestión de inventario, la facturación del seguro automático, e incluso la optimización de la utilidad. MAM consistía en tres programas: MAM / tienda, funciona en un pequeño ordenador en una farmacia, MAM / almacén, que se desarrolló en el servidor en un almacén regional, y MAM / Home, que se desarrolló en un gran servidor. Estos tres programas se comunican a través de líneas de comunicaciones fiables, transferencias de archivos podrían ocurrir a través de FTP. El sistema también es lo suficientemente flexible como para dar cabida a las transferencias a través de mensajería, en caso necesario. Para el año 2000, MedAMore estaba logrando lo que se proponía, en parte debido a los movimientos de reducción de costes activados por el sistema MAM. MedAMore decidió iniciar la expansión. Para ello, compró tres cadenas regionales. Con estas compras, MedAMore extendió su alcance a través del cuadrante sureste de los EE.UU. Sin embargo MedAMore estaba presentando algunos problemas, como fueron los siguientes: • MAM / tienda requiere especializaciones regionales. Por ejemplo, los planes de seguros necesitan ser apoyados en las distintas regiones, y estos todos los cambios necesarios en el módulo MAM / tienda. • Los almacenes regionales habían sido adquiridos por diferentes sistemas por lo que cada uno tenía diferentes maneras de recibir órdenes de las tiendas al por menor y los diferentes procedimientos de pedidos de suministros a los mayoristas. • El método de transferencia de archivos de intercambio de información que había funcionado tan bien cuando MedAMore consistia en 30 farmacias, un almacén regional y una pequeña oficina, empezó a decaer desde que empezó a crecer el “negocio”, el cual constaba de 200 farmacias, cuatro almacenes regionales, dos oficinas geográficas y una oficina en casa. Estaba claro para MedAMoreque que el sistema MAM necesita muchas mejoras. Sin embargo actualizar este sistema era difícil. Cada uno de los tres módulos (tienda, almacén y oficina en casa) era enorme, ineficiente y engorroso, ya que incluyen la funcionalidad de todo lo que puede necesitar cada entidad. Los módulos han crecido a más de un millón de líneas de código cada uno. Era difícil cambiar una función sin impactar otros. Todas las funciones de acceder a una base de datos única y los cambios en una definición de registro podría ondulación a través del sistema de una manera impredecible. Cambio de incluso una sola línea de código requiere una reconstrucción del módulo completo de varios millones de líneas. Para lo cual MedAManage se había convertido en MedANightmare: un sistema más fácil de depurar, usable y un sin número de ventajas. Sin embargo, en la medida que crecía la empresa empezaron a incrementar los problemas técnicos hasta el punto de que se empezaron a generar conflictos internos dentro de la oficina central de MedAMore… a lo que se sumaba que la parte comercial de MedAMore quería adquirir dos cadenas regionales más. Esto dio lugar a una brecha creciente entre la empresa y los aspectos técnicos de MedAMore: El lado del negocio vio la reducción de la agilidad del negocio, mientras que el aspecto técnico vio el lado empresarial como un medio que solo imponía demandas imposibles. La desconfianza se había llegado a un punto tal que para el año 2005, el CIO ya no se considera parte del equipo ejecutivo de MedAMore. Para el año 2006, MedAMore estaba en crisis. Se necesita claridad para modernizar sus sistemas técnicos para facilitar la especialización de las necesidades regionales. Esta iba a ser una propuesta costosa y MedAMore no podía permitirse el esfuerzo al fracaso. Igual de importante, MedAMore también tuvo que reconstruir sus relaciones internas. Las constantes peleas y la desconfianza entre las empresas impactaron negativamente en la moral, la eficiencia y la rentabilidad de dicha empresa. Una empresa que hace cinco años era un ente líder de la industria de la rentabilidad, en gran parte debido a su uso innovador en los sistemas de información. Cath, el director general de MedAMore, necesitaba desesperadamente una solución. En una conferencia de CEO oyó cómo muchos de sus compañeros estaban usando arquitecturas empresariales para construir alianzas más fuertes entre los grupos técnicos y de negocio y obtener sistemas de información más eficientes. Cath decidió que este enfoque merecía una mayor investigación. Para lo cual Irma propuso una recomendación sobre el uso de una arquitectura empresarial dentro MedAMore. Por recomendación de Irma, Cath convocó a una reunión con Bret, Vicepresidente de Negocios. Cath anunció que había decidido crear una arquitectura empresarial común para MedAMore en la cual uniría la parte técnica con la comercial. Esta arquitectura empresarial común se llamaría MedAMore-Enterprise Architecture, o MAM-EA. Una vez completado. MAM-EA podría gestionar y garantizar una nueva inversión en sistemas de información garantizando que cada dólar invertido tendría una gran utilidad en el negocio. Cath sabía que MAM-EA era una apuesta empresarial de MedAMore y tenía claro que para sacar este proyecto adelante dependía de Bret (en lo que respecta al negocio) e Irma (respecto a los sistemas de información) para hacer que funcione. Así que es el problema. Ahora vamos a ver cómo cada uno de los enfoques de EA puede El Marco Zachman para Arquitecturas Empresariales Lo primero que tenemos que entender sobre el Marco Zachman es que El Zachman "Framewrok" es en realidad una taxonomía para organizar los artefactos arquitectónicos (por ejemplo, documentos de diseño, especificaciones, modelos) que tenga en cuenta tanto los objetivos que los artefactos (por ejemplo, empresario, constructor) y qué tema en particular (por ejemplo, los datos, la funcionalidad ) se está abordando. Como John Zachman describe retrospectivamente su obra: El Framewrok que se aplica a las empresas no es más que una estructura lógica para clasificar y organizar las representaciones descriptivas de una empresa que son importantes para la gestión de la empresa, así como para el desarrollo de los sistemas de la empresa. Zachman originalmente explicó su taxonomía tomando como referencia el sector de la construcción. Como mencioné anteriormente, el Marco Zachman se compone de seis focos funcionales, cada uno considerado desde el punto de vista de un jugador importante. La primera sugerencia de la taxonomía Zachman es que cada artefacto arquitectónico debe vivir en una y sólo una célula. No debe haber ninguna ambigüedad acerca de donde vive un determinado artefacto. Como MedAMore comienza a acumular artefactos en el desarrollo de MAM-EA, se puede utilizar la cuadrícula Zachman para aclarar el foco de cada uno de estos artefactos. Por ejemplo, los artefactos relacionados con una arquitectura orientada a servicios en su mayoría viven en la tercera fila (la perspectiva del diseñador). Por lo general, no serán de interés para el dueño del negocio. En la segunda sugerencia de la taxonomía Zachman, una arquitectura es definida como una arquitectura completa solamente cuando todas las células de la arquitectura estén completas. Una célula es completa cuando contiene artefactos suficientes para definir completamente el sistema. La sugerencia de pájaro de la red Zachman es que las células en columnas shouls estar relacionados entre sí. Considere, por ejemplo, la columna de datos (la primera columna) de la rejilla Zachman. Desde la perspectiva del dueño del negocio (Bret), la información es la información sobre el negocio. Desde la perspectiva del administrador de base de datos, los datos son las filas y columnas de la base de datos. Tomando como ejemplo el caso de MedAMore, para definir la red Zachman, alguien debe ser capaz de seguir los requerimientos del negocio de Bret y demostrar que el diseño de bases de datos está impulsado por los requisitos. Si Bret tiene necesidades que no son rastreables hasta el diseño de base de datos, entonces debemos preguntarnos si las necesidades de la empresa se encontrarán con esta arquitectura. Por otro lado, hay elementos de diseño de bases de datos que no se remontan a los requerimientos del negocio, entonces podríamos preguntarnos si hemos incluido el diseño innecesaria a nivel de base de datos. Vale la pena aclarar que Zachman por sí solo no es una solución completa para MedAMore. Hay demasiadas cuestiones que serán fundamentales para el éxito MAM-EA 's que Zachman no aborda. Zachman no nos da un proceso paso a paso para la creación de una nueva arquitectura. Zachman ni siquiera nos dan mucha ayuda para decidir si el diseño del futuro que estamos creando es la mejor arquitectura posible. Por lo demás, Zachman ni siquiera nos dan una opción para mostrar la necesidad de una futura arquitectura. Por estas y otras cuestiones, vamos a tener que buscar otras metodologías. The Open Group Architecture Framework (FOGAT) – (Traducción) The Open GroupArchitectureFramewrok es mejor conocido por sus siglas, FOGAF. TOGAF es propiedad de The Open Group. Vista de TOGAF de una arquitectura de la empresa se muestra en la Figura TOGAF divide una arquitectura empresarial en cuatro categorías, de la siguiente manera: • Arquitectura de Negocios - Describir los procesos de la empresa utiliza para cumplir con sus objetivos. • Arquitectura de aplicaciones - Describe cómo las aplicaciones específicas están diseñados y cómo interactúan entre sí. • Arquitectura de datos - Describe cómo se organizan y se accede a los almacenes de datos empresariales. • Arquitectura Técnica - Describe la infraestructura de hardware y software que las solicitudes de apoyo y sus interacciones. TOGAF se describe a sí mismo como un Método de Desarrollo de Arquitectura, mejor conocido como ADM. ADM es una receta para la creación de la arquitectura. Una receta puede ser categorizado como un proceso. Visto como un proceso arquitectónico, TOGAF complementa Zachman, que, recuerdo, me clasifica como una taxonomía arquitectónico. Zachman te dice cómo categorizar sus artefactos. TOGAF le da un proceso para crearlos. TOGAF ve el mundo de la arquitectura de la empresa como un continuo de arquitecturas, que van desde muy genérico a altamente específica. Se llama a este continuum del Continuum Enterprise. Se considera que el proceso de creación de una arquitectura empresarial específica, como MAM-EA, como pasar de lo genérico a lo específico. ADM de TOGAF proporciona un procedimiento para la conducción de este movimiento de la genérico a lo específico. ADM de TOGAF proporciona un procedimiento para la conducción de este movimiento de la genérico a lo específico. TOGAF llama arquitecturas más genéricas Arquitecturas Fundación. Estos son los principios arquitectónicos que pueden, theretically, ser utilizado por cualquier organización de TI en el universo. TOGAF llama al siguiente nivel de especificidad arquitecturas del sistema común. Estos son los principios que uno esperaría ver en muchos - pero quizás no todos - los tipos de empresas. TOGAF llama al siguiente nivel de especificidad Arquitecturas Industria. Estos son los principios que son específicos a través de muchas empresas que forman parte del mismo dominio - tales como, en nuestro caso de estudio MedAMore, todas las empresas farmacéuticas. TOGAF llama al nivel más específico las arquitecturas organizacionales. Estas son las arquitecturas que son específicos de una determinada empresa, tales como MedAMore. La figura 6 muestra la relación entre la empresa y el Continuum de la Metodología de Desarrollo Arquitectónico (ADM). TOGAF define las distintas bases de conocimiento que viven en la ArchitectureFoundation. Dos que usted podría encontrarse son el modelo de referencia técnica (TRM) y las normas básicas de la Información (SIB). La TRM es una descripción sugerida de una arquitectura IT genérico. El SIB es un conjunto de normas y pseudo-normas que The Open Group recomienda que se tiene en cuenta en la construcción de una arquitectura de TI. TOGAF presenta tanto la TRM y el SIB como sugerencias, ni tampoco es necesario. En mi punto de vista, tanto la TRM y la SIB son deficientes por la misma razón: están sesgados hacia la portabilidad de aplicaciones a expensas de la interoperabilidad de las aplicaciones y la autonomía de la aplicación. Considero que esto es una concepción anticuada de arquitecturas técnicas. Por un organizaciones como MedAMore, TOGAF en gran medida se reduce a la arquitectura Método Deveploment (ADM). Los individuos dentro de MedAMore estarán expuestos al Continuum Empresa, la SIB y la TRM (así como algunas otras características TOGAF) por lo que yo les hablé. Pero la experiencia día a día de la creación de una arquitectura de la empresa será impulsado por el ADM, una vista de alto nivel de la cual se muestra en la Figura 7. Como se muestra en la Figura 7, el TOGAF ADM consta de ocho fases que son un ciclo a través después de una "cebado de la bomba" inicial. Yo te llevaré a través de estas fases, ya que se pueden aplicar al caso de estudio MedAMore. Pero, antes de MedAMore puede iniciar la ADM, tiene que ganar un poco de experiencia con TOGAF. MedAMore tendrá dos opciones sobre cómo puede obtener esta experiencia. En primer lugar, MedAMore puede entrenarse en TOGAF. MedAMore puede descargar la documentación TOGAF que describe todos TOGAF incluyendo la ADM con bastante detalle. Se puede comprar libros en TOGAF. Probablemente hay información disponible más libre y barato sobre TOGAF que todos los otros métodos arquitectónicos combinados. En segundo lugar, puede comprar MedaMore experiencia en TOGAF. Hay consultores que se especializan en TOGAF y que han obtenido la certificación Open Group. Desde MedAmore quiere minimizar las posibilidades de fracaso, se ha optado por llamar a un consultor TOGAF. MedAMore ha traído Teri, un Grupo abierto de certificación TOGAF arquitecto. Recuerde que los otros jugadores en MedAMore son Cath, el director general de MedAMore, Bret, VP de negocios, e Irma, el CIO. En la Etapa Preliminar, Teri se reúne con los principales actores en MedAMore introducir el proceso TOGAF. Allí goles en la fase preliminar son los siguientes: 1. Asegúrese de que todo el mundo se siente cómodo con el proceso. 2. Modificar el proceso TOGAF si es necesario para adaptarse a la cultura MedAMore y 3. Establecer el sistema de gobierno que se encargará de supervisar el trabajo futuro de arquitectura en MedAmore. Teri trabajará en estrecha colaboración con Brett entender la filosofía de negocio, modelos de negocio y estratégica conductores de MedAMore. Ella trabajará en estrecha colaboración con Irma para definir los prinpiples arquitectónicos que impulsan arquitecturas tecnológicas en MedAMore y documentar esos principios con el formato TOGAF recomendado. En algunas organizaciones, el logro de buy-in en la necesidad de una arquitectura empresarial puede ser muy difícil. Esto es especialmente cierto cuando el esfuerzo es impulsado desde la organización de TI, y más aún cuando hay una historia de la discordia entre la empresa y los aspectos técnicos de la organización. MedAMore tiene esta historia de animosidad. Sin embargo, hay otro dato a su favor si de la que Teri debe tener corazón: el esfuerzo no es impulsado por TI, pero se debe a Cath, el director general. Esto le da el alto visivility proyecto y crea un incentivo positivo para la cooperación de todos los lados. Tan pronto como Teri y MedAMore han completado la Fase Preliminar, que están listos para iniciar la fase A. La fase A begind, al menos en teoría, con una Petición de Arquitectura de Trabajo de alguna organización dentro MedAMore. Este documento incluye las razones de negocio para la solicitud, el presupuesto y la información personal y las restricciones que deben tenerse en cuenta. Debido MedAMore nunca ha hecho una solicitud de Arquitectura Trabajo, Teri tendrá probabilidad de trabajar con la organización patrocinadora en la creación de dicha solicitud. Tan pronto como la solicitud de Arquitectura Trabajo (o algún equivalente) se ha recibido, Teri (el consultor TOGAF) comienza MedAMore la Fase A. En la fase a, Teri se asegurará de que el proyecto cuenta con el apoyo necesario dentro MedAMore, definir el alcance de el proyecto, identificar las limitaciones, documentar los requerimientos del negocio, y establecer las definiciones de alto nivel para el stand de la arquitectura (partida) de la arquitectura y de destino (deseada) de referencia. Estas definiciones de base y objetivo se incluyen las definiciones de alto nivel sobre las cuatro EA sub-arquitecturas se muestra de nuevo en la figura 5 - a saber, negocios, tecnología, datos y arquitecturas de aplicaciones. La culminación de la fase A será una declaración de Arquitectura de Trabajo que deberá ser aprobada por las distintas partes interesadas antes de la siguiente fase de la ADM comienza. El resultado de esta fase es crear una visión arquitectónica para la primera pasada a través de la ADM comienza. El resultado de esta fase es crear una visión arquitectónica para la primera pasada a través del ciclo de ADM. TeriMedAMore guiará en la elección del proyecto, la validación del proyecto en relación con los principios arquitectónicos establecidos en la fase preliminar, y asegurarse de que las partes interesadas pertinentes han sido identificados y se han abordado sus problemas. La visión arquitectónica creada en la fase A será el objetivo principal de la fase de entrada B. de Teri en la Fase B es la creación de una línea de base detallada y arquitectura de negocios de destino y realizar un análisis completo de las diferencias entre ellos. Ella va a trabajar principalmente con Bret (o equipo de Bret) para lograrlo. Fase B es un poco complicado - La participación de modelado de negocio, análisis de negocios muy detallado y documentación de los requisitos técnicos. El éxito de la Fase B requiere la colaboración de muchos interesados. Los principales resultados serán una descripción detallada de la línea de base y los objetivos de negocio de destino, y las descripciones de la brecha de la arquitectura de negocios. Phace C hace de la arquitectura de sistemas de información lo que hace la Fase B de la arquitectura empresarial. En esta fase, Teri trabaja principalmente con Irma (o su equipo). TOGAF define nueve pasos específicos, cada uno con sub-etapas múltiples: Glosario Arquitecto: Persona responsable del diseño de una arquitectura y la creación de descripción arquitectónica. Artefacto Arquitectónico: Un documento especifico el informe, el análisis, el modelo, o de otro tipo tangible que contribuya a una descripción arquitectónica. Descripción Arquitectónica*: Una colección de productos (artefactos), para documentar la arquitectura. Marco Arquitectónico: Es una estructura esquelética que define los artefactos arquitectónicos sugeridos, describe como los objetos están relacionados unos con otros, y proporciona definiciones genéricas de lo que esos artefactos pueden parecer. Metodología Arquitectónica: Un término genérico que puede describir cualquier enfoque estructurado para la solución de algunos o todos los problemas relacionados con la arquitectura. Proceso Arquitectónico: Es serie definida de acciones dirigidas a la meta de producir ya sea una arquitectura o una descripción arquitectónica. Taxonomía Arquitectónica: una metodología de organización y categorización de los artefactos arquitectónicos. Arquitectura*:La organización fundamental de un sistema incorporado en sus componentes, sus relaciones entre sí y con el medio ambiente y los principios que guían su diseño e evolución. Arquitectura Empresarial: una arquitectura en la que el sistema en cuestión es toda la empresa, sobre todo el negocio, las tecnologías y sistemas de información de la empresa.