viernes, 30 de agosto de 2019

A fondo sobre Process Mining con Wil van der Aalst

Process Mining es una disciplina que analiza procesos de negocio usando técnicas procedentes de la ciencia de los datos e incluso del machine learning. Este libro es, en el momento de leerlo y de escribir estas líneas, probablemente la mejor y más completa obra que cubre esta disciplina. Un libro de carácter fundamentalmente académico, con sólido basamento teórico y una argumentación limpia y muy bien estructurada.

El libro se estructura en dieciséis capítulos agrupados en seis partes:
  • 'PARTE I: INTRODUCTION': Una parte, evidentemente, introductoria para entender fundamentalmente lo que es el Process Mining, el porqué de sus existencia y situarla en el mapa de disciplinas relacionadas.

    • 'Capítulo 1: Data Science In Action': Nos habla primero de un 'Internet de los eventos' destacando la oleada de eventos que se producen en el mundo digital. Luego explica lo que es Data Science y tiende el puente entre esta disciplina y la de gestión de procesos.

    • 'Capítulo 2: Process Mining: The Missing Link': Sitúa la disciplina del process mining. Para ello primero explica las limitaciones del modelado, explica lo que es el process mining y su funcionamiento básico y finalmente sitúa esta disciplina en relación con otras como el BPM, Data Mining, Six Sigma, Reingenieria de Procesos, Busines Intelligence, etc

  • 'PARTE II: PRELIMINARIES': Ya que, de alguna forma, Process Mining es una especie de fusión o influencia de técnicas (procesos y data science), en esta parte proporciona ideas sobre ambos

    • 'Capítulo 3: Process Modelling And Analysis': Habla del modelado de procesos y explica algunas de las técnicas y modelos más conocidos en este campo como las Redes de Petri, YAWL, BPMN, Workflow Nets, etc

    • 'Capítulo 4: Data Mining': Introduce ahora el campo del Data Mining, presentando ideas como el aprendizaje supervisado y no supervisado, árboles de decisión, k-means clustering, etc. Y cierra explicando conceptos sobre la calidad de los modelos.

  • 'PARTE III: FROM EVENT LOGS TO PROCESS MODELS': quizá la parte central, y también la más compleja, explica desde la obtención de los datos hasta el descubrimiento de los procesos subyacentes mediante diferentes técnicas

    • 'Capítul 5: Getting The Data': Se centra en el primer paso: la obtención de datos. Nos habla de las fuentes posibles de datos, de los logs de eventos incluyendo el estándar XES, problemáticas de calidad de los datos, etc

    • 'Capítulo 6: Process Discovery: An Introduction': Entrando en la primera de las grandes áreas de aplicación del Process Mining, explica cómo se puede hacer el descubrimiento de procesos para lo cual, prinmero define el problema y luego explica el algoritmo alpha reconociendo también sus limitaciones y presentando algunos desafíos

    • 'Capítulo 7: Advanced Process Discovery Techniques': tras haber visto en el capítulo anterior que el algoritmo alpha no puede tratar correctamente las cuatro dimensiones de calidad (ajuste, simplicidad, precision y generalización) este capítulo presenta otras técnicas sin llegar a un detalle completo de las mismas. Así, nos habla de heuristic mining, genetic process mining, region-based mining o inductive mining.

  • 'PARTE IV: BEYOND PROCESS DISCOVERY': Otra parte muy importannte que aborda las otras aplicaciones del process mining aparte del descubrimiento de procesos

    • 'Capítulo 8: Conformance checking': Plantea el uso de process mining para comprobar el ajuste de la realidad al proceso definido. Empieza por presentar cuál es la problemática y los objetivos. Luego explica el 'token replay' y alineamientos. Finalmente presenta varias formas de usar el 'conformance checking'.

    • 'Capítulo 9: Mining Additional Perspectives': Presenta otras posibilidades del process mining incluyendo el organizational mining, los análisis de tiempo y probabilidades o decision mining.

    • 'Capítulo 10: Operational Support': Habla del uso del process mining, no para un análisis a posteriori sino para acciones útiles durante la propia ejecución de los casos en temas como detección, predicción y recomendación.

  • 'PARTE V: PUTTING PROCESS MINING TO WORK': Entra ya en aspectos mucho menos teóricos y más de la realidad del día a día

    • 'Capítulo 11: Process Mining Software': Repasa la tipología de herramientas software de process mining y describe someramente algunas de ellas como ProM y algunas otras tanto comerciales como no comerciales.

    • 'Capítulo 12: Process Mining In The Large': Habla de Process Mining en el entorno de los grandes volúmenes de datos y el Big Data.

    • 'Capítulo 13: Analyzing "Lasagna Processes"': Presenta el análisis en el caso de procesos bien estructurados.

    • 'Capítulo 14: Analyzing "Spaghetti Processes"': Presenta el análisis en el caso de procesos poco estructurados.

  • 'PARTE VI: REFLECTION': Una parte breve con unas consideraciones finales.

    • 'Capítulo 15: Cartography And Navigation': Usando la metáfora de los navegadores cartográficos, habla de mapas de procesos de negocio y algunas posibilidades para su navegación.

    • 'Capítulo 16: Epilogue': Un breve cierre en que vuelve a presentar a Process Mining como un puente entre BPM y Data Science, presenta algunos retos y hace una llamada a la acción.
'Process Mining. Data Science in action' es un libro de una altísima calidad, que explica muy bien los conceptos pero que, eso sí, es muy especializado y bastante complejo en algunos momentos, con abundancia de álgebra y definiciones formales que aportan mucho rigor y exactitud, pero que hacen más difícil la lectura y la comprensión.

Un libro para especialistas y, probablemente, más para el estudio detenido que para la lectura de seguido.

Wil van der Aalst

(Fuente: Wikipedia)

Wil van der Aalst
De nombre completo, Willibrordus Martinus Pancratius van der Aalst y nacido el 29 de Enero de 1966, es un científico de computadoras holandés y profesor a tiempo completo en RWTH Aachen University, donde lidera el equipo Process and Data Science (PADS). Sus intereses en investigación y docencia incluyen sistemas de información, gestión de workflow, redes de Petri, process mining, lenguajes de especificación y simulación. También es reconocido por su trabajo en patrones de workflow.

