Tiempo estimado de lectura ( 25 minutos)

Estaba trabajando en el uso de la electrónica impresa con papel (piense en la interactividad digital dentro de un libro normal) cuando recibí esa llamada telefónica de un amigo sobre «este astronauta que realmente quiere conocerte» . Tenía curiosidad, así que fui a conocer a alguien llamado Mark en Canonical. No sabía qué esperar. Los primeros minutos fueron ciertamente interesantes.

Astronauta = “Soy Mark. Me han dicho que eres un buen diseñador de UX «.
Yo = «No sé nada de diseño».
… silencio.

Fue una pausa incómoda. Entonces Mark, al darse cuenta de que la siguiente hora probablemente fue una pérdida de tiempo, me pidió que le contara algo de lo que sabía. Hablé sobre la evolución, los cambios en la industria y en poco tiempo ya estábamos en gráficos, mapas y computación en la nube. El tiempo pasó volando. Seguimos hablando. Me presentaron a otros y en lo que parecía la velocidad del rayo, estaba trabajando en Canonical. Tenía un trabajo, llevar Ubuntu a la nube. Llamé a mi amigo y le pregunté qué había pasado. Steve simplemente respondió «Sabía que te llevarías bien» . La vida está llena de agradables alborotadores como Steve.

El primer día que llegué al trabajo, estaba muy emocionado y tenía la mirada confusa habitual de un conejo mirando los faros. Mi jefe, que también era otro Steve, hizo las habituales rondas de presentaciones. Ese fue un momento interesante. Aunque me encantó la calidez de la gente que conocí, las primeras cinco respuestas a mi papel de llevar Ubuntu a la nube fueron negativas: “es una moda pasajera” , “¿por qué estamos haciendo eso?”, Etc. Sabía que iba a tener para construir una camarilla bastante rápido y crear algo de impulso. Sin embargo, mi primera tarea oficial fue analizar la estrategia de virtualización que se había escrito. Fue uno de esos momentos «oh, pero que has hecho”. Afortunadamente, no tomó mucho tiempo encontrar a otros con intereses comunes: Rick Clark, Soren Hansen, Nick Barcet y muchos otros. Steve George (mi jefe) también fue una de las personas más comprensivas para las que he trabajado, un buen amigo y luego estaba Mark. Sin Mark nada de esto hubiera sucedido.

El problema para empezar fue que Canonical se centró en el mercado de servidores y computadoras de escritorio. Se enfrentó a gigantes como RedHat y Microsoft. Hacía esfuerzos valientes, casi heroicos, pero Canonical era pequeño. Muchos querían centrarse en el sistema operativo del servidor, generar ingresos de las licencias de soporte y para unos pocos, la nube era una distracción. El problema era de concentración y lo que tenía que hacer era cambiar la mentalidad. Para explicar este problema y por qué importaba, voy a cubrir una serie de conceptos desde Three Horizons hasta Porter antes de volver a Canonical.

Los tres horizontes

Los tres horizontes fue un modelo presentado en la Alquimia del crecimiento de 1999. Se discutieron tres puntos de vista que cualquier corporación tenía que adoptar.

Horizonte 1: el negocio principal que proporciona las mayores ganancias y flujos de efectivo que deben ampliarse y defenderse.

Horizonte 2 : son las oportunidades emergentes y los negocios que impulsarán el crecimiento a medio plazo. Estos pueden incluir nuevas empresas en las que está invirtiendo y que se espera que generen ganancias futuras sustanciales.

Horizonte 3 : Son emprendimientos que deben asegurar el futuro a largo plazo de la empresa. Pueden incluir proyectos de investigación o programas piloto o incluso inversiones en startups.

Cuando me uní a Canonical, el horizonte 1 era el principal ingreso de soporte. El horizonte 2 incluía nuevos conceptos como el almacenamiento online, la tienda de aplicaciones y la extensión a más dispositivos. El horizonte 3 fue … bueno, estoy bastante convencido de que algunos habrían pensado que mi trabajo en la nube estaría en esta categoría. Si bien este modelo de tres horizontes es una forma razonable de examinar una empresa, personalmente lo encuentro inadecuado. A menudo encuentro que algunos lo confunden con el modelo de organización pionero – colono – urbanista (capítulo 4) al asociar los urbanistas con el horizonte 1 y los pioneros con el horizonte 3. Para explicar la debilidad del modelo, voy a usar el mapa de mapeo que presenté anteriormente en el capítulo 7. Para evitar que tenga que retroceder por los capítulos anteriores, he proporcionado ese mapa aquí en la figura 213.

