Tendemos a asociar la palabra arquitectura, únicamente con la construcción de edificios y otras estructuras públicas o privadas, pero olvidamos que el significado de esta palabra tiene mayor profundidad.

Cuando entendemos la arquitectura como el arte y la técnica de diseñar, proyectar y construir obras urbanísticas u otras construcciones, podemos comenzar a imaginar que el significado se refiere a cómo fluyen las actividades humanas dentro de un espacio o estructura (física o metafísica).

Como marinos, gran parte de las actividades de nuestro día a día ocurren al interior de los buques, o bien imaginando como otras personas deben realizar sus tareas diarias dentro de él. Es por esto, que cuando nos referimos al diseño y proyección de un buque, cobra especial relevancia la figura del arquitecto naval, pues él es el llamado a abstraerse de lo tangible y comenzar a imaginar espacios físicos de desarrollo humano y su vinculación con las máquinas de su entorno.

Esta es la dimensión más observable del fenómeno, donde las personas se mueven entre espacios e interactúan con tecnología que les permite cumplir con sus funciones, sin embargo, al ampliar la mirada, podremos identificar que, dentro de estas estructuras, fluyen otras cosas además de las personas, los víveres y los fluidos que permiten el funcionamiento de la maquinaria. Podemos comenzar a entender que la arquitectura puede tener varias dimensiones, y una de ellas es el flujo de los datos al interior de los sistemas. 

El flujo de los datos

El flujo de datos en los sistema a bordo contempla la captura, almacenamiento, procesamiento y despliegue de información, principalmente orientada a ser una ayuda para quien sea el operador. Este flujo les permite a los navegantes, por ejemplo, ajustar alarmas de track dentro de la carta electrónica, transformándose en un apoyo constante a la seguridad. En buques que cuentan con capacidad de posicionamiento dinámico, automatizar el movimiento para que se mantenga en un punto específico. ¿Pero a dónde más se van esos datos históricos una vez que han sido utilizados? Dependiendo del sistema, la mayoría de esos datos quedan almacenados a bordo de la unidad, en una base de datos relacional exclusiva del sistema y no se están utilizando para efectuar análisis más complejos. Es decir, luego de haber apoyado en la automatización de un proceso puntual, ese dato no se vuelve a explotar.

Otros sistemas más complejos, como por ejemplo el Sistema Integrado de Gestión de la Plataforma (IPMS de sus siglas en inglés), brindan la opción de extraer los datos almacenados del comportamiento global del buque, para que sean analizados en un ambiente externo a la unidad. Algo similar ocurre con sistemas acústicos como los del Cabo de Hornos y del futuro rompehielos, que cuentan con la posibilidad de exportar los datos acústicos para su posterior análisis (50 tera bytes). Entonces, ¿Cómo se exportan los datos del IPMS o de los sistemas acústicos para su análisis? ¿Dónde son almacenados? ¿Quién tiene acceso a esos datos para su análisis y construcción de información para la toma de decisiones?

Suena trivial, pero la transferencia desde el buque, el almacenamiento y los accesos para análisis son actividades más complejas de lo sospechado. Los protocolos de comunicación, la seguridad en la transferencia y los anchos de banda involucrados hacen difícil la extracción y el almacenamiento, lo que impone un gran desafío institucional. Si a eso sumamos la interferencia humana, que en algunas oportunidades contaminan y alteran la unicidad del dato y su calidad, comprenderemos que nos vemos enfrentados a un problema de gran magnitud al enfrentar la gestión integral de los datos en la flota de activos.

Toma de decisiones en la gestión de flota

El macro-proceso desde la captura hasta la presentación de información, nos suena natural desde la llegada de la tecnología de sistemas integrados, los cuales cuentan con sus propias infraestructuras digitales, sin embargo, no es tan natural cuando tenemos que enfrentarnos a la gestión de la flota de buques y otros artefactos de uso militar, y queremos usar datos para la toma de decisiones de alto nivel.

Decidir cuándo separar un activo del servicio, cuando realizar una reparación mayor o cómo deberíamos reemplazar una capacidad, hoy en día requiere de una visión holística, que nos permita comprender de manera integral la realidad de las operaciones que la institución tendrá que enfrentar en el futuro de mediano y largo plazo.

La ciencia de datos es uno de los caminos que la academia y la industria han tomado para poder determinar el rendimiento de los activos y así poder realizar análisis que permitan construir información útil, sin embargo, al observar la flota como un conjunto de sistemas, podemos imaginar que al igual que en un sistema integrado, se requiere de una arquitectura dentro de la cual sea posible establecer el flujo de datos hacia las distintas capas que permiten generar información de calidad.

Nos referimos a contar con la capacidad que los datos generados por los sistemas puedan ser almacenados temporalmente a bordo, exportados a infraestructura terrestre (institucional o contratada como servicio externo), que permita el almacenamiento y acceso, para su posterior análisis y explotación.

De alguna manera, la institución ha realizado esfuerzos de consolidar y construir esta capacidad mediante la adquisición de herramientas (software) y de instauración de políticas organizacionales, sin embargo, estos esfuerzos suelen ser grandes desarrollos, poco flexibles y prácticamente inadaptables a la realidad de la cultura de la organización, lo que genera una baja explotación de la capacidad.