Nacido en Eersel, Holanda, van der Aalst obtuvo un grado en ciencias de la computación en 1988 en la Technische Universiteit Eindhoven (TU/e) y un doctorado en matemáticas en 1992 con la tesis "Timed colored Petri nets and their application to logistics" bajo la supervisión de Jaap Wessels y Kees van Hee.

En 1992 comenzó a trabajar en la Eindhoven University of Technology como profesor ayudante en el departamento de Matemáticas y Ciencias de la Computación, donde encabezó el grupo de investigación Specification and Modeling of Information systems (SMIS). Desde 2000 a 2003 fue profesor a tiempo parcial en el departamento de Ciencias de la Computación. Y desde 2000 a 2006 fue responsable del departamento de Sistemas de Información en el departamento de Gestión de la Tecnología de la Universidad de Eindhoven. Desde 2006 es profesor en el departamento de Matemáticas y Ciencias de la Computación de la Eindhoven University of Technology. También tiene una asignación a tiempo parcial en el grupo BPM de la Queensland University of Technology (QUT).

Ha sido profesor visitante en el Karlsruhe Institute of Technology (AIFB), en la University of Georgia (LSDIS), el Johann Wolfgang Goethe University Frankfurt am Main (WI-II), en la University of Colorado (CTRG), en Queensland University of Technology (CITI), en Aarhus University (DAIMI), y en la Fondazione Bruno Kessler (FBK).

Es editor asociado de varias revistas, incluyendo "IEEE Transactions on Services Computing", "IEEE Transactions on Industrial Informatics", "International Journal of Business Process Integration and Management", "International Journal on Enterprise Modelling and Information Systems Architectures", "Computers in Industry" y "Transactions on Petri Nets and Other Models of Concurrency".

Es editor de las series "Lecture Notes in Business Information Processing" (LNBIP) de Springer, miembro del comité editorial de "Distributed and Parallel Databases" y "Business and Information Systems Engineering" y miembro de varios comités directivos incluyendo "International Conference Series on Business Process Management" (presidente), "International Conference Series on Application and Theory of Petri nets" y "International Workshop Series on Web Services and Formal Methods". También es miembro de la Royal Holland Society of Sciences and Humanities (Koninklijke Hollandsche Maatschappij der Wetenschappen) y de la Academy of Europe (Academia Europaea). Van der Aslst fue elegido miembro de la Royal Netherlands Academy of Arts and Sciences en 2014.

Sus intereses de investigación se centran en los campos de sistemas de información, gestión de procesos de negocio, simulación, redes de Petri, modelos de procesos, sistemas de gestión de workflow, técnicas de verificación, process mining, systemas ERP, trabajo cooperativo soportado por ordenador, servicios web, rediseño de procesos de negocio, asignación de recursos y procesos de negocio interorganizacionales.

Es un firme partidario del software de código abierto. Inició y dirigió el desarrollo de:
  • El framework ProM, una herramienta de process mining
  • YAWL, un sistema de workflow
  • y otros varios software incluyendo Declare, Woflan, XRL, etc
También lanzó la iniciativa de patrones de workflow. Este trabajo influyó en estándares de la industria como el Business Process Execution Language (BPEL), el Business Process Modeling Notation (BPMN), etc. Las ideas de Van der Aalst han influenciado también varias herramientas comerciales ampliamente utilizadas como Flower, Protos, Futura Reflect, Staffware, WebSphere y ARIS.

Otras contribuciones científicas de Van der Aalst se encuentran en los campos del descubrimiento de procesos de negocio, cadenas de proceso dirigidas por eventos, la Workflow Management Coalition y XPDL.

Van der Aalst es un investigador altamente citado en ISI. Según Google Scholar es el octavo en el ranking de investigadores en computación en el mundo y el primero entre los no norteamericanos.

Puedes saber más del autor visitando su página oficial o siguiéndole en twitter donde se identifica como @wvdaalst.

Ficha técnica:

EDITORIAL: Springer
AÑO: 2016
ISBN: 978-3662498507
PAGINAS: 467

Artículos de este blog relacionados

miércoles, 28 de agosto de 2019

Patrones de migración a la nube: las seis Rs de AWS


En el post anterior comentábamos tres caminos (y medio) para la migración a la nube basándonos en las propuestas de Tom Laszewski, Kamal Arora, Erik Farr y Piyum Zonooz, en su libro 'Cloud Native Architectures',

Se incluía el realojamiento (lift-and-shift), del replataformado (lift-tinker-and-shift), de la reingeniería y del desarrollo nativo. Se trata de una visión algo resumida de las estrategias de migración posibles.

Los mismos autores, de hecho, nos hablan un poco más adelante de las llamadas 6 Rs (seis erres), de seis patrones o estrategias de migración a la nube que extienden un poco más la idea. Estos seis patrones parten de una propuesta inicial realizada por Gartner en 2011 en donde hablaba de 5 formas de migrar a la nube, a saber: rehost, refactor, rearchitect, rebuild, replace.

Apoyándose de forma explicita en esa ideas de Gartner (y hasta en las Rs iniciales), el equipo de AWS identifica seis estrategias para migrar aplicaciones a la nube:

Las 6 Rs de AWS para la migración a la nube

  • (R)ehosting:
    Se trata de la estrategia de lift-and-shift ya comentada, es decir, se trasladan las aplicaciones a la nube sin rediseño de ningún tipo casi (e incluso a veces literalmente) como una copia bit a bit. Hacerlo así a corto plazo no proporciona grandes beneficios pero permite una migración relativamente rápida (existen automatizaciones al respecto) y se espera que un posible rediseño posterior sea más sencillo una vez las aplicaciones se encuentran ya en la nube.

  • (R)eplatforming: Se corresponde con el escenario lift-tinker-and-shift, es decir, el medio del artículo anterior, donde no se cambia de forma fundamental la arquitectura de la aplicación pero se introduce alguna pequeña mejora.

  • (R)epurchasing: Se trata de una estrategia completamente diferente. En lugar de intentar migrar la aplicación existente, se adopta una nueva aplicación que ya está en la nube. Por ejemplo, podríamos abandonar nuestro CRM legado y migrar hacia Salesforce. Aunque no existe una migración de aplicación propiamente dicha, sí que resultan necesarias acciones como migrar datos, rediseñar interfaces, etc.

  • (R)efactoring / (R)e-architecting: Se trata de hacer un rediseño profundo de la aplicación para que ya sea realmente cloud nativa. Creo que abarca tanto lo que en el anterior artículo denominábamos reingeniería (cambios profundos en la aplicación) como el desarrollo cloud nativo que es la construcción desde cero.

  • (R)etire: En realidad no se trata de una migración sino de aprovechar el esfuerzo de análisis de la realidad de sistemas disponibles para prescindir de alguno que realmente no aporta valor o cuya funcionalidad puede ser absorbida por otro. Es una excelente oportunidad para simplificar el mapa de sistemas, lo que, aparte de ahorros de costes, aporta agilidad y mayor facilidad de gestión.

  • (R)etain: En realidad es una no migración, es decir, decidimos conscientemente no migrar una aplicación a la nube.

Estas 6 Rs, creo que ofrecen un panorama más completo de las opciones para la migración a la nube y diría que también más directivo en el sentido de contemplar decisiones no específicamente técnicas en la migración, sino también otras opciones como la de no migrar, apagar sistemas o adoptar un nuevo producto.

El mapa de opciones queda así bastante más claro...lo cual no significa que adoptar esas decisiones sea sencillo, y ejecutarlas tampoco.

lunes, 26 de agosto de 2019

Tres caminos (y medio) para migrar a la nube


El cloud computing 'ha llegado a nuestras vidas' o, más bien, a las de las empresas cuando éstas ya están dotadas de una importante infraestructura de TI (aplicaciones, servidores, redes, etc). Por lo tanto, el salto a la nube no es algo inmediato sino que, en general, implica un complejo y probablemente doloroso proceso de migración.

Cómo hacer ese viaje es una decisión de cada empresa pero se pueden sugerir algunos patrones. En su libro  'Cloud Native Architectures', los autores Tom Laszewski, Kamal Arora, Erik Farr y Piyum Zonooz, nos hablan en concreto de tres grandes caminos:

  • Realojamiento (lift-and-shift): Se trata de mover, simplemente, de trasladar los sistemas tal cual son, sin cambios, desde lo centros de proceso de datos de la empresa a la nube. Viene a ser casi como una copia bit a bit de aplicaciones, almacenamiento, bases de datos, etc Puede ser un primer paso pero sus beneficios son dudosos e, incluso, puede resultar en un coste neto en lugar de una eficiencia.

  • Reingeniería: Este camino se suele aplicar no a la totalidad de sistemas sino a un conjunto seleccionado y consiste en hacer un rediseño y recodificación parcial para una mejor adaptación a la nube y para aprovechar algunas de sus ventajas.

  • Desarrollo nativo: En este caso, más que un verdadera migración lo que se hace es un rediseño y recodificación completa de las aplicaciones para hacerlas completamente 'cloud native'. En cierto sentido es la mejor opción pero, evidentemente es muy radical y costosa en tiempo e inversión por lo que no parece fácil pensar que sea un camino que se aplique comúnmente a gran escala, al menos sin hacerlo convivir con otras opciones.

Estos serían los tres caminos básicos pero en el título hablo de tres y medio. ¿Por qué? Porque los autores nos hablan de una variante del realojamiento que casi considero un camino por si mismo. Se trata del lift-tinker-shift migration en que, aunque la mayor parte de la infraestructura TI se mueve tal cual es a la nube, sí se hace, a nivel de componentes muy concretos, un pequeño rediseño y aprovechamiento de las capacidades cloud. Así, en el libro se nos propone el ejemplo de, además de llevar tal cual todas las bases de datos a la nube, introducir el alamcenamiento de backups en a un almacenamiento en la nube. 

Veo estos tres caminos (y medio) como una especie de arquetipos, como unos esquemas de partida en que apoyarnos para estructurar nuestro propio camino de migración hacia la nube. un camino que presumo, al menos para grandes empresas, complejo, largo, personalizado y plagado de decisiones delicadas.

viernes, 23 de agosto de 2019

Surfeando el tsunami tecnológico con Ángel Bonet

'El tsunami tecnológico' es un recorrido por las tecnologías digitales (y no digitales) más disruptivas que están transformando ya nuestro mundo y continuarán haciéndolo en un futuro inmediato.

El libro, no muy extenso, tiene nueve capítulos principales, dedicado cada uno de ellos a una tecnología, rodeado de secciones anteriores y posteriores que abordan algún otro tema.

En concreto, la estructura es:
  • 'Introducción: historia de un sofá' a modo de prefacio, y usando una dura anécdota personal, el autor justifica su interés por el emprendimiento, la innovación y la tecnología.

  • 'De La Revolución Industrial a la Disrupción Tecnológica' traza un breve recorrido histórico por las diferentes revoluciones tecnológicas e industriales.

  • 'Qué son y cómo nos afectan las tecnologías disruptivas (TD)' es donde 'entra en harina' describiendo las tecnologías que el autor considera más disruptivas. Por cada una de ellas se nos ofrece una descripción, algunos ejemplos y se explica cómo afecta o puede afectar a las personas y a las empresas. Además, se nos proporcionan abundantes referencias y bibliografía. Las tecnologías seleccionadas son:

    • '1. Robótica'

    • '2. Internet de las Cosas (IoT)'

    • '3. Inteligencia Artificial (IA)'

    • '4. Conectividad móvil'

    • '5. La nube'

    • '6. Vehículo autónomo'

    • '7. Biotecnología'

    • '8. Nanotecnología'

    • '9. Impresión 3D'

  • 'La empresa del siglo XXI: los retos que plantea la Disrupción Tecnológica' terminado el recorrido tecnológico, se añaden algunas secciones con la vista puesta en cómo afrontar el reto tecnológico. Y la primera de estas secciones es la que afecta directamente a las empresas y para ello se plantea cómo deben ser las empresas del siglo XXI desde un punto de vista sobre todo de organización, cultura y liderazgo.

  • 'Los consumidores en el nuevo entorno' Hace un breve análisis del nuevo consumidor digital.

  • 'Epílogo: un mensaje optimista para terminar' breve cierre que, tras repasar los Objetivos de Desarrollo Sostenible de la ONU y cómo puede la tecnología contribuir a ellos, lanza un mensaje optimista confiando en la capacidad de cambio y resolución de problemas de la tecnología.
