Llegamos a ustedes gracias a:



Reportajes y análisis

Cómo hacer de Big Data algo lindo -y útil

Big data

[17/04/2015] Todo el mundo habla sobre Big Data; pero debido -en gran parte- a su complejidad, el grado de adopción es todavía relativamente bajo. De hecho, una encuesta reciente de Capgemini, encontró que solo un 13% ha alcanzado o llegado a una producción de gran escala.

Sin embargo, no tiene que ser de esta manera -por lo menos si Justin Langseth, CEO de Zoomdata es una persona confiable. Langseth me dijo en una entrevista, el diseño es tan importante como el desempeño o rendimiento cuando de Big Data se trata. La palabra "Big no es tan relevante si es que no se traduce en "útil.

Pequeño éxito con Big Data

Una de las mejores características de la revolución de Big Data es que está impulsada por el software de código abierto de costo cero. Mientras que la inteligencia de negocios ha estado plagada de softwares caros y complejos; hoy en día, la tecnología de Big Data más innovadora está a una descarga de distancia.

Al menos esa es la teoría.

En la práctica -como cualquiera que ha intentado descargar Hadoop le puede decir- funciona de manera un poco diferente. Mike Olson, co fundador de Cloudera está en lo correcto cuando declara que, "Ninguna infraestructura de software dominante a nivel de plataforma ha surgido en los últimos diez años en código cerrado y de forma patentada, incluyendo la mejor infraestructura de datos como Hadoop, MongoDB, Spark y Cassandra.

Pero dominante no necesariamente significa fácil.

Así como la encuesta de Capgemini revela, solo el 27 por ciento de los encuestados ve sus iniciativas de Big Data como "exitosas, y casi un 8% las describió como "sumamente exitosas. Incluso los proyectos de prueba de concepto han pasado por tiempos difíciles, con una tasa de éxito de casi 38%.

Algunos de los problemas son difíciles de separar de las personas que implementan la tecnología, incluyendo "tratar con los silos de datos dispersos, la coordinación no efectiva de las iniciativas de análisis, la falta de un modelo o caso de negocio claro para la financiación de Big Data, y la dependencia en los sistemas heredados para procesar y analizar Big Data.

Pero últimamente todos estos se reducen a la dificultad en la traducción de la promesa de Big Data a la capacidad de las organizaciones para hacer uso de la tecnología.

Diseñando el éxito de Big Data

Aquí es donde entra el diseño. Como Langseth señala, uno de sus primeros empleados en Zoomdata fue un diseñador de portadas de álbumes ganador de un premio de Blue Note Records, la casa de jazz con sede en Nueva York.

Sí, un diseñador de portadas de álbumes está ahora diseñando sistemas de Big Data -y este diseñador es más la regla que la excepción en Zoomdata. Él le informa a un vicepresidente que es miembro del Consejo Asesor de Currículo en NYU.

Claramente, Zoomdata se enfoca de manera diferente en Big Data. Cuando le dije a Langseth que destilara este enfoque centrado en el diseño, me dijo que se dividía o reducía a tres áreas principales:

1. Los imperativos de arriba abajo. En primer lugar, tiene que haber un mandato que venga de arriba y que diga que la compañía está construyendo una aplicación impulsada por el diseño. Esto es sumamente raro para la tecnología de la empresa (como cualquier persona que se ha visto en la obligación de mirar una interfaz SAP puede manifestar.)

Tony Fadell, uno de los "padres del iPod, mostró cómo esto funciona con los productos de consumo como el iPod en Apple y luego Nest, ahora parte de Google. Steve Jobs es el ejemplo emblemático de liderazgo de esa perspectiva con Apple. Tony trabajó para Steve y llevó ese punto de vista a Nest, luego a Google.

A pesar de este éxito en la tecnología de consumo, virtualmente no hay ejemplos de este mandato de liderazgo en el software empresarial. Esa es la razón por la cual la mayoría de software empresarial es terrible.

2. Atendido por el diseño. Langseth también hace hincapié en que las empresas necesitan poner su contratación donde están sus bocas. Es decir, las organizaciones deben tener una proporción o radio de diseñadores y desarrolladores UX que refleje el mandato centrado en el diseño.

Zoomdata apunta a una relación de cinco desarrolladores a un diseñador. La mayoría de las compañías de software empresarial tienen una proporción de 50 a 1, la cual es una razón importante de porqué la experiencia del usuario con el software empresarial es tan mala - incluyendo Big Data, que después de todo es una tendencia impulsada por el desarrollador.

3. La gente normal. La tercera sugerencia de Langseth es que todo el equipo UX debería ejecutar pruebas de usabilidad constantes con la gente común, no solo con especialistas en análisis. Los nerds pueden estar desarrollando el software, pero para que sea realmente relevante para la empresa, los usuarios comunes deben ser capaces de usarlo y asimilarlo.

Como Langseth señala: Esto es lo que hace que nuestra aplicación sea fácil de usar para la persona promedio que puede familiarizarse con un programa como Excel, pero puede no ser un especialista en el análisis de la inteligencia de negocio. Desde un punto de vista estratégico, esto abre nuestra aplicación a un público mucho más amplio que el que tendríamos si nos centramos únicamente en los especialistas.

Esto es crítico. En última instancia, Big Data gana cuando está disponible para todos de cierta manera. Peter Goldmacher, experto en datos se refirió a este punto de vista cuando años atrás dijo que los grandes ganadores en Big Data eran las compañías que la convertían en aplicaciones fáciles de usar. Solo es interesante si se traduce en valor para los simples mortales.

Los diseñadores también son desarrolladores

Si bien se comprende que los desarrolladores no son los mejores diseñadores, Zoomdata quiere que sus diseñadores aprendan a programar. Langseth insiste, "todos los buenos artistas y diseñadores tienen un excelente dominio de su medio y lo conocen a la perfección. Por ejemplo, un buen pintor mezcla sus propios pigmentos a la hora de pintar y construye sus propios lienzos.

Esto significa que conoce los límites de lo que estas cosas pueden hacer y cómo trabajar con ellas. Cuando no conoce bien el medio, puede arriesgarse a diseñar algo que le tomará más de 10 veces más tiempo en construir. Zoomdata no quiere que sus diseñadores impongan preguntas de ingeniería sumamente difíciles a sus desarrolladores, así que tienen que saber cómo nadar en códigos.

Diseñando para el resto de nosotros

También es importante realizar un gran trabajo de investigación sobre el lenguaje utilizado en la aplicación. Como Langseth sugiere, es fundamental "evitar la jerga específica de la industria. ¿Tentado a sumergirse en los matices del lenguaje de la industria? No lo haga. El objetivo final de Big Data es democratizar los activos de datos de una empresa, lo cual significa que tiene que ser útil para aquellos que no son científicos o analistas de datos.

El que últimamente es el punto más importante. Para que Big Data despegue realmente necesita ser más que una herramienta de un científico de datos. Como Svetlana Sicular, analista en Gartner, señala, "aprender Hadoop es más fácil que aprender el negocio de la compañía.

Por lo menos, debe ser. Pero el punto clave es que usted quiere que todos los que han aprendido a usar Hadoop sean capaces de traducirlo en una conversación sobre el negocio de la compañía. Microsoft está tratando de hacer esto con R, así como Zoomdata está tratando de hacerlo para datos no estructurados arrojados por las bases de datos NoSQL, Hadoop y más.

Aunque el diseño no es el único factor involucrado en la realización de esta visión, es un componente fundamental que la mayoría de empresas pasan por alto. Esa miopía es la gran razón por la cual los proyectos de Big Data siguen fallando. Podemos mejorar. Enfocarse en el diseño puede ser de gran ayuda.

Matt Asay, InfoWorld (EE.UU.)

Matt Asay, colaborador y ex abogado de propiedad intelectual de InfoWorld desde hace años, es actualmente vicepresidente de Mobile en Adobe. Las opiniones expresadas son personales y no las de su empleador.