QUE ES EA

1. MAESTRIA Y ESPECIALIZACION
GESTION ESTRATEGICA DE SISTEMAS Y
TECNOLOGIAS DE LA INFORMACION.
El CIO como ejecutivo de Negocios.

2. PROFESOR: Mg Espedito Passarello
2014
ASIGNATURA: INFRAESTRUCTURA
Y ARQUITECTURA TECNOLÓGICA

3. CLASE 2
¿Que es una Arquitectura
Empresarial?
Dante Minoli.
Material entregado para
lectura previa y exposición en
clase.

4. Que es una arquitectura empresarial?
MINOLI
 una arquitectura es "la organización
fundamental de un sistema, representada
en sus componentes, sus relaciones entre
sí y con el medio ambiente, y los
principios que rigen su diseño y evolución
".
 (ANSI / IEEE) Std. 1471-2000, Instituto
Americano de Estándares Nacionales /
Instituto de Ingenieros Eléctricos y
Electrónicos

5. La Arquitectura Empresarial es una práctica o una
forma de trabajar basada en principios de visión
sistémica, mejora continua e identificación integral
de todos los impactos que tendría la organización
en caso de ser necesario un ajuste en la
operación.
Debido a que busca documentar en mapas lo que
sucede en la operación y maneja diferentes
dimensiones que serán representadas, es
necesario mantener actualizados los mapas pues
serán información de referencia que nos permitirá
conocer todos los elementos relacionados con
cualquier ajuste. Estos mapas irán evolucionando
conforme la organización vaya cambiando.

6. Objetivo Global
 El objetivo de la arquitectura de la empresa es la
creación de un entorno de TI unificado (sistemas
de hardware y software estandarizados) para la
totalidad de las unidades de negocio de la
empresa.
 El objetivo de la Arquitectura Empresarial es
proveer una visión integral de la empresa, a
través de mapas que documenten los distintos
elementos que conforman a la operación y que
faciliten la mejora continua, permitiendo el
modelado de los posibles escenarios de ajustes a
los procesos del negocio.

7. ¿Porque ?
 El resultado final, en teoría, es que la definición de
arquitectura de la empresa hará que sea más
controlable el aspecto de las inversiones TI, alinea
a lo estratégico del negocio y permite una mayor
“visibilidad y transparencia” del acontecer de los
proyectos (concurrentes o no) .

8. ¿Para que?
 Alineación de TI a los modelos y procesos del
negocio.
 Normalización,
 Reutilización de los activos de TI existentes, y el
intercambio de métodos comunes para la gestión
de proyectos y desarrollo de software en toda la
organización.

9. MARCOS - MODELOS
 Se han formulado y aplicado una gran variedad
surgidos como necesidad para “comprender y
discernir” determinadas cuestiones practicas;
 ¿ Como empezar? Premisas y fundamentos.
 ¿ Que hacer? Funciones y actividades
 ¿Con que recursos? Skill de personas, soportes
técnicos, logística organizacional y financieras.
 ¿ Como ? Fases, procesos y métodos.
 Lo que es seguro que SIN COMPROMISO DIRECTIVO
es mejor no comenzar …..(REQUISITO MODELOS ISO)

10. DIVIDIENDO EL PROBLEMA; DOMINIOS
 Arquitectura de Negocio/procesos:
la documentación que describe los procesos de negocios
más importantes de la compañía;
 Arquitectura de la información:
Identifica los bloques importantes de información (registro
de cliente, productos y servicios, etc.) y los ciclos de
vida ( generación, captura, proceso, almacenamiento
y mantenimiento, comunicación, expurgación,
propietarios y accesos, etc.)
 Arquitectura del sistema de aplicación:
un mapa de las relaciones de aplicaciones de software.
 La arquitectura de tecnología de infraestructura:
un modelo para toda la gama de hardware, sistemas de
almacenamiento y redes.

11. Figura 1. Macro de vista del medio ambiente y de la arquitectura empresarial.

12. COMENTARIOS
 La arquitectura de negocio es la más crítica, pero también
