Archive | julio 2014

CATÁLOGOS/ DIAGRAMAS/ MATRICES TOGAF


  • Catálogo De Principios: Contiene los principios del negocio y de la arquitectura que describen la solución ideal que puede adoptar la organización.
  • Catálogo De requerimientos: Identifica los requisitos y los detalles que la empresa necesita saber para conocer sus objetivos.
  • Catálogo de Productos, Control, Eventos y Procesos: Proporciona la jerarquía, eventos que se dan a partir de, los productos que vienen desde, y los controles que se les aplican a la hora de la ejecución de los procesos.
  • Catálogo de portafolio de aplicación:  Identifica una lista de todas las aplicaciones de la empresa. Esta lista ayuda a definir el propósito de las iniciativas de cambio que pueden impactar en los tipos de aplicaciones.
  • Catálogo de interfaces (Fase C – Arquitectura de aplicaciones): Su propósito es documentar la relación entre interfaces y aplicaciones que permitan a las dependencias generales que se comuniquen tan pronto como sea posible.
  • Catálogo de portafolio tecnológico: Lista todas las tecnologías usadas en la empresa, incluyendo hw, sw y aplicaciones.
  • Diagrama de casos de uso del sistema: Especifican la funcionalidad y el comportamiento de un sistema mediante su interacción con actores, roles y otros sistemas.
  • Matriz de aplicaciones / datos: Representa la relación entre las aplicaciones y las entidades de datos que se tiene acceso.
  • Matriz actor/rol: El propósito de esta matriz es mostrar qué actores realizan qué roles, apoyándose en la definición de seguridad y los requisitos de habilidades.
  • Catálogo de estándares tecnológicos: Documenta los estándares que tienen que ver con tecnología cruzando las versiones, los ciclos de vida de la tecnología.
  • Un diagrama lógico de datos proporciona una vista gráfica de la estructura de un sistema de información, y le ayuda a analizar la estructura de su sistema de datos a través de entidades y relaciones.
  • Diagrama de Ingeniería de Comunicaciones (Fase D-Arquitectura Tecnológica): Describe los medios de comunicación – los métodos de envío y recepción de información – entre los activos de la Arquitectura Tecnológica. Identifica los límites de la red y la infraestructura de red necesaria.
  • El diagrama de ciclo de vida de los datos es una parte esencial de la gestión de los datos de negocio a través de su ciclo de vida, desde la concepción hasta la eliminación, dentro de las limitaciones del proceso de negocio.

34_contentfwk3

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

DIAGRAMA DE COMUNICACIÓN


  • El propósito del diagrama de comunicación de la aplicación es representar todos los modelos y las asignaciones relacionadas con la comunicación entre las aplicaciones en la entidad del metamodelo. Muestra los componentes de aplicaciones e interfaces entre los componentes.
  • Las interfaces pueden estar asociadas con las entidades de datos en su caso. Las aplicaciones pueden estar asociadas con los servicios de negocio en su caso. La comunicación debe ser lógica y sólo debe mostrar la tecnología intermedia donde es arquitectónicamente relevante.

page_1

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