Diagrama de Jerarquía de Clases

El propósito del diagrama de jerarquía de clases es mostrar los actores técnicos desde una perspectiva de la jerarquía de clases. Este diagrama provee una visión de los interesados dando idea de quién está usando los datos, cómo, por qué y cuándo.

Diagrama Seguridad de Datos

El propósito del diagrama de seguridad de datos es describir qué actor (persona, organización o sistema) puede acceder a los datos de la empresa. Esta relación puede ser demostrada en forma de matriz entre dos objetos o puede mostrarse como una asignación.
El diagrama también puede utilizarse para demostrar el cumplimiento de las leyes de privacidad de datos y demás normativas aplicables. Este diagrama también debe considerar cualquier implicación de confianza donde los socios de una empresa o terceros pueden tener acceso a los sistemas de la empresa, tales como una situación subcontratada donde información puede ser manejado por otras personas y puede incluso ser alojado en un país diferente.

Catalogo de servicios de negocio/Funciones

El propósito del catálogo de servicios de negocios / funciones, es la de proporcionar una descomposición funcional en una forma que se puede filtrar, informar, y preguntar, como suplementa a los diagramas de descomposición funcional gráfica El catálogo de servicios de negocios / funciones, puede utilizarse para identificar las capacidades de una organización y para comprender el nivel de gobierno que se aplica a las funciones de una organización. Esta descomposición funcional se puede utilizar para identificar nuevas
capacidades requeridas para apoyar el cambio de negocios o se puede usar para determinar el alcance de las iniciativas de cambio, aplicaciones o componentes de la tecnología.
Contiene las siguientes entidades del metamodelo:

• Unidad de Organización
• Funciones de negocios
• Servicio de negocios
• Servicio de Información del Sistema (puede ser incluidos opcionalmente)

Matriz de Stackeholders

La gestión de las partes interesadas es una disciplina importante que los profesionales de la arquitectura exitosa ya que se puede utilizar para ganar el apoyo de los demás, el desarrollo de las partes interesadas les ayuda a garantizar que sus proyectos tengan éxito donde otros fracasan.

El propósito de la matriz de los interesados es identificar los grupos de interés para la contratación  de la arquitectura, su influencia sobre el compromiso, sus preguntas clave, temas o preocupaciones que deben ser abordados en el marco de la arquitectura.
Entender las partes interesadas y sus necesidades permite a un arquitecto enfocar los esfuerzos en las áreas que satisfagan las necesidades de los interesados.

Debido a la naturaleza potencialmente confidencial de la información de mapeo de los interesados y el hecho de que la fase de la visión de la arquitectura está destinada a ser llevado a cabo utilizando técnicas de modelado informales, no hay entidades en un meta modelo específico que se utilizan para generar un mapa de las partes interesadas. El análisis de los interesados se debe utilizar durante la Fase A (Visión de Arquitectura) para identificar los actores clave en el sistema, e irlos actualizando a lo largo de cada fase; diferentes grupos de interés pueden ser descubiertos en el sistema a través del desarrollo de oportunidades y soluciones, en planeación de migración, y arquitectura de gestión del cambio. Las arquitecturas complejas son muy difíciles de manejar, no sólo en términos del propio proceso de desarrollo de la arquitectura, sino también en términos de obtener el acuerdo de la gran
cantidad de grupos de interés afectados por ella. Por ejemplo, al igual que un arquitecto de la construcción va a crear esquemas eléctricos, planos de planta y elevaciones para describir las distintas facetas de un edificio para sus diferentes grupos de interés (electricistas, propietarios, funcionarios de planificación), por lo que un arquitecto de la empresa debe crear diferentes puntos de vista de la empresa, arquitectura de sistemas de información y tecnología para los grupos de interés que tienen inquietudes relacionadas con estos aspectos.

TOGAF identifica específicamente este tema en todo el ADM a través de los siguientes conceptos:
 Las partes interesadas
 Preocupaciones
 Vistas
 Puntos de Vista

Diagrama de Cadena de Valor

Un diagrama de cadena de valor proporciona una vista de orientación de alto nivel de una empresa y cómo interactúa con el mundo exterior. En contraste con el diagrama de descomposición funcional más formal desarrollado dentro de la fase B (Arquitectura de Negocio), el diagrama de cadena de valor se centra en el impacto de la presentación.
El propósito de este diagrama es alinear de forma rápida a las partes interesadas para una iniciativa particular de cambio, de modo que todos los participantes entiendan el contexto funcional y organizativo de alto nivel de la participación en la puesta en marcha de una arquitectura. Una práctica habitual consiste en mostrar un diagrama de proceso de negocio simplificado, y para cada tarea de definir sus factores de valor y los cambios necesarios.
La cadena de valor empresarial, o cadena de valor, es un modelo teórico que permite describir el desarrollo de las actividades de una organización empresarial generando valor al cliente final.

Diagrama conceptual de solución

Un diagrama conceptual de solución provee una orientación de alto nivel de la solución prevista, con el fin de cumplir con los objetivos del contrato de arquitectura. Al contrario de los diagramas de arquitectura más formales y detallados desarrollados en las siguientes fases, el concepto de solución representa un “dibujo a lápiz” de la solución esperada al principio del contrato.

Este diagrama puede incorporar objetivos claves, requerimientos, y restricciones para el compromiso y también destaca áreas de trabajo a ser investigadas en más detalle con modelamiento arquitectónico formal.

