CapítuloII

MARCO TEÓRICO

13

CAPÍTULO II

MARCO TEÓRICO

A continuación, se exponen tanto los antecedentes como las teorías que

sustentan la investigación, asimismo se apoya en el perfil de competencias y

práctica profesional, enfocadas al problema tratado requerido como insumo

para el alcance de los objetivos, igualmente se presenta la fundamentación

conceptual y la operacionalización de las variables.

1. ANTECEDENTES DE LA INVESTIGACIÓN

Para la elaboración de este estudio de investigación se necesitó la revisión

y consulta de algunos estudios realizados con anterioridad y relacionados

con las variables; bien por ser iguales o por similares al estudio de

investigación brindando aportes importantes para su desarrollo hasta

alcanzar este propósito. Al respecto se seleccionaron los siguientes

antecedentes:

La de Borondo (2015), presentó ante la Universidad Autónoma de Madrid

el trabajo de fin de máster titulado: “Implementación de una solución Internet

Of Things base para futuros desarrollos de aplicaciones verticales enfocadas

a hacer eficientes, optimizar y gestionar ámbitos o negocios concretos”.

14

Su objetivo fundamental fue el desarrollo de una nueva solución integral

para el Internet of Things que integrara los parámetros recogidos por

dispositivos físicos a través de sensores en una aplicación de usuario en la

que éste pudiera gestionar y monitorizar dichos dispositivos, y que sirviera de

base para futuras implementaciones de soluciones verticales en este

contexto.

En este trabajo se ha llevado a cabo una investigación sobre la tendencia

tecnológica del IoT y del ecosistema M2M, compuesto por objetos físicos

(móviles, sensores, chips RFID, tabletas, entre otros…) conectados enviando

señales interpretadas, de modo que, mediante una inteligencia de negocio,

se genera información enviada al usuario final del sistema.

De igual modo, se utiliza un enfoque propio como metodología para

abordar el problema a través de siete (07) fases muy parecidas a las

utilizadas en el desarrollo de software convencional. No contempla la

definición de variables objetos de estudio. Aunque no menciona los lenguajes

de programación utilizados, se sobreentiende que se utilizan los lenguajes

asociados a las interfaces (API’s) de los “firmware” de las cosas que

estuvieron bajo estudio y los módulos de la solución se hicieron utilizando la

plataforma de desarrollo ThingWorx.

Como resultado se muestra una propuesta de solución basada en tres

(03) módulos que utilizan el protocolo Sigfox para la capa de comunicaciones

y demuestran su aplicabilidad a través de dos ejemplos concretos

pertenecientes a dos contextos muy diferentes, que han sido descritos

15

detalladamente en esta memoria: el de la agricultura y producción inteligente

del vino y el de un sistema de telemetría de boyas y estaciones

meteorológicas.

El estudio, no presenta recomendaciones y en su lugar sugiere como

trabajo futuro la ampliación a otro tipo de dispositivos y su aplicación a otro

tipo de industrias.

Esta investigación aporta a este trabajo una importante recopilación

bibliográfica y revisión teórica sobre los aspectos básicos relacionados con el

tema del internet de las cosas. Sirviendo como referencia para cubrir los

objetivos de análisis de conceptos y da una orientación en la determinación

de los requerimientos funcionales.

Por otro lado, Tabassum (2016), publicó en la revista “Indian Journal of

Science and Technology”, un artículo bajo el título: “Internet of Things

Architecture and Applications: A Survey”. El objetivo principal de este trabajo

fue discutir las diversas arquitecturas de IoT desde la perspectiva de la RFC

y el enfoque en capas. También se centra en las aplicaciones de IoT en

diversas áreas y el análisis de los protocolos de seguridad de IoT para los

dispositivos de recursos limitados.

El estudio se lleva a cabo usando una metodología basada en el análisis

sobre una revisión sistemática de artículos académicos y trabajos de

investigación. No se mencionan lenguajes de programación por tratarse de

arquitecturas de capas. Sin embargo, se mencionan protocolos de

comunicación como TPC/IP para clasificar las cosas entre dispositivos con

16

recursos restringidos y recursos ricos. Así mismo, se mencionan esquemas

de direccionamiento IPv6 y consideraciones arquitectónicas en “Smart Object

Networking”.

Como resultado se muestra que cuando se utilizan los servicios en la nube

para comunicarse, la interoperabilidad entre los dispositivos basados en IP y

no IP es la principal preocupación. En el caso de la arquitectura en capas, el

número de capas determina la complejidad de la arquitectura.

Por otro lado, se sugiere que cinco capas de arquitectura es lo ideal desde

la perspectiva de la seguridad, así como la compatibilidad. En todas las

