*

Negocios

“La tecnología obsoleta sigue siendo un problema en las empresas”

Infotechnology dialogó con el máximo responsable de la tecnología de la plataforma Despegar.com sobre el ciclo de vida de la tecnología. ¿Están los gadgets y la tecnología corporativa quedando viejos más rápido que antes?

Por Matías Castro - 28 de Marzo 2017
“La tecnología obsoleta sigue siendo un problema en las empresas”

A propósito del vertiginoso recambio tecnológico, impulsado por la reducción en los aranceles aduaneros para la importación de computadoras de distinto tipo, hablamos con Carlos Álvarez, CIO de la plataforma Despegar.com. En el marco de la publicación dedica al tema de la obsolescencia en tecnología  en el último número de la revista Infotechnology, el especialista se refirió a la evolución y los desafíos de la obsolescencia técnica, el rol del gerente IT en la empresa y cómo se puede innovar y ahorrar recurriendo al open source.

 

 ¿Cómo evolucionó la obsolescencia en los últimos años, en el rubro de la tecnología? ¿Hay más, menos, lo mismo?

Primero dejame definir el tiempo de “últimos años”, que voy a limitar a mi experiencia que es de alrededor de 20 años desde que comencé a trabajar en IT. Por un lado, el software parece durar cada vez menos, pero por el otro las arquitecturas de microservicios bien planeadas hacen que la actualización sea más sencilla y ágil. La obsolescencia sigue siendo un problema donde se depende de soluciones propietarias monolíticas, el ERP por caso, pero la evolución a arquitecturas de microservicios hacen que la obsolescencia del software duela menos: los reemplazos son puntuales, indoloros para el resto del ecosistema y realizables en fases. En cambio, si estoy obligado a reemplazar una solución monolítica propietaria el proceso es mucho más riesgoso y la estrategia en fases es mucho más complicada de implementar. Si esa solución es propietaria se da además el paraíso del proveedor: el vendor lock-in.

Con respecto al hardware, en despegar.com hemos decidido correr en cloud o en commodity hardware con sistemas operativos open source. Casi todo el stack casi sin excepción es abierto y la decisión nos evita el dolor de cabeza de la obsolescencia del hardware: en la nube pública el recambio del hardware es algo resuelto por el proveedor y el commodity hardware corriendo arquitecturas escalables horizontalmente se usa hasta que se rompe y ahí se tira. La teoría dice que en algún momento el hardware se debería volver energéticamente antieconómico, pero usualmente se rompe antes.

 

¿Acompaña el marco legal, político y social este cambio?

Afortunadamente, el marco legal y político es cada vez menos un problema: la mejora de las comunicaciones y la nube pública hace que cada vez se dependa menos de decisiones burocráticas para actualizar el software y el hardware. Imagino lo desesperante que puede ser necesitar un nuevo equipo para correr un sistema de misión crítica para el negocio y enfrentarse a un sinfín de burócratas aduaneros, pero afortunadamente eso es cada vez menos necesario.

Me costaría más definir el marco social, pero sí me gustaría que en la formación de los profesionales jóvenes se notara un foco en las cuestiones conceptuales subyacentes y un ejercicio en la formación continua y el aprendizaje a lo largo de toda la vida.

 

Hace algunos años la European Economic and Social Committee (EESC) está particularmente preocupada por la cuestión de la obsolescencia artificial o programada. ¿Existe realmente la obsolescencia programada en las empresas de tecnología?

 

De alguna manera, existe la obsolescencia programada, y creo que está relacionada con la idea de productos mínimos viables: a veces soportamos algo en una solución que sabemos tiene un horizonte de escalabilidad que la hará obsoleta en un futuro cercano.

Seguramente sí existe la obsolescencia artificial, donde no necesito migrar a una nueva versión de una solución pero debo hacerlo porque un proveedor deja de soportar la versión que estoy corriendo. Además, estas actualizaciones de un componente se llevan puesto todo el resto del stack. Las bases de datos, sistemas operativos, hardware, etcétera.

Para ser justos, además de ser una estrategia de ventas, la pérdida de soporte de versiones viejas, algo que empuja a la obsolescencia, tiene lógica: es antieconómico para el vendor mantener muchas versiones de un software, backportando patches y actualizaciones. Lo mejor que se puede hacer para evitar ser una víctima de la obsolescencia artificial es usar open source, interfaces basadas en estándares abiertos y arquitecturas orientadas a microservicios siempre que sea posible para manejar los tiempos con más libertad y flexibilidad.

 

¿Cuál es la relación entre innovación y obsolescencia?

Muchas veces la innovación genera obsolescencia real: evitaré dar nombres, pero imagínate que las mejoras en cierta tecnología open source hace obsoleta, por innecesariamente cara y compleja, una solución de almacenamiento propietaria, y no porque tenga más features, sino porque tiene menos, es más sencilla y de propósito más específico.

