FAQ: Tecnología de la Información (TI)

La aplicación de Lokad es una aplicación web proporcionada como SaaS (Software como Servicio). El propósito de Lokad es ofrecer análisis predictivos para optimizar la cadena de suministro (mejores stocks, mejores precios, etc.). La aplicación de Lokad está diseñada como una capa analítica que opera junto a los sistemas transaccionales (ERP, WMS, CRM, etc.). Viene con una tarifa plana de suscripción mensual que generalmente incluye la propia aplicación y servicios profesionales. Estos servicios profesionales, proporcionados por los ingenieros de Lokad (Supply Chain Scientists), eliminan casi por completo la necesidad de soporte técnico del propio departamento de TI para este alcance. La única contribución clave esperada del departamento de TI es la configuración de un canal de datos que envíe archivos planos (por SFTP o FTPS) a Lokad, y potencialmente reintegre los resultados generados.

Público objetivo: Departamento de TI
Última modificación: 30 de noviembre de 2023

Descripción técnica

La aplicación de Lokad es multitenant. Cada inquilino (es decir, cuenta de cliente) tiene su propio sistema de archivos dedicado y su propio repositorio de código base. El sistema de archivos es accesible a través de FTPS, SFTP y una interfaz web. Este sistema de archivos está diseñado para archivos planos grandes (hasta 100 GB por archivo) y cuenta con versionado de datos (como Git). El repositorio de código base se utiliza para alojar scripts de Envision. Envision es un DSL (Lenguaje de Programación Específico del Dominio) propietario desarrollado por Lokad. Este DSL está altamente especializado para casos de uso de optimización predictiva. Los scripts de Envision se utilizan para realizar los análisis numéricos principales (incluidos algoritmos de aprendizaje automático, solucionadores, …) y generar paneles de control con datos enriquecidos.

La aplicación se vuelve a implementar por completo todos los martes entre las 10:00 y las 14:00 (hora de París). El tiempo de inactividad generalmente se mantiene por debajo de los 5 minutos. Lokad se encarga por completo de todas las preocupaciones de versionado.

No se espera que el departamento de TI adquiera ninguna competencia específica con la pila de tecnología de Lokad. Sin embargo, si tienes curiosidad, hay una documentación técnica completa.

Descripción de la contribución de TI

Esperamos que el departamento de TI configure un canal de datos que envíe una serie corta de extracciones de archivos planos relevantes a Lokad mediante SFTP o FTPS. Las extracciones se realizan sobre los sistemas transaccionales (por ejemplo, ERP). Tenemos una fuerte preferencia por las extracciones de tablas sin procesar (sin filtro, sin unión, sin transformación), lo que requiere un esfuerzo mínimo. Desde una perspectiva de ETL, solo requerimos la parte de “extracción” (extract) en su forma más simple (copia simple). En cuanto al formato, Lokad es compatible con cualquier archivo plano tabular razonable.

Se espera que el canal de datos se ejecute al menos diariamente y esté completamente automatizado. La cantidad de trabajo para el departamento de TI depende del alcance de la extracción de datos (¿qué sistemas? ¿qué tablas?). Sin embargo, como regla general, la configuración del canal de datos generalmente requiere alrededor de 15 a 45 días-hombre, incluso para empresas grandes. Una vez que el canal de datos está en funcionamiento, Lokad generalmente requiere solo un monitoreo mínimo por parte del departamento de TI, lo cual se realiza típicamente con 1 o 2 días-hombre al mes.

Descripción de la seguridad

La aplicación está alojada en centros de datos de Microsoft Azure ubicados en la UE. No procesamos ningún dato personal, ya que no necesitamos dichos datos para operar. Al establecer el alcance de la extracción de datos, excluimos cualquier columna o campo que contenga datos personales.

En cuanto a la autenticación, nuestra preferencia es SAML. Sugerimos encarecidamente que los usuarios accedan a Lokad a través de una identidad federada como Azure Active Directory, Office 365 o Google Workspace. Esto elimina todos los problemas relacionados con las contraseñas.

A pedido, nuestros clientes pueden realizar auditorías de seguridad y pruebas de penetración. Los detalles dependen de los acuerdos negociados.

Para obtener más detalles, consulta Seguridad en Lokad.

Descripción general de la línea de tiempo

La Supply Chain Quantitativa es más un viaje que un fin en sí mismo. Sin embargo, al mismo tiempo, el liderazgo de la cadena de suministro que involucra a su empresa en la realización de una iniciativa de Supply Chain Quantitativa requiere visibilidad cuando se trata de la línea de tiempo del proyecto. Si bien se pueden obtener retornos positivos en un par de meses, a menudo se tarda hasta dos años en desbloquear todo el potencial de la Supply Chain Quantitativa. En el siguiente artículo, proporcionamos una descripción general de una línea de tiempo típica asociada con una iniciativa de Supply Chain Quantitativa para una empresa mediana. Para las grandes empresas, se espera que los plazos sean el doble de largos.

Inicio del proyecto: Los representantes de ambas partes se presentan entre sí y programan reuniones semanales. Estas reuniones semanales durarán hasta que se alcance la fase de producción. El Supply Chain Scientist presenta las diferentes fases de implementación y los diversos entregables que el cliente puede esperar. El resto de la llamada se dedica a revisar varios detalles de la cadena de suministro y características de TI de la integración. Después de la llamada, se produce un resumen que documenta los aspectos organizativos del proyecto y se envía al cliente.

Especificaciones de datos: Poco después de la reunión de inicio, el Supply Chain Scientist produce las especificaciones de datos necesarias para la implementación del proyecto. Estas especificaciones se revisan y validan junto con el cliente. En particular, este documento debe definir los datos que se extraerán de los sistemas de TI del cliente. Como regla general, la extracción debe mantenerse lo más cerca posible de los datos originales tal como existen en los sistemas de TI del cliente.

Carga de datos 1: Después de validar las especificaciones, el cliente carga el primer conjunto de datos en los servidores de Lokad. Por lo general, en esta etapa, la carga aún no se realiza a través de un proceso automatizado, ya que generalmente se requieren varios intentos para establecer un consenso sobre los detalles específicos de los datos.

Validación de los datos: El Supply Chain Scientist realiza una investigación exhaustiva del contenido del conjunto de datos del cliente. En particular, se introducen controles de integridad para monitorear la calidad de los datos según múltiples métricas. El objetivo es asegurarse de que 1) el conjunto de datos se actualice correctamente mediante el proceso de carga, 2) el conjunto de datos refleje correctamente la realidad del negocio y 3) el conjunto de datos sea coherente y completo para fines de optimización de la cadena de suministro.

En cuanto a los entregables, durante esta fase el Supply Chain Scientist proporciona al cliente varios paneles de control que evalúan la salud de los datos. Estos paneles de control pueden ser utilizados por el cliente incluso para fines que van más allá de la iniciativa de Supply Chain Quantitativa en sí, como parte de su proceso interno de aseguramiento de la calidad de los datos, por ejemplo.

Auditoría a mitad de proyecto: 6 semanas después del inicio inicial, se programa una reunión para evaluar el estado de finalización del proyecto. El objetivo de esta “auditoría” es abordar, lo antes posible, los problemas que puedan surgir durante la implementación, especialmente aquellos que puedan retrasar la fase de producción. En Lokad, esta “auditoría” consiste en un intercambio entre el Supply Chain Scientist y el cliente, basado en una lista de verificación que se comunica al cliente con anticipación por parte del Supply Chain Scientist, justo después de la reunión de inicio.