más difícil de poner en práctica, de acuerdo a los
profesionales de la industria.
 El objetivo es el desarrollo de la infraestructura de TI para
apoyar un ambiente de estado final de TI que habilite,
comprometa y facilite la estrategia de negocio.
 Con este fin, la empresa desarrolla una arquitectura
empresarial, modelizando la “Gestión de requerimientos “
referidos a información, sistemas y el entorno tecnológico
adecuado”.
 Es fundamental las especificaciones funcionales y no
funcionales (activos de información).
 Las normas asociadas en cada dominio y su aplicación
(por ejemplo; protocolos, estándares, CC, etc.)

13. COMENTARIOS
 Para el desarrollo de la arquitectura las empresas
en general se utilizan los mecanismos de la
industria ( extremo inferior de la figura 1).
 Estos incluyen técnicas de TI de la industria y los
métodos para desarrollarla como una arquitectura
empresarial en base a;
 principios de arquitectura;
 estándares de arquitectura dela industria de TI,
 marcos y modelos para las arquitectura por parte de
la industria TI y,
 herramientas de desarrollo de la arquitectura.

14. En construcción….
 La dinámica empresaria, obliga a replantear nuevas
estrategia de negocio, lo que obliga a “considerar la
factibilidad de mantener o modificar la arquitectura
empresarial existente.
 Lo que debe ser evaluado y determinado por un análisis
del estado actual y el requerido.
 Disponer de una arquitectura permite realizarlo
coherentemente y colaborativamente (ver figura);
 la base existente de los activos de TI,
 la arquitectura existente de la empresa,
 las normas de arquitectura empresarial existentes,
 principios y prácticas de la empresa, la estrategia de
negocio deseado, y
 los marcos disponibles / herramientas para desarrollar una
nueva arquitectura de la empresa o modificar la existente.

15. Gobernabilidad y capacidad de evaluación.
La posibilidad de partir de una estado objetivo y
documentado disminuye esfuerzos.
El resultado de este análisis, permitirá establecer la
necesidad o no de reformular las estrategias de IT,
y evaluar impactos sobre la infraestructura actual;
-una nueva arquitectura de la empresa,
-modificación de la actual,
-un nuevo conjunto ,
modificado las normas de arquitectura empresarial,
Es necesario definir una hoja de ruta que describa los
proyectos de TI necesarios para efectuar (aplicar) la
nueva arquitectura y lograr el objetivo estado, y
un plan de desarrollo / implementación.

16. Los beneficios
 Marcos en capas y modelos para la arquitectura
empresarial han demostrado ser útiles, porque la
estratificación tiene la ventaja de definir contenidos,
particiones no superpuestas del medio ambiente.
 Si bien existen una “jungla” de modelos , Jaap
Schekkerman,Trafford Publishing Ltd, Ireland, Copyright
2003. Cómo sobrevivir en la selva de Arquitectura
Empresarial Frameworks:. Crear o elegir un Marco de
Arquitectura Empresarial.
 No existe consenso completo de la industria aun en un
modelo, pero son referentes; Zachman, The Open
Group Architecture Framework (TOGAF), a nivel
comercial y la Enterprise Architecture Framework
Federal (DoD/FEAF) a nivel gubernamental.

17.  El propósito de la arquitectura de la empresa es
crear un mapa de los activos de TI y procesos de
negocio y un conjunto de principios de gobierno
que impulsan un consenso acerca de la
estrategia de negocio y la forma en que se puede
expresar a través de la tecnologías.
 La Arquitectura Empresarial documenta en
diagramas de flujo a los principales procesos
punta a punta de la empresa, conformando un
mapa en que conviven y se relacionan las
diferentes dimensiones que decida llevar cada
organización. También asegura que la información
de cada uno de mapas esté desarrollada de
manera estandarizada, y que haya una
integración entre cada uno de los elementos que
los conforman.

18.  Es una práctica de mejora continua que plantea
una metodología que madurará gradualmente a
medida que la organización la vaya adoptando.
 Promueve una visión integral del modelo de
negocio, basándose en la interacción de todas las
dimensiones involucradas.
 Ayuda a crear un repositorio único de información
