Los del Equipo de Arquitectura de Microsoft nos Hicimos la Película

 
 TechReady  es el nombre de un evento que Microsoft organiza dos veces al año para capacitar a sus empleados de todo el mundo en las tecnologías que la compañía desarrolla. Esta feria dura una semana y sirve mucho para que nos conozcamos cara a cara los que trabajamos en Corp (la casa central en Redmond), que no solemos ver clientes salvo contadas ocasiones, con los que pasan la mayor parte del tiempo frente a clientes y socios desarrolladores
 
Normalmente al promediar esa semana se realiza una cena informal conocida como "Ask the Experts Night" (La Noche de "Pregúntele a los Expertos"), especialmente para hablar cara a cara con los hacedores de los distintos productos y tecnologías, plantear inquietudes, etc
 
Mandy Landa, mi colaboradora en publicación web para los sitios MSDN Architecture Journal -versión on line de una revista de arquitectura de software, principalmente agnóstica de tecnologías, que dirige mi jefe, Simon Guest-, MSDN Architecture Center -sitio que dirijo y que pretende concentrar el conocimiento de arquitectura de software para sistemas de misión crítica basados en plataforma Microsoft– y SkyScrapr -el hermano menor de la familia, un espacio de comunidad dedicado a aspirantes a arquitecto de software-, andaba por allí con su cámara y se le ocurrió reportearnos a los arquitectos del Equipo de Estrategia de Arquitectura (Architecture Strategy Team, o AST) acerca de qué pensamos que hace falta ser, tener y hacer para ser arquitecto
 
Es interesantísimo escuchar, siendo que a todos nos tiró la pregunta ya con la cámara grabando y sin previo aviso, las respuestas espontáneas que todos dimos porque la realidad es que todos dimos visiones diferentes que, sin embargo y milagrosamente, no se contradicen entre sí. Al revés: se complementan. Yo revisaba, cuando Mandy subió el video a la web, las respuestas de mis compañeros, y pensaba "Fulano habla con palabras que perfectamente pude haber dicho yo, y sin embargo no dije, no se me ocurrió, pero qué bueno es que lo haya dicho él!! Sumado a lo mío potencia el resultado!"
 
Lo que hice fue embeber el video directamente en este post, pero como para variar está en gringo -y si te querés reir un rato, ponelo para escucharme hablando como si fuera Abraham Lincoln después de la bala-, lo que hice fue transcribir las ideas salientes que dio cada uno (no es traducción fiel de cada frase sino un condensado de las ideas principales: el video dura más de 8 -ocho- minutos)
 
Antes de pasar a la transcripción, te cuento quién es cada uno
 

Bueno, habiendonos presentado todos, vamos a la transcripción de los comentarios:

  • Diego Dagum: yo empecé a decir que era arquitecto antes de serlo realmente, ya que no tenía la experiencia aún. En consecuencia llegué a serlo cometiendo errores -claro, por inexperto, por arrogante, por ignorante, …- pero así me dí cuenta qué fue lo que falló para hacerme cargo y arreglarlo
  • Atanu Banerjee: hacen falta dos cosas principalmente: interesarse en un entorno amplio de tecnologías y a la vez desarrollar perfiles comunicacionales. Algunas de las personas a las que hay que llevarles un mensaje tecnológico son desarrolladores, otros son ejecutivos y en el medio tenés todo un rango de perfiles
  • Frederick Chong: arquitectura es parte ciencia y parte arte. Así que tenés que ser lógico cuando un enfoque científico sea el adecuado, y tenés que ser creativo cuando lo que se necesite sea arte
  • Michael Platt: no es cuestión de que te las sepas todas, eso es imposible. Tenés que saber sólo aquellas áreas que te hacen ir directo al fondo del asunto, pero no necesitás saber más allá de ahí. Para cada situación necesitás entender dónde está el problema y conocer a partir de allí cuál es técnico necesario (nota mía: desarrollador, DBA, operador, etc) para resolver ese problema. Tu rol va a ser clave para comunicarte con los demás. Necesitás conocer de administración de aplicaciones e instrumentación, y a la vez saber con qué productos cuenta la industria, pero no conocerte detalles de los mismos para ponerlos en práctica. Es interesante esto porque, alcanzar ese nivel de conocimiento equilibrado, es lo que a la mayoría le resulta más dificultoso
  • Simon Guest: lo que vas a necesitar seguramente es experiencia, y al respecto te digo que la mayoría de los arquitectos somos diferentes, es decir que los perfiles de arquitecto que desarrollamos son distintos. Ahora, lo que sí creo que todos los colegas tenemos en común son "años de experiencia". Y eso nos permite desarrollar un panorama completo
  • Mike Platt: pensamiento lógico y un par de cosas más: buenas capacidades comunicacionales y una buena comprensión de las características de la organización, también. Se necesita conocer cómo la organización trabaja, cómo su gente hace el trabajo, y además entender cómo la tecnología encaja en ese cuadro, porque en realidad de eso se trata: personas y tecnología. De esa manera tu rol consiste en poner a la tecnología como parte de un sistema más grande, siempre que apoye a estas personas
  • Diegum: ser un arquitecto implica cometer algunos errores al principio pero entenderlo y asumirlo luego, no? Así que vos podés cometer errores toda tu vida, pero ése no es en todo caso el problema: el problema es cuando nunca aprendés a parar de cometer el mismo error una y otra vez
  • Mike Platt: lo que la mayoría de la gente encuentra más complicado, y probablemente lo sea, es domar la abstracción. Porque hacer un conjunto de modelos abstractos quizás es lo fácil, pero comunicarselos a través de un pizarrón a una serie de tipos y que todos entiendan de ahí que es lo importante, qué lo crítico, etc. Es difícil pero a la vez esa es la parte central de la actividad que hacemos
  • Fred Chong: se trata de construir aplicaciones de misión crítica. Escribir código es una manera posible de seguir las tendencias, conocer los verdaderos puntos de interés, tratar de imaginarse qué problemas podrían venir para estar preparados cuando de veras llegue el momento. Yo creo que el rol del arquitecto tiene mucho que ver con eso: con resolver problemas
  • Diegum: para llegar a ser arquitecto realmente hay que invertir tiempo en leer mucho acerca de los distintos puntos de vista, las distintas formas de resolver un mismo problema ya que, el típico error que cometemos como arquitectos es el pecado de la arrogancia en el sentido de que… "ah no… Mi solución en realidad es LA solución así que no necesito aprender nada más". De manera que la mejor práctica para no caer en eso es tratar todo el tiempo de discutir contra uno mismo, jugar al abogado del diablo, probar de encontrar nuevas formas de resolver un mismo problema, incluso cuando considerés que con lo que ya tenés la batalla está terminada. Por supuesto, eso te implicará invertir cierto tiempo, y seguramente será difícil encontrar ese tiempo. También la mano pasa por participar en foros de discusión (nota mía: el Foro de Arquitectura General MSDN es un claro ejemplo). Y, definitivamente, la regla de oro en todo esto es tener la real experiencia de todo, no contentarse con solamente hablar sobre arquitectura y nada más. Vos necesitás tener la experiencia y probar en la práctica de que tus ideas, tus pensamientos realmente tienen sentido
  • Mike Platt: también hay que aprender escuchar, por supuesto. Todo viene y va en diferentes direcciones. Hay que saber escuchar a diferentes personas que vienen de diferentes lugares. Algunos son analistas de negocios, otros profesionales de TI, por lo tanto tienen diferente background. Pero vos tenés que entender todo el tiempo de dónde viene cada uno de ellos y no hay una respuesta correctamente entendible para todos ellos al mismo tiempo porque tienen diferentes puntos de vista, intereses e incluso estilos. Y vos también tendrás que entender cuando alguien más te esté hablando a vos, y ser capaz de alinearte a su visión. Ser hábil en entender todos los puntos de vista y habilitar una solución que sea capaz de contemplar los intereses de todas las partes
  • Diegum: vos no podés abandonar. Vos no debés abandonar. Vos tenés que continuar la carrera y tenés que lidiar con la frustración de modo de no abandonar nunca. De esa forma yo tengo fé que un día vas a llegar. Yo tengo un montón de casos, no sólo el mío propio, de un montón de amigos míos a quienes conocí cuando ellos apenas si eran desarrolladores juniors y puedo decir al respecto que ellos hoy en día son arquitectos probos. Puedo decir que ellos pueden aplicar para la certificación porque ellos hoy tienen los antecedentes, el conocimiento, en definitiva, los deberes hechos para poder aplicar a eso

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