Automatización de la carga: Una vez que ambas partes validan la calidad general del conjunto de datos que se ha cargado hasta ahora, el cliente implementa un proceso automatizado que transfiere su conjunto de datos a Lokad de manera regular, idealmente a diario. Al mismo tiempo, en el lado de Lokad, la lógica de integridad de los datos, con sus múltiples controles, se programa para actualizarse después de cada carga.

Configuración de la optimización: A partir de este punto, el Supply Chain Scientist tiene todos los ingredientes necesarios para implementar la optimización de las decisiones que se han acordado previamente con el cliente. Por lo tanto, implementa scripts para generar diferentes resultados cuantitativos: sugerencias de compra operativas, sugerencias de envío, etc. Las cifras producidas por estos scripts se pueden visualizar en forma de paneles de control. En esta etapa, estos paneles de control representan solo una versión preliminar de los paneles de control finales y deben ser revisados junto con el cliente.

Comentarios y ajustes: Las solicitudes del cliente para realizar algún tipo de modificación o “ajuste” a las diferentes salidas generalmente conducen a un ajuste fino de los scripts escritos por el Supply Chain Scientist. Hay muchos parámetros y métodos que se pueden adoptar para alinear adecuadamente las características de la cadena de suministro que se está optimizando con la lógica de optimización. Cuando la metodología en sí misma es de importancia estratégica para el cliente, esto se discute explícitamente entre el cliente y el Supply Chain Scientist.

Producción: Después de varias rondas de ajustes y revisiones, el cliente llega a una etapa en la que confía en la lógica implementada por el Supply Chain Scientist. En este punto, el cliente puede comenzar a utilizar el servicio en producción, es decir, puede ejecutar directamente las decisiones de la cadena de suministro tal como se calcularon originalmente por el software. Cuando el cliente valida que la solución está lista para producción, el Supply Chain Scientist entrega una documentación que garantiza la mantenibilidad de la solución.

Soporte y mantenimiento: La solución está operativa y es utilizada por el cliente mientras el Supply Chain Scientist supervisa la ejecución diaria fluida del flujo de datos. Se organizan llamadas regularmente entre el cliente y el Supply Chain Scientist para verificar que la optimización brinde el grado esperado de rendimiento de la cadena de suministro. Además, las cadenas de suministro no son estáticas, por lo tanto, los cambios comerciales o de TI, pequeños o grandes, deben ser revisados: un nuevo almacén, cambio en el mercado, nuevo proceso, etc. El Supply Chain Scientist propone modificaciones adecuadas para adaptarse a estos diferentes cambios. Se programan llamadas de control con una frecuencia acordada, generalmente mensual.

Preguntas frecuentes (FAQ)

1. Gestión de versiones

1.1 ¿Cómo funcionan las versiones en Lokad?

Lokad maneja todas las versiones internamente, lo que ayuda a garantizar una transparencia completa para los clientes. Cualquier versión que pueda afectar a un cliente se coordina con ellos, a través de los equipos técnicos del cliente, con suficiente antelación. En general, Lokad adopta un enfoque cauteloso en cuanto a las versiones: si una versión programada no proporcionaría suficiente tiempo de preparación para un cliente, la versión se pospondría temporalmente.

Las versiones de Lokad son muy detalladas y generalmente permiten al cliente optar por no incluir un elemento técnico específico de una versión general. Por lo tanto, si debemos posponer la implementación de un elemento -para el cual nuestro cliente aún no está listo- la versión general aún puede tener lugar (e implementar los otros elementos que no tienen impacto).

1.2 ¿Con qué frecuencia se lanzan las versiones?

Lokad lanza una nueva versión todos los martes, generalmente alrededor de las 11 AM (CET).

1.3 ¿Proporcionan un plan de las próximas versiones?

Sí, consulte Gestión de versiones 1.2.

1.4 ¿Un cambio de versión implica una reinstalación o solo un parche?

Lokad vuelve a implementar, a través de medios automatizados (scripts), su propia solución. No aplicamos parches a los sistemas en producción. Si tenemos un “parche de seguridad” para implementar, volveremos a implementar la solución a través de nuestros medios automatizados habituales.

1.5 ¿Cuánto tiempo lleva aplicar una versión importante?

El proceso automatizado lleva aproximadamente 1 hora. Hay una implementación gradual (máquina por máquina), ya que pretendemos mantener la plataforma de Lokad operativa y accesible durante la versión. La operatividad durante una implementación se discute en Gestión de versiones 1.7.

1.6 ¿Quién es responsable de la correcta ejecución de la versión?

El equipo de Lokad se hace cargo de la correcta ejecución de la versión.

1.7 ¿Hay tiempo de inactividad durante la versión?

En su mayoría no, pero tenga en cuenta que la solución de Lokad es un sistema distribuido dedicado a cálculos a gran escala. Como tal, el impacto de una versión difiere entre los sistemas de front-end y back-end. Los subsistemas orientados al cliente, como los paneles de control, están diseñados para no tener tiempo de inactividad. Los sistemas de back-end, como los encargados de la ejecución de trabajos por lotes, pueden pausarse durante unos minutos (al menos para algunos trabajos). Sin embargo, estos trabajos por lotes se pueden programar, por lo que una planificación proactiva debería permitir la finalización de los trabajos por lotes fuera del marco de tiempo de la versión.

1.8 ¿Cuál es su proceso o estrategia de prueba para una versión?

Lokad utiliza procesos automatizados dedicados a probar y garantizar la corrección de una próxima versión. Estos procesos incluyen conjuntos extensos de pruebas automatizadas (medidas en miles); pruebas unitarias, pruebas funcionales, pruebas de rendimiento, etc. También hemos desarrollado herramientas dedicadas que nos permiten reproducir secuencias completas de ejecuciones de trabajos pasados dentro de la plataforma de Lokad. Estas herramientas nos permiten verificar que los scripts de Envision tengan el mismo comportamiento exacto antes/después de una próxima versión. Además, podemos verificar que los perfiles de rendimiento de los scripts existentes se mantengan en línea con las expectativas del cronograma, según lo definido por nuestros clientes.

1.9 ¿Tienen varios entornos?

Sí, sin embargo, los entornos alternativos (a nivel de plataforma, además del de producción) generalmente no están destinados a nuestros clientes. Además del entorno de producción y los entornos de desarrollo transitorios, tenemos un entorno “evergreen” que coincide con la última versión estable de nuestro código base. Esto valida un subconjunto específico de nuestros procesos de prueba automatizados. Nuestros clientes pueden acceder a nuestro entorno “evergreen” para validar que una próxima versión específica se comporte como se espera. Esta situación puede surgir si hay una integración de TI entre Lokad y el cliente. En la práctica, esta situación es poco frecuente.

Si el objetivo es poder ejecutar (lado a lado) múltiples variantes de scripts de Envision, entonces una cuenta de Lokad se puede dividir en múltiples “entornos”. Si el objetivo es poder realizar cualquier tipo de prueba, entonces se puede proporcionar una segunda cuenta de Lokad para fines de prueba transitoria. Este segundo enfoque mantiene la cuenta principal del cliente (utilizada para producción) aislada de estas pruebas.