Su propósito es, rápidamente, abordar y alinear a las partes interesadas (stakeholders) para una iniciativa de cambio en particular, de modo que todos los participantes comprendan qué es lo que el compromiso con la arquitectura está tratando de lograr y como se espera que un enfoque de solución en particular reunirá las necesidades de la empresa. Al momento de diseñar el diagrama, se debe presentar solo los componentes principales de la solución, y resuma sus conexiones usando dependencias de “acceso”. Conéctelos a aplicaciones existentes cuando sea necesario. Conéctelos a requerimientos, procesos, o funciones, los mismos conectados a metas. También exprese (a través de dependencias de “consumo”) que roles usan que componente.

Entregables-Catalogo de principios.

Los principios son reglas y directrices generales destinadas a perdurar y a mejorar  a través del tiempo. Tales reglas informan y soportan la manera en la cual la  organización se ajusta al cumplimiento de su misión.  A su vez, los principios pueden ser solo un elemento en un conjunto estructurado de ideas que colectivamente definen y guían a la organización desde valores hasta
acciones y resultados.  Se deben tener criterios para definir los principios correctamente:
 Comprensibilidad
Los dogmas fundamentales de un principio pueden ser rápidamente comprendidos  y entendidos por individuos de todas las partes de la organización. La intención de  un principio es clara y sin ambigüedad.
 Robustez
Los principios deben habilitar decisiones de buena calidad acerca de la arquitectura  y los planes a realizar y que se puedan cumplir políticas y estándares que serán  creados. Cada principio debe ser suficientemente preciso para soportar las
decisiones complejas y las situaciones controversiales.
 Completitud
Cada principio importante gobierna la gestión de la información y la tecnología para  la organización. Los principios cubren cada situación percibida.
 Consistencia
El conjunto de principios deben ser expresados en una manera que permita una  adecuada interpretación. Estos no pueden ser contradictorios hasta el punto de que un principio viole la esencia de otro. Cada palabra de un principio debe ser
cuidadosamente escogida para permitir una interpretación adecuada y consistente.
 Estabilidad
Las reglas deben ser duraderas y capaces de acomodarse a los cambios. Se deben establecer procesos de corrección para adicionar, remover o alterar los principios luego de que fueron definidos con anterioridad.

Componentes

Nombre: Debe representar la esencia de la regla para que sea fácil de recordar. Plataformas específicas de tecnología no se
deben mencionar en el nombre o la declaración del principio. Evitar palabras ambiguas como “soportar”, “considerar”, “abrir” y especialmente con “gestionar” o “manejar” y adjetivos o adverbios innecesarios.
Declaración :Tiene que comunicar la regla fundamental sin ser ambiguo. En la mayor parte, estas declaraciones para
gestionar la información son similares de una organización a la siguiente.
Razón fundamental :Debe sobresaltar los beneficios innatos del principio usando terminología de negocios. Apuntar desde la
similitud de la información y los principios tecnológicos hasta los principios de operaciones y gobierno. También describe la relación con otros principios y las intenciones con respecto a una correcta interpretación. Describe situaciones donde una regla precede o tiene más peso que otra en la toma de decisiones.

Implicaciones: Tiene que sobresaltar los requerimientos del negocio y de TI para llevar a cabo el principio, en términos de recursos, costos y actividades o tareas. Debe ser con frecuencia aparente con los sistemas actuales, estándares o prácticas. El impacto y las consecuencias al negocio como resultado de adoptar el principio deben ser claramente establecidos. El sentido del principio debe responderle al lector “Como me va a afectar”. Es importante no simplificar demasiado o juzgar el mérito del impacto. Algunos impactos pueden ser identificados como potenciales solamente, y pueden ser especulativos en lugar de ser completamente analizados.

Gestión de Requerimientos-ADM

Cada etapa de un proyecto de TOGAF está basada en los requerimientos del negocio, incluyendo validación. Los requerimientos se identifican, se almacenan y se gestionan al ingreso y egreso de las Fases relevantes del ADM. El proceso de Gestión de Requerimientos de Arquitectura se aplica a todas las Fases del ciclo del ADM. El proceso de Gestión de Requerimientos es un proceso dinámico que aborda la identificación de los requerimientos de la empresa, almacenándolos, y luego gestionándolos al ingreso y egreso de las Fases
relevantes del ADM. Este proceso es fundamental para conducir el proceso del ADM. La capacidad para hacer frente a los cambios de requerimientos es crucial para el proceso del ADM, dado que la arquitectura, por su propia naturaleza, aborda la incertidumbre y el cambio, tendiendo un puente entre las aspiraciones de los interesados y lo que se puede entregar como una solución práctica.

Fase H Gestión de cambios de Arquitectura-ADM

Proporciona seguimiento continuo y un proceso de gestión de cambios para asegurar que la arquitectura responda a las necesidades de la empresa y que se maximice el valor de la arquitectura para el negocio. La Fase H asegura que los cambios en la arquitectura se
gestionen de una manera controlada.

Fase G Gobierno de la implementación-ADM

Proporciona supervisión arquitectónica para la implementación. Prepara y publica Contratos de Arquitectura. Asegura que el proyecto de implementación esté en conformidad con la arquitectura. La Fase G define cómo la arquitectura delimita los proyectos de implementación, la supervisa al mismo tiempo que se la construye, y produce un Contrato de Arquitectura  firmado.