arquitecturas discutidas se observa que, hay una necesidad de centrarse

más en interoperabilidad y estandarización que es esencial para las

características de seguridad. El trabajo concluye sin recomendaciones pero

dejando claro que la estandarización a nivel arquitectónico y la

interoperabilidad es necesaria, ya que cada proveedor está utilizando

tecnología diferente.

El aporte de este trabajo a esta investigación son las consideraciones

arquitectónicas desde la perspectiva de la seguridad y la compatibilidad que

sirvieron de referencia para cubrir el objetivo de diseñar la arquitectura

tecnológica basada en el ecosistema Internet de las cosas en el B.O.D a

partir de los requerimientos establecidos.

Por último, se considera una publicación de Harding (2016), avalada por

“The Open Group” bajo el título: “Reference Architectures and Open Group

Standards for the Internet of Things”. El objetivo principal gira entorno a tres

17

puntos: En primer lugar discute cómo los arquitectos pueden usar estándares

para definir sistemas, soluciones y productos IoT. En segundo punto,

compara cuatro estándares emergentes de arquitecturas de referencia IoT.

Finaliza con una explicación del papel de los estándares IoT adoptados por

“The Open Group”.

La metodología empleada estuvo orientada al establecimiento de

comparaciones tomadas desde los puntos de vista de negocio, uso,

funciones, información, comunicación, componentes y tipos de industria. Las

arquitecturas de referencia comparadas fueron: Draft ISO IoT RA, IIC

Industrial Internet Reference Architecture (IIRA), RAMI 4.0 y Web of Things.

Por ser un documento a nivel de arquitecturas de referencia no se

menciona de manera explícita lenguajes de programación. Sin embargo, al

momento de definir los estándares para “The Open Group” sugiere la

utilización de lenguajes orientados a objeto de manera muy general. El

resultado muestra una descripción detallada de las diferencias y similitudes

encontradas por el autor. Donde resalta la superposición significativa, y las

diferencias en cobertura y énfasis, que existe entre las arquitecturas

estudiadas.

Este artículo aporta una variedad de arquitecturas de referencia con

énfasis en aspectos de interoperabilidad que son de gran valor para los

arquitectos y sirve de soporte para lograr el objetivo de modelar escenarios

de aplicación de IoT en el B.O.D y analizar las arquitecturas de referencia

manejadas actualmente en la industria.

18

2. BASES TEÓRICAS

Este apartado, como se presenta el basamento teórico el cual está

sustentado por un conjunto de conceptualizaciones sobre la variable

arquitectura tecnológica, por lo que se presentan las definiciones de diversos

autores, para su desarrollo y comprensión, fijándose posición en las que se

consideran relevantes.

2.1. Internet de las cosas.

2.1.1. Concepto

Al dar inicio a este punto, se consideró pertinente consultar el concepto de

Internet de las Cosas expuesto por Higginbottom y Rajchel (2014) quienes

definen el internet de las cosas como "Una infraestructura de objetos

interconectados, personas, sistemas y recursos de información junto con

servicios inteligentes que les permitan procesar y reaccionar a la información

del mundo físico y virtual".

Por otra parte CASAGRAS (2009) define Internet de las cosas como “Una

infraestructura de red global, enlazando objetos virtuales y físicos a través de

la explotación de captura de datos y capacidades de comunicación. Esta

infraestructura incluye desarrollos de redes existente y en evolución.

Ofrecerá identificación de objetos específicos, sensores y capacidades de

conexión como la base del desarrollo de servicios independientes y

aplicaciones. Estarán caracterizadas por un alto grado de actividades

19

autónomas: captura de datos, transferencias de eventos, conectividad de red

e interoperabilidad.”

Asimismo, contrastando los planteamientos de los autores abordados

Higginbottom y rajchel (2014), CASAGRAS (2009), queda entendido para el

presente estudio que el Internet de las cosas se refiere a un ecosistema que

comprende cosas, conectividad y servicios, incluyendo análisis de datos y las

implicaciones de seguridad.

Esto es relevante para este estudio, considerando que el IoT está

trayendo consigo nuevas fuentes de información procedente de un universo

de cosas interconectadas que permitirán ofrecer nuevas experiencias de

cliente personalizadas. Concretamente se convertirá en un motor que

acelerará la creación de nuevos espacios en la transformación digital del

B.O.D.

2.1.2. Tecnologías relacionadas

En este punto se definirán las tecnologías que están relacionadas con el

Internet de las cosas por Gartner (2016), las cuales son:

A) Redes IoT de baja potencia y de corto alcance: la selección de una red

inalámbrica para un dispositivo IoT supone el equilibrio de muchos requisitos

