El movimiento NoSQL (II)

El movimiento NoSQL (II)

Seguimos tratando las bases de datos NoSQL, de las que ya empezamos a hablar en la entrada anterior. NoSQL se orienta principalmente a entornos altamente distribuidos –donde existen miles de ordenadores (o nodos) trabajando de manera colaborativa– que necesitan gestionar grandes volúmenes de datos con alta disponibilidad. La mayoría de estos sistemas usan la replicación y fragmentación de los datos, y explotan el paralelismo para potenciar la escalabilidad y la disponibilidad. Además, a diferencia de los gestores de bases de datos relacionales, en este tipo de soluciones es posible añadir nuevos nodos (normalmente “en caliente”) para conseguir mayor capacidad. Esto se conoce como escalabilidad horizontal. En este contexto, es necesario considerar la conjetura de Brewer, también conocida como teorema CAP (Consistency, Availability and tolerance to network Partition). Dicho teorema establece que en un sistema distribuido es imposible conseguir simultáneamente las tres características, y que en consecuencia es necesario elegir dos de las tres. La consistencia (consistency) se refiere a la capacidad de que se puedan recuperar siempre los mismos datos en un mismo instante de tiempo. Por su parte la disponibilidad (availability) se refiere a que si alguno de los nodos del sistema distribuido no se encuentra disponible, el resto pueda seguir trabajando. Finalmente, la tolerancia a la partición de red (tolerance to network partition) significa que el sistema distribuido pueda seguir operando, incluso ante posibles fallos en parte de la red de comunicaciones. La tolerancia a la partición de red, más que una decisión, constituye una necesidad en la mayoría de sistemas altamente distribuidos. Por lo tanto, la decisión consiste en elegir entre consistencia o disponibilidad, y en...
El movimiento NoSQL (I)

El movimiento NoSQL (I)

El pasado 6 de Octubre se celebró en la Casa de la Convalescència de Barcelona la conferencia NoSQL Matters . La conferencia incluyó diferentes ponencias donde se trataban aspectos técnicos, presentación de productos y casos de uso. Algunas de estas ponencias están comentadas en el blog «Alapamui!«. La organización fue impecable e incluyó contenidos interesantes, proporcionando además un marco adecuado para que asistentes y ponentes pudieran compartir experiencias e inquietudes. Bajo la denominación NoSQL (Not Only SQL) se engloba un amplio abanico de tecnologías para gestionar y analizar datos en entornos de aplicación donde las bases de datos relacionales no son la mejor solución, invalidando la máxima one size fits all esgrimida en ocasiones por los fabricantes de gestores de bases de datos relacionales. Existen diferentes propuestas de bases de datos NoSQL, buena parte de ellas tratadas en NoSQL Matters, y cuyas principales tendencias pueden resumirse en 3 grandes grupos: 1) Almacenes clave-valor (Key-value stores), que emulan el funcionamiento de las tablas de dispersión (hash tables), como sería el caso del sistema Dynamo desarrollado por Amazon, Redis, y los populares almacenes para grandes datos (Big data stores) como BigTable de Google, su versión de código abierto Apache HBase y Cassandra, liberado por Facebook y ahora proyecto Apache. Los almacenes para grandes datos añaden el concepto de familias al de clave-valor para explotar el almacenamiento físico por columnas. 2) Bases de datos documentales, que se orientan al almacenamiento y recuperación  eficiente de documentos. Son similares a los almacenes clave-valor, con la peculiaridad que el valor es el documento en sí mismo. Algunos ejemplos serían MongoDB, Couchbase y Riak. 3) Bases...

Buenas noticias para la gestión de proyectos

