The importance of BI-ing audited

Posted on by Àlex Caminals

Building a Business Intelligence (BI) solution could be compared to constructing a building. We need to build this solution on a solid foundation, which allows us to build different projects, with the security of being based on a structure that allows us to grow.

But, if everyone accepts this statement in construction, why are there organizations that opt ​​for another strategy when it comes to building a BI solution?

Building on a weak foundation

Some time ago, I worked in a project for a client who made a serious mistake. I called this project «The Leaning Tower of Pisa».

This client contacted me because in that organization they had several problems with their BI solution. The most important one was functional. They could not get correct results. So the client wanted an expert consulting service, which would allow them to identify and solve existing errors. They had tried to solve it by asking the consultancy company who had built the BI solution to do it, but they were unable to find the solution to these problems.

Given the urgency of the client, my objective was focused solely and exclusively on the resolution of the issues detected. Therefore, I set aside my usual top-down approach to focus on the problems identified. However, I could quickly identify that the problems causing these incidents had their origin in design flaws of the existing BI solution.

I decided to write a report detailing the implications of these system design errors along with a Pros & Cons analysis of maintaining or solving those errors.

I also stressed the fact of having built a BI system without any validation of its quality. They had not made any kind of inquiry into previous clients of that consultancy company nor had they opted for the validation of the design of their service provider by an independent expert. They had accepted the project blindly. And it was a project with transversal visibility in the organization, where the impact could affect decision making in all areas and levels of the organization.

A risky decision

They were building a giant with mud feet. At that time, I gave them the example of the Leaning Tower of Pisa. They were at the point where they discovered that the tower was not straight. It was time to decide what to do. If they went ahead, they ran the risk that the BI solution would be impossible to maintain in the future, having to make a large investment to rebuild it. If they decided to solve the foundation issues, they would have an extra cost not being budgeted, but in the long run, the cost would be much lower.

My client wanted a quick solution. This is why they chose to go ahead with the resolution of the issues detected initially, without solving the design flaws of their BI solution. So, I focused to solve them, not before warning them again of the risk that this could entail in the future, in the event that they wanted to expand the existing BI solution.

A wrong decision falls under its own weight

I think it was after a couple of months of finishing the service for which I was hired, that I received a call from the same client. They were desperate. They had a new BI project under development, but there was no way to make it work. Neither their usual service provider nor their internal BI team were able to move forward the project. When they tried to implement a new functionality, they caused other existing functionalities to stop working. They were in a dead end. The Leaning Tower of Pisa could not grow anymore.

This time, my client opted for a different approach. They asked me to evaluate the possibility of finishing the project, but also to estimate the cost involved in rebuilding the whole BI solution in order to have a scalable system that could easily grow in the future.

When presenting my proposal, I stressed the importance of evaluating long-term costs. That had been their big mistake when they initially contacted me. In a BI project, it is very important to take into account future projects when calculating the Return on Investment (ROI). This time they did it. And they came to the right conclusion in their situation. They decided to rebuild their BI solution.

Such was the confidence I got from the client that, instead of hiring the services of a larger consultancy firm than StraBIA, they decided to entrust me with the project to rebuild their BI solution. That was the beginning of a satisfactory professional relationship.

Conclusion

A BI solution is an information system with a wide visibility in an organization, since it is used for decision making at all levels and in all business areas. Being such an important system, it is a must ensuring that it meets the required level of quality. This is even more important due to the fact that it is a type of project with a very low number of experts when compared to application development projects, for instance.

Everytime I’m in charge of maintaining or expanding a project in a new client with an existing BI solution, I spend some time to analysing it, identifying areas for improvement. I know that by doing this, some of my clients have avoided unpleasant situations in the future. That encourages me to continue doing it, even if StraBIA does get the fix and improvement project.

Fortunately, this is not always the case, and sometimes, like in this case I just told you about, we are assigned the project. And in these cases, an audit of the new BI system would evaluate the new solution with a very good mark.

I would like to finish with a couple of questions:

  • Do you think that your current BI solution is ready to grow while maintaining the levels of performance, effectiveness and maintainability required by your business?
  • Do you think that your current BI solution would pass an audit?

If you have answered «No» to any of these questions, I hope this article makes you think of the risks that you may face in the future.

La importancia de una auditoría de BI

Posted on by Àlex Caminals

La construcción de una solución de Business Intelligence (BI), podría compararse a la construcción de un edificio. Necesitamos cimentar esta solución sobre una base sólida, que nos permita construir los diferentes proyectos, con la seguridad de estar aposentados sobre una estructura que nos permita crecer.

Pero, si todo el mundo acepta esto en la construcción, ¿porqué hay organizaciones que optan por otra estrategia a la hora de construir una solución de BI?

Una base poco sólida

Hace tiempo, realicé un proyecto para un cliente que cometió un grave error. A este proyecto lo bauticé como «La torre de Pisa».

Este cliente contactó conmigo porque en su organización tenían varios problemas con su solución de BI. El más importante de ellos era funcional. No conseguían obtener resultados correctos. Querían un servicio de consultoría experto, que les permitiese identificar y solucionar los errores existentes. Habían intentado solucionarlo con la consultora que les había construido la solución de BI, pero éstos fueron incapaces de hallar la solución a dichos problemas.

Dada la urgencia del cliente, mi objetivo se centró única y exclusivamente en la resolución de las incidencias detectadas. Por tanto, dejé de lado mi enfoque habitual (top-down), para focalizarme en los problemas identificados. Sin embargo, rápidamente pude observar que los problemas que causaban dichas incidencias, tenían su origen en fallos de diseño de la solución de BI existente.

Lo siguiente que hice, fue un informe detallando las implicaciones de estos errores de diseño dentro del sistema junto con un análisis de pros y contras del hecho de mantener o solucionar esos errores.

Pero también hice hincapié en el hecho de haber construido un sistema de BI sin ningún tipo de validación de la calidad de éste por parte de nadie. No habían hecho ningún tipo de indagación en clientes anteriores de esa consultora ni habían optado por la validación del diseño de un experto sobre el trabajo de su proveedor de servicios. Habían aceptado el proyecto con una fe ciega. Y se trataba de un proyecto con una visibilidad transversal en su organización, donde las repercusiones podían afectar a la toma de decisiones en todas las áreas y niveles de la organización.

Una decisión arriesgada

Estaban construyendo un gigante con pies de barro. En ese momento, les puse como ejemplo la torre de Pisa. Se encontraban en el punto en el que vieron como la torre estaba inclinada. Era el momento de decidir qué hacer. Si seguían adelante, corrían el riesgo de que la solución de BI fuera imposible de mantener en un futuro, teniendo que realizar una gran inversión para reconstruirla. Si decidían solucionar los problemas de base, tendrían un sobrecoste no presupuestado, pero a la larga, el coste sería mucho menor.

Mi cliente quería una solución rápida. Es por eso por lo que optó por seguir adelante con una resolución de las incidencias detectadas inicialmente, sin solventar los problemas de base en el diseño de su solución de BI. Así pues, me dediqué a solucionar las incidencias, no sin antes advertir del riesgo que ello podría suponer de cara al futuro, en el caso de que quisieran ampliar la solución de BI existente.

Una decisión errónea cae por su propio peso

Creo que fue al cabo de un par de meses de haber acabado el servicio por el que me contrataron, que recibí una llamada del mismo cliente. Estaban desesperados. Tenían un nuevo proyecto de BI en fase de desarrollo, pero no había manera de hacerlo funcionar. Ni su proveedor de servicios habitual ni su equipo interno eran capaces de seguir adelante con el proyecto. Cuando intentaban implementar una nueva funcionalidad, provocaban que otras funcionalidades ya existentes dejaran de funcionar. Se encontraban en un callejón sin salida. La torre de Pisa no podía crecer más.

Esta vez, mi cliente optó por un enfoque diferente. Me pidió que evaluara la posibilidad de finalizar el proyecto con el que estaban atascados, pero también una estimación del coste que supondría la reconstrucción de su solución de BI para poder disponer de un sistema escalable que pudiera crecer en el futuro de manera simple.

Al presentar mi propuesta, les indiqué la importancia de evaluar los costes a largo plazo. Ese había sido su gran error la primera de contactaron conmigo. En un proyecto de BI, es muy importante tener en cuenta los futuros proyectos a la hora de calcular el Retorno de Inversión (ROI). Así lo hicieron. Y llegaron a la conclusión más acertada en su situación. Decidieron reconstruir su solución de BI.

Tal fue la confianza que obtuve del cliente, que, en lugar de contratar los servicios de una consultora de más envergadura que StraBIA, decidieron encargarme el proyecto de reconstrucción de su solución de BI íntegramente. Aquello fue el principio de una satisfactoria relación profesional.

Conclusión

Una solución de BI es un sistema con una amplia visibilidad en una organización, ya que se utiliza para la toma de decisiones a todos los niveles y en todas las áreas de ésta. Al ser un sistema tan importante, es necesario estar plenamente convencido de que su construcción satisface los requerimientos de un sistema de BI. Esto goza aún de más importancia por el hecho de ser un tipo de proyecto con un número de expertos muy bajo si lo comparamos con proyectos de desarrollo de aplicaciones, por ejemplo.

Siempre que realizo un proyecto en un nuevo cliente con una solución existente de BI, intento dedicar un poco de tiempo a su análisis, identificando áreas de mejora. Sé que, haciendo esto, algunos de mis clientes han evitado situaciones desagradables en el futuro. Eso me anima a seguir haciéndolo, aunque no sea StraBIA quien acabe realizando el proyecto.

Afortunadamente, esto no es siempre así, y en ocasiones como la que os acabo de contar, sí que acabamos realizando el proyecto. Y en estos casos, una auditoría del nuevo sistema BI evaluaría la nueva solución con muy buena nota.

Quisiera finalizar con un par de preguntas:

  • ¿Crees que tu actual solución de BI está preparada para crecer manteniendo los niveles de rendimiento, efectividad y mantenibilidad requeridos por tu negocio?
  • ¿Crees que tu actual solución de BI superaría una auditoría?

Si has respondido «No» a alguna de estas preguntas, espero que este artículo te haga reflexionar sobre los riesgos a los que te puedes enfrentar en el futuro.

¿What is Big Data?

Posted on by Àlex Caminals

 

Big Data is fashionable. It is interesting to see how the vast majority of people have heard the term Big Data at some time even though they do not belong to the business or technological world.

But it is also very interesting to hear the great variety of definitions that emerge when people are asked about Big Data. In this article I am going to try to solve a doubt that many of you have: What is Big Data?

 

Big Data definition

Big Data is a set of techniques and technologies that allow data analysis.

These techniques and technologies allow us to store, transform, analyze and visualize data efficiently. And thanks to this, we can meet the present analysis needs of the organisations, with a level of demand much higher than a few years ago.

That is, Big Data needs to be used in scenarios where a traditional BI solution (used for data analysis) is not suitable to meet the required analysis objectives.

Definition of a Big Data scenario

Big Data should be used in situations where data analysis is not possible efficiently using a traditional Business Intelligence (BI) solution. These situations have historically been associated with what is known as the 3 V’s: volume, velocity and variety. Some people include other V’s in this list such as veracity, volatility, validity, visibility and variability, but the most common definition is still that of the 3 V’s.

Volume

Massive data volume means a very high amount of data. When massive data exists, it can no longer be handled efficiently by traditional data repositories. These are, in the vast majority of cases, relational databases, which, despite having evolved in the recent years to be more efficient and to run on more powerful hardware than before, are still a bottleneck for the efficient storage and query of large volumes of data.

The use of this type of storage systems for analysis of large volumes of data can take them beyond the limits for which they were designed, producing a decrease in performance when storing and accessing data. These limits vary depending on the hardware and software, so it is almost impossible to draw a line to delimit the beginning of massive data. A few years ago this limit was of the order of gigabytes, while today, with recent innovations in hardware and software, it’s around a few terabytes.

Velocity

When someone analyzes data, it does it with the aim of finding an answer to a question, within a timeframe in which that answer will bring some value. If that answer arrives late, it lacks all of its value and the opportunity is gone.

For example, analyzing vehicle and mobile devices location can provide information on traffic flow. In this scenario, the question we want to answer could be: «At what speed are vehicles moving?». If the vehicle and mobile device data could be obtained and analyzed in a very short timeframe, it would be very useful, since we could visualize the data in a map to offer «updated» information of the traffic density in each road (urban or interurban). However, if this answer is obtained one hour late, it will not be useful to the drivers.

Therefore, it is clear that velocity is a key factor when making decisions.

This velocity to obtain an answer from the data can be broken down into two components: the data loading speed (obtaining, processing and storing) and the speed of information analysis (extraction of knowledge through data analysis techniques such as statistics or artificial intelligence).

If any of these components is slow, there is a risk of exceeding the upper bound for the response time, which will result in no value to the user.

A traditional BI system, due to its design and architecture, has a delay in bringing the data into the repository which usually ranges from a few minutes (in specific cases such as Lambda architectures) to 24 hours (in a scenario of daily data loads), although it could be higher. If we take the previous scenario (traffic), a traditional BI clearly could not satisfy the requirements to have the information updated in near real time.

Variety

The traditional data types used to store data are three: numeric, character strings and dates. Historically, when there was a need to analyze data types beyond these, specialized applications were used, which were outside of what are considered BI tools.

For example, for years there were applications and libraries that allowed analyzing images and being able to obtain answers to questions such as «Does a green color appear in the image?» (which could be very useful to know the time elapsed in the growth of a fungus in a laboratory culture). But those applications and libraries were not integrated into traditional BI tools.

Therefore, the analysis of data types beyond the traditional ones was not considered, in the past, as something feasible within a BI solution.

Currently, with the growth of data available in organizations and on the Internet, there is an increasing need to find answers from non-basic data types, including audios, photographs, videos, geolocations, etc. When this is a requirement, the use of Big Data is a must.

Differences between a traditional BI and Big Data

Without going into technicalities, the following table tries to summarize the most important differences between traditional BI and Big Data:

FactorTraditionalBig Data
VolumeFew TerabytesTerabytes and above
VelocityPeriodic data loads (typically daily)Higher frequency in data loads → Real time
VarietyBasic data typesVirtually any data type
ComputationCentralized in a single computerDistributed
HardwareHigh specificationsAny (Commodity hardware)
ScalabilityDifficultSimple
Data quality (veracity)Very importantRelative importance (a certain degree of uncertainty is assumed)

Conclusion

Big Data allows us to bring data analysis beyond the traditional BI capabilties. It is a response to the needs of users, just as BI was in the past with respect to older technology. This does not mean that BI should be put aside as a valid alternative when analyzing data. On the contrary, it should always be an option to explore.

However, when the users’ needs include the use of massive data (volume), with responses obtained in a very short timeframe (velocity) or obtained from complex data types (variety), we must discard traditional BI due to its limitations, and go for the use of a solution with Big Data.

Veracidad: ¿La 4ª «V» de Big Data?

Posted on by Àlex Caminals

En el artículo «¿Qué es Big Data?«, os expliqué las tres situaciones que pueden definir un escenario donde es necesario aplicar una solución de Big Data. Éstas se definen como las 3 V’s. Hay gente que incluye otras V’s al hablar de Big Data.

Hoy os hablaré de la V de veracidad, puesto que una lectura errónea de ésta puede llevar a malas interpretaciones.

Calidad de datos

Para realizar el mejor análisis de datos que podamos imaginar, necesitamos disponer de un conjunto de datos completo y con una calidad de datos impoluta.

Estas condiciones son las ideales, pero lo cierto es que la realidad nos presenta escenarios que difieren de esta situación ideal. Es por eso que, durante la carga de datos (ETL), hay que realizar un proceso de verificación de los datos. Es lo que se conoce como el proceso de limpieza de datos, durante el cual se intentan arreglar los datos incorrectos o incompletos para así poder disponer de un conjunto de datos útil para su análisis posterior.

Este proceso de limpieza de datos incluye la aplicación de normas de dominio sobre los datos (e.g. Verificar que la provincia informada corresponde al país informado), de formato (e.g. Los números de teléfono empezarán todos con el código internacional con un «+» al principio y solamente contendrán números a continuación, sin espacios, puntos, guiones, etc.), y de negocio (e.g. El descuento «ABC» no aplica a clientes que compren por un valor inferior al millón de euros anuales).

Así pues, los datos que pueden ser arreglados durante la carga de datos, serán modificados para asegurar una buena calidad, mientras que los que no puedan ser arreglados, serán descartados y marcados como pendientes de arreglar en el sistema origen. De esta manera, conseguimos aumentar la calidad de datos no solo en el repositorio de datos destino de la carga, sino también en los sistemas origen.

Un gran coste en un escenario Big Data

El problema de realizar un proceso de limpieza de los datos durante la carga de éstos, es que es un proceso costoso. Muy costoso.

Sabemos que Big Data trabaja en muchos casos con datos masivos o con la necesidad de disponer de los datos con una latencia (retraso) muy baja. Por tanto, no puede perder ese tiempo en un proceso de verificación y limpieza de datos.

Y aquí aparece la contraposición de intereses. ¿Es Big Data incompatible con el hecho de tener un buen análisis de datos? La respuesta es que no es incompatible, aunque deberíamos analizar qué entendemos por «buen análisis».

En un escenario tradicional de Business Intelligence (BI), por ejemplo, basado en el análisis de información comercial, es importante que la calidad de datos sea correcta, sin errores. Si el importe de una venta es incorrecto, o si una venta no se carga en el repositorio analítico, no podremos obtener análisis de ventas que muestren un resultado correcto. Es decir, para obtener una visión exacta de la realidad, es necesario aplicar un proceso de limpieza de datos para evitar la pérdida de información durante la carga de datos.

Pero, por otra parte, en un escenario de Big Data, por ejemplo, basado en la obtención de lecturas de temperatura cada 5″ mediante 100 sensores repartidos por toda la ciudad, ¿es necesario tener una visión exacta de esa realidad? ¿Necesito saber la temperatura media exacta? Seguramente no. Por tanto, situaciones anómalas pueden ser aceptadas sin la necesidad de limpiar los datos.

Incertidumbre

Estas situaciones anómalas pueden introducir errores en los datos. En otras palabras, provocan que la veracidad de los datos y de los resultados del análisis de éstos sea incierto. Pero en Big Data trabajamos con grandes volúmenes de datos. Y tener errores en algunos de ellos, no tiene porqué distorsionar en gran manera el resultado del análisis. Por ejemplo, ¿una temperatura ambiente media de 20,375°C (incluyendo anomalías) sería aceptable si la temperatura real fuese 20,384°C? Estoy convencido de que así es para la gran mayoría de personas.

En Big Data, podemos distinguir entre los siguientes tipos de incertidumbre en función de dónde y cómo se genera ésta:

• Adquisición de los datos: Como ejemplo, pensemos en un sensor, un trozo de hardware, susceptible a errores de lectura. Si la temperatura leída es de 20°C durante 1 hora pero nos encontramos con una única lectura durante este periodo con un valor de 28°C (con su predecesor y sucesor, separados 5″, marcando 20°C ), podemos considerar que se trata de un error de lectura, un error de funcionamiento del sensor.
• Proceso de los datos: Imaginemos ahora, que hay un fallo de comunicación en un sector de la ciudad y no nos llega información durante 30′ de los 20 sensores que hay desplegados en esa zona. Los datos se perderán y no podremos hacer nada al respecto. Pero podemos continuaremos analizando los datos recibidos y mostrándolos en tiempo real. De hecho, para los datos no disponibles, podría mostrar la última información recibida o hacer una previsión en función de datos históricos y los datos del resto de sensores.
• Análisis de datos: El tipo de análisis de datos a realizar también puede introducir incertidumbre. En el caso de una predicción, existe un grado de confianza que debemos elegir. Si utilizamos un algoritmo de clustering para agrupar datos, también introducimos incertidumbre en el análisis. Es decir, el propio algoritmo utilizado incluye cierto nivel de incertidumbre.

Por tanto, Big Data, por sus propias características, introduce de por sí elementos que pueden provocar que el resultado del análisis de los datos no sea fiable al 100%.

Cuando pensamos en Big Data no debemos pensar en el análisi de todos los datos disponibles como en un BI tradicional, mostrando resultados exactos y 100% fiables. Debemos verlo como un análisis con un alto grado de fiabilidad (obtenido a partir del uso de datos masivos), pero con cierto grado de incertidumbre, que proporcionará información útil para la toma de decisiones.

Conclusión

El uso de Big Data viene precedido por una necesidad, ya sea de tratar un escenario con un gran volumen de datos, con una velocidad de tratamiento de éstos muy elevada o con variedad de tipos de datos, entendiendo ésta como el uso de tipos de datos no convencionales. Esto se conoce como las 3 V’s del Big Data.

Incluir una cuarta V para la veracidad puede causar confusión, puesto que no se trata de una necesidad de veracidad la que hace que tengamos que aplicar Big Data, tal y como sucede con el volumen, la velocidad y la variedad.

La realidad es que Big Data introduce cierto grado de incertidumbre durante el proceso de adquisición, proceso y análisis de datos.

Sin embargo, a pesar de este grado de incertidumbre, el hecho de trabajar con datos masivos nos permite obtener análisis de datos con una fiabilidad muy alta, lo cual justifica el uso de Big Data.

¿Qué es Big Data?

Posted on by Àlex Caminals

 

El Big Data está de moda. Es interesante comprobar como la gran mayoría de la gente ha oído hablar del Big Data alguna vez aunque no pertenezcan ni al mundo empresarial ni tecnológico.

Pero también es muy interesante oir la gran variedad de definiciones que afloran cuando la gente es preguntada acerca del Big Data. En este artículo voy a intentar resolver esa duda que muchos tenéis: ¿Qué es Big Data?

 

Definición de Big Data

Big Data es un conjunto de técnicas y tecnologías que permiten el análisis de datos.

Estas técnicas y tecnologías nos permiten almacenar, transformar, analizar y visualizar los datos de manera eficiente. Y gracias a esto, podemos satisfacer las necesidades de análisis de existentes hoy en día, con un nivel de exigencia mucho más elevado que el que existía hace unos años.

Es decir, utilizaremos Big Data en escenarios donde una solución de BI tradicional (usada para el análisis de datos) no nos permite satisfacer los objetivos del cliente.

Definición de un escenario Big Data

Big Data debe utilizarse en situaciones en las que el análisis de datos no es posible de manera eficiente mediante una solución de Business Intelligence (BI) tradicional. Estas situaciones se han asociado históricamente a lo que se conoce como las 3 V’s: Volumen, velocidad y variedad. Cierto es que hay personas que incluyen otras V’s como la veracidad, la volatilidad, la validez, la visibilidad y la variabilidad, pero la definición más extendida sigue siendo la de las 3 V’s.

Volumen

Por volúmenes masivos se entiende una cantidad de datos muy elevada, que deja de ser manipulada de manera eficiente por los repositorios de datos tradicionales. Éstos son, en la gran mayoría de casos, bases de datos relacionales, que aunque hayan evolucionado en los últimos años para ser más eficientes y puedan ejecutarse en un hardware más potente que antaño, siguen siendo un cuello de botella para el almacenaje de grandes volúmenes de datos.

El uso de este tipo de sistemas de almacenaje para el análisis de grandes volúmenes de datos, puede llevarlos más allá de los límites para los que fueron diseñados, produciendo un descenso en el rendimiento en el almacenaje y acceso a la información. Estos límites varían en función del hardware y el software utilizados, por lo que se hace casi imposible trazar una línea para delimitar el inicio de lo que se puede considerar volúmenes masivos. Hace unos años este límite era del orden de gigabytes, mientras que hoy en día, con las innovaciones recientes en el hardware y el software, estamos hablando del orden de los pocos terabytes.

Velocidad

Cuando alguien analiza datos, lo hace con el objetivo de hallar una respuesta a una pregunta, dentro de un espacio temporal en el cual esa respuesta le aportará un beneficio. Si esa respuesta llega fuera de ese margen de tiempo, carece de valor.

Por ejemplo, el análisis de la localización de vehículos y dispositivos móviles puede proporcionar información sobre la fluidez del tráfico. En este escenario, la pregunta sería: «¿A qué velocidad se desplazan los vehículos por las vías en las que están circulando?». Si estos datos proporcionan en un corto espacio de tiempo la respuesta a esta pregunta, pueden ser muy útiles, ya que las podemos mostrar en un navegador para ofrecer información «actualizada» de la densidad del tráfico en cada vía (urbana o interurbana) de la que dispongamos datos. Sin embargo, si esta respuesta la obtenemos con una hora de retraso, no nos será útil para mostrar en un navegador.

Por tanto, queda claro que la velocidad es un factor clave a la hora de tomar decisiones.

Esta velocidad para obtener una respuesta a partir de los datos puede desglosarse en dos componentes: la velocidad de carga del dato (obtención, transformación y almacenamiento) y la velocidad de análisis de la información (explotación del dato mediante técnicas de análisis de datos como son la estadística o la inteligencia artificial).

Si alguna de estas velocidades es baja, se corre el riesgo de sobrepasar el límite de validez de la respuesta, con lo que ésta carecerá de valor para el usuario.

Un sistema de BI tradicional, debido a su diseño y arquitectura, tiene una velocidad de respuesta desde la aparición del evento que genera un dato, que suele ir de entre algunos minutos (en casos concretos como es el caso de arquitecturas lambda) a las 24 horas (en un escenario de cargas de datos diarias), aunque podría llegar a ser superior. Si tomamos el escenario del ejemplo del tráfico, un BI tradicional claramente no podría satisfacer los requerimientos de los conductores.

Variedad

Los tipos de datos tradicionales son tres: numéricos, cadenas de caracteres y fechas. Históricamente, cuando había necesidad de analizar tipos de datos más allá de éstos, se recurría a aplicaciones especializadas, que quedaban fuera de lo que se consideran las herramientas de BI.

Por ejemplo, hace años que existían aplicaciones y librerías que permitían analizar imágenes y poder obtener respuestas a preguntas como «¿Aparece algún color verde en la imagen?» (que podría ser muy útil para saber el tiempo transcurrido en el crecimiento de un hongo en un cultivo de laboratorio). Pero esas aplicaciones y librerías no estaban integradas en una herramienta de BI tradicional.

Por tanto, el análisis de tipos de datos más allá de los tradicionales no se consideraba, en el pasado, como algo factible dentro de una solución de BI.

En la actualidad, con el crecimiento de los datos disponibles en las organizaciones y en Internet, cada vez hay más necesidad de encontrar respuestas a partir de datos no básicos, entre los que se incluyen audios, fotografías, vídeos, geolocalizaciones, etc. Cuando este es un requerimiento, nos encontramos delante de un escenario donde es necesaria la aplicación de Big Data.

Diferencias entre un BI tradicional y Big Data

Sin entrar en tecnicidades, la siguiente tabla intenta resumir las diferencias más importantes entre un BI tradicional y Big Data:

FactorTradicionalBig Data
VolumenPocos TerabytesTerabytes y superior
VelocidadCargas periódicas (típicamente diarias)Reducción del tiempo entre cargas de datos → Tiempo real
VariedadTipos de datos básicosVirtualmente, cualquier tipo de datos
ComputaciónCentralizada en una única máquinaDistribuida
HardwareAltas especificacionesCualquiera (Commodity hardware)
EscalabilidadDifícilSimple
Calidad de datos (veracidad)Muy importanteImportancia relativa (se asume cierto grado de incertidumbre)

Conclusión

El Big Data nos permite llegar más allá en el análisis de datos de lo que podemos con un BI tradicional. Se trata de una respuesta a unas necesidades de los usuarios, al igual que en su tiempo lo fue el BI. Eso no significa que el BI deba eliminarse como una opción a tener en cuenta a la hora de analizar datos. Al contrario, deberá ser siempre una opción.

Sin embargo, cuando las necesidades de los usuarios incluyan el uso de datos masivos (volumen), con respuestas obtenidas en un tiempo muy corto (velocidad) u obtenidas a partir de tipos de datos complejos (variedad), deberemos descartar el BI tradicional por sus limitaciones tecnológicas, y decantarnos por el uso de una solución con Big Data.