Introduccin a la ADM

ADM Resumen | El ciclo de desarrollo de la Arquitectura | Adaptacin de la ADM | Arquitectura Gobierno | Gestin de Procesos | Alcance de la arquitectura | Arquitectura de Integracin | Resumen En este captulo se describe el ciclo de desarrollo de mtodos Arquitectura ( ADM ) , la adaptacin de la ADM , alcance la arquitectura, y la integracin de la arquitectura.

ADM general

El TOGAF ADM es el resultado de continuos aportes de un gran nmero de practicantes de la arquitectura. Se describe un mtodo para el desarrollo de una arquitectura de la empresa , y forma el ncleo de TOGAF . Integra elementos de TOGAF descritos en este documento, as como otros activos arquitectnicos disponibles , para cumplir con el negocio y las necesidades de TI de una organizacin.

Relacin con otras partes de TOGAF

Hay otras dos partes principales a TOGAF , adems de la ADM :

El Continuum Empresa, se describe en detalle en la Parte III : Empresa Continuum . Se trata de un "marco - dentro-uno- marco " que proporciona el contexto para la movilizacin de activos arquitectura pertinentes y proporciona ayuda de navegacin cuando las discusiones se mueven entre diferentes niveles de abstraccin. La Base TOGAF recursos , que se describe en la Parte IV: Base de recursos. Se trata de un conjunto de recursos - directrices , plantillas, listas de comprobacin, y otros materiales detallados - que apoyan el TOGAF ADM . El ADM y el Continuum Empresarial

Como se mencion anteriormente, el Continuum Enterprise proporciona un marco y un contexto para el aprovechamiento de los activos arquitectura pertinentes en la ejecucin de la ADM . Estos activos pueden incluir descripciones de arquitectura , modelos y patrones tomados de una variedad de fuentes , como se explica en la Parte III : Empresa Continuum . En los lugares pertinentes de toda la ADM , hay recordatorios a tener en cuenta que los activos de arquitectura

de la empresa Continuum debe utilizar el arquitecto , en su caso . En algunos casos - por ejemplo, en el desarrollo de una arquitectura de tecnologa - esto puede ser la Fundacin Arquitectura TOGAF ( vase la Parte III : Empresa Continuum ) . En otros casos - por ejemplo , en el desarrollo de una arquitectura de negocios - que puede ser un modelo de referencia para el comercio electrnico tomada de la industria en general .

La aplicacin prctica del Continuum Empresarial a menudo toma la forma de un repositorio que incluye arquitecturas de referencia , modelos y patrones que han sido aceptados para su uso dentro de la empresa , y el trabajo arquitectnico real hecho con anterioridad en la empresa. El arquitecto tratar de volver a utilizar la mayor cantidad posible de la Continuidad Empresarial que era relevante para el proyecto en cuestin . ( En adicin a la coleccin de material de origen arquitectura , el repositorio tambin contendra desarrollo de la arquitectura de trabajo en curso . )

Los criterios para la inclusin de los materiales de base en Continuum empresarial de una organizacin se suelen formar parte del proceso de gobernanza de TI de la organizacin.

El Continuum Empresarial es, pues, un marco ( un "marco - dentro-uno- marco ") para clasificar material original arquitectura - tanto en el contenido del repositorio de trabajo , la arquitectura y el conjunto de modelos de referencia correspondientes , disponibles en la industria.

En la ejecucin de la ADM , el arquitecto no es slo desarrollar el resultado final de una arquitectura especfica de la organizacin , sino que tambin est poblando propio Continuum Empresarial de la organizacin, con todos los bienes arquitectnicos identificado y aprovechado a lo largo del camino, incluyendo , pero no limitado a , la arquitectura especfica de la empresa resultante.

Arquitectura desarrollo es un proceso iterativo, en curso, y en la ejecucin de la ADM repetidamente en el tiempo , el arquitecto rellena gradualmente ms y ms de Continuum de Empresa de la organizacin. Aunque el objetivo principal de la ADM es en el desarrollo de la arquitectura especfica de la empresa , en este contexto ms amplio el ADM puede tambin ser visto como el proceso de poblar propia Continuum de empresa de la empresa con bloques de construccin reutilizables pertinentes .

De hecho, la primera ejecucin de la ADM a menudo ser la ms difcil , ya que los activos de arquitectura disponibles para su reutilizacin sern relativamente pocos. Incluso en esta etapa de desarrollo, sin embargo, habr capital arquitectura disponibles de fuentes externas, como TOGAF , as como la industria de TI en general , que podran ser aprovechados para apoyar el esfuerzo.

Ejecuciones posteriores sern ms fciles , ya que cada vez ms activos arquitectura se identifican , se utilizan para rellenar Continuum Empresarial de la organizacin, y por lo tanto disponible para la reutilizacin en el futuro .

La ADM tambin es til para rellenar la Arquitectura Fundacin de una empresa . Los requerimientos del negocio de una empresa pueden ser utilizados para identificar las definiciones y las selecciones necesarias en la Architecture Foundation . Esto podra ser un conjunto de modelos comunes reutilizables , la poltica y las definiciones de gobernabilidad , o incluso lo ms especfico anular selecciones tecnologa (por ejemplo , si el mandato de la ley) . Poblacin de la Arquitectura Fundacin sigue principios similares como para una arquitectura de la empresa , con la diferencia de que los requisitos para el conjunto de una empresa estn restringidos a las preocupaciones generales y por lo tanto menos completos que para una empresa especfica .

