passarello espedito clase 2 _minoli_que_es_una_arq_empre_08_abril
TRANSCRIPT
MAESTRIA Y ESPECIALIZACION
GESTION ESTRATEGICA DE SISTEMAS Y
TECNOLOGIAS DE LA INFORMACION.
El CIO como ejecutivo de Negocios.
PROFESOR: Mg Espedito Passarello
2014
ASIGNATURA: INFRAESTRUCTURA
Y ARQUITECTURA TECNOLÓGICA
CLASE 2
¿Que es una Arquitectura
Empresarial?
Dante Minoli.
Material entregado para
lectura previa y exposición en
clase.
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
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.
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.
¿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) .
¿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.
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)
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.
Figura 1. Macro de vista del medio ambiente y de la arquitectura empresarial.
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.)
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.
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.
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.
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.
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.
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.
¿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.
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.)
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
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.)
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).
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 .
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.
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.
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.
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.
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)
Figura 2. MADUREZ de desarrollo de arquitectura empresarial en una empresa.
Figura 3. Necesidad de la arquitectura de la empresa como el entorno se vuelve más complejo.
Figura 4. Algunos acontecimientos básicos que desencadenan un refresco de
una arquitectura empresarial
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.)
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?
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.
Figura 5. Modelo de arquitectura de la empresa, que también muestra la
arquitectura artefactos.
TRABAJO PRACTICO
EXPOSICION DEL ANALISIS REALIZADO
POR PARTE DE LOS CURSANTES.
INTERCAMBIO DE PUNTOS DE VISTAS.
CONCLUSIONES.
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).
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.
(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
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.
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.
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.
Figura 6. Un modelo en capas de la arquitectura de la empresa.
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.
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.
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í.
Figura 7. Los componentes clave de un entorno compatible con la arquitectura.
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 .
Figura 8. Algunas actividades según el estado de la arquitectura empresarial.
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.
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.