Figura 213 – El mapa del mapeo

Supongamos ahora que decidimos utilizar el mapa del mapeo para construir un nuevo negocio. Tomaré una parte del mapa anterior y me concentraré en la provisión de pronósticos (es decir, anticipación de cambios conocidos) a otros. Podría haber construido una vida cómoda con bastante facilidad en torno a las señales débiles que había desarrollado para pronosticar el cambio mediante la creación de una pequeña consultora boutique que proporcionara pronósticos tecnológicos y de mercado. La premisa detrás de un negocio de este tipo se muestra en la figura 214. Mi propósito con un negocio de este tipo habría sido simplemente sobrevivir (es decir, ganar dinero), el usuario buscaría una ventaja sobre los competidores y probablemente lo mediría por el rendimiento del capital invertido. en un espacio. La empresa en sí misma proporcionaría servicios de anticipación basados ​​en patrones climáticos (económicos) conocidos que utilizan mapas de la industria.

Figura 214 – Servicio de consultoría

El horizonte 1 sería ese negocio de consultoría boutique. Habría estado protegiendo (es decir, sin crear bienes comunes creativos) los veinte patrones económicos comunes que conozco y que impactan el medio ambiente. Probablemente usaría un mecanismo basado en el valor (o basado en el resultado, como se llama hoy) para cobrar. También podría ampliar este mapa para cubrir con más detalle los componentes de capital social de la confianza y las actividades necesarias para realizar el análisis o dirigir la empresa. Recuerde que puede mapear todas las formas de capital, ya sean datos, práctica, actividad, conocimiento o social. Supongamos que yo había decidido construir esta empresa y, por las buenas o por las malas, la convertí en un pequeño éxito. ¿Cuál sería mi horizonte 2?

En este caso, la difusión del conocimiento y la evolución provocada por la competencia entre oferta y demanda llevaría a muchos de esos componentes a un espacio más industrializado. En algún momento, tendría que prepararme para que mi consultoría boutique entrara en un mundo donde los productos hicieran lo mismo. Yo sabría de antemano que tendríamos inercia a eso, cualquier cambio de una etapa de evolución a otra (por ejemplo, de costumbre a producto) causa inercia a través del éxito pasado. Es uno de esos patrones climáticos. He mapeado este cambio en la figura 215.

Figura 215 – Horizonte dos

Pero, con previsión, y espero usar el mapeo en mí mismo, sería relativamente trivial anticipar y superar la inercia. ¿Qué tal el horizonte tres? En este caso, obtenemos una divergencia. Por ejemplo, podría centrarme en una mayor industrialización hacia un servicio de mayor utilidad expuesto a través de alguna forma de API: Anticipación como servicio o AaaS para abreviar. Por supuesto, el cambio junto con la alegría sobre el acrónimo vendría con una inercia significativa creada por cualquier modelo de negocio existente basado en productos. Alternativamente, podría expandirme a algo nuevo, como el uso de la doctrina para el análisis de la competencia o la venta de armas de un juego específico de contexto o incluso algún sistema nuevo, inexplorado y de orden superior que ni siquiera he considerado. He mostrado estos tres horizontes divergentes en la figura 216.

Figura 216 – Horizonte tres

Ahora agreguemos el modelo pionero – colono – urbanista (del inglés «Pioneer, Settler, Town planner» o «PST») en el mapa del horizonte tres (ver figura 217). Recuerda que cada equipo tiene diferentes actitudes, que es lo que representan pioneros, colonos y urbanistas. Cada equipo no solo construye, sino que opera y mantiene su propio trabajo hasta que otro equipo se lo quite. Lo importante a tener en cuenta es que el horizonte tres está formado por urbanistas o colonos o pioneros o todos ellos, dependiendo de dónde elija enfocarme.

Figura 217 – PST agregado al horizonte tres.

