Cómo sobrevivir al software “Enterprise”

Hace poco me sonreía con una viñeta cómica que presentaba el concepto de “Programador Orientado a Google” en referencia a aquellos quienes han adquirido la mayor parte de sus conocimientos por su propia cuenta buscando Internet. Conozco no pocos programadores de esta clase, un puñado de ellos me parecen realmente sobresalientes. No obstante, la industria de software que se ve en Google, como toda la WWW en sí misma, es sólo la punta del iceberg. Este post me ha quedado algo largo y plúmbeo en comparación con las batallitas que suelo narrar. Pero si el lector es informático, o sufrido usuario de informática, le ayudará a reflexionar sobre cosas que posiblemente ya sabe aunque no se haya dado cuenta.

¿Qué caracteriza al software “Enterprise”?

Para los que no estén familiarizados con la historia, el Software Enterprise es algo demoníaco. Es tan pernicioso que se generó un movimiento cultural mundial, el Software Libre, en su contra. Y, sin embargo, el software enterprise también es necesario para el mantenimiento de la industria, incluso la industria del Software Libre. Aunque la innovación la encabeza el software libre, gran parte del dinero que nutre dicha innovación sale de empresas de software privativo ya sea on premise o SaaS. Y los algoritmos más avanzados en inteligencia artificial, machine learning y aplicaciones militares siguen estando sólo al alcance de unos pocos ojos.

Ahora la moda es publicar código en Github (benditos aquellos años 2003-2005 en los que estábamos en el top 10 de SourceForge con nuestro CRM libre hipergate :D). Pero la mayoría de los informáticos no hacen carrera publicando en Github ni sumando medallas en HackerRank. Por consiguiente, necesitan habilidades diferentes de las del Programador Orientado a Google que se caracterizan por lo siguiente:

1. La documentación es comparativamente paupérrima. No tanto por los manuales en sí mismos sino por la imposibilidad de consultar en Stackoverflow cómo se hace esto o aquello. Incluso los ISVs más importantes como IBM, Oracle y SAP tienen lagunas enormes en su documentación. Tampoco existe una comunidad de usuarios como tal, sino que se depende del soporte técnico del fabricante, el cual es caro, lento y a menudo con menos conocimientos prácticos que el cliente que está sufriendo en sus carnes la puesta en producción.

2. Los módulos son cajas negras. No se puede mirar dentro de ellos para ver qué están haciendo. Si no funcionan bien poco se puede hacer para soslayar el problema.

3. El programa de instalación no es algo a lo que le hayan prestado mucha atención. Hay algunas excepciones, creo que la más notoria que conozco eran los instaladores de Panda, por la dificultad excepcional de instalar un antivirus. Pero el instalador no suele considerarse un componente prioritario. Es por eso que empresas como Bitnami han tenido tanto éxito externalizando la función de instalación. A los desarrolladores normalmente se les da una máquina virtual con todo el entorno preinstalado pero no es fácil replicar todo un ecosistema empresarial en local, por consiguiente, pocas veces se puede desarrollar en remoto sino que hay que trabajar de cuerpo presente conectado a las redes internas del cliente.

4. Los expertos escasean. Debido a la dificultad para autoformarse, sólo la gente que ha trabajado en proyectos reales tiene los conocimientos necesarios.

5. El control de versiones es propietario. En el software enterprise muchas veces se programa con un lenguaje de scripting que corre sobre la plataforma privativa. Es frecuente que la plataforma no esté integrada con un sistema de control de versiones estándar como Git o Subversion.

6. Puede ser difícil hacer TDD. Muchas plataformas no incorporan un marco idóneo para el diseño dirigido por tests. Hay que instrumertarlo por fuera con Selenium o alguna otra herramienta.