Es importante reconocer que los modelos existentes de estas diversas fuentes pueden no ser necesariamente integrable en una arquitectura de la empresa coherente . " Integrabilidad " de las descripciones de la arquitectura se considera en Integration Architecture .

El ADM y la base de recursos

La base de recursos TOGAF es un conjunto de recursos - directrices, plantillas, listas de comprobacin, y otros materiales detallados - que apoyar el TOGAF ADM .

Las secciones individuales de la base de recursos se describen por separado en la Parte IV: Base de recursos para que puedan hacer referencia a los puntos relevantes de la ADM , segn sea necesario , en lugar de tener el desorden texto detallado de la descripcin de la propia ADM .

El ciclo de desarrollo de la Arquitectura

Puntos clave

Los siguientes son los puntos clave de la ADM :

El ADM es iterativo , durante todo el proceso , entre las fases , y dentro de las fases . Para cada iteracin de la ADM, una nueva decisin debe tomarse en cuanto a : La amplitud de la cobertura de la empresa para definir El nivel de detalle que se define La extensin del horizonte temporal dirigido a , incluyendo el nmero y alcance de cualquier horizontes temporales intermedios El patrimonio arquitectnico se deje sentir en el Continuum de Empresa de la organizacin , entre ellos : Los activos creados en versiones anteriores del ciclo de ADM en la empresa Activos disponibles en la industria ( otros marcos , modelos de sistemas, modelos verticales de la industria , etc ) en otros lugares Estas decisiones deben hacerse sobre la base de una evaluacin prctica de los recursos y competencias de disponibilidad, y el valor que realmente puede esperar que obtuviera la empresa del mbito elegido de la obra de arquitectura . Como un mtodo genrico , el ADM est destinado a ser utilizado por empresas en una amplia variedad de diferentes geografas y aplicada en diferentes sectores verticales / tipos de industria . Como tal , puede ser , pero no necesariamente tiene que ser , adaptado a las necesidades especficas . Por ejemplo : Puede ser utilizado en conjuncin con el conjunto de entregables de otro marco , cuando stos han sido considerados para ser ms apropiado para una organizacin especfica . ( Por ejemplo , muchas agencias federales de Estados Unidos han desarrollado marcos individuales que definen los resultados especficos para sus necesidades del servicio en particular. ) Puede ser utilizado en conjuncin con el Marco Zachman bien conocido , que es un esquema de clasificacin excelente , pero carece de una metodologa disponible abiertamente , bien definido . Estas cuestiones se examinan en detalle en la adaptacin de la ADM .

Adems del mtodo en s est iterativo , tambin hay iteracin dentro del ciclo de ADM , tanto entre las fases individuales y entre los pasos dentro de cada fase .

Estructura bsica

La estructura bsica de la ADM se muestra en la Arquitectura ciclo de desarrollo.

A lo largo del ciclo de ADM , es necesario que haya validacin frecuente de resultados en contra de las expectativas iniciales , tanto los de todo el ciclo de ADM , y aquellos para la fase particular del proceso .

Figura: Arquitectura Ciclo de Desarrollo Las fases del ciclo de ADM se muestra en la Arquitectura Ciclo de desarrollo se dividen en etapas , como las descritas por la expansin de la fase de Arquitectura de Tecnologa en la Arquitectura Ciclo de Desarrollo - Expansin .

Figura: Arquitectura Ciclo de Desarrollo - Expansin Las fases del ciclo se describen en detalle en las siguientes subsecciones . Fase D , la creacin de una arquitectura de la tecnologa , se describe en mayor detalle en la Fase D : Arquitectura Tecnologa .

Tenga en cuenta que la salida se genera durante todo el proceso , y que la salida en una fase temprana puede ser modificado en una fase posterior . El control de versiones de salida se gestiona a travs de los nmeros de versin . En todos los casos , el esquema de numeracin ADM se proporciona como un ejemplo . Debe ser adaptado por el arquitecto para satisfacer las necesidades de la organizacin y trabajar con las herramientas de arquitectura y los registros de empleados por la organizacin .

Adaptacin de la ADM

El ADM es un mtodo genrico para el desarrollo de la arquitectura , que est diseado para hacer frente a la mayor parte del sistema y los requisitos de organizacin . Sin embargo , a menudo ser necesario modificar o ampliar el ADM , para adaptarse a necesidades especficas . Una de las tareas antes de aplicar la ADM es revisar sus componentes para su aplicabilidad , y luego adaptarlos segn corresponda a las circunstancias de la empresa individual. Esta actividad tambin se puede producir una " especfica de la empresa " ADM .