Los horizontes son específicos del contexto. No puede simplemente superponerlos en un modelo PST o incluso en el concepto de evolución diciendo «la génesis es el horizonte tres»ya que depende de dónde se encuentre y del paisaje que lo rodea. Por ejemplo, dependiendo de dónde se encuentre la empresa en el mapa, el horizonte tres podría ser la génesis de un nuevo acto o el cambio de un producto a una mercancía o incluso a un nuevo producto. Eso, por supuesto, supone que por horizonte tres te refieres al futuro lejano. Si se ciñe a los horizontes que se basan en general en la evolución (es decir, desde la génesis hasta el producto y la mercancía), entonces puede encontrar que el horizonte tres es a veces su negocio principal, a veces su futuro ya veces su futuro lejano. Los horizontes no se comparan bien con la evolución y rápidamente se vuelve complicado a menos que acepte una terminología de horizonte uno como actual a horizonte tres como futuro lejano y les permita existir en diferentes partes del mapa.

Otra cosa a tener en cuenta es que, a menudo, los horizontes pueden ser ampliamente anticipables. Esto es lo que encuentro inadecuado con el modelo de horizonte porque sin un mapa y el aprendizaje de patrones económicos (también conocidos como climáticos) comunes, entonces es muy fácil pasar por alto lo obvio. Es por eso que encuentro los tres horizontes útiles como concepto de alto nivel, pero en general débiles en la práctica por sí mismos. Tampoco me ayuda a lidiar adecuadamente con la inercia o el legado.

El tema del legado

En el capítulo 9, examinamos los patrones climáticos de coevolución, es decir, las prácticas pueden coevolucionar con la evolución de una actividad. Por lo general, existe alguna forma de inercia en una actividad cambiante y esto puede verse agravado por la coevolución de la práctica. En la figura 218, tomé el diagrama original del capítulo y agregué algunas barreras de inercia para el cambio de producto a utilidad tanto para computación como para plataforma.

Figura 218 – Cambio de computación y plataforma

Como se discutió anteriormente, hay muchas formas que puede adoptar la inercia. Sin embargo, la pregunta que quiero que consideremos es ¿qué representa el legado en este mapa? Las dos áreas obvias para el legado son aquellas atrapadas detrás de las barreras de inercia, por ejemplo, computación como producto y plataforma como producto (es decir, stacks de plataforma). La siguiente obviedad incluye aquellas prácticas relacionadas, es decir, las mejores prácticas arquitectónicas asociadas con la computación como producto. Lo que no es tan obvio para empezar es el problema de que a medida que los componentes evolucionan y permiten que aparezcan sistemas de orden superior, los sistemas de orden inferior se vuelven menos visibles y, para la mayoría de nosotros, heredados. Los departamentos que administraban centralitas en la mayoría de las empresas alguna vez fueron un aspecto muy importante y, a menudo, visible de la comunicación. Para muchas empresas, esa actividad se ha consumido en la recepción o en los centros de llamadas de la misma manera que el correo electrónico se ha consumido en la sala postal. Todavía nos enviamos cartas (más que nunca) pero son digitales. En el mapa de arriba, el papel de los componentes debajo de la capa de la plataforma será menos visible. El tratamiento y la gestión de la infraestructura se convertirá en un legado para la mayoría de las empresas, como lo es hoy la centralita.

Por lo tanto, otra área del legado serían las prácticas y actividades debajo de la capa de plataforma, que incluye conceptos como DevOps. En 2017, tal declaración tiende a recibir una fuerte reacción negativa. La mayoría reacciona con las mismas formas de inercia que aquellos que reaccionaron contra la nube en 2006. Muchos afirmarán que DevOps es más que infraestructura, ya que se trata de desarrollo y cultura. Dependiendo de qué tan lejos en el futuro estés leyendo esto, probablemente te sorprenderá mucho y es más probable que nunca hayas oído hablar de DevOps.

Como ocurre con todas esas cosas, DevOps fue un niño y una reacción contra los métodos de gestión predominantes. Cooptó conceptos de escuelas de pensamiento anteriores (por ejemplo, ITIL), incluidos enfoques iterativos, uso de componentes, gestión de la configuración, enfoque de servicios, un enfoque en los usuarios y la medición, al tiempo que se distanció de ellos. Añadió su propio dogma y creó una tribu separada. Lo mismo sucederá en la plataforma, surgirá una nueva escuela de pensamiento que copiará y se basará en DevOps, pero negará que tenga alguna relación con él. DevOps se convertirá en «lo que mi mamá y mi papá hacen” como el niño rebelde declara su independencia y niega cualquier herencia del primero. Muchos de los genes de DevOps se encontrarán en esta nueva generación (aunque rara vez lo admitirán, pintando DevOps como una especie de versión de hombre de paja de sí mismo), algunos de los genes se volverán recesivos y dominarán nuevos genes.

