Kitabı oku: «La carrera digital», sayfa 4
Redes de área local
Lo descrito arriba es una red de telecomunicaciones que aplica para largas distancias. Sin embargo, desde hace ya muchos años se encuentra generalizado el uso de lo que se denominan redes de área local (LAN, Local Area Network) o simplemente redes locales, pensadas típicamente para edificios o viviendas, aunque, apoyadas en capacidades de redes de telecomunicaciones, pueden tener cobertura multisede con extensión incluso mundial.
Estas redes son propiedad de una empresa, administración o incluso de particulares.
Aunque existen muchas tipologías, la más común es la red Ethernet, en que los equipos, por ejemplo los ordenadores personales, se conectan a un bus común a través del cual comparten la información.
Hoy en día, además, es muy frecuente que las redes se extiendan mediante capacidades inalámbricas, muy especialmente mediante la bien conocida y casi ubicua wifi.
Ilustración 5. Red de área local.
Estas redes locales, si las queremos ver integradas en el esquema de redes de telecomunicaciones, vendrían a ser una variante compleja de los equipos de cliente.
Ilustración 6. Red de área local unida a red de telecomunicaciones.
Tecnologías para distancias cortas
Aparte de wifi, hoy día existen otras tecnologías y protocolos para conexiones inalámbricas de corta distancia, como el bien conocido bluetooth (que alcanza distancias de diez metros sin repetidores y hasta cien metros con ellos) o NFC (Near Field Communication), que se utiliza, por ejemplo, para pago mediante tarjetas o móvil y que no puede alcanzar más de veinte centímetros.
2.3.Sistemas de información
Los grandes protagonistas del mundo digital son los sistemas de información. A pesar de eso, la literatura actual sobre transformación digital apenas se refiere a ellos, ya que se dan por supuestos y por conocidos. Sin embargo, es muy importante tenerlos en cuenta si queremos realmente entender el mundo digital y llevar a cabo una transformación digital.
Los sistemas de información son un conjunto de hardware y software que proporcionan una funcionalidad, una solución.
Decimos que combinan hardware y software y es cierto, pero, en el fondo, tendemos a centrarnos en el software porque es el elemento diferencial, lo que hace a un sistema realmente distinto de otro.
Los sistemas de información ejecutan cuatro de las cinco funciones de procesamiento de información de que hablábamos en el capítulo anterior. En concreto, se ocupan de todas las funciones menos las comunicaciones, es decir:
→Codificación.
→Almacenamiento.
→Presentación y captura.
→Tratamiento.
Como usuarios, percibimos los sistemas de información a través de un navegador o de un programa o aplicación instalados en nuestro ordenador personal, tablet o smartphone, mediante los cuales obtenemos la funcionalidad. Pero los sistemas de información actuales, tanto los sistemas de empresa como los que vemos en Internet, suelen tener una arquitectura más compleja que un simple programa residente en nuestro equipo. En realidad, suelen estar estructurados en capas, según la arquitectura cliente/servidor.
Cliente/servidor
Aunque existen casos aislados en que el software se presenta como un programa aislado que se ejecuta en un ordenador (lo que se conoce como standalone), lo cierto es que prácticamente todos los sistemas profesionales y gran parte de los personales se estructuran en capas, según el modelo cliente/servidor.
Los ERP (Enterprise Resource Planning) como SAP, Oracle, etc. tienen arquitectura cliente/servidor. Internet y las aplicaciones web tienen arquitectura cliente/servidor. Las aplicaciones de que disponemos en la intranet tienen arquitectura cliente/servidor. Incluso muchas apps de nuestro móvil tienen arquitectura cliente/servidor.
Ilustración 7. Arquitectura cliente/servidor.
En el modelo cliente/servidor más básico se distinguen los dos elementos que dan nombre a la arquitectura: cliente y servidor.
El cliente es la parte que se relaciona con el usuario, lo que este ve del sistema. El cliente presenta los datos al usuario, recoge sus entradas y valida el formato de los datos que el usuario introduce.
En el servidor, por su parte, residen la mayor parte de los datos y la funcionalidad más específica de la aplicación. La mayor parte de lo que entendemos por el sistema o la aplicación reside realmente en el servidor, aunque no lo veamos si no es a través del cliente.
El cliente se relaciona con el servidor en un modelo petición/respuesta: solicita un dato y lo recibe. Solicita un cálculo y recibe el resultado.
La aplicación cliente reside en nuestros equipos personales: ordenadores, tablets y smartphones, y suele ser relativamente pequeña y ligera. Por el contrario, la aplicación servidora suele ser compleja y pesada y reside en grandes máquinas que se denominan también servidores.
Aunque el modelo cliente/servidor se explica hablando de dos niveles, las arquitecturas reales suelen estructurarse al menos en tres capas.
Ilustración 8. Arquitectura cliente/servidor en tres capas.
En el cliente reside la primera capa, que se denomina lógica de presentación porque, coincidiendo con lo que comentábamos más arriba, su función principal es presentar información al usuario y recibir sus órdenes y datos. Esto es lo que ve el usuario.
En el servidor, sin embargo, tenemos dos capas.
Por un lado, tenemos la lógica de datos, que se encarga de codificar, almacenar y recuperar la información. Por otro, tenemos lo que se denomina la lógica de negocio, que contiene los algoritmos y las reglas de negocio propios de la aplicación, constituyendo el núcleo de la misma.
Observemos que en la figura hemos representado explícitamente una red que separa el cliente del servidor porque, en efecto, en casi la totalidad de los casos cliente y servidor se encuentran en máquinas diferentes y, en ocasiones, muy lejanas. Esa red puede ser, por ejemplo, una red de área local (LAN), en el caso de una aplicación corporativa; o una red de área extensa, en el caso, por ejemplo, de aplicaciones de Internet.
Esa figura nos sirve además para destacar y resumir cómo se colocan habitualmente las diferentes funciones de procesamiento de la información de que hablábamos en el primer capítulo. Recordemos, hablábamos de cinco funciones:
→Codificación.
→Almacenamiento.
→Presentación y captura.
→Comunicación.
→Tratamiento.
Ilustración 9. Funciones de procesamiento en la arquitectura en tres capas.
No nos resultará extraño a estas alturas entender que la función de presentación y captura se concentra en el cliente, que la función de comunicación es propia fundamentalmente de la red, que las funciones de codificación y almacenamiento de la información son propias de la lógica de datos, residente en el servidor, y que la función de tratamiento es objetivo fundamentalmente de la lógica de negocio, también residente en el servidor.
Aunque la realidad es algo más compleja de lo arriba expresado, no se separa demasiado de ese esquema.
ERP y CRM
La variedad de sistemas de información presentes en el mundo de la empresa es inmensa e incluye tanto sistemas construidos a medida por las propias compañías como software comercial desarrollado y comercializado por fabricantes especializados.
Sin embargo, hay dos clases de aplicaciones empresariales tan presentes y de funcionalidad tan amplia que es relevante dedicarles unas líneas: los ERP y el CRM.
Los ERP (Enterprise Resource Planning), de los cuales el más conocido y difundido es SAP R/3, se encargan de informatizar y automatizar la mayor parte de los procesos e información corporativos, pero con un mayor foco en los procesos de back-office: económico-financieros, de producción y logística.
Así, en un ERP típico podemos encontrar módulos para:
→Gestión financiera.
→Contabilidad analítica.
→Gestión de recursos humanos.
→Producción.
→Compras.
→Logística y materiales.
→Gestión de proyectos.
→Etc.
Los sistemas CRM (Customer Relationship Management) son históricamente posteriores, pero siguen la misma filosofía. Eso sí, se centran en los procesos más comerciales y de relación con el cliente, promoviendo una visión única de cliente y una mayor omnicanalidad, es decir, integración entre canales comerciales y de relación con el cliente.
Los módulos típicos de un sistema CRM incluyen:
→Ventas.
→Marketing.
→Atención posventa.
No es extraño, a pesar de la distinción que aquí hacemos, que una misma suite incluya módulos tanto de ERP como CRM para intentar proporcionar una solución completa de gestión empresarial.
Los productos ERP y CRM llevan incorporados de serie unos procesos y un modelo de información, pero ofrecen posibilidades de personalización para adaptarse a las necesidades de cada empresa. Si es necesaria esa adaptación, cada empresa procede a lo que se denomina una parametrización. Igualmente, los proveedores de estas soluciones intentan proporcionar soluciones adaptadas para un sector específico (salud, retail, industria, etc.), constituyendo lo que se denominan verticales.
Hay dos elementos tan importantes de los sistemas de información y tan presentes en la realidad digital actual que bien merecen una sección propia: bases de datos y SOA.
Por un lado, al hablar de bases de datos vamos a desarrollar algo más esa lógica de datos, esa forma en que se almacena y recupera la información, y para ello vamos a dedicar una sección a las bases de datos.
Por otro lado, es importante para entender la realidad de las empresas medianas y grandes saber cómo interconectamos sistemas entre sí. Lo abordaremos hablando específicamente de una arquitectura de integración de sistemas que se denomina SOA.
2.4.Bases de datos
Las bases de datos o, por mejor expresarlo, los Sistemas de Gestión de Bases de Datos (SGBD), son un tipo de software especial que se centra en el almacenamiento y recuperación de datos. La necesidad de este tipo de software específico deriva del hecho de que para que el almacenamiento y recuperación de datos almacenados sea eficiente al tratar grandes cantidades de datos, es preciso aplicar tecnologías y algoritmos especiales.
Hablamos de software del estilo de Oracle, DB2 o Access, si pensamos en soluciones comerciales; o de alternativas como MySQL o PosgreSQL, si optamos por software libre.
Bases de datos relacionales
Aunque existen y han existido diferentes tipos de bases de datos, las que dominan el panorama actual, al menos hasta el advenimiento del big data, son las bases de datos relacionales.
En una base de datos relacional toda la información se modela en torno a dos conceptos: la entidad, que representa una cosa física o un concepto (por ejemplo, un cliente o una factura), y las relaciones, que son las asociaciones que se establecen entre las entidades (por ejemplo, la relación que une a una factura con el cliente al que se aplica). Las relaciones y, especialmente, las entidades pueden tener datos asociados (por ejemplo, el CIF o razón social del cliente). Veámoslo con un ejemplo muy simple:
Ilustración 10. Un modelo entidad-relación simple.
En la figura hablamos de tres entidades: clientes, productos y facturas. La entidad cliente tiene como atributos el CIF, la razón social, el segmento y la cuenta bancaria a la que se factura. El producto/servicio tiene como atributos un identificador interno, un nombre comercial, la cuota de alta y la cuota mensual. La factura tiene como atributos un número identificador, el inicio del periodo en que aplica, el final del periodo en que aplica y el importe. Además, hay relaciones. Así, un cliente se relaciona con los productos/servicios que ha contratado y una factura se relaciona con el cliente al que se le emite.
En una base de datos relacional, las entidades y relaciones se traducen en última instancia a tablas. En el caso más general, una tabla representará una entidad. También puede representar o una relación muchos a muchos entre entidades. Las columnas de una tabla representan o bien los atributos de la entidad, o bien identificadores de las entidades que intervienen en una relación. Cada fila en una tabla representa un caso concreto de la entidad o relación (por ejemplo, un cliente concreto o una factura concreta).
Ilustración 11. Tablas en una base de datos relacional.
Las bases de datos relacionales son muy buenas gestionando importantes cantidades de datos en lectura y escritura y a muy alto ritmo (transaccionalidad), logrando mantener la coherencia de los datos. Eso sí, trabajan bien con datos estructurados (fundamentalmente, textos cortos y números con formatos y longitudes claramente establecidos) y en interacciones cortas y que manejan los datos en bloques pequeños.
Ilustración 12. Transacciones sobre una base de datos.
Datawarehouse y business intelligence
Cuando lo que deseamos hacer no es almacenar y consultar datos en pequeños volúmenes, sino consultar grandes cantidades de datos de una sola vez para obtener indicadores, análisis, informes, etc., las bases de datos relacionales no son óptimas.
¿Por qué? Porque en una base de datos relacional, cuando un programa está escribiendo sobre un dato, este queda bloqueado para su acceso por otras aplicaciones que lo comparten. Si para obtener un informe, indicador o parámetro tenemos que recorrer una gran parte de las tablas de la base de datos, estaremos bloqueando el trabajo de otros programas y ralentizando el conjunto.
Para resolver esta problemática, se separan las bases de datos que se usan por los programas de trabajo de aquellas otras que se utilizan para grandes consultas. Las bases de datos de trabajo se suelen denominar operacionales, precisamente porque se utilizan para la operación diaria. Por su parte, las que se utilizan para consultas son informacionales.
En los casos más sencillos, las bases de datos utilizadas para las consultas son una réplica exacta, en cuanto a su estructura y datos, de las bases de datos de trabajo, de las operacionales. En este caso, estamos hablando de lo que se conoce como ODS u Operational Data Store.
En otros casos, sin embargo, estas bases de datos que se utilizan para informes se dotan, por una parte, de un diseño técnico especial que agiliza esas consultas. Ese diseño es lo que se denomina dimensional. En este tipo de bases de datos se habla por una parte de hechos, es decir, qué tipo de información nos interesa consultar (por ejemplo, facturación, número de clientes y productos vendidos) y, por otro lado, de las dimensiones, es decir, las perspectivas bajo las cuales queremos presentar los datos (por ejemplo, por segmento de clientes).
Ilustración 13. Modelo dimensional.
Este tipo de bases de datos constituye lo que se conoce como datamarts o datawarehouses. La diferencia entre ambos términos no es cien por cien nítida, pero en general podemos entender un datamart como un subconjunto de un datawarehouse. Con cierta frecuencia, los datamarts o datawarehouses se alimentan no desde la base de datos operacional, sino desde los ODS. Con ello, el esquema más general sería el que se muestra en la figura:
Ilustración 14. Relación de bases de datos operacional, ODS, datamart y datawarehouse.
Este tipo de soluciones se dotan de capacidades específicas para elaboración de informes y análisis de datos, con lo que entramos en el campo de la inteligencia de negocio (o business intelligence). En algunos casos, además, se proporcionan capacidades avanzadas de descubrimiento de ciertos patrones, lo que nos lleva al conocido como data mining o minería de datos.
2.5.Integración de sistemas. La arquitectura SOA
A pesar de que soluciones como los ERP y CRM, que planteábamos más arriba, pueden cubrir la mayor parte de las necesidades de una empresa, lo cierto es que en el caso de compañías de mediano o gran tamaño suelen disponer de un mapa de sistemas complejo.
Esta variedad de sistemas obedece tanto a necesidades especializadas de cada sector o empresa como a motivos históricos de desarrollo e implantación de las diferentes soluciones.
Aunque tener un mapa de sistemas complejo hace más difícil la gestión, no es en sí mismo muy problemático si esos sistemas no se relacionan entre sí. Sin embargo, lo habitual es que sí deban hacerlo. Integrar sistemas de diferentes procedencias suele implicar problemáticas, de entre las cuales dos muy importantes son:
→Diferente tecnología.
→Diferente modelo de información.
Diferente tecnología implica el uso de distintos lenguajes, productos comerciales y plataformas. Así, por ejemplo, una aplicación legada puede estar desarrollada en COBOL, almacenar datos en una base de datos DB2 y ejecutarse en un mainframe S/360 con monitor transaccional CICS, mientras que otra aplicación puede estar desarrollada en Java, tener su base de datos en MySQL y ejecutarse sobre un servidor de aplicación Apache.
Diferente modelo de información implica que para la misma información del mundo real (por ejemplo, para la misma factura) diferentes sistemas pueden darle un identificador distinto, o denominar a los datos con diferente nombre, o asignarles distinta longitud.
Para que se puedan comunicar deben definirse lo que se denominan unas interfaces, poniéndose de acuerdo en la tecnología usada para el intercambio de información, el formato en que los datos se intercambiarán, los servicios que un sistema puede pedir a otro, etc.
Si solo se tratase de relacionar dos sistemas el problema sería de moderadas dimensiones: se establece esa interfaz y punto. Pero cuando hablamos de decenas o centenas de sistemas diferentes se genera una explosión combinatoria de interfaces que reclama una solución más global.
Esa solución es SOA (Service Oriented Architecture).
En SOA cada sistema expone dos cosas: unos servicios y un modelo de información de intercambio.
Los servicios son las interacciones atómicas que otros sistemas pueden mantener con el primero.
El modelo de información de intercambio define qué datos se pueden intercambiar, cómo se interrelacionan y los formatos de cada campo. Es algo muy similar a un modelo entidad-relación y, de hecho, puede coincidir parcialmente con el modelo entidad-relación de alguno de los sistemas intervinientes. De todas formas, por principio, no debe suponerse que el modelo de información de intercambio coincida con el de una base de datos en concreto, sino que es un convenio para intercambio de información.
Ilustración 15. Servicios y modelo de información de intercambio.
Veámoslo con un ejemplo. Imaginemos que el sistema de la figura de arriba es un sistema que almacena todas las facturas que se reciben o generan en una empresa. El sistema puede exponer tres servicios: uno para grabar una factura, otro para modificar una factura y un tercero para consultar una factura.
A su vez, define un modelo de información de intercambio que reutiliza parcialmente el que vimos al hablar de modelos entidad-relación. En ese modelo, la entidad principal es la factura con sus cuatro atributos y con una relación con el cliente al que corresponde.
En las arquitecturas SOA actuales, normalmente los servicios se implementan mediante los denominados web services, donde se utilizan protocolos de intercambio propios de Internet (HTTP: HyperText Transfer Protocol), la información de intercambia en formato XML (eXtensible Markup Language) o JSON (JavaScript Object Notation) y el modelo de información puede reflejarse en los denominados esquemas XML No nos adentraremos en el significado de estos términos técnicos porque no es preciso realmente para entender la importancia de SOA.
Sin embargo, SOA no acaba en un sistema. Lo que se hace es que todos los sistemas que intervienen en la arquitectura SOA exponen sus servicios. Además, todos los sistemas tienen acceso al censo completo de servicios expuestos y comparten un modelo de información de intercambio único.
A esto se añade una última pieza: el bus o, mejor, el ESB o Enterprise Service Bus. El ESB es un software especializado de interconexión que, entre otras cosas, tiene las siguientes funciones:
→Sirve de intermediario entre todos los sistemas.
→Realiza la traducción de datos cuando alguno de los sistemas no se adhiere completamente al modelo de información de intercambio.
→Es capaz de comunicarse mediante conectores de diferentes tecnologías.
→Aporta mecanismos de entrega segura de mensajes (ejemplo: reintentos).
Cuando existe un bus, como es el caso habitual, los sistemas no hablan directamente entre sí, sino a través del bus.
Ilustración 16. Enterprise Service Bus.
Al hablar de integración nos referimos fundamentalmente a integración entre las partes servidoras de los sistemas. Sin embargo, es posible que también el cliente de una aplicación hable con su servidor usando esos mismos servicios.
Con esto, vemos cómo SOA resuelve la problemática de integración:
→Todos los intercambios se reducen a un catálogo cerrado y conocido de servicios que se utilizan por todos los sistemas, en lugar de definiciones específicas para cada interfaz bilateral.
→La diversidad tecnológica la resuelve mediante la propuesta de un modelo común de servicios basado normalmente en la tecnología de web services. Las diferencias tecnológicas que puedan quedar pendientes o los casos de sistemas que no incluyen web services los resuelve el bus.
→La diversidad de modelos de información se resuelve compartiendo un modelo de información de intercambio único y, de nuevo, si persiste alguna diferencia o algún sistema que no se adapta, las traducciones se realizan sobre el bus.
