You are on page 1of 11

ZACHMAN FRAMEWORK

BIBIANA ALVARADO
DANIELA SIERRA
ANDRES BENAVIDES
CHRISTIAN CARDENAS
JEINER FARLEY DIAZ

Presentado a
YAMID E. RAMIREZ SANCHEZ

UNIVERSIDAD MINUTO DE DIOS


FACULTAD DE INGENIERA
Ingeniera de Sistemas
BOGOT
AGOSTO DE 2015

Contenido
Zachman Framework 1
Historia 1
Evolucin 1
Descripcin Especfica 1
Vistas o Filas 1
Fila 1 Vista de Planeacin / Alcance

Fila 2- Vista del Propietario / Modelo Empresarial

Fila 3 Vista del Diseador / Modelo de sistema de informacin...

Fila 4 Vista del Constructor / Modelo Tecnolgico.

Fila 5 Vista del Subcontratista / Especificacin Detallada

Fila 6 Vista del Sistema Actual / Empresa en Funcionamiento .......................

Enfoques o Columnas 2
Modelos o Celdas 2
Contexto... 2
Lgico... 2
Fsico... 2
Representacin Detallada....................................................................................... 2
Comparacin con COBIT ...................................................................................... 2
Resumen ............................................................................................................... 2
Observaciones ...................................................................................................... 2
Conclusiones.........................................................................................................

Bibliografa ............................................................................................................

Conceptos Iniciales

Para comprender este texto de manera correcta es necesario que exploremos cuatro
conceptos que sern utilizados de manera comn en este texto.
Arquitectura
Una arquitectura es lo fundamental de una organizacin, es decir sus componentes,
relaciones entre ellos y su ambiente al igual que los principios usados para gobernar.
Arquitectura Empresarial
Es la lgica con la cual los procesos de negocios y la infraestructura de TI reflejan la
integracin y la estandarizacin de requerimientos de un modelo operativo.
Framework de Arquitectura Empresarial
Es un kit de herramientas que puede ser usado para desarrollar mltiples
arquitecturas, debe describir un mtodo para disear un sistema de informacin en
trminos de bloques de construccin, mostrando en el proceso como estos se relacionan
entre s.
Tambin este debe tener una lista de estndares que se han de usar en la creacin de
estos bloques.
Gobernanza de TI
Gobernanza describe la manera en que las decisiones se toman y cmo estas estn
relacionadas con todos las dems partes, nunca llevando un proceso de caja negra.

Zachman Framework
Historia
Zachman Framework es un framework de arquitectura empresarial, el cual provee una
manera formal y sumamente estructurada de ver y definir lo que una empresa consiste.
Esta fue creada por John Zachman en los 1980s, quien se encontraba trabajando en IBM
en Business System Planning (Sistema de planeacin de Negocios o BSP), el cual
consista en un mtodo para analizar, definir y disear una arquitectura de informacin
para una organizacin. En 1982 Zachman haba concluido estos anlisis los cuales
podan hacer mucho ms que automatizar diseos de sistemas y manejar datos en el
campo de la planeacin estratgica de negocios y la administracin. Estos podran ser
utilizados en las reas ms problemticas y esotricas en esas pocas, por ejemplo
arquitectura, diseo de sistemas basados en datos, criterio de clasificacin de datos y
mucho ms.
En el artculo de 1987 A Framework for Information Systems Architecture (Un framework
para una arquitectura de un SI), Zachman resalt cmo el trmino
arquitectura el cual era usado de manera comn por profesionales de sistemas de
informacin y este tena un significado completamente diferente para planeadores,
diseadores, programadores, entre otros. Por ello, Zachman se dedic a desarrollar un
Framework para arquitecturas de informacin, el analiz el campo de la arquitectura
clsica al igual que mltiples proyectos complejos de ingeniera, de esta manera pudo ver
que siempre exista una aproximacin inicial similar, concluyendo que las arquitecturas
existen en mltiples niveles e involucran por lo menos tres perspectivas: Materiales en
bruto o datos, funciones de procesos y localizaciones o redes.
Esta arquitectura est diseada para ser un esquema de clasificacin para organizar
modelos de arquitectura. Provea una manera sinptica de los modelos necesitas para la
arquitectura empresarial. Information Systems Architecture no define en detalle los
modelos que debera contener, no reforzaba el lenguaje de modelado usado para cada
modelo y no propona un mtodo para crearlos.
En 1992 se present el framework mejorado con sus nuevas extensiones y se demostr
como este podra ser formalizado en la notacin de grficos conceptuales.
En 1997, Zachman aclaro como el framework se le debera llamar Framework for
Enterprise Architecture (Framework para Arquitectura Empresarial). Como podemos ver
existen mltiples propuestas de framework hechas por Zachman, cada vez que se refieren
a un Framework de Zachman se pueden referir a cualquier de los propuestos por el, los
cuales podemos definir de esta manera:
El framework inicial, nombrado A Framework for Information Systems
Architecture en 1987

