Hago clic... ¡y no pasa nada!

Todos (bueno, todos los de este lado de la brecha digital) sentimos con cierta frecuencia esta sensación de desazón que nos invade cuando estamos intentando realizar cualquier operación por Internet, hacemos clic para validar una opción y pasados unos cuantos segundos ... ¡no pasa nada!. De repente, nos invade el temor porque no sabemos si esa transferencia se ha realizado o no, si nos cargarán o no ese importe en la tarjeta de crédito, si el pedido es o no conforme... No tenemos nada en nuestra mano que nos garantice la veracidad de los hechos.

(Fuente: redusers)

Tendremos que empezar a revisar los cargos de la VISA, el saldo de la cuenta, o lo que sea para intentar averiguar dónde y en qué punto se rompió esa relación cordial con nuestro ordenador, con la Red, con otros cientos de ordenadores que ignoramos dónde están y para qué sirven, y con el ordenador de nuestro Banco, proveedor, o lo que sea.

El origen de este problema radica en que estamos rodeados de cientos, de miles de aplicaciones y programas informáticos, imbricados en equilibrios muchas veces inestables, y las cosas sólo acabarán funcionando bien cuando toda la cadena completa de ordenadores, aplicaciones y programas funcione de acuerdo a lo que esperamos de ellos, cuando todos los engranajes funcionen a la perfección.

Un antiguo y llorado colega, Francesc Lluch, informático de la vieja escuela donde los hubiera, solía decir, para ilustrar el éxito, que había escrito un programa que sabía contar hasta 100 y se paraba. Con ello quería ilustrar una realidad que debería ser de cabecera para cualquiera que se dedique, de una u otra forma, a la informática: el coste (en tiempo, por ejemplo) de desarrollar un programa que haga lo que queremos que haga cuando le suministramos los datos que espera no es más que un 10% (si acaso) del coste de hacer un programa sólido que haga lo que queremos que haga en cualesquiera circunstancias.

Esto era cierto cuando las aplicaciones y programas informáticos eran piezas muy homogéneas y sólidas que funcionaban sobre un ordenador, preparados para ser utilizados por usuarios formados y entrenados. Con el paso del tiempo y la extensión de las telecomunicaciones en sentido amplio, las aplicaciones y programas se tuvieron que desarrollar pensando en que debían poder ser utilizados por cualquier usuario, incluso por el público en general. Sólo este hecho supone que en el desarrollo del código de programas y aplicaciones hay que tener en cuenta un catálogo casi infinito de barbaridades que puede cometer el usuario y que en ningún caso deben provocar un malfuncionamiento: tienen que estar previstos.

Con la extensión prácticamente universal de Internet, y su utilización por todo tipo de usuarios, este fenómeno se ha agudizado por varios motivos. Los que antes eran programas monolíticos, ahora son un conjunto de piezas separadas, que funcionan en diversos ordenadores, incluyendo el del propio usuario, de los que el programador poco o nada sabe cuando escribe su código. Las aplicaciones se han convertido en engranajes muy complejos, que deben funcionar a la perfección en cualesquiera circunstancias.

Esquema simplificado del funcionamiento de aplicaciones
monolíticas centralizadas. Un mundo cerrado.
(Fuente: jmscaos)

Tradicionalmente, la estructura de la profesión informática incluía a programadores, analistas e ingenieros de sistemas que, progresivamente al desplazarse hacia arriba en la pirámide, tenían una perspectiva mayor del sistema en su conjunto. Pero la labor del programador era muy importante y de gran responsabilidad. Debían desarrollar y depurar el código para que ese programa o aplicación realizara el proceso que se esperaba de él, a partir de los datos que se le suministraran. El analista debía definir cuáles (y cómo) eran los datos de entrada a ese programa, y lo mismo para los de salida. El control de calidad del programador debía incluir la verificación de que el código desarrollado cumplía con las especificaciones definidas. Y prácticamente se podían integrar los programas desarrollados por todo un equipo de programadores para tener una aplicación o un sistema informático que funcionara de acuerdo a lo que se esperaba de él.