donde se incluyen los mapas de referencia.
 que reflejan los procesos de la empresa, estos
mapas plasman las dimensiones que definen al
negocio, además de identificar la relación que
existe entre ellas.

19. ¿Como realizo las transformaciones
(cambios, mejoras..)?
Es necesario definir una hoja de ruta (road map)
que describa los proyectos de TI necesarios para
aplicar la nueva arquitectura y lograr el objetivo
estado establecido como meta (target), y
un plan de transformación (desarrollo /
implementación ) con detalle de los
entregables, sus conformaciones y
habilitaciones.

20. NORMALIZACION….NORMALIZACION….
 Un caso en el que la normalización en el modelo de
capas se ha logrado es en el caso del modelo de
Interconexión de Referencia de Sistemas Abiertos
(OSIRM) publicado en 1984 por la Organización
Internacional de Normalización (ISO) este modelo, sin
embargo, sólo se aplica a las comunicaciones ).
 ANSI y el IEEE de ANSI / IEEE Std 1471-2000 Práctica
recomendada para la Descripción de Arquitectura de
Software Intensivo Sistemas, uno de los objetivos de la
presente norma tiene por objeto promover un enfoque
más coherente y sistemático a la creación de puntos
de vista (una visión es una representación de todo un
sistema desde la perspectiva de un conjunto
relacionado de problemas). Sin embargo, la adopción
de este modelo aún está lejos de ser universal.
 ISO, UIT-T, IEEE, ANSI, Internet Engineering Task Force
(IETF), OMG, etc.)

21. Tabla 1 Enterprise Architecture (EA) Marcos (lista
parcial)
 1. Zachman Enterprise Architecture Framework (ZIFA)
2. El Open Group Architecture Framework (TOGAF))
3. Extended Enterprise Architecture Framework (E2AF))
4. Enterprise Architecture Planning (EAP))
5. Federal Enterprise Architecture Framework (FEAF))
6. Tesoro Enterprise Architecture Framework (TEAF))
7. Marco Integrado de Arquitectura (FIA))
8. Arquitectura Técnica Mixta (JTA))
9. Comando, Control, Comunicaciones, Computación, Inteligencia,
Vigilancia y Reconocimiento (C4ISR) y DoD Architecture Framework
(DoDAF))
10. Departamento de Defensa de modelo de referencia técnica (DoD
TRM))
11. Marco de Arquitectura Técnica para la Gestión de la Información
(TAFIM))
12. Computer Integrated Manufacturing arquitectura abierta del sistema
(CIMOSA))
13. Purdue Arquitectura Empresarial Referencia (PERA))
14. Estándares y Arquitectura para aplicaciones de administración
electrónica (SAGA))
15. Unión Europea-IDABC y Marco Europeo de Interoperabilidad)
16. ISO / IEC 14252 (norma IEEE 1003.0))
17. IEEE Std 1471-2000 IEEE Práctica Recomendada para Descripción
Servicios de arquitectura

23. ORIENTACION A SERVICIOS…
Todos los modelos hacen “foco” en la noción de servicio
/ o sea Arquitecturas orientadas. La idea es agrupar
las funciones, en módulos de servicios reutilizables que
pueden ser descritos como objetos; permitiendo mas
capacidades para lo complejo, construye a partir de
el montaje correcto de estos módulos básicos.
La visión de servicio es generalmente mas visible en las
lógica o sea las "capas superiores“ (de procesos,
aplicaciones y datos). En las capas inferiores,
infraestructura física de activos tecnológicos
(servidores, redes, storage, ), la adecuación obliga
replanteos y/o innovaciones fuertes(virtualizacion,
comunicaciones unificadas, clusterizacion, grid
computing, movilidad, etc.)

24. EVOLUCION …
 Los modelos de arquitectura empresarial tienen su
génesis en el modelo cliente-servidor desarrollado a
finales de 1980 y principios de 1990.
 Se han adecuado a el paradigma internet, donde ;
 el cliente puede ser un dispositivo de acceso basado