1.10 ¿Cuántas versiones diferentes pueden coexistir?

Lokad es un SaaS multiinquilino que ejecuta la misma versión única para todos sus clientes, sin embargo, Lokad tiene la capacidad de operar tantas versiones distintas como desee el cliente.

1.11 ¿Puede un cliente optar por no participar en una versión?

Como Lokad es un SaaS multiinquilino que ejecuta la misma versión única para todos los clientes, no es posible optar por no participar en una versión. Sin embargo, desde una perspectiva empresarial, esto es irrelevante ya que cualquier “cambio” se implementa mediante la ejecución de scripts de Envision dentro de la solución de Lokad.

Para situaciones en las que una versión puede posponerse temporalmente, consulte Gestión de versiones 1.1.

1.12 ¿Tienen notas de versión? ¿Las proporcionan a sus clientes?

Sí. Estas notas se comparten internamente (con nuestros equipos de científicos de la cadena de suministro). Si se acuerda explícitamente como parte de un contrato, estas notas de versión pueden estar disponibles para un cliente. En la práctica, las notas de versión de la plataforma de Lokad solo son de interés para las personas que trabajan con código de Envision.

1.13 ¿Cuál es el proceso para que un cliente solicite una evolución de la solución?

La mayoría de nuestros clientes se benefician de una oferta de “software + experto”, donde un equipo de científicos de la cadena de suministro de Lokad es responsable de la implementación y mantenimiento de la solución de cadena de suministro de un cliente. Estas situaciones se conocen como “cadena de suministro como servicio”. En estos acuerdos, el cliente interactúa rutinariamente con uno (o más) científicos de la cadena de suministro. Además, la mayoría de los clientes se benefician de un comité de dirección semanal o mensual para discutir el estado actual de la solución y cualquier evolución deseada. Lokad utiliza este método para recopilar todas las solicitudes de evolución y proponer una hoja de ruta para la implementación de cambios.

1.14 ¿Es posible administrar el servicio web de la aplicación y configurar sus parámetros?

Sí, en el sentido de que la plataforma de Lokad es programática por naturaleza. La lógica “analítica” de Lokad toma la forma de scripts de Envision, siendo Envision el DSL (Lenguaje Específico del Dominio) desarrollado por Lokad con el propósito de la optimización predictiva de la cadena de suministro.

Por lo tanto, en cierto sentido, cada configuración de parámetros está disponible aprovechando los scripts de Envision dentro de la cuenta.

2. Rendimiento

2.1 ¿Su SLA (acuerdo de nivel de servicio) cubre un tiempo de actividad del 99.xy%?

Sí. El SLA es parte de nuestro acuerdo contractual predeterminado. Sin embargo, la noción de tiempo de actividad en el contexto de un sistema informático distribuido, dedicado a la optimización predictiva de cadenas de suministro, es compleja. Considere los siguientes escenarios: - Lokad recibe datos del cliente (un paso diario) 2 horas después de lo programado. Esto bien podría interrumpir la eficiencia habitual de nuestras heurísticas de asignación de recursos. Esto, a su vez, puede prolongar el tiempo necesario para realizar los trabajos por lotes de Lokad (por ejemplo, 75 minutos en lugar de los habituales 60). Algunos pueden considerar esto como un tiempo de inactividad de 15 minutos, pero eso está fuera de nuestro control.

• Lokad recibe los mismos datos del cliente a tiempo, pero los datos presentan una caída considerable en los niveles de stock. Esto desencadenaría una interrupción de los trabajos por lotes (lado de Lokad) y alertaría a un científico de la cadena de suministro para investigar el problema. El científico de la cadena de suministro ve que un pedido de reposición automatizado es excepcionalmente grande. El científico de la cadena de suministro decide que es necesario realizar una evaluación directa por parte del cliente. Al día siguiente, el cliente confirma que los datos de stock estaban corruptos y habrían resultado en una gran cancelación de stock. Algunos pueden considerar esto como un tiempo de inactividad de 24 horas, pero eso parece prácticamente obtuso en contexto.

El mayor peligro para una solución de optimización de la cadena de suministro no es llegar un poco tarde; es estar muy equivocado. Una vez que se toma una decisión de la cadena de suministro, como (incorrectamente) activar un lote de producción, deshacerlo puede ser extremadamente costoso. Alentamos a nuestros clientes a no apegarse arbitrariamente a indicadores de forma aislada, ya que esta actitud puede incentivar a las personas a entregar un trabajo general inferior siempre y cuando parezca satisfacer un KPI (como el tiempo de actividad x.y%).

2.2 ¿Garantizan un tiempo de respuesta para las solicitudes de los usuarios dentro de X segundos?

Sí, en menos de 500 ms, pero con advertencias.

Hemos diseñado lo que equivale aproximadamente a “paneles de tiempo constante”. Bajo el capó, la visualización de un panel requiere una sola solicitud a través de la red, y en nuestro backend, colocamos todos los datos del panel para mantener bajo el número de solicitudes de red (generalmente medido en cifras de un solo dígito). Esta elección de diseño contribuye en gran medida a “garantizar” la baja latencia de la solicitud típica del usuario en la visualización de un panel. Esta elección de diseño también evita que el panel se llene de mosaicos, cada uno de los cuales requeriría solicitudes de red, y ralentice la experiencia general del usuario.

En cuanto a la duración de los trabajos por lotes, a través de Envision podemos proporcionar garantías, en tiempo de compilación, de que un trabajo por lotes se completará. También podemos garantizar tiempos de finalización en gran medida reproducibles para nuestros trabajos por lotes. Estas garantías se obtienen mediante análisis estático y un diseño cuidadoso del lenguaje Envision, que hace posible ciertas clases de análisis estático en primer lugar. Este enfoque tiene límites, pero es muy superior a los diseños que no ofrecen ninguna garantía.

Sin embargo, la latencia de extremo a extremo no está completamente en nuestras manos. Por ejemplo, no controlamos la calidad de la conexión a Internet utilizada por nuestros clientes. Una gran hoja de cálculo de Lokad llevará tiempo descargarla a través de una red de baja capacidad.

2.3 ¿Tienen registros de auditoría del rendimiento del sistema?

Sí. Recopilamos registros de rendimiento muy detallados para todos los recursos informáticos involucrados: CPU, memoria, almacenamiento, ancho de banda, etc. Estos registros de rendimiento se utilizan, entre otras cosas, para asegurarnos de que una nueva versión de la plataforma, aún no lanzada, cumpla nuestras expectativas en términos de rendimiento. Probamos esto comparando el rendimiento de la nueva versión con el rendimiento de las versiones anteriores, como se evidencia a través de estos registros.

2.4 ¿Es posible monitorear respuestas lentas o congestión?

Sí. La plataforma de Lokad viene con un programador interno que puede rastrear la ejecución oportuna de los trabajos por lotes. El diseño de Lokad garantiza en gran medida una respuesta constante para todas las solicitudes, excepto las operaciones de larga duración, que se tratan como trabajos por lotes.

Dado que Lokad es una plataforma multiinquilino, una gran parte del monitoreo de rendimiento no es directamente accesible para nuestros clientes (ya que cubre el rendimiento de la plataforma en su conjunto). Como era de esperar, los equipos de Lokad monitorean continuamente el rendimiento de nuestra plataforma.

