Archive | Marco AE RSS for this section

DIAGRAMA DE MIGRACIÓN DE DATOS


  • Diagrama de migración de datos (Fase C – Arquitectura de datos) tiene como propósito mostrar el flujo de datos desde la fuente hacia las aplicaciones destino, proporcionando una representación visual de la propagación de fuentes y objetivos a alcanzar, sirviendo como una herramienta para la auditoría de los datos y su trazabilidad la cual evita la pérdida de información, aumenta la precisión en la carga de datos, reduce el  tiempo en de correcciones de información, se mejora la carga de información, se mantiene la integridad de los datos y se restringe el acceso a los datos a ciertos usuarios.

data-large

MATRIZ ROL/APLICACIONES


El propósito de la matriz de Rol / Aplicación es describir la relación entre las aplicaciones y los roles de negocio que sos utilizados por la empresa. El mapeo de la relación de componentes – función de aplicación es un paso importante, permite que el siguiente tenga lugar:

  • Asignar el uso de aplicaciones a las funciones específicas en la organización.
  • Entender los requisitos de seguridad de la aplicación, de los servicios y procesos de apoyo a la función de negocio, y se les trata de acuerdo con la política actual.
  • Apoyar el análisis de las deficiencias y determinar si alguna de las aplicaciones están deficiente y si es necesario la creación de una nueva.
  • Definir el conjunto de aplicaciones que utiliza una función de negocio en particular; esencialmente en cualquier movimiento hacia la computación basada en roles.

funcion

EVOLUCIÓN DE DODAF


  • DoDAF evolucionó en los EE.UU, la primera versión DoDAF fue desarrollado en la década de 1990 bajo el nombre de framework de arquitectura C4ISR. La primera versión oficial v1.0 C4ISR Architecture Framework, fue lanzada el  7 de junio de 1996, en respuesta a la aprobación de la Ley Clinger-Cohen. Desde principios de 1995 el subsecretario del Departamento de Defensa, encamino todos sus esfuerzos en definir y desarrollar un mejor medio en el proceso de asegurar que las capacidades de C4ISR fueran interoperables y que al mismo tiempo satisfagan las necesidades de los combatientes. El esfuerzo continuo desarrollado resultó en diciembre de 1997 en la segunda versión, C4ISR Architecture Framework v2.0.
  • En agosto de 2003 la v1.0 DoDAF fue lanzada, debido a la reestructuración del Framework v2.0 C4ISR para ofrecer mejor orientación, descripciones de productos, e información complementaria en dos volúmenes de un libro escrito. Se amplió la aplicabilidad de los principios y prácticas de arquitectura de todos los interesados y no sólo a la comunidad C4ISR.
  • Esta versión aborda el uso de arquitecturas integradas, las políticas del Departamento de Defensa y el Federal, el valor de las arquitecturas, las medidas de la arquitectura, los procesos de apoyo a la decisión del Departamento de Defensa, las técnicas de desarrollo, técnicas de análisis, y la CADM v1.01, y se dirigió hacia un enfoque basado en el repositorio, haciendo hincapié en  elementos de datos de arquitectura que integran productos.

evu

MARCO DODAF


  •  El framework de referencia DoDAF proporciona un marco fundamental para el desarrollo y la representación de un denominador común para el entendimiento, la comparación y la integración de las arquitecturas a través de fronteras organizativas, conjuntos y multinacionales. Este marco establece definiciones de elementos de datos, reglas y relaciones y un conjunto básico de productos para el desarrollo coherente de los sistemas integrados, o arquitecturas federadas.
  • Estas descripciones de arquitectura pueden incluir familias de sistemas (FOS), sistemas de sistemas (SOS), y las capacidades de red centralizada para interoperar e interactuar en el medio ambiente que no es de combate.
  • En este framework se contemplan todas las principales armas de EE.UU. y del Departamento de Defensa, las adquisiciones del sistema de tecnología de información en busca de desarrollar y documentar una arquitectura empresarial (EA) con las vistas previstas en el DoDAF. A pesar de que está claramente destinada a los sistemas militares, DoDAF tiene una amplia aplicabilidad en los sectores privado, público y voluntarios de todo el mundo, y representa uno de un gran número de sistemas de marcos de arquitectura  empresarial.
  • El propósito de DoDAF es definir conceptos y modelos que pueden utilizarse en los 6 procesos básicos del DoD(Departamento de defensa):1)    Capacidad de Integración y Desarrollo (JCIDS)

    2)    Planificar, programar, presupuestar y ejecutar (PPBE)

    3)    Adquisición de Sistemas de Defensa (DAS)

    4)    Ingeniería de Sistemas (SE)

    5)    Planificación Operativa (OPLAN)

    6)    Capacidad de manejo de la cartera (CPM)