Una de las razones para que el deseo de adaptar la ADM , que es importante destacar, es que el orden de las fases de la ADM es hasta cierto punto depende de la madurez de la disciplina de la arquitectura dentro de la empresa de que se trate . Por ejemplo, si el modelo de negocio para hacer arquitectura en todo no est bien reconocido , a continuacin, crear una visin arquitectura es casi siempre esencial , y una arquitectura detallada de negocios a menudo tiene que venir a continuacin , con el fin de respaldar la Visin Arquitectura , detalle del caso de negocio para el trabajo de la arquitectura restante, y asegurar la participacin activa de los actores clave en ese trabajo. En otros casos un orden ligeramente diferente puede ser preferido , por ejemplo , un inventario detallado del entorno de lnea de base se puede hacer antes de emprender la Arquitectura de negocios .

El orden de las fases puede ser definido por los principios de negocio y la arquitectura de una empresa. Por ejemplo , los principios de negocios pueden determinar que la empresa estar preparado para ajustar sus procesos de negocio para satisfacer las necesidades de una solucin de envasado , de manera que se puede implementar rpidamente para permitir una respuesta rpida a los cambios del mercado . En tal caso , la Arquitectura de negocios ( o al menos de la finalizacin de la misma) puede as seguir la finalizacin de la Arquitectura de Sistemas de Informacin o la arquitectura de la tecnologa .

Otra de las razones para que el deseo de adaptar la ADM es TOGAF si se va a integrar con otro marco empresarial (como se explica en la Parte I: Introduccin, TOGAF como Architecture Framework Empresa) . Por ejemplo , una empresa puede querer usar TOGAF y su genrico ADM conjuntamente con el Marco Zachman conocido , u otro entorno de arquitectura empresarial que tiene un conjunto de productos especficos para un sector vertical, en particular definida : Gobierno , Defensa, e -Business , Telecomunicaciones, etc El ADM se ha diseado especficamente con este potencial de integracin en la mente.

Otras posibles razones para querer adaptar el ADM incluyen:

El ADM es uno de los muchos procesos empresariales que conforman el modelo de gobierno corporativo . Es complementario , y de apoyo a otros procesos de gestin de los programas estndar , como los de autorizacin , gestin de riesgos , planificacin y elaboracin de presupuestos, planificacin del desarrollo, desarrollo de sistemas, y las adquisiciones. El ADM es para ser utilizado como un mtodo para algo distinto de arquitectura de la empresa , por ejemplo , como un mtodo de gestin de programa general .

El ADM se encarg para su uso por un contratista principal o el plomo en una situacin de outsourcing, y debe adaptarse para alcanzar un compromiso adecuado entre las prcticas actuales de los contratistas y los requisitos de la empresa contratante. La empresa es una empresa de tamao pequeo a mediano y desea utilizar un mtodo "cut -down " ms en sintona con la reduccin del nivel de recursos y la complejidad del sistema tpico de dicho entorno. La empresa es muy grande y complejo , que comprende muchas "empresas" separados pero relacionados entre s dentro de un marco general de colaboracin de negocios , y el mtodo de la arquitectura debe adaptarse a reconocer esto. Diferentes enfoques para la planificacin y la integracin se pueden utilizar en tales casos , incluyendo las siguientes ( posiblemente en combinacin ) : Planificacin de arriba hacia abajo y el desarrollo - el diseo del conjunto de meta- empresarial interconectado como una sola entidad ( un ejercicio que normalmente se extiende a los lmites del sentido prctico) Desarrollo de un "genrico " o arquitectura " de referencia" , tpico de las empresas dentro de la organizacin , pero no representa a ninguna empresa especfica , la cual se espera que las empresas para adaptarse a fin de producir una arquitectura "instancia" se adapte a la empresa de que se trate . Replicacin - el desarrollo de una arquitectura especfica para una empresa, su aplicacin como una prueba de concepto , y luego tomar eso como una " arquitectura de referencia " que se clona en otras empresas. En un entorno de proveedor o de produccin , una arquitectura genrica para una familia de productos relacionados se refiere a menudo como un " Lnea de Arquitectura del producto " , y el proceso anlogo al descrito anteriormente se denomina " ( basado en Arquitectura ) Ingeniera Lnea de productos " . El ADM se dirige principalmente a arquitectos de TI de las empresas usuarias , sino una organizacin de proveedores cuyos productos estn basados en TI bien podra desear adaptarla como un mtodo genrico para un desarrollo de la arquitectura de lnea de productos. Arquitectura de Gobierno

El ADM , ya sea adaptada por la organizacin o se utiliza como documentado aqu , es un proceso clave para ser administrado en la misma forma que otros objetos de arquitectura en el continuo de la empresa . La Junta de Arquitectura debe estar convencido de que el mtodo se est aplicando correctamente en todas las fases de una iteracin desarrollo de la arquitectura . El cumplimiento de la ADM es fundamental para la gobernanza de la arquitectura , para asegurar que todas las consideraciones se hacen y se producen todos los entregables requeridos.

Gestin de Procesos

La gestin de todos los artefactos arquitectnicos , la gobernanza y los procesos relacionados debe apoyarse en un entorno administrado. Normalmente, esto se basa en uno o ms repositorios de apoyo objeto versionado y control de procesos y el estado .

