ARQUITECTURA EMPRESARIAL

1. Arquitectura empresarial

1.1. ¿Qué es la arquitectura empresarial?

https://www.youtube.com/watch?v=ctls1-g1IzE

- "La Arquitectura Empresarial es una

metodología que, basada en una visión
integral de las organizaciones – o en
este caso, de todo el Estado –, permite
alinear procesos, datos, aplicaciones e
infraestructura tecnológica con los
objetivos estratégicos del negocio o
con la razón de ser de las entidades.
Cuyo principal objetivo es garantizar
la correcta alineación de la tecnología
y los procesos de negocio en una
organización, con el propósito de
alcanzar el cumplimiento de sus objetivos estratégicos" (2)

- La arquitectura empresarial en una organización corresponde a la forma de

representar de manera integral la empresa, permitiendo cubrir y considerar
todos y cada uno de los elementos que la conforman. Esto conduce a que se
pueda establecer una visión clara sobre los objetivos, las metas y líneas de
negocio en la empresa, comenzando desde la perspectiva estratégica (misión,
visión, lineamientos e indicadores estratégicos), hasta llegar a una estructura
actual y futura para los procesos de la organización; la cual incorpora algunos
de los componentes que se consideran como críticos para su funcionamiento:
 Los procesos: modelos de negocio y procesos.
 La estructura organizacional: personas, estructuras administrativas.
 Las tecnologías de información: aplicaciones, información, infraestructura
tecnológica y seguridad informática.

- Como resultado final, se va a disponer de las herramientas y los mecanismos

necesarios para la adecuada operación y funcionamiento de la empresa, y por
ende, apoyar el cumplimiento de sus objetivos estratégicos.

1.2. Características de la arquitectura empresarial:

ESCABILIDAD: si aumenta la carga del sistema se adapta

-
MANTENIBILIDAD: permite modificar los componentes existentes sin
-
modificar el comportamiento del sistema
- DISPONIBILIDAD: soporte de arquitecturas tolerantes a fallos, sistemas de
redundancia.
- EXTENSIBILIDAD: ha de ser posible añadir nuevos componentes
- Manejabilidad y Seguridad
1.3. Componentes de la Arquitectura empresarial:
 - El secreto de la AE radica en la alineación de los distintos componentes
informáticos de una organización, todos en función de una visión estratégica
que les dé sentido y, a la vez, que los convierta en recursos útiles para la toma
de decisiones, más allá del conjunto de recursos para realizar tareas en que
pueden convertirse sin una integración desde la Arquitectura.

- "En general, dentro de la Arquitectura Empresarial se identifican seis

componentes: estrategia, gobierno de TI, información, sistemas de
información, servicios de tecnología, uso y apropiación".(3)

Fuente: Arquitectura Empresarial (Articulo Colombia Digital) (4)

1.4. Metodologías de la Arquitectura empresarial:(4)

a. Marco de trabajo de Zachman:

- El Marco Zachman se considera como una taxonomía para organizar

documentos de diseño, especificaciones y modelos; que tiene en cuenta
tanto a quién se dirige el producto, como el tema concreto del que se
hablará en el documento o modelo. Esto quiere decir, según Zachman,
que es una estructura lógica para clasificar y organizar las
representaciones descriptivas de una organización que son significativas
para la gestión de la misma, así como para el desarrollo de los sistemas.
- Fue el primer modelo de arquitectura empresarial (1987), no propone
un método para obtener cada uno de sus elementos
b. Marco federal de arquitectura empresarial:
- Es uno de los intentos del gobierno federal para unir sus agencias y
funciones bajo una única arquitectura empresarial. FEA es
considerada por muchas organizaciones como una de las
metodologías más completas; pues tiene una taxonomía completa,
como la de Zachman, y un proceso arquitectónico, como TOGAF.
Actualmente la FEA puede ser vista como una metodología para crear
una Arquitectura Empresarial o como el resultado de aplicar ese
proceso a una organización en particular, como por ejemplo, el
Gobierno de los Estados Unidos.

