jueves, 29 de septiembre de 2011

Chamanes de la informática

Siguiendo con la línea de profesiones relacionadas con la informática llegamos a los chamanes.
Mi compañero de fatigas Quique suele hacer mención de forma recurrente a la utilización de los apéndices gallináceos en su forma vulgar de 'pata de pollo' ante ciertos comportamientos de ciertos softwares.

El caso del Essbase, una herramienta de la que ya os he hablado en bastantes ocasiones, clama al cielo. Esta herramienta MOLAP tiene muchas utilizaciones y es flexible como pocas, pero su filosofía de dimensiones densas y dispersas y sus optimizaciones rayan lo paranormal.

Imaginad un proceso de cálculo en el cual se especifican una serie de miembros multidimensionales el orden de los cuales afecta al cálculo. Ordenándolos de una manera el cálculo tarda 5 minutos y de otra tarda 10.
Imaginad que nadie en todo el mundo es capaz de decir por qué el primer orden de cálculo hace que el sistema tarde menos.
Imaginad que además, en su benevolencia, en ningún lugar de ninguna documentación aparece por ningún lado que deba ordenarse de alguna u otra manera llegando el lector a la suposición de que 'da lo mismo'.

Que una herramienta de esta categoría (y precio) y un fabricante como Oracle (y antes Hyperion) sean incapaces de especificar unas reglas claras (más allá de las obvias de la herramienta) de cómo mejorar el tiempo de proceso o de por qué ciertos casos son más rápidos que otros es lo de menos. El problema es el siguiente:
a) Caso normal:
- He conseguido bajar el cálculo de 1 hora a 15 minutos
- Genial. ¿Cómo lo has conseguido?
- He estudiado la estructura, el orden de los cálculos, lo que cargábamos y los cachés y lo he configurado adecuadamente para las circunstancias y ha funcionado.
- Perfecto, para otra vez ya lo sabemos.

b) Caso paranormal:
- He conseguido bajar el cálculo de 1 hora a 15 minutos
- Genial. ¿Cómo lo has conseguido?
- He cambiado el orden en que se especificaban ciertos elementos.
- ¿Y cómo es que ha mejorado?
- Porque el motor de optimizaciones de cálculo unido al condensador de fluzo provoca una expansión en las cuerdas del espacio tiempo que optimiza la alineación astral planetaria al respecto de los neutrinos supralumínicos haciendo que tarde menos la interacción en el campo electromagnético generado por el procesador concorvial y en consecuencia hay un aprovechamiento sinérgico máximo del proceso de cálculo, haciendo que sea óptimo.
- No sé por qué pero no acabo de creerte.

Efectivamente, explicarle a un cliente que haciendo un cambio que según toda la documentación no va a tener impacto lo tiene y no sabemos por qué nos deja en mal lugar a los técnicos. ¿Sería posible obtener documentación más avanzada del proceso de cálculo? ¿Realmente no hay nadie que sepa cómo funciona? ¿Se les borra la memoria a los programadores cuando acaban una versión? ¿El programador que ideó el optimizador de cálculo ha sido abducido por los extraterrestres? Seguiremos informando.

jueves, 8 de septiembre de 2011

Escalabilidad simple

Una de las palabras más grandilocuentes que utilizan los fabricantes de soluciones empresariales es 'escalabilidad'. Obviamente se trata te un anglicismo no contemplado por la RAE como puede verse aquí.
Esta palabra supone que puedes tener una implantación simple para pocos usuarios y luego, según vas teniendo más usuarios y complejidad, irla adaptando de manera que sin un desembolso adicional o un cambio de infraestructura importante se pueda adaptar.

En los tiempos que corren todo es escalable (incluso el Everest)...
- Su saldo de puntos en el carnet de chistoso está en números rojos

 ... Y en virtud de esa escalabilidad se hacen ciertas adaptaciones a los productos que, cuanto menos, son cuestionables.

Como experto en Essbase voy a hablar de Essbase en este sentido. La versión actual de Essbase es la 11.1.2, si no recuerdo mal. Yo hace más de 10 años que lo conozco, aunque la primera con la que traté fue la versión 5.
Hoy en día, para tener una instalación de Essbase que funcione con la última versión, necesitas un monstruo de servidor e instalar el módulo de servidor de base de datos, el de administración, un par de repositorios relacionales, el directorio activo, los antiguos shared services... En fin, toda una infraestructura que a veces es complicada de manejar y de instalar para tener, finalmente, un sistema de base de datos multidimensional de última generación.

El caso, y que me perdonen los señores de Oracle y anteriormente los de Hyperion, Essbase sigue siendo el mismo Essbase que yo conocí hace 10 años. Con mejoras y algunas ampliaciones, pero en esencia es el mismo. De hecho porque ya no lo venden, pero muchas de las demos o cursos que hago de Essbase las hago con la versión 7 que tiene como 6 años (ahí es nada) y es totalmente equivalente a la versión última y válida para el 95% de los clientes.

