Arquitectos vs Desarrolladores

 Días  atrás encontré un post interesantisimo de Jotapé, un MVP chileno –MVP significa "most valuable professional", o "profesional de los más valorables", una suerte de distinción que MS otorga a aquellos tecnólogos que más se destacan por sus conocimientos y su labor en transmitirlos a sus pares-. Juan Pablo hablaba sobre la relación entre Arquitectos de Soft y Desarrolladores de Soft

En rigor de verdad, su post le disparaba a los arquitectos de software que se la pasan hablando a más de 10 mil pies de altura acerca de cosas que se ven sencillas desde esa posición, pero que para los desarrolladores son difíciles de implementar. La crítica de Juan Pablo hacia los arquitectos iba en la medida en que los arquitectos suelen (debería decir solemos?) no reparar en esos detalles

Definitivamente entiendo la postura de Jotapé, interpreto a lo que se refiere. Pero no la comparto. Veamos: sé a qué clase de arquitectos de software Jotapé se está refiriendo; sé que existe esa clase de "así llamados" o "autodenominados" arquitectos

Si realmente vamos a permitir que la definición de "arquitecto de software" incorpore a este grupo de arquitectos de "coloquios de café", entonces Juan Pablo tiene razón. Pero un verdadero arquitecto de software no debe actuar de esa manera. Y si lo hace, sea el jefe de proyecto (deseable) o incluso los desarrolladores (aunque sea los más senior) se lo deben hacer notar

Cuál debería ser el modus operandi del arquitecto de soft políticamente correcto? Para responder a esa pregunta repasemos el sentido básico del rol de arquitecto. Me quiero colgar de una definición de John deVadoss, Director del Equipo de Estrategia de Arquitectura de Microsoft

"El arquitecto de software es un administrador de la complejidad, lidia con ella todo el tiempo"

A qué tipo de complejidad se refiere deVadoss? A la complejidad de las API’s, de las tecnologías como ADO.NET, JSF, EJB, Windows Communication Foundation, AJAX, etc. Tecnologías útiles, potentes para el fin con que fueron creadas. Pero complejas desde la óptica de un desarrollador promedio. No me refiero a los más destacados desarrolladores: de esos hay tan pocos que es por eso que son los más destacados

Pero el desarrollador promedio es aquel al que las organizaciones prefieren antes que asimilen la cultura y las prácticas comerciales de la organización, que dilapiden el tiempo entendiendo por qué la aplicación no compila, y una vez que compila por qué no hace lo esperado, por qué no escala, por qué presenta un rendimiento bajo, por qué es insegura, etc