Gestin de procesos de gobernanza incluye la gestin de repositorios, acceso , comunicacin, formacin y acreditacin . En esta seccin se incluye para identificar las principales reas de informacin que gestiona el repositorio de gobierno . El repositorio consiste inicialmente en una o ms instalaciones de almacenamiento de datos que van a contener los siguientes tipos de informacin :

Los datos de referencia ( garanta de los propios depsitos de la organizacin / empresa Continuum , incluidos los datos externos , por ejemplo , COBIT , ITIL ) Se utiliza para la orientacin e instruccin durante la ejecucin del proyecto. Esto incluye los detalles de la informacin descritos anteriormente . Los datos de referencia se incluye una descripcin de los propios procedimientos de gobierno .

estado del proceso Toda la informacin sobre el estado de los procesos de gobierno estar a cargo ; ejemplos de ello son las solicitudes pendientes de cumplimiento , solicitudes de dispensa y el cumplimiento de las evaluaciones de las investigaciones.

La informacin de auditora Esto grabar todas las acciones del proceso de gobierno realizadas y se utilizarn para apoyar :

Las decisiones clave y el personal responsable para cualquier proyecto de arquitectura que han sido sancionados por el proceso de gobernanza Una referencia para futuros desarrollos arquitectnicos y el apoyo del proceso , la orientacin y precedencia Los artefactos de gobierno y el proceso son a su vez parte de los contenidos del Continuum Enterprise.

Alcance de la Arquitectura

Hay muchas razones para querer limitar el alcance de la actividad de la arquitectura a realizar , la mayora de las cuales se reducen a la disponibilidad de las personas , las finanzas y otros recursos. El mbito de aplicacin elegido para la actividad arquitectura es normalmente dependiente directamente de los recursos disponibles , y en el anlisis final es por lo general una cuestin de la viabilidad .

Cualesquiera que sean las razones para querer o tener que limitar el alcance de la actividad de la arquitectura , hay cuatro dimensiones en las que el alcance puede ser definido y limitado :

mbito empresarial o enfoque : Cul es la magnitud de la empresa, y cunto de esa medida debe centrarse el esfuerzo de arquitectura de encendido? Muchas empresas son muy grandes, que comprende efectivamente una federacin de unidades organizativas que vlidamente se podran considerar las empresas en su propio derecho. La empresa moderna se extiende cada vez ms all de sus lmites tradicionales , para abrazar una combinacin confusa de la empresa comercial tradicional combinado con proveedores, clientes y socios. Dominios Arquitectura : Una descripcin completa arquitectura de la empresa deben contener todos los dominios de cuatro arquitecturas (empresariales , datos, aplicaciones , tecnologa ), pero la realidad de las limitaciones de recursos y tiempo, a menudo significa que no hay tiempo suficiente , la financiacin o los recursos para construir una de arriba hacia abajo , descripcin de la arquitectura de todo incluido que abarca todos los cuatro dominios de la arquitectura , incluso si el mbito empresarial se elige para que sea menor que la extensin completa de la empresa en general . Alcance vertical , o el nivel de detalle : En qu nivel de detalle debe ir el esfuerzo architecting ? Cunto arquitectura es "suficiente" ? Cul es la adecuada delimitacin entre el esfuerzo , la arquitectura y otras actividades relacionadas ( diseo de sistemas, ingeniera de sistemas , desarrollo de sistemas ) ? Horizonte de tiempo : Cul es el horizonte de tiempo que necesita ser articulado para la Visin Arquitectura, y tiene sentido (en trminos de funcionalidad y recursos ) para el mismo horizonte que se tratarn en la descripcin detallada de la arquitectura? Si no es as , cuntos arquitecturas de referencia son por definir, y cules son sus horizontes ? Estos aspectos se analizan en detalle a continuacin. En cada caso , en particular en entornos de gran escala donde arquitecturas estn necesariamente desarrollaron de manera federados , existe el peligro de arquitectos optimizacin dentro de su propio alcance de la actividad , en lugar de en el nivel de la empresa en general . A menudo es necesario sub - optimizacin en una zona determinada , con el fin de optimizar a nivel de empresa . El objetivo debe ser siempre de buscar el ms alto nivel de coincidencia y se centran en mdulos escalables y reutilizables con el fin de maximizar la reutilizacin a nivel de empresa .

Empresa Scope / Focus

Una de las decisiones clave es el foco de los esfuerzos de la arquitectura, en cuanto a la amplitud de la actividad global de la empresa a cubrir ( qu sectores especficos de negocios , funciones , organizaciones , zonas geogrficas , etc.)

Un factor importante en este contexto es la creciente tendencia de la evolucin de arquitectura gran escala que se realizarn en forma de "arquitecturas federadas " - independientemente desarrollados , mantenidos y administrados arquitecturas que posteriormente se integran en un marco de arquitectura de meta . Dicho marco se especifican los principios de interoperabilidad , la migracin y la conformidad. Esto permite que las unidades de negocio especficas que se han desarrollado arquitecturas y gobernados como proyectos de arquitectura independientes.

Arquitecturas complejas son muy difciles de manejar , no slo en trminos del propio proceso de desarrollo de la arquitectura , sino tambin en trminos de conseguir aceptacin por parte de un gran nmero de partes interesadas. Esto a su vez requiere un enfoque muy disciplinado para identificar los componentes arquitectnicos comunes , y la gestin de los puntos en comn entre los componentes federados - decidir cmo integrar , lo que la integracin , etc