Con la evolución de las tecnologías y la progresiva modularización de la programación, el control de calidad del trabajo del programador garantizaba en menor medida la adecuación de la aplicación global a las especificaciones definidas. Para empezar, había un factor de escala. No era para nada lo mismo que el código se probara con un usuario  y una base de datos de prueba con cien registros, por ejemplo, a un funcionamiento más realista, donde hubiera cientos o miles de usuarios simultáneos (en la práctica, cientos o miles de instancias del mismo código, ejecutándose simultáneamente sobre el mismo ordenador), trabajando todos contra una misma Base de Datos de millones de registros. Hubo que desarrollar las buenas prácticas necesarias para poder garantizar que el trabajo de los programadores fuera compatible con ese factor de escala, y no aparecieran en la fase de pruebas limitaciones inaceptables que provocaran la necesidad de un rediseño de todo el conjunto. Apareció un oficio nuevo, el arquitecto de aplicaciones. Este debía mantener la perspectiva del edificio completo (la aplicación en su conjunto) y asegurar que lo desarrollado en el sótano y en los diferentes pisos fuera compatible y conforme, para alcanzar finalmente un edificio de calidad.

Pero la extensión de Internet ha generalizado el desarrollo de lo que se acostumbra a llamar aplicaciones web, que son las que utilizamos todos continuamente, aunque no siempre seamos conscientes de ello. Su característica diferencial es la casi infinita atomización de los módulos de programa, cada uno limitado a una función específica. Esto ha provocado, paralelamente, una degradación de la posición del programador en la pirámide del oficio. Lo que ha llevado, obviamente, a que sea una labor muy mal pagada, realizada habitualmente por los más junior del oficio, de la que cualquiera con ambición y talento huye en cuanto puede. Lógicamente, la calidad del código entregado por los desarrolladores también se ha resentido.

En paralelo, ha habido que desarrollar nuevas labores en la pirámide del oficio. Ha aparecido, por ejemplo, el urbanista de aplicaciones. Porque ya no se trata de construir un edificio, sino de crear una ciudad coherente y habitable. Con sus zonas residenciales, comerciales y de ocio; cada una con sus comportamientos y exigencias específicos.

Un esquema simplificado de aplicación web, con
los diversos ordenadores y módulos involucrados.
(Fuente: brainlabs)

Tomemos un ejemplo: una aplicación bancaria para los clientes de Banca Online, que requiera autenticación del usuario mediante contraseña o cualquier otro método. En el interior de la aplicación habrá un elevado número de módulos de programa, cada uno dedicado a una tarea concreta: conexión y desconexión del usuario, visualización de su posición global, realización de una transferencia (posiblemente haya transferencias de muchos tipos diferentes, que requieran cada una de un proceso específico), compra o venta de valores, etc. etc. Todos estos módulos funcionarán sobre diversos ordenadores del Banco, cuyo número y naturaleza habitualmente se desconoce en la fase de escritura del código. Por lo tanto, es necesario que el código sea portable y escalable.

Cada módulo podrá ejecutarse en condiciones de entorno diferentes. Un usuario debe poder ver su Posición Global y desconectarse, mientras otro querrá realizar una transferencia y luego desconectarse, o incluso ordenar una compra de valores y desconectarse a continuación. La visibilidad para el usuario será que, haga lo que haga, dispondrá en la pantalla de una opción de desconexión. Que, en todos los casos, debe lanzar la ejecución del módulo de desconexión correcto. Porque las aplicaciones, como las ciudades, son seres vivos. Continuamente se construyen (o derriban) edificios de viviendas en la zona residencial, se abren (o cierran) comercios en la zona comercial, se abren (o cierran) restaurantes o cines en la zona de ocio. El residente deberá modificar sus hábitos y costumbres para adecuarse a esos cambios.

Si un residente se empeña en ir a comprar el pan a un comercio que ya cerró, Houston, tenemos un problema. Si un comercio dejó de vender pan pero no cerró, y muchos residentes siguen yendo allí para comprar pan, tenemos un problema también.

