Architecture Development Method (ADM) Ángeles Arroyo Stephanie Joally Conde Muñoz Rosa María Gonzales Martínez David Lomelí Valderrábano Miguel Angel Ortiz Valdez Brian Reynaldo

Introducción TOGAF ADM es el resultado de continuas contribuciones de un gran grupo de profesionales de la arquitectura. Ésta describe un método para el desarrollo de una arquitectura empresarial, la cuál forma el núcleo de TOGAF. Esta Arquitectura integra elementos de TOGAF así como otros bienes arquitectónicos disponibles, para satisfacer las necesidades de negocio y de TI de una Organización.

The ADM, Enterprise Continuum, and Architecture Repository The Enterprise Continuum provee un marco y un contexto para soportar el apalancamiento de los patrimonios arquitectónicos en la ejecución de ADM. The Enterprise Continuum es una herramienta para la categorización de material de origen arquitectónico. La implementación práctica de Enterprise Continuum típicamente toma la forma de una Arquitectura de Repositorio, incluyendo arquitectura de referencia, modelos y patrones que han sido aceptados para ser utilizados con la Organización y el trabajo de arquitectura actual hecho previamente dentro de la misma.

En la ejecución de la ADM, la arquitectura no es solo el desarrollo de una instantánea de la empresa en determinados momentos en el tiempo, sino que también esta en el propio repositorio de arquitectura de la empresa, con todos los bienes arquitectónicos identificados y aprovechados a lo largo del camino, incluyendo, pero no limitado a, la arquitectura específica de la empresa resultante.

El desarrollo de la arquitectura es un proceso continuo y cíclico, y en la ejecución de la ADM repetidamente en el tiempo, el arquitecto añade gradualmente más y más contenido al Repositorio de Arquitectura de la organización. Aunque el objetivo principal de la ADM está en desarrollar una arquitectura específica de la empresa, en un ámbito mas amplio también puede ser visto como el proceso de trabajar con el propio Repositorio de Arquitectura de la empresa con bloques de construcción reutilizables pertinentes tomados del '’left ’’, el lado más genérico del Continuum Enterprise.

De hecho, la primera ejecución de la ADM a menudo será la más difícil, ya que los bienes arquitectónicos disponibles para su reutilización serán relativamente escasos. Incluso en esta etapa de desarrollo, sin embargo, habrá bienes arquitectónicos disponibles de fuentes externas, como TOGAF, así como de la industria de TI en general, que podrán ser aprovechados.

The ADM and the Foundation Architecture La ADM también es utilizada para completar la Foundation Architecture de una Empresa. Los requerimientos de negocio de una Empresa pueden ser utilizados para identificar las definiciones y selecciones necesarias en la Foundation Architecture. Esto podría ser un conjunto de modelos comunes reutilizables, políticas y definiciones de gobernabilidad, o incluso lo más específico, anular selecciones de tecnología (por ejemplo, si el mandato de la ley). La Población de la Arquitectura Fundación sigue principios similares a los de una arquitectura empresarial, con la diferencia de que los requisitos para el conjunto de una empresa están restringidos a las preocupaciones generales y por lo tanto son menos completos que para una empresa específica.

ADM and Supporting Guidelines and Techniques ADM Guidelines & Techniques es un conjunto de recursos, directrices, plantillas, listas de comprobación y otros materiales detallados, que son el soporte de TOGAF ADM.

Architecture Development Cycle Key Points El ADM es iterativo, durante todo el proceso, entre las fases, y dentro de las fases. Por cada iteración en el ADM, se debe de tomar una nueva decisión en cuanto a: La amplitud de la cobertura de la empresa que se define El nivel de detalle que se define La extensión del período de tiempo destinado a, incluyendo el número y la extensión de los periodos de tiempo intermedios Los bienes arquitectónicos para ser apalancados, incluyendo: Los bienes creados en iteraciones previas del ciclo de la ADM con la empresa Los bienes disponibles en otra parte de la industria (otros marcos, modelos de sistemas, etc.)

Estas decisiones deben basarse en una evaluación práctica de los recursos y competencias disponibles, y el valor que realmente espera obtener la empresa del ámbito elegido de la obra de arquitectura. Como un método genérico, el ADM está destinado a ser utilizado por empresas en una amplia variedad de diferentes áreas geográficas y aplicada en diferentes sectores verticales (tipos de industria). Como tal, puede ser, pero no necesariamente tiene que ser, adaptado a las necesidades específicas.

