Documentos de Académico
Documentos de Profesional
Documentos de Cultura
EMPRESARIAL
Los diferentes frameworks de AE establecen una descripcin de la
arquitectura, la cual representan a travs de diferentes 'perspectivas' que
corresponden a las vistas o componentes principales que sirven como
instrumentos para el soporte de las operaciones del negocio.
INVESTIGACIN SOBRE
LOS FRAMEWORKS:
FEA, ZACHMAN,
TOGAF.
Contenido
INTRODUCCION ................................................................................................................................... 0
FEAF THE FEDERAL ENTERPRISE ARCHITECTURE FRAMEWORK (FEA) ................................................ 1
DESCRIPCIN ............................................................................................................................... 2
Modelo de Referencia del Negocio (BRM por sus siglas en ingls) ............................................ 3
Modelo de Referencia de Desempeo (PRM) ............................................................................. 3
Modelo de Referencia de Datos (DRM por sus siglas en ingls) ................................................. 4
Modelo de Referencia de Aplicaciones-Capacidades (ARM por sus siglas en ingls) ................. 5
Modelo de Referencia Tcnico (TRM por sus siglas en ingls) ................................................... 6
TOGAF ................................................................................................................................................. 7
Ciclo ADM .................................................................................................................................... 7
Fase A. Visin arquitectnica ...................................................................................................... 8
Fase B. Arquitectura de negocio ................................................................................................. 9
Fase C. Arquitectura de los sistemas de informacin ................................................................. 9
Fase D. Arquitectura tecnolgica ................................................................................................ 9
Fase E. Oportunidades y soluciones ............................................................................................ 9
Fase F. Plan de migracin ............................................................................................................ 9
Fase G. Implementacin de la gobernabilidad.......................................................................... 10
Fase H. Administracin del cambio de la arquitectura ............................................................. 10
Niveles de detalle ...................................................................................................................... 10
ZACHMAN.......................................................................................................................................... 20
LAS PERSPECTIVAS..................................................................................................................... 21
LAS DIMENSIONES ..................................................................................................................... 21
LA NEUTRALIDAD DEL MARCO DE REFERENCIA ........................................................................ 22
DESCRIPCIN DEL MTODO ...................................................................................................... 23
LOS PASOS DEL MTODO .......................................................................................................... 23
BIBLIOGRAFIA .................................................................................................................................... 28
INTRODUCCION
Las empresas requieren de instrumentos que les permitan una mayor agilidad
empresarial, la cual es posible si se facilita la implantacin de nuevos modelos de negocio
de forma rpida y la obtencin de una mejora en la eficiencia empresarial derivada de
unos procesos mejor orquestados, va una integracin ms natural, confiable y oportuna,
y que, en el mbito operativo de TI, estn representados principalmente en reduccin
de costos, facilidad de la escalabilidad, flexibilidad y oportunidad, y mejor administracin
de la seguridad, entre otros.
El desarrollo de la AE se debe entender como la descripcin integral y estructurada de
los diferentes elementos que conforman la empresa, que es realizada por equipos
interdisciplinarios que conocen muy bien la empresa, sus procesos, las lneas de negocio
y la forma en que la empresa evoluciona, que se acogen a las reglas y principios
corporativos, que aplican las tcnicas y metodologas establecidas, que se arriesgan a
proponer, a innovar y a disfrutar del proceso de construccin de diferentes procesos y
proyectos que apoyan el desarrollo del negocio, y que tienen la capacidad de percibir,
pensar y proyectar la empresa con una visin global e integral, sin perder de vista el
contexto en que sta se desenvuelve. El proceso de construccin de la AE no debe ser
visto solamente como el ejercicio de desarrollar o crear la arquitectura; la importancia
real radica en el hecho de que sta realmente sea til para quien la utiliza, que se
mantenga actualizada y que genere valor al negocio al ser aplicada en la ejecucin de
los proyectos.
El concepto de AE debe ser entendido entonces como una disciplina que provee
conceptos, modelos e instrumentos a las organizaciones para afrontar los retos que
representa la articulacin de las reas estratgicas y los procesos de negocios con las
reas de TI, con lo cual es posible generar mayor valor, mejorar el desempeo, la
comunicacin y la integracin en la empresas, que finalmente llevarn a la creacin de
ventaja competitiva mediante el apoyo efectivo para el cumplimiento de las estrategias
y objetivos establecidos en el negocio.
oportunidades.
Hoy en da muchas iniciativas y esfuerzos entre agencias estn en la va de implementar
arquitecturas en las agencias. Y las arquitecturas empresariales federales no deberan ser
impedimento para las implementaciones de la arquitectura de cada agencia.
DESCRIPCIN
La meta de FEAF (Federal Enterprise Architecture Framework) es mejorar la
interoperabilidad entre las agencias de gobierno de E.U. (Estados Unidos) mediante una
arquitectura empresarial para todo el gobierno federal. Este marco es de aplicabilidad
obligatoria
y
cubre
todas
las
organizaciones
del
gobierno.
FEAF contiene 5 modelos de referencia los cuales definen como es el el comportamiento de
la arquitectura. Estos son:
Esta Lnea de Visibilidadse implementa a travs del uso de una estructura jerrquica: rea
de Medicin, Categora de Medicin, Grupo de Medicin e indicador.
TOGAF
The Open Group Architecture Framework (TOGAF) es un mtodo paso a paso y probado
para desarrollar y mantener una Arquitectura Empresarial. Como vimos anteriormente
cubre los cuatro dominios principales de una arquitectura: negocio, sistemas de
informacin (aplicaciones), datos e infraestructura tecnolgica. Adems se enfoca en la
necesidad de que la arquitectura debe apoyar los objetivos y requerimientos del negocio
en forma flexible a travs del tiempo, independiente de fabricantes de tecnologas.
Es importante resaltar que The Open Group es un consorcio neutro a vendedores y
tecnologa cuya visin es el flujo de la informacin sin fronteras. El consorcio permitir el
acceso a informacin integrada dentro y entre las empresas, basado en estndares abiertos
y una interoperabilidad global.
TOGAF est compuesto por tres partes fundamentales:
1. El Mtodo de Desarrollo Arquitectnico (ADM) que veremos ms adelante
2. El Enterprise Continuum (Continuo empresarial), es decir, un repositorio virtual de
todos los activos arquitectnicos (modelos, patrones, descripciones, etc.) que existen
tanto dentro de la organizacin como en la industria de TI
3. La Base de Recursos, la cual es un conjunto de recursos como guas, plantillas,
informacin de fondo, etc. para ayudar al arquitecto en el uso del ADM
En cuanto al ADM, este se aplica para desarrollar la arquitectura de negocio y las tcnicas
con el fin de alcanzar las metas de la organizacin. Por el momento diremos que es un
proceso de 9 fases que lleva a la organizacin de la mano en el establecimiento de una
arquitectura empresarial. Este podra ser adaptado a las necesidades de la organizacin.
Al ser un framework de referencia TOGAF nos da un mapa de carretera para desarrollar el
tema. A continuacin se describir cmo.
Ciclo ADM
El ciclo ADM est diseado [Chase 2006] como un proceso iterativo que nos lleva a travs
de ocho fases de desarrollo, empezando con la Visin Arquitectnica y terminando con la
Implementacin del Control y la Administracin del Cambio a la Arquitectura. La idea es
construir el sistema en fases, completando un ciclo y embarcndose en el proceso de nuevo
para mejorar lo que se construy en la ltima ronda.
Cada fase contribuye a un conjunto de requerimientos, y se desarrolla desde ellos.
de la arquitectura objetivo (al menos en el papel) pero rara vez se implementar el sistema
completo de una vez (y si se hizo el resultado podra ser un caos). En esta fase se determina
el orden en el cual se implementan nuevos sistemas, es decir, la cartera de proyectos.
Artefactos de Entrada
1. Solicitud de Trabajo Arquitectnico
2. Estrategia, metas y conductores (driversI) del negocio
Artefactos de Entrada
1. Solicitud para Trabajo Arquitectnico
2. Declaracin del Trabajo Arquitectnico aprobada
3. Declaracin refinada de las metas del negocio y conductores estratgicos
4. Principios arquitectnicos, incluyendo los de negocio
5. Contino empresarial
6. Visin arquitectnica
7. Visin arquitectnica (escenarios del negocio/visin arquitectnica) incluyendo
a. Arquitectura de Negocio actual, versin 0.1
b. Arquitectura Tecnolgica actual, versin 0.1
c. Arquitectura de Datos actual, versin 0.1
d. Arquitectura de las Aplicaciones actual, versin 0.1
e. Arquitectura del Negocio objetivo, versin 0.1
f. Arquitectura Tecnolgica objetivo, versin 0.1
g. Arquitectura de Datos objetivo, versin 0.1
h. Arquitectura de las Aplicaciones objetivo, versin 0.1
Pasos
1. Desarrollar la descripcin de la lnea base de la arquitectura de negocio
2. Identificar modelos de referencia, puntos de vista y herramientas
3. Crear el(los) modelo(s) arquitectnico(s)
4. Seleccionar los bloques de construccin de la arquitectura de negocio
5. Conducir puntos de revisin formales del modelo arquitectnico y los bloques de
construccin con los involucrados
6. Revisar los criterios no funcionales (cualitativos) como desempeo, costo, volmenes
7. Completar la arquitectura de negocio
8. Desarrollar un anlisis de brechas y crear reporte
Artefactos de Salida
1. Declaracin de Trabajo Arquitectnico actualizada, si es necesario
2. Principios y metas de negocio as como los conductores estratgicos validados
3. Arquitectura de Negocio objetivo, versin 1.0, incluyendo
a. Estructura organizacional identificando ubicaciones del negocio y relacionndolas
con unidades organizacionales
b. Metas y objetivos del negocio para la empresa y cada unidad organizacional
c. Funciones del negocio un paso detallado y recursivo incluyendo una
descomposicin sucesiva de las reas funcionales ms grandes en sub-funciones
d. Servicios del negocio los servicios que la empresa y cada unidad empresarial
proveen a sus clientes, tanto interna como externamente
e. Procesos de negocio incluyendo mtricas y entregables
f. Roles del negocio incluyendo el desarrollo y modificacin de los requerimientos de
habilidades
g. Modelo de datos de negocio
h. Correlacin entre la organizacin y las funciones relacionando funciones del
negocio en unidades funcionales en la forma de un reporte tipo matriz
Artefactos de Entrada
1. Principios de la aplicacin, si existen
2. Principios de datos, si existen
3. Solicitud de Trabajo Arquitectnico
4. Declaracin del Trabajo Arquitectnico
5. Visin arquitectnica (escenarios del negocio/visin arquitectnica)
6. Continuo empresarial (una introduccin)
7. Lnea base de la arquitectura de negocio, versin 1.0 detallada, si es necesario
8. Arquitectura de Negocio objetivo, versin 1.0 detallada
9. Lnea base de la arquitectura de datos, versin 0.1
10. Arquitectura de Datos objetivo, versin 0.1
11. Lnea base de la arquitectura de aplicaciones, versin 0.1
12. Arquitectura de Aplicaciones objetivo, versin 0.1
13. Requerimientos tcnicos relevantes que aplicarn a las Fase C
14. Resultados del anlisis de brecha (de la arquitectura de negocio)
15. Bloques de construccin reutilizables (desde el continuo de la arquitectura, si estn
disponibles)
Pasos
1. Desarrollar la descripcin de la lnea base de la arquitectura de aplicaciones
2. Revisar y validar principios, modelos de referencia, puntos de vista y herramientas
3. Crear el(los) modelo(s) arquitectnico(s)
4. Identificar sistemas de aplicacin candidatos
5. Conducir puntos de revisin formales del modelo arquitectnico y los bloques de
construccin con los involucrados
6. Revisar los criterios cualitativos (como desempeo, costo, volmenes)
7. Completar la arquitectura de aplicaciones
8. Desarrollar un anlisis de brechas y crear reporte
Artefactos de Salida
1. Declaracin del Trabajo Arquitectnico actualizada, si es necesario
2. Lnea base de la arquitectura de aplicaciones, versin 1.0, si es necesario
3. Principios de aplicacin validados, o nuevos principios de aplicacin
4. Arquitectura de Aplicaciones objetivo, versin 1.0 5. Puntos de vista que atienden las
principales preocupaciones de los involucrados
6. Vistas de la arquitectura de aplicaciones correspondientes a los puntos de vista que
atienden las preocupaciones claves de los involucrados
7. Resultados del anlisis de brecha
8. Reporte de la arquitectura de aplicaciones resumiendo qu fue hecho y los hallazgos
principales
9. Anlisis de impacto 10. Requerimientos del negocio actualizados, si es necesario.
Fase C Arquitectura de Datos
Artefactos de Entrada
1. Principios de datos, si existen
2. Solicitud de Trabajo Arquitectnico
3. Declaracin de Trabajo Arquitectnico
4. Visin arquitectnica (escenarios del negocio/visin arquitectnica)
5. Requerimientos tcnicos relevantes que aplicarn a esta fase
6. Resultado del anlisis de brechas (de la Arquitectura de Negocio)
7. Lnea Base de la Arquitectura de Negocio, versin 1.0 detallada, si es necesario
8. Arquitectura de Negocio objetivo, versin 1.0, detallada
9. Lnea Base de la Arquitectura de Datos, versin 0.1, si est disponible
10. Arquitectura de Datos objetivo, versin 0.1, si est disponible
11. Bloques de construccin reutilizables (desde el continuo de la arquitectura, si estn
disponibles)
Pasos
1. Desarrollar la descripcin de la lnea base de la arquitectura de datos
2. Revisar y validar principios, modelos de referencia, puntos de vista y herramientas
3. Crear el(los) modelo(s) arquitectnico(s)
4. Seleccionar los bloques de construccin de la arquitectura de datos
5. Conducir puntos de revisin formales del modelo arquitectnico y los bloques de
construccin con los involucrados
Artefactos de Entrada
1. Principios de aplicaciones, si existen
2. Solicitud de Trabajo Arquitectnico
3. Declaracin de Trabajo Arquitectnico
4. Visin arquitectnica (escenarios del negocio/visin arquitectnica)
5. Requerimientos tcnicos relevantes que aplicarn a esta fase
6. Resultado del anlisis de brechas (de la Arquitectura de Negocio)
7. Lnea Base de la Arquitectura de Negocio, versin 1.0 detallada, si es necesario
8. Arquitectura de Negocio objetivo, versin 1.0, detallada
9. Bloques de construccin reutilizables, del Continuo empresarial, si estn disponibles
10. Lnea Base de la Arquitectura de Aplicaciones, versin 0.1, si es apropiada y est
disponible
11. Arquitectura de Aplicaciones objetivo, versin 0.1, si est disponible
Pasos
1. Desarrollar la descripcin de la lnea base de la arquitectura de aplicaciones
2. Revisar y validar principios, modelos de referencia, puntos de vista y herramientas
3. Crear el(los) modelo(s) arquitectnico(s)
4. Identificar sistemas de aplicacin candidatos
5. Conducir puntos de revisin formales del modelo arquitectnico y los bloques de
construccin con los involucrados
Artefactos de Entrada
1. Principios Tecnolgicos, si existen
2. Solicitud de Trabajo Arquitectnico
3. Declaracin de Trabajo Arquitectnico
4. Visin arquitectnica (escenarios del negocio/visin arquitectnica)
5. Lnea base de la arquitectura de negocio, versin 0.1 (de la Fase A)
6. Arquitectura Tecnolgica objetivo, versin 0.1 (de la Fase A)
7. Requerimientos tcnicos relevantes de fases anteriores
8. Resultados del anlisis de brechas (de la Arquitectura de Datos)
9. Resultados del anlisis de brechas (de la Arquitectura de Aplicaciones)
10. Lnea base de la arquitectura de negocio, versin 1.0 detallada, si es necesario
11. Lnea base de la arquitectura de datos, versin 1.0 detallada, si es necesario
12. Lnea base de la arquitectura de aplicaciones, versin 1.0 detallada, si es necesario
13. Arquitectura de Negocio objetivo, versin 1.0 detallada
14. Bloques de construccin reutilizables (desde el continuo de la arquitectura, si est
disponible)
15. Arquitectura de Datos objetivo, versin 1.0
16. Arquitectura de Aplicaciones, versin 1.0
Pasos
Artefactos de Entrada
1. Solicitud de Trabajo Arquitectnico
2. Declaracin del Trabajo Arquitectnico
3. Arquitectura de Negocio objetivo, versin 1.0
4. Arquitectura Tecnolgica objetivo, versin 1.0
5. Arquitectura de Datos objetivo, versin 1.0
6. Arquitectura de Aplicaciones objetivo, versin 1.0
7. Bloques de construccin reutilizables (desde el continuo de la arquitectura, si est
disponible)
8. Informacin del producto
Pasos
1. Identificar conductores claves de negocio que restringen la secuencia de
implementacin
2. Realizar una lluvia de ideas acerca de los requerimientos tcnicos desde la perspectiva
funcional
3. Realizar una lluvia de ideas sobre la coexistencia e interoperabilidad de los
requerimientos
4. Ejecutar una valoracin de la arquitectura y un anlisis de brechas
5. Identificar los paquetes de trabajo y proyectos principales
Artefactos de Salida
1. Estrategia de implementacin y migracin
2. Plan de implementacin de alto nivel
3. Anlisis de impacto lista de proyectos
Fase F Planeacin de la migracin
Artefactos de Entrada
1. Solicitud de Trabajo Arquitectnico
2. Declaracin del Trabajo Arquitectnico
3. Arquitectura de Negocio objetivo, versin 1.0
4. Arquitectura Tecnolgica objetivo, versin 1.0
5. Arquitectura de Datos objetivo, versin 1.0
6. Arquitectura de Aplicaciones objetivo, versin 1.0
7. Anlisis de impacto lista de proyectos
Pasos
1. Priorizar proyectos
2. Estimar los requerimientos de recursos y su disponibilidad
3. Ejecutar una avaluacin de costo/beneficio de los diferentes planes de migracin
4. Desarrollar un anlisis de riesgos
5. Generar el mapa de carretera de la implementacin (en el tiempo)
6. Documentar el Plan de Implementacin
Artefactos de Salida
1. Anlisis de impacto Planes de implementacin y migracin detallados
Fase G Implementacin de la gobernabilidad
Artefactos de Entrada
1. Solicitud de Trabajo Arquitectnico
2. Declaracin del Trabajo Arquitectnico
3. Bloques de construccin reutilizables
4. Anlisis de impacto Planes de implementacin y migracin detallados
Pasos
1. Formular la recomendacin de los proyectos
2. Documentar el Contrato de Arquitectura
Artefactos de Entrada
1. Solicitud de cambio arquitectnico cambios tecnolgicos
2. Solicitud de cambio arquitectnico cambios de negocio
Pasos
1. Actualizaciones de la arquitectura
2. Cambios al marco arquitectnico y a los principios
3. Nueva solicitud de cambio arquitectnico, para mover a otro ciclo
ZACHMAN
El Marco de Referencia de Zachman (Zachman, 1987) es una herramienta de pensamiento
que permite organizar, clasificar y analizar los diferentes descripciones arquitecturales o
artefactos de una empresa (modelos de estrategia, organigramas, modelos de procesos,
modelos de flujos de trabajo, modelos de datos, reglas de negocio, diagramas de
aplicaciones, diagramas de redes, especificaciones de programas, etc).
Aunque es descrito como un marco de referencia, Zachman es en realidad una taxonoma
arquitectnica, es decir, un esquema para organizar y categorizar artefactos arquitectnicos
(documentos de diseo, especificaciones y modelos) que toma en cuenta tanto a quin est
dirigido el artefacto como a cul asunto particular est siendo orientado. Esto lo hace
perfecto para documentar una Arquitectura de Sistemas de Informacin. Est basado en un
marco de prcticas tradicionales de arquitectura e ingeniera que result en un enfoque en
el cual los ejes verticales proveen mltiples perspectivas de la arquitectura general y en una
clasificacin en el eje horizontal de los varios artefactos en la arquitectura.
El propsito del marco de Zachman es proveer la estructura bsica que soporta la
organizacin, el acceso, la integracin, la interpretacin, el desarrollo, la administracin y
el cambio de un conjunto de representaciones (artefactos) arquitectnicas de los sistemas
de informacin de la empresa. No tiene una metodologa ni un modelo de referencia, por
lo que su implementacin es difcil.
LAS PERSPECTIVAS
El Planeador se ocupa del contexto de la empresa, de su entorno competitivo, de las
fuerzas internas y externas que influyen en su competitividad, del posicionamiento de
sus productos y servicios, que lo obligan a especificar sus alcances a largo plazo; esta
perspectiva cubre los componentes del nivel estratgico.
El Dueo se interesa en la operacin del negocio, para lo cual requiere del modelado de
la empresa mediante modelos de procesos, de flujos de trabajo, de logstica
empresarial, de modelos semnticos y de planes de negocio que le permitan controlar
la operacin de la empresa; esta perspectiva se centra en el proceso de negocio, por lo
que constituye en buena medida el nivel de procesos.
El Diseador tiene que ver con la especificacin de los planos conceptuales de los
sistemas de informacin que se requieren para soportar la operacin de los procesos.
El Constructor se encarga del ensamblado y fabricacin de los diversos componentes de
los sistemas de informacin de acuerdo con las restricciones de la tecnologa utilizada.
El Programador trabaja en la fabricacin de los componentes de acuerdo con las
especificaciones del constructor.
Las perspectivas del diseador, constructor y programador se ubican claramente en el nivel
de sistemas de informacin.
LAS DIMENSIONES
El Dato responde a la interrogante Qu?, para la perspectiva del planeador se refiere
a la lista de cosas importantes para el negocio como clientes, proveedores, productos,
servicios, contratos, facturas, etc.; conforme se va descendiendo a las perspectivas
inferiores se van teniendo diferentes descripciones relacionadas con la visin particular
de cada perspectiva: el dueo ve las cosas como entidades representadas en un modelo
eventos de negocio que inciden o son causados por el proceso, y la incorporacin de las
iniciativas estratgicas que se relacionan con el proceso.
Por otro lado, el Marco de Referencia no prescribe mtodos y tcnicas para el desarrollo de
los artefactos, ni mucho menos recomienda o sugiere herramientas, estndares o
tecnologas particulares. Esto es, el Marco de Referencia de Zachman es neutral ante
cualquier iniciativa de desarrollo de artefactos. Este hecho ha propiciado que un buen
nmero de proveedores de herramientas, acadmicos (Pereira, C. and Sousa, P., 2004) y
organismos independientes como la Comunidad de Reglas de Negocio, propongan modelos
y mtodos basados en el Marco de Referencia. Este mismo razonamiento hicieron los
autores de este trabajo al desarrollar un mtodo para obtener el artefacto de la celdilla
formada por el cruce del primer rengln (Planeador) y la columna de Funcin: la
Arquitectura de Procesos.
a los clientes previstos, identificando y definiendo los flujos de trabajo entre las diversas
unidades organizacionales. El diagrama resultante se denomina de la vista horizontal pues
centra su atencin en los clientes, a diferencia del organigrama que privilegia la relacin con
el jefe. El artefacto se ubica entre las dimensiones de Datos (productos, servicios, clientes
proveedores) y Funciones (flujos de trabajo).
iii.
iv.
Se coloca el bloque de los clientes del lado derecho, el de los proveedores del lado
izquierdo y el de la empresa en el centro;
Se identifican claramente los productos/servicios que provee la empresa (el Qu
hace), los clientes especficos a los que les surten (el Para Quin lo hace) y los
proveedores particulares de los que reciben insumos;
Se traslada el organigrama de la empresa en cuestin al bloque central, se
acomodan las diversas unidades organizacionales respetando la estructura
jerrquica;
Se identifica, dibuja, nombra y numera la secuencia de flujos de trabajo que
intervienen en la operacin de la empresa (el Cmo lo hace).
En este paso se entiende la manera en que la empresa crea el valor para los clientes. La
Configuracin de Valor describe la lgica que sigue el conjunto de actividades primarias que
crean valor para los clientes. En (Porter, 1980) se presenta la Cadena de Valor como la lgica
de creacin de valor vlida para cualquier tipo de empresa. Sin embargo, en (Stabell, C. and
Fjeldstad, O., 1998) se demuestra que la cadena de valor se ajusta perfectamente para
empresas manufactureras y comerciales pero es incapaz de modelar la creacin de valor de
empresas de servicios. Es por ello que se proponen dos nuevas configuraciones de valor: el
Taller de Valor y la Red de Valor.
Esto significa que cualquier empresa, sin importar su giro, podr ser modelada por una
Cadena, Taller o Red de Valor. Si esta aseveracin es cierta, en consecuencia nuestro
mtodo podr ser aplicado a cualquier empresa. Por otro lado, las configuraciones de valor
se componen de dos tipos de actividades o funciones de negocio: las Actividades Primarias
y las Actividades Secundarias. Las actividades primarias son las actividades relevantes de la
empresa, pues es donde se crea el valor para los clientes y constituyen la razn de ser de la
empresa y de la ventaja competitiva; ocupan la parte inferior del diagrama de configuracin
de valor.
Por el contrario, las actividades secundarias son actividades de soporte para las primarias,
son importantes y tiles pero no son relevantes para la empresa; ocupan la parte superior
del mismo diagrama. Las actividades primarias especficas dependen de la configuracin de
valor de que se trate y tienen que ver con la lgica de creacin de valor, mientras que las
actividades secundarias son las mismas sin importar la configuracin de valor. Tanto las
actividades primarias como las secundarias se componen a su vez de un conjunto de
Actividades de Negocio, que son las que realmente detallan la manera particular en que se
realiza el trabajo en la funcin de negocio.
En la cadena de valor el valor se crea al transformar las entradas (materia prima para
manufactureras y mercancas para comerciales) en productos (terminados para
manufactureras y entregados para comerciales). Es por ello que las actividades primarias
En este paso se identifican, modelan y definen los procesos esenciales de la empresa, los
cuales se encuentran dentro de las actividades primarias de la configuracin de valor
elegida. Para identificar los procesos esenciales se procede de la siguiente manera:
i.
ii.
iii.
iv.
v.
BIBLIOGRAFIA
1. F. Goethals et al., Managements and enterprise architecture click: The FADE framework, Information
Systems Frontiers, vol. 8, no. 2, pp. 67-79, 2006.
[ Links ]
2. F. S. De Boer et al., Change Impact Analysis of Enterprise Architectures, en Proceedings of the 2005 IEEE
International Conference on Information Reuse and Integration (IRI2005), Las Vegas, USA, 2005, pp. 1517.
[ Links ]
3. H. Jonkers et al., Enterprise architecture: Management tool and blueprint for the
organization, Information Systems Frontiers vol. 8, no. 2, pp. 63-66, 2006.
[ Links ]
4. S. H. Kaisler et al., Enterprise Architecting: Critical Problems, en Proceedings of the 38th Hawaii
International Conference on System Sciences (HICSS'05), Hawaii, USA, 2005.
[ Links ]
5. M. Lankhorst, Enterprise Architecture at Work Modeling, Communication, and Analysis, Berlin: Berlin
Heidelberg, SpringerVerlag, 2005, 352 p.
[ Links ]
6. J. M. Morganwalp, y A. P. Sage, Enterprise Architecture Measures of Effectiveness, International Journal
of Technology, Policy and Management, vol. 4, no. 1, pp. 81-94, 2004.
[ Links ]
7. R. Sessions. A Comparison of the Top Four Enterprise Architecture Methodologies, 20 de febrero,
2008;www.objectwatch.com.
[ Links ]
8. J. Zachman, A framework for Information Systems Architecture, the IBM Systems Journal vol. 26, no. 3,
pp. 454-470, 1987.
[ Links ]
9. U. S. D. o. Defense, Technical Architecture framework for Information Management (TAFIM), D. o.
Defense, ed., 1994.
[ Links ]
10. U. N. CONGRESS, Clinger-Cohen Act of 1996, 1996.
[ Links ]
11. R. Whittle, y C. Myrick, Enterprise Business Architecture: The Formal Link between Strategy and
Results,Boca Ratn, USA: CRC Press LLC, 2004, 256 p.
[ Links ]
12. J. Schekkerman, Enterprise Architecture Good Practices Guide: How to Manage the Enterprise
Architecture Practice: Trafford Publishing, 2006, 386 p.
[ Links ]
13. J. Schekkerman, How to Survive in the Jungle of Enterprise Architecture frameworks: Creating or
Choosing an Enterprise Architecture framework p. 266: Quality trade paperback, 2006, p.
[ Links ]
14. B. Scott, An Introduction To Enterprise Architecture, Bloomington: Authorhouse, 2005, p.
[ Links ]
15. R. Wurman, y P. Bradford, Information Architects, Zurich, Switzerland: Graphis Press, 1996,
p.
[ Links ]
16. J. Mc Govern et al., A Practical Guide to Enterprise Architecture, en, Bloomington: Prentice Hall,
2003.
[ Links ]