Hay dos enfoques bsicos para el desarrollo de la arquitectura federada :

La empresa global se divide " verticalmente " , a la empresa "segmentos ", cada uno representando un sector de negocio independiente dentro de la empresa en general , y cada uno con su propia arquitectura de la empresa con, potencialmente, los cuatro dominios de la arquitectura ( de negocios , datos, aplicaciones , tecnologa ) . Estas arquitecturas separadas , multi-dominio pueden ser desarrollados con vistas a la integracin posterior , pero tambin pueden ser aplicadas en su propio derecho , posiblemente con entornos de destino intermedios definidos , y por lo tanto representan un valor para la empresa en su propio derecho . La estructura general de la empresa se divide " horizontal " , en " sper -dominios " arquitectnicas , en el que se desarrolla cada dominio de la arquitectura ( de negocios , datos, aplicaciones , tecnologa ), que abarca la totalidad de la empresa en general y aprobado como un gran proyecto independiente de los otros, posiblemente por personal diferente . Por ejemplo , una arquitectura de negocios para la empresa global completa formara un proyecto independiente de la arquitectura , y los dems dominios se elabor y aprob en proyectos separados , con miras a la integracin posterior .

El Gobierno de los EE.UU. , y en particular el Departamento de Defensa de EE.UU. (DoD ) , ha realizado y publicado trabajos de liderazgo en el campo de la arquitectura federada , haciendo hincapi en la necesidad de repositorios integrados y metamodelos para ayudar a la integracin y garantizar la interoperabilidad . Este trabajo es muy a la vanguardia de la tecnologa de ltima generacin , sin embargo , y lo que funciona en la prctica, sigue siendo en gran medida una cuestin de debate.

La seccin de Introduccin en el Marco de Arquitectura Empresarial Federal ( FEAF ), publicado por el Consejo Federal CIO EE.UU. explica las opciones de enfoque que daban al Gobierno de los EE.UU. en el desarrollo de la FEAF :

" En el desarrollo del Marco de Arquitectura Empresarial Federal , el Consejo CIO evalu tres enfoques. Enfoque convencional - requiere una inversin inicial sustancial en tiempo y dinero . En primer lugar , el marco debe ser desarrollado que muestra cmo preparar una descripcin de la arquitectura . En segundo lugar, la lnea de base actual debe ser descrito . Por ltimo , una arquitectura objetivo debe ser descrito . Slo despus de que se hayan completado estas actividades , la implementacin de los cambios necesarios arquitectura a travs del diseo , desarrollo y adquisicin de sistemas puede comenzar. Aunque este enfoque parece ser sonido , que puede resultar en " parlisis por anlisis " , debido a la complejidad del esfuerzo federal . Enfoque Segmento - promueve el desarrollo incremental de los segmentos de arquitectura en un marco de arquitectura empresarial estructurado. Este enfoque se centra en las principales reas de negocio (por ejemplo , las becas o los sistemas financieros comunes ) y es ms probable que tenga xito porque el esfuerzo se limita a funciones comunes o empresas especficas. Status Quo enfoque - representa lo de siempre resulta en un fracaso continuo para compartir informacin y hacer frente a la rpida evolucin del entorno . Este enfoque dara lugar a la reanudacin de negocios , disminucin de la productividad y las oportunidades perdidas y perdidas , as como el incumplimiento de los requisitos de la Ley Clinger - Cohen . ... Para mitigar el riesgo de extralimitacin con rendimientos mnimos, restringir los costos iniciales para una arquitectura convencional, y darse cuenta de rendimientos rpidamente, el Consejo CIO selecciona el tramo de aproximacin ...

La FEAF permite a las partes crticas de la empresa federal total , llamadas " segmentos arquitectnicos ", que se desarrollarn de forma individual , mientras que la integracin de estos segmentos en la arquitectura de la empresa ms grande " .

El enfoque FEAF tanto busca hacer una arquitectura empresarial "completo " a travs de una serie de dominios de negocio individuales seleccionados (o segmentos) , y despus de integrar estos en una arquitectura ms amplia de la empresa global .

Por el contrario , la Gua prctica de Arquitectura Empresarial Federal , tambin emitida por el Consejo Federal CIO EE.UU. , pone de relieve los peligros de la seleccin demasiado estrecho un mbito empresarial , sobre todo en los niveles ms altos de negocios :

