Transcription
Una de mis consignas sobre arquitectura es que la arquitectura vende opciones. ¿Verdad? La arquitectura te da opciones en la forma en que te permite posponer decisiones para el futuro. ¿Verdad? Así que, por ejemplo, la gente dice: "Oh, nuestro sistema debe ser escalable". Bueno, esa es la opción de añadir capacidad de hardware o quitar capacidad de hardware. Fácil de hacer en la nube, ¿verdad? La idea de una arquitectura de escalado horizontal, balanceador de carga de aplicaciones, infraestructura elástica, como todos los ingredientes técnicos que conocemos muy bien. Pero la opción que realmente estás comprando es la opción de añadir o eliminar capacidad. Las opciones son valiosas porque si puedes posponer una decisión, generalmente puedes tomar una mejor decisión. Para mí, las opciones son una forma muy agradable de expresar lo que hace la arquitectura. Ahora, irónicamente, las opciones posponen decisiones. Mueven las decisiones al futuro. En muchos casos, la gente malinterpreta la arquitectura como que ellos son los que toman todas las decisiones. Siempre digo que los arquitectos venden opciones. No las donan. No son gratis, ¿verdad? Y pagas, por ejemplo, con complejidad. Una arquitectura de escalado horizontal, una que tiene APIs y es extensible, es también invariablemente más compleja. Las opciones no son gratis. Te cuestan esfuerzo y te cuestan complejidad. Y creo que encontrar ese equilibrio, ¿verdad? Las opciones que te gusta tener frente al costo de estas opciones, para mí eso es arquitectura. Hola a todos y bienvenidos de nuevo al podcast Bounderless Conversations [música]. En este podcast, exploramos el futuro de los modelos de negocio, las organizaciones, los mercados y la sociedad en nuestro mundo en rápida evolución. Hoy me acompaña mi co-anfitrión habitual Shriy Pash. Hola Shely. >> Hola a todos. >> Y tenemos un invitado extremadamente eminente hoy que se une a nuestro podcast Gregor Hope. Gregor es ampliamente considerado como uno de los principales pensadores [música] en la intersección, digamos, entre la arquitectura empresarial, el diseño transaccional [música] y las transformaciones tecnológicas a gran escala. Es autor de muchos libros, Software Architect Elevator, coautor de Enterprise Integration Patterns, entre otras obras influyentes que han dado forma [música] a cómo se diseñan los servicios de integración de sistemas de discapacidad. Es también el autor de su último libro, uh, Platform Strategy, que disfrutamos mucho. Hola Gregor, es un placer tenerte con nosotros hoy. Estamos súper emocionados de tenerte. Sí. Igualmente. Espero con ansias la charla. Gracias. [música] A lo largo de tu carrera, has ocupado [música] algunos roles de arquitectura muy importantes y has asesorado a tantas empresas. a algunas de las organizaciones tecnológicas más influyentes, trabajando con Allianz, luego Google y, más recientemente, también Amazon, pero también asesorando en esfuerzos de modernización del sector público, incluyendo, por ejemplo, la Autoridad Monetaria de Singapur, si no me equivoco, el banco central del país. En la preparación de la conversación, creo que tuvimos este interesante cambio y tú me dijiste que la discusión sobre la separación entre negocios y tecnología es un poco, al mismo tiempo, un tema antiguo pero también siempre relevante. Um, a veces hay este matiz en el que ves el lado tecnológico de las organizaciones que intenta aferrarse a ser relevante, ¿sabes?, en un mundo donde, irónicamente, las fuerzas impulsadas por la tecnología están haciendo que la tecnología sea menos relevante, ¿sabes?, más madura, más integrada en segundo plano. Pero luego, cuando trabajo con organizaciones de productos que tienen quizás, ¿sabes?, carteras de productos, incluso si son scaleups, parecen muy ágiles, terminan con los mismos problemas, terminas con problemas de orquestación, problemas de escalabilidad, problemas de rendimiento. ¿Cómo va realmente esta conversación? ¿Sigue siendo realmente relevante hablar de la relación entre tecnología y negocios? >> Sí. Y creo que de alguna manera divertida la pregunta inicial también podría ser la pregunta final porque es un tema importante. Así que, déjame darte mi experiencia con ello, habiendo trabajado tanto en Silicon Valley, grandes empresas como en el sector público. Mi estándar de oro es siempre cuando trabajé en Google, yo era un ingeniero y yo era el negocio. Así que siempre bromeaba diciendo que en una década en Silicon Valley, nadie dijo nunca: "Necesitamos hablar con el negocio". El concepto simplemente no existía. Yo era el negocio. Mi objetivo era un objetivo monetario de mejora de la tasa de ejecución anual. Yo estaba haciendo anuncios móviles, ¿verdad? Así que medimos la tasa de ejecución que generamos. Y, de hecho, para nosotros fue muy divertido porque pudimos seguir el impacto comercial de inmediato. La rentabilidad también fue buena para el equipo porque con cinco personas pudimos generar un aumento de ingresos bastante significativo. Sí. Y eso nos hizo felices y nos facilitó la recompensa por nuestro trabajo. Ahora, ese es un extremo y lo disfruté. Ahora, en las grandes organizaciones, tiende a ser bastante diferente. Bueno, en realidad, debemos tener cuidado cuando vemos grandes organizaciones porque Google, Amazon, Meta y como se les llame no son exactamente pequeños, ¿verdad? A menudo cometemos el error de pensar que son pequeños y jóvenes y que los otros son viejos y grandes, no es del todo cierto. Google tiene 30 años, ¿sabes? Microsoft tiene más de medio siglo. Así que creo que al final no se trata de crecer, donde empiezas de una manera y terminas de otra, sino que creo que es una actitud fundamentalmente diferente. Añadiría lo siguiente, que diría que en el pasado, cuando la tecnología era más estable, como las viejas bromas, ¿sabes?, simplemente comprabas un mainframe de IBM y ya estaba hecho. Creo que la separación funcionó. No fue tan mala y así es como las organizaciones se acostumbraron a ello porque, al final, si la gente puede, ¿sabes?, poner un poco de límites a lo que hacen, lo cual es irónico porque el podcast se llama sin límites. Soy un gran fan de no tener límites, pero a mucha gente le gusta tener límites, ¿verdad? Te permite concentrarte y también te da cierta diferenciación, otros no hacen lo que tú haces. Así que creo que la naturaleza humana, hasta cierto punto, es volver a algún tipo de división del trabajo, a algún tipo de límites, y en el pasado eso funcionó bien porque las elecciones tecnológicas que hacías no definían realmente qué tipo de negocio podías tener. Eres un banco, sigues siendo un banco. Compras un mainframe más grande, bueno, puedes tener quizás más clientes. Ahora, la tecnología define qué negocio puedes o no puedes hacer. Así que creo que las desventajas de la separación se han vuelto mucho más pronunciadas y muchos de mis clientes lo están descubriendo por las malas. >> Dijo que no se trata de lados, sino de actitud, ¿verdad? Y tal vez como segunda pregunta, puede ser útil vincular esto de nuevo a la cuestión de la arquitectura porque cuando decimos actitud, ¿qué queremos decir, ¿verdad? Eh, típicamente, a medida que creces, puedes crecer como una organización aislada, como una jerarquía, o puedes crecer de manera distribuida. La actitud a menudo se traduce en la arquitectura, ¿verdad? Entonces, ¿cómo se traduce la cuestión de la tecnología y los negocios en cómo tú, ¿sabes?, digamos, ¿cuáles son tus elecciones al desarrollar la organización, que es el tercer tema, ¿verdad? Así que cuando hablamos de una empresa, ¿sabes?, está el lado del producto, el negocio, está el lado de la tecnología y luego está el lado de la organización. ¿Cuál es tu experiencia de cuáles son algunos puntos de partida para empezar a mirar esta imagen desde estas tres perspectivas? Para mí, quizás retomando primero la parte de la arquitectura. Así que, lo peor que puedes hacer es convertir la arquitectura en otro silo. Ahora tienes tres, ¿verdad? Ese sería el peor de los casos. Sí, estoy seguro de que también lo ves, donde, ¿sabes?, el negocio está aquí, la tecnología está allá y la arquitectura flota en algún lugar del espacio dibujando diagramas y, ¿sabes?, haciendo hojas de ruta a cinco años que al final nadie lee y que nunca se cumplirán. Así que mi punto de vista es que si tienes un tercer elemento en la mezcla, y creo que tener arquitectura es muy valioso, el papel de ese tercer elemento tiene que ser conectar los otros dos, ¿verdad? Porque volviendo a lo que dijimos, a la gente le gustan los silos, lo último que queremos hacer es reforzar esa actitud, y sucede fácilmente, seamos honestos, ¿verdad? A mucha gente técnica le gusta hablar de lo que llamamos "tecnobabble", y eso definitivamente no ayuda a romper los silos. Y luego, lo que le gusta hacer al negocio es, bueno, no me importa la tecnología, solo implementa mi gran visión. Recibí un comentario así muy recientemente. Le dije, bueno, ¿sabes?, para alguien, solo empújanos, realmente no necesitamos un alto ejecutivo, para ser honesto, podemos poner un póster en la pared que diga: "Por favor, entrega rápido y barato". Así que ambas cosas, para mí, son formas de disfunción. Así que creo que la arquitectura, en mi opinión, puede aportar valor construyendo un mejor puente entre los otros dos. Ahora, eso podría significar, oye, si realmente logramos conectar los dos elementos, no necesitaríamos mucha arquitectura. Y, para ser honesto, estaría bastante bien con eso porque todavía tendría un millón de otras cosas que hacer. No veo que eso suceda pronto. Así que veo la arquitectura como el elemento de conexión entre el negocio y la TI, y encuentro que esa conexión es mucho más relevante de lo que era en el pasado. Digamos que la arquitectura crea el maletín, el puente o el lenguaje para unir estas piezas. ¿Es que la tecnología está ahí solo para apoyar al negocio? Esencialmente, tenemos una visión de negocio, está distribuida. Tenemos, por ejemplo, una cartera de productos de experiencias que queremos crear para los clientes y luego tenemos el problema de tener una tecnología de apoyo que garantice el rendimiento, que sea sostenible y replicable, que garantice que lo que queremos hacer, podemos hacerlo. Así que la impresión que tengo de esta conversación es, vale, como necesitamos tecnología para hacer lo que hacemos, creamos algún tipo de capa donde la tecnología pueda enchufarse y entregar lo que necesitamos. ¿O es que la tecnología, o la tecnología de la información, todavía tiene una importancia masiva? Y cuando pienso en esto, pienso en lo que típicamente veo en las organizaciones con las que trabajo, que es un patrón que veo una y otra vez. Parecen hablar con dos tipos de clientes, ¿verdad? Uno son los clientes no técnicos, el usuario final. Puede ser en una empresa, las empresas que usan tus productos o pueden ser quizás tus usuarios finales como en una empresa B2C. Y por otro lado, hablan con terceros que quizás extienden sus productos, coexisten con sus productos o usan algunas versiones de sus productos. Entonces, ¿es la tecnología la pieza de la organización que habla con esta parte del ecosistema, o es una arquitectura diferente la que estamos buscando? Tengo una fuerte opinión de que la relación entre negocio y TI es una calle de doble sentido ahora. Sabes, mucha gente dice que está ahí para apoyar al negocio y sí, eso es absolutamente cierto. Todo está ahí para apoyar al negocio porque si no tienes un negocio, no tienes una organización, a menos que seas del sector público. Así que no olvides el sector público. Pero para mí, si miras la innovación, también se trata de aprovechar las capacidades técnicas. Es una calle de doble sentido. Cuando surge una nueva tecnología, nos permite hacer cosas que antes no podíamos hacer como modelo de negocio. Te doy mi ejemplo estándar, ¿verdad? Y estoy seguro de que muchos de tus clientes tienen ideas similares de pasar de un modelo de producto a un modelo de servicio. ¿Verdad? Esto tiene mucho que ver con ecosistemas, plataformas, etc. Algo muy común. Un ejemplo clásico es que en lugar de vender motores de tren, vendemos kilómetros de pasajeros. Siempre digo, por ejemplo, Hilty, ¿verdad? ¿Qué venden realmente? No venden taladros. Venden agujeros, ¿verdad? Eso es lo que el cliente trabaja. Y todos sabemos que esta estrategia de negocio es genial, ¿verdad? Porque para el cliente, nos pagas, como proveedor, obtienes más información, tienes más datos, tienes una relación más cercana. Así que muchas, muchas buenas razones por las que ese modelo de negocio es deseable. Ahora, la pregunta que siempre hago es, bueno, si ese modelo de negocio es tan fantástico, ¿por qué no lo hicimos hace 50 años o hace 30 años? Y la respuesta es muy simple. En gran medida, no teníamos las capacidades técnicas. ¿Verdad? Si quieres vender agujeros en lugar de taladros, necesitas IoT, necesitas mantenimiento predictivo, necesitas IA, necesitas la nube. ¿Verdad? Así que, básicamente, esos son todos los ingredientes que hacen que el modelo de negocio funcione. Ahora, no es que nunca hayamos pensado en este modelo de negocio, pero definitivamente es una calle de doble sentido. Las organizaciones que tienen éxito, tienen una buena idea de cuándo las capacidades técnicas alcanzan cierto punto donde puedo hacer algo diferente en el lado del negocio, y ese diálogo para mí es extremadamente valioso. Pero también hay un cierto conjunto de disfunciones allí, siempre las hay en las grandes organizaciones, y es cuando surge una nueva tecnología, el negocio dice: "Oh, debemos hacer algo con esta nueva tecnología". La IA generativa viene a la mente, ¿verdad? La nube solía ser, ¿verdad? La cuántica será la próxima, lo que sea. El móvil solía ser. Dicen: "Oh, necesitamos una aplicación móvil, necesitamos un asistente de IA". Eso no es lo que quiero decir, ¿verdad? Esto es solo, "Oh, hay alguna pieza de tecnología que debemos usar de alguna manera porque de lo contrario, sentimos que tenemos FOMO, ¿verdad?". Lo que quiero decir es, en realidad, comprender cómo esa tecnología habilita diferentes modelos de negocio específicamente para tu negocio y no solo marcar una casilla. "Oh, tenemos un chatbot o un agente, o estamos en la nube, o tenemos algún tipo de aplicación móvil". Y creo que las organizaciones que lo hacen bien son las que han hecho esa traducción en sus cabezas. Y las que lo hacen menos bien, gastan mucho dinero en faros y prototipos y hacen una aplicación móvil que hace exactamente lo mismo que el sitio web ya hacía, pero es móvil, ¿verdad? Así que tienen un chatbot que todavía no es bueno, ¿verdad? Terminan con todos estos costosos proyectos tecnológicos que no añaden mucho valor y luego hacen exactamente lo que dices. Dicen: "Oh, tal vez las cosas técnicas no son tan interesantes". Pero para mí, esa es la conclusión equivocada. Las cosas técnicas son menos interesantes porque no hiciste la traducción para ver lo que las cosas técnicas realmente pueden hacer por tu negocio. Uno de los puntos que dijiste antes de tu transición de una época en la que eras el negocio a ahora, digamos, la tecnología siendo el negocio, y en medio de eso también mencionaste cómo a la gente le gustan las restricciones o los límites y operar en estructuras que han sido establecidas para ellos, y de manera similar, digamos, el negocio también opera desde lugares de, digamos, restricciones. ¿Cómo diseñas tu arquitectura para permitir la transformación mientras trabajas en estos, digamos, espacios de restricciones y haces esto también mientras, de nuevo, creas opcionalidad como Simona también mencionó la posibilidad de un futuro donde haya múltiples productos, cosas así? Cuando tus sistemas o estructuras de poder, etc., son relativamente antiguos y luego, ¿sabes?, estás envolviendo estas nuevas tecnologías a su alrededor, pero eso obviamente no es la dirección más útil. Entonces, ¿cómo permites esa coherencia estratégica en todo esto? >> Sí, creo que hay muchos puntos ahí. Uno al que me aferraría es que soy un gran fan de la palabra opcionalidad. Ustedes quizás conozcan una de mis consignas sobre arquitectura: la arquitectura vende opciones, ¿verdad? La arquitectura te da opciones en la forma en que te permite posponer decisiones para el futuro, ¿verdad? Así que, por ejemplo, la gente dice: "Oh, nuestro sistema debe ser escalable, ¿verdad?". Bueno, esa es la opción de añadir capacidad de hardware o quitar capacidad de hardware. Fácil de hacer en la nube, ¿verdad? Tienes una arquitectura de escalado horizontal, balanceador de carga de aplicaciones, infraestructura elástica, como todos los ingredientes técnicos que conocemos muy bien. Pero la opción que realmente estás comprando es la opción de añadir o eliminar capacidad. Y las opciones son valiosas. Bueno, eso está matemáticamente probado. Sí, Black y Scholes obtuvieron un Premio Nobel de Economía por eso, ¿verdad? Así que las opciones tienen valor y es fácil de entender por qué, porque si puedes posponer una decisión, generalmente puedes tomar una mejor decisión. Quedémonos con el ejemplo del dimensionamiento porque es simple, ¿verdad? Cuando trabajé en Allianz, siempre digo que teníamos un equipo muy triste y el equipo triste era el equipo de dimensionamiento de hardware. Como si alguien tuviera una idea sobre alguna aplicación que iba a construir y luego alguien tiene que averiguar cuánta capacidad de hardware necesitas, y la razón por la que siempre digo que era un equipo triste es porque siempre puedes equivocarte, ¿verdad? O tienes demasiado o muy poco, porque nadie puede predecir el futuro, ¿verdad? En comparación, si pospones esa decisión, se vuelve trivial. Necesitas más rendimiento, añades capacidad. Sabes, tienes poco tráfico, reduces la capacidad. Así que para mí, las opciones son una forma muy agradable de expresar lo que hace la arquitectura. Ahora, irónicamente, ¿verdad?, las opciones posponen decisiones, ¿verdad? Mueven las decisiones al futuro, en comparación con muchos casos en los que la gente malinterpreta la arquitectura como que ellos son los que toman todas las decisiones. Así que creo que hay ambas partes. Sí, tomamos algunas decisiones, como usar una infraestructura elástica y un balanceador de carga y una arquitectura de escalado horizontal, lo que sea. Pero la razón para tomar la decisión técnica es para poder posponer la decisión de, por ejemplo, la planificación de capacidad y el dimensionamiento. Así que para mí, las opciones y la opcionalidad capturan muy bien lo que hace la arquitectura. APIs, puntos de extensión, ¿verdad? Simone mencionó la construcción de un tercero, la construcción de un ecosistema alrededor de tus activos de TI, ¿verdad? Eso tiene mucho que ver con la opcionalidad, ¿verdad? Si alguien quiere añadir un nuevo módulo, ¿verdad?, o un nuevo tipo de comportamiento o conectarse a lo que tienes, realmente pueden hacerlo. Las plataformas están muy relacionadas con esta idea, pero para mí, realmente estás comprando opciones. Y el último comentario sobre esto sería que elijo la palabra "comprando" conscientemente porque siempre digo que los arquitectos venden opciones, no las donan, no son gratis, ¿verdad? Y pagas, por ejemplo, con complejidad. Una arquitectura de escalado horizontal, una que tiene APIs y es extensible, es también invariablemente más compleja. Y eso puede estar bien para ti, porque si puedes construir un ecosistema gigante alrededor de tu negocio y florece, entonces estás muy feliz con eso. Pero a veces las cosas no valen la complejidad. Como algunas personas vienen a mí y dicen: "Oh, todo debe estar débilmente acoplado siempre". Yo digo: "Bueno, eso probablemente...". Debe ser multicloud, portátil, débilmente acoplado, lo que sea. Y yo digo: "Bueno, estas son cosas muy abstractas. ¿Mi cliente se beneficia de que sea multicloud, débilmente acoplado, algo?". ¿Cuál es el verdadero impulsor aquí? ¿O simplemente estoy aumentando la complejidad? Así que las opciones no son gratis, te cuestan esfuerzo y te cuestan complejidad. Y creo que encontrar ese equilibrio, ¿verdad? Las opciones que te gusta tener frente al costo de estas opciones, para mí eso es arquitectura. Y eso es también algo que no se puede hacer en el vacío. Esa es la ironía. La gente viene a mí y dice: "Oh, ¿es esta una buena arquitectura o hazme una buena arquitectura?". Yo digo: "¿Cómo lo sabría sin entender lo que el negocio quiere hacer? ¿Vamos a entrar en nuevos mercados? ¿Vamos a ampliar nuestra cartera de productos? ¿Vamos a hacer adquisiciones?". ¿Verdad? ¿Vamos a dirigirnos a diferentes segmentos de clientes? ¿Vamos a querer vender cruzado? ¿Verdad? Tendría un millón de preguntas para el negocio que realmente impactan mi arquitectura. Así que, realmente recuerdo a los arquitectos de TI que la mayoría de las decisiones que toman no se pueden tomar en TI en el vacío porque no conoces el impulsor. No sabes qué opciones valen la pena tener y cuáles no, y sabes exactamente lo que sucede si ese es el caso. Si la gente no sabe qué opciones son valiosas, bueno, como buen arquitecto, pongo todas las opciones. Lo hago débilmente acoplado, escalable, portátil, mantenible, pero entonces el problema es que el proyecto dura 24 meses y me cuesta 20 millones. Y luego el negocio se pregunta: "Bueno, ¿por qué todo es tan caro y lleva tanto tiempo?". Y mi respuesta corta es: "Bueno, porque ustedes no hablan entre sí". Volviendo a mi punto original, ¿verdad? Ustedes no hablan entre sí. Así que entonces hacemos que TI adivine y, como TI quiere hacer un buen trabajo, adivina por el lado de las inclusiones, lo metemos todo. Y luego tenemos estos objetos complejos de 20 millones de dólares y dos años que luego al negocio no le gustan. Así que la cura, si se quiere, en mi opinión, es valorar las opciones desde el lado del negocio. Entender que hay un costo asociado. Estar de acuerdo en que algunas opciones pueden no ser necesarias te ahorra dinero, te ahorra tiempo, pero tienes que tener esa calibración de ambos lados del negocio. De lo contrario, no puedes hacer arquitectura. Ese es un punto muy interesante. Creo que mi sentimiento al escucharte es que esta conversación sobre opciones, por ejemplo, opcionalidad, resuena mucho con la idea de crear un lenguaje. Los lenguajes son en gran medida formas para que mantengas la opcionalidad en una conversación y al mismo tiempo tengas algún tipo de compensación. Por ejemplo, un lenguaje es algo que quizás puedas escribir, puedas cambiar. Así que esencialmente, ¿sabes?, si veo la arquitectura como una forma de, digamos, reducir el número de decisiones que tomas para poder mantener más opciones abiertas en el futuro. Así que realmente tomas las decisiones importantes, digamos, ¿verdad? Pero para que las otras decisiones puedas tomarlas en el futuro. Es extremadamente interesante. Y mi sentimiento es que en las empresas, especialmente las grandes, pero más en general, diría yo, ¿verdad?, está esta conversación sobre tecnología, esta conversación sobre los clientes y el negocio, lo que los clientes quieren, los productos, las experiencias, la UX. Pero hay un lugar en el medio que está un poco tenso, en este tipo de organizaciones, que es lo que puedo llamar, digamos, la ontología. De acuerdo, digamos, ontología. Sé que es una palabra muy cargada y, de hecho, a veces este espacio es abordado o dirigido por la gente de datos, las ontologías de datos y demás. Pero para mí, especialmente a medida que avanzamos hacia organizaciones que tienen que hablar cada vez más con terceros, ¿verdad? Así que la responsabilidad de crear la ontología del negocio, lo que somos, lo que hacemos, para eso, los flujos de trabajo que habilitamos, que se traducen en la orquestación de servicios, por ejemplo, a menudo se deja allí como un huérfano en una organización y, al mismo tiempo, es lo más importante que tienes en la organización. Entonces, ¿cuál es tu sentimiento al respecto? >> Oh, estoy muy de acuerdo y soy un gran fan de DDD. Como el libro Domain-Driven Design de Eric Evans salió casi al mismo tiempo que Enterprise Integration Patterns, que Bobby y yo escribimos. Así que tenemos una larga amistad desde finales de 2003. Ambos libros tienen ahora 22 años. Así que de nuevo, hay muchos puntos ahí que veo. Así que siento que entender y poder articular tu dominio es críticamente importante tanto para el lado del negocio como para el lado técnico, ¿verdad? Como las cosas que mencionas, si quieres tener algún tipo de ecosistema, APIs abiertas, extensibilidad, porque las organizaciones modernas no viven en el vacío, ¿verdad? Tienen éxito porque se abren y permiten integraciones. Llegaría a decir que sin una buena comprensión de tu dominio, tendrás muchas dificultades. Hay un par de cosas que juegan en tu contra. Y esta es otra razón por la que este es un tema que nos acompaña desde hace dos décadas. Y conocemos el problema, pero la solución parece ser algo esquiva. Hay un par de cosas que juegan en tu contra. Y es, la que mencionaste, que a menudo la ontología y el dominio residen con el equipo de datos, y eso es noble, pero también da la noción de que esto es una especie de cosa tecnológica de TI, ¿verdad? Quieren mantener el modelo de datos empresarial, y encuentro que eso nos hace la vida aún más difícil porque el modelado de dominios es una tarea blanda. Es como una tarea del cerebro derecho. Se trata de la nomenclatura correcta. ¿Diseco dos conceptos? ¿Verdad? Cuando trabajé con Eric Evans, siempre se trataba de los matices, ¿verdad? De encontrar cosas. Así que esa es una tarea muy del cerebro derecho, mientras que el modelo de datos empresarial es muy del cerebro izquierdo. Dicen: "Oh, ¿necesito un índice? ¿Cuál es el tipo de datos para este tipo de cosa?". Así que dejarlo solo con el equipo de datos, creo que es una de las razones por las que luchamos, y las carreteras empresariales están llenas de cadáveres de modelos de datos empresariales. >> Sí. También porque no tienen derecho a pensar en la ontología, ¿verdad? >> Tienen el modelo de datos. Así que necesitan el resultado, pero tienes razón, es posible que no tengan derecho a hacer la entrada, ¿verdad? Porque básicamente, ¿cuál es el modelo lógico que tienes? Así que creo que esta es definitivamente una parte por la que luchamos. La otra parte es que los ingenieros, o ni siquiera diría solo ingenieros, las organizaciones que tienen una cierta implementación de algo tienen mucha dificultad para abstraer eso. Básicamente, si miras de adentro hacia afuera, siempre piensas en las piezas que estás haciendo y que estás construyendo. Y te doy un par de ejemplos. Es gracioso. De hecho, hicimos una webcast con la industria automotriz esta mañana. Y mi vieja broma es que si los ingenieros hubieran nombrado el automóvil, se llamaría conjunto de pistón, cigüeñal, engranaje, rueda, ¿verdad? Porque así es como vemos esta cosa. Y estamos tan orgullosos de los pistones, los cigüeñales, los engranajes y las ruedas, ¿verdad? Que debemos tener un nombre que contenga todas estas cosas. Y mira a los proveedores de la nube, ¿verdad? Tus proveedores de la nube hablan mucho de primitivas y abstracciones, pero al final, ¿en qué piensan? Son todos los nombres de sus servicios, ¿verdad? Y luego te certifican en el conocimiento de todos los iconos y todos los nombres de sus servicios, lo cual no es diferente. Ve a cualquier gran hiperescalador y mira la arquitectura del sistema. ¿Qué ves? Bueno, pistón, cigüeñal, engranaje, rueda, como si tuvieran iconos para cada cosa. Es como SQS de Amazon, Event Bridge, Event Arc, lo que sea, GCP Pub/Sub, del color que quieras, ¿verdad? Y así, mirando de adentro hacia afuera, es increíblemente difícil encontrar las abstracciones de afuera hacia adentro. Y creo que ese es el segundo elemento que nos perjudica en hacer mejor las cosas al articular realmente el lenguaje que necesitamos para construir este tipo de capas que imaginas. En muchos casos, lleva décadas. Como dije, acabamos de salir de la industria automotriz, ¿verdad? Todo el mundo sabe cómo se llaman las piezas de un coche. Tuvimos 100 años para hacerlo. Pero aún así, cuando se trata de definir APIs y ecosistemas, ¿verdad?, todavía luchamos por tener el lenguaje común, el lenguaje común, porque siempre miramos de adentro hacia afuera. ¿Cómo cambias esa conversación de transaccional, a veces incluso engañosa, a evocar una conversación más rica que apoye quizás un pensamiento arquitectónico real, pensando en ello desde una lente de coordinación en lugar de puramente, digamos, una disciplina técnica? Entonces, ¿cómo ocurre esa transición? >> De nuevo, hay un par de puntos ahí. Así que, para hacer el puente entre, digamos, el lado de la arquitectura y el lado del negocio, y mantengo mi punto, no puedes tomar decisiones de arquitectura sin tener aportes del negocio porque no sabes cuáles son las compensaciones. Diría que el túnel debe ser excavado desde ambos lados. Soy un gran creyente. Así que, desde una perspectiva técnica, me sorprende lo difícil que es para muchas personas técnicas articular realmente las compensaciones y las decisiones que están tomando. Y hago esto mucho porque escribo el Architect Elevator, bajando a la sala de máquinas. Así que la gente viene a mí y dice: "Necesito un sistema de caché de dos etapas con un algoritmo de actualización en caché, ¿verdad? Blah, blah, blah, blah, blah, blah, blah, ¿verdad?". Y yo digo: "¿Qué te hace tomar esta decisión?". "Oh, necesitamos baja latencia. Necesitamos acoplamiento débil". Así que estas palabras de moda vienen y tienen muchas dificultades para mirar detrás de estas palabras de moda y articular realmente lo que hacen y por qué. Y si me preguntas, me desconcierta un poco por qué es tan difícil para ellos. Pero creo que una de las razones es que a menudo, de los proveedores, esto viene un poco como: "Oye, nuestro producto está débilmente acoplado, nativo de la nube, portátil, escalable", y luego los desarrolladores repiten lo que escuchan. Lo otro es que creo que los tecnólogos de alguna manera se definen a sí mismos por estar asociados a una tecnología determinada. Sabes, soy un tipo de J2EE o un tipo de Spring o un tipo de... ¿sabes?, lo que sea, algo de GenAI, ¿verdad? Y creo que eso es muy extraño para mí. Básicamente, han cedido su identidad a un producto determinado que ven. Así que ese es un lado de la casa que definitivamente tiene margen de mejora. El otro es que el negocio necesita entender y apreciar las compensaciones. Y vuelvo a mi ejemplo. Los ejecutivos vienen y dicen: "Oh, todo lo que ustedes tienen que hacer es implementar mi grandiosa visión". Yo digo: "Bueno, una visión que carece de comprensión, complejidad y esfuerzo no es muy útil". Cualquiera puede soñar. Es como, "Oh, ¿sabes?, el paraíso se ve así, ¿verdad? Todo es posible. Todo es barato, fácil y rápido y lo que sea". No se necesita ninguna habilidad para enumerar todos tus atributos deseables. La habilidad es entender las compensaciones, ¿verdad? Y aprovechar las capacidades que tienes. Así que tiendo a rechazar bastante duramente a estas personas de negocios que dicen: "No me importa la tecnología". Yo digo: "Deberías hacerlo, ¿verdad?". Y el ejemplo que a menudo doy: ¿Crees que los pilotos se preocupan por la tecnología del avión? Y el... Oh, sí, les importa mucho porque suben a esa cosa y si algo sale mal y no tienen idea de cómo funciona este avión, ¿verdad?, eso terminará muy mal. Ahora, afortunadamente, no nos estrellamos tan fuerte en los negocios, pero aún así, si algo sale mal en tu tecnología y no tienes idea de qué tecnología estás usando, tu negocio también puede tener un aterrizaje un poco accidentado. Así que tiendo a insistir mucho en que tu vida empresarial depende de ello. Deberías querer entender algo de ella. Doy un ejemplo positivo donde trabajé con un director de operaciones de servicios financieros y hablamos de hacer una aplicación móvil, nuestra cosa clásica. Al final, terminamos hablando de descarga de carga y cómo construir sistemas escalables con un miembro de la junta, ¿verdad? Director de operaciones, miembro de la junta. Hablamos de cómo diseñar sistemas distribuidos y escalables. Y la parte interesante fue que él disfrutó mucho de esa discusión. Pero, ¿por qué haría eso? ¿Por qué hablaría con un COO sobre descarga de carga, algo muy técnico? La respuesta es bastante simple y es que quiero tener la aceptación de las compensaciones. Hacer un producto exitoso no se trata de hacer una lista de deseos más larga. Como digo, los deseos son baratos. Cualquiera puede hacer cualquier deseo que quiera. Se trata de entender las compensaciones y obtener la aceptación de las compensaciones. Así que el mensaje que quería transmitir es que cualquier sistema escalable debe rechazar trabajo. Si hay una cierta capacidad que puedes manejar cuando la carga excede esa capacidad, lo mejor que puedes hacer es rechazar el trabajo extra porque de esa manera puedes servir la capacidad que tienes. Todavía puedes, digamos, manejar mil transacciones por segundo. Si obtienes dos mil, lo mejor que puedes hacer es rechazar mil y servir mil. Si no lo haces, tu sistema se caerá y servirás cero. ¿Verdad? Así que quería dejar claro a nuestros patrocinadores que hay compensaciones que estamos haciendo en el diseño. Y para mí, eso es lo que parece una verdadera aceptación. Básicamente, el antipatrón que veo es que el negocio solo quiere desearlo todo y luego, de alguna manera, retrata una arquitectura que se supone que concede todos los deseos. Oh, es escalable, es increíble, es portátil, es flexible, y ambos lados pretenden que no están haciendo ninguna compensación, que esto es solo un concurso de deseos. Y eso, en mi opinión, es muy disfuncional. Todas las decisiones de arquitectura implican hacer una compensación. Obtienes esto, no obtienes aquello. Quieres que esté débilmente acoplado, tienes más sobrecarga en tiempo de ejecución, más sobrecarga en tiempo de diseño. Quieres que sea extensible, pasarás más tiempo diseñando tus APIs. Quieres que sea escalable, tienes una arquitectura de tiempo de ejecución más compleja. Quieres microservicios, necesitas más observabilidad, ¿verdad? Todo lo que quieres, tienes algo más. Y encontrar el mejor equilibrio para el negocio. Ese es el objetivo. Pero si es solo un concurso de deseos en ambos lados, nunca lo lograrás realmente. Así que eso es lo que hago con los ejecutivos. No les muestro una larga lista de hermosas características, sino que les muestro las compensaciones, las decisiones que estamos tomando, y luego discuto, ¿verdad? Y o bien obtengo la aceptación de mi decisión o cambio mi decisión. Si el negocio dice "no, no, no, esa compensación va en la dirección equivocada", entonces digo "genial, hablemos" y llegamos a algo más. Pero de esa manera, ambos entendemos lo que obtenemos y lo que no obtenemos. Siempre hay algo que no obtienes. Una vez fui invitado por Charles Simonyi, un tipo muy agradable, también un tipo razonablemente rico. Nos invitó a su barco. Un barco muy bonito, ¿verdad? Muy grande. Creo que 70 metros en ese momento. Así que, la única pregunta que le hice a Charles fue: "¿Qué querías que no obtuviste?". ¿Verdad? Porque la cosa costó, no sé, 100 millones o algo así, ¿verdad? Bien por él, ¿verdad? Es un barco bonito. Desearía tener uno, ¿verdad? Dije: "¿Qué no obtuviste?". Y ni siquiera dudó un segundo. Supo inmediatamente lo que no obtuvo. No obtuvo la chimenea y no obtuvo la cerveza de barril. Y yo digo: "Vaya, eso es interesante". Y ambos, todos nosotros dijimos: "Vamos, gastaste como 100 millones. ¿Qué tan difícil sería poner una chimenea y cerveza de barril? Puedes tener, vamos". Lo acabas de añadir un poco. Y él dijo: "No, no, no, no, no. Tu chimenea es pesada. Es grande. Es voluminosa. Necesita combustible. Necesita una chimenea, ¿verdad? Y en algún momento, es como, ah, entonces voy a estropear algo más, pero la chimenea tiene que ir aquí. El jacuzzi no puede ir allí, o la ventana no puede ir aquí, ¿verdad? Y en algún momento, simplemente dices, vale, simplemente, como si rayáramos la chimenea, a pesar de que queríamos tener una chimenea, porque queríamos tenerlo todo. Así que la lección aprendida es que incluso si diseñas algo desde cero, todos estos yates de lujo están diseñados desde cero. Puedes construir lo que quieras, pero no obtendrás todo lo que quieres. ¿Verdad? Puede tener cualquier tipo de forma, cualquier tipo de compensaciones que quieras hacer, pero aún así estás haciendo las compensaciones y todavía habrá algo que no obtendrás. Y Charles es un gran arquitecto. Así que lo tenía muy presente. Sabía inmediatamente que eran dos cosas que quería tener. Y finalmente, renunció a ellas porque no valía la pena la compensación. No valía la pena renunciar a algo más. Y luego, si haces el barco más grande, tarda más. Se vuelve más pesado. Usa más combustible, ¿verdad? Entonces necesitas más tanque de combustible, motores más grandes. Ah, todo eso no funciona, ¿verdad? Así que, en última instancia, te conformas con lo que tienes. Y creo que esa actitud entre negocios y TI resolvería la gran mayoría de los problemas que enfrentamos. Como, ¿qué estás dispuesto a ceder? ¿Puedes aceptar que no obtendrás algunas cosas y no es porque sea perezoso o incompetente, sino que es así como es? Los constructores de barcos eran increíbles y aún así no obtuvo una chimenea y no culpa a los constructores de barcos. Decidió finalmente, está bien, la chimenea se va. Pero en cambio, tengo un helipuerto y un jacuzzi y una sala de estar más grande, y estoy totalmente feliz con eso y todo está bien. >> Creo que me gusta mucho que esto desmitifica las arquitecturas ideales, digamos, y las pone en un contexto consciente. Así que eso solo quería señalarlo. Y lo segundo fue que estaba pensando en ello desde, digamos, un contexto indio de tecnología y negocios tan aislados entre sí, incluso cuando pensamos en organizaciones, ¿verdad? Así que cuando un tipo de tecnología entra, tienen reglas separadas, tienen una cultura de trabajo diferente, sus capacitaciones son diferentes, por ejemplo. Y la primera vez que se integran con el negocio es cuando tienen que ser promovidos a un puesto gerencial, esa es la primera interacción de conciencia empresarial central que han tenido, que es alguna capacitación de habilidades que está ocurriendo desde una escuela de MBA externa. Así que, ya sabes, esa es la primera capa de interacción que han tenido con un negocio. Así que solo me preguntaba si esto es, digamos, una brecha entre quizás la habilidad y el hecho de que el proceso de aprendizaje no es quizás horizontal, sino más paso a paso y lineal. Así que tenía curiosidad sobre eso. >> Para mí, nunca tuve esa experiencia de aprendizaje porque en la escuela, cuando fui a Stanford, estudié gestión de ingeniería y ciencias de la computación, obtuve dos maestrías, así que siempre he vivido en ambos lados y para mí ha sido muy natural. Diría que sí, así que veamos a la gente clásica de Silicon Valley en una startup, no tienes más remedio que estar orientado al negocio, porque si no, no estarás presente en unos 6 o 9 meses. Así que veo a los ingenieros allí, pongámoslo de esta manera, una vez que tienen interés en el negocio, no veo ningún obstáculo para que entiendan el negocio. Así que, si acaso, es más una falta de curiosidad que una falta de habilidad. Creo que a algunas personas simplemente no les importa y piensan que su vida es más fácil, digamos, caminar por el tapiz nativo de la nube y escupir los nombres de los últimos proyectos de código abierto que nadie más puede entender, y eso los hace sentir inteligentes, en lugar de realmente entender el negocio. Pero no veo que sea un problema de capacidad para mí. Es un problema de actitud. Creo que lo que me ha impulsado es que generalmente encuentro fascinante cada dominio de negocio en el que trabajo. Trabajo con algunos minoristas. Oh, y es súper genial, ¿verdad? Porque, ¿sabes?, la logística, su cadena de suministro, algunos de ellos son cooperativas. Así que las tiendas son propiedad de la gente, pero siguen siendo parte de esta cooperativa. Súper interesante seguro, ¿verdad? Se podría decir fácilmente que a mucha gente le parece un poco aburrido el seguro. Permítanme aclarar eso. Ningún negocio es realmente aburrido, ¡incluido el seguro! ¿Verdad? Así que creo que lo que me mantiene en marcha es que encuentro el negocio fascinante. ¿Verdad? Acabo de hablar con gente del sector automotriz esta mañana. Vehículos definidos por software fascinantes y nube y autónomos y de izquierda, derecha y centro. Así que creo que si la gente tiene la actitud de que es realmente interesante, no creo que tengan un problema tan grande para entenderlo. Solo necesitan querer hacerlo. Sí. >> Creo que ese es el problema. >> Sí, creo que la evolución tecnológica los está empujando a hacerlo y, por lo tanto, no tendrán mucha opción. Supongo que esa es mi impresión. En este espacio, hemos estado hablando de la comprensión del dominio y el modelado del dominio como una pieza varada del desarrollo organizacional que a veces se pierde entre TI o tecnología y negocios, y que los equipos de datos a menudo lo miran desde un lado demasiado tecnológico. Suena mucho a lo que en el desarrollo de IA estamos empezando a llamar ingeniería de contexto. Así que la idea de que tenemos que entender el contexto, ¿verdad? Y lo que descubrimos es que la IA generativa necesita contexto, ¿verdad? Así que para mí, suena a que no es que la IA generativa necesite contexto, es que todo el mundo necesita contexto y el contexto es muy importante para compartir decisiones y compensaciones, como dijiste. Pero lo fascinante es que la aparición de estos sistemas de IA, sistemas agenticos o incluso sistemas de desarrollo que pueden aprovechar el contexto de texto nos está mostrando que hay muchos sesgos y orgullo y coartadas y profundidades que intentamos proteger en la organización y luego, de repente, hay esta tecnología que necesita una comprensión clara de las compensaciones para ayudarnos a tomar decisiones y nos está empujando a hacer que nuestras organizaciones sean mucho más reales. ¿Cuál es tu impresión en el trabajo que haces con las empresas a medida que surgen estas tecnologías? ¿Es algo que resuena contigo? >> Oh, sí, en gran medida. Y veo como dos partes. El primer aviso que daría es si vives en un silo, ¿verdad? Dices: "Oh, solo haré lo mío y me importa menos lo demás". Te conviertes en un gran objetivo para el reemplazo por IA, porque funciona extremadamente bien en silos. Si todo lo que haces es, "dame los requisitos y yo los codifico". Bueno, los LLM son bastante buenos en eso. Si todo lo que haces es diseñar hermosas interfaces de usuario sin preocuparte por el dominio de negocio, la IA generativa es bastante buena en eso, ¿verdad? Así que esa es mi advertencia. Si vives en una pequeña caja en tu organización, piénsalo de nuevo, porque eres el principal objetivo de reemplazo, ¿verdad? Donde la IA no es tan buena es en la estrategia, la colaboración, la interconexión entre los diferentes dominios, la conexión de puntos, la toma de apuestas, la colocación de apuestas para tu negocio, ¿verdad? Ahí es donde no es ni de lejos tan buena. Así que las personas que cruzan, creo que tendrán mucha más demanda, ¿verdad? Es como todo lo demás en el pasado, la IA generativa eleva el listón, ¿verdad? Y el listón generalmente sube al comprender el dominio, trabajar a través de los diferentes silos, ¿verdad? Ahí es donde creo que no necesitas preocuparte por ello, será un impulso para ti. Si vives felizmente en tu pequeña caja, podría ser realmente el reemplazo. Así que ese es el gran pensamiento número uno. El gran pensamiento número dos es que es gracioso cómo las organizaciones siempre creen que la tecnología resolverá todos sus problemas, ¿verdad? Y bueno, puedes entender por qué, de lo contrario es un poco deprimente. Pero aquí está la realidad: mucha nueva tecnología no resuelve tus problemas. En realidad, resalta tus problemas más. Amplifica los problemas que ya tienes. Empecemos con algo simple, la nube. Si tienes esta gran separación entre desarrollo y operaciones, porque los silos no solo existen entre negocios y TI, los silos también existen dentro de TI, ¿verdad? Simplemente continúa, ¿verdad? Y luego vas a la nube. Las empresas han tardado una década y todavía están lidiando con resolver esa pesadilla, ¿verdad? ¿Cómo consigo el ritmo de lanzamiento, la agilidad, todas las cosas que el proveedor de la nube me prometió que realmente no sucedieron debido a nuestras propias disfunciones organizacionales? Y creo que lo mismo ocurre con la IA generativa. Te doy un par de ejemplos. Supongamos, a efectos de argumentación, que la IA generativa hará que tus desarrolladores sean cinco veces más productivos. Mi predicción es que todo en tu organización se desmoronará, ¿verdad? Porque la fricción que tienes, los procesos de toma de decisiones, los procesos de lanzamiento, básicamente nada en tu organización está diseñado para lidiar con una organización cinco veces más productiva, ¿verdad? O el otro ejemplo es lo que Simona alude, ¿verdad? Es, sabes, si la IA generativa puede construir software con solo pulsar un botón, digamos, solo das tus ideas y el software sale, a efectos de argumentación, bueno, necesitas tener ideas bastante buenas, ¿verdad? Porque todo lo demás ahora se ha vuelto una mercancía, así que necesitas entender tu dominio, el ecosistema, el lenguaje, todas las cosas a las que se refirió, ¿verdad? Ese es ahora el verdadero diferenciador. Y en muchas organizaciones, esa habilidad es débil. Y la interfaz de negocio es que el negocio vierte dinero y deseos y, de alguna manera, escupe algo que puede o no >> ¿Sabes qué es gracioso? ¿Sabes qué es gracioso? Perdón por interrumpirte, pero creo que fue divertido, es divertido intervenir porque en Boundaries hemos estado pensando en algo de software que queríamos desarrollar y durante algunos meses hemos estado un poco frustrados por la necesidad de recaudar capital y demás, pero de repente hay estas herramientas que pueden ayudarnos a prototipar y ahora estoy aún más frustrado porque no tengo suficiente tiempo para trabajar en el modelado del dominio y así el agente de respuesta está ahí esperando por mí desde hace unas semanas y estoy tan frustrado. ¿Verdad? Así que, si acaso, la frustración ha crecido con estas nuevas.
tecnologías. >> Sí. Y luego multiplica esto por unas 1.000 y entonces ves cómo esto se desarrolla en una organización grande. De hecho, me encanta tu historia porque nos dice que podemos ver los efectos en lo pequeño y luego, ya sabes, para las organizaciones podemos extrapolar, pero ese es el gran desafío que predigo que será. Ya no puedes esconderte detrás de los largos ciclos de entrega y todas las especificaciones que necesitas escribir. Ahora necesitas ir a entender tu dominio, buscar oportunidades de negocio, construir ecosistemas, ¿verdad? Y eso es trabajo duro. Puedo relacionarme totalmente con lo que dice Simony, ¿verdad? Conseguir el ancho de banda o el tiempo de concentración para hacer un pensamiento crítico real para alimentar a tu agente de IA es, de hecho, más difícil que sentarse y simplemente escribir unas pocas líneas de código o generar algún documento de diseño aleatorio. La vara en realidad sube y si no eres bueno en esto, ah, no serás feliz con Genai. Así que amplifica las disfunciones que ya tienes en lugar de hacerlas desaparecer. Y diría que esa es la principal advertencia que tengo para las organizaciones. >> Muy curioso cómo todo esto se desarrolla. Fue muy agradable, Gregor, tenerte. Y antes de terminar, siempre nos encanta dejar a nuestros oyentes con algunas migas de pan. Así que si tienes, digamos, algún libro, podcast o pensador que te haya influenciado o que haya moldeado tus perspectivas últimamente, sería bueno, ya sabes, entrar en eso. >> Quizás empiece con un comentario meta. Una cosa que aprendí cuando asisto a eventos, lo cual espero que muchos oyentes hagan. Recomiendo encarecidamente a las personas que asistan a charlas de personas con cuyo punto de vista no están de acuerdo. ¿Verdad? Escucha a personas que tienen un punto de vista diferente porque una de las mayores trampas en las que veo que cae la gente, y las redes sociales no ayudan con eso, es que la gente busca cosas que de alguna manera reafirman lo que ya creen. Mira, yo tenía razón, este tipo Gregor dice lo mismo, las plataformas son importantes en la nube, ¿verdad? La gente busca la reconfirmación. En cambio, deberías buscar un punto de vista diferente, ¿verdad? Recuerdo bien, fui a un evento y alguien, yo trabajaba en AWS y en el departamento de serverless, y un caballero muy inteligente dio una charla que básicamente decía que serverless está obsoleto, se basa en suposiciones de hace 10 años y básicamente es una mala idea. Yo digo, esa es la charla a la que quiero ir, ¿verdad? Porque quiero escuchar lo que este tipo tiene que decir, ¿verdad? Y fue muy, muy perspicaz, así que ese sería mi consejo meta. En cuanto a recursos concretos, creo que si alguien se ha dado cuenta es que el pensamiento sistémico ya no es un nicho, sino un requisito previo, créanme. Así que cualquier cosa que puedan leer sobre si es la quinta disciplina o el pensamiento en sistemas, muchos, muchos trabajos relacionados, ¿verdad? Creo que eso es lectura obligatoria ahora, ¿verdad? Está el modelado de dominio y estoy seguro de que cada audiencia o cada oyente ya ha comprendido el modelado de dominio y el diseño impulsado por el dominio, pero también está el pensamiento sistémico, el pensamiento de sistemas, así que animaría encarecidamente a la gente a, como dije, no considerarlo ya un nicho, sino lectura obligatoria. Y luego, quizás permitiéndome ser un poquito sesgado, pero encaja bien dentro de nuestro podcast también. Creo que las plataformas ya no son algo que solo hacen los grandes hiperscaladores, ¿verdad? Es algo que, sin importar en qué negocio estés, serás una plataforma para algo más. Por eso escribí "Estrategia de Plataformas". Honestamente, no fue un libro fácil de escribir porque tiene tantos matices entre mercados, plataformas de desarrolladores y plataformas en la nube, ¿verdad? Todas estas cosas, pero también animaría a la gente. Es difícil tener una estrategia de TI hoy en día que no tenga, o incluso una estrategia de negocio/TI, pongámoslo de esta manera, sin una idea de plataforma. Así que estos serían quizás tres vectores para nuestra audiencia que deberían ser útiles. >> Y por supuesto, si quieres añadir un par de cosas sobre dónde la audiencia puede seguir tu trabajo. La mayor parte de mi trabajo está en architectelevator.com, ¿verdad? El architect elevator trata de ver a los arquitectos como un elemento conector entre los diferentes pisos, siempre digo, desde el ático hasta la sala de máquinas y de regreso, porque esa es gran parte de la desconexión de la que acabamos de hablar, ¿verdad? Si el negocio tiene alguna visión en abstracto y la gente técnica juega con cosas tecnológicas aleatorias que son divertidas, pero no es una buena forma de organizar tu negocio, así que tu architectelevator.com. Ahí es donde están todos mis blogs, mis libros. Y lo único que los lectores deben tener en cuenta es que yo mismo escribo el elevator. Así que podrías leer una publicación de blog sobre arquitecturas de mensajería asíncrona serverless y luego leer otra publicación de blog sobre estrategia de plataformas, pero mi opinión sería que eso es bueno para ti porque, una vez más, deberías leer cosas que no solo reafirmen lo que ya sabes, sino que también te lleven a dominios ligeramente diferentes. >> Debes cavar el túnel hacia la verdad desde ambos lados, ¿verdad? >> Sí. Exactamente. Bien dicho. >> Bien. Bien. Quiero decir, fue una conversación increíble. Espero que también la hayas disfrutado. >> Sí. No, una conversación muy agradable y preguntas muy perspicaces. Solo bromeaba a medias cuando dije que la primera pregunta podría llevarnos fácilmente una hora en responder y creo que lo mismo es cierto para todos los demás temas. >> Pero hasta cierto punto hemos estado lidiando con esto en la conversación durante todo el podcast, ¿verdad? Así que creo que eso fue efectivo lo que sucedió. Nos tomó 1 hora solo para darle vueltas. Así que muchas gracias de nuevo. Fue un placer tenerte. Creo que fue una conversación muy esperada para tu trabajo en plataformas. Es tan relevante que es extraño que la tengamos en la séptima edición de la serie de podcasts 7. Pero para nuestros oyentes, por supuesto, pueden ir a nuestro sitio web. Van a boundress.io/resour/mpodcast. Si están escuchando este podcast ahora, encontrarán la transcripción de Gregor con todos los enlaces, los libros, las cosas que mencionó en la conversación. Y muchas gracias, Shy, por unirte a nosotros. >> Gracias. Gracias, Gger. Gracias >> a nuestros oyentes. Hasta que volvamos a hablar, recuerden pensar sin límites. [música]