en conflicto, como el rango, la duración de la batería, el ancho de banda, la

densidad, el costo del punto final y el costo operativo. Las redes de corto

alcance y de baja potencia dominarán la conectividad IoT inalámbrica hasta

20

2025, superando en número las conexiones que utilizan redes IoT de área

amplia.

B) IoT Security: El IoT introduce una amplia gama de nuevos riesgos y

desafíos de seguridad para los dispositivos IoT, sus plataformas y sistemas

operativos, sus comunicaciones e incluso los sistemas a los que están

conectados. Se necesitarán tecnologías de seguridad para proteger los

dispositivos y plataformas de IoT de ataques de información y manipulación

física, para encriptar sus comunicaciones y para enfrentar nuevos desafíos,

como la suplantación de "cosas" o ataques de denegación de servicio que

agotan las baterías. La seguridad IoT se complicará por el hecho de que

muchas "cosas" usan procesadores simples y sistemas operativos que

pueden no soportar enfoques de seguridad sofisticados. "Especialistas de

seguridad IoT experimentados son escasos y las soluciones de seguridad

están actualmente fragmentadas e involucran a varios proveedores", El Sr.

Jones dijo. "Nuevas amenazas surgirán a través de 2021 como hackers

encontraran nuevas formas de atacar dispositivos IoT y protocolos, por lo

que “cosas” de larga vida pueden necesitar actualización de hardware y

software para adaptarse durante su vida útil.

C) Procesamiento de secuencias de eventos: Algunas aplicaciones de IoT

generarán tasas de datos extremadamente altas que deben ser analizadas

en tiempo real. Los sistemas que crean decenas de miles de eventos por

segundo son comunes y millones de eventos por segundo pueden ocurrir en

21

algunas situaciones de telecomunicaciones y telemetría. Para abordar estos

requisitos, han surgido plataformas de computación de flujo distribuido

(DSCP). Normalmente utilizan arquitecturas paralelas para procesar flujos de

datos de muy alta velocidad para realizar tareas tales como análisis en

tiempo real e identificación de patrones.

D) Sistemas operativos IoT: Los sistemas operativos (SO) tradicionales

como Windows e iOS no estaban diseñados para aplicaciones IoT.

Consumen demasiada potencia, necesitan procesadores rápidos y, en

algunos casos, carecen de características tales como una respuesta en

tiempo real garantizada. También tienen una huella de memoria demasiado

grande para dispositivos pequeños y pueden no soportar los chips que

utilizan los desarrolladores de IoT. Por lo tanto, una amplia gama de sistemas

operativos específicos de IoT se ha desarrollado para adaptarse a diferentes

huellas de hardware y necesidades de características.

E) Plataformas IoT: Las plataformas IoT incorporan muchos de los

componentes de infraestructura de un sistema IoT en un solo producto. Los

servicios provistos por estas plataformas se dividen en tres categorías

principales:

Control de dispositivos de bajo nivel y operaciones tales como

comunicaciones, supervisión y administración de dispositivos, seguridad y

actualizaciones de firmware.

22

Adquisición, transformación y gestión de datos de IoT.

Desarrollo de aplicaciones IoT, incluyendo lógica de eventos, programación

de aplicaciones, visualización, análisis y adaptadores para conectarse a

sistemas empresariales.

F) Ecosistemas y estándares IoT: Aunque los ecosistemas y los estándares

no son precisamente tecnologías, la mayoría eventualmente se materializan

como interfaces de programación de aplicaciones (API). Los estándares y

sus APIs asociadas serán esenciales porque los dispositivos IoT tendrán que

interoperar y comunicarse, y muchos modelos de negocio IoT dependerán

del intercambio de datos entre múltiples dispositivos y organizaciones.

Aparecerán muchos ecosistemas de IoT, y las batallas comerciales y

técnicas entre estos ecosistemas dominarán áreas como la casa inteligente,

la ciudad inteligente y la atención sanitaria. Las organizaciones que crean

productos pueden tener que desarrollar variantes para soportar múltiples

estándares o ecosistemas y estar preparadas para actualizar productos

durante su vida útil a medida que los estándares evolucionan y surgen

nuevos estándares y APIs relacionados.

2.1.3. Arquitecturas de referencia

Desde la Perspectiva de Chris Harding (2016) Una arquitectura de

referencia es “Una arquitectura genérica que proporciona directrices y

opciones para tomar decisiones en el desarrollo de arquitecturas más

23

específicas y la implementación de soluciones. Una arquitectura de

referencia puede estar en cualquier punto del continuo de la arquitectura.”

Tomando en consideración que existen muchas arquitecturas de

referencia, se hace énfasis a las mencionadas posteriormente por tener

relación con el trabajo de investigación.