Los libros y artículos de gestión de proyectos comienzan con las cifras apocalípticas de los desastres de gestión (el famoso informe anual del Standish Group, llamado el “Informe del Caos”, o el blog de Michael Krigsman titulado “IT Failures” han hecho del desastre una razonable manera de ganarse la vida) y el reparto de culpas entre los sospechosos habituales (las “principales causas de fracaso” ). Luego está la sección y las webs de chistes y bromas. Nosotros, en las asignaturas de gestión de proyectos solemos empezar con un debate donde los estudiantes, muchos de ellos profesionales, ponen en común sus experiencias de fracasos (y a veces también de éxitos). “El fracaso es la madre del éxito”, dicen que decía Confucio. Este año estamos usando para el debate la estupenda y “seminal” entrada de Robert Clarisó sobre el hundimiento del barco “Vasa”. Pero un paseo reciente por algunas noticias profesionales da algunos motivos de alegría a nuestra profesión, que siempre creemos maltrecha y poco reconocida. Fuera de las cifras del Standish Group, si miramos otras fuentes más ponderadas, las cosas no son tan graves, si puede decirse. El informe más o menos anual de Gartner de este año (“Survey Shows Why Project Fails”, ID: G00231952; los estudiantes de la UOC tienen acceso a la base de datos de Gartner) viene a decir que un 75% de los proyectos suelen salir bien y las cifras van mejorando. Lo pequeño es hermoso: las cifras aumentan hasta el 80% en los proyectos más pequeños y algunas compañías están implantando mecanismos para limitar el tamaño máximo de cualquier proyecto. Cuanto más grande, más equivocado, especialmente...

Ágil

En nuestros primeros blogs de gestión de proyectos empezamos, como casi todo el mundo, por los chistes, los fracasos y las mentiras (1, 2). Analizábamos las causas del fracaso y nos salían temas de tipo más organizativo (involucración de usuarios y directivos, presiones económicas que afectan al tiempo y coste), que de tipo técnico o de gestión del proyecto (requerimientos poco definidos, pruebas insuficientes). La mejora de la gestión de proyectos como disciplina y profesión y la introducción y práctica de la cultura de proyectos dentro de las empresas ha mejorado en el ciclo largo la calidad y resultados de los proyectos, más o menos hasta principios de los 2000, pero en los últimos años tiene un efecto marginal. Aproximadamente, un cuarto de los proyectos son un fracaso total y más o menos un tercio pues ni fu ni fa. El enfoque tradicional y bien establecido de la gestión de proyectos, en las TIC y en cualquier otra cosa, se basa en la obsesión por la predictibilidad y el cumplimiento, soportados por liderazgos fuertes y documentación exhaustiva. Si definimos bien el alcance, si tenemos un buen plan y si todas las partes lo cumplen y nos dirige un buen jefe, el proyecto será un éxito. Pero lo es pocas veces. El cliente y los usuarios no saben bien lo que quieren y lo cambian continuamente (o no saben explicarlo, o el analista no los entiende), aceptamos presupuestos cortos que sabemos que no podremos cumplir (también lo sabe el comprador) y las empresas no hacen lo que tienen que hacer para que el proyecto y sus resultados sirvan para algo....

Reducir el fracaso en los proyectos de Business Intelligence (I)

El próximo miércoles 25 se celebra en Barcelona un Foro Profesional sobre Inteligencia de Negocio (1), en el que intervendrá el profesor Jordi Conesa, referente de la UOC en estos temas (2). Los últimos días nos hemos cruzado con él y con la profesora Isabel Guitart algún correo y comentarios sobre su intervención, dirigida a discutir los factores de éxito en la implantación de proyectos BI. Por mi lado, no me atrevo a decir factores de éxito, la verdad. Pocos proyectos puedo imaginar tan caros, complejos, inciertos; pocos con tantos fracasos en calidad, tiempo, coste y, sobre todo, satisfacción de los clientes; pocos en que la promesa sea tan grande (aumentar la información y el conocimiento organizativo para conseguir mejores resultados y obtener ventaja competitiva) y el resultado tan pobre; pocos en que el enorme esfuerzo de la organización y los implantadores sea tan difícil de convertir en beneficios. Apenas a partir de mi experiencia, la de otros que saben más que yo y alguna literatura, me atrevo a sugerir algunas prácticas que no van mal para hacer las cosas un poco mejor. Como quedará un poco largo, lo haré en un par de entregas (3). 1)     Para qué hace falta el proyecto. No es trivial. Según los objetivos que quiere conseguir la empresa, cada proyecto es distinto o a lo mejor ni siquiera hace falta. No es igual un cuadro de mando de dirección que un sistema de analítica de costes para los financieros que un portal de datos de toda clase para decenas de unidades de negocio y cuadros intermedios que un sistema de inteligencia comercial que...