En las aplicaciones web, además, existe un factor añadido de complejidad técnica. Parte del código de la aplicación se interpreta y ejecuta en el propio ordenador del usuario, en el seno de lo que se conoce como Navegadores (o browser, en inglés). Y no podemos obviar el hecho de que el dispositivo de acceso del usuario a la aplicación puede ser, a su vez, de diferentes categorías: ordenador (con diferentes tamaños de pantalla y diversas resoluciones), tablet, smartphone, etc. En algunos casos deberá existir una versión específica de la aplicación para cada tipo de dispositivo de acceso. No se organiza igual un McDonalds que un McAuto, por ejemplo.

Incluso si el dispositivo es un PC en todos los casos, el Sistema Operativo puede ser de diversos tipos (Windows, Linux) y de diversas versiones. Y existen, también, varios Navegadores diferentes bien implantados en el mercado. Los tres más extendidos en la actualidad son el Internet Explorer, el Google Chrome y el Mozilla Firefox, pero hay bastantes más. Todos los Navegadores hacen exactamente lo mismo, pero no necesariamente de la misma manera. Por lo tanto, inevitablemente, no se comportarán todos exactamente del mismo modo al interpretar un código que le envíe la aplicación del Banco.

Para la aplicación de ese Banco que estábamos comentando, el número de combinaciones posibles es prácticamente infinito. Y nunca va a ser posible haber probado exhaustivamente todas ellas.

Analizada toda la intrincada complejidad interna, volvamos a ese usuario desconcertado, que ha hecho clic y no ha pasado nada. Ha proporcionado todos los datos necesarios para realizar una transferencia, por ejemplo, pero al pulsar el botón de Validar no ha pasado nada, pasados unos segundos.

En este caso, la mejor recomendación es aplicar el principio del in dubbio pro reo. Si aparentemente no ha pasado nada, debemos entender que realmente no ha pasado nada, y que la transferencia no se ha realizado. Todas las aplicaciones de calidad actualmente incorporan mecanismos de seguridad por el que nunca se da por concluida una operación hasta que todos los actores implicados han manifestado explícitamente su conformidad y han sido correctamente informados de su conclusión.

Cuando hago clic y nada ha pasado en unos
segundos, casi seguro que ya no pasará.
Mejor no acabar así.
(Fuente: antinformaticos)

Y lo siguiente, antes de concluir que la aplicación no funciona, conviene probarla con un Navegador diferente. Sí, nadie dijo que fuera a ser fácil. Cuando hago clic y no pasa nada, es muy probable que esté haciendo algo de una forma diferente a como lo espera quien diseñó la aplicación. Y como el Navegador es parte de lo que el usuario aporta a la aplicación, pues eso.  Conviene tener disponibles en nuestro PC al menos los navegadores más extendidos. Seguro que tendremos uno que es nuestro favorito y el que utilizamos habitualmente, pero conviene tener también los demás, para verificar la situación cuando se producen este tipo de casos. Por otra parte, si acudimos al Servicio de Atención al Cliente (del que ya hablaré in extensum en otra ocasión) alegando que la aplicación no funciona, es harto probable que la primera respuesta que obtengamos sea que la probemos con otro Navegador. Y lo curioso del caso es que, en la mayoría de ocasiones, con eso resolvemos el problema, por lo que más nos vale intentarlo de inicio, y no perder más tiempo.

Y, para ilustrarlo, tres ejemplos que he vivido en las últimas semanas. Es posible realizar apuestas online a las Loterías del Estado (Bono Loto, Primitiva, Euromillones,...) a través de la web oficial del Servicio. Se visualiza una parrilla (parecida al boleto físico de apuesta) donde podemos escoger las diversas opciones. Utilizando Google Chrome como navegador, a veces esta parrilla no se visualiza correctamente, aunque es posible realizar la apuesta igualmente si se elige la opción de Apuesta Automática; sólo es un problema de visualización. Utilizando Internet Explorer siempre funciona bien.