He marcado estas áreas principales de legado en nuestro mapa en la figura 219. Para hacer esto, he usado los conceptos de inercia y cómo los componentes industrializados permiten no solo sistemas de orden superior, sino que ellos mismos se vuelven menos visibles. También agregué una estructura típica de PST (pioneer, settler and town planner). Como podemos ver, muchas de las áreas heredadas existen dentro de los colonos y los equipos de planificación urbana.

Figura 219: adición de legado (una perspectiva del consumidor)

También hay una perspectiva a considerar aquí. Estoy mirando desde el punto de vista de alguien que consume computación. Si soy un proveedor importante, ya sea una plataforma en el futuro o computación de servicios públicos en la actualidad, mucho de esto definitivamente no es un legado más de lo que los sistemas de generación de energía lo son para los proveedores de electricidad. Desde la perspectiva de un proveedor importante, el legado se parecería más a la figura 220, es decir, consistirá en actividades (y prácticas relacionadas) que están atrapadas detrás de las barreras de inercia, pero no el impacto de los sistemas de orden inferior que se vuelven menos visibles. Lo que se vuelve cada vez más invisible para los demás (es decir, los consumidores) sigue siendo muy visible para los proveedores.

Figura 220: legado desde la perspectiva de un proveedor

A pesar de la desafortunada tendencia de la gente a asociar los grupos urbanísticos con el legado, de lo anterior debe quedar claro que este no es el caso. La computación en la nube ha tenido que ver con la industrialización de los urbanistas hacia los servicios públicos. El legado reciente ha sido modelos de productos pasados, un reino de colonos. Si tomamos la perspectiva del consumidor de la figura 219, entonces el futuro es una mezcla de colonos que crean aplicaciones, pioneros que descubren prácticas emergentes que combinan las finanzas con el desarrollo (al tiempo que niegan cualquier herencia de DevOps) y los urbanistas crean afanosamente los imperios de escala en torno a la utilidad de la plataforma de servicios. He mostrado este futuro en la figura 221 y es donde las empresas deberían invertir en 2017.

Figura 221: el futuro, desde la perspectiva del consumidor

Es importante tener en cuenta que el legado puede estar en cualquier lugar. Puede ser causado por una actividad personalizada que no ha evolucionado o por un negocio basado en productos en un mundo de servicios públicos. El legado es simplemente una consecuencia de la falta de evolución y no está asociado a un grupo como pioneros, colonos o urbanistas, sino a todos. Cuando se trata de administrar el legado, es realmente importante comprender esos puntos de cambio y el impacto de la coevolución. Esto se convertirá en una segunda naturaleza para ti, pero merece la pena practicarlo. Hay otra perspectiva más allá de los tres horizontes, más allá de la inercia y el legado que también debemos discutir. Es la perspectiva de las fuerzas de Porter.

En Porter

Para aquellos que no están familiarizados con las cinco fuerzas de Porter, estas son la rivalidad dentro de la industria, las amenazas de nuevos participantes, las amenazas de sustitución y el poder de negociación de proveedores contra consumidores. En esta sección vamos a examinar estas cinco fuerzas a través de la lente del ciclo de paz, guerra y maravillas (ver capítulo 9).

En el momento de maravilla , es un tipo de batalla para establecerse. El campo aún no está desarrollado y no hay » nuevos participantes «, ya que no hay cifras establecidas contra los «nuevos participantes» . Todo es nuevo, incierto e inexplorado. Es el salvaje oeste, hay dragones y el hogar de infinitivos divididos. Los consumidores tienen el poder y son ellos quienes deciden si esta industria tendrá éxito o no a pesar de su incapacidad inicial para saber si la necesitan.

En tiempos de paz , hay un tira y afloja constante entre el poder del proveedor y el consumidor sobre los productos producidos. Los gigantes en desarrollo normalmente están bien protegidos de los nuevos participantes en un juego de competencia relativa. La excepción es la ocasional amenaza de sustitución. Es esta sustitución por un producto diferente lo que tiende a ser el factor dominante.