en el navegador,
 el servidor puede ser un servidor Web y
 el protocolo de intercambio podría ser el Protocolo
de transferencia de hipertexto (HTTP), o ambas
entidades podría ser un servidor que ejecute algún
servicio service-providing/service-requesting Web (WS)
y el protocolo de intercambio Simple Object Access
Protocol (SOAP).

25. LA INNOVACION TI Y LA APLICABILIDAD REAL
Se requiere una visión más pragmática que académico
de todos estos modelos, de lo contrario, se podría
llegar a gastar una cantidad excesiva de tiempo
durante varios años desarrollando un modelo de
marco (por ejemplo, con los principios, estrategias,
decisiones, directrices, normas, alternativas,
justificaciones, etc.) y tienen poco concreto para
mostrar (algunas empresas han gastado en el rango
de 100 personas-años para desarrollar un modelo de
este tipo, con relativamente poco que mostrar en el
extremo). Se requiere la articulación de diferentes
estándares y normativas de las capas mas bajas .

26. OBSERVACIONES ; niveles de servicios y
refinamientos
El intento ultra riguroso para modelar en una
empresa toda función (negocio / informática) con
cualquiera de los modelos disponibles pueden ser
un esfuerzo muy tedioso y puede llegar a ser un
punto discutible cuando cambia el entorno de
negocios cada dieciocho meses o incluso cada seis
meses.
Debido al esfuerzo que implica la aplicación rigurosa
de los lenguajes de modelado, una organización
de arquitectura empresarial puede invertir grandes
cantidades de tiempo en la realización de un
ejercicio fuera de la fecha de los resultados en el
momento en que se complete.

27. Observaciones;
rigurosidad contextual.
Estamos de acuerdo en que el desarrollo de
software a gran escala con los requisitos estrictos y
bien establecidas, para proyectos de fallas criticas
(aviación, planta de energía nuclear, un sistema
militar, o una plataforma de exploración espacial)
exige ae alto rigor, pero en sistemas empresariales
( seguimiento de pedidos, sistema de inventario,
registros de clientes, etc.) pueden y deben
realizarse de formas economicas que no afecten
la sostenibilidad de las soluciones propuestas.

28. Recomendaciones
Los requisitos suelen cambiar incluso durante un
corto período de tiempo (pueden ser necesarios
en el plazo de seis meses,), y así un esfuerzo ultra
riguroso documentación de los requisitos puede
no valer la pena.
Además, los mecanismos de control de cambios
pueden ser difíciles de aplicar sobre las
variaciones frecuentes en un corto período de
tiempo.
No estamos sugiriendo que no fuera a través del
esfuerzo de modelado; estamos recomendando
no gastar cientos de personas-año para
desarrollar un marco parcial para la arquitectura
empresarial.

29. Una empresa puede haber desarrollado una
completa gama de arquitecturas para las distintas
capas del marco o sólo puede tener una
arquitectura parcialmente desarrollado, como se
ilustra en la Figura 2.
Figura 3 ilustra gráficamente la motivación por tener
una arquitectura empresarial: la parte superior
muestra una aplicación bastante sencilla en una
empresa, donde la arquitectura puede ser opcional,
pero debido a que con el tiempo el sistema y las
interrelaciones pueden crecer en complejidad, por
lo que se recomienda arquitectura del modelo, la
parte inferior de la figura muestra un entorno de
aplicación-de plena madurez en que un diseño de
arquitectura es indispensable.

30. Empresas de Fortune 500 pueden tener varias decenas
(si no cientos) de aplicaciones con este tipo de
complejidad, tratando de posicionarse
estratégicamente en el medio ambiente y sin un plan
de arquitectura de la empresa es completamente
inútil. En esta coyuntura, no son sólo las grandes
organizaciones que han adoptado la arquitectura
empresarial: las organizaciones más pequeñas
también están adoptando este enfoque (sin
embargo, la madurez arquitectura es a un nivel
mayor en las empresas grandes que en las pequeñas
empresas). Cada organización que busca gestionar
su complejidad TI de una manera costo-efectiva para
el despliegue rápido del sistema debe considerar la
posibilidad de las inversiones apropiadas en la
arquitectura empresarial. ( Fig. 4)