2.5 ¿Tienen balanceadores de carga?

Sí. Los balanceadores de carga de Lokad están destinados principalmente a garantizar la confiabilidad en lugar de mejorar el rendimiento. El equilibrio de carga a nivel de red se realiza a través de la capa de redes de la plataforma de computación en la nube que utilizamos (Microsoft Azure). Sin embargo, la distribución de la carga de trabajo interna de procesamiento de datos, que maneja la plataforma de Lokad, no se gestiona a través de balanceadores de carga, sino a través de un orquestador interno asociado con nuestra pila de compiladores.

2.6 ¿Agrupan recursos como conexiones de BD, sesiones, etc.?

Sí. Sin embargo, la plataforma de Lokad no se basa en una base de datos transaccional para operar. Por lo tanto, no hay conexiones de BD para agrupar. No obstante, agrupamos muchos otros recursos siempre que tenga sentido desde una perspectiva de rendimiento.

2.7 ¿Admiten procesamiento paralelo?

Sí. Envision (nuestro DSL) está diseñado en torno a la noción de ejecución paralela automática. La plataforma de Lokad aprovecha activamente la paralelización en múltiples niveles: a nivel de núcleo de CPU a través de operaciones SIMD (Instrucción Única/Múltiples Datos); a nivel de CPU a través de ejecuciones multinúcleo; y a nivel de clúster a través de computación distribuida. Como el procesamiento paralelo es un aspecto fundamental del diseño de Envision, la casi totalidad de las cargas de trabajo ejecutadas en la plataforma de Lokad se benefician de una extensa paralelización, de forma predeterminada, sin ningún esfuerzo específico por parte de nuestros clientes o nuestros científicos de la cadena de suministro.

2.8 ¿Admiten el almacenamiento en caché de datos de acceso frecuente?

Sí. Sin embargo, el almacenamiento en caché se introduce con frecuencia como una solución alternativa para hacer frente a las limitaciones de rendimiento de las bases de datos transaccionales. Dado que la plataforma de Lokad no incluye bases de datos transaccionales, no utilizamos el almacenamiento en caché para este propósito.

2.9 ¿Comprimen los datos para reducir el tráfico de red?

Sí, comprimimos la mayor parte del tráfico de red. Sin embargo, no podemos comprimirlo todo, ya que eso presentaría una vulnerabilidad de seguridad conocida como BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext). BREACH ocurre cuando se cumplen 3 factores en combinación.

1. Una respuesta está comprimida.

2. Una respuesta contiene un secreto.

3. Una respuesta contiene una cadena que puede ser recopilada por el atacante que crea la solicitud.

Para defenderse contra BREACH, Lokad deshabilita la compresión en todas las respuestas donde se cumple la tercera condición. También comprimimos los datos por razones más allá de reducir el tráfico de red; en primer lugar, para reducir los costos de almacenamiento de datos; y en segundo lugar, para reducir los retrasos de cálculo.

2.10 ¿Realizan pruebas de rendimiento?

Sí. Lokad tiene una extensa capa de instrumentación automatizada orientada al rendimiento. Esta serie de herramientas nos permite evaluar, antes de cada lanzamiento, la diferencia de rendimiento de la próxima versión en comparación con la obtenida con la versión actualmente implementada. Esta herramienta nos permite reproducir las mismas cargas de trabajo, tal como se observan en producción, y monitorear el rendimiento resultante; no solo en tiempo de reloj, sino considerando todos los recursos informáticos relevantes (memoria, ancho de banda, E/S, CPU, etc.).

2.11 ¿Monitorean el rendimiento a nivel de transacción?

Sí. Sin embargo, como la plataforma de Lokad no utiliza una base de datos transaccional, no hay “transacciones” que se puedan monitorear (en el sentido tradicional). El equivalente más cercano es la ejecución de scripts de Envision. Para estos scripts, monitoreamos el rendimiento a un nivel muy granular, que es aproximadamente análogo a monitorear los detalles de la ejecución del plan de consulta (desde una perspectiva de base de datos transaccional).

Consulta Autorización 3.6 y Registro y Monitoreo 5.3 en nuestra documentación de Seguridad para obtener más información sobre las “transacciones” en la solución de Lokad.

2.12 ¿Cuál es el impacto en el rendimiento de tener usuarios concurrentes en la solución?

Casi ninguno. El diseño de Lokad garantiza que los paneles de control puedan ser atendidos en tiempo constante incluso para un gran número de usuarios (según los estándares B2B). Este enfoque contrasta fuertemente con muchas arquitecturas alternativas, especialmente las bases de datos transaccionales y los cubos de Business Intelligence.

Sin embargo, dado que cualquier usuario individual podría (si tiene los derechos de sistema adecuados) desencadenar cargas de trabajo arbitrariamente grandes, el número de usuarios concurrentes es, como máximo, una preocupación secundaria en cuanto al rendimiento de la solución. En lo que respecta a la optimización predictiva de la cadena de suministro, los trabajos por lotes utilizados para realizar el análisis de interés representan más del 99% de la carga de trabajo. El menos del 1% restante se dedica a atender las solicitudes de los usuarios.

2.13 ¿El sistema está diseñado para escalar vertical y horizontalmente?

Sí. Desde nuestra perspectiva, la escalabilidad vertical y horizontal son complementarias, y el diseño de la plataforma de Lokad aprovecha ambas. El orquestador interno, encargado de la paralelización, generalmente comienza con la escalabilidad vertical, ya que la escalabilidad vertical facilita en gran medida la colocación de datos. Luego, el orquestador aprovecha la escalabilidad horizontal si la carga de trabajo es lo suficientemente grande como para beneficiarse de la ejecución en varias máquinas.

2.14 ¿Realizan la escalabilidad automática de cómputo y almacenamiento según sea necesario?

Sí. La plataforma de Lokad es multiinquilino. A través de la multiinquilinidad, realizamos asignaciones de recursos informáticos a gran escala y baja latencia. Esto significa que la escalabilidad automática de cómputo que proporciona Lokad es órdenes de magnitud más rápida que la creación de grandes VM (máquinas virtuales) a partir de un proveedor de computación en la nube. La escalabilidad automática de almacenamiento se realiza en gran medida aprovechando las propiedades de escalabilidad automática de la base de datos clave-valor persistente, proporcionada por la plataforma de computación en la nube subyacente (Microsoft Azure).

2.15 ¿Cómo gestiona su aplicación los requisitos de “Big Data”?

La plataforma de Lokad ha sido diseñada específicamente para el procesamiento de “Big Data”. A partir de enero de 2023, toda la plataforma de Lokad gestiona aproximadamente 1 petabyte de datos en toda nuestra base de clientes. Nuestra plataforma puede procesar archivos individuales de hasta 100 GB, y rutinariamente procesamos tablas con decenas de miles de millones de líneas. Ir a Seguridad de Lokad 4.10

Este punto es particularmente técnico y va más allá del alcance de este documento. Para una explicación detallada, recomendamos la serie de 4 partes de Victor Nicollet sobre el diseño de la Máquina Virtual Envision.

2.16 ¿Se puede configurar la solución basada en la nube de Lokad teniendo en cuenta las restricciones de ancho de banda y latencia (lado del cliente)? Por ejemplo: ancho de banda = 3Mbps (descarga) / 1Mbps (carga), latencia = 600-800ms