3 respuestas a Los del Equipo de Arquitectura de Microsoft nos Hicimos la Película

  1. Matias Woloski dijo:

    Muy bueno dieguete… Me gusto: el problema es cuando nunca aprendés a parar de cometer el mismo error una y otra vez
    y la de Fred: Yo creo que el rol del arquitecto tiene mucho que ver con eso: con resolver problemas
    Pragmatismo es la clave.
    Un abrazo

  2. Diego dijo:

    Gracias, Matías!! Que lujo saber que una eminencia como Usted lée mi blog!!  😀
     
    Está claro que el pragmatismo, como decís, es fundamental. En otras palabras, el sentido común. En otras palabras, no ser más papista que el Papa. En otras palabras, como dice Kent Beck en "eXtreme Programming explained", "do the simples thing that can possibly work" (algo así como "hacé lo más simple que con suerte vaya a funcar"). En otras palabras, normalizar tablas es lo deseable pero si eso implica un despelote de accesos que a la larga le pega al rendimiento y a la complejidad del código, ya no es tan deseable y quizás cierto nivel de redundancia acotada no era tan nefasto como los libros decían. En otras palabras, diseñar para el reuso es cool porque te vas a ahorrar horas hombre más adelante, pero si eso implica consumir interminables horas de diseño en algo que sirva para satisfacer requerimientos actuales (conocidos) y requerimientos futuros (y acá no digamos conocidos porque aún no llegaron!!) el tiempo que queríamos ganar ya lo perdimos de entrada (y adelante del usuario quedamos como el cool)
     
    El amigo Ted Neward está escribiendo para MSDN Architecture una serie llamada "Pragmatic Architecture", la cual empezó con dos capítulos, Layering y Seguridad; ya se viene Experiencia de Usuario y ya está Ted trabajando en Misión Crítica, Procesos Ágiles y Acceso a Datos. En realidad, nos podemos leer todos sus artículos y no vamos a aprender nada nuevo, nada que no supieramos. El asunto es ése: todos lo sabíamos pero, cuando nos tocó el turno… Firulete qué pachó?
     
    By the way, viste que te marqué? Abrite este post reciente, http://diegumzone.spaces.live.com/blog/cns!1AD5096D63670065!593.entry. Ahí ventilé 5 (cinco) cosas de mi oscuro pasado y mandé en cana después a 5 (cinco) blogueros para que hagan lo propio  😉

  3. Matias Woloski dijo:

    Ahi respondi mostruo a tu marca… La semana del 26 de marzo estoy por alla, asi que preparate. A proposito, fijate que te parece este articulo para ponerlo en tus boletines
    http://staff.southworks.net/blogs/matiaswoloski/archive/2007/03/10/The-holly-grail-of-Enterprise-SOA-security.aspx
    un abrazo

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s