Pensar en el cliente 360

Cliente 360.

O, como lo llama uno de nuestros competidores (que permanecerá en el anonimato, pero que utiliza una hoja de abedul como logotipo), Single View.

Todo el mundo lo quiere.

Todo el mundo lo necesita.

Al fin y al cabo, la mayoría de los datos de sus clientes se almacenan en distintos sistemas, cada uno de los cuales sólo proporciona una pequeña visión de cada cliente.

Sería estupendo disponer de una visión única e integral del cliente, en un solo lugar.

Así pues, el cliente 360, todo un grial de los datos de clientes.

Y si crees en el marketing de nuestro sitio web, todo lo que necesitas hacer es tomar todos tus sistemas existentes, dejar caer Couchbase en medio de todos ellos, dibujar algunas flechas, y TA-DA, estás listo y funcionando.

¡Es mágico!

Bueno...

No tan rápido.

A nuestra gente de marketing le pagan por convencerte de lo fácil y sencillo que es.

(Lo siento Peter, sólo estoy siendo sincero)

Tengo un trabajo diferente.

Mi trabajo consiste en ayudar a que sus proyectos tengan éxito al utilizar Couchbase.

Al fin y al cabo, nuestro sector está plagado de cadáveres de proyectos fracasados.

Todos los hemos visto...

He estado en sus funerales...

Y muchos de nosotros tuvimos algo que ver en al menos una de las muertes...

Así que no compensa adoptar una visión simplificada.

(A menos que su puesto empiece por "C")

No, para aquellos de nosotros cuyo trabajo consiste en implantar sistemas como un Cliente 360, tenemos que prestar atención a los detalles.

Integración

Si observamos el dibujo de la arquitectura de referencia en nuestro sitio web, de izquierda a derecha, veremos estos recuadros con varios sistemas con nombre encapsulados en su interior.

CRM, ERP, Mainframe, etc.

Y un par de flechas, apuntando dentro y fuera de un rectángulo alto etiquetado como "integración".

Parece sencillo.

Por desgracia, no lo es.

Esta es una parte en la que habrá que pensar mucho.

Realmente, mucho.

No se trata sólo de conectar los distintos sistemas a Couchbase mediante Kafka u otro conector y enviar los datos.

Es decir, podrías, pero entonces sólo tendrías un montón de datos desconectados abarrotando tu cubo de Couchbase.

No, hay que pensar en cómo relacionar los datos de los clientes procedentes de distintos sistemas.

Y cómo combinarlo.

Y dale formato.

Como he dicho, mucha reflexión.

Introducir los datos en Couchbase es la parte fácil, lo difícil es combinarlos y formatearlos.

O al menos determinar cómo debe hacerse.

El proceso ETL en sí debería ser bastante sencillo.

Al fin y al cabo, sólo se trata de extraer los datos de los sistemas de origen, formatearlos como JSON, combinar los datos de las distintas fuentes y almacenarlos en Couchbase.

Fácil, fácil...

Podría hacerlo mientras duermo.

La parte ETL, es decir, no el modelado de datos...

Tengo que estar despierto para hacer esa parte...

Microservicios

Sí, cada implementación de un Cliente 360 va a implicar algún conjunto de microservicios.

Tendrás algunos datos importantes y sensibles en este cubo y, como mínimo, querrás controlar el acceso a ellos.

Qué otros microservicios querrá tener dependerá de su negocio y de lo que quiera hacer con los datos de sus clientes.

Probablemente algún tipo de reglas de negocio detrás de una API REST...

Un proceso empresarial o dos...

Y una sincronización de datos para una aplicación móvil de algún tipo.

Lo que me lleva a...

Integración móvil

Mira, aquí es un lugar donde nosotros (Couchbase) realmente puede simplificar las cosas para usted.

Al integrar nuestra pila móvil...

Couchbase Server, Sync Gateway y Couchbase Lite...

Puedes reducir tus responsabilidades de sincronización de datos móviles a decidir cómo quieres repartir los datos para tus usuarios móviles.