Sí, la aplicación web diseñada por Lokad ha sido desarrollada para poder soportar escenarios donde la conectividad es “pobre” (tanto en términos de ancho de banda como de latencia). Estas preocupaciones se abordan principalmente mediante elecciones fundamentales de diseño tecnológico. Estas elecciones de diseño arquitectónico también diferencian a Lokad de la corriente principal. Las preocupaciones sobre el ancho de banda se abordan de dos maneras. En primer lugar, somos parcimoniosos en lo que respecta a los componentes de terceros de JavaScript. Tenemos menos de 1MB de activos que se deben recuperar inicialmente. En segundo lugar, la plataforma ofrece un control completo sobre la cantidad de datos que se incluirán en cualquier panel individual. Por lo tanto, si la conectividad es deficiente, es posible hacer que el panel sea apropiadamente “ligero”. En cuanto a las preocupaciones de latencia, nuestros paneles han sido diseñados para empaquetar todos los datos relevantes del panel en una sola solicitud HTTP. Esto minimiza la fricción incurrida por los usuarios finales de baja latencia.

2.17 ¿Cuáles son las capacidades de rendimiento promedio y máximo de la solución en comparación con un punto de referencia de 1 (bajo) y 5 (alto) mensajes por segundo?

La plataforma de Lokad no opera con mensajes. De manera similar, las interacciones con la plataforma de Lokad no se realizan a través de mensajes. Sin embargo, el rendimiento es importante para procesar rápidamente conjuntos de datos vastos de datos transaccionales. La plataforma de Lokad gestiona, en conjunto, más de 1 petabyte de datos. Rutinariamente manejamos más de 1 terabyte por minuto para grandes lotes de cálculos.

Un rendimiento muy alto es importante para evitar retrasos operativos al procesar conjuntos de datos muy grandes (decenas de terabytes) con cálculos complejos que incluyen pasos de aprendizaje automático y optimización matemática.

2.18 ¿Qué tamaño de mensajes puede manejar la solución? Proporcione detalles sobre los valores mínimos, máximos y promedio.

La plataforma de Lokad no opera con mensajes. Lo más parecido serían los “archivos planos”. Estos archivos planos se pueden enviar y recuperar de Lokad. La plataforma de Lokad puede procesar archivos que individualmente tienen un tamaño de hasta 100 GB. Sin embargo, esta no es una práctica recomendada, ya que suele ser un poco incómoda (no para Lokad, sino para los clientes que tendrán que familiarizarse con herramientas externas para producir y consumir los archivos grandes).

3. Incidentes

3.1 ¿Cuál es el proceso para que un cliente informe de un incidente?

La mayoría de nuestros clientes se benefician de un paquete que incluye acceso a nuestro equipo de científicos de la cadena de suministro. Estos científicos de la cadena de suministro son el primer punto de contacto para informar de incidentes. En caso de un incidente, sugerimos a los clientes que llamen directamente a su científico de la cadena de suministro, si el problema es urgente, o que envíen un correo electrónico. Los científicos de la cadena de suministro se encargan de la gestión de incidentes, incluyendo cualquier escalada dentro de la organización de Lokad.

3.2 ¿Ofrecen un sistema de tickets?

Sí. Lokad utiliza un sistema de tickets de terceros. Sin embargo, a partir de enero de 2023, hemos comenzado a desarrollar una solución interna que ofrece una integración estrecha con el resto de nuestra plataforma.

3.3 ¿Soportan la notificación de incidentes a herramientas de terceros?

Sí, bajo la provisión de un acuerdo contractual dedicado.

En el contexto de la optimización predictiva de la cadena de suministro, los “incidentes” pueden variar y ser difíciles de definir. En general, nuestros clientes no consideran eventos menores a nivel de plataforma (como cortes de minutos) como “incidentes”. En cambio, las anomalías reales en la cadena de suministro, que pueden o no reflejar problemas con los scripts de Envision implementados en la cuenta del cliente, serían mejores candidatos. Los departamentos de TI externos rara vez están involucrados en la resolución de estos incidentes.

3.4 ¿Cómo garantizan una alta disponibilidad?

Lokad se convirtió en un adoptante temprano (c. 2010) de plataformas de computación en la nube precisamente para garantizar una mayor disponibilidad. Además de hacer que la infraestructura sea redundante (ver Incidentes 3.5), el diseño de la solución de Lokad enfatiza fuertemente la simplicidad. A diferencia de las soluciones de software empresarial comparables, tenemos significativamente menos dependencias complejas (casi una orden de magnitud menos). Una enorme capa de complejidad ausente de nuestra solución es una base de datos transaccional. Al tener menos piezas móviles, tenemos muchos menos modos de falla, lo que nos ayuda a mantener una alta disponibilidad para nuestros clientes (que están distribuidos en varios husos horarios).

3.5 ¿Tienen una infraestructura redundante (si es así, cómo)? ¿Evitan los puntos únicos de falla?

Sí. Nuestros sistemas críticos son redundantes, precisamente para evitar puntos únicos de falla. Los sistemas redundantes incluyen los subsistemas que admiten protocolos stateful como SFTP. Además, el almacenamiento de datos no solo es redundante, sino también geográficamente redundante. Esta redundancia se aprovecha durante nuestras versiones para preservar el tiempo de actividad mientras se realiza la implementación.

3.6 ¿Cómo se recuperan de las fallas de hardware?

La recuperación de la mayoría de las fallas de hardware se realiza de forma transparente por la plataforma de computación en la nube que utiliza Lokad. La redundancia incorporada en la plataforma de Lokad garantiza que las fallas de hardware transitorias no afecten el tiempo de actividad mientras la plataforma de computación en la nube asigna un nuevo recurso no defectuoso. Para el almacenamiento de datos persistente, Lokad solo utiliza servicios (es decir, almacenes de clave-valor) que están protegidos contra fallas de hardware a través de sus propias capas de redundancia.

3.7 ¿Tienen una copia de seguridad?

Sí. Tenemos un entorno de copia de seguridad dedicado a escenarios graves de recuperación ante desastres (más allá de un tiempo de inactividad a nivel de centro de datos). Este entorno de copia de seguridad está completamente aislado del entorno de producción. El entorno de copia de seguridad puede leer del entorno de producción (pero no escribir), mientras que el entorno de producción no puede leer ni escribir en el entorno de copia de seguridad.

3.8 ¿Tienen un plan de recuperación ante desastres?

Sí. A nivel técnico, el plan de recuperación ante desastres cubre la reinstanciación completa de la plataforma de Lokad. Esta parte aprovecha ampliamente los procesos automatizados que tenemos en marcha para nuestras versiones semanales. A nivel empresarial, el plan de recuperación ante desastres incluye contactar a cada cliente que tenemos, siguiendo típicamente un proceso acordado con cada uno. Para la mayoría de nuestros clientes, los científicos de la cadena de suministro designados actúan como los puntos de contacto principales durante la recuperación.

3.9 ¿La solución admite la recuperación en un momento determinado (PITR) en la base de datos y en los datos fuera de la base de datos? ¿Cuál es el objetivo de punto de recuperación (RPO) de la solución?

