Oracle y BEA: Empieza el baile

Es la gran noticia de estas últimas semanas en lo que a adquisiciones/fusiones se refiere: Oracle ha realizado una oferta para la adquisición de BEA Systems.

Hace ya varios meses desde que ciertos analistas apuntaron el interés de inversores propietarios de BEA en vender la compañía, así que los intereses de las grandes compañías como SAP, HP y Oracle no tardaron en surgir. Intereses que, en este último caso, se ha materializado en una oferta formal de 6,7 billones de dólares.

Ante esta oferta, el comité de dirección de BEA se escandalizó, no tanto por el hecho de la oferta de adquisición (¿signo de que ya sabían algo?) sino por el ínfimo precio que se le había dado a la compañía. No obstante, aunque en un principio pudo parecer que se iban a negar ante cualquier oferta independientemente de la cuantía, la voz de los inversores económicos (empresas que hacen que este tipo de compañías sea tan potente en EEUU y de las que, por desgracia, carecemos en Europa) se hizo notar. Aquel NO rotundo se ha tornado en un “eso no pero si fuera esto otro…”.

Ahora ya han puesto un precio de 21 $ por acción, lo que resultaría en más de 8,3 billones de dólares por el total de la compañía (http://www.news.com/BEA-sets-buyout-price-at-21-a-share/2100-1014_3-6215263.html?tag=item ).

Este precio ha sido oficialmente rechazado por Oracle, aunque creo haber visto este tipo de situaciones en algún otro lugar:

La orquesta comienza a sonar. Él le pide bailar. Ella se muere de ganas pero se excusa en que su madre les está mirando. Él le dice que es únicamente un baile, nada más. Ella flirtea ligeramente aunque titubea con intenciones de acceder. Finalmente pone ciertas condiciones. Él podría aceptarlas pero no lo hace (ha de hacerse valer!!), así que simula reflexionar … aunque en lo más profundo de sus corazones saben que están hechos el uno para el otro.


Un saludo, navegantes del mar tempestuoso

La problemática de la actualización de las infraestructuras

En el mundo de los Sistemas de Información, cuando hablamos de las infraestructuras hardware o software, éstos son elementos que nunca se valoran lo suficiente. Se trata de piezas de los que se asume un correcto funcionamiento pero que, en el caso de que fallen, es cuando realmente adquieren el valor que les corresponde. Parece una contradicción pero es así.

Aunque para los legos en esta materia esta afirmación puede resultarles sorprendente , estas infraestructuras están basadas en productos y máquinas que, por lo general, deberían tener un ciclo de vida como el de cualquier otro aplicativo. Pero cuando hablamos de infraestructuras, al tratarse de servicios “core” y sin los cuales los sistemas de información que se basan sobre los mismos dejarían de funcionar, la gestión de estos ciclos de vida se complica sobremanera. Generalmente existen dos orientaciones para llevarla a cabo:

• Orientación “si algo funciona no lo toques”. Es algo que se ve circular en algún correo electrónico de tono jocoso (al menos entre los informáticos, esa rara avis cada vez más extendida entre los que me incluyo) pero realmente es la orientación más extendida entre todos los departamentos de Sistemas. Este modo de pensar y actuar es muy conservador y, a la larga, termina de ser contraproducente. Las sustituciones y/o evoluciones terminan por darse y suelen ser traumáticas. Además, las infraestructuras, aunque estén estables, nunca terminan de dar todos los servicios, ni por lo general de igual calidad, de las versiones de plataformas más evolucionadas. No obstante, para ciertos casos, es posible que esta orientación sea la más adecuada.
• Orientación “vamos a estar siempre a la última”. Esta orientación es muy arriesgada en la mayoría de los casos. Las infraestructuras, por lo general, están sujetas a excesivas actualizaciones y nunca terminan de quedar estables. Por el contrario, las ventajas que aporta esta situación son plataformas “a la última” con lo que ello implica: mayor nivel de seguridad, de corrección de errores o “bugs” y una mayor funcionalidad aportada. Existen organizaciones que, para su escenario de negocio, esta opción es más adecuada.

No obstante, para los sistemas de información de la mayor parte de las empresas, lo ideal es encontrar un equilibrio. Como suele decirse, en el medio está la virtud. Los responsables de las infraestructuras deberían realizar un seguimiento de la evolución de las mismas y tener una política de actualización. Esta política será más o menos conservadora pero deberá existir siempre. Aunque suene un poco ridículo en un blog de tecnología el hablar de valentía, una de las cualidades más deseables en los responsables de las infraestructuras es la no carencia de valentía. El motivo principal por la que los responsables son reacios a realizar actualizaciones de infraestructuras es por la complejidad que posee esta acción de actualización.

Las infraestructuras son servicios “always on” para el conjunto de los sistemas de información. Un mecanismo de trabajo habitual y muy recomendable para llevar a cabo las actualizaciones es diseñar un entorno de laboratorio donde se lleva a cabo una simulación del upgrade. El juego de ensayo para validarlo puede ser más o menos complejo y, cuanto más completo sea, mayor será su coste y su eficacia. Aun y todo, la validación de una actualización en base a las conclusiones sacadas de un entorno de laboratorio, no es fidedigna del todo. No es más allá que una orientación más o menos precisa. El entorno real de prueba de la actualización termina por ser el entorno productivo con todas las implicaciones que esto lleva consigo: posibles caídas del servicio en caso de fallo, quejas a todos los niveles tanto del usuario final de los aplicativos como de los responsables de los mismos dentro de la organización, etcétera. Se dice que uno no valora algo hasta que deja de tenerlo y esto se aplica perfectamente para el caso de las infraestructuras.

A la hora de la verdad, la de realizar la actualización de una infraestructura en un entorno productivo, el contar con una copia de seguridad de todos los elementos afectados en el caso de las infraestructuras software, o un procedimiento de contingencia en el caso de las hardware es, si cabe, lo más importante del proceso. Además, en función de la infraestructura concreta, la recuperación del entorno inicial debe realizarse lo más rápidamente posible. Esta presteza implica que:

• Las copias de seguridad deben realizarse de aquello que garantice una recuperación rápida (incluso una imagen del disco puede ser aplicable en muchos casos).
• Siempre debe existir un procedimiento definido para llevar a cabo la actuación. Esto evita que indecisiones de última hora se den en momentos inconvenientes.
• Las decisiones tienen que ser extremadamente rápidas en caso de fallo. Son servicios que no pueden dejar de funcionar y hay que tener un procedimiento perfectamente acotado además de una persona con la capacidad necesaria de tomar esta decisión con la presteza requerida.

Creo que, con lo anterior, la falta de valentía extendida en los responsables de infraestructuras podría quedar justificada en parte. Pero, no nos engañemos, nunca del todo.

Para terminar con esta gota en el mar de la tecnología, un consejo para aquellos en los que os encontráis en la complicada situación de afrontar este proceso: armaos de valentía (no es tontería) y sed meticulosos y exactos en los pasos a seguir. Tened preparado un procedimiento de marcha atrás por mucho que los entornos de laboratorio hayan sido completos y sed eficaces y rápidos en su aplicación en caso de que sea necesario. Son decisiones complejas en algún caso pero que han de tomarse rápidamente. Eso sí, la frontera entre la valentía y el ser temerario es difusa en muchos casos, y únicamente en el juicio de cada uno esto tiene un matiz claramente diferente.

Un saludo, navegantes del mar tempestuoso