Además, DoDAF 2.0 tiene como objetivos principales:

  • Establecer formas de arquitectura en función de los objetivos adecuados.
  • Aumentar la utilidad y la eficacia de arquitecturas a través de un modelo de datos riguroso el Meta Modelo DoDAF (DM2) por lo que las arquitecturas pueden ser integradas, analizadas, y evaluadas con más precisión.

dod

META-MODELO TOGAF


El meta-modelo proporciona  metodología y directrices para establecer una buena AE. Posee diferentes capas para su mayor y mejor aplicación en las organizaciones. A continuación se mencionaran algunas:

  • Arquitectura de principios(preliminar, visión)
  • Arquitectura de requerimientos
  • Arquitectura del negocio (procesos del negocio, sistemas administración, organización)
  • Arquitectura de aplicaciones (servicios)
  • Arquitectura de datos  (datos e información)
  • Arquitectura tecnológica (hw, sw, redes)

metamodelo

FASES DE DESARROLLO DE TOGAF


Togaf se compone de 10 fases donde la gestión de requerimientos interactúa con las demás. La metodología provee y necesita mucha documentación, por tal motivo se puede aprovechar la reusabilidad de la misma.

Fase A Preliminar

Es una de las más críticas puestos que es donde se prepara y se inician las actividades en todo el proceso. Aca se entienden los entornos del negocio y se establece los principios y la estructura de gobierno.

“Todos los cambios que se hagan tienen que estar soportados por escrito”

Fase B Arquitectura del Negocio

Muestra como la organización conoce sus objetivos del negocio. Se establece la relación de los procesos entre sí, los principios de gobierno, diseño y evolución. Intervienen las funciones del negocio, servicios del negocio, procesos del negocio, roles del negocio y los objetivos del negocio. Dispone de 8 pasos

  • Seleccionar modelos de referencia, puntos de vista y herramientas
  • Definición de la descripción de la arquitectura base
  • Definición de la descripción de la arquitectura objetivo
  • Ejecutar análisis de brechas
  • Definir la trayectoria candidata para componentes
  • Revisión formal de las conductas de los stakeholders
  • Finalizar la arquitectura
  • Crear el documento que define la arquitectura

Fase C Arquitecturas de los sistemas de información

El objetivo que se persigue con los sistemas de información en las empresas es automatizar la empresa. Si se logra que los SI resuelvan la automatización de la empresa entonces se podría escalar a los llamados sistemas de conocimiento.

Qué va primero, datos o aplicaciones? no importa desde que los dos modelos esten balanceados. Se debe hacer un proceso de iteración entre ambos para tener los modelos balanceados. La forma más ordenada de llegar a un mejor balanceo es partiendo de un enfoque orientado a procesos (yendome a las app, a los problemas mismos).

Fase D Arquitectura tecnológica

Se tiene la tecnología misma sobre la que se van a implementar las soluciones como: hw, protocolos, sw de dllo, sistemas de soporte para desarrollar los SI, tecnología de comunicaciones..

Diagramas de la tecnología que en un momento dado se quiere para la implementación.