31. Figura 2. MADUREZ de desarrollo de arquitectura empresarial en una empresa.

32. Figura 3. Necesidad de la arquitectura de la empresa como el entorno se vuelve más complejo.

33. Figura 4. Algunos acontecimientos básicos que desencadenan un refresco de
una arquitectura empresarial

34. OBSERVACION
La arquitectura empresarial debe ser vista (desarrollo y su
aplicación) y se debe consensuar internamente, como
un producto entregable, algo que puede ser "tocada y
usada" no sólo una conceptualización abstracta.
 En el contexto de TI, una arquitectura necesita ser
percibida (vista) por los usuarios y grupos de interés, casi
como otra aplicación del sistema de TI: debe tener las
entradas, salidas, la funcionalidad, los datos
incorporados, etc.
 Una simple conceptualización es difícil de ser vista como
agregando valor. Si uno ha de considerar la arquitectura
de la empresa como un conjunto de "directrices modelo
sobre cómo construir cosas, que muestra en particular la
relación de una entidad con otra", entonces la
arquitectura debe ser percibido por el usuario
corporativo / desarrollador , como cualquier otro
artefacto estándar de la industria (salvo que esto se
aplica internamente a una empresa en lugar de toda la
industria.)

35. Las norma son de hecho un producto esencial:
uno puede comprar un estándar de la UIT-T,), para
desarrollar productos globalmente homologados
Uno puede comprar un estándar del IEEE que es la
declaración definitiva, por ejemplo, de
WiMax/802.16, puede utilizar para desarrollar
productos globalmente conformes.
la descripción de la arquitectura de la empresa, así
podría tener el look-and-feel de una norma ISO, la
UIT-T, IEEE, ANSI, o documento IETF con /
capacidades opcionales obligatorios,
Si tales ISO, IEEE, ANSI, son lo suficientemente buenos
para estandarizar los productos a través de una
industria, o la mayoría de las industrias, o incluso en
todo el mundo , ¿por qué estos mecanismo no son lo
suficientemente bueno para estandarizar los
productos dentro de una empresa?

36. Por qué se tienen que reinventar, tal vez durante
varias iteraciones, el conjunto de artefactos
apoyando arquitectura-?
Esto es lo que queríamos decir antes cuando dijimos,
no es suficiente la adquisición/disposicion de TI:
es porque a menudo las empresas piensan que son
tan diferentes entre sí que tienen que reinventar la
forma en que llevan a cabo una función común,
en lugar de utilizar un enfoque estandarizado, que
se representa en la Figura 5.

37. Figura 5. Modelo de arquitectura de la empresa, que también muestra la
arquitectura artefactos.

38. TRABAJO PRACTICO
 EXPOSICION DEL ANALISIS REALIZADO
POR PARTE DE LOS CURSANTES.
 INTERCAMBIO DE PUNTOS DE VISTAS.
 CONCLUSIONES.

39. A continuación, se define un modelo simple de
arquitectura de la empresa que hemos utilizado en
los últimos años, que se representa en la Figura 5.
Esta descomposición de la empresa es el modelo de
TOGAF y es como sigue:
Función comercial: Esta es una descripción de todos
los elementos de negocio y estructuras que están
cubiertos por la empresa.
Arquitectura empresarial: Una formulación
arquitectónica de la Función comercial.
(Los temas de BPM se tratan en otra materia).

40. Función de Información:
Se trata de una identificación exhaustiva de los
datos, los flujos de datos y las interrelaciones de
datos necesarios para apoyar la función de
negocios. La identificación, sistematización,
clasificación e inventario / almacenamiento de
información son siempre necesarios para dirigir un
negocio, pero son esenciales si las funciones de
manejo de datos han de ser automatizado.
Arquitectura de la Información:
Una formulación arquitectónica de la función de
información a través de un modelo de datos.