En tiempos de guerra , los nuevos participantes que ofrecen una forma más industrializada del acto amenazan a los gigantes existentes que están atrapados detrás de las barreras de la inercia. Se convierte en una lucha por la supervivencia para estos gigantes y, a menudo, están mal equipados. No se trata de un caso de sustitución de un producto por otro, sino de un cambio de industria completa hacia formas más industrializadas. A menudo se asume que el cambio hacia la provisión de servicios públicos significa centralización, pero este no es el caso.

Si bien la interacción de todos los consumidores (competencia de la demanda) y todos los proveedores (competencia de la oferta) impulsa el proceso de evolución, la cuestión de si una actividad o conjunto de datos específico se centraliza o descentraliza depende de las acciones de los actores individuales (proveedores y consumidores) en este proceso. mercado. Por ejemplo, hubiera sido relativamente trivial para los fabricantes de hardware crear clones de Amazon y una guerra de precios en el espacio de IaaS alrededor de 2008-2010 para fragmentar el mercado al aumentar la demanda más allá de la capacidad de Amazon para suministrar, debido a la restricción de construcción de centros de datos. Tuve estas conversaciones exactas con Dell, IBM y HP durante 2008 y 2009. Incluso les dije que su propia inercia lucharía contra este cambio necesario y que negarían la existencia del equilibrio puntuado hasta que fuera demasiado tarde.

La centralización depende de las acciones de actores específicos (en este caso, la inacción de los proveedores de hardware y las empresas de alojamiento). En el futuro, esto puede, de hecho, cambiar de centralizado a descentralizado o encontrar un equilibrio entre los dos (como con el suministro de electricidad y la autogeneración). Sin embargo, es poco probable que tal cambio en los medios de producción cambie las interfaces en sí mismas, es decir, un cambio de generación central a autogeneración no significa un cambio en el voltaje o la frecuencia para el suministro de energía doméstica. Las futuras interfaces de la informática ya están definidas.

El punto a recordar con las fuerzas de Porter es que el equilibrio entre estas fuerzas tiende a cambiar a medida que evoluciona cualquier componente. Tampoco es estático dentro de una etapa de evolución, por ejemplo, el yo-yo entre centralización y descentralización con un yo-yo correspondiente entre el poder de negociación del Proveedor y el Consumidor. Sin embargo, como guía general, he proporcionado en la figura 222 las fuerzas más dominantes que probablemente encontrará.

Figura 222 – Fuerzas y evolución de Porter

Examinando Canonical

Con una comprensión básica de los horizontes, las fuerzas y el legado de Porter, ahora podemos examinar el negocio de Canonical. El horizonte uno (negocio principal) estaba relacionado con la venta de soporte en el SO del servidor (sistema operativo). Sin embargo, la computación estaba evolucionando hacia una mayor provisión de servicios públicos. Por lo tanto, con la excepción de los grandes proveedores de la nube, es probable que el soporte del sistema operativo del servidor se convierta en un negocio heredado. En cambio, necesitábamos centrarnos en el horizonte dos y el uso comercial del sistema operativo además de estos grandes entornos informáticos virtualizados. Entendimos que las empresas tendrían inercia a estos cambios y, al pasar de formas de productos a mercancías, era probable que se tratara de un equilibrio puntuado (período de cambio rápido). También comprendimos que las mayores amenazas en este espacio serían los nuevos participantes y, dado el estado del juego estratégico en muchas empresas, era probable que veamos la centralización. Dibujé estos conceptos en el mapa de la figura 223.

Figura 223 – el mercado cambiante

También entendimos que surgirían prácticas co-evolucionadas, que era poco probable que veamos ahorros significativos en TI, sino que aumentamos la actividad de desarrollo y que, en un horizonte adicional, el cambio de plataforma del producto a la utilidad era posible. He marcado estos horizontes en la figura 224.

Figura 224 – los horizontes

En términos de juego, entendimos que moverse rápido y apoderarse del territorio del SO cliente era esencial. Para ayudar en esto, también necesitábamos apoyar a quienes desarrollan aplicaciones o construyen herramientas en torno a esas prácticas coevolucionadas. Si encontrábamos ejemplos de juegos de plataformas en este espacio, también teníamos que invertir en esto. Entendimos que muchos clientes potenciales tendrían inercia, por lo tanto, tendríamos que proporcionar algunas formas de oferta de nube privada o de transición, incluso si esto no hiciera más que iniciar la conversación.

También sabíamos que nuestros competidores tenían inercia. Tan pronto como descubrí que a los vendedores de Red Hat se les recompensaba con bonificaciones basadas en suscripciones adicionales (utilizadas para actualizaciones de seguridad), rápidamente me puse a promover un mensaje de que la seguridad debería ser » gratuita » en la nube. No hay nada como amenazar con la bonificación de alguien para que se vuelva contra un cambio. Nuestro enfoque estaba claro dentro de mi camarilla. Mark hizo un trabajo increíble al convertir esto en el enfoque de toda la empresa. Rick y otros se dedicaron a hacer un esfuerzo de ingeniería para que esto sucediera. Steve me dio toda la potencia de fuego y la cobertura que necesitaba. Por mi parte, me concentré principalmente en promover el mensaje en la nube de Ubuntu, involucrarme en la comunidad, resaltar objetivos para incorporar y tratar de evitar que la gente reconstruya o se interponga en las cosas que la comunidad estaba haciendo.

En la figura 225 se proporciona un esquema del juego y en la figura 226 el resultado. En dieciocho meses, Ubuntu pasó de ser una pequeña parte del sistema operativo a dominar el SO cliente en la nube. Mi papel fue un papel menor pero instrumental y tengo que aplaudir a los maravillosos equipos de Canonical y dentro de la comunidad por hacerlo realidad. Una pequeña compañía de trescientos asumió el poder de dos hordas gigantes, pero a diferencia de los espartanos, esta vez ganamos. Mi momento de mayor orgullo fue escuchar a un CIO hablar sobre cómo “el futuro era todo RedHat y luego, de repente, todo era Ubuntu” . Yo jugué un pequeño papel en todo eso.

Figura 225 – nuestro enfoque

Figura 226 – los resultados

A menudo escucho a la gente hablar sobre la suerte que tuvo Canonical, bueno, siempre hay algo de suerte, pero los movimientos fueron deliberados. Obviamente, la gente puede simplemente decir que el momento fue afortunado, pero también se equivocarían en eso. Tuve una mano amiga con el tiempo gracias a Gartner. Probablemente ni siquiera se den cuenta, pero creo que merece la pena explicarlo.

Sobre la cuestión del tiempo

No soy un gran admirador de Gartner, pero la figura 227 es uno de los gráficos más útiles que jamás hayan producido. Es un ciclo exagerado de tecnologías emergentes creado en 2008. Utiliza el eje y anterior de visibilidad que más tarde se convirtió en expectativas . ¿Cómo puede cambiar el eje mientras el gráfico permanece igual? Ah, esa es la belleza, pero primero, un poco más de antecedentes.

Figura 227 – Tecnologías emergentes de Gartner, 2008

Durante mi tiempo en el desierto antes de Canonical, había estado buscando varias formas de medir los impactos de la evolución. Uno de los problemas con los que me había topado era que la evolución de un acto único crea dos oleadas de oportunidades. Una de estas ondas se centra en el valor diferencial (es decir, es algo que usted tiene pero yo no) y la segunda onda se centra en el valor operativo (es decir, ambos proporcionamos esto pero usted lo hace de manera más eficiente). Ambas ondas parecen tener un elemento de aprendizaje y luego un fuerte declive a medida que el cambio se difunde y evoluciona más. Proporcioné ejemplos de estas ondas en la figura 228.

Figura 228 – Un ejemplo de diferentes olas de valor

Por supuesto, la oportunidad es solo una parte de la ecuación. Hay efectos de volumen y el costo involucrado particularmente en el desarrollo de algo nuevo. También existe el riesgo, ya que el espacio inexplorado es, por su propia naturaleza, incierto. Sin embargo, desarrollé una curva de beneficio generalizada que para el valor diferencial se muestra en la figura 229. Parece existir una curva de beneficio casi idéntica para el valor operacional, pero que ocurre mucho más tarde en la evolución y está relacionada con las prácticas coevolucionadas que surgen.

Figura 229 – Una curva de beneficios para el valor diferencial