Al no contar con una arquitectura que organice el creciente volumen de datos y de solicitud de información, los tomadores de decisión se ven forzados a integrar información incompleta y apoyar gran parte de sus decisiones en la experiencia personal, no representativa de fenómenos que ocurren en una escala mayor a lo potencialmente observable por una persona y atemporal en relación con sus vivencias personales.

El esfuerzo que realiza cada organización de la institución en desarrollar individualmente herramientas de software (local), para resolver los problemas de obtención y procesamiento de datos, da origen a iniciativas que pueden llegar a funcionar en su escala local, pero no son escalables o son ineficientes en la globalidad.

La falta de escalabilidad de estas soluciones locales no permite su integración a otras soluciones similares, generando islas de desarrollo de software que complejizan la construcción y visualización de información relevante.

Este fenómeno termina impactando en los dos activos más importantes de la institución, los activos físicos y humanos, al no tener la posibilidad de integrar datos en las distintas dimensiones que permiten generar una imagen global.

Este supuesto nos permite inferir que el problema no sólo está en el desarrollo de las herramientas de software específicos para cada área y tarea, sino que, al carecer de una arquitectura que permita orientar el flujo de los datos dentro de una estructura común, no es posible organizar el análisis de grandes volúmenes de datos que se obtienen de los buques y de las personas que los tripulan.

Esto sumado a la nula flexibilidad y adaptabilidad de las herramientas a las crecientes y cambiantes demandas de los usuarios, hacen pensar que este es un problema transversal que requiere de una filosofía que se adapte a la cultura organizacional, por lo que debe ser descubierta y no impuesta.

Contar con una arquitectura definida, que determine las subrutinas, funciones y procedimientos que ofrece una biblioteca de datos, para ser consumida por otros software que se encuentren en una capa de abstracción y no sean parte integral  de la gestión de las bases de datos (tarea realizada hoy por las API de su significado en inglés “Application Programming Interface”), permitiría la contratación de estructuras de software más livianas, de distintos desarrolladores, que pueden ser concebidas como servicios temporales o permanentes, que permiten flexibilidad de gestión y del uso de la herramienta.

¿Cómo lo hacen las grandes empresas de tecnología?

El problema de manejo de datos a gran escala no es algo nuevo. Imaginemos un pequeño negocio de ventas online. Es muy probable que al tener un catálogo de 20 productos y distribuir a 50 clientes, es suficiente contar con una planilla Excel y un computador casero para la gestión de fichas de producto y de cliente. Con el tiempo ese negocio se verá forzado a crecer en cantidad de productos y tecnología, para el manejo de las bases de datos donde organiza a sus clientes. Enfrentar la escalabilidad de este problema tiene un límite tecnológico, que es la arquitectura de las bases de datos.

Una base de datos relacional, como su nombre indica, nos permite vincular una serie de datos de los clientes con la base de datos de los productos, pero al mismo tiempo trae consigo el inconveniente que en la medida que la base de datos crece, se va necesitando más capacidad de procesamiento para que las consultas sean dentro de un tiempo “tolerable” y acorde a las expectativas del usuario. Al mismo tiempo, esta arquitectura de base de datos relacional o también conocida como MySQL, no es divisible. Es decir, la única forma de aumentar la capacidad de proceso es aumentando físicamente la cantidad de computadores (procesadores). Eso significa que, en el largo plazo, cuando el negocio de ventas online ha crecido suficiente, tiene un problema con el manejo de grandes volúmenes de datos, pues es caro mantener una infraestructura física muy grande, es lento para poder realizar consultas, y finalmente, se ve afectado el servicio hacia el consumidor, por lo que los clientes migran a otros prestadores de servicio.

Las grandes empresas tecnológicas como Amazon, eBay o Google se vieron enfrentados a este problema de arquitectura, que los impulsó a desarrollar a finales de 2007, nuevas formas de manejo de datos. Al no ser económicamente rentable seguir creciendo en infraestructura física, se vieron desafiados a desarrollar nuevas formas tecnológicas de abordar el problema de “Big DATA”.

Es en este punto, donde nacen nuevas formas de aproximarse a los datos y cambia la arquitectura, se da paso a que entre en escena una nueva tecnología. Ahora, las bases de datos NoSQL (no relacionales), permiten mayor flexibilidad y menos latencia. Pero ¿Cuál es la gracia de esta nueva tecnología? Imaginemos al mismo negocio de venta online, que tiene sus productos identificados del 1 al 10.000 y atiende a 40.000 clientes ordenados de la A a la Z. Con las bases de datos NoSQL ahora puede dividir a los clientes en bases de datos independientes de la A a la L y otra de la M a la Z y al mismo tiempo, a los productos en bloques de 1.000. Esto permite una capa superior en la arquitectura, que ayuda a gestionar las consultas y derivarlas a la sección correcta, disminuyendo el tiempo de cada transacción, pues el motor de búsqueda ya no debe buscar en un solo lugar la información requerida. De esta manera, se necesita menos recursos de proceso y en consecuencia menos hardware para enfrentar el problema del volumen de datos.