Intentando cargar unas fotos en un álbum online en la web de Viajeros, utilizando Google Chrome (que es mi favorito), no pasaba nada al pulsar el botón de Subir Fotos. Reporté el problema (que creo que ya está corregido) al Servicio Técnico, y me recomendaron probarlo con otro navegador. La prueba con Internet Explorer fue totalmente satisfactoria.

Intentando realizar, esta misma mañana, una transferencia en la web de ING Direct, me encontré con que no pasaba nada al pulsar el botón de Continuar, tras proporcionar todos los datos. Me desconecté y repetí la operación utilizando Internet Explorer, sin ningún problema.

Ante estas experiencias, algún lector suspicaz seguro que me preguntará por qué no uso como favorito el Internet Explorer. La respuesta es muy simple: porque es desesperantemente lento.

Ante un entorno tan terriblemente complejo, hay que tener cintura.

JMBA

Informática en la Nube

Hoy me anima el ánimo pedagógico (divulgador, incluso vulgarizador) y un objetivo ambicioso. Se está hablando mucho en estos días de lo que en inglés se conoce como Cloud Computing, y que en castellano se acepta habitualmente como Informática en la Nube. Las palabras en sí mismas no aclaran absolutamente nada, sólo son la cobertura verbal y fonética de conceptos complejos. Cualquier referencia meteorológica está fuera de lugar.

Al final me ha salido un artículo muy largo, pero prefiero entregarlo de una vez que dividirlo en varios capítulos. Leedlo por partes, o aquellos que ya conozcáis bien la historia, id directamente a la parte del enchufe.

(El ENIAC, con las programadoras Betty Jean Jennings y Fran Bilas, en la Moore School of Electrical Engineering. Fuente: http://www.plyojump.com/classes/mainframe_era.html).

Existen en Internet muchas entradas que describen la historia de la informática, y yo no intento aquí suplirlas. Sin ánimo de ser absolutamente riguroso ni exhaustivo, lo único que pretendo es describir un hilo conductor simplificado (soy consciente de que las cosas han sido y son mucho más complejas de cómo las cuento aquí) que, de modo bastante natural, contra lo que pueda parecer, nos ha llevado hasta aquí. E intentar describir, en modo divulgativo, que resulte comprensible para cualquier no experto, a dónde es que hemos llegado, o que se anuncia que vamos a llegar.

La historia de los ordenadores es del siglo XX. Podríamos ponerle fechas diversas, pero tomemos 1944 (el año de la instalación del ENIAC - Electronic Numeric Integrator And Computer) como un cierto comienzo. De uso básicamente militar, con una capacidad de proceso mínima (en comparación con cualquier portátil de hoy en día), programación por cableado, y toneladas de peso.

Fue en 1951 cuando el primer UNIVAC I se entregó a la Oficina del Censo de Estados Unidos, en lo que podría ser la primera aplicación comercial de los ordenadores.

Los 60 fueron la etapa de desarrollo de los grandes mainframes (el nombre por el que se conoce habitualmente a este tipo de grandes ordenadores monolíticos). Este nombre, con el tiempo, se ha extendido para definir cualquier ordenador de gran potencia, al margen de su arquitectura interna.

(Centro de Cálculo en 1969. Fuente: www.caixatarragona.es).

Si nos situamos en 1970, por ejemplo, la situación en el mercado real de los usuarios potenciales de la informática (las administraciones públicas, los Bancos, las Compañías de Seguros, los sistemas de Reservas de Vuelos, etc.) correspondía a lo que hoy se denomina como Informática Centralizada. Los clientes potenciales eran, en general, todas las organizaciones que debían manejar miles o millones de datos del mismo tipo. El coste de los ordenadores era enorme (muchos millones de dólares, si lo ponemos en una escala que nos resulte comprensible hoy).

Hay que tener en cuenta que la evolución de la informática se ha producido obedeciendo a tres ejes principales:

1) La evolución del hardware (la chatarra, las máquinas). Es decir, la capacidad de la industria de desarrollar, industrializar y poner a disposición a precios viables, componentes progresivamente más potentes y capaces, procesadores más rápidos, etc.