" Es de vital importancia que el desarrollo de la arquitectura empresarial puede abordar de una manera gradual de arriba hacia abajo , de acuerdo con las opiniones arquitectura jerrquica , que son los bloques de construccin de marcos probados arquitectura empresarial .... De este modo , es igualmente importante que el alcance de los puntos de vista de negocios de alto nivel de la arquitectura de la empresa abarcan toda la empresa u organismo. Mediante el desarrollo de esta iniciativa en toda la comprensin de los procesos de negocio y reglas, y las necesidades de informacin , flujos y lugares , la agencia estar en condiciones de tomar buenas decisiones acerca de si la empresa, por lo que la arquitectura de la empresa , puede ser compartimentado apropiada. Sin ello, las decisiones de alcance acerca de la arquitectura de la empresa corre el riesgo de promover las operaciones de " estufa " entubada y entornos de sistemas , y en ltima instancia el rendimiento de la empresa sub -optimizacin y rendicin de cuentas . " La experiencia actual no parecen indicar que , con el fin de hacer frente a la cada vez ms amplio enfoque y la ubicuidad de arquitecturas , a menudo es necesario tener un nmero de diferentes arquitecturas existentes en toda la empresa , se centr en marcos de tiempo particulares , funciones de negocios , o requisitos de negocio ; y este fenmeno parece poner en duda la viabilidad de una nica arquitectura de toda la empresa para cada funcin de negocio o propsito. En tales casos, la necesidad primordial es la gestin y explotacin de las " federaciones " de la arquitectura . Un buen punto de partida es la adopcin de un modelo de publicacin y suscripcin que permite a la arquitectura para ser puesto bajo un marco de gobernanza . En este modelo , los desarrolladores de la arquitectura y de los consumidores en los proyectos de arquitectura ( el lado de la oferta y la demanda de trabajo de arquitectura) se inscriban en un marco de beneficio mutuo de gobierno que asegura que :

Material arquitectnico es de buena calidad , hasta a la fecha , el ajuste a los objetivos , y publicado ( revisado y acordado que se hagan pblicos ) . Uso de material de arquitectura puede ser monitoreada, y el cumplimiento de las normas , modelos y principios se puede exhibir , a travs de : Un proceso de evaluacin de la conformidad que describe lo que el usuario se suscribe a , y evala su nivel de cumplimiento

Un proceso de dispensacin que pueden conceder dispensas de cumplimiento de las normas de arquitectura y directrices en casos especficos ( por lo general con un fuerte imperativo de negocio ). Tcnicas de publicacin y suscripcin se estn desarrollando en el marco de gobierno de TI en general y especficamente para el mbito de la Defensa.

Arquitectura Dominios

Una arquitectura empresarial completa debe abordar todos los mbitos cuatro arquitecturas (empresariales , datos, aplicaciones , tecnologa ), pero la realidad de las limitaciones de recursos y tiempo, a menudo significa que no hay tiempo suficiente , la financiacin o los recursos para construir una de arriba hacia abajo , todo incluido Descripcin de la arquitectura que abarca los cuatro dominios de la arquitectura.

Arquitectura descripciones normalmente se construyen con un propsito especfico en mente - un conjunto especfico de factores de negocio que impulsan el desarrollo de la arquitectura - y aclarar la cuestin especfica ( s ) que la descripcin de la arquitectura est destinada a ayudar a explorar , y las preguntas que se espera que ayudar a responder , es una parte importante de la fase inicial de la ADM .

Por ejemplo , si el objetivo de un esfuerzo particular arquitectura es definir y analizar las opciones tecnolgicas para lograr una capacidad determinada , y los procesos de negocio fundamentales no estn abiertos a la modificacin, a continuacin, un completo Business Architecture bien puede no estar justificada. Sin embargo , debido a que los datos , aplicaciones y arquitecturas de tecnologa se basan en la arquitectura de negocio , la arquitectura de negocios todava tiene que ser pensado y entendido.

Si bien las circunstancias pueden dictar veces la construccin de una descripcin de la arquitectura que no contiene todos los dominios de cuatro arquitectura , debe entenderse que tal arquitectura no puede, por definicin , ser una arquitectura de la empresa completa . Uno de los riesgos es la falta de consistencia y por lo tanto capacidad de integrar . Integracin cualquiera tiene que venir ms tarde - con sus propios costos y riesgos - o los riesgos y compensaciones que implica el no desarrollo de una arquitectura completa e integrada que ser articulado por el arquitecto , y comunicada y entendida por la gestin de la empresa .

Vertical Alcance / Nivel de detalle

Se debe tener cuidado para juzgar el nivel de detalle adecuado para ser capturado , basado en el uso previsto de la arquitectura de la empresa y las decisiones que se tomen con base en ella. Es importante que un nivel uniforme y equitativa de profundidad puede completar en cada dominio de la arquitectura ( de negocios , datos, aplicaciones , tecnologa ) que se incluye en el esfuerzo de la arquitectura. Si se omite el detalle pertinente , la arquitectura no puede ser til . Si se incluye el detalle innecesario , el esfuerzo de la arquitectura puede superar el tiempo y los recursos disponibles , y / o la arquitectura resultante puede ser confuso o desordenado .

Tambin es importante para predecir el futuro utiliza la arquitectura de modo que , dentro de las limitaciones de recursos , la arquitectura puede ser estructurada para acomodar sastrera futuro , extensin , o re - uso . La profundidad y el detalle de la arquitectura de la empresa tiene que ser suficiente para su propsito , y no ms.

