De lo enterprise

Sé que no os tengo acostumbrados a los que pasáis por aquí a este tipo de material tan técnico. Pero, a pesar de que en el blog no lo demuestre últimamente (=hace años?), la informática forma parte fundamental en mi vida. Tampoco tendría sentido crear un blog específico para estos temas, por lo poco frecuente de mis posts informáticos y porque entonces no sabría si dividir también la fotografía del dibujo o la música de las curiosidades... todos son aspectos de esta fraguel que escribe, así que aquí lo dejo.

Si eres un lector que no está intersado en estos temas, pasa directamente del post y queda a la espera de mi próxima foto o poema. Haremos como si esto no hubiera pasado :P

También le quiero agradecer a Javi las numerosas conversaciones y discusiones a las que no sabría decir cuánto le debe el artículo. A favor de mi autonomía en las opiniones vertidas aquí, he de decir que en cada apartado podría aportar una situación en la que un producto supuestamente enterprise incumplió ese requisito y padecí las consecuencias en carne propia. La necesidad de escribir este post surge de la incompresión que detecto en algunos de mis compañeros y jefes ante mis quejas...

Observo desde hace tiempo que existe cierta confusión en el uso del término enterprise referido a los productos TIC (Tecnologías de la Información y Comunicaciones).

El abuso en la utilización de este adjetivo, que se viene aplicando a productos que no cumplen ninguna condición para ser enterprise, parece que está acabando por hacer muy borroso su significado. Al fin y al cabo, los usuarios domésticos han terminado por asumir que en informática las cosas fallan, que es normal tener que reinstalar el sistema operativo de tanto en tanto y que nada hay seguro ni determinista en todo esto. Ya ocurre que algunos administradores y programadores creen más en la magia que en la tecnología. Pero esos son los efectos del marketing...

Hasta que el uso de este tipo de adjetivos esté tan regulado en el mundo TIC como en otros mercados, no nos queda más que tratar de no olvidar qué significan. Mientras que está reglado a qué se le puede llamar yogourt, todos hemos visto el cambio de nombre de algunos productos mal llamados bio y últimamente la persecución está tras lo light, que después es ligero y al final, si te fijas, tiene más calorías que el producto que compraste toda la vida, en informática enterprise, pro, platinum... son garantía de... ¿de qué?

¿Qué debería cumplir un producto Enterprise para ser llamado como tal?

Por lo pronto, este tipo de productos son usados, como su nombre indica, en un entorno empresarial. Alguien quiere prestar un servicio soportado sobre sistemas TIC y aplicará a este servicio las reglas tradicionales: darlo el mayor tiempo posible con el menor costo. Para poder alcanzar este equilibrio entre gastos en ingresos, una empresa buscará una serie de garantías en ese producto:

1)Ciclo de vida asegurado.

No es un producto enterprise aquel que se descontinua en un tiempo tan pequeño como para no permitir el retorno de la inversión. Es decir, si gasto X y dentro de pocos meses me voy a ver obligado en gastar Y para actualizar de versión, no habré recuperado el dinero que invertí inicialmente.

La puesta en marcha del sistema TIC que ayuda a la empresa a ofrecer el servicio, supone un coste que necesita tiempo de prestación de ese servicio para ser amortizado (si nunca llegara a amortizarse es que la decisión de compra, o la estrategia de negocio es incorrecta).

Adviértase que los costes anteriores no se refieren sólo a costes de licencia y/o soporte (que son los que habitualmente se contabilizan en primer lugar en los cálculos mentales de los compradores), sino que incluyen el coste de horas de personal técnico (instalador y de mantenimiento), así como otros costes adicionales como pueden ser construir un cpd donde no lo había o la formación de los usuarios.

Hay que tener en cuenta que todos estos gastos son aplicables tanto a productos con licencia, como sin licencia, sean de código abierto o no. Cada concepto en la suma variará de volumen y en algunos casos se pondrá a cero, pero el cómputo total acabará por suponer un coste para la empresa. La elección de un tipo de producto u otro estará motivado, además de por el coste total, por otro tipo de cuestiones relacionadas con las funcionalidades ofrecidas, la propiedad del formato de los datos, la libertad de elección de proveedor, el conocimiento de dicha tecnología por el personal técnico de la organización, la compatibilidad con otros productos... En cualquier caso, una vez realizada la inversión, se quiere que esta sea lo más rentable posible.