'El tsunami tecnológico' es un libro de carácter divulgativo, ameno, muy fácil de leer y entender y que hace un repaso inspirador y esperanzador del apasionante panorama tecnológico ante el que nos encontramos y sus enormes posibilidades no sólo de presente, sino también de futuro.

Angel Bonet

(Fuente: Sección Ficha de autor en Planeta de libros.)

Ángel Bonet
Ángel Bonet Codina es experto en innovación y en estrategias de Marketing y Ventas con más de veinticinco años de experiencia. Ha desarrollado su carrera profesional en el área de la consultoría y los servicios, pasando por empresas familiares, startups y multinacionales.

Actualmente es Chief Sales & Marketing Officer en Minsait (an Indra Company), compañía española multinacional de consultoría y tecnología con presencia en más de cien países, que contribuye a solucionar los grandes retos de la sociedad, transformando empresas e instituciones.

Asimismo, es fundador y presidente de la Fundación UnLtdSpain, aceleradora de empresas de impacto social, coautor de 'El nuevo consumidor digital' y uno de los conferenciantes en innovación y disrupción tecnológica más solicitados tanto en España como en América Latina.

Puedes saber más del autor visitando su página oficial o siguiéndole en twitter donde se identifica como @angelbonet.

Ficha técnica:

AUTOR: Ángel Bonet.
EDITORIAL: Deusto
AÑO: 2018
ISBN: 978-8423429677
PAGINAS: 208

Artículos de este blog relacionados

miércoles, 21 de agosto de 2019

Doce buenas prácticas para la construcción de software como servicio


Uno de los paradigmas que trae consigo el cloud computing es el ofrecimiento de las capacidades IT como un servicio siguiendo el modelo de utility empleado en agua, electricidad, etc. Una de las formas, quizá la más avanzada, de esa prestación 'como servicio', sea el Software como Servicio (SaaS, 'Software as a Service').

Proporcionar el software como servicio tiene unas importantísimas implicaciones a nivel de gestión TI y de modelos operativos y de negocio, pero también tiene, no lo olvidemos, una base tecnológica. Aunque el cloud computing está alcanzando ya unos niveles de madurez que nos hacen empezar a percibirlo como algo 'normal', lo cierto es que el diseño de aplicaciones para la nube, tiene sus indudables dificultades y problemáticas propias.

Cuando en el post anterior hablábamos del modelo de madurez para aplicaciones cloud nativas propuesto por de Tom Laszewski, Kamal Arora, Erik Farr y Piyum Zonooz, en su libro 'Cloud Native Architectures', mencionábamos, dentro del eje de diseño centrado en la aplicación, una metodología denominada 'los doce factores'.

En este post quisiera ampliar un poco más la información sobre esa metodología. En mi opinión, no se trata realmente de una metodología sino, más bien, de unas buenas prácticas nacidas de la experiencia práctica de los creadores del documento. Eso si, doce muy interesantes buenas prácticas y que creo que recogen muy acertadamente la experiencia de sus creadores y proporcionan buenos sabios consejos.

Las doce buenas prácticas son, muy resumidas, las siguientes:
  • Código base (codebase): Utilizar un repositorio de control de versiones y un código base único usado para los diferentes despliegues que puedan ser necesarios.

  • Dependencias: Declarar todas las dependencias de forma completa y explícita de forma que una aplicación no dependa nunca de la existencia de paquetes ya instalados.

  • Configuraciones: Separación estricta de configuración y código y almacenamiento de la configuración en el entorno.

  • Servicios de soporte: Tratar los servicios de soporte como 'attached resources' y tratar de la misma forma los servicios propios y los proporcionados por terceros.

  • Construcción, despliegue y ejecución: Separación completa de las fases de construcción, distribución y ejecución.

  • Procesos: Las aplicaciones se ejecutan como procesos sin estado y son 'share nothing', es decir, cualquier información que deban almacenar se hará mediante un servicio de soporte (como una base de datos).

  • Asignación de puertos: Hacer aplicaciones auto-contenidas sin dependencia de la existencia de un servidor web y, a esos efectos, publicar los servicios indicando los puertos en que escuchan.

  • Concurrencia: Preparar la aplicación para escalar con base en una correcta aplicación del modelo de procesos y confiar en el gestor de procesos del sistema operativo.

  • 'Desechabilidad': Hacer las aplicaciones 'desechables' es decir, que puedan iniciarse y finalizarse en el momento que sea necesario y teniendo en cuenta cosas como minimizar el tiempo de arranque y la finalización en modo seguro.

  • Paridad desarrollo/producción: Minimizar las diferencias (de tiempo, personal y herramientas) entre entornos de desarrollo y producción, facilitando la filosofía del despliegue continuo.

  • Trazas (logs): Hacer que la aplicación 'se despreocupe' del enrutado o almacenamiento de los 'logs'. escribiendo en su lugar en la salida estándar y, posteriormente, en cada entorno, haciendo la redirección de esa salida a donde sea oportuno.

  • Procesos de administración: Hacer que procesos del tipo de migraciones, scripts, etc se ejecuten en el mismo entorno que los procesos 'normales'.
Estas buenas prácticas, por supuesto, se explican en más detalle que lo aquí mencionado y están accesibles en la web, incluso en español, y también se pueden descargar como documento ePub.

Escritas por técnicos para técnicos, creo que estas doce buenas prácticas pueden resultar muy interesantes e ilustrativas para desarrolladores, arquitectos y operadores cloud.