Microsoft Azure IoT reference architecture.

Figura 2. Arquitectura de Microsoft Azure IoT.

Fuente: DominicBetts (2017)

A) Conectividad de dispositivos:

En esta arquitectura de solución de IoT, los dispositivos envían telemetría

(como lecturas de sensor de un centro de bombeo) a un punto de conexión

24

de la nube para su almacenamiento y procesamiento. Los dispositivos

también pueden recibir y responder a los mensajes de la nube a dispositivo

mediante la lectura de mensajes desde un punto de conexión en la nube.

B) Procesamiento de datos y análisis:

En la nube, un back-end de soluciones de IoT es el lugar en el que se

produce la mayor parte del procesamiento de datos como, por ejemplo, el

filtrado y la incorporación de telemetría y su enrutamiento a otros servicios.

El back-end de soluciones de IoT:

o Recibe la telemetría a escala de los dispositivos y determina cómo

procesar y almacenar esos datos.

o Puede permitirle enviar comandos desde la nube a dispositivos

específicos.

o Proporciona funcionalidades de registro de dispositivos que le permiten

aprovisionar dispositivos y controlar qué dispositivos pueden conectarse a

la infraestructura.

o Le permite realizar un seguimiento del estado de los dispositivos y

supervisar sus actividades.

C) Presentación y conectividad empresarial:

El nivel de presentación y conectividad empresarial permite a los usuarios

finales interactuar con la solución de IoT y con los dispositivos. Permite a los

usuarios ver y analizar los datos recopilados desde sus dispositivos. Estas

25

vistas pueden adoptar la forma de paneles o informes de BI que pueden

mostrar tanto datos históricos como datos prácticamente en tiempo real. Este

nivel también permite la integración del back-end de soluciones de IoT con

las aplicaciones de línea de negocio existentes para conectarse con los

procesos empresariales o flujos de trabajo.

Google Cloud Platform (Cloud IoT Core).

Cloud IoT Core es un servicio totalmente administrado que le permite

conectarse, administrar e ingerir de manera fácil y segura datos de millones

de dispositivos dispersados a nivel mundial.

Figura 3. Plataforma de Google Cloud.

Fuente: https://cloud.google.com/solutions/iot(2017)

A) Administrador de dispositivos

El gestor de dispositivos permite que los dispositivos individuales se

configuren y gestionen de forma segura en una forma de grano grueso; La

26

gestión se puede realizar a través de una consola o mediante programación.

El gestor de dispositivos establece la identidad de un dispositivo y

proporciona el mecanismo para autenticar un dispositivo cuando se conecta.

También mantiene una configuración lógica de cada dispositivo y puede

utilizarse para controlar remotamente el dispositivo desde la nube.

B) Puente de Protocolo

El puente de protocolo proporciona extremos de conexión para protocolos

con equilibrado automático de carga para todas las conexiones de

dispositivos. El puente de protocolo tiene soporte nativo para la conexión

segura a través de MQTT, un protocolo IoT estándar de la industria. El

puente de protocolo publica toda la telemetría del dispositivo a Cloud Pub /

Sub, que luego puede ser consumida por sistemas analíticos downstream.

Samsung Artik Cloud.

Samsung Artik Cloud no es una arquitectura de referencia en sí, pero se

menciona ya que se toma en consideración los componentes que utiliza ésta

solución de una plataforma abierta para el intercambio de datos en el Internet

de las Cosas.

27

Figura 4 Arquitectura de Samsung Artik Cloud.

Fuente: https://developer.artik.cloud/documentation/(2017)

ARTIK Cloud es un dispositivo agnóstico y escala a todas las aplicaciones

de IoT, incluyendo casas inteligentes, ciudades inteligentes e IoT industrial.

Los desarrolladores pueden pensar más allá de un solo dispositivo y

concentrarse en crear nuevas conexiones alrededor de los datos. Llamamos

a este desarrollo impulsado por datos.

Los clientes pueden acceder y agregar datos históricos de diferentes

fuentes, abriendo así una nueva perspectiva sobre los grandes datos.

Los clientes pueden usar muchos protocolos diferentes para enviar y

recibir datos, incluyendo REST, WebSockets, MQTT y CoAP.

ARTIK Cloud es el único servicio que ofrece a los usuarios un control total

sobre sus datos. Al otorgar acceso a dispositivos y aplicaciones, los usuarios

promueven un ecosistema de servicios alrededor de los datos

28

2.1.4. Consideraciones

Con respecto a las consideraciones de una arquitectura de referencia,

Kumar B., Malla S. (2016) refieren que, aunque el IoT aporta innumerables

beneficios, también conlleva algunos riesgos asociados. Tomar decisiones