Fuente: Enfoque sistemático para el desarrollo de SI integrados

c. Método Gartner:

- Conocido como “cuadrante mágico”, busca integrar, analizar y

comunicar información estructurada y no estructurada.
- Gartner considera que la Arquitectura Empresarial trata de reunir
tres componentes: dueños de negocios, especialistas en información
e implementadores de tecnología. Si una organización logra unir estos
tres grupos y unirlos detrás de una visión común que impulsa el valor
del negocio, eso se traduce en éxito. La arquitectura empresarial,
dentro de la visión de Gartner, se trata de la estrategia, no de la
ingeniería. Las dos cosas que son más importantes para Gartner son
hacia dónde va una organización y cómo llegará allí.

Fuente: AEA(5)

d. TOGAF ( The Open Architecture Framework):

- Creado por “The Open Group”, desarrolla procesos de AE en 8 fases

sistemáticas y entrega manuales de implementación que hace que la
organización siga.
- Es la metodología estándar utilizada por las principales
organizaciones del mundo (públicas y privadas), para abordar de
manera efectiva las necesidades críticas de los negocios u objetivos
misionales. Así mismo divide a el AE en cuatro categorías :
 Arquitectura de Negocio
 Arquitectura de Datos
 Arquitectura de Aplicación
 Arquitectura Tecnológica
 Caso de éxito TOGAF: https://colombiadigital.net/actualidad/articulos-
informativos/item/8202-sena-mejores-servicios-al-ciudadano-gracias-a-una-
mejor-administracion-de-la-tecnologia.html
2. Arquitectura de los sistemas de información:
https://argus-acia.com/white_papers/evaluating_ia.pdf

- La arquitectura de la información trata, en realidad, sobre lo que no es obvio. Los

usuarios no perciben la arquitectura de la información de un sitio a menos que no
funcione. Cuando notan las características de una buena arquitectura en algún sitio,
las atribuyen a algo más... No obstante, ningún término describe en forma adecuada
las relaciones que hay entre los elementos intangibles que constituyen la
arquitectura del sitio. Estos elementos –sistemas de navegación, rotulado,
organización, indexación, búsqueda y metáforas – son el adhesivo que une todo el
sitio y le permite evolucionar con naturalidad.(6)
- Un sistema de información es un conjunto organizado que integra datos, actividades
y recursos para registrar datos y generar una nueva información.
- La Arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los
algoritmos y estructuras de datos de la computación; el diseño y especificación de la
estructura global del sistema es un nuevo tipo de problema.
 Fuente: arquitectura de sistemas de la información (7)
A. Beneficios de la Arquitectura de la información:
- La Arquitectura de la Información brinda ciertos beneficios que la institución
debe tomar en cuenta, pues en algunos casos representan pérdidas y ganancias
millonarias.
- Un ejemplo interesante es el caso Boo.com. La tienda deportiva Boo trató de
lanzar un sitio Web, utilizando la tecnología de punta, con imágenes en tres
dimensiones y tienda electrónica, el cual era visualmente espectacular. Nadie
podía competir con el impresionante diseño gráfico que demandó muchas
horas de trabajo. Pero a pesar de las ingentes cantidades de dinero invertido
en su implementación y las crecientes campañas de publicidad que crearon
expectativas, el sitio Web fracasó estrepitosamente.
- ¿Qué estaba mal sino se había escatimado en gastos?; las razones fueron muy
sencillas. “La mayoría de los actuales sitios web comerciales están diseñados
para impactar al navegante, mostrar las habilidades del diseñador o hacer una
pobre publicidad de las empresas promotoras. Los resultados habituales son
lentitud en la descarga de imágenes, desorganización de la información,
distracciones centellantes y coloristas, diseños efectistas, ilegibilidad de los
textos y navegación al zar, sin dirección a lo que se busca el usuario.(8)

B. Componentes de la arquitectura de la información:

- La Arquitectura de la Información se puede separar en cuatro componentes:

I. Organización: Existen diferentes esquemas de organización, en las cuales

se puede dividir en exactas o subjetivas y ambiguas. La organización exacta
se refiere a aquellas que tienen una sola interpretación, como pueden ser
las que se organizan en forma alfabética (diccionarios, directorios y
listados ordenados), cronológicas (revistas, periódicos, publicaciones),
geográficas (agencias y sucursales, portales organizados geográficamente).
Mientras la organización subjetiva se basa en diversos criterios, como son
las temáticas (portales horizontales, tiendas organizadas por rubros),
funcionales (intranets corporativas), audiencia específica y la metafórica.
II. Navegación: El sistema de navegación es uno de los temas más importantes
en la accesibilidad y usabilidad del sitio Web. Proveer opciones para ir de
un lado a otro, poder regresar a la página anterior o ir hacia otras secciones
con el menor esfuerzo, puede brindar al usuario cierta placentera
comodidad. Existe barra de navegación horizontal, vertical, desplegable,
permanentes.

La navegación se puede clasificar en globales (acceso a las secciones

principales), locales (acceso a las secciones internas) y ad hoc (acceso a
secciones relacionadas). Se recomienda presentar información que permita
conocer la ubicación exacta del navegante, como opciones de subir o bajar
cuando existen textos grandes. En la navegación externa, se puede apoyar
la navegación utilizando tablas de contenido, índices, mapas del sitio o
visitas guiadas.

III. Rotulado: La rotulación es una forma de representación de la

información, que describe el contenido de una página Web. Los sistemas de
rotulación pueden ser como enlace, encabezados, como iconos, y además
cumple una función fundamental en la indización de documentos.

IV. Sistema de Búsqueda: En algunos sitios Web la posibilidad de

explorar el contenido puede ser un pasatiempo placentero, sin embargo,
cuando un sitio Web cuenta con más de 50,000 páginas puede convertirse
en una pesadilla. Los sistemas de búsqueda permiten encontrar
rápidamente la información, y algunas interfaces permiten realizar
opciones de filtrado por secciones o por tipo de documento.

En el caso de contenidos dinámicos, es necesario implementar un buscador

interno, más aún cuando los robots y arácnidos de indización, no pueden
clasificar la información en los grandes motores de búsqueda.
3. Arquitectura de las tecnologías de la información;

- "La Arquitectura de Tecnologías de Información es la disciplina que se ocupa de

realizar sedes web en la World Wide Web y determinar la infraestructura
tecnológica, delimitando el conjunto de conocimientos, máximas, principios y
técnicas que rigen o deberían regir la práctica de los que desarrollan y gestionan sus
contenidos"i

4. Arquitectura y software orientado a servicios:

https://www.youtube.com/watch?v=o_Br2vZ4uQY

4.1. ¿Qué es el SOA?(9)

- SOA (Arquitectura orientada a servicios) es un marco de trabajo conceptual que

establece una estructura de diseño para la integración de aplicaciones, que permite
a las organizaciones unir los objetivos de negocio, en cuanto a flexibilidad de
integración con sistemas legados y alineación directa a los procesos de negocio,
con la infraestructura de TI.
- Esto permite la reducción de costos de implementación, innovación de servicios a
clientes, adaptación ágil ante cambios y reacción temprana ante la competitividad,
ya que, combinan fácilmente las nuevas tecnologías con aplicaciones
independientes, permitiendo que los componentes del proceso se integren y
coordinen de manera efectiva y rápida.

4.2. Características del SOA(11)

 Los servicios deben estar definidos a través de protocolos y lenguajes
estándar de forma que su uso sea independiente de la plataforma.
 Los servicios deben estar accesibles y publicados en un repositorio de
servicios con el objetivo de poder monitorizar el estado de los mismos.
 Los servicios definidos deben cumplir el requisito de reutilización. Se debe