lunes, 19 de agosto de 2019

Un modelo de madurez para aplicaciones cloud nativas


Aunque en mi libro "La Carrera Digital" clasifico aún el cloud computing como una tendencia, más que como una realidad madura, lo cierto es que su nivel de implantación y popularización es cada vez mayor y se va acercando a la madurez.

Tanto es así que, por lo que he descubierto, ya existe incluso algún modelo de madurez. Me estoy refiriendo en este caso al modelo que se propone en el libro 'Cloud Native Architectures' de Tom Laszewski, Kamal Arora, Erik Farr y Piyum Zonooz, que denominan, simplemente, Cloud Native Maturity Model (CNMM) y que se ilustra en la figura inferior:



Se trata de un modelo para las aplicaciones cloud native que son aquellas que aprovechan todas las potencialidades y características de cloud.

El modelo considera tres ejes y, a su vez, dentro de cada eje, existen tres niveles. Enunciados brevemente los ejes y sus elementos son los siguientes:

  • Eje 1: Servicios cloud nativos un eje centrado, como resulta evidente, en la disponibilidad y uso de servicios en la nube. En este eje distingue tres niveles

    • Bloques constructivos (building blocks) hablaríamos de componentes básicos referidos sobre todo a infraestuctura incluyendo aspectos como capacidad de computación, almacenamiento, monitorización o networking.

    • Oferta de servicios gestionados Se trata de servicios que cubren funcionalidades básicas, poco diferenciadas e incluso poco apreciadas cuando se hacen correctamente, pero que son imprescindibles. En este nivel se incluyen elementos como bases de datos, servicios de directorio, balanceadores de carga, sistemas de 'caché', repositorios de código, herramientas de administración, etc

    • Servicios gestionados avanzados en la nube Se incluyen los servicios más avanzados, incluyendo aquellos que adoptan el modelo serverless o los que ofrecen funcionalidad de machine Learning.

  • Eje 2: Diseño centrado en la aplicación En este eje se trata de hacer un diseño adecuado de las aplicaciones que saquen el máximo partido a las capacidades de cloud computing. De nuevo, nos encontramos con tres niveles

    • Los 12 factores de una aplicación Se trata de aplicar los principios definidos en la metodología de los doce factores, descrita en 2011, que aplica a todo tipo de lenguajes y uso de servicios y que proporciona una guía para conseguir aplicaciones escalables, con una interacción simple con el entorno y que permiten una rápida incorporación de nuevos desarrolladores.

    • Microservicios Uso del concepto de microservicios, una evolución de SOA en que se pone énfasis en unos servicios más discretos y aún menos acoplados.

    • Diseño cloud nativo incluyendo consideraciones sobre instrumentación (monitorización y medida), seguridad, paralelización, resiliencia o eventos.

  • Eje 3: Automatización Se trata de un aspecto operacional pero muy importante: la automatización de las tareas de despliegue, monitorización y gestión. Se habla, de nuevo, de tres niveles:

    • Despliegue, configuración y gestión se centra en las tareas de provisión y configuración propiciando el concepto CICD ('Continuous Integration, Continuous Deployment') tan propio de filosofías DevOps.

    • Monitorización, cumplimiento normativo y optimización Se trata de emplear servicios que proporcionan capacidades de monitorización, y automatizar tareas como, por ejemplo, aumentar automáticamente la capacidad ante un pico de demanda. También se menciona el uso intensivo del logging como fuente para la realización de análisis.

    • Analítica predictiva, Inteligencia Artificial y Machine Learning En el nivel más avanzado se trataría de aplicar técnicas de inteligencia artificial y Machine Learning para, a partir de información como la obtenidos a partir de los propios logs, realizar predicciones sobre cómo ciertos eventos podrían afectar al sistema y tomar las medidas oportunas.

No sé si el modelo propuesto se puede considerar un modelo de madurez riguroso, pero sí me parece interesante como una forma de ordenar las capacidades a usar en aplicaciones cloud y con una forma de clasificar aquellas más básicas y aquellas más avanzadas.


miércoles, 14 de agosto de 2019

Soledad creativa


En el post anterior vimos algún juicio crítico acerca del brainstorming, una de las herramientas más admitidas, conocidas y utilizadas como estímulo de la creatividad. El brainstorming es una de tantas herramientas que trabaja con grupos.

Siempre he sostenido, quizá porque mi propia personalidad me impulsa a ello, que sin restar valor al trabajo en grupo, también es muy valioso y necesario el trabajo individual, el propio estudio, la propia reflexión, y el propio desarrollo de ideas, conceptos y documentos.

Pues bien, en el mismo libro 'Strategic Management of Technological Innovation' de Melissa A. Schilling, y justo a continuación de la exposición de la revisión crítica del brainstorming, se exponen, precisamente, los beneficios del trabajo individual. De la exposición que quedo con este pequeño párrafo que abre la argumentación.

Solitude is extremely valuable for creativity. It affords a person the time to think and pursue those things they find intrinsically interesting.

Una sorprendente, aunque creo que acertada, alabanza de la soledad, de la soledad como elemento de creatividad ya que permite concentrarse en los intereses individuales. A eso yo añadiría que ofrece el tiempo y la reflexión para la generación y análisis de ideas.

Como complemento de esa soledad, la autora nos habla de otro valor que también practico y que considero esencial: la auto formación. Creo que, en efecto, la auto formación, adquirida esencialmente por lectura de libros, artículos y blogs, pero hoy en día también complementada mediante la búsqueda en Internet o los MOOCs, es un arma fundamental para el desarrollo profesional en general y para la creatividad en particular, ya que las nuevas ideas se suelen construir con frecuencia mediante recombinación de ideas de terceros o de reutilización en el propio campo de trabajo, de ideas que ya se han aplicado en otro sector o problemática. La afirmación se ilustra citando un estudio sobre grandes innovadores y se nos dice que:

Research on serial breakthrough innovators show that many spent significant time alone, investing heavily in self education.

En el texto se nos pone el ejemplo de Elon Musk, al parecer un reconocido emprendedor e innovación en serie y, por lo que se nos cuenta, un empedernido lector que ha tenido temporadas de dedicar diez horas diarias a la lectura.