correctas podría ser un gran desafío para instituciones bancarias y

financieras. Los bancos necesitan profundizar en la gestión de los datos, la

seguridad y en la necesidad de proteger la información de los clientes y a la

vez mantener estándares de privacidad.

Privacidad: Como parte del IoT, todos los datos de transacción, incluyendo

la información enviada a través de dispositivos inteligentes estará disponible

para los bancos. Junto con estos datos, los bancos tendrán acceso también

a la ubicación de los clientes, lo cual podría llevar a una violación de

privacidad.

Riesgo de seguridad de los datos: Los bancos y otras instituciones

financieras recolectan una gran cantidad de información de los clientes a

través de varios canales. Cualquier filtración de los datos podría traer

severas repercusiones a los bancos. La exposición de los datos privados

causaría daños masivos a los clientes y a la relación de los mismos con sus

respectivos bancos.

29

Los bancos deben incorporar las mejores y últimas tecnologías de

seguridad de datos y deben tomar medidas preventivas y correctivas para

asegurarse que la información está segura.

2.1.5. El impacto del internet de las cosas en los servicios financieros

Desde la perspectiva de Kumar B. y Malla S. (2016) Miles de millones de

dispositivos están conectados unos a los otros, convirtiéndose así en sistema

inteligente de sistemas. Cuando estos dispositivos y sistemas inteligentes

comparten información en la nube y empiezan a analizar, transforman

negocios, vidas y al mundo propio en infinitas maneras.

Los clientes hacen uso de dispositivos inteligentes para acceder a la

información, lo cual permite a los bancos proveer una vista completa de las

finanzas del cliente en tiempo real. Los bancos pueden anticipar las

necesidades de sus clientes a través de los datos recolectados y ofrecer

soluciones y consejos que pueden ayudar a los clientes a tomar decisiones

financieras e importantes de forma inteligente. De esta manera, el “banco de

las cosas” puede convertirse en un facilitador muy poderoso para

incrementar la lealtad del cliente y, a cambio, producir mayores ingresos.

Uno de los beneficios más importante del IoT en el sector bancario es

proveer servicios de fácil acceso a los clientes de tarjetas de crédito y débito.

Los bancos podrán analizar frecuencia y uso de los ATM en áreas

específicas y aumentar o disminuir la instalación de los mismos dependiendo

del uso. Además de los ATM, los bancos también podrán hacer uso de la

30

información generada por los servicios IoT para acercar aún más los

servicios en demanda al cliente, proveyendo quioscos e incrementado la

accesibilidad a los servicios.

Otra característica importante que los bancos podrían beneficiarse al usar

un ecosistema IoT, es prediciendo posibles fraudes en las transacciones de

tarjetas de crédito y débito. Cuando un cliente utiliza su tarjeta, y se compara

la ubicación del dispositivo móvil del dueño con la ubicación de la

transacción, el banco puede con gran confidencia aprobar o declinar la

transacción acordemente.

La información del cliente disponible a través del IoT ayudará a los bancos

a identificar las necesidades de negocio del cliente, el valor de la cadena –

como proveedores, revendedores, distribuidores – y además obtener

información extra del cliente. La información del cliente ayudará también los

bancos a proveer servicios de valor agregado, asistencia financiera y

productos personalizados para asegurar una situación ganar-ganar para

ambas partes.

2.2. Sistema de pago

2.2.1. Concepto.

Con el fin de indagar sobre el concepto del término sistema de pago, se

consultó a Bank for International Settlements(BIS) and International

Organization of Securities Commissions(IOSCO) (2016) donde definen un

31

sistema de pago como “Un conjunto de instrumentos, procedimientos y

reglas para la transferencia de fondos entre los participantes; El sistema

incluye a los participantes ya la entidad que opera el acuerdo.”

2.2.2. Actores

Según Payfirma (2016) estos son los actores que participan en un sistema

de pago:

Adquirente: Asume el riesgo de procesar tarjetas de crédito. El adquirente

solicita, asegura y mantiene la cuenta mercantil. Pueden proporcionar la

tecnología y el hardware que permite al comerciante procesar la transacción.

Agregador: Los agregadores permiten a los comerciantes procesar los

pagos sin configurar una cuenta de comerciante. Agrupan varios

comerciantes y les permiten procesar los pagos con una cuenta comercial

conjunta. La configuración es simple y directa.

Tarjetahabientes: Los tarjetahabientes son consumidores con tarjetas de

crédito utilizadas para comprar bienes y servicios. Son aprobados por el

emisor basado en la solvencia crediticia.

Redes de marcas de Pago: Las redes marcas de pago son coloquialmente

conocidas como tarjetas de crédito y tarjetas de débito. Su trabajo