Si tuviera que armarle una checklist a un arquitecto de software que debe concretar la arquitectura de una nueva aplicación, dando por asumido que ya conoce el problema de negocio a resolver y que lo que se espera ahora es que planée la arquitectura sobre la cual montar una solución tecnológica, las tareas que le indicaría son las siguientes:

  1. Descomponer la aplicación en capas, al menos, lógicas. Las capas lógicas se diferencian de las capas físicas en la medida en que no hacen referencia al equipamiento en donde correran como sí a la responsabilidad primordial que tienen en la solución general
    Es ideal que la arquitectura preliminar incluya ambos tipos de descomposición (lógico y físico). No obstante, la descomposición en capas físicas es algo que un arquitecto de soluciones genérico no es tan hábil de hacer sólo sino que normalmente debe discutirlo y cederle, cuando sea necesario, la palabra a un arquitecto de infraestructura. Por una cuestión de costos, algunas organizaciones designan en un mismo miembro del equipo ambos roles arquitectónicos. No obstante, en la práctica, son poco los casos donde una misma persona presenta habilidades aceptables en los dos terrenos a la vez
    La descomposición en capas lógicas es fundamental, y de hecho debe ser tal que pueda acomodarse a más de una descomposición en capas físicas, en la medida en que la aplicación -por razones de escalabilidad y/o rendimiento- deba re desplegarse (redeployment
    ). Por ejemplo, separar la capa de datos (la base de datos) en un servidor diferente del de la lógica de negocio, o replicar la capa de presentación en una granja de servidores web
  2. Descomponer cada capa lógica en componentes. Esto es, asignar claramente las responsabilidades de ejecución, ya sea en clases concretas o abstractas, o quizás también en interfaces que posean contratos completamente definidos, de manera tal que los desarrolladores de lógica de aplicación completen su implementación
    Esto último es el típico caso del Principio de Hollywood: "no nos llame, nosotros lo llamamos" que actualmente es la piedra basal de los contenedores livianos (lightweight containers). Estos frameworks posibilitan que los desarrolladores implementen componentes de negocio que en tiempo de ejecución sean inyectados dinámicamente como dependencias de la aplicación principal. De esa manera se invierte el control (Inversion of Control, o también IoC) de la aplicación y la misma arquitectura es capaz de instanciar y pasar el control (callback
    ) a dichos componentes de aplicación
  3. Seleccionar tecnologías y/o frameworks de implementación. Acá viene la parte a la que deVadoss se refería cuando hablaba de "lidiar con la complejidad"
    Por ejemplo: se requiere aprovechar la potencia de JSF pero sin lidiar con la complejidad de JSF? Perfecto: que el arquitecto colabore por ejemplo adaptando las interfaces de las API’s de JSF en una nueva API quizás más limitada pero sí al menos con toda la potencia necesaria para satisfacer los requerimientos de lógica de presentación que la aplicación requiere. En otras palabras: algo que le saque el jugo a JSF pero que no obligue a cada desarrollador a aprender JSF sino que sólo se use aquello por lo que hemos elegido JSF
    Otro ejemplo: se requiere contar con una capa de acceso a datos potente, que evite líneas de código innecesarias pasando ("paseando") del mundo orientado a objetos al mundo de las tablas relacionales y viceversa? Ok: que el arquitecto seleccione algún framework de mapeo entre objetos y tablas relacionales (object/relational mapping u O/R-M) al que quizás se le añadan cierta capa de aislamiento encima, de modo de aprovechar su potencia pero sin acoplar la lógica de aplicación al mismo. Y quizás también como una forma de suavizar la curva de aprendizaje si el framework O/R-M es potente pero también complejo de aprender
  4. Realizar una Prueba de Concepto (Proof of Concept o PoC) de la arquitectura. Si un arquitecto define su arquitectura sin pasar por esta etapa, coincido con Jotapé en que es un chanta. No un arquitecto
    Qué es una PoC de arquitectura? Es cierta pieza de código compilable y ejecutable que ejemplifique, en una primera aproximación, cómo el control va atravesando las diferentes capas. A este ejercicio también se lo conoce como "corte vertical" (vertical slice) en el sentido que a las capas se las suele representar en diferentes niveles: la de presentación suele aparecer arriba de todo, luego le sigue la de negocio, luego las de acceso a datos y a recursos externos, y en el último nivel las capas de datos (las bases u otros repositorios de datos) y los servicios expuestos por recursos externos a la aplicación
    Existen varios tipos de PoC, según lo que se quiera probar. Por ejemplo, si lo que se pretende es testear de antemano el rendimiento de la aplicación, o su escalabilidad, la prueba se limita a estressar un entorno de servidores similar al que se planée para Producción, a efectos de conocer los límites o puntos de quiebre de la aplicación (cuántos usuarios concurrentes, cuántos requerimientos simultáneos será capaz de atender con un tiempo de respuesta no mayor a los 200 mseg, etc). Otros tipos de PoCs pueden testear la seguridad de la aplicación simulando ataques y observando cómo reacciona el sistema, etc
    La Prueba de Concepto es una etapa necesaria para validar la arquitectura, para decidir si seguir adelante o someterla a ajustes o revisiones ulteriores. Pero fundamentalmente, es un elemento que al arquitecto le debe proveer confianza en sus decisiones, y a la vez inspirar confianza en el resto de los interesados en la aplicación. Empezando por el jefe de proyecto, que deseablemente debería ser el principal sponsor del arquitecto
    Ahora bien, para concretar la PoC, el arquitecto debe ser capaz de escribir software? No necesariamente. Estoy seguro que acá tengo el punto principal de discordancia con Jotapé. Lo que el negocio espera de un arquitecto es que interprete las tecnologías de manera de alinearlas en la dirección a la que la organización se dirige. Esta parte quizás no suena alegre a los oídos de los desarrolladores, pero el negocio es el que manda (lo digo honesta y lamentablemente, sin arrogancia)
    Es un plus
    importantísimo que el arquitecto sea un ex developer que todavía recuerde cómo escribir código que compile y ejecute, o al menos sea capaz de escribir un pseudo código que un desarrollador senior sea capaz de interpretar sin dificultad y dar una mano extra al arquitecto para poner en práctica sus ideas. La colaboración directa de un desarrollador senior con un arquitecto en una PoC tiene al menos dos beneficios:
    1. Mejora la productividad del arquitecto, que de lo contrario demoraría más en escribir el código el mismo
    2. Beneficia al desarrollador senior, que de la misma interacción con el arquitecto puede ir moldeando su propio estilo con miras a convertirse en arquitecto en un futuro próximo
      Definitivamente la arquitectura de software no es una ciencia oculta: que es difícil no tengo duda alguna. Pero no es nada que con voluntad y esfuerzo no se pueda aprender
  5. Brindar algunos casos de uso de referencia. Esta última actividad que destaco tiene como finalidad explicar como juegan, en la práctica, la arquitectura y los componentes a implementar por los desarrolladores. Cuanto más representativos y emblemáticos del 80/20 sean los casos de uso, tanto mejor
    Nuevamente: acá es ideal que algunos desarrolladores -quizás los más destacados del equipo- colaboren con el arquitecto en la implementación de estos casos de referencia. Esto le va a dar no sólo feedback
    al arquitecto respecto de la arquitectura que definió, sino que además le va a permitir ganar confianza respecto de cuán asimilable es su arquitectura
    Los desarrolladores que participen en esta etapa pueden ser quienes transmitan las ideas generales de la arquitectura al resto de los desarrolladores, e ilustren las mismas a través de estos casos de referencia