fomentar el uso de estándares para reutilizar servicios ya existentes con
el objetivo de aumentar las posibilidades de integración con sistemas
legados.
 Los servicios encapsulan los detalles de implementación y exponen sus
funcionalidades a través de una interfaz basada en estándares.
 Un servicio debe ser independiente y no debe depender del estado de otro
servicio y por tanto su relación con el resto de los servicios es débilmente
acoplada.

4.3. Historia del SOA:

- El termino SOA fue utilizado por primera vez por Gartner en 1996. Hacia foco en
la interaccion entre modulos (consumidor y proveedor) usando comunicación
request/ response.
- En 2003 logra ingresar al mercado por medio de los web services:
 Estandarización
 Flexibilidad
 Firewall friendly
4.4. Beneficios del SOA:(10)

 SOA facilita la integración de los diferentes ambientes encontrados en

muchas organizaciones. SOA facilita la colaboración, y compartición de
información, en toda la organización y con socios externos. Al exponer los
procesos de negocios, SOA ayuda a los negocios a enfocarse en las mejores
formas de mejorar las operaciones. SOA provee la habilidad de apoyar un
modelo de negocios que cruce las líneas de la organización. SOA realza la
colaboración, facilita los procesos de negocio de punta-a-punta y mejora
la efectividad operativa.

 SOA le permite personalizar sus procesos de negocios sin modificar su

código fuente. Con SOA, hacer que los procesos en sus sistemas
compaginen con su negocio es sólo una cuestión de configuración, no
personalización. Esto significa que cuando sea tiempo de actualizar a la
siguiente versión, usted lo puede hacer mucho más fácilmente que si tiene
personalizaciones diseminadas en toda su implementación.

 Un beneficio adicional del SOA es que, provee la habilidad de modernizar

los procesos de negocios, que a su vez promueve una administración de
procesos de negocios ágil. SOA provee una forma de hacer que los
procesos de negocios sean más visibles, de forma que puedan ser
personalizados y optimizados para cubrir mejor las crecientes exigencias
de los clientes sobre tiempos de respuesta reducidos, mientras se
mantiene alta calidad y rentabilidad. Posiblemente más importante, SOA
mantiene a distancia la complejidad de la integración entre aplicación-a-
aplicación y negocio-a-negocio, reduciendo costos significativamente y
elevando la tecnología a un nivel de negocios.

4.5. Diseño de aplicaciones SOA:

A. IMPLEMENTACION DEL SOA EN ESSALUD: 13

 B. DISEÑO DE APLICACIONES SOA UTILIZANDO VISUAL STUDIO TEAM
SYSTEM(14)

4.6. ¿Qué son las aplicaciones SaaS?(12)

- El concepto de SaaS suele asociarse con los proveedores de servicios de
aplicación (ASPs) de los años 90, que ofrecían aplicaciones “empaquetadas” a los
usuarios corporativos a través de Internet. Estos primeros intentos de poner en
marcha soluciones de Software a través de Internet tenían más en común con las
aplicaciones corporativas tradicionales (las que se instalan y utilizan dentro de la
red interna de las empresas) que con las actuales aplicaciones SaaS en muchos
aspectos, tales como el modelo de licencia y la arquitectura. Puesto que esas
aplicaciones se crearon en principio como aplicaciones para un solo destinatario,
su capacidad para compartir datos y procesos con otras aplicaciones estaba muy
limitada y tendían a ser escasamente atractivas en comparación con sus
equivalentes de instalación en local.

4.7. Historia de las aplicaciones SaaS(15)

- Inicia en los años sesenta con IBM y su modelo 67 IBM 360, al ser increíblemente
costoso tener una computadora profesional se podría rentar el poder y espacio a
un externo, este servicio se conocía como tiempo compartido.
- Para los años setenta en Estados Unidos el tener una computadora personal
incrementó en popularidad y se volvió económicamente viable tener
computadores en las oficinas de trabajo comunes, aquí el SaaS tomó una pausa
del mercado.
- Pero en los años ochenta, se creó el primer CRM (Customer relationship
management) el cual permitía información de clientes quedar almacenado en una
zona común disponible para todos en la empresa y así tener mejores ventas.