7. Los componentes están pensados para integrarse en arquitecturas existentes. Esto implica que existirán piezas de las que les gustan a los administradores de sistemas, como single sign-on o sistemas de monitorización. También implica que el número de novísimas librerías “alienígenas” es menor debido a que a los técnicos del cliente no les suele gustar, y con razón, tener que mantener tecnologías de las que son totalmente desconocedores además de ser cuestionables en estabilidad, seguridad y rendimiento debido a su novedad. Ciertamente es posible encontrar piezas de Python 3 escondidas en lo profundo de la aplicación Core Java más recalcitrante, pero no suele ser la tónica que las grandes empresas sean adoptadores tempranos de tecnología excepto en proyecto tácticos con los que pretenden ganar una ventaja competitiva.

¿Qué tener en cuenta a la hora de producir software enterprise?

Como consecuencia de los puntos anteriores, conviene tomar en consideración que:

1. La especificación no puede contener nada que no esté en la documentación. El cliente no puede escribir la clase de Carta a los Reyes Magos tradicional en un proyecto de desarrollo a medida sobre Software Libre. Sólo puede pedir lo que se pueda encontrar en la documentación, pues el nivel de esfuerzo para hacer cualquier otra cosa variará desde titánico a imposible según el caso.

2. Los usuarios tienen que aprender a usar el software. Y no al revés. Quiero decir, cuando se va cambiando su comportamiento del software para adaptarlo a lo que los usuarios esperan que haga.

3. La instalación pueden convenir encargársela al ISV. Así como la actualización de versiones y el desarrollo de plug-ins estrechamente acoplados con el sistema principal.

4. Hay que incluir programas de formación para desarrolladores en la planificación. No se puede conjeturar que habrá en el mercado consultores disponibles. Puede que si, o puede que no. Por consiguiente, lo más prudente es pagar por la formación previa de todos los que vayan a desarrollar sobre la plataforma.

5. Hay que hacer el control de cambios a la antigua usanza. Aunque casi todas las herramientas enterprise proporcionan algún tipo de gestión de versiones, en muchas de ellas no existe una forma sencilla de trazar los commits o revertir un cambio puntual.

6. Conviene sobredimensionar los servidores. Muchas de las aplicaciones enterprise son bastante pesadas, sobre todo en consumo de memoria porque suelen hacer uso de un número muy considerable de librerías. Además, debido a la opacidad sobre el funcionamiento interno de los módulos es difícil hacer optimizaciones en el caso de que el rendimiento no sea el deseado.

¿Cómo influye el entorno organizativo?

Además de la naturaleza particular del software enterprise, hay que tener en cuenta el ecosistema de departamentos que coexisten en una gran empresa donde cada incumbente tiene intereses diferentes de los demás.

1. Patrocinio directivo. Según el capítulo primero de cualquier libro de gestión de proyectos, nada sale adelante sin la sponsorización de la alta dirección. El soporte de alto nivel ejecutivo sirve para garantizar que se mantendrán los recursos humanos, físicos y monetarios asignados al proyectos. Pero cuidado porque el soporte ejecutivo también puede ser una manzana envenenada por tres motivos: a) los miembros del consejo de administración no siempre actúan como una piña sino que pueden usar los proyectos para atacarse unos a otros, b) los altos mandos rara vez pueden defender a los operativos de las malas prácticas de los mandos intermedios esencialmente porque no es fácil reemplazar a los mandos intermedios indeseables, y c) cuanto más apoyo ejecutivo -y por ende dinero- recibe un proyecto más visible se vuelve a los ojos de los Nazgull de otras empresas.

2. Dedicación del staff del cliente. A menudo el staff del cliente se encuentra en una situación de sobrecarga laboral en la cual debe por una parte colaborar con los desarrolladores en la definición y validación de nuevos sistemas, y por otra seguir sacando adelante su trabajo diario habitual.

3. Procesos organizacionales. Cualquier empresa que lleva sufientes años en el mercado probablemente ha invertido una gran cantidad de esfuerzo en definir y mejorar sus procesos hasta el punto de que se han quedado grabados de forma indeleble en la mente de los usuarios. Los procesos de cambio organizacional son, en general, muy difíciles y llevan años cuando no lustros de completar, incluso muchas empresas acaban fuera del mercado antes de ser capaces de cambiar.