Basic Structure

Las fases del ciclo de ADM son además divididos en pasos, por ejemplo, los pasos dentro de la fase de Tecnología de Arquitectura son: Seleccionar modelos de referencia, puntos de vista y herramientas Desarrollar Tecnología de Base Descripción de Arquitectura Desarrollar Target Tecnología Descripción de Arquitectura Realizar análisis de las deficiencias Definir los componentes de la hoja de ruta Resolver los impactos en la Arquitectura del Paisaje Código de Conducta para opiniones Finalizar la Arquitectura Tecnológica Crear Documento de Definición de Arquitectura

Adaptando ADM ADM es un método genérico para el desarrollo de arquitecturas, el cual está diseñado para lidiar con la mayoría de los requerimientos organizacionales y de sistemas. Sin embargo la mayoría de las veces es necesario modificar o extender la suit ADM para necesidades específicas. Razones para adaptar ADM El orden de las fases de ADM son de cierta manera dependen de la madurez de la arquitectura de la empresa. Las fases son definidas por el negocio o los principios de la arquitectura de la organización El uso en conjunto con otro marco de trabajo empresarial

Gobierno de Arquitectura La administración de todos los artefactos de arquitectura, gobierno y procesos relacionados deberían ser soportados por un ambiente de control. Típicamente esto estaría basado en uno o más repositorios con soporte de versiones de objetos y procesos , control y estatus. La mayoría de las áreas de información administradas por un repositorio de gobierno deberían contener los siguientes tipos de información: Datos de referencia: Descripciones de los procedimientos de gobierno e información externa a la organización Estado de proceso: Toda la información referente al estado de cualquier proceso de gobierno que serán administrados Información auditable: Esta almacena todos las acciones de los procesos de gobierno completados

Alcance de la Arquitectura Hay muchas razones para restringir (o restringir) el alcance de la actividad de la arquitectura que en virtud de medidas, la mayoría de los cuales se refieren a límites en: La autoridad organizacional del equipo desarrollando la arquitectura Los objetivos y las preocupaciones de los accionistas a ser vistos dentro de la arquitectura La disponibilidad de personal, financiamiento y otros recursos Cuatro dimensiones son usadas para definir y limitar el alcance de la arquitectura: Alcance o enfoque organizacional: Cual es el alcance total de la organización y que tanto de este alcance debe enfocarse la arquitectura

Dominios de la Arquitectura: Una completa descripción de arquitectura debe contener los 4 dominios de arquitectura (negocio, datos, aplicación, tecnologia), pero la realidad de las limitaciones de recursos y tiempo, a menudo significa que no hay tiempo suficiente, la financiación o los recursos para construir una completa descripción de la arquitectura, que abarca todos los dominios de arquitectura, aunque el alcance de la organizacion es elegido para ser menos de la magnitud de la empresa en general. Nivel de detalle: Hasta que nivel de detalle la arquitectura debe llegar? Que tanta arquitectura es suficiente? Cual es la demarcación apropiada entre el desarrollo de la arquitectura y otras actividades relacionadas (diseño de sistema, ingeniería de sistema, desarrollo de sistema) Periodo de tiempo: ¿Cuál es el período de tiempo que necesita ser articulado para la Visión Arquitectura, y ¿tiene sentido (en términos de funcionalidad y recursos) para el mismo período que se tratarán en la descripción detallada de la arquitectura? Si no es así, ¿cuántos arquitecturas de referencia deben definirse por definir, y cuáles son los plazos?

Este enfoque puede ser particularmente eficaz cuando se necesita una visión a largo plazo, pero las etapas iniciales de implementación sólo entregará una fracción de esa visión. En estas circunstancias, las arquitecturas más detalladas inicialmente pueden ser producidos para hacer frente a un período de tiempo mucho más corto, con arquitecturas adicionales desarrollados'' justo a tiempo'' para la siguiente fase de aplicación.

Integración de la arquitectura 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 aspecto lo suficientemente similares para permitir las relaciones críticas entre las descripciones que ser identificados, tanto en menos, lo que indica la necesidad de una mayor investigación. En el extremo superior, integrabilidad idealmente significa que diferentes descripciones deben ser capaces de ser combinados en una sola representación lógica y física.