La solución de Lokad cuenta con un diseño de protección continua de datos a través de la copia de seguridad incremental en vivo tanto de su almacén de eventos como de su fuente de contenido. Por lo tanto, podemos realizar PITR para cualquier momento dado (hasta el nivel de minutos).

Tenemos un RPO de 1 minuto para desastres a nivel de centro de datos, si los datos no se ven comprometidos. Logramos esto aprovechando las escrituras geográficamente redundantes de nuestro almacén de valores clave persistente. Si el almacén de valores clave se ve comprometido, Lokad se recupera de su almacenamiento de respaldo (mantenido lo más aislado posible de nuestros sistemas de producción), también alojado en una ubicación geográfica diferente. En este caso, tenemos un RPO de 12 horas.

3.10 ¿La solución es capaz de generar alertas de violación de integridad? ¿La solución tiene la capacidad de agregar o ampliar las comprobaciones de integridad según los requisitos?

Sí, aunque este tipo de problema refleja principalmente un diseño de software basado en una base de datos transaccional. La plataforma de Lokad no opera con una base de datos transaccional, sino con un almacén de eventos, adoptando un diseño de origen de eventos en lugar de uno relacional. Esto no elimina la necesidad de hacer cumplir la integridad de los datos, pero estas preocupaciones se abordan de otras formas.

En lo que respecta al procesamiento de los datos del cliente, Envision (DSL de Lokad) tiene amplias capacidades orientadas a verificar su calidad. A través de Envision, es posible verificar la integridad y generar alertas. Esta lógica se puede ampliar o modificar de la manera que el cliente considere apropiada.

3.11 ¿Se prueban periódicamente las copias de seguridad para garantizar la funcionalidad adecuada de la restauración de datos?

Sí. El diseño de origen de eventos de Lokad, combinado con su almacén de contenido direccionable, facilita mucho más las pruebas de la funcionalidad de copia de seguridad y restauración de datos que en la mayoría de los diseños convencionales que aprovechan bases de datos relacionales (como SQL).

Ver también Incidentes 3.7.

3.12 ¿Se prueban periódicamente los planes de recuperación ante desastres para garantizar la funcionalidad adecuada de la recuperación ante desastres?

Sí. La estrategia de implementación de Lokad aprovecha scripts automatizados de extremo a extremo, manteniendo deliberadamente muy pocas intervenciones humanas, siendo una notable excepción la capacidad de desencadenar una implementación completa de producción. Este enfoque altamente automatizado facilita las pruebas de la funcionalidad de recuperación ante desastres.

Ver Incidentes 3.8.

3.13 ¿Se puede realizar la recuperación para clientes individuales y/o entornos de clientes?

Sí. Nuestra herramienta interna admite la posibilidad de restaurar la cuenta de un cliente seleccionado (incluida la restauración de la cuenta/entorno a un momento dado). Sin embargo, considerando que la plataforma de Lokad en sí cuenta con amplias capacidades de versionado (por ejemplo, los scripts de Envision tienen versiones y las versiones anteriores son accesibles desde la aplicación), esta capacidad se utiliza rara vez.

3.14 ¿Los planes de copia de seguridad y recuperación ante desastres cumplen con los objetivos de tiempo de recuperación (RTO), objetivo de punto de recuperación (RPO) y requisitos de escenario de desastre (según lo definido y acordado con los respectivos clientes)?

Sí. El Objetivo de Tiempo de Recuperación (RTO) se referiría aquí a la cantidad de tiempo que la plataforma de Lokad podría estar teóricamente inactiva sin causar daños significativos al cliente, así como el tiempo dedicado a restaurar la plataforma y sus datos para que pueda reanudar las operaciones normales después de un incidente importante.

El RTO depende en gran medida de los detalles específicos de los procesos admitidos/proveídos por Lokad. Por ejemplo, un cliente que depende de Lokad para programar órdenes de compra mensuales en el extranjero puede tener un RTO de 1 semana. Por otro lado, un cliente que depende de Lokad para optimizar el envío diario de inventario desde un almacén a varias tiendas puede tener un RTO de 1 hora.

En la práctica, se pueden implementar diversas contingencias técnicas para mejorar sustancialmente el RTO (es decir, reducir el tiempo de inactividad teórico). Por ejemplo, las “decisiones de conmutación por error” se pueden calcular de antemano. Estas decisiones se pueden utilizar en caso de que la plataforma de Lokad no esté disponible. En comparación con las decisiones optimizadas “regulares”, las decisiones de conmutación por error pueden mostrar un rendimiento de suministro ligeramente degradado, dado que (por definición) no aprovecharían los datos más recientes y absolutos.

Para nuestras cuentas gestionadas, es responsabilidad del Supply Chain Scientist de Lokad elaborar conjuntamente un proceso, junto con los equipos operativos del cliente, que proporcione un alto RTO, pero también que garantice un impacto comercial mínimo en caso de incidente real. Desde nuestra perspectiva, este desafío es principalmente un problema de cadena de suministro en lugar de uno de TI.

Ver también Incidentes 3.9.

3.15 Si un defecto no se puede reproducir en el entorno de prueba, ¿puede Lokad verificar que el defecto ha ocurrido a partir de los registros y los datos de apoyo, y asegurarse de que el defecto se haya solucionado según el Acuerdo de Nivel de Servicio (SLA)?

Sí, los defectos se pueden reproducir en nuestros entornos. La reproducibilidad estricta de todos los estados de datos y todos los cálculos es un principio de diseño fundamental de la plataforma y la arquitectura de Lokad. Por ejemplo, el sistema de archivos dentro de la plataforma de Lokad está completamente versionado (como Git), precisamente para abordar esta preocupación.

Cabe señalar que los registros son más efectivos para solucionar problemas triviales, como el tiempo de inactividad del servidor. Cuando se trata de solucionar problemas complejos y defectos en un entorno de datos a gran escala, donde están involucrados terabytes de datos, los registros a menudo son insuficientes.

Por lo tanto, si bien Lokad mantiene y consulta registros cuando corresponde, no nos basamos en los registros para solucionar defectos o verificar que los defectos se hayan solucionado. En cambio, principalmente aprovechamos elecciones de diseño superiores para proporcionar una mayor visibilidad, trazabilidad y reproducibilidad.

Estas elecciones de diseño deliberadas nos permiten identificar, reproducir y solucionar defectos de una manera que no permitiría depender únicamente de los registros.

Consulte también Arquitectura de Lokad para obtener un desglose detallado de las varias elecciones de diseño clave que adoptamos para evitar clases enteras de problemas de software comunes.

3.16 ¿Mantiene registros de todas las solicitudes de servicio y llamadas de servicio (incluida la categoría de cada llamada) realizadas por la empresa cliente? ¿Los registros incluyen: la identidad de la persona que llama y la persona llamada; la naturaleza del error, problema o incidente informado; el tiempo de respuesta de Lokad; la disposición de la llamada de servicio; la resolución; los tiempos de resolución; y la disponibilidad del sistema?

Sí, la plataforma de Lokad tiene capacidades de gestión de tareas/tickets/incidentes que proporcionan los detalles mencionados.

En cuanto a las “resoluciones”, vale la pena señalar que la filosofía de la cadena de suministro cuantitativa de Lokad (QSC, por sus siglas en inglés) consiste en encontrar el compromiso más beneficioso desde el punto de vista financiero cuando se presenta un problema. QSC no es, técnicamente, un enfoque de “solución de problemas”, ya que los problemas de la cadena de suministro no son problemas que se “solucionan”, sino que se atenúan mediante la realización de compromisos financieramente informados.