- En los años noventa empezó a desarrollarse más rápido los software de lo que los
hardwares podían apoyarlo, por lo que algunas empresas tuvieron que regresar
al método original: el tener todo almacenado junto en una computadora de
alguien externo. En esta época se establecieron compañías que actualmente son
exitosas y conocidas por haber vendido softwares con disquetes y licencias de
 uso, pero los costos se iban acumulado al sumarle mantenimiento y soporte
técnico.
- Al principio del milenio se fueron estableciendo varias compañías de SaaS para
ventas, lo suficiente para que creara un boom que llevó a SaaS hasta el año 2010
en adelante. Una vez establecida la posibilidad de tener un sistema independiente
del lugar de uso y sin necesidad de tener 10 disquetes para utilizarlo se dio paso
al sistema en la nube.
- La IDC (International Data Corporation) estimó en el 2014 que la industria del
SaaS iba a valer para el 2018 $50.8 mil millones de dólares, en el 2017 el mercado
de SaaS cerró con alrededor de $105 mil millones de dólares.
- Hoy en día se pueden encontrar 12,000 SaaS start-ups registradas oficialmente,
pero el número real es desconocido. A futuro es muy posible que el SaaS se divida
en subcategorias para su mejor aprovechamiento pero hoy ahora el mercado sólo
seguirá creciendo

Fuente: la historia del software como servicio (15)

4.8. Impacto sobre el desarrollo de software:

- Actualmente los proveedores de SaaS no han establecido las mejores prácticas

para desarrollar este tipo de aplicaciones ni tampoco estándares en la industria.
Las metodologías tradicionales son suficientes para desarrollar modelos SaaS
muy simples, pero cuando se trata de especializar y escalar hacia un negocio
más avanzado, aún se carece de técnicas bien establecidas.
- Por el lado de ingeniería de software, las aplicaciones SaaS presentan
diferencias en cuanto a su ingeniería de requerimientos con las aplicaciones
empaquetadas (por ejemplo, desde la perspectiva del cliente, la instalación y
mantenimiento son diferentes).
- Pioneros del modelo SaaS argumentan que se requiere un enfoque alterado de
ingeniería de software para este tipo de aplicaciones. Una pregunta importante
 es cómo el enfoque SaaS afecta a los proveedores de software y su incentivo a
invertir en el desarrollo de productos.
- Transformar un producto empaquetado a un modelo SaaS no es una simple
cuestión de reescribir código. Estas compañías necesitan examinar sus modelos
de ingeniería y mercadeo para adaptarse a este nuevo enfoque de negocio y de
desarrollo.

Fuente: CICLOS DE VIDA EN APLICACIONES SaaS

4.9. Diseño de las aplicaciones SaaS:

Fuente :desarrollo de aplicaciones en plataformas Sofware as Service(16)

a. Requerimientos:

- En el enfoque tradicional, los requerimientos consisten en definir una serie

de funciones que satisfagan las necesidades de un cliente. En el caso de las
aplicaciones SaaS, los desarrollos son meramente basados en un modelo de
negocio. Eso es, una aplicación SaaS debe cumplir con los requerimientos
de un mercado meta. Debido a que las aplicaciones serán consumidas por
un gran número de subscriptores (empresas clientes) y cada uno puede
tener potencialmente un número grande de usuarios, entonces más
requerimientos no funcionales son introducidos al proceso, como por
ejemplo: soporte para alta concurrencia, almacenamiento escalable,
virtualización/ clustering entre otros. Las actividades propuestas son:

 Definición de un plan de requerimientos de negocio. Deben ser

identificadas las características del plan de negocio (del proveedor)
para ser transformadas a requerimientos funcionales.
 Análisis del mercado meta. Catalogar y puntualizar las necesidades