Este concepto de ciclo de vida no es nada nuevo, en industria se ha manejado tradicionalmente: realizo una inversión de varios millones en la máquina tal porque me supone un ahorro de un tanto por ciento en los costes de producción y lo amortizaré en tantos años. La diferencia fundamental es que el mercado de máquinas industriales no ofrece productos pretendidamente novedosos en tan cortos períodos de tiempo como ocurre en el entorno informático.

Por otro lado, parece lógico pensar que con una política de liberación de versiones que asegure estos ciclos de vida largos, el producto liberado tendrá mayores garantías de calidad y el roadmap, que veremos más adelante, estará más claramente definido.

2)Compatibilidad hacia atrás y hacia adelante.

Un producto enterprise y en este caso hablaríamos típicamente de software, debe garantizar la compatibilidad hacia atrás entre versiones. Esto incluye la configuración del producto, que debe permanecer compatible, así como las interfaces con productos de terceros, que deben extender su funcionalidad sin modificar lo que ya se ha definido.

Respecto a la compatibilidad hacia adelante, esta se debe garantizar al menos, en el acceso a los datos. En caso de romperse esta última compatibilidad deben ofrecer herramientas de migración de formatos o de versión, de manera que la información permanezca siempre accesible.

Son habituales las quejas contra productos gratuitos, típicamente de código abierto, cuando estos rompen compatibilidades al cambiar de versión. De repente, no puedes abrir ficheros de la versión anterior o posterior (poco habitual pero ocurre y puede ocurrir) o el servicio web que utilizabas para la integración con una tercera aplicación ha cambiado sus parámetros. Parece que se olvida que no existe acuerdo contractual con los distribuidores de ese producto, por lo que ellos, en su justo derecho, pueden hacer lo que quieran con él. En realidad, son muchos los que aseguran que esta es una de las ventajas de este tipo de software, que es impulsor de grandes cambios tecnológicos y de paradigma, que se retrasan en los entornos enterprise al estar atados por los acuerdos con los clientes.

Y ocurre lo contrario, cuando productos supuestamente entreprise obligan en un cambio de versión a retocar, a veces rehacer por completo, una configuración o un desarrollo de interoperabilidad con otros productos, quizá por las experiencias con esos otros tipos de software, el cliente considera que no hay alternativa, que es lo normal y que es un gasto a asumir porque es imposible para la empresa proveedora hacerlo de otro modo.

Como el usuario doméstico que cree que es normal la reinstalación...

3) Roadmap

Cuando adquieres un producto enterprise debes poder conocer las restricciones de funcionalidad de la versión actual y cuáles son los cambios y mejoras planificados para las siguientes.

Esto que parece irrelevante, permite a una empresa definir los pasos para la implantación del producto con suficientes garantías y ajustes de gastos. Pongamos por ejemplo una empresa que quiere implantar un producto con autenticación mediante un servicio de directorio (como puede ser ldap) y mediante certificado, almacenado en unas tarjetas que se distribuirán entre los empleados. Supongamos que en la actual versión de un producto que se le oferta, se proporciona la capacidad de autenticación contra ldap y no mediante certificado. Pero la autenticación con certificado está prevista para la siguiente versión que estará disponible en un año. La empresa puede entonces, por ejemplo, posponer la compra de los lectores y las tarjetas para la extracción de certificado un año (los comprará al precio del momento en que los usa, probablemente más bajo) y podrá adquirir el producto software ahora para comenzar la implantación, teniendo la garantía de que en el futuro cubrirá todas sus necesidades.

4) Certificación

Un producto enterprise debe ofrecer configuraciones estándar que pueden utilizarse con garantías de éxito. Por ejemplo un software podría certificarse sobre un determinado entorno hardware, incluyendo además de arquitectura, marcas y modelos concretos de servidores, sistemas de almacenamiento, electrónica de red...etc que han sido probados en sus laboratorios y se certifican por su correcto funcionamiento. Esto permite al comprador asegurarse de establecer todos los mecanismos necesarios para poder garantizar la provisión del servicio. Estas configuraciones certificadas pueden intervenir como prerrequisito en los contratos de soporte de los que hablaremos en el siguiente apartado y es muy importante conocerlas.