Fase E Oportunidades y soluciones

  • Hacer el plan de implementación, especificar cómo se van a implementar esas soluciones.
  • Escoger o hacer el inventario de todos los proyectos que necesito tener para lo que voy a hacer.
  • Determinar si se va a pasar de un punto A a un punto B de modo incremental o de un solo paso.

Decidir sobre el enfoque:

  1.  Hacerlo o Comprarlo o Re-usarlo.
  2. Proceso de tercerización (que se contrata y que no).
  3. Mirar si en el mercado existen soluciones que yo pueda comprar (COTS    Commercial off the shelf).
  4. Mirar soluciones híbridas (compra una solución global y una local, aunque no es la mejor solución).
  5. Open Source: Comprar cajas negras o blancas.

Problemas desde el punto de la implementación:

  • La nube o no la nube.
  • Priorización (el orden en que se van a hacer las cosas, cómo se van a afrontar esos proyectos).
  • Cumplimiento (cumplimientos regulatorios).

Fase G Gobernanza de la implementación

  • Se busca que todo el proceso de implementación que se estableció, no pierda el rumbo, que todo esté ligado a obtener los objetivos, que conserve el rumbo hacia el objetivo planteado.
  • Verificar que los contratos estén bien elaborados y pensados en el sentido de que están orientados a alcanzar los objetivos planteados.
  • Garantizar que lo que se esta haciendo cumpla especificaciones, normas, políticas, directrices.
  • Garantizar que todo lo que se esta haciendo le está agregando valor a la organización.

Ventaja de la gobernanza:Da una visión global de toda la problemática

Fase H Gestión del Cambio

Los Ingenieros de sistemas somos gestores de cambio de manera permanente.

Hay que pensar en cómo hacer para que el cambio sea aceptado por una población que normalmente tiene inercia a seguir como venía.

  • Proveer un continuo monitoreo y un proceso de gestión de cambio.
  • Asegurarse que los cambios a la arquitectura son gestionados de una manera cohesiva.
  • Monitorear el negocio y la capacidad de gestión.
  • Garantizar que el cambio es coherente con todo el proyecto y que todo el proyecto permanece coherente.

 Togap13

GENERALIDADES TOGAF


The Open Group Architecture Framework en la actalidad se encuentra en la versión (9.1) del 2011. Está pensada para que “encaje” con otros marcos de referencia. Su objetivo es proporcionar metodología y directrices para establecer una buena AE. Posee fases iterativas y cíclicas. Está dedicado a orientar la gestión del cambio en la empresa.

En sus características se destaca enfoques de seguridad, stakeholders, análisis de brechas, gestión del cambio, requerimientos de interoperabilidad, gestión de riesgos, entre otros. Vuelve el concepto de gobernanza.

Desde los 90 Zachman era el propietario de estas metodologías y enfoques. Desde la versión 8 se empieza a tener una visión robusta de este enfoque. La versión 9 replantea los aspectos de la organización con respecto a los anteriores enfoques.

Las ventajas de una AE garantiza la no duplicidad, integración, eficiencia y por decirlo así una sola instancia de la información. Tener en cuenta poseer contratos para acordar los lineamientos correctamente entre las partes interesadas. Esta es una buena forma para garantizar calidad y orden.

Maneja 5 dominios:

  • Estrategia: Forma de como realizar los objetivos de la organización.
  • Negocio: Se maneja los procesos de la empresa.
  • Aplicaciones y Sistemas: Manejo de Sistemas de Información.
  • Información y Datos: La información es la clave para la organización.
  • Redes e Infraestructura: Es la infraestructura que soporta la información y los datos.

Se integra con marcos como Cobit (orienta en el direccionamiento), Prince2 (es el PMBOK orientado a tecnología) e Itil (TI orientado a servicio).

OP

ARQUITECTURA DINÁMICA


La arquitectura es algo dinámico (en el enfoque de sistemas). Se puede entender la arquitectura como la instancia de un objeto donde cada instancia se puede apreciar desde diferentes perspectivas o vistas. La visión depende del sujeto que la este apreciando.