Desde la curva de beneficios, las primeras etapas de la génesis tienen que ver con la inversión. A medida que evoluciona, el coste de producción se reduce y comenzamos a darnos cuenta de algunos de los beneficios. Todavía estamos en la etapa de construcción personalizada, otros están comenzando a copiar, pero en general el coste de producción se está reduciendo lo suficientemente rápido como para superar cualquier pérdida diferencial debido a la copia. Por desgracia, en algún momento el coste de producción es lo suficientemente bajo y la actividad está lo suficientemente definida como para que alguien produzca un producto. Por el lado positivo, el coste de implementación está cayendo en picado, pero lamentablemente, el valor diferencial está disminuyendo más rápido a medida que más empresas implementan. Todos los modelos que desarrollé tenían variaciones de esta forma. No me siento lo suficientemente cómodo con los datos, así que piense en ellos más como un modelo mental y una posible curiosidad.

Mientras exploraba este espacio, me fascinaron los problemas de sincronización. Supongamos que hemos leído recientemente un documento técnico sobre alguna actividad nueva y maravillosa. Esa actividad se describe como que tiene algún beneficio, pero también implica un coste. Para cuando llegue a implementar la actividad, probablemente habrá evolucionado. Podría proporcionar un beneficio diferente al que esperaba, es decir, cuesta menos porque es un producto, pero hay poco valor diferencial ya que todos los demás también lo están haciendo. He superpuesto la evolución de un acto a la curva de beneficios en la figura 230 para resaltar este punto.

Figura 230 – Beneficio cambiante con la evolución y la implementación

Luego modelé este delta entre lo que esperaba obtener y lo que obtuve con el tiempo. El modelo que utilicé hizo muchas suposiciones horribles, es incómodamente parecido al vudú y es tan sólido como una torre de gelatina. En algún momento en el futuro, podría ir y volver a revisarlo, pero normalmente no menciono este pequeño viaje lateral. Sin embargo, hubo una cosa notable acerca de la curva de expectativa delta a lo largo del tiempo: se asemeja a un ciclo exagerado de Gartner; consulte la figura 231.

Figura 231 – expectativa delta a lo largo del tiempo (la curva de expectativa)

Tenemos el mismo pico de expectativa inflada y el mismo valle de delirio. Mi primera reacción fue de horror.

La curva de evolución sobre la que se construye el mapeo usa ubicuidad versus certeza. Si puedo modelar desde el ciclo de exageraciones de Gartner hasta la evolución, entonces puedo tomar los puntos en un ciclo de exageraciones y medir con precisión dónde está algo en el eje de certeza de la evolución. Para las cosas que son inciertas, esto debería ser imposible, ya que la capacidad de medir con precisión algo que es incierto es cosa de la magia. Mi primera reacción fue que el ciclo de publicidad de Gartner demostró que la evolución estaba mal. En ese momento estaba un poco perplejo, especialmente porque había encontrado que el mapeo era tan útil. Afortunadamente, me encontré con un amigo que señaló un gran vacío en mi argumento. Supuse que el ciclo de publicidad de Gartner se basaba en la medición de alguna propiedad física. Si no lo fue, si solo fuera una opinión agregada (de consultores, analistas o la industria), entonces no hay una medida de lo incierto, es solo una opinión. Es una opinión de dónde está algo, no una medida de dónde está realmente. Como descubrí posteriormente, el ciclo de la exageración es una opinión subjetiva.

Además de estar tranquilamente aliviado de no haber refutado todavía lo que encontraba útil, también abrió una nueva oportunidad. Tengo dos curvas de beneficios: una para el valor diferencial y otra para el valor operativo. Ambos compartían una expectativa común frente a un patrón de tiempo. Si observo un componente en evolución, el lugar donde aparece en las primeras etapas de la curva de expectativa para el valor diferencial puede ser el mismo lugar en el que aparece en la curva de expectativa para el valor operacional cuando está más evolucionado. Ver figura 232

Figura 232 – Evolución de un acto sobre curvas de expectativa diferencial y operativa

También tuve una señal débil usando tipos de publicación que podrían identificar cuándo es probable que las cosas comiencen a industrializarse y entren en una guerra (consulte el capítulo 9). Reimprimí el último análisis sobre esto que realicé en 2014 en la figura 233. Lo que me gustaría que noten es que el cambio de producto a utilidad para la infraestructura de computación se convirtió en una guerra en 2014. Mientras que la guerra por 3d la impresión y el uso de impresoras 3D comercializadas están lejos.

Figura 233 – ¿Cuándo es probable la guerra?