2) La evolución del software (los Sistemas Operativos, los Programas, las Aplicaciones)

3) La evolución de las comunicaciones.

Por tanto, la evolución real de los recursos disponibles para su uso viable por cualquier empresa u organismo ha tenido siempre que ver con el avance relativo de estos tres factores.

En los 60 y buena parte de los 70, el hardware era muy caro (muy costoso I+D, ventas escasas), y las capacidades de las comunicaciones extremadamente limitadas. Esto provocó la aparición de los llamados Centros de Cálculo. Estos eran empresas que invertían en ordenadores y software, y ponían el servicio a disposición de los usuarios. Habitualmente funcionaban como cajas negras. Es decir, el cliente aportaba los datos en formatos entendibles por el ordenador (cinta perforada, tarjetas perforadas,...), o incluso en papel y era el propio personal del Centro de Cálculo el que se encargaba de traducir los datos en papel a un formato entendible por el ordenador.

Los ordenadores procesaban los datos (las nóminas de una empresa, la gestión de facturación, etc.), y producían un material de salida entendible por los humanos (habitualmente interminables listados impresos).

Para finales de los 70, y definitivamente en los 80, hubo una auténtica revolución en la informática. Primero con la introducción del llamado time sharing, o compartición de tiempo. Utilizando los llamados terminales tontos (dumb terminals) se podía acceder directamente al ordenador. Los terminales estaban ligados al ordenador por conexiones dedicadas (fueran locales mediante cables punto a punto o telefónicas de algún tipo), y tenían una capacidad muy limitada de presentación en pantalla de los datos recibidos del ordenador, y de enviarle los que el usuario introdujera mediante el teclado (o tarjetas perforadas, u otro método). Una de las restricciones era la capacidad en cuanto a flujo de datos que tenían las conexiones. Se intentaba que los datos que circulaban entre el ordenador y el terminal fueran los mínimos, para evitar ralentizar en exceso el proceso.

De esta forma, los clientes podían desligarse de entregar papel, cinta perforada o lo que fuera al Centro de Cálculo, y podía introducir los datos directamente desde terminales instalados en sus propias oficinas. Se reducían intermediarios. Por lo tanto, un cliente cualquiera del Centro de Cálculo utilizaba un porcentaje (habitualmente pequeño) de la capacidad de proceso del ordenador allí instalado. Se compartía el tiempo de proceso disponible.

Se empezaron a producir ordenadores más pequeños pero, al producirse en mayor número, muchísimo más baratos en precio.  Se trataba de los llamados miniordenadores, o simplemente minis, en el argot. La capacidad de procesar muchos datos en poco tiempo ya se había convertido en una ventaja competitiva a la que ninguna empresa u organismo que lo hubiera probado podía renunciar. Por ello las grandes corporaciones empezaron a instalar en sus propios locales algún mainframe que, al producirse ya en mayor número, podían tener un precio enorme, pero asequible para algunos negocios. Y empresas más pequeñas pudieron hacer algo equivalente con los minis.

En la práctica, eso fue el final del modelo de negocio de los Centros de Cálculo tal y como se conocieron y proliferaron en los 60 y 70. Las organizaciones se sentían orgullosas de disponer de Informática Propia.

Por esa época había pocas empresas en el mundo con capacidad de producir mainframes (IBM, UNIVAC, Bull, Control Data,...) o incluso miniordenadores (con Digital y HP como nuevos protagonistas, junto a los clásicos).

(Sala con PC,s como puestos de trabajo. Fuente: www.uab.es).

Los 80 trajeron la aparición de los primeros PC,s (Personal Computer, ú Ordenador Personal). Aportaron a las corporaciones la posibilidad de disponer, junto al usuario, de dispositivos con una capacidad notable de proceso. Ello dió inicio a un movimiento pendular extremo, conocido como Informática Distribuida. La mayoría de corporaciones implantaron una arquitectura de este tipo, con tres niveles habitualmente: los servidores centrales o mainframes, los servidores departamentales (los minis o su evolución), y los ordenadores personales como puestos de trabajo. El proceso total se distribuía entre los tres niveles, intentando limitar la cantidad de datos que debían circular por las conexiones, pues éste seguía siendo un recurso escaso y caro.