consiste en gobernar las políticas de cumplimiento relativas a sus tarjetas

32

de pago, supervisar la actividad de procesamiento, desarrollar nuevos

productos y supervisar la compensación y liquidación de transacciones.

Banco Emisor: El banco emisor emite tarjetas de crédito en nombre de las

marcas de las tarjetas. Proporcionan a los consumidores tarjetas de

crédito, envían estados de cuenta de tarjetas de crédito y ofrecen crédito

al consumidor. El emisor también es responsable de la seguridad de la

tarjeta y compensa a los clientes por las pérdidas debidas al fraude.

Comerciantes: Los comerciantes son dueños de negocios que aceptan

pagos a cambio de bienes o servicios.

Procesador de pago: Los procesadores de pago negocian el

procesamiento, la configuración y las tarifas de equipos, así como

configuran la cuenta de comerciante. Actúan como intermediarios entre

comerciantes y adquirentes. También pueden proporcionar la tecnología y

el hardware que permite al comerciante procesar la transacción.

2.2.3. ISO-8583

ISO-8583 es un estándar definido por la Organización Internacional de

Estándares (ISO) utilizado para el intercambio de mensajes en transacciones

financieras. Este estándar define un formato de mensaje y un flujo de

comunicación para que diferentes sistemas puedan realizar estas

transacciones.

33

A pesar de que ISO-8583 es un estándar común, no es utilizado en forma

estricta por sistemas o redes. Sino que más bien es adaptado a las

necesidades particulares de cada constructor. (Luis Gil, 2014).

2.2.4. Funcionamiento

En la siguiente figura se muestra como es el funcionamiento del sistema de pago.

Figura. 5 Funcionamiento de Sistema de pago

Fuente: Payfirma (2016)

1. El tarjetahabiente presenta la tarjeta para hacer la compra.

2. El comerciante procesa la transacción y envía la solicitud al procesador de

pagos.

3. El procesador de pago envía la autorización para la marca de pago

4. La marca de pago envía la solicitud al emisor de la tarjeta.

5. El emisor de la tarjeta aprueba o rechaza la transacción y devuelve el

mensaje a la marca de pago.

34

6. La marca de pago envía la respuesta de autorización al procesador de

pago.

7. El procesador de pago transmite la respuesta al comerciante.

8. El comerciante reciba la respuesta y complete la transacción.

2.3. Arquitectura Empresarial

2.3.1. Conceptos básicos

Una definición interesante por Jeanne Ross, Peter Weill y David

Robertson, investigadores del MIT Sloan Center for Information System

Research (CISR), citado por Camarena Karina y Candela Oscar (2016).

Donde expresa a la arquitectura empresarial como “La lógica organizacional

para procesos de negocio claves e infraestructura de TI que refleja la

estandarización e integración del modelo de negocio de una compañía”

En éste punto se tomará en consideración los conceptos que son básicos

para comprender una arquitectura empresarial y que hacen referencia para

éste trabajo de investigación.

Marco de trabajo: Una estructura conceptual usado para desarrollar,

implementar y sustentar una arquitectura.

Gobernanza de la arquitectura: Es la práctica y orientación por la cual las

arquitecturas empresariales y otras arquitecturas son administradas y

controladas a un nivel empresarial.

35

Visión de la arquitectura: Una breve descripción sobre el valor de negocio y

los cambios producidos en la empresa por la implementación de una

arquitectura.

Dominio de arquitectura: Es el área de la arquitectura a considerar. Por lo

general son cuatro: Negocio, datos, aplicación y tecnología.

Capacidad: Es la habilidad que una organización, persona o sistema posee.

Las capacidades son típicamente expresadas en términos generales y de

alto nivel, y requieren de una combinación de personas, procesos,

tecnologías y organizaciones para llevarse a cabo.

Modelo: Es una representación abstracta y simplificada de un tema de

interés. Un modelo es construido como “un medio para un fin”.

Modelo de referencia: Es un marco de trabajo abstracto usado para

entender relaciones interesantes entre entidades de un ambiente, y para el

desarrollo de estándares y especificaciones consistentes. Un modelo de

referencia está basado en un número pequeño de conceptos unificados y

puede ser usado como la base de explicación de los estándares para una

persona no especialista.

Prueba de concepto: Son desarrollos rápidos, y normalmente incompletos,

realizados con el propósito de verificar que un concepto o una teoría es

susceptible de ser llevada a la práctica. El uso de esta técnica resulta muy

útil cuando se busca disminuir el riesgo potencial asociado a alguna dificultad

36

técnica o algún problema de diseño con el que se enfrente un equipo de

desarrollo.

2.3.2. Beneficios