The Zachman Framework for Enterprise Architecture de 1990, ao en el cual este


fue actualizado y renombrado.

O una de las versiones recientes, ofrecidas por Zachman International como


estndar de la industria.

Evolucin
De manera general, exploramos cmo el framework ha sufrido pocos cambios en s y
cmo estos han afectado su aplicacin.
En 1984, se propuso la primera versin del framework, a pesar del paso del tiempo los
conceptos no han cambiado, simplemente se ha refinado la representacin grfica.
Esta imagen muestra el concepto original del framework, creado en Junio de 1984,
consista de 3 columnas nicamente, a pesar de que en si son 6, las cuales no fueron
aadidas pues Zachman pensaba que no tendran acogida frente a los usuarios.

En 1992, el framework ya era conocido como Framework for Information Systems


Architecture. Esta versin tambin consta de 3 columnas ya que no exista el concepto
de pensamiento empresarial.

En el 2001, ya se conoca como Zachman Framework, contaba con mltiples


refinamientos y era ampliamente usada y distribuida.

Esta es la versin del ao 2008, la ms reciente y que cuenta con mltiples cambios
significativos respecto a sus versiones anteriores. Se elimina el modelo global, no se
usan adjetivos y es predominante la terminologa empresarial. La terminologa en azul
fue elegida de manera que se incluyeran nombres de
Enterprise y Normative Zachman Frameworks.
En general, se han cambiado mltiples aspectos estticos, pero Que no ha cambiado?

La teora del Framework: Todas las representaciones descriptivas pueden ser


expresadas en trminos de cosas y sus relaciones
La Lgica del Framework

Cada celda primitiva contiene dos entidades meta (meta, meta) y una cosa y una
relacin
Comprensiva y completa

Descripcin Especfica
La idea general en el Zachman Framework es que una cosa compleja o tem puede ser
descrita para diferentes propsitos de maneras diferentes usando tipos diferentes de
descripciones (textos, grficas). El framework provee 36 categoras necesarias para
describir de manera completa cualquier cosa, especialmente, cosas complejas como
bienes manufacturados (componentes electrnicos, por ejemplo), estructuras construidas
(Edificios) y empresas (la organizacin y todos sus objetivos, gente y tecnologas). Este
contiene seis vistas detalladas o niveles de abstraccin desde 6 perspectivas diferentes.
De esta manera, diferentes personas pueden mirar a la misma cosa de manera diferente,
esto crea una vista holstica del entorno, una capacidad sumamente importante.
Vistas o Filas
Cada fila representa una vista total de la solucin 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 debe proveer suficiente detalle para definir la solucin al nivel de la
perspectiva y estos se deben transferir a la prxima fila inferior.
Cada perspectiva debe tener en cuenta los requerimientos de las otras perspectivas y las
limitaciones que stas imponen. Las limitaciones de cada perspectiva se suman. Por
ejemplo, las limitaciones de las filas superiores afectan a las inferiores. Las limitaciones
de las filas inferiores pueden, pero no necesariamente afectan las filas superiores.
Entender los requerimientos y limitaciones implica conocimiento y entendimiento de
perspectiva a perspectiva.

Esta versin simplificada nos servir para explicar el funcionamiento del framework.
Fila 1 Vista de Planeacin / Alcance: El primer borrador de arquitectura es un
diagrama de Venn el cual muestra en trminos de tamao, forma, relaciones parciales y el
propsito final de la estructura. Corresponde a un sumario ejecutivo para un planeador
o inversionista que requiere una perspectiva general del sistema, cunto costara y
como se relacionara con el sistema general donde este operaria.
Fila 2- Vista del Propietario / Modelo Empresarial: Lo siguiente son los dibujos del
arquitecto que muestran cmo la construccin final sera desde la perspectiva del usuario,
el cual tendr que interactuar con este.
Corresponden a los modelos de la