John Zachman aboga por el desarrollo de la arquitectura en toda la empresa con un enorme nivel de detalle , de la misma manera que una compaa aeroespacial necesita modelos para todo, hasta los tornillos y tuercas . Algunos consideran esto como una posicin extrema en trminos de alcance vertical, pero sin duda puede estar justificada si se compara con los costos de vida til de las alternativas . El argumento de Zachman es que los sistemas de informacin no son especiales. En otras industrias en las que se construyen muy caros, las cosas complejas , y no exista una expectativa de reparacin o cambio , los modelos se mantienen a un enorme nivel de detalle, con un gasto concurrente. Los aviones , edificios y coches se construyen de esta manera. Por qu son diferentes los sistemas de informacin ?

Sin embargo , no es necesario tratar de completar una descripcin detallada de la arquitectura en el primer intento . Futuras versiones del ADM, en un ciclo de vida de la arquitectura ms all, se basarn en los artefactos y las competencias creadas durante la iteracin actual .

La conclusin es que hay una necesidad de documentar todos los modelos de una empresa, a cualquier nivel de detalle es asequible , en una evaluacin del riesgo de cambio y el riesgo concomitante , y teniendo en cuenta la necesidad de integrar los componentes de los diferentes dominios de la arquitectura ( de negocios , datos, aplicaciones , tecnologa ) . La clave es entender la condicin de obra de arquitectura de la empresa, y lo que realmente puede lograr con los recursos y las competencias disponibles y , a continuacin, centrarse en identificar y entregar el valor que se puede lograr. Stakeholder valor es un elemento clave : un alcance demasiado amplio puede disuadir a algunas partes interesadas (sin retorno de la inversin ) .

Horizonte temporal

El ADM se describe en trminos de un nico ciclo de Vision Architecture , y un conjunto de arquitecturas de destino ( de negocios, datos , aplicaciones , tecnologa ) que permiten la aplicacin de la visin.

Sin embargo, cuando el alcance de la empresa es grande, y / o las arquitecturas objetivo particularmente complejos, el desarrollo de la Arquitectura descripciones de destino puede encontrar grandes dificultades , o incluso probar " misin imposible " , sobre todo si est llevando a cabo desde el principio.

En tales casos , una visin ms amplia puede ser tomada , por lo que una empresa est representado por varias instancias arquitectura diferentes , cada uno representa la empresa en un punto particular en el tiempo . Una instancia arquitectura representar el estado actual de la empresa (el " tal cual" , o lnea de base) . Otro ejemplo, la arquitectura , tal vez definida slo parcialmente , representar el ltimo estado final de destino ( la "visin" ) . En el medio, intermedio o " Arquitectura de transicin " casos pueden definirse , comprendiendo cada uno su propio conjunto de Arquitectura descripciones de destino .

Por este mtodo , el trabajo Arquitectura objetivo se divide en dos o ms etapas discretas :

En primer lugar, el desarrollo de arquitectura objetivo descripciones para todo el sistema ( gran escala ) , lo que demuestra una respuesta a los objetivos de las partes interesadas y las preocupaciones por un plazo de tiempo relativamente distantes ( por ejemplo, un perodo de seis aos ) . A continuacin, desarrollar una o ms " Arquitectura transitorias" descripciones , como incrementos o mesetas , cada uno de acuerdo con y convergentes en la arquitectura de las descripciones de destino , y la descripcin de los detalles del incremento en cuestin. En este enfoque , las arquitecturas de destino son de carcter evolutivo , y requieren una revisin peridica y actualizacin de acuerdo a la evolucin de las necesidades y la evolucin de la tecnologa de negocios , mientras que las arquitecturas son transitorias (por diseo ) incremento en la naturaleza, y , en principio, no deberan evolucionar durante el fase de aplicacin del incremento, a fin de evitar el sndrome de " blanco mvil " . Esto, por supuesto , slo es posible si el calendario de aplicacin est bajo un estricto control y relativamente corto ( tpicamente menos de dos aos ) .

Las arquitecturas de destino siguen siendo relativamente genrico, y debido a que son menos vulnerables a la obsolescencia de las arquitecturas transitorias . Ellos encarnan slo las decisiones arquitectnicas estratgicas , que deben ser bendecidos por los interesados desde el principio, mientras que las decisiones arquitectnicas detalladas en las arquitecturas transitorias son

deliberadamente posponer lo ms posible (es decir , justo antes de la ejecucin) , a fin de mejorar la capacidad de respuesta frente a nuevas tecnologas y productos vIS.

La empresa evoluciona mediante la migracin a cada una de estas arquitecturas transitorias en turno. A medida que cada Arquitectura de Transicin se implementa , la empresa logra un estado coherente , operativo en el camino a la ltima visin . Sin embargo, esta visin misma se actualiza peridicamente para reflejar los cambios en el ambiente de negocios y tecnologa , y en efecto puede en realidad nunca se puede lograr, como se describe en un principio. Todo el proceso se prolonga durante todo el tiempo que la empresa existe y contina cambiando .

Esta ruptura de la descripcin de la arquitectura en una familia de productos relacionados con la arquitectura , por supuesto, requiere una gestin eficaz del sistema y sus relaciones.

Integration Architecture

Hay una necesidad de proporcionar un marco de integracin que se encuentra por encima de las arquitecturas individuales . Esto puede ser un " marco empresarial ", como Zachman para posicionar los diferentes dominios y objetos , o puede ser un marco de arquitectura de meta (es decir , los principios , modelos y normas ) para permitir la interoperabilidad , la migracin y la conformidad entre las arquitecturas federadas. El propsito de este marco , la arquitectura meta es :