Con respecto a los beneficios de una arquitectura empresarial, Camarena

Karina y Candela Oscar (2016) refieren:

Aplicar Arquitectura Empresarial en su organización brinda:

La alineación de su modelo de negocios con el modelo de operación.

Contribuye a la toma de decisiones empresariales entre Negocio y TI.

Brinda velocidad hacia el mercado para nuevas innovaciones y habilidades.

Optimiza los recursos de la organización y mejora la distribución de

esfuerzos de acuerdo a las necesidades del negocio.

Procesos más consistentes entre las unidades del negocio.

Fortalece el cumplimiento de políticas, procesos y procedimientos.

Mejor confianza, seguridad, así como menos riesgos a todo nivel incluido

en el uso y calidad de la información.

Trazabilidad entre procesos, datos, aplicaciones y tecnología.

2.3.3. Método de desarrollo

Muchas son las metodologías y arquitecturas empresariales usadas en la

actualidad, pero son tres (03) las que están presentes en la mayoría de las

empresas:

37

El Marco de Trabajo de Zachman para Arquitecturas Empresariales.

El Marco de Trabajo Arquitectural de Open Group (TOGAF).

La Arquitectura Empresarial Federal.

A continuación, una breve descripción de cada una de ellas.

A) Marco de Trabajo de Zachman para Arquitecturas Empresariales:

Más que un marco de trabajo, es en verdad una taxonomía para organizar

artefactos de arquitectura, es decir, documentos de diseños, especificaciones

y modelos, y toma en cuenta el objetivo del artefacto y a qué problema en

particular está siendo dirigido.

B) El Marco de Trabajo Arquitectural de Open Group (TOGAF):

Divide una arquitectura empresarial en cuatro categorías:

Arquitectura de negocio: Describe los procesos que el negocio utiliza

para lograr los objetivos.

Arquitectura de aplicación: Describe cómo aplicaciones específicas son

diseñadas y cómo interactúan entre sí.

Arquitectura de datos: Describe cómo el almacenamiento de datos es

organizado y accedido.

38

Arquitectura técnica: Describe la infraestructura de hardware y software

que soportan las aplicaciones y sus interacciones.

TOGAF ve el mundo empresarial como un continuum de arquitecturas, que

varía desde las más genéricas, hasta las más específicas. Llama a este

continuum como Enterprise Continuum.

TOGAF llama a las arquitecturas más genéricas como Arquitecturas

Bases. Estas son los principios arquitecturales que pueden, en teoría, ser

usado por cualquier organización IT.

El siguiente nivel en el continuum es llamado Arquitecturas de Sistemas

Comunes. Estas arquitecturas son principios que se esperaría ver en

muchos, pero no en todos, tipos de empresas.

TOGAF llama al siguiente nivel Arquitecturas de Industria. Estos son

principios que son específicos a través de varias empresas que forman parte

del mismo dominio, como la industria financiera.

El nivel más específico es llamado Arquitecturas Organizacionales. Estas

son las arquitecturas que son específicas a una empresa dada.

C) Arquitectura Empresarial Federal (FEA):

FEA posee una taxonomía comprensible, como Zachman, y un proceso

arquitectural, como TOGAF. FEA puede ser visto tanto como una

metodología para crear arquitecturas empresariales o como el resultado de la

aplicación de ese proceso a una empresa particular.

39

Para otorgar términos y definiciones estándares para los dominios de la

arquitectura empresarial y facilitar la colaboración a través de varias

empresas, FEA posee cinco modelos de referencias:

El Modelo de Referencia de Negocio (BRM) otorga una vista de negocio

sobre las varias funciones de la empresa.

El Modelo de Referencia de los Componentes (CRM) otorga una vista

más tecnológica sobre los sistemas que soportan la funcionalidad del

negocio.

El Modelo de Referencia Técnico (TRM) define las varias tecnologías y

estándares que pueden ser usados para la construcción de sistemas

tecnológicos.

El Modelo de Referencia de Datos (DRM) define las formas estándar de

describir los datos.

El Modelo de Referencia de Rendimiento (PRM) define las formas

estándar de describir el valor entregado por las arquitecturas empresariales.

2.3.4. Arquitecturas de referencia de la industria bancaria

BIAN

BIAN (Banking Industry Architecture Network), Red de arquitectura de la

Industria Bancaria en español) es una asociación de bancos, proveedores de

soluciones e institutos educacionales con el objetivo común de definir un

estándar de operación de servicio semántico para la industria bancaria. Las

40

expectativas de BIAN es que una definición estándar de las funciones de

negocios e interacciones de servicios beneficiaría significativamente a la

industria. Cuando se compara distintos diseños propietarios, como los