principales del mercado meta. Se deben evaluar las necesidades del
mercado y definir características de alto valor para los clientes
potenciales. En esta actividad se van identificando los requerimientos
no-funcionales que se mencionaron anteriormente.
 Definición de las funcionalidades. Puntualizar las características
principales como funciones de cada aplicación que será entregada como
servicio. Estas funcionalidades deben ser completamente alineadas al
mercado y no a los requerimientos de un solo proveedor.

b. Análisis:

- La etapa de análisis debe ser realizada también desde la perspectiva de

negocio. Esto es debido a que cada aplicación tratará de satisfacer las
necesidades de un amplio número de clientes. La definición de los
procesos de negocio que soportará cada aplicación es un paso
importante en este tipo de aplicaciones, ya que debe permitir la
personalización y definición de procesos similares para cada cliente.
- Análisis de procesos de negocio, En esta actividad se deben analizar los
procesos de negocio que serán automatizados con la aplicación. Por
ejemplo, si se desarrolla un CRM, se deben analizar los procesos de
venta y su integración con otros procesos como cadenas de suministro,
por ejemplo. Cada proceso con sus actividades, roles y reglas de
ejecución debiera ser documentado.
- Desarrollar casos de uso. Tarea formal en metodologías existentes, que
debiera hacerse para documentar y modelar las funcionalidades de la
aplicación. Artefactos tradicionales son casos de uso descriptivos y sus
diagramas.

c. Diseño:

- La fase de diseño consiste en desarrollar documentación que soporte la etapa

de construcción.
 - Investigación de tecnologías. Es importante en esta etapa hacer
investigación sobre las tecnologías que soporten las necesidades
identificadas. Un artefacto entregable puede ser un documento de
investigación acerca de plataformas SaaS, proveedores existentes,
frameworks, componentes Web 2.0, etc.
- Evaluación de tecnologías. Es importante definir cuál es la plataforma y las
tecnologías que serán usadas en el proceso de desarrollo. Las pruebas de
concepto en esta etapa son necesarias, para realmente determinar si la
plataforma y tecnologías cumplen con los requerimientos tanto de negocio
como técnicos.
- Arquitectura de servicios. En este caso, las decisiones arquitecturales están
basadas en las premisas SaaS y la plataforma que las soporta. Debido a que
las plataformas SaaS están diseñadas para ofrecer una infraestructura de
servicios, los componentes de la aplicación deberían ser diseñadas bajo este
enfoque.
- Ingeniería de procesos de negocio. Incluso cuando la aplicación debe
proveer una definición predeterminada del proceso de negocio que
ejecutará, su valor incrementa cuando es posible redefinir cada proceso de
acuerdo al cliente.
- Documentación tradicional. Esta actividad involucra diversas tareas
comunes como diagramas UML. Se trata de la documentación formal de la
aplicación y depende de las especificaciones de la misma.
- Diseñar casos de prueba. Esta tarea resulta obviamente importante para
cualquier desarrollo serio. Se deben incluir mecanismos de pruebas
unitarias, de integración, de rendimiento, etc.
- Prototipos. Los recursos y la agilidad de generar y desplegar aplicaciones en
plataformas SaaS puede ser explotado a través de la construcción de
prototipos.

d. Implementación:

- Además de las tareas comunes involucradas en la implementación, dentro del

desarrollo SaaS es necesario considerar a la plataforma que soporta las
aplicaciones.
- Desarrollo de servicios de negocio. Se trata de codificar las interfaces
principales de la aplicación, así como sus implementaciones.
Integración con los servicios de la plataforma. Desarrollar el código para
consumir los servicios que la aplicación necesita para operar. Estos servicios
consumidos pueden ser de seguridad, logging, métricas, etc.
- Desarrollar la lógica de negocio. Implementación de las reglas de negocio
para los módulos de la aplicación.
- Desarrollo de integración. Si es necesario, desarrollar código para
integrarse con otros sistemas.
- Implementación de tecnología. Asegurarse que toda la implementación
trabaja correctamente. Esta actividad cubre revisión de código, mejores
prácticas, revisión de complejidad ciclomática, pruebas funcionales, entre
otros.
 e. Pruebas:

- La principal diferencia entre las metodologías tradicionales y la propuesta

para SaaS radica en que las pruebas de integración necesitan validar la
integración correcta entre las aplicaciones y la plataforma.
- Otra diferencia importante es en cuanto a las pruebas de rendimiento y
métricas de uso.
- Pruebas unitarias. Estas pruebas son desarrolladas y ejecutadas por cada
desarrollador.
- Pruebas de integración. Pruebas importantes en cuanto a la integración con
la plataforma, con otros módulos de la aplicación y con otras aplicaciones.
- Pruebas de rendimiento. Cada aplicación tiene sus propios requerimientos
de rendimiento, en este caso, las aplicaciones SaaS tienen una fuerte
dependencia en el número de usuarios y sus especificaciones.
- Pruebas de medición de tenants. La aplicación no debiera implementar
código para logging o medición de uso. Estos componentes son
responsabilidad de la plataforma misma. El objetivo de estas pruebas es
asegurar que el uso y debug de cada aplicación es correctamente registrado
y para cada tenant (cliente y/o proveedor).
- Aprobación Técnica. Consiste en correr todas las pruebas sistemáticamente
y asegurarse que la aplicación es correctamente desplegada a producción. En
el caso de actualizaciones y bugfixes, la plataforma debe proporcionar
mecanismos de rollback cuando existan fallas y se pueda regresar a versiones
anteriores.

5. REFERENCIAS:

Trabajos citados
1. Ricardo Haro Carrere, P. (2012). Obtenido de
ftp://ftp.software.ibm.com/la/documents/imc/la/pe/news/post_events/s
oftware_solutions/presentaciones/Desafios_Beneficios_de_la_Practica_Arqu
itectura_Empresarial_1.pdf
2. http://www.mintic.gov.co/gestionti/615/articles-5322_Revista_pdf.pdf
3. https://colombiadigital.net/actualidad/articulos-informativos/item/8123-
que-es-arquitectura-empresarial.html
4. https://colombiadigital.net/actualidad/soluciones-tic/item/9733-
metodologias-para-abordar-la-arquitectura-empresarial.html
5. Asociacion de Arquitectos Empresariales de España. (2013). Obtenido de
https://es.slideshare.net/Spain-AEA/1200-presentacion-mega-luca-de-risi-
evento-aea-14102013-28494529/4
6. Arquitectura de la Información en el WWW. Luis Rosenfeld y Peter
Morvillle. O’Really. 2000.
7. https://www.mindmeister.com/es/746065050/arquitectura-de-sistemas-
de-informaci-n?fullscreen=1#
8. Usabilidad: la gran desconocida. Emergía. Artículo publicado en la revista
E.Comm (N° Sept. 2000)
9. https://blog.powerdata.es/el-valor-de-la-gestion-de-
datos/bid/394442/qu-es-la-arquitectura-orientada-a-servicios-soa
 10. https://www.epicor.com/lac/solutions/soa.aspx
11. Diaz Rosales Marianela, Arquitectura orientada a Servicios (2008)
12. La Arquitectura Orientada a Servicios (SOA) de Microsoft aplicada al mundo
real
13. Implementación de Arquitectura Orientada a Servicios (SOA) en un
proyecto de E-Salud
14. https://slideplayer.es/slide/122894/
15. http://go.getcirrus.com/blog/la-historia-del-saas
16. https://sg.com.mx/content/view/674

6. MATERIAL COMPLEMENTARIO:
1. http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S2227-
18992015000300001
2. http://www.nosolousabilidad.com/articulos/historia_arquitectura_informa
cion.htm?utm_source=fee
3. https://www.youtube.com/watch?v=SGy2uZFpdBM
4. https://www.youtube.com/watch?v=rS_LCKYnR5k
i
FRANCISCO TOSETE HERRAZ, “concepto de la arquitectura de tecnologías de la información”