41. (Sistemas / Aplicación) Función Solución:
Esta es la función que tiene como finalidad dar /
suministro de sistemas informáticos
computarizados necesarios para soportar la gran
cantidad de funciones específicas necesarias
para el funcionamiento de negocios.
(Sistemas / Aplicación) Arquitectura de la solución:
Una definición arquitectónica de la (Sistemas /
Aplicación) Función de so

42. Función de Infraestructura Tecnológica:
El entorno de la tecnología completa requerida
para apoyar la función de la Información y la
(Sistemas / Aplicación) Función de soluciones.
Tecnología Arquitectura Infraestructura:
Una formulación arquitectónica (descripción) de la
función de Infraestructura Tecnológica.

43. Estos sub-capas de la arquitectura están claramente
relacionados entre sí a través de las relaciones
bien definidos, la integración de estos sub-capas
es una necesidad para un diseño de arquitectura
empresarial coherente y eficaz.
Estas capas son jerárquicas sólo en el sentido débil,
por lo que también pueden ser vistos como
dominios de TI / redes de seguridad también es
importante, y las empresas necesitan tener bien
desarrollados, arquitecturas integrales de
seguridad en su lugar (en lugar de capas per se.);
este tema, será tratado en otra materia en
extenso.

44. Figura 6 divide el espacio de TI desde una perspectiva
arquitectónica en recursos lógicos, los recursos físicos y
los recursos de gestión. Los recursos físicos en la capa de
la tecnología proporcionan el medio ambiente y los
servicios para la ejecución de las aplicaciones, estos
recursos abarcan plataformas (procesadores de
mainframe y de gama media), junto con el hardware y
el sistema operativo (OS) clasificaciones;
-almacenamiento;
- escritorios y redes (ocho subcomponentes).
- Las operaciones y capa de gestión es una combinación
de procesos y herramientas necesarias para apoyar a
todo el entorno de TI. Cubre la detección de fallas y
apagones, configuración, job accounting, el
rendimiento y la seguridad.

45. Figura 6. Un modelo en capas de la arquitectura de la empresa.

46. Como se mencionó anteriormente, hay muchos modelos
que se pueden utilizar.
El modelo de la figura 5 se inspira en el modelo de
referencia del procesamiento distribuido abiertoen
entornos heterogéneos. (ISO-RM-ODP) (Rec. UIT-T.
X.901-(alias) ISO / IEC 10746-1 a través de la UIT-T Rec..
X. 904 (aka) ISO / IEC 10746-4),
RM-ODP utiliza un enfoque de modelado de objetos
para describir los sistemas distribuidos.
Dos enfoques de estructuración se utilizan para simplificar
los problemas de diseño de grandes sistemas
complejos:
(1) los "puntos de vista" proporcionan una manera de
describir el sistema, y ​​
(2) (2) las "transparencias" identificar problemas
específicos únicos para los sistemas distribuidos. Cada
punto de vista está asociado con un lenguaje que
puede utilizarse para describir sistemas de ese punto
de vista.

47. Los cinco puntos de vista en RM-ODP son los siguientes:
El punto de vista de la empresa, que examina el sistema y su
entorno en el contexto de los requerimientos del negocio
en el sistema, su propósito, el alcance y las políticas. Se
ocupa de los aspectos de la empresa, tales como su
estructura organizativa, que afectan el sistema.
El punto de vista de la información, que se centra en la
información en el sistema. ¿Cómo está estructurada la
información, cómo se transforma, los flujos de información,
y las divisiones lógicas entre funciones independientes
dentro del sistema se tratan de manera en el punto de
vista de la información.
El punto de vista aplicativo, que se centra en la
descomposición funcional del sistema en objetos que
interactúan en interfaces. El punto de vista de
ingeniería, que se centra en cómo se apoya la
interacción distribuida entre los objetos del sistema.
El punto de vista de la tecnología, que se concentra en los
componentes individuales de hardware y software que
componen el sistema.

48.  Ejercicio 1
discutir este modelo, sobre el marco implícito de la
Figura 5 y la Figura 6.
La figura 7 muestra cómo los componentes clave de
un entorno compatible con la arquitectura se
relacionan entre sí.