En resumen, el cambio significativo fue que la arquitectura de base de datos relacional forzaba el crecimiento en infraestructura física al no ser divisible, mientras que la nueva tecnología, permite ir dividiendo los registros en cuantas bases de datos sea necesario y agregando una capa de gestión que organiza el registro y las consultas, de manera de optimizar el tiempo de consulta y evitar el recorrido de todos los datos mediante una dirección eficiente de los requerimientos.

Ahora que los datos están organizados de manera accesible para grandes volúmenes ¿Cómo se puede mejorar la capacidad de una institución?

Si tomamos este ejemplo de arquitectura de los datos y ahora le adjuntamos pequeños servicios entregados por software, que cumplan con tareas definidas y en base a un mecanismo que establezca las definiciones y protocolos de conexión con los servicios entregados por software mediante API (Interfaz de programación de aplicaciones), ya no necesitamos contar con un gran sistema informático auto-contenido, pues al tener una estructura a la cual se puede acceder ágilmente, es posible mejorar los tiempos de respuesta para cada transacción, independiente si quien consulta es una persona o es un software externo.

De esta manera, es posible subcontratar pequeños servicios, los cuales pueden provenir de desarrollo propio o externos, lo que le da al sistema informático en plaza la flexibilidad para crecer o encogerse en la medida que sea necesario, permite ir generando bancos de aplicaciones (APP Store), que ayuden a explotar distintos conjuntos de datos, teniendo siempre la certeza que los datos se mantienen accesibles, depurados y únicos.

Contar con una Arquitectura Orientada a Servicios (SOA de sus siglas en inglés), nos permitiría poder conectar en base a protocolos institucionales, distintas aplicaciones de software provenientes del desarrollo propio o privado, dando flexibilidad y distribuyendo el riesgo que significa contar con grandes y complejos sistemas de gestión auto-contenidos, que indirectamente limitan las posibilidades de cambiar de proveedor, y se traducen en dependencia y altos costos en el tiempo.

Contar con una arquitectura orientada a servicios, nos daría la flexibilidad de desarrollar software específicos, livianos y ágiles, para resolver problemas puntuales que no signifiquen esclavizar las actividades propias del servicio naval a un único desarrollador.

¿Qué es la Arquitectura Orientada a Servicios?

La Arquitectura Orientada a Servicios o SOA (de sus siglas en inglés), es un estilo de diseño de software donde los servicios son entregados a otros componentes del sistema en base a aplicaciones, a través de un protocolo de comunicación en la red. Dicho de otra manera, es un espacio donde múltiples servicios se comunican entre  ellos en una de dos maneras posibles: facilitando datos o agrupando servicios para coordinar una actividad.

Esta es solo una aproximación, sin embargo, existen seis factores que toda SOA debe cumplir de manera de abordar el concepto de manera integral:

-    Valor del negocio.

-    Metas estratégicas.

-    Inter-operatividad intrínseca.

-    Servicios compartidos.

-    Flexibilidad.

-    Refinamiento evolutivo.

Existen ciertos roles en cada uno de los servicios que integran los bloques de la arquitectura: proveedores de servicios; intermediario de servicios; registro de servicios; y consumidores de servicios.

El proveedor de servicios trabaja en conjunto con el registro, permitiendo el cuestionamiento de que servicio y porque este debe ser ofrecido, tales como seguridad, disponibilidad, como debe cambiaren el futuro y más. Este rol determina la categoría del servicio.

El intermediario de servicios, entrega información relacionada a la disponibilidad del servicio consultado. El alcance del Intermediario es determinado por quienes implementan la arquitectura.

El consumidor de servicios entra en el registro, y es dirigido hacia el proveedor. El consumidor puede acceder o no dependiendo de su perfil de acceso, a múltiples servicios.

Las tecnologías implementadas en SOA, pueden ser variadas y muy amplias y  dependerá de cuales sean los objetivos  que se busca alcanzar. Una de las más usadas es la de servicios web, que permite el acceso operar en base a protocolos estándar de internet. En este punto es importante notar que la arquitectura puede operar de forma independiente de las  tecnologías específicas que se seleccionen para una solución.

Este proceso requiere de la ejecución de prototipos en espacios controlados, con el objetivo que el descubrimiento de la arquitectura sea una consecuencia de la adaptación cultural y no una imposición que va en contra del uso por parte del usuario.

Realizar esfuerzos que signifiquen un primer paso en el descubrimiento y normalización de una arquitectura que permita ganar flexibilidad, permitiría entender y aprender de cuáles son las decisiones que tendremos que tomar al momento de desarrollar aplicaciones que nos permitan obtener indicadores de rendimiento de los activos (unidades) y finalmente comprender cuáles son las condiciones de rendimiento bajo las cuales es operada la flota de superficie y cómo impactan en el desarrollo de futuras unidades hechas a la medida de nuestra Armada de Chile.

Este es el insumo necesario y vital para determinar los requerimientos que determinarán la flota del futuro y son relevantes a la hora de plantear un plan nacional continuo de construcción naval.