Deje que el arquitecto para entender cmo los componentes encajan en el marco Derivar los modelos arquitectnicos que se centran en las capacidades de nivel empresarial Definir los estndares de conformidad que permiten la integracin de los componentes para obtener el mximo apalancamiento y de re - uso Como se describi anteriormente , un nmero importante de decisiones de mbito deben tenerse en trminos de enfoque en la empresa , el alcance arquitectura, nivel de detalle, horizontes de tiempo , y la eleccin de arquitecturas transitorias , cualquiera de las cuales puede dar lugar a un menor que descripcin completa arquitectura siendo desarrollado . Una posible manera de evaluar las lagunas en su alcance o el nivel de detalle es utilizar un marco de arquitectura de la empresa ( por ejemplo , Zachman ) para entender la cobertura de los artefactos .

Hay varios grados de descripcin de la arquitectura " integrabilidad " . En el extremo inferior , integrabilidad significa que las diferentes descripciones de la arquitectura (ya sea elaborado por una unidad organizativa o muchos ) debe tener un " look and feel " que es lo suficientemente

similares para permitir las relaciones crticas entre las descripciones que se identifiquen , con lo que , al menos, lo que indica la necesidad para una mayor investigacin . En el extremo superior , integrabilidad idealmente significa que diferentes descripciones deben ser capaces de ser combinados en una sola representacin lgica y fsica .

En la actualidad , el estado de la tcnica es tal que la integracin de la arquitectura puede llevarse a cabo slo en el extremo inferior del espectro de integrabilidad . Los factores clave a tener en cuenta son el nivel de detalle y el nivel de detalle en cada artefacto, y la madurez de las normas para el intercambio de descripciones arquitectnicas.

Como organizaciones abordan temas comunes ( como la arquitectura orientada a los servicios y la infraestructura de informacin integrada ) , y modelos de datos universales y surgen las estructuras de datos estndar, se facilitar la integracin hacia el extremo superior del espectro. Sin embargo , siempre habr la necesidad de una gobernanza eficaz de las normas para reducir la necesidad de una resolucin de la coordinacin y el conflicto manual.

resumen

El TOGAF ADM define una secuencia recomendada para las distintas fases y los pasos implicados en el desarrollo de una arquitectura, pero no se puede recomendar un alcance - esto tiene que ser determinada por la propia organizacin , teniendo en cuenta que la secuencia recomendada de desarrollo en el proceso de ADM es iterativo , con la profundidad y amplitud de alcance y los resultados aumentan con cada iteracin. Cada iteracin se sumar recursos para Arquitectura Continuum de la organizacin.

La eleccin del mbito de aplicacin es crtica para el xito de la arquitectura de esfuerzo . El factor clave aqu es la enorme complejidad de una , horizontal y verticalmente arquitectura empresarial completa e integrada , representada por una instancia completamente poblado del Marco Zachman . Muy pocos desarrollos de arquitectura empresarial de hoy en realidad se comprometen tanto esfuerzo en un solo proyecto de desarrollo , simplemente porque se reconoce que en los lmites del estado de la tcnica, un hecho que el propio John Zachman reconoce :

"Algn da , usted va a gustara tener todos estos modelos ... Sin embargo, yo no soy tan altruista a pensar que tenemos que tener a todos ellos hoy ... o incluso que entendamos cmo construir y administrar a todos hoy . Pero el hecho de que podamos identificar conceptualmente donde queremos llegar algn da, nos hace pensar ms en lo que estamos haciendo en el marco de tiempo actual que nos pueden impedir llegar a donde queremos ir en el futuro " . (Cita de la correspondencia de correo electrnico de John Zachman a George Brundage . )

El mismo Juan Zachman gusta sealar las alternativas disponibles para aquellos que no pueden tolerar la cantidad de trabajo que implica el desarrollo de todos los modelos necesarios en su marco . Slo hay tres opciones :

Ensayo y error (" derribar los muros ") A partir de nuevo La ingeniera inversa y la arquitectura de los sistemas existentes todos los cuales son peligrosos y / o muy costoso . Lo que es necesario debido a que el ritmo de cambio es tener un conjunto de artefactos fcilmente desplegables y un proceso para ensamblarlos con rapidez.

Si bien este marco completo es til (de hecho, esencial) para tener en cuenta que el objetivo final a largo plazo , en la prctica es una decisin clave que hacerse en cuanto al alcance de un esfuerzo especfico de arquitectura empresarial . Siendo este el caso , es de vital importancia para comprender la base sobre la cual se toman las decisiones de alcance , y para establecer las expectativas correctas para lo que es la meta del esfuerzo.

La directriz principal es centrarse en lo que crea valor para la empresa , y para seleccionar el alcance horizontal y vertical, y horizontes temporales , consecuencia. Independientemente de si se trata de la primera vez , entiendo que se repetir este ejercicio, y que las versiones futuras se basarn en lo que se est creando en el esfuerzo actual , aadiendo mayor anchura y profundidad. volver al principio de la pgina