*

Negocios

Esclavitud 2.0: cómo no quedar "pegado" a tu proveedor de tecnología

Al momento de elegir una tecnología para desarrollar un proyecto, siempre hay letra chica. Elegir el proveedor equivocado puede costarles a las empresas su autonomía. Qué es el concepto de lock-in y por qué está en el corazón del “costo oculto” en cualquier proyecto IT.

Por PABLO LABARTA - 05 de Septiembre 2018
Esclavitud 2.0: cómo no quedar "pegado" a tu proveedor de tecnología

El acelerado desarrollo tecnológico que predomina hoy en día es el resultado de dos factores principales: las nuevas formas de colaboración y la integración de servicios que permiten que cada empresa haga lo que mejor sabe hacer, dejándoles los problemas ajenos a su core de negocio a terceros. Pero este cambio en las formas de producción, que le da mucha velocidad al ecosistema IT, requiere que las empresas entreguen un activo preciado: su independencia.

El problema se sintetiza en el concepto de “lock-in”, la situación de dependencia hacia un proveedor o una tecnología que surge cuando la empresa no puede elegir otra opción debido a que los costos de migración se lo impiden. Los precios de moverse de una plataforma, infraestructura o ecosistema a otro están asociados principalmente a las diferencias tecnológicas entre ellos, puede variar el lenguaje de programación, el formato en el cual se almacenan los archivos e incluso la forma de comunicarse, entre otras causas. Y no siempre es algo “accidental”: a veces la práctica es parte de la estrategia de negocios de los vendors para retener a sus clientes, aun cuando sus servicios no son los mejores ni los más económicos del mercado. Ahora, impulsado por la velocidad de los cambios, mantener las opciones abiertas es una necesidad y el lock-in, una preocupación para todos.

 

Cada quien con sus códigos

El primer caso de lock-in se da cuando el operador no tiene el control sobre la tecnología que usa. Esto puede ser debido a cuestiones legales que le impiden modificarla —como patentes y licencias— o impedimentos técnicos —como procesos de cifrado o simplemente porque su funcionamiento es secreto—. Las razones para elegirlos exceden, en algunos casos, sus contraindicaciones: los “enlatados” y los paquetes de soluciones también resultan tentadores porque pueden ayudar a reducir costos, requiriendo de una evaluación en cada caso. Según explica Gustavo Guaragna, CEO de la empresa de soluciones informáticas Snoop Consulting, es una decisión de negocios que debe ser evaluada junto al equipo técnico. “Caer en una situación de lock-in no siempre es algo malo, pero es necesario medir su impacto económico y ver si realmente conviene sacrificar flexibilidad para reducir costos”, señala el ejecutivo.

Todos los años Snoop realiza, al igual que grupos como Gartner, estudios del ecosistema y las distintas plataformas para evaluar su adopción actual y futura. Así, recomiendan no evaluar vendors, sino cada uno de sus productos. “Es una estrategia que puede perjudicar la relación con los proveedores, pero el producto requiere tomar las decisiones según la necesidad de su arquitectura. Así, en un momento decidimos no trabajar con la plataforma mobile de Microsoft, pero apostamos a fondo por Azure y Business Intelligence”, cuenta Guaragna.

Algo similar ocurre a nivel infraestructura: aun en una época donde todo va a la nube, los principales vendors, Google, Microsoft y Amazon, tienen sus diferencias e implementan estrategias para ganar clientes. “Hoy en día, con las plataformas como servicio, hay que ver cómo se consumen las API, cómo es la interacción con estos servicios. Porque si no es muy estándar, es recomendable evaluar cómo habría que hacer una extracción en caso de que sea necesario cambiar”, detalla el CEO de Snoop.

A esta recomendación de tener un “plan B” se le suma que ahora también hay tecnologías que permiten simplificar y reducir los costos de las migraciones. Olivia Cesio, directora Comercial de la software factory Wolox para América latina, destaca que el surgimiento de estándares Open Source está cambiando el panorama. “Antes no había soluciones que faciliten las migraciones, pero ahora hay containers y Kubernetes que permiten que, si viene un proveedor nuevo, podés hacer una transición sin mucho esfuerzo”, explica. Esto permite crear una capa que separa la aplicación de la infraestructura, reduciendo el trabajo de reescritura.

Kubernetes es una tecnología que surgió dentro de Google, pero que la empresa luego decidió abrir para acelerar su adopción. Jorge Giraldo, director de Google Cloud para América Latina, explica que hoy las empresas necesitan más de un proveedor, pero que también hay oportunidades para ofrecerles servicios que les faciliten la gestión de su infraestructura. “Ahora no solo tienen múltiples proveedores, sino que algunas incluso están pasando sus sistemas críticos a la nube, algo para lo cual es necesario tener más de un proveedor. Entonces optamos por brindar las herramientas para que los clientes puedan administrar estos entornos multi Cloud”, detalla el ejecutivo latinoamericano. Aunque también agrega que otra de las razones para ofrecer esta clase de plataformas es la convivencia entre la nube y los sistemas on premise que siguen sosteniendo parte del negocio. “Todavía resulta extraño para algunos desarrolladores entender que ofrecemos herramientas que les permiten irse de nuestra nube e instalarse en otra”, concluye.

 

