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.