Era, y es, cierto que la unidad de proceso en los ordenadores más pequeños era más barata que en los grandes mainframes, y se llegó a creer que podían ser intercambiables. La evolución pendular, primando absolutamente los niveles más próximos al usuario, llevó a los gurús, en torno a 1990, a predecir la desaparición del mainframe en unos pocos años. Como otras predicciones, esta acabó resultando absolutamente falsa. Los mainframes se reinventaron a sí mismos, adaptaron su arquitectura a los nuevos componentes disponibles, para reducir su coste, y han perdurado sin problemas hasta la actualidad, y gozan de excelente salud. Sólo que su aspecto monolítico tiende a desaparecer, y hoy los grandes mainframes disponen de cientos, de miles, hasta de cientos de miles de procesadores trabajando al mismo tiempo. Y utilizan, siempre que es posible, componentes estándar, para beneficiarse en el precio del factor volumen.

La Informática Distribuida (con su arquitectura cliente/servidor de las aplicaciones) acabó creando más problemas de los que resolvía, pues se convirtió en Informática Dispersa, con una complejidad de administración que resultó imposible de mantener con el tiempo, especialmente en las grandes corporaciones.

En paralelo, la evolución de las comunicaciones tomó una imparable carrera ascendente. Las primeras redes IP (interconexión de múltiples ordenadores, atendiendo a ciertos protocolos comunes) sembró la semilla de lo que acabaría siendo Internet ya en el siglo XXI. Los límites al flujo de datos que podían circular por las conexiones aumentó varios órdenes de magnitud, y convirtió en viables arquitecturas que nunca antes se habían podido ni siquiera plantear.

Que el puesto de trabajo para cualquiera de los cientos, miles, decenas de miles de usuarios de una corporación fuera un PC complicaba las cosas, porque cada PC tiene vida propia, y requiere de recursos dedicados a su administración. Es vulnerable al ataque de virus informáticos, y tiene una tendencia ineluctable a degradarse por el uso, por la instalación imparable de toda clase de softwares de usuario, necesarios o no para los fines corporativos.

El navegador como herramienta única de acceso a las aplicaciones corporativas supone una evolución que hoy parece irreversible. Un navegador es una pieza de software sofisticada, capaz de interpretar códigos complejos, que puede aportar capacidades de presentación rica de los datos al usuario, y aporta algunas pequeñas capacidades de control y proceso. La proliferación de estándares y nuevos lenguajes (como el HTML, o Java) permite el diseño de las aplicaciones por bloques u objetos que, combinados mágicamente para formar un todo, permiten poner a disposición del usuario toda la capacidad de proceso del mundo (en el límite), por el simple hecho de tener su PC conectado a la Red. Podemos hablar también de clientes ligeros, que pueden ser submodelos de PC, básicamente sólo con un navegador.

Detrás de esa conexión a la Red hay básicamente tres suministros:

a) Capacidad de proceso, que aportan los mainframes, servidores centrales, servidores periféricos, etc.

b) Capacidad de almacenamiento (seguro) de datos

c) Software (aplicaciones y programas) que permiten al usuario realizar todas las funciones de las que tenga necesidad.