Además, el proveedor ofrecerá casos de éxito, es decir, ejemplos de implantaciones exitosas que permitan al cliente aprender de posibles errores cometidos anteriormente. Aportará además medidas de consumo por recurso, curvas de carga por número de usuarios concurrentes, guías de "mejores prácticas", ... que permiten al cliente dimensionar su infraestructura de la forma más ajustada.

5) Soporte

El servicio que ofrece una empresa estará sujeto a determinados contratos con sus clientes y a su vez,establecerá sus propios contratos con los proveedores, entre los departamentos de su propia organización... (SLAs, OLAs, UCs, SLRs... ver terminología ITIL), para asegurar que puede cumplir con lo pactado con sus clientes.

Por ejemplo, una empresa que ofrece un servicio soportado en un sistema TIC que está constituido por un front-end web, no podrá asegurar que el servicio estará disponible al 100% si se está utilizando un único servidor web con puntos únicos de fallo o si está usando una arquitectura completamente replicada pero el proveedor del software que utiliza sólo le garantiza una disponibilidad del 90%. (En realidad puede asegurarlo, pero debería ser consciente de que lo hace sin garantías).

Así que el acuerdo contractual con el proveedor del producto TIC adquiere tanta importancia para una empresa como para delimitar qué compromisos podrá asumir con sus clientes. Estos acuerdos pueden ser tan críticos como los de un hospital con sus pacientes.

En un soporte hay que delimitar claramente qué tiempos de respuesta se contratan, qué tiempos de resolución, qué garantías, tiempos de actuación in situ, disponibilidad de piezas de repuesto en cuánto y durante cuánto tiempo... etc. Y además, se deben establecer mecanismos de penalización ante incumplimiento de estos acuerdos.

Hay que tener en cuenta que "tiempo de respuesta" no es equivalente a "tiempo de resolución". Delimitar exáctamente tiempo de recepción de los repuestos y si es de todos o de un subconjunto. Y ante todo, aclarar entre empresa y proveedor que el soporte se ofrece sobre cierta instalación certificada con un versionado concreto.

¿A alguien le resulta fácil pensar en que un proveedor de productos TIC sea capaz de firmar un contrato de este tipo sin un ciclo de vida largo, mantenimiento de la compatibilidad, un roadmap definido...?

6) Documentación y formación

La documentación del producto y de la instalación, manuales de buenas prácticas, de integración, de explotación... deben ser exigidas por la empresa y tenidas en cuenta antes de firmar el contrato. A estas alturas a nadie se le ocurre comprar una lavadora sin manual, ¿cómo hacerlo con una infraestructura TIC? Esta documentación será una garantía de la calidad de los trabajos y en algunos casos, asegurarán la libertad de elección de proveedor en caso de insatisfacción con el actual. Y si un proveedor o equipo técnico piensa que por aportar documentación de sus productos está perdiendo control sobre ellos, ¿no es ése un motivo para pensar que no tienen mucho más que aportar que la información que se puede documentar? El verdadero know-how y la excelencia de los servicios técnicos no se pierden por escribir cierta información esencial en un documento.

Además de la documentación, un producto Enterprise debe ir acompañado de una oferta de formación reglada y de calidad, a la que puedan acceder aquellos clientes que deseen acortar sus curvas de aprendizaje por suponerles un ahorro en costes o por una necesidad surgida de plazos ajustados de puesta en marcha de los servicios.

7) Garantía

La garantía del producto TIC estará avalada por todos los puntos anteriores: desde el aseguramiento del ciclo de vida hasta el soporte completo durante todo ese ciclo. Y deben existir mecanismos de penalización ante incumplimiento de los acuerdos o violación de las garantías ofertadas.

Con todo lo anterior, debería quedar claro que el adjetivo entreprise debe aplicarse a una gama de productos concretos orientados a clientes con unas necesidades específicas. Y, a pesar de que se pueda abusar del uso de esta calificación enterprise, como clientes potenciales de productos de fabricantes TIC (incluso siendo un usuario doméstico) deberíamos tener claro qué significa a grosso modo esta categorización. Quizá algún día se regule la utilización de este tipo de apelativos y podamos estar seguros de que al comprar un producto apodado enterprise nos queda garantizado un cierto nivel de calidad.