estándares industriales, BIAN provee los siguientes beneficios:

Permite un desarrollo e integración de soluciones bancarias más eficiente y

efectivo.

Mejora eficiencia operacional dentro de un banco y provee las

oportunidades de mayores soluciones y reusabilidad de capacidades dentro

un banco y entre los mismos.

Soporta la adopción servicios de negocios más flexibles y mejora la

evolución y adopción de servicios creados por terceros.

Los principales documentos que conforman el estándar BIAN son:

BIAN Service Landscape – Un mapa de referencia BIAN de alto nivel, que

incluye un conjunto de diseños.

Serie de guía BIAN – Una colección de documentos dirigidos a diferentes

audiencias.

Metamodelo BIAN y documentos de soporte.

Escenarios de negocios BIAN – Los cuales difieren entre bancos.

BIAN Service Domain Definitions – Incluye operaciones de servicio a nivel

semántico.

El objetivo de BIAN es construir un entorno canónico que sea interpretado

consistentemente por cualquier banco en varios escenarios de

41

implementación. BIAN busca identificar capacidades de negocios

elementales que existen dentro de cualquier banco. Las capacidades de

negocios elementales son definidas a un nivel granular donde cualquier

descomposición adicional causaría la pérdida del contexto. Cualquier banco

podría mapear cualquier o todos sus procesos que interactúen con estas

capacidades.

Implementation of Financial Message Standards to BIAN Architecture;

Abhijeet Singh, Ghotra, Arun Kumar Thiagarajan, Felipe Soares Faraco,

Rohan Gupta, Yasuyuki Nishihara (2014)

MIRA-B

Microsoft Industry Reference Architecture for Banking (MIRA-B) les otorga

a las instituciones bancarias las herramientas y el marco de trabajo

requeridos para asegurar que los objetivos estratégicos y las necesidades

del cliente en cuanto al área TI sean satisfechas. Provee un puente entre los

objetivos de negocios y los objetivos centrales a la TI en un banco. La

administración de datos y tecnología es la piedra angular de los servicios

financieros, y de la banca, en particular. Las instituciones financieras que

logran administrar los datos y los sistemas de forma óptima y eficiente,

orquestan procesos y transacciones de negocios, y tienen una gran visión de

negocio pueden ganar una ventaja competitiva en la industria en términos de

innovación de productos, eficiencia de operación y gestión riesgo.

Leading Banks Back into the Black. Joe Pagano (2012)

42

IBM Banking Industry Framework

El Marco de Trabajo Industrial Bancario de IBM (IBM Banking Industry

Framework) combina las herramientas de software de IBM con extensiones

de software, soluciones y prácticas específicas al sector bancario que

permiten desarrollar soluciones más rápido y a un menor costo y riesgo. Un

enfoque orientado a un marco de trabajo ayuda a migrar a una arquitectura

tecnológica más estratégica y flexible, más alineada a las necesidades del

negocio, un proyecto a la vez.

El Marco incluye mejores prácticas y enfoques de implementación

documentados, basado en proyectos exitosos en la industria bancaria.

Soporta también un ecosistema de aplicaciones desarrollados por empresas

independientes, lo que permite una mayor flexibilidad al escoger las

aplicaciones y herramientas necesarias para el negocio.

IBM Banking Industry Framework: Helping banks build a strategic platform

for growth and innovation. IBM Corporation (2009)

3. SISTEMA DE VARIABLES

Se ubica una variable antes expuesta en este trabajo de investigación,

para definirla de manera nominal, conceptual y operacional. De manera, que

la variable a estudiar es:

Arquitectura tecnológica.

43

3.1. DEFINICIÓN NOMINAL

Arquitectura tecnológica basada en el ecosistema Internet de las cosas

(IoT).

3.2. DEFINICIÓN CONCEPTUAL

ARQUITECTURA TECNÓLOGICA

Conceptualmente “Se define Arquitectura Tecnológica como las

capacidades de software y hardware que se requieren para apoyar la

implementación de servicios de negocio, datos y aplicación. Esto incluye

infraestructura de IT, capa de mediación, redes, comunicaciones,

procesamiento y estándares.” The Open Group (2013, p24).

3.3. DEFINICIÓN OPERACIONAL

ARQUITECTURA TECNÓLOGICA

Operacionalmente “Para esta investigación, se busca involucrar las

capacidades de software y hardware de una arquitectura tecnológica, para

diseñar un servicio de negocio para la infraestructura de tecnología de

información del Banco Occidental de Descuento (B.O.D), basado en el

novedoso mundo del Internet de las Cosas (IoT), que permitirá la

optimización de diversos servicios de la entidad bancaria; así como también

servirá de base para futuros proyectos.”