 Bueno, pasaríamos con nuestro siguiente presentador, verdad que nos va a hablar de un importantísimo tema. ¿Qué tan ágil puede ser una arquitectura de tecnología de información? Para ello tenemos al señor Carlos Bittrich, nos acompaña desde Perú. Él trabaja en fabric communication como consultor, verdad, él es un experto en tecnologías emergentes y de innovación con una trayectoria de más de 34 años en roles técnicos y en nivel regional. También él estuvo con IBM, nos colaboró por cierto con nuestro evento regional en Perú hace un par de años, verdad, y pues ha participado en muchas iniciativas de integración de diferentes actores, soluciones innovadoras, comunidades globales, verdad, y ha sido pues actualmente, como lo mencioné, trabaja como asesora en tecnología de fabric Perú y también como consultor independiente. Muchísimas gracias Carlos por acompañarnos el día de hoy y puedes iniciar tu presentación. Gracias Sonia y buenos días para los que están con el mismo horario que yo y buenas tardes para el resto. Ahora vamos a escoger la presentación. ¿Cuál era? Esta de acá debe ser, vamos a la página, retrocedemos, avanzamos, ¿cómo es esto? Ok, bueno ya me presentó Sonia, yo quiero hablar un poco del tema de ágil amarrado al rol del arquitecto. No sé si les habrá pasado a ustedes, pero cuando apareció el mundo de innovación, agilidad, etcétera y los programadores, muchos me decían hoy, para que necesitamos un arquitecto ahora, ¿no? Todo has configurado tu asesora en drop y realmente el rol del arquitecto un poco que había perdido importancia. Entonces un poco quiero que la tengamos ese tema, ¿no? O sea, cómo afecta ágil porque también hay que diferenciar, ¿no? O sea, y hay muchos que hablan a respecto, ¿no? O sea, todavía ahora en época de pandemia, que todos hablamos de la pandemia, estaban buscando en Estados Unidos programadores de COBOL, ¿no? COBOL lo aprendí yo en la universidad hace 40 años y ¿cómo es posible que todavía algo de hace 40 años siga funcionando ahora? ¿no? Sin embargo, este, ya va y ya pasó de modo, ¿no? Entonces, este, lo, lo, muchas veces, a pesar de que hablamos de ágil, lo tradicional y lo robusto sigue vigente, ¿no? Entonces, ¿qué diferencia hay entre ágil, algo robusto, etcétera? Eso es cosas que donde los arquitectos tenemos que estar muy conscientes de que, este, tenemos que apuntar a empujarlo a ágil, pero hay cosas que no se pueden tomar a la ligera, ¿ok? A ver cómo avanzamos aquí. Entonces, esto apunta al tema de diferencia entre diferentes enfoques de desarrollo de las cosas, hasta ahora conocíamos el enfoque tradicional donde te piden algo, lo diseñas, de ahí viene todo el ciclo de desarrollo, pruebas, etcétera y se pasa en producción. Entonces, también tenemos esos triángulos que le llaman el triángulo dorado de la gestión de proyectos, ¿no? Generalmente, te decían, tienes que hacer tal cosa y hay tal presupuesto. Era fijo lo que querías, realmente, no, realmente, te decían que había tal presupuesto, pero lo único que decían yo, yo quiero que salir en producción dentro de un año con la nueva versión del home banking, ¿ok? Entonces, lo único que era fijo para el cliente o para el stakeholder, el usuario final, era lo que quería, ¿ok? Entonces, tú ponías gente, tú armabas infraestructuras, tenías un cronograma bien establecido, pero ¿qué sucede? Como no lograbas hacer lo que el cliente quería o no lograbas el, este, o el usuario final cambiaba de idea porque devoraba mucho tiempo entre que se pensó que seguiría a hacer algo y se terminaba, crecían los presupuestos, tenías que poner más gente, etcétera. Entonces, en los proyectos tradicionales el problema es ese, ¿no? En que tú no sabes cuánto te va a costar el proyecto ni cuánto va a durar. Entonces, hay todos esos estudios que dicen que por qué fallan los proyectos y que fallan porque los requerimientos no estaban bien definidos, pero no es necesariamente que los requerimientos no están bien definidos, sino que los requerimientos van cambiando con el tiempo. O sea, todos los proyectos que comenzamos en enero seguramente hoy día están muertos porque no es la pandemia y no solamente es la pandemia, es el crack financiero, es la inundación, uno de nuestros países que son tan frágiles con el cambio climático, etcétera. Y por otro lado tenemos el enfoque ágil, ¿no? ¿Qué decimos en el enfoque ágil? Todo es iterativo, realmente tú decides que se quiere hacer algo, pero todavía no sabes cómo se va a hacer. Yo quiero salir al mercado con e-commerce porque me han cerrado la tienda. ¿Cómo será? No sé ahora, pero hay que hacer. Entonces, esas son las estapas de movilización y entender qué hay que hacer y de ahí comenzamos a explorar posibilidades. O me pongo un SaaS o contrato a dos programadores o lo hago con el equipo que tengo que ahorita ya hizo una prueba de hacer la página sin ende para hacer toma de pedidos sencillos sin hacer integración contra el vaquete, etcétera. Pero la etapa de construcción y la etapa de salida de producción cosas es iterativa, ¿no es cierto? Si revisamos el triángulo de estos, está completamente invertido. Tú dices que yo tengo dos personas y tengo que salir el primero de abril porque me han cerrado las tiendas. No puedo salir el 2 de abril ni el 10 de abril, yo tengo que salir tal día. O sea, no me podrá el lujo de arrancar un proyecto de dos años. Por supuesto, eso no puedo hacer con proyectos muy grandes y muy complejos. No lo tengo que hacer con proyectos chicos. Ok, yo ya tengo todo mi sistema de gestión de órdenes y yo tengo todo mi inventario de productos y si el vende pongámole ya no lo atienda la gente que está en el almacén sino desde su casa. Débame una página web a eso de ahí. Entonces, tú lo como decíamos, lo fijo es tengo tantos recursos, sea gente y dinero y tengo paltar y de ahí. Y lo único que ponemos variable es el alcance. Lo que trabajo yo es el proyecto y es el enfoque estilo MVP. En el MVP no tienes que tener algo perfecto, tienes que tener algo que funcione y de ahí lo sacas de producción. Ok, entonces, si funciona a medias, ¿qué importa? O sea, el alcance es variable. Ok, ahora, no todos los proyectos se pueden tratar de la nueva manera. Si bien nos han vendido de que todo ahora es ágil y todo para ser moderno tienes que ser ágil, no todos los proyectos tienen que manejar así. Es algo que podemos ver en el siguiente chat, ¿no? Y esto queda, tal vez, de ejercicio entre todos y tenemos diferentes escenarios. Por ejemplo, a la izquierda tenemos las estaciones de servicio, los grifos, no sé cómo los demás cada uno en su país, pero ¿cuál es el problema en las estaciones de servicio? Que tú estás y que nos pasa en esta época, ¿no? Estamos protegidos con las ventanas cerradas en nuestro carro y tenemos que abrir la ventana para pagarle al grifero, porque creo que en los países todos hacemos nosotros la compra de grasolina, ¿no? No es como Estados Unidos de que tú bajas y tú te surtes la gasolina y tú pagas con tu tarjeta de crédito en el solidor sin personas al costado. En nuestros países interactuamos contra el grifero. Ok, los griferos tienen la fama de estar este todo el día agarrando o gasolina, aceite, dinero, tarjetas de crédito, etcétera. Entonces, yo tenía un proyecto en que la estación de servicio, lo que decía quiero hacer, pago contactles en mis estaciones de servicio. Yo ya tengo un sistema de gestión de los surtidores, yo ya sé cuán, yo ya tengo una PC al costado del surtidor que cuando cuelgan la manguera, la PC se actualiza solita, eso se interiera contra mi vaquen, etcétera, todo funciona. Ok, y simplemente quiero experimentar de el pago con un app. Entonces, ese proyecto lo atacamos de forma áskel o lo atacamos de forma tradicional. Es primero, decimos, ok, todo el sistema de billing y aquí esté, no sé, todo el sistema de facturación, todo el sistema de integración entre el surtidor y los EIT, ya está listo. Entonces realmente no hay mucha complicidad en hacer toda la conciliación, toda la, este, no, la emisión de la factura, etcétera. Es complejidad, es más o menos bajo. Este, todavía no sabemos cómo hacer, no, lo vamos a hacer con el app, lo vamos a hacer con un detector de Bluetooth, lo vamos a hacer con un TAC que le demos a cada uno de los clientes, lo vamos a hacer por reconocimiento visual. Entonces, hay mucha posibilidad en ese EP, no sé, como se haga, ok, lo iremos viendo en el camino. Cultura, ok, aceptamos hacer algo raro, porque va a hacer algo raro, ¿no? ¿Cuántos de nosotros usamos BICONS? Tal vez Luis Fernando, que está hablando de los, de ReggaeTale, conoce la tecnología BICOSADO, teras, quilatina, tí, talofa, donde podemos usar esa tecnología para, este, reconocer al conductor del, del carro, no sabemos. Entonces, tenemos que aceptar hacer algo desconocido. Y por último, hoy día nadie tiene presupuesto porque todo el mundo está en pérdida. Entonces tenemos presupuesto para un proyecto chico. Entonces, esos son los candidatos que deberíamos atacar de una manera aquí, ok. Si el cliente está dispuesto, si la, el área de empresa está dispuesta a arriesgarse, si no tiene este, un presupuesto que le va a durar dos años en la conversión de JD towards a SAP, etcétera, etcétera. Entonces, veamos, eso sería que es un proyecto 100% ágil y demos todo con estas filosofías. Por otro lado, tenemos el completamente a la derecha, ok. En ese caso que tenemos, por ejemplo, vino el COVID, me pidieron un sistema de gestión hospitalaria o de historia clínica, lo desarrollé para la clínica U1, le fue bien y dijo, oye, ¿por qué no reutilizo ese código y se lo revendo a las 100 clínicas que ahora, todas las clínicas también quieren hacer transformación digital, ok. Ahora, a la que no le puedo vender algo, que mañana se le muere un paciente. Entonces la cultura de la clínica es 100% ordenada con auditoría y con compliance, etcétera, ok. No puedo darme lujo de dar una solución a una clínica donde le diga, ok, este, y compromete el sistema que hoy día hace la consulta, la reserva de consulta, pero cuando llegas al médico, el médico tiene un papel donde tiene que buscar las consultas del día. No, pues, necesito algo que esté casi completamente listo, ok, con todas las funcionalidades del proceso o de journey de ese cliente, ok. Y por último, ok, este, hagamos un business plan, ¿no? Ok, ¿cuánto me cuesta salir a vender este empaquetado? Está bien concreto el caso de negocio, ¿no? Haberán hecho sucambas, etcétera. Entonces, ese proyecto, ¿por qué lo debería tratar de manera ágil? Si yo no quiero vender hoy día algo y que mañana el cliente o el usuario me llame porque no le funciona y me exija que haga rollback de lo que puse. Nuestros todos los proyectos, por ejemplo, de migración de RP, los proyectos de que estoy empaquetando un producto para venderlo, el proyecto de cambio de cor bancario, esos no pueden ser tratados de una manera ágila, ok. Tiene que ser muy estricto el paso de producción, muy estricta las pruebas, muy estricta el cronograma de trabajo. O sea, no me puedo extender, no puedo salirme del presupuesto, etcétera. Ok. Entonces, eso es lo primero que me interesa que salgamos hoy día entendiendo esto, ¿no? No todo es ágila, ok. Y por supuesto hay cosas intermedias, como el caso del medio, ¿no? Como decía Luis Fernando, ¿no? Todos ahora queremos hacer comercio electrónico, ok. Oye, pero mira, este, me encontré que ahí existe, este, ¿cómo se llama? Magento, WooComers, Shopify, que ya están listos, ok. Oye, entonces, este, yo decido voy a usar uno de esos SaaS. Y no solamente pasa en el comercio electrónico, me pasa con Salesforce, me pasa con, este, SAP, con, este, Core Metrics, con todos los productos ahora se venden estilo SaaS. Ok, eso ya están listos, se ponen en producción y deberían funcionar. Pero siempre quiero algo más, ¿no? Porque claro, yo tengo el, este, Shopify, pero Shopify te da una interfaz estilo web. No, pues si yo quiero darle un app al cliente. Entonces, es algo intermedio, ¿no? Para parte del proyecto o en forma, este, cascara nacional. Tal vez estoy haciendo mini Mbps asociados a, a todo el desarrollo completo. Entonces, hay todo el abanico de posibilidades, ok. Ese es lo primero que, y me gusta este chat porque un poco nos quita de la idea de eso, ¿no? De que si no soy ágil, ¿no? Este, no, no estoy a la moda, ok. Y los arquitectos nosotros somos los que tenemos que hacerle entender al usuario final a todos sistemas, a todos los que están en su curso de, este, transformación digital, ¿no? Este, de los negocios, etcétera. Y que no todo, ¿no? Es un solo, este, un cambio completo. Y viene también el tema de arquitectura, ¿no? Yo necesito hacer arquitectura, o sea, y acá viene otro tema que es qué es arquitectura, ¿no? O sea, cuál es nuestro trabajo de arquitectos. Nuestro trabajo de arquitectos no es necesariamente ser un consultor de negocios, ni tampoco ser un desarrollador, ¿ok? Entonces, a veces se nos remese el piso porque ya decíamos. Ahora, todos quieren ser desarrolladores con tecnologías, este, open source en la nube y desarrollar desde el front end en un celular, este, de moda, hasta el acceso a la casandra o la otra base de datos que esté de moda, ¿ok? Y aparecen los programadores full stack, pero ellos no son arquitectos. El arquitecto no tiene que meterse a codificar, el arquitecto no se tiene que meter a codificar, pero sí a planificar. O sea, el rol básico del arquitecto y por eso tenemos y es tan importante la arquitectura empresarial, que es básicamente planificar el orden, o sea, si, obviamente, orden es sinónimo de planificación, ¿no? Ahí estamos viendo que hay un comentario ahí que dice Gustavo, ¿no? La arquitectura siempre está buena o mala, explícita o no. Lo muy malo es que sea inconstancial. Y ahí discrepo un poco, no es que esté la arquitectura, lo que está es la infraestructura y la vista de esa infraestructura es parte de la arquitectura. O sea, la arquitectura es, por un lado, la parte funcional, por otro lado, la parte operacional o infraestructura, que, claro, a veces está ahí desorrenada y el arquitecto tiene que tomarla y ver cómo meterle cambios para que sea más funcional, lo más, y no, como dice ahí, esta circunstancia. Entonces, claro, la arquitectura se requiere más arquitectura de acuerdo a la complejidad del proyecto, ¿ok? No entendí, yo dice, Gustavo, bueno, después lo vemos en las discusiones, dentro de un rato que me quedan tres minutos de charla, más tarde podemos entrar. No, pero es importante esto, ¿no? Que la complejidad, la arquitectura va, o sea, requerirá más arquitectura de acuerdo a la complejidad del proyecto. Al avanzar un poquito más rápido, porque no me llegué mucho tiempo, es importante también ser conscientes y más en temas ágiles, en temas ágiles es más importante que el arquitecto esté involucrado en los diferentes sprints, o sea, durante todo el ciclo de desarrollo, que no pasaba antes, ¿no? Antes el arquitecto trabajaba en el macro diseño y en el micro diseño, pero cuando se comenzaba a desarrollar o a crear ya los componentes, ya medio que, participaba muy poco. Ahora, durante el ciclo de desarrollo, es iterativo, no sé si tengo mouse o puntero, la arquitectura va cambiando, porque poco a poco voy pasando en producción cosas y poco a poco me voy enterando de que esto estuvo bien o el otro estuvo mal. Te tengo que ir actualizando la arquitectura, o sea, la arquitectura de la solución y la arquitectura de acuerdo con cómo van avanzando los proyectos. Los documentos se vuelven más vivos. El problema que yo he visto con muchas arquitecturas empresariales es que la recomendación de arquitectura empresarial está bien bonita, guardada en anaquil del gerente de sistemas, pero hace cinco años, o sea, no ha evolucionado. Entonces, contratamos a consultores que me hagan la arquitectura empresarial y yo la guardo de recuerdo, porque me sirvió para saber qué planificar, pero ahí no fui actualizándola. Entonces, ahora con el tema ásquil y que van cambiando tantos componentes y toda la infraestructura tan rápido y con cada entity que va saliendo, es muy importante que la arquitectura siga viva. Ahora, ¿qué arquitectura es necesaria hacer? Ahora que no tengo todo un ciclo grande de macro diseño o micro diseño. Todo proyecto ásquil debería comenzar con confirmar lo que llaman los gil, lo que se quiere hacer. ¿Eso dónde se hace? Básicamente en talleres de Design Sinking. Un taller de Design Sinking que demorará dos medios días a dos días y después, de acuerdo a lo que sale de Design Sinking, tenemos uno o dos días más donde se define bien los requerimientos del proyecto. En ese momento deberíamos tener la arquitectura en una hoja. En una hoja de papel es suficiente, suficiente arquitectura que entre en una hoja de papel. Y después cuando estamos haciéndoles el primer MVP, el primer prototipo, también hagamos un poco de arquitectura. ¿Qué haremos en esa arquitectura inicial? Básicamente hay que tener una idea de requerimientos no funcionales, porque a veces me piden cosas que no van a poder ser. Me piden, ok, quiero darle esto al cliente, pero tienen que funcionar en un segundo. No, pues ese es un requerimiento no funcional que hay que confirmar. ¿Quiénes son los usuarios finales? O sea, hacer un contexto del sistema. ¿Con quiénes voy a interactuar? Con el cliente, con el personal del almacén, con el sistema A, B y C, etcétera. Muchos proyectos ágiles y han estado fallando, por ejemplo, porque un departamento hacía algo ágil y no se integraba contra el sistema de seguridad del banco. Muerto, pues eso nunca ha ido a pasar a producción. Una idea de los componentes que necesito y de acuerdo a los sistemas contra los que quiero, los que me quiero integrar, también tener un poco de integración. Esa es la arquitectura en una página. Y después en las siguientes, en semanas que se va a comenzar a hacer el prototipo, ya tendré un modelo de componentes a más detalle, alguna idea del operational model o de la infraestructura que voy a necesitar y crítico al tema de seguridad. Estas son las arquitecturas iniciales. No es como hasta ahora que necesitaba tal vez una arquitectura que estaba en 50 páginas. Y es básicamente lo que quería comentar. Ahora en un rato vienen la sesión de preguntas y respuestas. Podemos discutir más respecto. Lo importante es, lo que decía acá, un proyecto ágil, generalmente lo único que se define es el que tengo tanto tiempo y tantos recursos o costos. Y poco se va avanzando en el alcance. Ok. Pero desde el, el design syncing, desde los primeros días tenemos que tener una arquitectura. Una arquitectura en una hoja. No hacer más que el proyecto no se arranque o que no se arranque el MVP. Y eso era todo. Después puse una documentación. El modelo C4, por ejemplo, un modelo de arquitectura muy simple. Y BMW está hablando en su modelo, en sus prácticas ágiles, está hablando de ese modelo C4. Y después ponemos a otros sites más que pueden revisar. Y ahí lo dejo por ahora. Que excelente, Carlos. Muchísimas gracias. Excelente presentación. Efectivamente toca puntos críticos, verdad. Una de ellos es el balance. Cuando aplicar un arquitectura ágil o cuando una más tradicional, por buscar una palabra, cómo es ese balance, es uno de los tópicos más fuertes de discusión, por cierto, dentro de los foros, verdad. Y el otro, pues, qué tanta arquitectura necesaria, verdad. Ese es el otro, verdad. Y también el otro, el hecho de que en medio de una receta única para esto depende, pues, de cada situación en particular. Bueno, muchísimas gracias a todos nuestros presentadores. Estaremos pasando a la última parte del evento, porque si no es de tiempo estaríamos dando, quizás, una media hora, verdad, a la parte del...