Zachman

Zachman Framework es un marco (framework) de arquitectura empresarial, el cual provee de una manera formal y estructurada de visualizar y definir lo que una empresa consiste.

Fue creada por John Zachman en los 1980’s, en ese entonces trabajaba en IBM en Business System Planning (Sistema de planeación de Negocios o BSP), sobre un método para analizar, definir y diseñar una arquitectura de información para una organización. En el año 1982 Zachman había concluido los análisis que permitían hacer más que automatizar diseños de sistemas y manejar datos en el campo de la planeación estratégica de negocios y la administración. Estos se podrían utilizar en las áreas más problemáticas definidas en esa época, por ejemplo arquitectura, diseño de sistemas basados en datos, criterio de clasificación de datos y mucho mas.

En su artículo de 1987 “A Framework for Information Systems Architecture” (Un framework para una arquitectura de un SI)17_{, Zachman resaltó el término}

17 _{J.A. Zachman, 1987, Obtenido de: https://www.zachman.com/resources/ea-articles-reference/49-}

‘arquitectura’ el cual era usado de manera común por profesionales de sistemas de información y este tenía un significado completamente diferente para planeadores, diseñadores, programadores, entre otros.

Zachman se dedicó a desarrollar un Framework para arquitecturas de información, analizó el campo de la arquitectura clásica al igual que múltiples proyectos complejos de ingeniería, de esta manera pudo ver que siempre existía una aproximación inicial similar, concluyendo que las arquitecturas existen en múltiples niveles e involucran por lo menos tres perspectivas:

 Materiales en bruto o datos.  Funciones de procesos.  Localizaciones o redes.

Esta arquitectura ha sido diseñada para ser un esquema de clasificación a fin de organizar modelos de arquitectura. Proveía una manera clara de los modelos necesarios para la arquitectura empresarial. Information Systems Architecture no define en detalle los modelos que debería contener, no fortalecía el lenguaje de modelaje que se utilizaba en cada tipo y no exponía un método para su desarrollo.

En 1992, presentó el framework mejorado con sus nuevas extensiones y se demostró que podía ser establecido con signos de gráficos conceptuales (ver Gráfico 8. Evolución de Zachman).

Gráfico 8. Evolución de Zachman

Fuente: https://www.zachman.com/ea-articles-reference/54-the- zachman-framework-evolution

En 1997, Zachman aclaró como el framework le correspondería llamarse “Framework for Enterprise Architecture” (Framework para Arquitectura Empresarial). Existen diversos planteamientos de framework realizadas por Zachman, cada vez que se refieren a un ‘Framework de Zachman’ se pueden referir a cualquiera de las propuestas por el, las cuales se definen de la siguiente manera:

El framework inicial, nombrado “A Framework for Information Systems Architecture” en 1987

“The Zachman Framework for Enterprise Architecture” de 1990, este fué el año en de su actualización y su nuevo nombramiento.

O una de las versiones recientes, ofrecidas por Zachman International como un modelo de la industria.

3.4.2 Evolución

De manera general, el framework ha tenido pocos cambios en sí y han afectado su aplicación. En 1984, se planteó la primera versión del framework, a pesar del paso del tiempo los conceptos no se han alterado, sencillamente se ha venido puliendo en la representación grafica.

Esta imagen muestra el concepto original del framework, creado en Junio de 1984, consistía de 3 columnas únicamente, a pesar de que en si son 6, las cuales no fueron añadidas pues Zachman pensó en ese momento que no tendría un recibimiento positivo frente a los usuarios.

En 1992, el framework ya era conocido como “Framework for Information Systems Architecture”. Esta versión también consta de 3 columnas, esto debido a que en ese momento no se manejaba una definición de pensamiento empresarial.

A continuación se presenta el siguiente Gráfico 9. Evolución de Zachman del “Framework for Information Systems Architecture”.

Gráfico 9. Evolución de Zachman

Fuente: https://www.zachman.com/ea-articles-reference/54-the- zachman-framework-evolution

En el 2001, ya se conocía como “Zachman Framework”, esta versión tenia diversas distinciones y era considerablemente utilizada y distribuida, ver Gráfico 10. (Evolución de Zachman).

Gráfico 10. Evolución de Zachman

Fuente: https://www.zachman.com/ea-articles-reference/54-the-zachman-framework- evolution

En la versión del año 2008 se elimina el modelo global, no se utilizaban los adjetivos y es sobresaliente los términos empresarial. La terminología en azul fue elegida de manera que se incluyeran nombres de “Enterprise” y “Normative Zachman Frameworks” , como se observa en el Gráfico 11. (Evolución de Zachman).

En general, se han modificado diversos aspectos estéticos, sin la alteración de:

 La teoría del Framework: todas las formas descriptivas pueden ser formuladas en términos de cosas y sus relaciones.

 La lógica del Framework.

 Cada una de sus celdas originales contenían dos entidades meta (meta, meta) y una cosa y una relación.

 Comprensiva y completa.

Gráfico 11. Evolución de Zachman

Fuente: https://www.zachman.com/ea-articles-reference/54-the-zachman-framework- evolution

3.4.3 Descripción Específica

La finalidad de Zachman Framework es que algo muy complicado puede ser representado para distintas intenciones de formas diferentes utilizando diferentes tipos de representaciones (textos, graficas). El framework provee 36 categorías necesarias para describir de manera completa cualquier cosa, especialmente, cosas muy complicadas como por ejemplo: bienes manufacturados (dispositivos electrónicos, por ejemplo), estructuras (Edificios) y empresas (la organización y todos sus objetivos, gente y tecnologías). Abarca seis (6) vistas especificadas o fases de abstracción desde 6 perspectivas diferentes.

De esta forma, distintas personas pueden ver la misma cosa de manera diferente, esto crea una vista holística del entorno, siendo esta una capacidad sumamente importante.

3.4.4 Vistas o Filas

Cada fila representa una vista total de la solución desde una vista particular. Una fila superior o perspectiva no tiene necesariamente un entendimiento de toda la perspectiva inferior. Cada fila representa una perspectiva única, sin embargo, los contenidos de cada perspectiva deben proveer suficiente detalle para definir la solución al nivel de la perspectiva y estos se deben transferir a la próxima fila inferior.

Cada perspectiva debe tomar en cuenta los requisitos de las diferentes perspectivas y las restricciones que estás aplican. Las limitaciones de cada perspectiva se suman. Por ejemplo, las limitaciones de las filas superiores afectan a las inferiores. Las restricciones de las filas inferiores pueden, pero no obligatoriamente afectan las filas superiores.

Entender los requisitos y restricciones involucra el conocimiento y el entendimiento de perspectiva a perspectiva.

A continuación se describen las vistas de el framework de Zachman, en el Gráfico 12. Vistas de Zachman:

Gráfico 12. Vistas de Zachman

Fuente:

https://commons.wikimedia.org/wiki/File:Simplification_Zachman_Enterprise_Framework.jpg A continuación la descripción de las vistas:

Fila 1

– Vista de Planeación / Alcance: El primer esquema de arquitectura es un diagrama de Venn el cual muestra en términos de tamaño, forma, relaciones parciales y el propósito final de la estructura. Corresponde a un sumario ejecutivo para un planeador o inversionista que requiere una perspectiva general del sistema, su costo y su relación con el sistema general donde operaría.

Fila 2

- Vista del Propietario / Modelo Empresarial: Lo siguiente son los dibujos

del arquitecto que muestran como la construcción final seria desde la perspectiva del usuario, el cual tendrá que interactuar con este. Corresponden a los modelos de la empresa/negocio, los cuales constituyen los diseños del negocio y muestran las entidades del negocio y como se relacionan los procesos.

Fila 3

– Vista del Diseñador / Modelo de sistema de información: Los propósitos

requisitos desde una vista de diseñador. Ellos corresponden al modelo del sistema diseñado por un Analista el cual debe determinar los elementos de datos, el flujo de la lógica de los procesos y las funciones que representan entidades o procesos de negocios.

Fila 4

– Vista del Constructor / Modelo Tecnológico: El contratista debe redibujar

los planes del arquitecto para representar la perspectiva del constructor con bastante detalle para su mejor comprensión de las restricciones de las herramientas, así como de tecnologías y materiales. Los planes corresponden a los modelos tecnológicos, los cuales deben ser ajustados al modelo de sistemas de información, teniendo en cuenta los lenguajes de programación, los dispositivos de I/O u otra tecnología de soporte.

Fila 5

– Vista del Subcontratista / Especificación Detallada: Los subcontratistas

producen desde plantas, en las que se especifican los segmentos o sub- secciones correspondientes a las representaciones que se especifican y que se le entregan a los programadores para que lleven a cabo el desarrollo de los diferentes tipos que se definen, sin tomar en cuenta el contexto general. Sucesivamente pueden representar soluciones COTS o GOTS (soluciones ya listas, empresariales o gubernamentales).

Fila 6

– Vista del Sistema Actual / Empresa en Funcionamiento Enfoques o Columnas

En resumen, cada perspectiva le da enfoque a una pregunta fundamental donde estas se resuelven desde ese punto, creando diferentes representaciones (modelos), lo cual se interpreta desde perspectivas de alto a bajo nivel.

Se cuenta con seis categorías con sus respectivas interrogativas, ver Gráfico 13. (Matriz Zachman):

 Descripción de datos – ¿Qué?  Descripción de función – ¿Cómo?

 Descripción de Redes – ¿Dónde?  Descripción del personal – ¿Quién?  Descripción del tiempo – ¿Cuándo?  Descripción de la motivación – ¿Por qué?

Gráfico 13. Matriz Zachman

¿QUÉ? - INVENTORY SETS.

“Describe las entidades involucradas en cada punto de vista de la empresa. Los ejemplos incluyen los objetos de negocio, datos del sistema, las tablas relacionales, las definiciones de campo”18_{. En efecto las partes interesadas} de la empresa como se verán relacionadas con la futura AE respecto a la data, también entendido como los datos.

¿CÓMO? - PROCESS FLOWS.

“Muestra las funciones dentro de cada perspectiva. Incluyen procesos de negocio, la función de la aplicación de software, la función del hardware del equipo, y lazo de control del lenguaje”. Enfocado así en la función de los flujos de proceso que llevan a cabo.

¿DÓNDE? - DISTRIBUTION NETWORKS.

“Muestra las localizaciones y las interconexiones dentro de la empresa. Esto incluye lugares geográficos empresariales importantes, secciones separadas dentro de una red logística, la asignación de los nodos del sistema, o incluso las direcciones de memoria dentro del sistema”. En sí, la distribución de las redes dentro de la organización.

¿QUIÉN? - RESPONSIBILITY ASSIGNMENTS.

“Representa las relaciones de las personas dentro de la empresa. El diseño de la organización empresarial tiene que ver con la asignación de trabajo y la estructura de autoridad y responsabilidad. La dimensión vertical representa la delegación de autoridad, y la horizontal representa la asignación de la responsabilidad”. Asignando las responsabilidades a personas con roles específicos.

¿CUÁNDO? - TIMING CYCLES.

“Representa el tiempo, o el caso de las relaciones que establecen los criterios de rendimiento y los niveles cuantitativos de los recursos de la empresa. Esto es útil para diseñar el programa maestro, la arquitectura de procesamiento,

18 _{Alekseigil's SAP Warehouse Management: Descripcion Conceptual de Arquitecturas}

Empresariales [en linea]<http://alekseigil.wordpress.com/2011/07/22/arquitecturas_empresariales/> [citado el 15 de agosto de 2014]

arquitectura de control, y dispositivos de sincronización”. Los ciclos de tiempo son útiles a la hora de llevar un control sobre el desarrollo de la AE.

¿POR QUÉ? - MOTIVATION INTENTIONS.

“Describe las motivaciones de la empresa. Esto pone de manifiesto los objetivos de la empresa y los objetivos, plan de negocios, la arquitectura del conocimiento y el diseño de los conocimientos”. Las intenciones de motivación deben ser claras a la hora de mostrar los cambios que traería la implementación de la AE.

3.4.5 Modelos o Celdas

Los modelos se hacen claros, en las intersecciones entre filas y columnas, a estas se les conoce como celdas, las cuales son únicas, su contenido es normalizado según el enfoque de la perspectiva, como se muestra en el Gráfico 14. (Matriz de modelos o celdas).

Las descripciones de estas utilizan un lenguaje general enfocado a un set específico de objetivos:

Gráfico 14. Matriz de modelos o celdas

Fuente: http://docplayer.es/6293737-Universidad-de-cuenca.html Contexto

 Porque – Lista Objetivos: Provee objetivos organizacionales de alto nivel.

 Como – Lista Procesos: Se listan todos los procesos conocidos.

 Que – Lista de Materiales: Lista todas las entidades organizacionales conocidas.

 Quien – Lista de Roles y Unidades: Lista todas las unidades de la organización, subunidades y roles identificados.

 Donde – Lugares Geográficos: Localidades importantes para el negocio.

 Cuando – Lista Eventos: Lista de disparadores y ciclos importantes para la organización.

Conceptual

 Porque – Relación de Objetivos: Identifica una jerarquía de metas que soportan los objetivos primarios.

 Como – Modelo de prácticas: Provee descripciones de los procesos, las entradas y salidas.

 Que – Modelo entidad relación: Identifica y describe los materiales organizacionales y sus relaciones.

 Quien – Modelo relación de roles: identifica roles de la empresa y sus unidades, al igual que las relaciones existentes.

Lógico

 Porque – Diagrama de Reglas: identifica y describe las reglas que tiene restricciones a procesos sin importan la implementación físico-técnica.  Como - Diagrama de Procesos: Identifica y describe transiciones de

procesos expresadas como frases verbo-sustantivo sin importar implementación física-técnica.

 Que – Diagrama de Roles: Identifica y describe entidades y sus relaciones sin importar implementación física-técnica.19

 Quien – Diagrama de Relación de Roles: Identifica roles y sus relaciones a otros roles por los tipos de materiales que se obtienen en sus procesos sin importar implementación física-técnica.

19 _{Gómez,Carlos, TOGAF Y ZACHMAN FRAMEWORK, recuperado de:}

 Donde – Diagrama de Localidades: Identifica y describe las localizaciones usadas para acceder, manipular y transferir entidades y procesos sin importar implementación física-técnica.

 Cuando – Diagrama de Eventos: Identifica y describe eventos que se relacionan de manera secuencial, al igual que los ciclos que ocurren entre eventos, sin importar implementación física-técnica.

Físico

 Porque – Especificación de Reglas: Expresadas en lenguaje formal, consisten de un nombre de la regla y su lógica estructurada para especificar y probar el estado de la regla.

 Como – Especificación función de Proceso: Expresada en un lenguaje específico según su tecnología, los procesos jerárquicos se relacionan por llamadas a procesos.

 Que – Especificación entidades de Datos: Expresado en un formato específico según su tecnología, cada entidad se define por nombre, descripción y atributos mostrando sus relaciones.

 Quien – Especificación Roles: Expresa los trabajos que los roles desempeñan al igual que los componentes del workflow.

 Donde – Especificación Localidad: Expresa la infraestructura física, componentes y conexiones

 Cuando – Especificación Eventos: Expresa transformaciones de los estados y los eventos de interés a la empresa.20