empresa/negocio, los cuales constituyen los diseos del negocio y muestran las entidades
del negocio y cmo se relacionan los procesos.
Fila 3 Vista del Diseador / Modelo de sistema de informacin: Los planes del
arquitecto son la traduccin de los dibujos a representaciones detalladas de los
requerimientos desde una perspectiva de un diseador. Ellos corresponden al modelo
del sistema diseado por un Analista el cual debe determinar los elementos de
datos, el flujo de la lgica de los procesos y las funciones que representan entidades o
procesos de negocios.
Fila 4 Vista del Constructor / Modelo Tecnolgico: El contratista debe redibujar los
planes del arquitecto para representar la perspectiva del constructor con suficiente
detalle para entender las limitaciones de las herramientas,
Tecnologas y materiales. Los planes corresponden a los modelos tecnolgicos, los
cuales se deben adaptar al modelo de sistemas de informacin, estos tienen en cuenta
los lenguajes de programacin, los dispositivos de I/O u otra tecnologa de soporte.
Fila 5 Vista del Subcontratista / Especificacin Detallada: Los subcontratistas
trabajan desde plantas, en las cuales se especifican los detalles en partes o
subsecciones. Estas corresponden a las especificaciones detalladas que se le
dan a los programadores que desarrollan modelos especficos sin tener en cuenta el
contexto general. Alternativamente 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.
Contamos con seis categoras con sus respectivas interrogativas:
1)
2)
3)
4)
5)
6)

Descripcin de datos Que


Descripcin de funcin Como
Descripcin de Redes Donde
Descripcin del personal Quien
Descripcin del tiempo Cuando
Descripcin de la motivacin Porque

Modelos o Celdas
Los modelos se hacen explcitos en las intersecciones entre filas y columnas, a estas se
les conoce como celdas, las cuales son nicas, su contenido es normalizado segn el
enfoque de la perspectiva.
Las descripciones de estas utilizan un lenguaje general enfocado a un set
especfico de objetivos

Contexto

Porque

Como

Que

Quien

Lista
Objetivos

Lista
Proceso s

Lista
Lista de
Materiale s roles y
unidade
s

Donde

Cuando

Lugares
Lista
geogrfico s Eventos

Conceptual

Relacin de
Objetivos

Modelo
de
prcticas

Modelo
E/R

Modelo
relacin
de roles

Modelo de
localidades

Modelo
de
eventos

Lgico

Diagrama
de reglas

Diagram
a de
Proceso s

Diagram
a
de
roles

Diagram
a
de
relacin
de roles

Diagrama
de
localidade s

Diagram
a
de
Eventos

Fsico

Especificaci
n
de
Reglas

Esp.
Func. de
proceso

Esp.
Entidade s
de Datos

Esp.
Roles

Esp.
Localidad

Esp.
Eventos

Detallado

Detalles
Reglas

Detalles
proceso

Detalles
datos

Detalles
roles

Detalles
Localidad

Detalles
Eventos

Contexto
1) Porque Lista de Objetivos: Provee objetivos organizacionales de alto nivel
2) Como Lista Procesos: Se listan todos los procesos conocidos
3) Qu Lista de Materiales: Lista todas las entidades organizacionales conocidas
4) Quin Lista de Roles y Unidades: Lista todas las unidades de la organizacin,
subunidades y roles identificados.
5) Dnde Lugares Geogrficos: Localidades importantes para el negocio
6) Cuando Lista de Eventos: Lista de disparadores y ciclos importantes para la
organizacin
Conceptual
1) Porqu Relacin de Objetivos: Identifica una jerarqua de metas que soportan los
objetivos primarios.
2) Como Modelo de prcticas: Provee descripciones de los procesos, las entradas y
salidas.
3) Qu Modelo entidad relacin: Identifica y describe los materiales
organizacionales y sus relaciones
4) Quien Modelo Relacin de Roles: identifica roles de la empresa y sus unidades, al
igual que las relaciones existentes.
5) Donde Modelo de localidades: Identifica las localidades de la empresa y sus
relaciones
6) Cuando Modelo de eventos: Identifica y describe eventos y ciclos relacionados por el
tiempo.
Lgico
1) Porque Diagrama de Reglas: identifica y describe las reglas que tiene restricciones a
procesos sin importan la implementacin fsico-tcnica.
2) Como - Diagrama de Procesos: Identifica y describe transiciones de procesos
expresadas como frases verbo-sustantivo sin importar implementacin fsicatcnica.
3) Que Diagrama de Roles: Identifica y describe entidades y sus relaciones sin importar
implementacin fsica-tcnica.
4) Quien Diagrama de Relacin de Roles: Identifica roles y sus relaciones a otros roles
por los tipos de materiales que se obtienen en sus procesos sin importar implementacin
fsica-tcnica.
5) Donde Diagrama de Localidades: Identifica y describe las localizaciones usadas para
acceder, manipular y transferir entidades y procesos sin importar implementacin fsicatcnica.