(Informática en Red. Fuente: http://encontrarse.wordpress.com).

Con una Informática Propia, todos esos suministros se proporcionan desde el interior de la organización. Existe una Red Interna que facilita las comunicaciones a todos los niveles, así como la salida de los usuarios, cuando es necesaria, a Internet para acceder a otros servicios no disponibles en interno (para obtener informaciones necesarias, para reservar sus billetes de avión ú hoteles, etc.). Estaríamos hablando aquí de la Informática en Red, en el sentido de que el puesto de trabajo puede estar conectado a servidores diversos (internos o externos) para las diversas aplicaciones o funciones que requiera.

(Enchufe eléctrico. Fuente: http://www.gardelonline.com.ar/category/tecnologia/).

El paso a la Informática en la Nube supone la sublimación del concepto de enchufe eléctrico. Todos estamos acostumbrados a que cuando conectamos un dispositivo eléctrico a un enchufe, lo que obtenemos es un suministro ordenado (que obedece a ciertas características y requerimientos) que nos da 220V de diferencia de potencial (por ejemplo), con un límite de intensidad en Amperios (para que no salten los fusibles). En la práctica, la bombilla ilumina cuando la enchufamos. El suministro se paga por la suma de dos componentes. El primero es por disponer del servicio, el segundo es proporcional a lo que efectivamente gastamos (es decir, a cuántas bombillas encendemos y por cuánto tiempo).

Lo que hay por detrás del enchufe (centrales de generación eléctrica, redes de distribución de la energía, parques eólicos, placas fotovoltaicas,...) no constituye ninguna preocupación para el usuario, no son su problema. Para él solamente existe el contrato que tiene con una Compañía Eléctrica, y no existe ningún compromiso de que el kilovatio-hora consumido proceda de esa central hidráulica concreta o de ese molino de viento del pueblo de mi cuñado. Es corriente alterna de un cierto voltaje, y con unos límites de consumo predefinidos. Eso es todo.

Cuando un usuario conecta su PC a la red, en el fondo está haciendo sensiblemente lo mismo que cuando enchufa la licuadora a un enchufe. Espera que todo funcione correctamente, que se genere el zumo de fresas y mandarinas (aportadas por el usuario), y que el aparato no se queme ni se destruya.

Con Informática Propia, todos los recursos que se utilizan por el usuario para realizar su trabajo están bajo el control, la supervisión y la administración de algún departamento de la propia Corporación. Lo que provoca que cualquier gran organismo o empresa tenga muchos recursos humanos dedicados a lidiar con un mal necesario, como es la informática, pero que no es el núcleo de su actividad (la Banca, los Seguros, el servicio al Ciudadano,...). Por ello ya ha habido movimientos muy enérgicos en el sentido del outsourcing, o contratación con una empresa externa de un determinado nivel de Servicio Informático. Y si esta tendencia no se ha extendido más y más rápidamente ha sido por la extrema complejidad (jurídica y legal) que tiene este tipo de contratación, que además debe realizarse para plazos muy prolongados, a fin de que sea financieramente viable también para el proveedor.

Pero, si destilamos los activos informáticos que realmente suponen una ventaja competitiva sostenible para cualquier organización, nos quedaremos con solamente dos factores:

1) Las aplicaciones o programas. Hay algunas muy genéricas, e iguales para todo el mundo (los procesadores de texto, las hojas de cálculo, los editores gráficos, etc.). Pero hay otras aplicaciones específicamente ligadas a una actividad concreta, o incluso a una empresa en particular (la gestión tributaria de un país, la gestión de los productos bancarios de millones de clientes, etc.). Disponer de aplicaciones potentes y flexibles, que permitan a la organización poner en el mercado en el mínimo tiempo posible nuevos productos, que les permitan ir siempre por delante de sus competidores, es una ventaja competitiva irrenunciable.

2) Los datos (de clientes, de proveedores, de empleados, de transacciones, de mercados, etc.).

La propia capacidad de proceso no es más que un mal necesario, la que haga falta para que las actividades de la empresa no se vean ralentizadas por su escasez. Y el cómo se aporte esa capacidad (o las tecnologías empleadas) es, desde luego, absolutamente irrelevante a sus objetivos corporativos.

Por lo tanto, si exportamos las aplicaciones y los datos a algún lugar inconcreto de la Red, donde algún suministrador experto dispone de los recursos informáticos necesarios para proporcionar el nivel de servicio contratado y comprometido, ya estaremos en un entorno de Informática en la Nube.