La diferencia (aparte de temas de compatibilidad con los últimos sistemas operativos) radica en que la versión 7 se instalaba con un super agradecido siguiente siguiente siguiente siguiente en dos ejecutables y en 15 minutos podías tenerla funcionando en casi cualquier PC mientras que la versión actual puedes tardar como 2 días y eso si no te da algún problema por el medio el fabuloso (léase la fina ironía) instalador de Oracle o el evaluador de requisitos.

La evolución informática a veces no va hacia la simplicidad y la sencillez. Entiendo que primero Hyperion y después Oracle decidieron desplazar ciertos módulos que tenía nativos a módulos comunes que pudieran compartir con otros módulos más en virtud de una escalabilidad futura. Pero al final, esa escalabilidad se queda muchas veces en nada y tenemos que plantearnos la instalación de una mega solución para algo que tiende a ser más pequeño.

Es como si, haciendo mis habituales símiles automovilísticos, comprásemos un autobús con remolque para ir a comprar el pan.

Luego los fabricantes se preguntan por qué las herramientas open source (actualmente muchas de ellas mucho más simples de instalar y utilizar para cosas concretas) o herramientas all-in-one como DeltaMaster les comen terreno. Y en el caso de Oracle, no sólo es la simplicidad comparada la que puede hacerles perder una implantación sino el curioso anagrama que forman sus letras si lo lees al revés.

viernes, 2 de septiembre de 2011

El mejor trabajo del mundo


Mi coche lo podéis encontrar ahora mismo debajo de una buena capa de polvo/tierra que hace bueno aquel dicho que reza 'lávalo o siembra patatas'.
Como buen previsor y tratando de que a uno la ley de Murphy le afecte lo justo, si el señor del tiempo (el meteorólogo, no hablamos de Cronos) dice que va a llover, uno se abstiene de lavar el coche (una excusa más que tengo, claro).

El caso es que desde hace una semana el señor del tiempo (de nuevo el meteorólogo) dice que 'mañana lloverá'... Y mi coche sigue sucio, ergo llover, lo que se dice llover, no ha llovido.

Esto me hace preguntarme exactamente para qué sirve la predicción del tiempo porque lo que ha pasado, como siempre a toro pasado, es fácil de decir. El que me digan que en Sevilla hoy ha hecho calor y que en Santander un poco menos... Pues mira... Pero que te digan que mañana prepares el chubasquero y que luego haga un sol de justicia para volverte a decir que no, que mañana no, que pasado mañana... Bueno, pues como que incomoda un poco.

Y entonces llegas a la componente informática de todo esto, porque hay un modelo (informático, no un modelo de ropa... Aunque teniendo en cuenta las predicciones que hace, no sé yo...) que a partir de la información del canal visible, el infrarrojo, el térmico, el blanco nuclear y muchas matemáticas genera la predicción. Y esa predicción no siempre es fiable porque 'el tiempo puede cambiar imprevisiblemente'.

Yo voy a probar lo mismo en algún proyecto que haga y hablaré con mi cliente:
- Oye, que no lo vas a tener hoy, que será mañana.
- ¿Y por qué mañana?
- Es que los datos son imprevisibles
- ¿Y cuándo lo tendré, por la mañana o por la tarde?
- Hombre, dependerá de las circunstancias, que los datos son imprevisibles.
- Ahm... Ya...
Con este discurso me parece que conseguiré que el cliente me bote pronto (y podré tomarme otra tanda de vacaciones aunque no sé si en el paro...), cosa que no pasa con los meteorólogos (y su equipo, que no están ellos solos), que tras fallar durante una semana siguen felices asegurando que mañana lloverá (bueno, algún día tendrán que acertar) sin ningún tipo de responsabilidad aparente por sus errores.

En la fórmula uno, la predicción del tiempo es tan exacta que permite determinar, normalmente, en qué vuelta va a comenzar a llover y su intensidad, y si el meteorólogo del equipo se equivoca, se pierden carreras y se le despide.
A mediados de los 90, la ya fallecida Enron propuso crear un mercado de 'seguro del tiempo atmosférico' (weather risk management) en el que le darían de collejas al meteorólogo que fallara sus predicciones dado que las empresas exigían (y pagaban por ello) una predicción absolutamente fiable.

¿Alguno de mis lectores puede explicarme por qué un meteorólogo puede equivocarse reiteradamente (con todo un país, nada menos) y no pasa nada y un consultor puede verse crucificado por poner mal una coma? ¿Mojarse por no llevar paraguas es menos malo que equivocarse en un dato en un informe de costes? ¿Tendrán que poner una advertencia en los partes meteorológicos de 'úsese con precaución y fíese lo justo'?

Al tiempo...