6) 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
implementacin fsica-tcnica.
Fsico
1) Porque Especificacin de Reglas: Expresadas en lenguaje formal, consisten de un
nombre de la regla y su lgica estructurada para especificar y probar el estado de la regla.
2) Como Especificacin Funcin de Proceso: Expresada en un lenguaje especfico
segn su tecnologa, los procesos jerrquicos se relacionan por llamadas a procesos.
3) Qu Especificacin Entidades de Datos: Expresado en un formato especfico segn
su tecnologa, cada entidad se define por nombre, descripcin y atributos mostrando sus
relaciones.
4) Quien Especificacin Roles: Expresa los trabajos que los roles desempean al igual
que los componentes del workflow
5) Donde Especificacin Localidad: Expresa la infraestructura fsica, componentes
y conexiones
6) Cuando Especificacin Eventos: Expresa transformaciones de los estados y los
eventos de inters a la empresa.
Representacin Detallada.
Esta fila no se utiliza para un nivel empresarial, como se mencion previamente.
Zachman como tal no es un framework, es ms una taxonoma, con la cual se organizan
los artefactos de la arquitectura, es decir documentos de diseo, especificaciones y
modelos. Esto tiene en cuenta los objetivos de este y el problema a tratar.
Por esta razn, este framework es destacable para clasificar toda la estructura de una
empresa de manera inteligente y ordenada, pero el manejo de procesos es pobre y se
trata de manera superficial.
Observaciones
Cada framework es un universo aparte el cual fue creado para satisfacer una
necesidad de una industria especfica, por ello se deben analizar detenidamente
antes de tomar una decisin sobre su uso.

Zachman, es ms una manera de organizar una empresa y de delegar


responsabilidades y dems. TOGAF es ms prctico desde mi punto de vista en los
aspectos de creacin de una arquitectura slida.

Conclusiones
Implementar sabiamente un framework es una decisin crtica, tanto de negocios como

de estrategia.
organizacin.

Con esta nos aseguraremos de no ignorar ningn aspecto de la

Al elegir un framework se debe analizar la estructura de la empresa al igual que sus

procesos, ya que cada framework por su origen no es una plantilla necesariamente


genrica.
Ejecutar los pasos y generar la documentacin necesaria al implementar un framework

es una tarea sumamente importante, por esto, es recomendable tener los servicios de un

consultor especializado en el framework para as no caer en errores de principiante que


pueden ser letales para nuestra organizacin.
Existen mltiples alternativas para implementar un framework, por esto, es bueno
compararlas y elegir una con base a otras empresas que funcionen de manera similar a la
nuestra.

Bibliografa
(s.f.). Recuperado el 18 de Marzo de 2010, de BESPOKE Systems:
http://www.bespokesystems.net/
Group, O. (s.f.). Architecture Governance. Recuperado el 19 de Marzo de 2010, de
http://www.opengroup.org/architecture/togaf8-doc/arch/chap26.html
International, Z. (s.f.). The Zachaman Framework Evolution. Recuperado el 19 de Marzo
de 2010, de http://www.zachmaninternational.com/index.php/ea- articles/100-thezachman-framework-evolution
Microsoft. (s.f.). A Comparison of the Top Four Enterprise-Architecture Methodologies.
Recuperado el 19 de Marzo de 2010, de http://msdn.microsoft.com/enus/library/bb466232.aspx