Por supuesto, necesitamos que nuestras aplicaciones corporativas estén disponibles y sean rápidamente adaptables a las nuevas necesidades diarias del negocio. Y mis Datos deben estar permanentemente accesibles y estar seguros, es decir, a salvo de que se pudieran perder o corromper por cualquier contingencia no deseada. Y a salvo de que pudieran ser robados.

Del mismo modo que se desterró el concepto de que cada casa tenga su generador de electricidad (concepto en parte recuperado con las instalaciones fotovoltaicas y demás; la historia es pendular), la capacidad de proceso informático se deportaría a unas pocas compañías expertas en ello, a imagen de las grandes Compañías Eléctricas del mundo.

(Informática en la Nube. Fuente: www.lapstec.com).

Con la disponibilidad de redes de comunicaciones de gran capacidad y rendimiento, que permiten la transmisión prácticamente inmediata de millones de datos a cualquier lugar del mundo, no existe ningún impedimento técnico para poder llevar adelante esta aproximación.

La extensión de esta aproximación permitirá, sin duda, un aprovechamiento mucho más eficiente de los activos informáticos (bastidores llenos de servidores, o de matrices de discos, o de dispositivos de interconexión), ya que los diferentes husos horarios del mundo permiten un porcentaje de utilización de esos activos mucho más elevado de lo que podría conseguir cualquier usuario individual. Es decir, existe un yacimiento de economías de escala tras esta idea.

Los grandes Centros de Proceso de Datos de las corporaciones dedicadas en todo el mundo a prestar este servicio (recuperaríamos el concepto -actualizado- de los antiguos Centros de Cálculo de los 60) podrían instalarse en el lugar del Mundo que fuera más conveniente. Buscando la mano de obra más barata, o los lugares con temperaturas medias más bajas, limitando así el consumo necesario para la refrigeración de tantas máquinas. Es decir, un auténtico ejercicio de globalización informática.

Pero existe un inhibidor importante a esta aproximación, y es el temor pánico al Gran Apagón, así como las complejidades contractuales para poder estar seguros de que el Nivel de Servicio que definamos será exigible efectivamente, y en todo momento. Porque si mis datos se perdieran, o mis aplicaciones dejaran de estar disponibles, ningún tipo de indemnización podría compensarme, pues, posiblemente, el hecho me habría arrojado fuera del negocio. Así de dramáticas son las cosas en este siglo.

Yo mismo, como autor de este blog, lo tengo alojado, de forma gratuita, en Blogger, que forma parte de la gran corporación Google. Y es gratuito porque la corporación obtiene ingresos de otras fuentes, publicitarias y demás. Pero si un día me buscáis en la Red, y mi blog no aparece en unos pocos segundos, desviaréis vuestra mirada hacia otro lado. Seguro que tengo copia de seguridad de todos los artículos que he publicado (¿todos?¿seguro?), y podría reconstruir el blog en algún otro lugar. Volvería a buscaros, e intentar convenceros de que ya todo es como antes, y así seguiría hacia adelante.

Pero si un día Iberia, o Amadeus, o Banco de Santander, o El País, dejan de estar disponibles en la Red, por el Gran Apagón de algún proveedor, el quebranto para su negocio podría llegar a ser insalvable. Y el Apagón podría ser técnico, pero también financiero.

Además, ¿es que hay o puede haber alguien que controle a esas grandes corporaciones?, un Gran Hermano del siglo XXI, que pueda decidir ceder los datos de mis clientes a mi competidor, o que pueda analizar todos los datos de la Nube, y con ello pueda manipular a los individuos de forma, todavía, más eficiente, para orientarles hacia ciertos patrones de consumo, o hacia ciertas conductas.

Creo que solamente las Economías de Escala, a cambio de todas estas inquietudes y angustias, no es motivo suficiente para que se produzca una migración masiva hacia la Informática en la Nube a corto plazo. Es una obligación para cualquier director el reducir los costes, pero no a cualquier precio.

La Informática en la Nube va a coexistir durante muchos años con otras alternativas (la Informática Propia, o el outsourcing dedicado).

Y es que somos de coche propio, más que alquilado. Si podemos mantenerlo, claro.

JMBA