En 2008, ya sabía (por mis señales débiles) que estábamos entrando en la fase de guerra de la infraestructura informática, mientras que a la impresión 3D le quedaba mucho tiempo antes de que comenzara a industrializarse. También sospeché que tanto una actividad relativamente nueva (por ejemplo, impresión 3D) como una actividad de industrialización (nube) podrían aparecer en el mismo lugar en dos curvas de expectativa diferentes, una para el valor diferencial y otra para el valor operativo (figura 232 anterior). Por lo tanto, veamos nuevamente ese ciclo de publicidad de Gartner y resaltemos dos componentes: la computación en la nube y la impresión 3D.

Figura 234 – Computación en la nube e impresión 3D.

Ambos aparecieron aproximadamente en el mismo lugar. Esto me dijo algo que posteriormente encontré bastante útil. El ciclo de publicidad de Gartner no distingue entre valor diferencial y valor operacional, ya que ambos están en la misma curva. Entonces, ¿por qué importa eso? Bueno, en el caso de la computación en la nube, que fue la industrialización de la computación y todo el valor operacional que existía, lo que nos permitía ir con “todo” durante 2008. Estar en la etapa inicial de esta curva de expectativa solo refuerza el punto en el que las personas están aprendiendo sobre un cambio en el que usted absolutamente desea ser el primero en moverse. Lo último que querría hacer es esperar hasta que alcance la meseta de la productividad, momento en el que la guerra habrá terminado. Gartner incluso señala que esto se está moviendo rápido con el momento de incorporar la adopción de la nube (círculo azul claro).

Sin embargo, en el caso de la impresión 3D, debe esperar o ser un seguidor rápido. Tiene un largo camino por recorrer antes de que se industrialice y usted tiene toda una etapa de producto por la que debe evolucionar. De hecho, la impresión 3D alcanzará la meseta de la productividad y verá una adopción relativamente generalizada como producto mucho antes de que se industrialice. En algún momento futuro (2025-2030), cuando comience a industrializarse, probablemente reaparecerá en el disparador de tecnología, generalmente bajo un meme ligeramente diferente. Cuando se trata de impresión 3D, entonces puede esperar un poco e involucrarse en el espacio del producto o esperar mucho más hasta que la «guerra» esté en esa industria, momento en el que tendrá que ir «con todo«.

Dos puntos, la computación en la nube y la impresión 3D, en casi exactamente la misma posición del ciclo de publicidad, requirieron enfoques radicalmente diferentes de inversión y estrategia. Uno era «ir con todo«, el otro era «esperar y ver«. Siendo una opinión agregada, encuentro el ciclo de la exageración bastante útil siempre que separe en qué etapa de la evolución se encuentra algo primero. A menudo hablo con los CIO que me dicen que invierten cuando algo está en la etapa de iluminación. Esa es una forma bastante razonable de perder todas las guerras tecnológicas importantes en los negocios.

Para mí, en 2008, este ciclo de publicidad ayudó a reforzar el mensaje de que teníamos que «ir con todo», era una apropiación de tierras para este territorio. También me consoló que muchos de mis competidores probablemente leyeran exactamente el mismo ciclo de publicidad y pensaran que tenían tiempo. Hagamos hincapié en ese punto, iba «con todo» cuando los competidores pensaron que tenían tiempo; es una ayuda para el futuro buffet sin que nadie diga que no puede tener 7 raciones porque todos los demás se equivocaron en la fecha. Gracias Gartner, probablemente no tengas idea de cuánto me has ayudado. Mejor suerte la próxima vez IBM, HP, Dell, RedHat… suponiendo que sobrevivan a lo que está por venir.

De todos modos, la jugabilidad anterior fue de 2008 a principios de 2010. A mediados de 2010, después de capturar prácticamente todo el mercado (un espacio que ha crecido enormemente desde que Ubuntu sigue siendo el «alta gama» en 2016), volví a investigar. Mi trabajo estaba hecho. Naturalmente, dejé a Mark y a otros con una variedad de jugadas para usar junto con un enfoque específico en el espacio de la plataforma. No estoy necesariamente de acuerdo con todos los pasos que han dado, pero respeto sus elecciones y juegan un buen juego. Supongo que ese es el punto real: están jugando el juego, no yo, pero de alguna manera los ayudé a mejorar. Antes de sumergirnos en el espacio de la estrategia, deberíamos echar un vistazo a otra parte de mi viaje hacia el gobierno. Por tanto, vayamos con valentía al próximo capítulo.