Gestión Documental Para Gente (Casi) Normal

Un poco de historia.

Los primeros ordenadores con un tamaño y precio asequible para una empresa (grande, desde luego), universidad o Administración Pública compartían una arquitectura común: un ordenador central (normalmente tan grande como una cocina completa) y «terminales» conectadas directamente a él.

Eran los tiempos en los que IBM era una empresa de hardware (regalaban el software), los ingenieros llevaban bata blanca y la informática era una ciencia bastante exótica. Eran los tiempos de los S360, PDP de Digital (utilicé uno brevemente en 1983 y todavía recuerdo que un estudiante de ingeniería de telecomunicaciones me comentaba que sus manuales ocupaban un armario de 2 metros). En la Wikipedia hay algunos artículos muy curiosos, para el que le gusten estas historias de la época de los dinosaurios.

El caso es que la arquitectura o diseño de la instalación era muy sencilla: el ordenador central lo era todo, y los usuarios se conectaban con terminales que no eran más que un teclado y una pantalla. Es lo que ahora llamamos «terminales tontos» o «terminales ligeros», aunque en aquella época no tenían calificativo porque no había otra cosa. Con el tiempo, se ampliaron las posibilidades y se podía conectar una terminal usando una línea de teléfono, pero seguía siendo lo mismo, solo que con cables más largos.

El gran cambio vino de la mano del PC. La bajada de precios y la consiguiente popularización de los ordenadores personales cambió totalmente la situación. Al principio los nuevos ordenadores se conectaban a los «ordenadores centrales» simulando una conexion, pero enseguida surgió la gran pregunta: ¿Por qué no utilizar la potencia de cálculo de mi terminal, su capacidad de almacenamiento «local» y la posibilidad de ejecutar programas de forma independiente al ordenador central? Habían surgido los «terminales inteligentes», con muchas más opciones que los «viejos terminales tontos» (supongo que ahora entenderás el calificativo).

Para complicar aún más las cosas, los «ordenadores centrales» también habían bajado drásticamente de precio y ahora podíamos disponer de varios de ellos y especializarlos en tareas concretas. Pasaron a llamarse «servidores» y a tener apellidos: Servidor de ficheros (para almacenar ficheros o archivos comunes a varios usuarios), servidor de aplicaciones (en los que residen programas que utilizan diferentes personas), servidor de correo electrónico (este no lo explico) o incluso, servidor de firma (electrónica). Hoy, una empresa de un tamaño medio puede tener fácilmente varias decenas de servidores en su CPD (centro de proceso de datos).

A esta variedad de hardware se suma la variedad de software: programas ejecutándose en los puestos de trabajo, o en el servidor. Sistemas basados en «clientes» Web (luego lo explicaré mejor) o «clientes pesados». Bases de datos centrales o distribuidas.

Y no nos olvidemos de la «última moda», el Cloud computing. En este modelo de trabajo, los servidores ni siquiera están físicamente en nuestras instalaciones. Este blog no tengo ni idea de donde está guardado. Puede ser un disco duro en un servidor en EEUU, o en Taiwan. Y puedo consultarlo, y editarlo, desde un PC último modelo con 500 Gb de disco y 4 Gb de RAM en mi casa, en un PC corriente en un hotel en Alemania, o desde mi iPhone. El blog está en la nube.

Hay muchas opciones y, por tanto, muchas decisiones que tomar. Cuando solo hay una opción, la decisión es muy fácil. Pero elegir la arquitectura adecuada para cada caso concreto es hoy una tarea difícil porque las combinaciones son muchas. Si hablaba en mi primera entrada de que la arquitectura de un sistema es el conjunto de partes que lo componen y cómo se conectan entre sí, hoy tenemos un puzzle con muchas piezas, de muy diversos tamaños y formas y conectadas con una maraña de hilos de todos los colores y tamaños.

En la siguiente entrada empezaré a describirlos con más detalle y, sobre todo, a comentar las ventajas e inconvenientes de cada uno para que elijamos los más adecuados.