49. Figura 7. Los componentes clave de un entorno compatible con la arquitectura.

50. figura 8 ilustra ACTIVIDADES proceso de desarrollo y/o
mantenimiento de la arquitectura de la empresa.
Entre otras observaciones, los siguientes son pertinentes.
Arquitectura empresarial debe ser algo más que imágenes
bonitas. A menudo, se ve un montón de figuras
elaboradas, gráficos y presentaciones, pero a menos que
los conceptos se traducen en decisiones reales, las
migraciones y la gobernabilidad, tales gráficos intrigantes
no darán lugar a ningún avances y mejorías concretas
Arquitectura empresarial debe ayudar a las empresas no
solo a gestionar los costos de TI, sino abarcar las
decisiones dónde realizar nuevas inversiones de TI, es
decir, cuando a "conservar", "retirarse", o "reconstruir" las
aplicaciones o la infraestructura.
Además, el marco de la arquitectura (sólo) en sí no ahorrar
dinero intrínsecamente: todo el seguimiento de los
artefactos debe ser desarrollado, y, a continuación, a su
vez aplicado al medio ambiente, es decir, ejecutado a
través de esfuerzos financiados .

51. Figura 8. Algunas actividades según el estado de la arquitectura
empresarial.

52. Resumen
Las necesidades de satisfacer los requerimiento de los
Negocios/empresas actualmente, conllevan a
replanteos continuos y mejoras de sus sistemas de
información, en función de la dinámica de cambios
de su complejo entorno (factores externos/internos).
Esta realidad adolece de metodologías que
responder en oportunidad y de manera coordinada,
articular acciones para adecuar
estrategias/operaciones. Arquitectura Empresarial, se
presenta como una nueva practica, cuya visión es
integral y de mejora continua. Asegura la estructura
de información de la empresa actualizada (Capital
Intelectual). Identificando sistemáticamente,
impactos de innovaciones /cambios, generando
escenarios de solución basados en toma de
decisiones consensuadas.

53. NOTA
El OSIRM es un conjunto de normas internacionalmente aceptadas que definen un
modelo de protocolo que comprende siete capas jerárquicamente
dependientes. Es la base del trabajo de desarrollo del protocolo por los distintos
organismos de normalización. Una Organización Internacional conjunta de
Normalización (ISO) / Unión Internacional de Telecomunicaciones (UIT) estándar
para un niño de siete capas, estructura de comunicación de arquitectura para la
interconexión de los ordenadores en las redes. Normas basadas en OSIRM incluyen
protocolos de comunicación que son en su mayoría (pero no totalmente)
compatible con el de protocolos de Internet, pero también incluyen modelos de
seguridad, como X.509, que se utilizan en Internet. Las capas OSIRM, de mayor a
menor, son: (7) Aplicación, (6) Presentación, (5) de sesiones, (4) Transporte (3) Red,
(2) de enlace de datos, y (1) Física. El modelo, desarrollado originalmente en la
década de 1980, se define en los siguientes cuatro documentos: (1) ISO / IEC 7498-
1:1994: Tecnología de la información-Interconexión de sistemas abiertos-Modelo de
referencia básico: El modelo básico, (2) ISO 7498 - 2:1989: Procesamiento de
información sistemas de interconexión de sistemas abiertos-Basic Modelo de
Referencia-Parte 2: Arquitectura de seguridad. (3) ISO / IEC 7498-3:1997: tecnología
abierta Information Systems Interconnection- Modelo de referencia básico:
Denominación y direccionamiento. (4) ISO / IEC 7498-4:1989: Procesamiento de
información sistemas de interconexión de sistemas abiertos-Basic Modelo de
Referencia-Parte 4: Marco de gestión.
 2. Interconexión de Sistemas Abiertos (Redes) estándares son definidos por ISO para
apoyar la arquitectura OSIRM.
 3. Empleamos el término GSOA para describir el concepto general de modelado
orientado al servicio de la arquitectura empresarial. Usamos el término SOA para
referirse específicamente a los productos disponibles en el mercado para
implementar un paradigma GSOA, como se discute más adelante en el libro.