4. Dispersión geográfica. Ni el SaaS más puro para empresas puede librarse de al menos un recurso que se necesita de forma casi lineal con respecto al crecimiento de la base de usuarios: el soporte. Muchos pequeños proveedores de software no están preparados para instalar su producto en grandes empresas aunque el producto sea idóneo y funcione bien carecen de la capacidad para movilizar suficientes recursos de postventa. Si las sedes del cliente están geográficamente dispersas el esfuerzo en formación y soporte se incrementa todavía más. No quiero sugerir con lo anterior que el software como servicio no suponga ninguna diferencia, sí la supone, por ejemplo, uno de los factores claves del éxito de Salesforce fué su capacidad diferencial para desplegar apliaciones de CRM para equipos dispersos.

5. Normativas y KPI. En una gran empresa cada departamento tiene sus propias normativas y Key Point Indicators en los que basan sus métricas de eficiencia y cumplimiento de objetivos. Aunque el software tenga una misión global, para alcanzarla todavía necesita cumplir con una larga lista de requisitos burocráticos intermedios.

¿Cómo influye la arquitectura técnica?

No es posible, en general, llegar a una gran empresa y pretender que adopte el último grito en tecnología sólo porque sea teóricamente disruptiva. Algunas veces pasa, y ciertamente en los departamentos web hay bastante libertad para incorporar novedades, pero simplemente no se puede sacar algo de una chistera y que el cliente lo use porque es “mágico”. Los arquitectos de software en los clientes piensan de forma holística en términos de plataformas interoperables: ¿Cuánto me costará adoptar esta plataforma? ¿Tengo a gente formada? ¿Cómo haré el mantenimiento diario de sistemas? ¿Qué pasa si algo funciona de forma defectuosa? ¿Cómo voy a comunicar esta plataforma con aquella? ¿Cuantos años puedo usarla antes de que esté obsoleta?

La SEGURIDAD suele ser una característica deficiente en casi todo el software que se instala en las empresas. Además normalmente hay bastantes restricciones de acceso. Es frecuente que los ordenadores desde los que se ejecutan las aplicaciones empresariales tengan severamente restringido el acceso a Internet (o ningún acceso a Internet). Incluso dentro de la red interna de la empresa es probable que una aplicaciones no “vean” a otras. La electrónica de red, por cierto, puede jugar muy malas pasadas en una red empresarial porque la situación típica consiste en centenares de usuarios enviando correos ballena y moviendo archivos diplodocus sobre una infraestructura física que puede tener hasta una década de antigueadad. En una empresa es muy habitual que el rendimiento de una apliación se vea degradado porque otra aplicación está compitiendo por los mismos recursos (casi siempre la red). Por último, para las aplicaciones que trabajan con los datos más sensibles todo tiene que funcionar con certificados y protocolos seguros que garanticen que la información en tránsito no ha sido espiada ni alterada en modo alguno.

Otra regla del dedo gordo es que no quieres que tu software tenga que llamar a ningún otro sistema. Siempre hay que pelear a muerte que sean los otros sistemas los que le llaman a uno. Esto es debido a que siempre es posible monitorizar las llamadas entrantes y el software propio. Pero si se produce un mal funcionamiento los sistemas de terceros son una caja negra con la que se pueden tardar días o semanas en diagnoticar cualquier cosa tras una discusión interminable con el otro sobre quién tiene la culpa de qué.

¿Cómo diseñar software enterprise?

Los requisitos a priori para que un producto de software enterprise sea vendible son una consecuencia de todos los puntos expuestos anteriormente.