Jaulas abiertas

Pero la tecnología propietaria no es la “mala de la película”, y la Open Source tampoco la panacea. Las herramientas de código abierto y uso libre tienen una mayor aceptación entre las empresas, o al menos estas suelen aparentar ser menos riesgosas. “Si se necesitan licencias, puede pasar que estas son del proveedor y al migrar, se las pierde. Es por esto que recomendamos Open Source”, argumenta Cesio. La preocupación que generaba implementar React, una librería para crear interfaces de usuario desarrollada por Facebook, es un claro ejemplo. Esta tecnología desarrollada por la empresa de Mark Zuckerberg fue liberada en 2013 bajo una licencia Apache 2.0, pero en 2014 la cambiaron e incluyeron una cláusula que le negaba a sus usuarios la posibilidad de demandar a Facebook, mientras que la red social podía iniciar acciones legales contra estos sin problemas. Esto hizo que las grandes empresas o aquellas startups que se enfocan en verticales de interés para la compañía de Zuckerberg le escaparan a la librería. “Recién en 2017 lanzaron React bajo la licencia MIT para que los usuarios se sientan cómodos y se acabaron esta clase de peleas con los clientes”, cuenta la directora de Wolox.

Lo que sucede es que no alcanza con poder usar la tecnología, sino que es fundamental poder trabajarla. “Lo primero que necesitamos saber como desarrolladores que trabajamos para terceros es si el cliente tiene un equipo propio, si va a estar interactuando con el nuestro o si planean tercerizar todo”, destaca Cesio. Es que, aun si se usan tecnologías Open Source, sus clientes pueden caer en una situación de dependencia porque no cuentan con las personas necesarias para luego continuar manteniendo el producto por su cuenta. “Por cuestiones como esta, hay proyectos donde una tecnología conviene, pero si el cliente no cuenta con los necesarios desarrolladores puede causar más problemas de los que resuelve. Entonces, como proveedor, tenés que adaptarte a su necesidad”, sintetiza. Entonces, no solo se trata de elegir un stack tecnológico que cumpla con los requerimientos de negocio, sino que también cuente con una oferta de desarrolladores lo suficientemente amplia como para que resulte sencillo conseguirlos. De lo contrario se genera otra clase de lock-in en el cual el cliente depende de la software factory o de la empresa que le desarrolló la solución porque ellos no saben continuar con el proyecto.

Si bien nadie piensa que se va a separar cuando se casa, tan importante como planear cómo entrar es planear cómo salir. Aun cuando se trate de tecnologías abiertas, sistemas agnósticos y desarrollos a medida, voltear la cabeza para ver qué tan lejos está la puerta puede ser lo que defina si el negocio se expande o si se queda atrapado.

 

Los consumidores también

El lock-in no solo es un problema del mundo del desarrollo, los consumidores también lo sufren cuando los fabricantes de equipos y aplicaciones deciden crear ecosistemas cerrados para retenerlos. Uno de los casos más claros es el modelo Apple: hardware y software son inseparables, al punto que pasarse a Windows u Android luego de algunos años trabajando en un entorno MacOS y usando iOS en el teléfono puede ocasionar dolores de cabeza. En el caso de su teléfono insignia, el iPhone, no puede ser cargado con cualquier cable, se necesita uno con una ficha Lightning, un diseño propietario de la marca. A su vez, iOS limita a sus usuarios a usar las aplicaciones disponibles en la App Store —cuya oferta se encuentra estrictamente regulada por Apple— y donde la mayoría de las aplicaciones suelen ser pagas.

Todo esto significa que si una persona decide que quiere cambiar su teléfono por un smartphone con Android, no solo va a tener que cambiar el equipo, sino que también va a tener que comprar nuevos accesorios, encontrar nuevas aplicaciones con las cuales manejarse y probablemente pagar nuevamente por aquellas que tenía en iOS, pero quiere seguir usando. Con otros gadgets menos techie sucede lo mismo: las cafeteras de marca solo funcionan con su propia línea de cápsulas, modelo que copiaron de las impresoras. Y ambas suelen reservarse el derecho de cancelar la garantía si se usan con insumos “no oficiales”.

-- 

Nota publicada en la edición 251 (agosto/2018) de INFOTECHNOLOGY.



¿Te gustó la nota?

Comparte tus comentarios

Sé el primero en comentar

Notas Relacionadas