En resumen, Lokad posee las herramientas y los procesos para resolver rápidamente “problemas sencillos” (como la caída del servidor) de manera directa. Cuando se trata de problemas más grandes y más importantes de la cadena de suministro (como la asignación de existencias en el comercio minorista o los problemas de reposición de inventario), estos suelen ser discusiones más abiertas y continuas con los clientes sobre qué compromisos maximizan su retorno de inversión.

4. Arquitectura

4.1 ¿Qué lenguajes de programación utilizan?

La plataforma de Lokad se desarrolla en C#, F# y TypeScript. La plataforma también cuenta con Envision (DSL de Lokad), que se utiliza para implementar las soluciones de cadena de suministro específicas del cliente.

4.2 ¿Qué conjunto de desarrollo utilizan?

Los equipos de ingeniería de software de Lokad utilizan Microsoft Visual Studio. Los equipos de científicos de la cadena de suministro utilizan la propia plataforma de Lokad, que cuenta con su propio conjunto de desarrollo.

4.3 ¿Qué sistema operativo admiten?

Lokad es una plataforma basada en web y admitimos todos los sistemas operativos que tienen acceso a un navegador web moderno (por ejemplo, Firefox). Internamente, la plataforma de Lokad es compatible tanto con Linux como con Microsoft Windows, aunque todos nuestros sistemas de producción se implementan en Linux (Ubuntu).

4.4 ¿Qué sistema de base de datos utilizan o admiten?

Lokad admite todos los sistemas de base de datos que pueden producir exportaciones de archivos planos. Esto incluye prácticamente todos los sistemas de base de datos del mercado, incluidos los modelos más antiguos. Internamente, Lokad no utiliza un sistema de base de datos, sino un almacén de clave-valor. En el momento de escribir esto (enero de 2023), utilizamos Blob Storage proporcionado por Microsoft Azure.

4.5 ¿Qué sistema de almacenamiento en caché utilizan?

Lokad ha desarrollado sus propios subsistemas de almacenamiento en caché en C#/.NET. Estos subsistemas están estrechamente integrados con el resto de la solución y no reflejan los sistemas de almacenamiento en caché tradicionales destinados principalmente a mitigar problemas de rendimiento con una base de datos relacional (que Lokad no tiene).

4.6 ¿Cómo maneja la solución los certificados?

Lokad aprovecha Let’s Encrypt a través de renovaciones automáticas de certificados.

4.7 ¿Cuáles son los requisitos técnicos para utilizar la solución?

El requisito técnico principal es un sistema de transacciones que lleve un registro del inventario. Además, es útil si el cliente tiene experiencia en la extracción de datos (como archivos planos) de sus sistemas transaccionales, pero esto ciertamente no es un requisito previo.

4.8 Enumere cualquier licencia de terceros adicional necesaria para operar la solución de Lokad (por ejemplo, SO, SQL,…).

N/A. Lokad no requiere ninguna licencia de terceros para operar. Existe una amplia variedad de herramientas de código abierto para admitir la integración de Lokad (es decir, archivos planos transferidos a través de FTPS o SFTP); por lo tanto, no se requiere ninguna licencia de terceros, ni siquiera indirectamente, para beneficiarse de la plataforma de Lokad.

4.9 ¿La aplicación requiere complementos del navegador o software especial?

Lokad es una aplicación web. No requiere complementos del navegador ni ningún software especial.

4.10 ¿Cuáles son las interfaces de entrada y salida de la aplicación?

La solución de Lokad ofrece una interfaz web, accesible a través de HTTPS, y protocolos de archivos, a saber, SFTP y FTPS.

4.11 ¿Cómo se asegura que no haya fugas de datos entre los inquilinos?

La solución de Lokad segrega los datos de los inquilinos a través de su propio diseño, lo que garantiza que no se produzcan fugas de datos (incluso accidentales). Además, todo el código enviado a producción se revisa entre pares, lo que proporciona una capa adicional de protección. Por último, dirigimos a los investigadores de seguridad (personas que realizan pruebas de penetración) para que investiguen específicamente la posibilidad de fugas de datos. Les damos acceso a varias cuentas de Lokad, en un entorno dedicado y completamente aislado que replica el de producción, para que puedan verificar agresivamente esta propiedad de nuestra plataforma.

4.12 ¿Se puede contenerizar la solución?

Sí, pero hay poco o ningún beneficio para que la plataforma de Lokad se contenerice. La contenerización aporta valor cuando hay dependencias complejas (por ejemplo, una base de datos transaccional, un sistema de almacenamiento en caché aislado, etc.). No utilizamos contenedores en producción o desarrollo, lo que mejora nuestra seguridad al eliminar clases enteras de vulnerabilidades. En su lugar, mantenemos la solución lo suficientemente simple como para que la implementación se pueda realizar incluso con pequeños scripts de shell.

4.13 ¿Se pueden desacoplar los componentes de la interfaz gráfica de usuario del backend?

Sí, los componentes de la interfaz gráfica de usuario (en este caso, las interfaces web) son independientes. Este diseño ayuda a lograr una mayor disponibilidad. Los usuarios finales pueden acceder a los paneles de control de su cuenta de Lokad incluso si una interrupción repentina afecta a uno de los otros subsistemas.

4.14 ¿La aplicación de Lokad admite funciones de localización (como cambiar el idioma)?

Sí, la aplicación admite funciones de localización. Todas las interfaces de usuario producidas por la plataforma de Lokad se pueden localizar en cualquier idioma. En particular, toda la pila tecnológica adopta UTF-8, para poder acomodar todos los conjuntos de caracteres que existen más allá del latino. En particular, cualquier interfaz de usuario producida por la plataforma de Lokad se puede relocalizar, después de la entrega, a otro idioma.

4.15 ¿Es posible que los usuarios finales actualicen o creen nuevas traducciones después de la entrega de los datos postprocesados de Lokad?

Sí, consulte la pregunta 4.14 anterior.

4.16 ¿Su sistema tiene una ayuda incorporada? Si es así, ¿en qué idioma(s)?

Sí, Lokad viene con una documentación pública muy extensa (en inglés). Sin embargo, el uso de la plataforma de Lokad implica la creación de interfaces de usuario personalizadas y nuestro proceso regular implica al menos dos formas de documentación o ayuda.

En primer lugar, los paneles creados dentro de la solución de Lokad están destinados a ser documentados contextualmente, directamente desde el propio panel. En particular, incluso tenemos una ficha de Markdown dedicada a la documentación enriquecida con texto. En segundo lugar, nuestros entregables incluyen un “Manual de Procedimientos Conjuntos”. En general, el manual proporciona un análisis detallado no solo de la mecánica de la solución, sino también de por qué se seleccionó cada elemento (y cómo satisface las necesidades específicas de la cadena de suministro del cliente).

4.17 ¿La aplicación web es responsive?

La aplicación web de Lokad, junto con sus materiales de soporte (como la documentación técnica), ha sido diseñada para ser responsive. Sin embargo, algunas capacidades avanzadas, como la edición de código, son impracticables en dispositivos móviles y/o tabletas. Por lo tanto, el diseño está destinado a maximizar la capacidad de respuesta para las actividades previstas que se llevan a cabo en PC y dispositivos más pequeños, respectivamente.