1. Tecnología. Debe estar basado en una tecnología que el cliente no perciba como un riesgo a medio-largo plazo. Además, las empresas de software se fagocitan unas a otras. Por consiguiente, desde el día 1 las elecciones de tecnología base deben hacerse teniendo en cuenta quienes podrían ser los compradores potenciales de la empresa. Esto no necesariamente descarta el Open Source, en Google, por ejemplo, se usa mucho Python. Pero si el objetivo último es Oracle o IBM entonces mejor si todo está escrito en Java.

2. Funcionalidades. Los pliegos de compra de software enterprise contienen casi siempre tantos requisitos que parece que el programa vaya a ser capaz de conectarse con la tostadora de tu casa y prepararte el desayuno antes de que te levantes. Hay un dilema irresoluble con respecto a esto: con pocas funcionalidades no se gana el pliego y con muchas el producto es como una navaja suiza útil para todo y buena para nada. Algunos fabricantes han resuelto el problema con una versión “estándar” que contiene lo que funciona, y un conjunto de módulos accesorios con lo que no funciona pero queda bien decir que lo hace el producto.

3. Posicionamiento. El posicionamiento del producto depende del alcance que tenga. Para los productos tácticos que sólo satisfacen una necesidad concreta de un departamento es posible dirigirse directamente a los clientes sin muchas maniobras. Para los productos más ambiciosos se suelen emplear tres tácticas: a) puntuar bien en los informes de las consultoras como Gartner, b) aliarse con socios estilo Accenture o KPMG para que prescriban el producto, c) autoproclamarse sistemáticamente el líder indiscutible en algún determinado nicho. Cualquiera de estas tácticas es costosa. Trabajar con las consultoras que evalúan producto no es barato aunque a veces se puede ahorrar dinero anunciando que se lanzará al mercado justo lo que la consultora pronosticó como tendencia futura a corto plazo. Es peligroso que el roadmap de producto lo condicione un tercero con una tasa de acierto en sus predicciones que no siempre es espectacular. Pero si los clientes también se creen las predicciones entonces se puede salir en el magic quadrant de la consultora y cerrar ventas simultáneamente. Por otro lado, las empresas como Accenture y KPMG lo que buscan es posicionarse como líderes en asesoría de negocio y proyecto en determinados sectores, para lo cual una de las piezas que necesitan es el software. Todos los socios para la implantación son, en general, muy oportunistas y sólo apuestan a corto plazo, pero si se consiguen algunos pocos proyectos exitosos con ellos es posible convencerles de que inviertan más en formar personal de venta, gestión y soporte postventa al software. Por último, aclamarse como el líder indiscutible de un nicho requiere de buenas referencias, una gran pericia en relaciones públicas y no poco gasto publicitario.

4. Precio. Una de las cosas que no se puede buscar en Google es el precio de un software enterprise. Existe un precio de lista que se facilita sólo a los distribuidores pero los fabricantes pueden aplicar descuentos de hasta el 60% según lo que les interese entrar en una cuenta o redondear el cierre de trimestre. La política de precios consiste, basicamente, en cobrar lo que se pueda a quien se pueda.

5. Soporte. El soporte es un área curiosa para mi, porque tiene tanto de gestión de expectativas como de solución real de problemas. Normalmente lo que el cliente quiere es saber qué es lo que sucede y cuándo va a estar arreglado (o no). Pocas veces hay incidencias críticas de verdad. En una ocasión leí una publicidad de una empresa que ofrecía “soporte fanático”, no he vuelto a saber de ellos, probablemente porque cuando los de soporte son unos fanáticos todo el mundo va como loco. Y si hay algo que detestan los clientes corporativos es la incertidumbre. En la mayoría de las empresas de software enterprise hay un departamento de I+D (que va a su puta bola) y un departamento de servicios que son los que tragan con la comida de perro de los de I+D. Yo no soy partidario de la separación radical entre desarrollo y soporte por esta razón enunciada de que los programadores acaban viviendo en una torre de marfil, pero tampoco se puede asignar a una persona simultáneamente a desarrollo y a soporte porque acabará haciendo pobremente lo uno y lo otro.

