Hace un tiempo me contactó Carlos Delgado, como representante y re-lanzador del capítulo de IASA en Madrid. Me hizo una entrevista que podéis ver en el siguiente vídeo.

Posteriormente nos visitó el CEO internacional de IASA, Paul Preiss, quien nos estuvo introduciendo qué es IASA, qué es según ellos un arquitecto, los tipos que hay y un roadmap de formación y certificación.

Yo, si os digo la verdad, no he tenido mucho interés en certificarme de nada nunca pero hay realidades que no podemos ignorar y una de ellas es que en algunos clientes internacionales que tenemos, le dan mucha importancia a las certificaciones. Distintas personas de Autentia tienen que certificarse en distintas disciplinas.

También sucede otra cosa. En empresas que estamos todo el día aprendiendo, la gente demanda un plan de carrera y formación, y muchas veces esta formación que requieren no es siempre la que necesitan, y me voy a explicar. Para hacerlo voy a acceder a contenidos de la página de IASA Global. Os podéis logar gratis y tener acceso a los documentos.

Si preguntas a la gente qué es un arquitecto te contestarán muchas cosas en función del background:

Fijaos en este modo de pensar, como nosotros somos arquitectos de software pensamos que todo el que no sea un experto en software no es un arquitecto pero ¿y el que define toda la estructura de servidores? ¿Y el que define las redes y subredes físicas y lógicas? ¿Y el que entiende el negocio y los sistemas existentes y construye un plan estratégico o el modelo de micro-servicios? ¿Y el que define la arquitectura de información y ciclo de vida del dato e incluso modelos de aprendizaje automático?

Entonces, podemos ver que hay distintos tipos de arquitectos y que cada uno de ellos tendrá roadmaps diferentes de formación.

Adicionalmente estamos siempre muy interesados en las habilidades Hard, como programar y manejar los frameworks y herramientas pero ¿una persona senior puede permitirse el lujo de no desarrollar habilidades Soft?

Además, tendrá que entender qué es un negocio, saber hablar de KPIs o OKRs, conocer modelos de definición de proyectos de futuro (y no considerar que se pierde el tiempo cuando se asiste a reuniones de conceptualización), tendrá que entender que hay sistemas legacy que generan la riqueza actual de las empresas y no se pueden tirar, etc.

Por tanto, a medida que un profesional avanza debe visualizar el universo del conocimiento en distintas dimensiones y no negarse la posibilidad de aumentar horizontes. Seguimos escuchando eso de, “si a mí lo que me gusta es programar, no me metas en mierdas de reuniones” o “pero en esta empresa alguien trabaja” (haciendo referencia a gente que define y coordina).

Por esto, en Autentia estamos empezando el trayecto de formación en arquitectos de software, para forzarnos a formalizar y ampliar la visión.

Este es el roadmap:

Por el camino, vamos a intentar hacer algunas cosas, como ayudar a traducir la guía a castellano y, en lo que podamos, re-lanzar el capítulo de IASA en Madrid, ya simplemente porque creemos que igual que hay muchos meetups de muchas cosas, un foro donde podamos quedar gente a hablar de arquitectura (en su amplio sentido) parece buena idea. Es que parece que si no eres el mejor programador, no tienes cabida en los foros técnicos.

Esta semana pasada ayudamos a organizar una mesa redonda y podéis ver el cartel de expertos que se anima a participar:

• Elena Rodríguez, IT manager for Digital and Customer experience at Iberia en IAG GBS.
• Daniel Brandi, CIO for Spain en Orange Bank.
• José Luis Merino, Software Director en Grupo DIA.
• José San Román, Responsable de desarrollo en ING.
• Javier Vélez, Líder de Desarrollo Tecnológico en Arquitectura de Canales de Front en BBVA.

Como digo siempre, hasta las 21 h. se aprende. Hasta las 24 h. se hacen amigos y hasta las 3 am. se hacen amigos para toda la vida. A estos eventos hay que venir sin prisa.

Durante la mesa redonda y posteriormente, se tuvieron conversaciones muy interesantes relativas a la complejidad de entregar valor continuamente a negocio e ir construyendo y consolidando una arquitectura.

Yo me quedaría con algunos conceptos (siempre me gusta recordar qué es lo que yo he interiorizado, que no es necesariamente lo que la gente quiere decir (pero lo hemos grabado ?).

• En una pila de producto hay 4 elementos: funcionalidad, bugs, arquitectura y deuda técnica. Los dos primeros los compra con facilidad negocio, los dos últimos hay que ser hábiles a la hora de venderlos porque son imprescindibles para seguir entregando valor de un modo sostenible.
• El legacy se caracteriza por dos cosas: da miedo tocarlo y genera mucho dinero. Hay que ir viendo cómo se digiere y se va rompiendo en piezas pequeñas para pensar en la futura “digestión” dentro de años.
• Se ha entendido mal el manifiesto ágil diciendo que en las metodologías ágiles las arquitecturas emergen de los equipos auto-organizados. Esto ha hecho que los equipos quieran partir muchas veces de cero o dedicar solo un Sprint a la arquitectura cuando es algo importante y continuo.
• Es más, sin una arquitectura que simplifique muchas cosas no es posible tener agilidad.
• La arquitectura establece restricciones a los equipos para que sea mantenible y asumible la evolución de los sistemas.
• El término “transformación digital” empieza a oler mal porque se usa para todo.

Bueno, espero que esto sea un comienzo de algo duradero. ¡Nos vemos por las charlas!