4.18 Si su sistema es una aplicación web, ¿qué navegador y versiones admite? ¿Cuál es su estándar mínimo de navegador de Internet?

Lokad es una aplicación web y admitimos los principales navegadores web “evergreen”, como Chrome, Firefox y Safari. No intentamos admitir navegadores antiguos por razones de seguridad, ya que admitir esos navegadores pone en peligro implícitamente a nuestro(s) cliente(s). En pocas palabras, un navegador vulnerable puede ser aprovechado por un actor malintencionado para extraer datos. Dicho esto, también somos bastante conservadores cuando se trata de nuevas capacidades del navegador. Como regla general, evitamos admitir cualquier capacidad del navegador que no haya sido adoptada por todos los principales navegadores web durante al menos 1 año.

4.19 Para aplicaciones móviles y de tabletas, ¿qué sistema operativo (y versiones) admite Lokad?

N/A. Como Lokad es una aplicación web servida como SaaS, nuestros clientes no se preocupan por el soporte del sistema operativo. Internamente, Lokad se desarrolla en Windows, mientras que todo nuestro entorno de producción alojado en la nube está en Linux. Por lo tanto, tenemos bastante confianza en la amplia portabilidad de la solución de Lokad. Aunque no sentimos ninguna necesidad presente de cambiar esta configuración, si se presenta evidencia válida, nos adaptaremos en consecuencia.

4.20 ¿Puede la aplicación web de Lokad proporcionar notificaciones para los usuarios finales? Si es así, ¿qué tecnología/protocolo se utiliza?

Sí, Lokad tiene la capacidad de enviar notificaciones a través de notificaciones de gancho HTTP programables. Estos ganchos se pueden aprovechar para utilizar un sistema de terceros, que a menudo ya está en su lugar en la empresa del cliente, para enviar una notificación por correo electrónico o cualquier otro tipo de notificación que se considere apropiada. Los ganchos también se utilizan típicamente para señalar la disponibilidad de datos que se pueden recuperar de la plataforma de Lokad a través de SFTP o FTPS.

4.21 ¿Hay elementos compartidos en la solución que son comunes a todos los clientes (como funciones de monitoreo, soluciones de copia de seguridad o gestión de parches, etc.)?

Sí, como Lokad es una aplicación multiinquilino, las capacidades a nivel de infraestructura se comparten entre/entre inquilinos, es decir, cuentas de clientes. Esto incluye el monitoreo de tiempo de actividad, rendimiento y, por razones de seguridad, copia de seguridad, gestión de parches, actualización, etc.

4.22 ¿Permite la solución la funcionalidad de mensajería con múltiples destinos (es decir, la capacidad de enviar un mensaje a más de un destinatario o aplicación)?

La plataforma de Lokad no opera con mensajes. Sin embargo, proporcionamos capacidades de HTTP-hook que se pueden utilizar para generar notificaciones de mensajes arbitrariamente complejas, típicamente a través de sistemas de terceros de bajo costo. Estas notificaciones a veces son utilizadas por los equipos de la cadena de suministro para monitorear la finalización oportuna de lotes de cálculos críticos para la misión con la plataforma de Lokad.

4.23 ¿Todos los sistemas y componentes críticos utilizan la misma fuente de tiempo (NTP) o sincronizan sus relojes de alguna otra manera confiable?

Sí. Lokad utiliza el servicio NTP predeterminado que viene con Ubuntu - ntp.ubuntu.com. Más específicamente, se ejecuta ntpd como el servicio de sincronización de tiempo, que se sincroniza con una fuente de tiempo NTP externa a la que se accede a través de la red.

4.24 ¿Existe una lista de inventario de activos o una base de datos de gestión de configuración (CMDB)?

Sí, tenemos un software de gestión de activos de TI para respaldar nuestros procesos. Esta plataforma nos ayuda a mantener una lista de inventario de activos completa y actúa como nuestra base de datos de gestión de configuración (CMDB). A través de este sistema, podemos realizar un seguimiento, administrar y asignar eficientemente activos de hardware y software en toda la organización. Nuestros equipos tienen la capacidad de identificar rápidamente el estado, la ubicación y la configuración de cualquier activo, lo que garantiza respuestas rápidas a cambios, actualizaciones o posibles problemas.

Además, nuestra herramienta proporciona funcionalidades que permiten una gestión detallada del ciclo de vida, asegurando que los activos se cataloguen con precisión desde la adquisición hasta el final de su vida útil. Las capacidades de auditoría automatizadas, junto con características detalladas de informes, garantizan que mantengamos una visibilidad y control completos sobre nuestro entorno de TI, facilitando el cumplimiento y la asignación eficiente de recursos.

4.25 ¿Se termina cada conexión a una red externa en un firewall (por ejemplo, Internet, redes de socios)?

No, no terminamos cada conexión a una red externa en un firewall, ya sea Internet o redes de socios. Nuestra decisión se basa en preocupaciones del mundo real sobre la efectividad e implicaciones de tales medidas.

Desde nuestra perspectiva, si bien los firewalls suelen verse como una defensa de primera línea, paradójicamente pueden ampliar la superficie de ataque. Cuantos más componentes y sistemas integramos, más puntos débiles potenciales introducimos. Los firewalls, debido a su naturaleza, funcionan como procesos de alto privilegio. Esto significa que se convierten en objetivos principales de los ciberataques y, cuando se ven comprometidos, los resultados pueden ser devastadores. Un caso ilustrativo es el ataque de SolarWinds, donde los propios sistemas destinados a salvaguardar la información fueron explotados, lo que llevó a brechas significativas.

Además, la presencia de firewalls estrictos puede ser contraproducente en un sentido práctico. Nuestra experiencia ha demostrado que dichos sistemas a menudo incentivan a los empleados a buscar medios alternativos para acceder y compartir información. Esto suele implicar eludir por completo la red corporativa (impidiendo así cualquier monitoreo), utilizando conexiones personales 4G o 5G desde sus propios dispositivos. Tales prácticas aumentan inadvertidamente el riesgo de brechas de seguridad y filtraciones de datos.

Por lo tanto, si bien estamos profundamente comprometidos con la seguridad, nuestro enfoque es holístico y se basa en consideraciones prácticas en lugar de depender únicamente de medidas tradicionales.

4.26 ¿La red tiene un entorno de DMZ que transmite, procesa o almacena sistemas críticos (como servidores web, DNS, servicios de directorio y acceso remoto), así como datos de clientes?

No, Lokad no utiliza un entorno de DMZ tradicional dentro de nuestra red para transmitir, procesar o almacenar sistemas críticos y datos de clientes. En su lugar, hemos adoptado un enfoque de confianza cero para la seguridad de la red.

Este modelo no se basa en DMZ, sino que opera según el principio de “nunca confiar, siempre verificar”. Cada solicitud de acceso se valida y autentica, independientemente de su origen, ya sea desde dentro o fuera de la organización.

Esto garantiza una postura de seguridad más sólida y holística, ya que no depende de defensas perimetrales como una DMZ, sino que se centra en asegurar cada punto de acceso individual y transacción de datos. Creemos que el enfoque de confianza cero ofrece una protección superior para nuestros sistemas críticos y datos de clientes.