Zachman utiliza unas comparaciones con respecto a la construcción de grandes sistemas o edificios. Se empieza de un nivel alto de abstracción para luego seguir con la descripción del sistema. Aquí el elemento principal es la planeación, análogamente con los planos del edificio.

Las columnas base de la arquitectura de Zachman es:

  • Qué (Datos) → Lista de materiales
  • Quién (Personal) → Instrucciones de Operación
  • Como (Funciones) → Especificaciones funcionales
  • Donde (Lugar) → Diagramas
  • Cuando (Tiempo) → Diagramas de Tiempo
  • Por que (A futuro) → Objetivos de Diseño

En los años 70 esta filosofía solo aplicaba a la parte de DATOS pero aproximadamente en los 90 se fue adaptando a la arquitectura empresarial. El enfoque implica la presencia de todos los personajes relacionados de la empresa.

Diferentes modelos de representación

  • Alcance de los Objetivos (Planeación)
  • Modelo empresarial (Owner)
  • Modelo de sistema (Diseñador)
  • Modelo de tecnología (Builder)
  • Representaciones detalladas (Subcontractor)

Los datos son a los insumos como los programas son la forma de cómo operar con los datos. Existen 6 reglas de este framework. Este framework sirve y aporta un modelo para tener una abstracción de la empresa y así poderla representar fácilmente.

cuadro

CATALOGO DE ROLES


  • El propósito del catálogo de roles es  proporcionar una lista detallada de todos los niveles o zonas de autorización dentro de la empresa. Con frecuencia, la seguridad de las aplicaciones o el comportamiento de las mismas, se definen en contra de los permisos  autorizados a nivel local, creando consecuencias complejas e inesperadas cuando se combinan con las aplicaciones que maneja el usuario final.
  • Si se definen los roles de manera clara y precisa, y son alineados con la organización y las aplicaciones, se generara una experiencia de usuario más fluida en general, además serán más seguras, ya que los administradores no tendrán que recurrir a soluciones alternativas con el fin de permitir a los usuarios llevar a cabo su trabajo.
  • El catálogo de roles además de apoyar el manejo de la seguridad en la empresa, también forma un insumo clave para la identificación de los impactos de la organización en la gestión del cambio, la correcta definición de los roles de trabajo, y la oportuna capacitación del  usuario final mantienen a la empresa en los más altos niveles de eficiencia.
  • Como cada rol implica el acceso a una serie de funciones en la empresa, si alguna de estas funciones se ve afectada, es necesario cambiar el manejo de éstas,  además es posible que las responsabilidades organizativas deban redefinirse, y pueda ser necesaria la definición de nuevas funciones.

rol

AE ENFOQUE BASE


Para definir una base de arquitectura empresarial, se puede tener en cuenta dominios o capas basados en un modelo genérico:

Modelo Estratégico:

  • Visión, Misión, Valores, Políticas
  • Portafolio de Productos y Servicios
  • Análisis Dofa
  • Análisis Competitivo
  • Modelo de Negocio
  • Mapa Estratégico
  • Cuadro de mando integral (BSC)

Arquitectura de Procesos: El inventario de procesos es esencial

Arquitectura de Datos: Como debe estar organizados los repositorios de datos y de información.

Arquitectura de Tecnología:

  • Arquitectura Orientada a Servicios
  • Arquitectura de Aplicaciones
  • Arquitectura de Infraestructura

Zachman es el referente importante para esta área. Se parte de que la organización es un “todo”. Se orienta bajo 2 vías: Gestión de Procesos y AE. Se parte de la estrategia para saber para donde ve y cuales son los objetivos de la empresa.

Se tiene en cuenta el concepto de Portafolio, el cual es un conjunto de proyectos y programas, donde los programas son de las empresas y no de los individuos. Los programas no poseen holgura. La administración de los programas no son proyectos.

Proyectos_Servicios_y_Arquitectura_Empresarial