Muchas veces la innovación es un proceso de quitar features, no de agregarlos, para hacer el producto más accesible a una parte del mercado al que no llegaría de otro modo o permitiendo ahorros de costos a todo el mercado. Este proceso de innovación vuelve obsoletas soluciones más complejas e integradas.

 

Desde algunos sectores aseguran que en el mercado de tecnología se acostumbra a comprar y desechar demasiado rápido productos y servicios, y que esto genera un incentivo para que los proveedores innoven poco pero lancen muchos productos con mínimos cambios o mejoras. ¿Qué opinión merece esto?

 

Yo no sería tan duro con nosotros mismos: la velocidad de cambio muchas veces tiene que ver con la propia experimentación y el error inherente a una industria que, aún, está naciendo y explorando sus posibilidades.

Es cierto que este contexto es tierra fértil para las modas irracionales y la sobrefeaturización de ciertos componentes, pero creo que es porque aún la industria sufre cambios rápidos debido a su inmadurez. La sobreabundancia de features de utilidad poco clara es algo que veo con más frecuencia que los existencia de nuevos productos con mínimos cambios, lo cual tampoco es para desesperar: algunos de esos features pueden ser la base de the next big thing. En 2006 nos preguntamos por qué Amazon nos permite crear virtuales con una API… ¿para qué? que utilidad tiene?

 

Una reciente (2015) normativa en Francia quiere que los fabricantes de software y hardware, al igual que productos de línea blanca, identifiquen un tiempo estimado de vida útil de sus productos. ¿Qué opinión merece esta medida? ¿es una aceptación tácita de que los productores “juegan” un poco con los tiempo de uso estimados?

Francamente no me gusta: para calcular un tiempo estimado de vida útil del software antes de conocer el entorno donde será utilizado hay que anclar tantas variables que la ‘estimación’ va a ser irreal. No me imagino como podría saber una agencia gubernamental que el appliance que voy a comprar para protegerme de, por ejemplo, denegaciones de servicio, tendrá una vida útil de determinado tiempo. Tal vez sí tenga sentido que el proveedor explicite tiempos de soporte comprometidos o cuanto piensa tardar en desoportar la versión que estoy comprando (cosa que usualmente se hace), pero poco más.

 

 

Pensando en el mundo corporativo,  ¿cuál es el tiempo de uso promedio de un sistema de gestión IT?

En nuestro caso, de tres a cinco años. A veces un poco más y en casos excepcionales puede llegar a ser menos de un año.

 

¿A qué se debe mayormente los cambios?

A veces se debe a que el negocio que soporta el sistema creció más de lo previsto y el mismo ya no lo soporta. Otras veces, luego de muchos años de modificaciones, el sistema ha quedado tan degradado en términos de calidad técnica que conviene reemplazarlo enteramente. En sistemas propietarios puede llegar a ser casi la decisión del proveedor, pero en despegar.com evitamos esto tanto como sea posible.

 

¿Cómo son los costos de adaptación cuando un proveedor decide renovar sus servicios y, por caso, dejar de dar soporte?

Pueden llegar a ser procesos traumáticos si se planificó una arquitectura muy cerrada y basada en componentes propietarios. Si la arquitectura de la solución está basada en partes intercambiables facilmente, es un proceso manejable y que no debería entorpecer la operación.

 

 ¿Cuáles son los equipos o programas de software que más recambio necesitan debido a quedarse obsoletos?

El software de sistemas comerciales que soportan negocios muy cambiantes y que, por lo tanto sufren muchos cambios en poco tiempo. Como decía antes, el uso de commodity hardware y nube pública hace que no tengamos que sufrir demasiado la obsolescencia de hardware.

 

¿Cómo ve el cliente corporativo IT la cuestión de la obsolescencia tecnológica?

En despegar.com la tecnología tiene un papel central, somos una empresa de tecnología. La cuestión de la obsolescencia está enmarcada en una regla más general que dice que nosotros siempre tenemos que poder actuar sobre los componentes de nuestro stack sin depender de la acción de un proveedor. No significa que no tengamos proveedores, sino que tenemos que no depender de ellos para actuar llegado el caso. Esta regla de hierro en lo que respecta al stack del sitio y las herramientas expuestas publicamente tiene que ver con que para nosotros la disponibilidad del sitio es directamente la fuente de nuestro revenue.

Por supuesto que hay grises y hay lugares donde la regla se cumple más firmemente que otros, no hacemos nuestros propios switches, por ejemplo, pero el enfoque de la independencia nos permite tener una arquitectura donde la obsolescencia planificada por un proveedor no nos comprometa la operación ni nos altere necesariamente el pipeline de desarrollo de nuestro producto.

 



¿Te gustó la nota?

Comparte tus comentarios

Sé el primero en comentar

Notas Relacionadas