¿Qué ventajas tiene el software enterprise?

Por lo que he escrito hasta ahora, sé que parecería que uno no desearía caer prisionero del software enterprise ni en su peor pesadilla. Pero no todo es malo respecto de este segmento de la industria de software.

1. Acceso a componentes y procesos predefinidos y testeados. Para muchas aplicaciones simplemente no existe ninguna alternativa libre. Los programadores son técnicos a quienes lo que les gusta resolver problemas técnicos y luego publicar las soluciones para ganar fama, pero muchos de los procesos empresariales son aburridos a morir ergo no les interesan. Faricarse el software a medida uno mismo puede ser mucho peor. Yo he estado en proyectos con más de 300 aplicaciones a medida cada una de su padre y de su madre y eso es un sin Dios.

2. Disponibilidad de un marco de desarrollo común. Cuando se trabaja con varios equipos, posiblemente subcontratados de forma cambiante, es necesario tener un marco de desarrollo común que aporte un mínimo de homogeneidad a las aplicaciones. Los desarrolladores de funcionalidades deben estar, además, lo más aislados posibles del núcleo técnico para que no puedan por error provocar ningún desastre en la base de datos.

3. Acceso a innovación precocinada. Una pega de las herramientas Open Source es que muchas de ellas se distribuyen como un kit de hágaselo usted mismo. Entonces, una parte de lo que se ahorra en licencias hay que gastarlo en configuración y atención diaria de sistemas.

4. Mejor arquitectura. No siempre es el caso porque algunos programas bastante populares son un verdadero truño. Pero normalmente un software enterprise que ha sobrevivido suficiente tiempo en el mercado ha pasado por una serie de versiones en las que ha tenido que evolucionar en función de los requisitos de múltiples clientes en producción. Algunas de las aplicaciones Open Source más rabiosamente de moda son software extraído, es decir, software que se fabricó en una empresa concreta para un propósito concreto y luego se liberó sin demasiados cambios.

5. Continuidad. Esto sólo se aplica a los programas que son tan grandes como para no se blanco de compra de nadie. Las empresas de software empresarial tienen tres opciones de futuro: crecer muchísimo, ser absorbidas o desaparecer. Existen incluso empresas especializadas en gestionar el fin del ciclo de vida de software empresarial obsoleto. A decir verdad nunca se está a salvo. Spring y JBoss se fueron a manos de Red Hat y MySQL acabó nada menos que en manos de Microsoft Oracle con todos los directivos abandonando el barco y Monty Widenius creando MariaDB por su cuenta. Y si el software no es comprado por otro más grande es posible que al proveedor deje de interesarle y no invierta en actualizaciones.

Conclusiones

Existen muchos aspectos a tener en cuenta en el software que no son el lenguaje de programación o la productividad del último grito en herramientas. El software empresarial debe gestionar un complejo conjunto de subsistemas interconectados y debe cumplir con una larga lista de requisitos técnicos y funcionales de los clientes. Todo esto tiene un coste que, unido a lo largos que son los procesos de venta, implica que el precio del software empresarial no puede ser bajo. Por último, es legítimo invertir en innovación y pretender cobrar por ello. Creo que una parte de los defensores a ultranza del Software Libre se equivocan al pensar que todas las licencias de software deberían ser GNU o Apache. El movimiento Open Source surgió como reacción a las prácticas abusivas de venta por dominio de algunos fabricantes y como respuesta a regulaciones absurdas como las patentes de software. Pero no se trata de negar el derecho a cobrar por la propiedad intelectual y el esfuerzo en innovar, testear y distribuir.

Post relacionados:

El ciclo de vida del cliente B2B.
Los nuevos productos y el poder en las organizaciones.
Cómo ponerle precio a un producto software.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Esta entrada fue publicada en Adoptando Sw Libre en una Organización. Guarda el enlace permanente.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *