En los últimos años numerosas empresas han iniciado la exploración de nuevas vías de ingresos con la transformación de sus datos en activos.

Con mayor o menor acierto se esfuerzan en la explotación de sus silos de datos y en la búsqueda de nuevos yacimientos, con frecuencia sin saber con exactitud cómo extraerles valor,  pero con la confianza en prometedoras oportunidades.

En este contexto, las áreas de Arquitectura de Datos de las empresas han adquirido una posición delicada, puesto que debemos enfrentarnos a la  labor clave de proporcionar los sistemas responsables de la producción y el suministro de estos codiciados activos.

 “Las áreas de Arquitectura de Datos de las empresas se ven más exigidas que nunca.”

Hoy en día, los analistas del negocio además de requerir una mayor variedad y calidad de datos, también demandan con insistencia el acceso autónomo a los mismos y un entorno adecuado donde analizarlos, manipularlos y difundirlos.

A todo esto, a los equipos de Arquitectura de Datos se nos suma que debemos también ocuparnos de la laboriosa adaptación de los sistemas a las exigencias de los reguladores en el uso y custodia de datos.

Ante esta situación, debemos ingeniárnoslas para ofrecer soluciones sostenibles que se adecuen a la realidad de nuestras empresas, y muchos nos vemos forzados a emprender  la incierta travesía de una profunda transformación de los sistemas para su  adaptación a las exigencias presentes.

En estos casos, es importante trazar un rumbo hacia una arquitectura objetivo y dotarse de una guía que ayude a no perdernos en el caos incitado por la constante irrupción de nuevas tecnologías y sus sugestivas posibilidades.

Pero sobretodo, es aún más importante que antes de partir consideremos en perspectiva cuales son los grandes desafíos del viaje, y nos preparemos a resolver cada uno de los retos capitales a los que con toda probabilidad deberemos enfrentarnos en el trayecto.

Reto Nº 1 – La voracidad insaciable de los datos

“El terrible monstruo penetró en las entrañas de Eresictón de tal forma que desde entonces nada saciaría sus ganas de comer, y cuanto más engulliera más crecería su hambre”

Las metamorfosis, Libro VIII (Ovidio, 8 d.C.)

En 1890, Hermann Hollerith, decidido a encontrar la manera de terminar el censo de los EUA antes del inicio del siguiente censo en diez años, ideó una máquina capaz de procesar unas tarjetas perforadas que contenían los datos de los ciudadanos censados. Este episodio es para muchos el verdadero inicio de la informática.

Paradójicamente, la necesidad de procesar datos que inspiró el invento de Hollerith a finales del siglo XIX, ha mutado en el presente en una voraz necesidad de disponer datos que procesar.

“Cuantos más datos engullimos más nos crece el hambre de nuevos datos.”

Este afán es esencialmente debido a que en los datos prevalece una característica que los hace muy apetitosos; los datos son el material básico con el que recrear una fiel representación digital del mundo real, y cuantos más datos y de mejor calidad, más precisa es la imagen obtenida.

El Internet de la cosas, los avances constantes en comunicaciones, las capacidades de procesamiento de Big Data y la Inteligencia Artificial  son exponentes de tecnologías que juntas conforman la capacidad de ofrecer servicios de valor sustentados en el conocimiento virtual de lo  que sucede en la realidad y en la reacción automática ante los que está sucediendo.

E Irremediablemente, todo ello pasa por un inagotable y continuo suministro de datos, e igual que en el castigo que Deméter infringió a Eresictón en el texto de Ovidio, siendo como somos una sociedad cada vez más digital, estamos abocados a una insaciable voracidad de datos.

Ante esta situación, los arquitectos de datos únicamente podemos defendernos con diseños pensados para la factorización de los servicios de datos.

“Ya no se trata de diseñar la arquitectura de datos apropiada para un uso  más o menos concreto…   se trata de idear plataformas cuyo  único propósito  sea procesar toda clase de datos procedentes de  cualquier fuente,  y ponerlos a disposición de todo tipo de consumidores.”

Los sistemas de ingesta de datos basados en suscripciones a colas de mensajes o  en tecnologías de Data Syncronization, la cadena de producción de procesos apoyada en contenedores o la “apificación” del acceso a los datos son, entre otras, soluciones que combinadas ofrecen la posibilidad de construir verdaderas plataformas industriales de procesar datos, plataformas con las que armar las fábricas capaces de acercarse a satisfacer la voracidad del terrible monstruo que ha penetrado en las entrañas de las empresas.

Y llegados a este punto, sería bueno advertir que Eresictón, tras vender todas sus posesiones e incluso vender su hija reiteradamente a hombres distintos para comprar alimento, como que no lograba saciar su apetito, acabó con su tormento comiéndose a sí mismo.

Reto Nº 2 – La falacia del martillo dorado

“Si le das a un niño un martillo, le parecerá que todo lo que encuentre necesita un golpe”

The Conduct of Inquiry: Methodology of Behavioral Science (A. Kaplan, 1964)

La falacia del martillo dorado, también conocida como el martillo de Maslow o la ley del instrumento de Kaplan, hace alusión a tecnologías o paradigmas cuyos impulsores propugnan de manera exagerada, recurriendo a ellas como respuesta en la mayoría de las situaciones.

“Para un martillo, todo son clavos.”

Esta pauta es especialmente acentuada en las tecnologías de la información y, hoy en día, a los arquitectos de datos nos resulta estresantemente difícil de descifrar, ya que tenemos que lidiar con la prolífica cantera de las soluciones open source y sus entusiastas partidarios.

Ciertamente, las tecnologías open source ofrecen un universo de buenas posibilidades en el tratamiento y almacenaje masivo de todo tipo de datos, en la capacidad de ingesta y de proceso en tiempo real, o en lenguajes y librerías para el desarrollo y entrenamiento de algoritmos de machine learning.

Sin embargo, más allá de la dificultad de probar y escoger entre tan enorme número de soluciones, antes de lanzarnos a la adopción y aplicación de alguna de estas tecnologías, debemos asegurarnos de  entender correctamente las necesidades, no sea que como en el caso del niño de Kaplan, nos  parezca que todo merece un golpe.

Irónicamente, si bien la apariencia de un martillo de oro puede ser imponente, la poca dureza del material lo hace prácticamente inútil.

Reto Nº 3 – El efecto Einstellung

“Por eso estoy hablando con usted. Usted es una de esas raras personas que son capaces de separar sus observaciones de sus prejuicios. Usted ve lo que es, mientras que la mayor parte de la gente ve lo que espera ver”

Al este del Edén (John Steinbeck, 1952)

El cerebro humano, en busca de la eficiencia, tiende a acercarse a la resolución de nuevos problemas a partir de patrones de solución conocidos.

Sin embargo, esta característica evolutiva también conlleva que lo que conocemos previamente afecta a la forma en que interpretamos lo que sucede.

A este sesgo cognitivo se le conoce como el efecto Einstellung, y es especialmente significativo en casos de alta especialización, ya que cuanta más experiencia previa, mayor es la posibilidad que incida negativamente en la resolución de nuevos problemas.

“Ante un nuevo problema, nos inclinamos a ignorar cualquier información que no coincide con la solución preconcebida interiorizada”

En el caso de los arquitectos de datos, la competencia en ciertas tecnologías nos puede atenazar a que acudamos a la búsqueda de mejores soluciones. El conocimiento y la experiencia son activos que aportan luz, pero que a veces pueden cegarnos.

Debemos valorar honestamente cuando y cuanto las  soluciones conocidas siguen vigentes, y no renunciar  a explorar alternativas. Debemos esforzarnos a integrar en nuestros diseños la seguridad de tecnologías probadas y las capacidades que nos brindan las nuevas tecnologías.

En definitiva, ante los nuevos desafíos, los arquitectos de datos debemos intentar ser una de esas raras personas que ven realmente lo que es y no lo que esperamos ver.

Reto Nº 4 –  El dilema del cambio

“Nuestro dilema es que odiamos y amamos el cambio al mismo tiempo; lo que realmente queremos es que las cosas sigan igual pero mejores”

 (Sidney J. Harris, 1917 -1986)

Últimamente, en muchas empresas se han multiplicado en número de departamentos fuera del ámbito de tecnología cuya principal labor es la de cocinar datos.

Durante años, gracias al constante caudal de nuevas herramientas de análisis de datos, numerosos equipos ajenos a las unidades de tecnología han tejido un entramado de procesos informacionales que en muchos casos han acabado siendo críticos para el negocio.

Evidentemente, el desarrollo de estos procesos por equipos dentro de las unidades de negocio, su proximidad y dedicación exclusiva, es de innegable comodidad.

Sin embargo, también es innegable que este modelo es, además de ineficiente, terriblemente arriesgado, ya que con toda probabilidad la producción de los procesos desarrollados por estos equipos no ofrece la garantía exigida a los sistemas que soportan el resto de  procesos de la empresa.

Por todo ello, es indispensable plantear una transformación que trasciende al ámbito de la Arquitectura de Datos, un cambio intrusivo  en el modelo que impactará en la funciones de estas unidades y en la labor de algunos de sus equipos.

E inevitablemente, este cambio provocará una vigorosa resistencia en parte de los equipos afectados, y con la misma firmeza que señalaran las deficiencias de sus sistemas actuales, también defenderán sus bondades.

“Antes de proponer cualquier cambio, debemos acercarnos a la realidad de las situaciones vigentes fijándonos en sus carencias pero sin perder de vista sus ventajas.” 

Ante esta situación, la mejor manera que los arquitectos de datos tenemos para vencer la oposición al cambio es ofrecer un sistema que haga obsoleto al actual.

Debemos proyectar entornos en los que de una manera contenida, los equipos de analistas de las unidades de negocio dispongan de mejores medios para explorar los datos y elaborar informes, para desarrollar cálculos y probar indicadores con reiteradas simulaciones antes de proceder a su implantación.

Pero a diferencia de lo que sucede en los sistemas actuales, la ejecución recurrente de estos procesos debe de preverse  fuera de estos entornos desde su inicio, y disponer una pauta para su implementación ordenada en plataformas que garanticen su producción y su integración con el resto de sistemas informacionales y analíticos.

En definitiva, debemos proporcionar laboratorios donde los equipos de analistas puedan hacer de forma segura todo lo que hoy hacen, con mayores prestaciones y sin la carga de la ejecución recurrente de los procesos.

De este modo,  puestos a que las cosas no pueden seguir igual, al menos lleguen al convencimiento de que irán a mejor.

Reto Nº 5 – Hacer las cosas como Dios manda

“A la mañana siguiente Nashe y Pozzi descubrieron que construir un muro no era tan sencillo como habían imaginado. Antes de empezar la construcción en sí había que hacer toda clase de preparativos. Había que trazar líneas, cavar zanjas, crear una superficie plana.

–No podéis dejar caer las piedras simplemente y esperar que quede bien – les dijo Murks. Tenéis que hacer las cosas como Dios manda.”

La música del azar (Paul Auster, 1990)

Por último, parece una obviedad afirmar que las cosas se tienen que hacer como se debe, pero no siempre es fácil  y a veces las circunstancias lo hacen imposible.

En el mundo de la Arquitectura de Datos, el legacy de años de desarrollo evolutivo, la presión en los equipos por la entrega rápida de soluciones, o simplemente la contención económica impiden frecuentemente una buena preparación previa del terreno antes de iniciar una nueva construcción.

Para el arquitecto de datos es vital participar proactivamente y solidariamente con los ingenieros y desarrolladores desde el inicio, en el proceso de diseño y en la construcción de las soluciones, pudiendo así influir y disponer una mejor arquitectura de datos.

Pero nos es igual de vital convencer a la organización de la idoneidad de disponer de una buena Arquitectura de Datos, y con ello obtener el apoyo y los recursos,  especialmente el tiempo, imprescindibles para afianzar los cimientos y renovar los materiales de los sistemas de datos.

Afortunadamente, la creciente presión en la democratización de los datos por parte del negocio, las posibilidades que ofrecen las nuevas tecnologías y las nuevas regulaciones cada vez más exigentes han abierto una ventana a la oportunidad, y porque no al oportunismo,  de que los arquitectos de datos podamos hacer las cosas como Dios manda.