Así que, si: a pesar de lo que pudiéramos pensar, a pesar de mucha literatura en pro del trabajo en grupo, la soledad es creativa.

lunes, 12 de agosto de 2019

Cuestionando el brainstorming


El brainstorming es quizá una de las herramientas más conocidas para la ideación, para esa fase inicial divergente de la creatividad en que lo importante es generar muchas ideas, cuantas más mejor, para luego trabajar sobre ellas.

Es tan popular que casi, casi se ha incorporado al lenguaje de la calle.

Conocemos la técnica (más o menos) y la damos por buena. pero ¿es realmente tan útil? Bueno, hay mucha gente y muchos expertos que dirían que sí, pero también hay alguna voz discordante, que visualiza riesgos en la aplicación de esta técnica.

En concreto, leyendo el libro 'Strategic Management of Technological Innovation' de Melissa A. Schilling, veo que la autora cita algunos estudios según los cuales la supuesta fertilización cruzada de ideas que se produce en el brainstorming tiende a dar como resultado consensos mediocres, más que emocionantes nuevas ideas. Tres son las razones que parecen explicar esos resultados:

  • Miedo a ser juzgado: aunque en la práctica del brainstorming explícitamente se indica a los participantes que se desinhiban al proponer ideas y que no juzgen las de los demás, parece que a pesar de todo se impone una cierta auto-censura y muchas buenas ideas no ven la luz por miedo a ser juzgados negativamente por los otros participantes.

  • Bloqueo de la producción de ideas: de forma un tanto sorprendente, el trabajar en grupo puede bloquear la generación de ideas por asuntos tan simples como que, al tener que esperar el turno para expresarlas, simplemente, se olvidan. Además, el escuchar las ideas de otros se tiende a desviar el propio curso de pensamiento hacia esas ideas abandonando el propio. También se producen dinámicas en que las personas más extrovertidas y dominantes tienden a eclipsar las aportaciones de otros.

  • La factibilidad supera a la originalidad: esta problemática afecta no tanto a la generación de ideas sino a la selección posterior. Según los estudios aportados, parece que tendemos a ser prudentes y dar mucho peso a la factibilidad práctica de las ideas y eso actúa en contra de la innovación, de las ideas más originales y divergentes.

Unas razones que nos previenen frente al brainstorming y que, como vemos, son razonables y fáciles de entender. Probablemente, incluso, coinciden con nuestra experiencia práctica en la participación en grupos donde se aplica esta técnica. Se basan además en unos estudios que no son especialmente novedosos (algunos tienen varios años). Y, sin embargo, parece que el brainstorming sigue siendo la técnica reina de la creatividad.

Supongo que tampoco cabe descalificarla. Hay que conocer que no es perfecta, intentar minimizar los riesgos mencionados y, probablemente, complementarla o sustituirla, según el caso, por otras técnicas.

viernes, 9 de agosto de 2019

La curiosa experiencia de una 'auto-reseña': Transformación Digital con... Ignacio G.R. Gavilán

'La Carrera Digital' es mi propio libro, un libro escrito por mi. En ese sentido, puede ser difícil mantener la objetividad. He dado vueltas sobre si debía reseñarlo o si no reseñarlo. Y mi conclusión ha sido afirmativa, porque lo cierto es que no sólo le he escrito, también lo he leído. Lo tuve que leer, evidentemente, para repasar el texto y para revisar las galeradas. Pero también lo he leído posteriormente como lo haría un lector cualquiera, sin más empeño que leerlo y acceder a su contenido de una forma ordenada.

Además, 'La Carrera Digital' se adentra en temas que me interesan como la tecnología y la transformación digital y sobre los cuales leo a muchos autores y muchos libros. La obra de esos autores forma parte de mi biblioteca como profesional y como interesado en esas materias. Y la obra de esos autores la suelo reseñar en este blog. Y por tanto, 'La Carrera Digital' creo que también debe formar parte de mi biblioteca, no solo de escritor, sino también de profesional y se merece ser reseñado en este blog como cualquier libro similar..

Así que si, lo voy a reseñar. Igual que haría con otro libro y sólo, quizá, poniendo un poco de cuidado en los juicios de valor, para intentar no incurrir en sesgos y, en aras de esa aspiración a la neutralidad, incluso hablaré de mi mismo en tercera persona.

Vamos allá.

'La Carrera Digital' versa, fundamentalmente, sobre Transformación Digital, una transformación que se enfoca bajo tres ópticas diferentes: la tecnología, la gestión y el lado humano. Como metáfora a lo largo del libro se emplea el atletismo (de ahí el uso de la palabra 'carrera' en el título) y con base en esa metáfora, esos tres bloques se agrupan en tres partes que el autor denomina 'Preparados', 'Listos' y 'Ya'. Además, y en una tercera dimensión, esos bloques se corresponden también con el armazón conceptual que el autor nos propone y que estructura en tres 'drivers': conocimiento, método y acción.

El libro se abre con una introducción titulada 'Ha llegado la hora' en que el autor presenta el libro y sus motivos para escribirlo. A esto sigue un prefacio 'Salida' en que se mezcla por primera vez la visión atlética y la tecnológica para explicar la transformación digital y sirve de imaginario inicio de la carrera que supone todo el libro.

A partir de ahí, el contenido se estructura en diez capítulos agrupados en tres partes. Cada parte se inicia con una suerte de introducción que mantiene la metáfora de la carrera y se cierra con unas reflexiones muy personales del autor y que nos presenta como un 'avituallamiento'. Cada capítulo, además, se cierra con un breve resumen 'Técnica de carrera: lo que tienes que interiorizar' que resume los puntos más relevantes del capítulo. Según todo eso, la estructura es la siguiente:

  • 'PARTE I: PREPARADOS': Una primera parte, la más larga, ocupando más o menos la mitad del libro, que se centra, fundamentalmente, en la tecnología y su papel habilitador de la transformación digital y que incluye cuatro capítulos y un 'avituallamiento'.

    • 'Capítulo 1: Entender la revolución digital: ' explica los fundamentos más basicos de lo digital, desde su propia definición hasta la diferenciación entre hardware y software y su importancia así como la identificación de seis características de lo digital que le confieren su carácter disruptivo.

    • 'Capítulo 2: Realidades digitales: ' es un repaso por las tecnologías digitales más maduras que incluye comunicaciones, sistemas de información, bases de datos, integración de sistemas, automatización de procesos de negocio, internet, social media, comercio electrónico, movilidad y puesto de trabajo digital.

    • 'Capítulo 3: Tendencias digitales:' revisa ahora las tecnologías digitales más modernas y disruptivas y en esa revisión se incluyen el cloud computing, la automatización robótica de procesos, big data, inteligencia artificial, chatbots, blockchain, internet de las cosas y realidad extendida.

    • 'Capítulo 4: Transformación digital: ' Explica el concepto de transformación digital y ejemplifica cómo se puede materializar a nivel de sistemas de información, puesto de trabajo, relación con el cliente, procesos de negocio, productos y servicios y modelo de negocio.

    • 'Primer avituallamiento: conocimiento: ' hace una apuesta por el conocimiento y el rigor y reafirma la importancia de la tecnología como base y como habilitadora de la transformación digital.


  • 'PARTE II: LISTOS': Segunda parte que aborda la parte más metodológica o de gestión, con foco, por un lado, en el encaje estratégico y, por otro en una definición de programa de transformación y de su gestión muy apoyada en la disciplina de dirección de proyectos. Esta parte se compone de tres capítulos y un 'avituallamiento'.

    • 'Capítulo 5: Encaje estratégico: ' Explica la necesidad del encaje de la transformación digital en la estrategia competitiva de las empresas y en su modelo de negocio, ya sea para ser coherente con ellos o ya sea para redefinirlos.

    • 'Capítulo 6: Selección de iniciativas de transformación: ' propone una mecánica sencilla y comprensible para la identificación de iniciativas de transformación y para su priorización y selección.

    • 'Capítulo 7: Programa y proyectos de transformación: ' explica cómo gestionar un programa y cada uno de los proyectos que lo componen con base en las técnicas de dirección de proyectos.

    • 'Segundo avituallamiento: método: ' a modo de expereincia y conclusión, refuerza la idea de la necesidad del rigor y el método y del seguimiento riguroso de un plan.


  • 'PARTE III: YA': tercera y última parte que aborda los temas más relacionados con la cultura y las personas. Se compone de tres capítulos y su correspondiente avituallamiento.

    • 'Capítulo 8: Cultura digital y transformación cultural: ' identifica los elementos de la cultura digital que acompañan y que se deben tener en cuenta en esa transformación.

    • 'Capítulo 9: Comunicación y gestión del cambio: ' Tras analizar las causas posibles de la resistencia al cambio, repasa las herramientas fundamentales y las mecánicas más adecuadas en cuanto a formación y comunicación.

    • 'Capítulo 10: Liderazgo: ' identifica las cualidades del nuevo liderazgo digital y describe las funciones del liderazgo en la transformación.

    • 'Tercer avituallamiento: acción: ' expresa experiencias y perspectivas en cuanto a liderazgo y comunicación y hace una apuesta decidida por las personas y por los valores

El libro se cierra con un posfacio titulado 'Meta' donde, retomando por última vez la netáfora de la carrera, y con una perspectiva muy personal, acaba con una especie de llamamiento casi emocionado a la acción inmediata y continua.

'La Carrera Digital' es un libro de carácter fundamentalmente divulgativo aunque, para mejor apreciarlo, es bueno leerlo con alguna experiencia de gestión y algún conocimiento tecnológico de partida. Un libro que proporciona una visión muy transversal de la transformación digital cubriendo tanto el aspecto tecnológico como el humano y el de gestión.

Ignacio G.R. Gavilán

(Fuente: Sección 'Acerca del autor' de su libro La Carrera Digital.)

Ignacio G.R. Gavilán
Ignacio G.R. Gavilán (Ignacio González de los Reyes-Gavilán) es asesor empresarial, profesor, escritor y conferenciante, especializado en innovación y transformación digital de procesos y modelos de negocio.

Desde 2018 dirige su propia firma de asesoría y formación, Reingeniería Digital, especializada en la definición de planes de transformación digital de compañías y de mejora de procesos de negocio mediante la aplicación de tecnología digital. Además, es profesor y mentor de proyectos en EOI (Escuela de Organización Industrial).

Anteriormente, entre 1992 y 2018, prestó servicios como mando en diversas unidades de Telefónica.

Allí estuvo más de doce años (1992 a 2005) en Telefónica Investigación y Desarrollo, donde tuvo responsabilidad en proyectos de desarrollo de sistemas de CRM, gestión de red, provisión y trouble ticketing de servicios de telecomunicación y donde participó activamente en el plan de innovación, trabajando en los ámbitos de historia clínica electrónica y soluciones de colaboración P2P desarrolladas con metodología agile.

Posteriormente, y encuadrado en Telefónica Soluciones de Informática y Comunicaciones (2005 a 2012), fue responsable del desarrollo de negocio y ejecución de proyectos y servicios para grandes clientes, fundamentalmente en el ámbito del puesto de trabajo digital y soluciones de conectividad LAN.

Desde 2012 a 2018, ya en Telefónica de España, coordinó los trabajos de la unidad de Operaciones y Red, tanto en el lanzamiento del servicio Movistar Fusión Empresas como, posteriormente, en una ambiciosa iniciativa de compañía en materia de reingeniería de procesos y sistemas.

Anteriormente a su ingreso en Telefónica, entre 1990 y 1992, prestó servicios en GADD S.A., donde participó en proyectos de desarrollo de sistemas de gestión documental y receta electrónica.

Ignacio G.R. Gavilán es ingeniero superior industrial por la Universidad de Oviedo, con especialidad en Electrónica y Automática. Tiene un Executive MBA en 2000 por IE Business School y mantiene las certificaciones PMP (Project Management Professional) en dirección de proyectos y OCEB2 (Object Management Group Certificate Expert in Business Process Management) en gestión de procesos de negocio.

Nació en Oviedo (Asturias), pero actualmente, y desde hace más de veinticinco años, reside en Madrid. Está casado y es padre de dos hijas.

Entre sus aficiones se cuentan la literatura y el deporte, habiendo sido practicante en su juventud del baloncesto, estando más enfocado en la actualidad a golf, pádel y sobre todo, y modestamente, al atletismo, formando parte del Club Corredores de Alcobendas (Madrid).

Ignacio es muy activo en medios sociales y le puedes encontrar en su página oficial (ignaciogavilan.com), en su blog Blue Chip (ignaciogavilan.com/blue-chip), Twitter (@igrgavilan) y YouTube.

Puedes saber más sobre el autor, visitando su página oficial o siguiéndole en Twitter donde se identifica como @igrgavilan

Ficha técnica:

TITULO: La Carrera Digital
EDITORIAL: ExLibric
AÑO: 2019
ISBN: 978-8417845162
PAGINAS: 316

Artículos de este blog relacionados

viernes, 2 de agosto de 2019

El teclado QWERTY y lo que enseña sobre innovación y competencia


Las cosas no siempre son lo que parecen. Ese aforismo se aplica casi a cualquier ámbito de la vida pero, como vamos a ver, también se traslada al mundo de la empresa, de la innovación y de la competencia.

De forma intuitiva pensamos que en el mercado triunfan los mejores productos/servicios, ya sea aquellos que ofrecen mejores prestaciones, o mejor precio o alguna otra cualidad en que ese producto / servicio es 'mejor' que su competencia.

Racionalmente es así y en la realidad también sucede así con frecuencia... pero no siempre, porque las cosas no siempre son lo que parecen.

¿Conoce el lector la historia del teclado QWERTY? 

Si, esa disposición del teclado en que las letras no aparecen en orden alfabético sino en una disposición casi imposible de explicar y que hace que las cinco primeras letras de arriba a la izquierda sea, precisamente: Q, W, E, R, T, Y. Una disposición de teclado que no sabemos explicar pero a la que nos hemos acostumbrado porque es omnipresente en los teclados de las antiguas máquinas de escribir y de los actuales ordenadores y smartphones.

¿A qué obedece esa disposición de las teclas?

Si seguimos nuestro enfoque racional, pensaríamos que de alguna forma es la 'mejor' disposición de teclas: la disposición más cómoda para las manos, o que tiene en cuenta de alguna forma la frecuencia del uso de cada letra para favorecer un movimiento lo más rápido y natural de nuestros dedos, o que favorece el uso de la parte central, o que, por algún motivo mecánico, es la que menos desgasta el teclado y lo hace más duradero. Algo así, algo que indique que ese tipo de teclado es el 'mejor'.

Pues nada de eso. Más bien es casi el 'peor'.

Los 'martillitos'
Según descubro (no lo conocía hasta ahora) en el libro 'Strategic Management of Technological Innovation' de Melissa A. Schilling resulta que el teclado QUERTY fue diseñado en 1867, nada más y nada menos, por un tal Christopher Scholes. En esa época, las máquinas de escribir eran de naturaleza mecánica (los menos jóvenes de los lectores de este blog recordarán perfectamente cómo eran las máquinas de escribir mecánicas): el pulsar una tecla, activaba un pequeño 'martillito (había uno por cada tecla) que golpeaba en el papel dejando su huella de tinta. Un mecanismo fascinante e ingenioso pero que tenía cierta tendencia a atascarse cuando se pulsaban las teclas muy rápido. Además, en la época de Scholes, las máquinas de escribir estaban construidas de una forma en que se golpeaba la parte de atrás del papel y la persona que escribía no veía lo escrito hasta que no sacaba ya la hoja completa.

Así que Scholes diseñó el teclado para evitar atascos. Lo concibió de forma que las letras que normalmente van en sucesión (en Inglés, lógicamente) estuviesen lo más separadas posible en el teclado, minimizando la posibilidad de atascos. No sólo eso, es que además, las veces que se pulsa con la mano izquierda (siempre pensando en textos en Inglés) en un teclado QWERTY es desproporcionadamente más alta que las que se pulsan con la derecha, aproximadamente 10 veces más. Lo que conduce a ¡una ralentización del tecleo! Claro esa ralentización, de nuevo, favorecía la minimización de atascos.


Un diseño que, en la época que se hizo era estudiado, racional y muy ingenioso.


Pero... ¿y hoy día?


Los teclados de ordenadores y smartphones no son mecánicos. No hay atascos. Y, más bien, querríamos favorecer la velocidad, no ralentizar.


¿Por qué se sigue entonces manteniendo el teclado QWERTY?


Pues tan simple, y tan sorprendente cuando lo contemplamos con una perspectiva de más de un siglo, como debido a los costes del cambio. Estar entrenado para teclear rápido en un teclado, cuesta tiempo, bastante tiempo y, una vez conseguido, como sucede en tantos aprendizajes, se hace de forma automática. Cuando tus manos 'vuelan' sobre un teclado QWERTY, pensar en otra disposición de teclas 'te mata'. Puedo contar, como experiencia personal que mi navegador Tom Tom, que todavía tengo, tiene un teclado en orden alfabético y 'me cuesta horrores' teclear en él una dirección porque mis dedos buscan instintivamente, una y otra vez, la disposición QWERTY.


De hecho, tras QWERTY se han diseñado otros teclados objetivamente mucho mejores... que no han tenido éxito ninguno en el mercado.


Y esta es la historia del teclado QWERTY.


¿Qué nos enseña esto sobre innovación?


Bueno, el ejemplo lo trae a colación en su libro Meslisa Schilling como un ejemplo en que el ser el primero en innovar ('first-mover') trae consigo una ventaja competitiva sostenible (¡como que se ha sostenido siglo y medio!), No siempre es así, hay muchas situaciones en que ser el primero en innovar no es lo más ventajoso pero cuando existen altos costes para cambiar de proveedor o solución, puede ser muy ventajoso ser ese 'first-mover'.


QWERTY así lo acredita...