La semana pasada compartí con la comunidad de profesionales de 101Blockchains la visión de Blockchain que tenemos en Telefónica y cómo las empresas pueden crear valor mediante la adopción de esta tecnología. Si tenéis curiosidad podéis revisar la presentación completa en este enlace.
Pero además, en el debate con los asistentes se volvieron a plantear los retos e interrogantes comunes al adoptar Blockchain. Muchos de ellos ya los analizábamos en nuestra LUCA Talk a principios de verano. En esta ocasión, tuve la oportunidad de confirmarlos con la audiencia lanzando dos preguntas. Los resultados, sin pretender que tengan ninguna validez estadística, sí nos marcan ciertas tendencias que podemos analizar. Pero sobre todo, nos sugieren la primera de las prioridades que debemos atender en nuestro proyecto Blockchain.
La tecnología
Sobre el tipo de blockchain preferida para aplicaciones empresariales, las opciones mayoritarias fueron las redes privadas y permisionadas. Teniendo en cuenta que las opciones no eran excluyentes, podríamos incluso concluir que la mayoría de los participantes se decanta por este tipo de redes. La tercera opción elegida por un tercio de la audiencia se decantaba por la red pública de Ethereum.
Con la segunda pregunta intentábamos conocer las preocupaciones de los asistentes a la hora de adoptar blockchain en sus operaciones. De nuevo la respuesta no dejaba dudas. En este caso nos presentaba la versión empresarial del trilema de blockchain, es decir, elegir
- la trazabilidad y transparencia de las redes públicas o permisionadas en detrimento de la escalabilidad y rendimiento
- la escalabilidad y rendimiento de redes privadas renunciando a cierta transparencia.
Podemos relacionar fácilmente las dos respuestas. Una mínima transparencia de las operaciones que se registran en la red está garantizada por la propia tecnología. A más participantes, más transparencia y garantías sobre la inmutabilidad de la información almacenada.
En aquellos casos de uso conectados intrínsicamente con el negocio o con exigentes necesidades de rendimiento, las tecnologías preferidas son aquellas que ofrecen la posibilidad de tener más control y confianza entre los participantes de la red. Especialmente Hyperledger Fabric es la tecnología estrella en estos casos. Hablamos de entornos con pocos participantes y conocidos, por ejemplo cadenas de suministro o plataformas de conciliación de datos. Sin embargo, para aquellos casos donde la transparencia es vital, las empresas encuentran en la red pública de Ethereum, con miles de participantes independientes, el ecosistema perfecto para dejar traza de sus operaciones y permitir la verificación de terceros.
La importancia de una PoC y Minimo Ecosistema Viable
YA hemos elegido la tecnología que más se adapta a los requisitos de nuestro caso de uso. Ahora debemos aseguraros de que una vez desplegada la solución ayudará a resolver los retos del caso. Para ello, la mejor opción es diseñar una prueba de concepto y validar lo antes posible qué funcionalidades mínimas nos permitirán crear valor para el negocio. Su alcance está acotado y normalmente se limitan a demostrar rápidamente que se puede implementar esa funcionalidad mínima. Nos situamos en el ámbito de la tecnología y la tecnología siempre funciona. Sin embargo, siendo importante, una prueba de concepto no es suficiente en la mayoría de los casos.
Necesitamos relativizar el plano funcional y analizar qué atributos o componentes del proyecto determinarán realmente la viabilidad del mismo. Es lo que llamamos no ya el mínimo producto viable, sino el mínimo ecosistema viable. El valor de un proyecto de blockchain está en el valor que capturan todos los participantes. Tenemos que identificar los participantes adecuados para crear el valor suficiente y entender las relaciones entre ellos, la gobernanza, el modelo operativo y cómo se puede facilitar que nuevos participantes, los sistemas con los que debe interactuar y los interfaces de integración con los mismos. En definitiva, se trata de trazar el mapa de interacciones y la cadena de creación y transmisión del valor: donde, cómo y cuando se crea y quien, como y cuando se captura.
Sin embargo, identificar todos esos componentes y relaciones no significa implementarlos. Por ejemplo, pensemos en sistemas que registran, procesan y toman decisiones en base a información recolectada por dispositivos IoT. Esa información de entrada puede simularse. Exactamente igual con la información que pueda recibirse desde sistemas de información. Lo importante del mínimo ecosistema viable es entender qué información va a entregar nuestra solución, a quien, cómo y cuando. Y además, valorar si ese escenario es suficiente como para dar por bueno el proyecto. Un mínimo ecosistema viable no es nunca funcional. Ofrece una visión completa del impacto que va a tener la solución en los procesos sobre los que actúa. No estamos simulando la solución, estamos planteando con el mayor detalle posible todos los escenarios y oportunidades potenciales para los participantes de capturar parte del valor creado.
Podemos pensar en ese mínimo ecosistema viable como el paso intermedio entre una prueba de concepto y un piloto. El primero es un planteamiento conceptual y el segundo sí es ya un ejercicio funcional. Un piloto puede productivizarse y escalarse a un sistema productivo. El ecosistema debe implementarse.
Retorno de la inversión
Como resultado del mínimo ecosistema viable hablábamos del valor capturado por los participantes. En cualquier comité de evaluación donde vaya a decidirse sobre la continuidad de un proyecto debe estimarse ese valor. En los proyectos de blockchain hablamos de una red, por tanto, las decisiones se complican. La viabilidad del proyecto puede depender de las decisiones sobre la continuidad que tome otro de los participantes. Si uno no va adelante, quizás el resto no logren generar el valor suficiente para hacer viables las inversiones necesarias.
Por tanto, los parámetros de rentabilidad y retorno de la inversión tienen en estos proyectos más de una dimensión. Como parte del ejercicio de construcción del mínimo ecosistema viable hay que entender las motivaciones de cada participante y valorar los beneficios que cada uno de ellos obtendrá del proyecto. Además, es frecuente que en un mismo proyecto, los diferentes participantes ejerzan un rol diferente. Es típico por ejemplo una cadena de suministro donde participan distribuidores y proveedores. Cada uno puede obtener beneficios de naturaleza diferente e incluso en ejercicios diferentes.
El beneficio generado puede traducirse directa o indirectamente en valor contable para los diferentes participantes. Por ejemplo, pensemos en un proyecto de trazabilidad alimentaria diseñado para transmitir una mayor confianza en el consumidor final. A medio plazo esa confianza podrá tanto retener al cliente como justificar un premium en el precio. Sin embargo, pensemos en un pequeño productor. Quizás el proyecto le permite demostrar su excelencia cumpliendo plazos de entrega o los parámetros de calidad. Gracias a esas evidencias podría renegociar sus contratos y obtener beneficios directos en el corto plazo.
Esta variabilidad y asimetría en los beneficios obtenidos determina que cada proyecto, en función del caso de uso concreto y de los participantes involucrados, combine rentabilidades diferentes e incluso niveles de inversión diferentes para la consecución de los resultados esperados. Caracterizar este mapa de beneficios con el mayor detalle posible debe ser una prioridad antes de embarcarse en costosos proyectos de integración con o migración desde sistemas y aplicaciones legacy a una nueva solución basada en blockchain.
Interoperabilidad entre redes
El desarrollo de proyectos empresariales basados en blockchain está acelerándose en paralelo a la criptoeconomía. Los casos de uso como bitcoin o las criptomonedas han desarrollado un ecosistema centralizado en unas pocas redes públicas. Sin embargo, cuando una empresa decide embarcarse en un proyecto de blockchain piensa en crear su propia red privada. El resultado es una multitud de redes desplegadas independientemente como silos, aunque muchas de ellas puedan compartir tecnología.
Existe un debate actualmente en torno a la interoperabilidad de redes de blockchain. ¿Cómo se asegura la interoperabilidad entre diferentes redes de blockchain? Antes de responder es necesario preguntarnos que entendemos por interoperabilidad y si es necesaria para nuestro caso de uso concreto.
A priori, dos redes de blockchain pueden interoperar en distintos niveles. Podrían compartir datos o permitir que un smart contract desplegado en una red escriba o interaccione con otra. También podrían nodos de varias redes validar transacciones y alcanzar el consenso entre ellos. Sin embargo, ¿qué casos de uso necesitan estos niveles de interoperabilidad? Pensemos en dos aplicaciones empresariales, una de gestión de nóminas y una de gestión de gastos. Probablemente ambas deben conocer los datos de los empleados. Estos podrán estar replicados en cada aplicación o disponibles en un repositorio común. Sin embargo, no se hablan entre ellas. No interoperan. Simplemente cada aplicación utiliza la información que obtiene de las fuentes disponibles. Lo mismo sucede con blockchain. La información almacenada en una red o las tareas (smart contracts) son autocontenidas. No necesitan interaccionar con otra red. En todo caso, será la aplicación quien se integrase con dos redes simultaneamente. De cada una de ellas recuperará o registrará información de diferente naturaleza que permite implementar el caso de uso.
¿Reutilización de componentes o desarrollos ad-hoc?
Buena parte de las aplicaciones empresariales basadas en blockchain hacen uso de la misma funcionalidad básica de la tecnología. Al menos dos de cada tres casos de uso se basan en la inmutabilidad de la información almacenada o intercambiada. El resto se reparten entre la tokenización de activos (derechos de uso, activos intangibles, gemelos digitales, etc.) y la conciliación de fuentes de información.
Analicemos el caso más común de proyectos de blockchain, la trazabilidad y certificación. Gracias a la inmutabilidad podemos crear evidencias digitales irrefutables que además podemos fechar y atribuir de manera exacta. Con esas evidencias podemos dejar traza de una información o un evento para que pueda ser verificada por un tercero. Ahora pensemos en un caso concreto de certificación de documentos. Si atomizamos las operaciones necesarias podemos crear un catálogo de acciones que podríamos reutilizar en otro caso. Entre las acciones estarían crear el activo digital que representa el documento, asociarle los datos intrinsecos del mismo, firmarlo digitalemente para atribuirselo al poseedor, crear una huella digital única que permita verificaciones posteriores, etc. Estas mismas operaciones podríamos aplicarlas en un proyecto de trazabilidad industrial para monitorizar el estado de una pieza concreta. En este caso crearíamos el activo, lo asignaríamos a un operario responsable de la pieza y podemos asignarle datos intrinsecos para identificarla.
Por tanto hemos conseguido reutilizar componentes en proyectos de diferente naturaleza. Si pensamos en la implementación, seguramente cada operación puede traducirse en un smart contract genérico parametrizable según el proceso concreto que monitorizamos y trazamos. Esos smart contracts genéricos son los componentes reutilizables que permiten minimizar notablemente los tiempos de desarrollo de las soluciones blockchain. En algunos casos necesitaremos desarrollar componentes especificos (i.e. nuevos smart contracts). Sin embargo, la mayoría de casos de uso pueden maearse en esos componentes reutilizables.
Necesidad de descentralización
Otro debate recurrente entre los defensores de blockchain plantea hasta que punto es necesario descentralizar la operación de una red. De hecho, muchos expertos afirman que una red privada no respeta el valor subyacente de tener una plataforma descentralizada. Desde esta posición sólo las redes públicas con miles de nodos independientes serían verdaderas redes de blockchain. La replicación masiva en miles de nodos sin que ninguno pueda influir sobre el resto garantiza inmutabilidad e integridad.
En los casos consorciados donde varios socios operan la red, una mínima descentralización está garantizada. Sin embargo, decíamos que cada empresa está desplegando su propia red privada. ¿Como garantizamos la inmutabilidad e integridad en estos casos? Siempre que existan evidencias registradas criptográficamente que pueden verificar terceros sin relación se puede garantizar ambos atributos. La criptografía básica que enlaza los bloques de información almacenada hace inviable que la información histórica pueda alterarse sin invalidar las pruebas de verificación distribuidas. En cualquier caso, la utilización de redes públicas para registrar a modo de evidencia snapshots o imágenes del sistema en un instante es un procedimiento habitual para garantizar la integridad y verificabilidad requeridas por los defensores de blockchain.
Veracidad de los IIOT
Por último, podemos hacer una reflexión sobre lo que supone la inmutabilidad de la información. En esencia, la información que registramos en una red no puede ser alterada y podemos garantizar su integridad. ¿Qué pasa si esa información es falsa? Efectivamente estamos “construyendo” una mentira que la gente va a poder verificar. Por tanto, tenemos que ser cuidadosos con la información que almacenamos en blockchain. Nunca debemos creer en algo resgistrado en la blockchain sin tener garantizado cómo se está registrando esa información.
La forma más fácil de garantizar no sólo la integridad sino la veracidad de esa información es registrarlo lo más cerca posible de la fuente. En muchos de los procesos de negocios que nos encontramos, ese lugar es un dispositivos IoT confiable como interfaces para cargar automáticamente la información en blockchain. Pero aún así las partes deben asegurarse de que los dispositivos no han sido manipulados y confiar en ellos.
TrustOS: Blockchain fácil y rápido
Desde Telefónica llevamos varios años trabajando para que nuestros clientes puedan implementar Blockhain sin preocuparse de todos estos retos. Nuestra propuesta es TrustOS, un sencillo servicio en red que permite invocar de manera sencilla la funcionalidad más demandada de blockchain. Siguiendo la tesis que explicábamos anteriormente, TrustOS serían esos componentes reutilizables de todo proyecto Blockchain, que hemos empaquetado y puesto a disposición de los clientes. Gracias a TrustOS, una empresa puede:
- Añadir blockchain a sus sistemas, servicios y aplicaciones a un bajo coste en tiempo y recursos. Puede desentenderse de la tecnologia de blockchain subyacente y utilizar las APIs de TrustOS para combinar lo mejor de las redes públicas y privadas de blockchain.
- Simular su mínimo ecosistema viable sin dedicar atención a la topología de red o desarrollar complejas integraciones de sus sistemas con Blockchain.
- Presentar a los gestores unos casos de negocio positivos desde el minuto 0, ya que se minimiza la inversión en despliegue de red y se comienza a utilizar el servicio de manera inmediata.
- DEsarrollar aplicaciones que simultaneamente puedan interaccionar con varias redes de blockchain incluso cuando estén basadas en tecnologías diferentes.
- Reutilizar los componentes básicos de TrustOS para implementar casos de uso de trazabilidad o certificación con muy pocas líneas de código.
- Confiar en la descentralización real de las solución gracias a la federación de redes, un concepto novedoso que permite crear mallados de redes diferentes que hacen de verificadores de la integridad de la información intercambiada en las otras redes de la malla.
- Garantizar el dato intercambiado y su integrdad, gracias a los módulos IoT que de manera nativa registran información y evidencias en blockchain a través de TrustOS.
Si necesitas más información sobre como funciona TrutsOS, puedes visitar nuestra web en http://blockchain.telefonica.com
The post Las 7 prioridades de una empresa a la hora de adoptar Blockchain appeared first on Think Big.