Considerando esta checklist de actividades, verdad que cambia el panorama que Juan Pablo describía en su post? Es cierto que no son pocas las organizaciones que poséen uno o quizás más miembros en sus equipos de desarrollo, que ostentan el título de "arquitecto" sólo porque de ellos se espera que alinéen tecnologías al negocio… sin que necesariamente deban verificar o refutar sus decisiones. Y no es menos cierto que, en esos casos, el arquitecto suele presentar su arquitectura documentada, a personas practicamente incapaces de validarla. Ya sea porque son miembros del equipo más con un rol de manager, u otro cargo jerárquico, que suelen estar menos enterados de las últimas novedades tecnológicas. O quizás porque son desarrolladores con mayor o menor seniority, pero sin la capacidad de influencia necesaria como para convencer al arquitecto (y más arriba del arquitecto) de los riesgos a los que la arquitectura -así como está- dejaría la puerta abierta

No pretendo con esto resolver todos los tironeos que han habido -y seguirán habiendo- entre arquitectos y desarrolladores. Aunque sí al menos proponer un esquema de trabajo con responsabilidades distribuidas que permitan a ambos combinar lo mejor de su potencial

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

3 respuestas a Arquitectos vs Desarrolladores

  1. Juan Pablo dijo:

    Hola DIEGUM,
     
    me gustó tu post, escribí algunas ideas sobre el mismo en BLOG
     
    http://spaces.msn.com/liarjo/blog/cns!4131EA552C5BB029!740.entry
     

     
    Te invito a leerlo, esta conversación posteada me parece muy positiva.

  2. Luis Alberto dijo:

    Hola Diego,
    Lei lo del Arquitecto Vs. Desarrollador, Quizas en un entorno mas antiguo o del pasado esto es la vieja "pelea" entre el Analista y el Programador ?
     
    Muy buen articulo.
     
    Saludos
    Luis
     

  3. Diego dijo:

    Sin dudas que hay similitudes, Luis, aunque en aquel caso quizas el origen de la pulseada era que, en la vision del desarrollador, el analista tenia el "si" facil con el usuario y despues lo tiraba a los leones. En la vision del analista, el desarrollador parecia alguien que no estaba alineado con los objetivos empresariales de la compañía
     
    En el caso del Arq vs Dev el trasfondo de la pelea pasa quizás más por cuestiones tecnológicas ("a mí me dijeron que con Indigo se podía hacer blah blah blah, cómo es que ahora no se puede?" / "sí que se puede pero la performance es mala", etc)
     
    Me atrevería a decir que lo que no está del todo claro en el rol del arquitecto es si a éste le compete o no conocer los pros y cons de cada tecnología, API o plataforma, o si esa es una tarea que los desarrolladores deben desempeñar (yo tengo opinión formada al respecto y en base a mi experiencia pero cada vez que la dije me lanzaron cosas, mejor en otro post)  😀

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