Ya sabes, quién obtiene qué datos.

Sí, lo sé, más pensar...

Verás, no hay mucho que podamos hacer para eliminar la parte pensante de esto.

En realidad, muy poco.

No hay vuelta de hoja, esto implica una buena cantidad de pensamiento...

Pero una vez que has pensado, intentamos que el resto sea lo menos doloroso posible.

Y utilizando nuestra pila móvil, puedes reducir lo que tienes que pensar a cómo asignar los datos a los usuarios, y qué propiedades tienes en los distintos documentos que puedes utilizar para determinar esta asignación.

A continuación, pones todo esto en una función escrita en JavaScript.

Y céntrese en su propia aplicación móvil.

Sí, me temo que aún habrá que escribir la aplicación.

No hay vuelta de hoja.

Pero no tendrá que lidiar con las API REST, ni esperar a que el servidor responda.

No, tu aplicación móvil sólo tendrá que tratar con la base de datos local del dispositivo.

Nosotros nos encargamos de todo lo demás relacionado con la transmisión de datos desde y hacia el dispositivo.

Por lo tanto, mediante el uso de nuestra pila móvil, usted es capaz de reducir sus responsabilidades de codificación de aplicaciones móviles de este:

A esto:

Sé cuál preferiría tener responsabilidades de codificación...

Front-End

Lo que nos lleva a la parte final de un Cliente 360, la aplicación de acceso de usuarios.

Por desgracia, no podemos hacer mucho para eliminar o simplificar esta parte de la solución.

Tienes que determinar cómo quieres que tus usuarios accedan a los datos y trabajen con ellos...

Entonces deja libres a tus desarrolladores...

Y espera que lo que te entreguen se acerque a lo que realmente querías.

Es decir, facilitamos a los desarrolladores el trabajo con Couchbase.

Ofrecemos SDK en la mayoría de los lenguajes de programación más populares...

Facilitamos la transición de SQL a N1QL para trabajar con los datos...

Y disponemos de numerosos servicios de formación y consultoría para ayudarle en sus esfuerzos.

Pero no podemos escribir el código por usted.

Lo siento.

¿Por qué Couchbase?

Todo el mundo te dirá que su base de datos es la mejor para esta solución.

¿Por qué nosotros?

Además de ser conocidos por nuestra alta disponibilidad, velocidad y facilidad de ampliación, tenemos otras cosas a nuestro favor...

Aparte de mis prejuicios personales...

Es decir, facilitamos la transición desde una base de datos basada en SQL haciendo que nuestro lenguaje de consulta N1QL sea compatible con ANSI, lo que le permite trasladar sus conocimientos y experiencia existentes en SQL (¿no se queda atrás ningún conocimiento?)...

Y nuestro almacén de documentos sin esquemas permite que su modelo de datos evolucione con el tiempo a medida que su organización plantee a sus desarrolladores diversas demandas de nuevas características y funcionalidades...

Nuestra búsqueda de texto completo integrada facilita la búsqueda sin tener que integrar otra herramienta...

Nuestro servicio Analytics permite a sus analistas de negocio retorcer sus datos en todo tipo de formas extrañas sin tener que esperar...

Nuestro servicio Eventing le permite hacer todo tipo de travesuras en tiempo real...

Y nuestra pila móvil hace que sea muy sencillo limitar qué datos tiene cualquier usuario en su dispositivo móvil, y sincroniza las actualizaciones entre el teléfono y el Centro de Datos sin tener que esperar a un servicio REST o escribir todo tipo de complejas rutinas de sincronización...

Y cuando ocurra lo inevitable y uno de tus servidores muera (y créeme, uno de ellos acabará muriendo), tus datos permanecerán intactos y disponibles.

Esto hará muy feliz a su CIO.

Al fin y al cabo, será un motivo menos para que su director general le grite.

Y con el tiempo, esa felicidad llegará a los que trabajamos en las trincheras digitales.

Felicidad por goteo.

Es algo bueno en lo que pensar...

Sí, ya estamos otra vez con eso de "pensar".