Cuánto daño han hecho… los arquitectos de software

En el mundo del desarrollo de software, como en todo, hay cosas que, a priori, parecían una buena idea, pero con el tiempo han acabado haciendo más mal que bien. Si anteriormente ponía el ejemplo del daño que habían hecho los generadores de aplicaciones, en este post le toca el turno a los arquitectos de software.

En demasiadas ocasiones se utiliza el, en mi opinión poco acertado, símil de la construcción o de la ingeniería civil para intentar comprender y gestionar el desarrollo de software y eso ha dado lugar a la aparición de un rol, el del arquitecto de software, que se pretende asimilar al arquitecto de un edificio, y que incluso ha sido mitificado por películas como Matrix.

Arquitecto de Matrix

Pero empecemos por el principio, ¿a qué nos referimos con arquitectura de software?

Arquitectura de Software

Según la wikipedia, la arquitectura de software es el diseño de más alto nivel de la estructura de un sistema. Esta definición es algo ambigua puesto que precisar cuál es el “más alto nivel” de un sistema es un tanto subjetivo, pero nos permite hacernos una idea intuitiva de lo que estamos hablando.

En realidad, podríamos ver la arquitectura como algo fractal que podemos observar con distintos niveles de detalle. Podemos tener una arquitectura global de todo un proyecto que engloba varios sistemas, arquitecturas a nivel de cada sistema, y arquitecturas específicas para cada componente de un sistema pero, independientemente del nivel al que lo apliquemos, la idea es la misma: diseñar la manera en que se estructuran y comunican los distintos componentes que forman parte de algo.

Partiendo de esta idea, es fácil entender que la arquitectura de software es un factor muy importante a la hora de desarrollar aplicaciones. Elegir la arquitectura correcta para un sistema (o para una parte del mismo) puede ser crítico a la hora de alcanzar los requisitos establecidos de escalabilidad, flexibilidad, facilidad de mantenimiento, etc.

Existen muchos tipos de arquitecturas que han ido evolucionando con el tiempo, desde las tradiciones cliente-servidor, las basadas en N-capas, orientadas a servicios, basadas en microservicios, orquestadas alrededor de buses, etc.

Hay también catálogos de patrones de arquitectura similares a los catálogos de patrones de diseño (a veces la frontera entre diseño y arquitectura es francamente difusa), que recogen distintos patrones de “probada eficacia” (ejem) que podemos aplicar al establecer la arquitectura de un sistema.

Desarrollar una aplicación sin tener en cuenta la arquitectura acaba resultando en una masa monstruosa de código difícil de comprender, difícil de evolucionar y difícil de escalar.

Si la arquitectura de software es algo tan importante a la hora de desarrollar aplicaciones, parece lógico que exista gente especialmente preparada para decidir qué arquitectura usar y cómo implantarla, y esos son, claro está, los arquitectos de sofware.

Arquitectos de Software

Un arquitecto de software debe ser capaz de analizar un problema y diseñar la mejor arquitectura para resolverlo. Un arquitecto de software conoce una amplia gama de tipos de arquitectura y patrones arquitectónicos, sabe cuando aplicarlos y, a partir de ellos, establece unas pautas, normalmente usando diagramas UML, frameworks o implementaciones de referencia, y delega la implementación del sistema a un equipo de desarrollo.

Esa visión de la arquitectura de software tan similar a la del arquitecto de un edificio, que genera unos planos para que otros construyan el edificio, es una visión errónea y peligrosa.

El desarrollo de sofware no se puede compartimentalizar tanto como para que unos diagramas UML o un mega framework corporativo sirva de guía única e infalible al construir una aplicación.

Es posible (no lo sé, no tengo ni idea de eso) que al construir un edificio se puedan dar instrucciones tan precisas sobre cómo debe ser una pared como para que cualquiera que sepa construir paredes lo haga bien.

En el desarrollo de software, el número de grados de libertidad que existen a la hora de implementar algo hacen que definir específicamente lo que se debe hacer y cómo se debe hacer, no sea práctico. La única forma de conseguirlo es con el código fuente, y eso implica hacerlo (no diseñarlo).

La arquitectura es algo que hay que ir ajustando en mayor o menor medida a lo largo del desarrollo. Puede que las pautas más generales, como si la aplicación será web o de escritorio, o si se usará una SQL Server o MongoDB puedan mantenerse estables durante bastante tiempo, pero en cuanto bajas a niveles de componentes, suele ser contraproducente tener que atarse a una arquitectura prefijada, del estilo de “todos las clases deben tener su interfaz correspondiente”, “todo sistema tendrá su contenedor de inversión de control”, “siempre se usará un ORM”, etc.

Tratar de separar la arquitectura del desarrollo es un error y tratar de separar el rol del arquitecto del rol del programador/desarrollador es otro error. Es cierto que no todos los programadores son arquitectos, pero todos los arquitectos deben ser programadores. Aun así, todo programador debería comprender la arquitectura del sistema que está desarrollando, con sus pros, sus contras y los motivos por los que se ha elegido.

Ser arquitecto de software tiene un componente aspiracional para muchas personas. Puede que sea porque es la única forma que tienen de mejorar en sus empresas, puede que sea por el aparente glamour asociado al rol, pero hay personas que parece que necesitan ser arquitectos de software, incluso a veces despreciando todo el trabajo relacionado con la programación (eso es para los que “pican código”).

Eso suele acabar con una obsesión por la arquitectura en términos abstractos, mucha palabraría sobre SOA, DDD, ESBs o lo que esté de moda en el momento, pero con una falta de conexión muy grande con el mundo real. Son arquitectos que viven sus torres de marfil y desde ellas “diseñan” (por llamarlo de alguna manera) arquitecturas que luego son de muy poca ayuda, o incluso directamente contraproducentes, a la hora de desarrollar realmente el software.

He conocido empresas en las que un “arquitecto” diseñaba una arquitectura, se la pasaba al equipo de desarrollo para que la siguiese a rajatabla y sólo volvía a aparecer por el proyecto de vez en cuando para asegurarse que la arquitectura se estaba siguiendo. Incluso he visto casos de empresas con un departamento específico de arquitectura que marcaba las pautas a nivel global de cómo debían ser todos los proyectos. En ambos casos los resultados, al menos desde el punto de vista del software desarrollado, era bastante cuestionables.

Conclusiones

La arquitectura de software es una tarea necesaria para el desarrollo de software y se le debe prestar la atención adecuada.

El problema es que la arquitectura de software es algo demasiado importante para dejarlo en manos de los arquitectos. O al menos, es algo demasiado importante como para dejarlo en manos de arquitectos como los que he descrito antes y que, por desgracia, abundan en determinados sectores.

Existen muy buenos arquitectos de software, capaces de diseñar y desarrollar soluciones sencillas para problemas complejos, pero todos los que he conocido con esa capacidad son también buenos programadores, viven el día a día con el equipo de desarrollo y conciben la arquitectura como parte del proceso de desarrollo, no como algo que quede prefijado al principio del desarrollo y haya que seguir de forma ciega e innegociable.

En definitiva, por mucho que en algunos ámbitos se empeñen en crear roles específicos para cada aspecto del desarrollo de software, es bueno recordar que la especialización es para los insectos, y que cuando creas roles muy especializados, consigues justamente eso: arquitectos que diseñan sin saber las implicaciones que tienen sus diseños a nivel de código, y programadores que no pueden mejorar el sistema porque ni pueden ni saben salirse de la arquitectura marcada.


16 comentarios en “Cuánto daño han hecho… los arquitectos de software

  1. Omar del Valle dijo:

    Hola Juanma…

    La verdad es que este artículo me deja un sabor agri-dulce :) Yo sí creo en la responsabilidad de un arquitecto en un equipo de desarrollo y, cuando hablo de equipo hablo de todas las personas encargadas de planificar, orquestar, desarrollar (picar) y entregar un producto.

    El rol de arquitecto para mi sí que es importante, no puedes pretender que en un equipo todos sean capaces de crear arquitecturas que posteriormente ellos mismos picarían (otra cosa es entenderlas), por una parte el coste del equipo se te dispara y por otra, hay muchas formas de hacer lo mismo y alguien tendrá que decidir qué camino seguir.

    Tampoco sé si de verdad son tantos los arquitectos que se creen estar en esa torre de marfil o que desprecian el desarrollo o al menos me gustaría creer que no son tantos.

    Yo creo que el problema real está en el rol que nos quieren asignar las empresa como arquitectos de software. Si metes a un arquitecto para que defina la arquitectura general de un proyecto y luego lo sacas para otro proyecto, corres el riesgo de cometer todos los errores que mencionas acá. Está más que demostrado que un proyecto es algo que cambia continuamente durante su ciclo de vida y, esos cambios afectan la arquitectura del mismo (aunque es nuestra responsabilidad que la afectación sea mínima si es que hemos escogido bien la arquitectura y patrones a seguir)

    De cualquier forma estoy de acuerdo en el planteamiento general del artículo. El arquitecto no debe ser un electrón suelto en el proceso de creación de una aplicación, sino que debería ser un elemento activo y en constante intercambio con el equipo de desarrolladores.

    Mi última experiencia en este sentido fue muy buena la verdad. Yo generaba una solución a alto nivel, esa solución se discutía con todo el equipo de desarrollo y entre todos sacábamos los pro y contras que pudiera tener la arquitectura, hacíamos las modificaciones pertinentes en caso necesario y de ahí, repartíamos las tareas a desarrollar (yo como uno más) Fueron dos años de trabajo donde se sacaron varios proyectos y todos con excelentes resultados.

    Saludos…

  2. Para mí el desarrollo de software está en pañales y las problemáticas asociadas a tan amplísimo problema (inclúyanse palabrerías agile también al cocido) son sólo los síntomas de la no existencia de una solución (como las que ya existen en muchas otras disciplinas, que casi nadie se plantea como deben hacerse las cosas, sencillamente las hacen).

    Siempre en mi opinión, el arquitecto de software como tal, debe quedar definido en inversa proporción a lo monolíticos que sean los proyectos. Bueno o malo, la alternativa de la conciencia global (o “arquitectura emergente”) me parece impredecible y poco apetitosa.

    Hoy en día, un arquitecto hábil puede lograr ensamblar un conjunto de servicios de forma adecuada sin desarrollar directamente ninguno de los componentes.

    Que no podrá hacer el día de mañana en que la interoperabilidad, datos y servicios estén plenamente estandarizados…

  3. Completamente de acuerdo.
    EL arquitecto de software, o está en las trincheras o es muy dificil que tenga una visión real de como crece el projecto y se convierte en burocracia.

  4. Juan M Gómez dijo:

    Como apunta @JoseJuan yo también creo que el problema es que el desarrollo está en pañales. Concretamente carece de formalización. Si la tuviera, el perfil del arquitecto sería muy distinto, probablemente con un fuerte background matemático.
    A día de hoy, IMO un arquitecto que no baje al código (o lo genere), es un burócrata.

  5. La arquitectura del software es muy importante, pero los arquitectos de software no pueden estar separados de la programación, generalmente no pasa así y los que no saben o no les gusta programar se perfilan por la arquitectura y el resultado no es nada bueno.

  6. Empiezo por un amén … y aprovecho para agregar que no solo “los arquitectos” han hecho mucho daño, un daño aún mayor han hecho “las arquitecturas” o “modelos de desarrollo” donde se pretende que los programadores sean “monos” que no entiendan lo que sucede y solo hagan un trabajo repetitivo como en las pelis de Chaplin.

    Ojo!, que ver esto me ha costado años y el cambio de paradigma no fue fácil en mi caso; pero a día de hoy vuelvo a remarcar la importancia de las personas en un equipo y de poder trabajar con lo mejor de cada uno. Si una persona o equipo solo se dedica a definir “cómo” deben trabajar y “qué” deben usar otros equipos sin siquiera probarlo ellos en el entorno de negocio adecuado .. eso es un problema a futuro asegurado.

    Afortunadamente, estamos viendo estos problemas hoy y eso nos da margen para seguir teniendo trabajo en esta profesión (cambiando los paradigmas una vez más con algo que sabíamos desde 1990). Lamentable Refresh que hacemos cada cierto tiempo en nuestro sector :(

  7. Estrictamente, la arquitectura es diseño lógico, pero hecho a nivel de sistema, en lugar de a nivel de componente.

    Personalmente, creo que la arquitectura sí es útil. Una buena arquitectura puede resultar en mayor capacidad para soportar cambio (flexibilidad), mayor productividad en el desarrollo (ya que no es necesario reinventar la rueda y el desarrollo se enfoca en componentes que proveen funcionalidad específica), y mejor “mantenibilidad” (ya sé que no existe la palabra pero saben a qué me refiero).

    Lo que sin duda estoy de acuerdo, es que tener arquitectos alejados de los proyectos es receta segura para el fracaso, ya que la “arquitectura” pasa a ser un conjunto de dogmas que logran todo lo contrario del propósito: afectan la productividad del equipo, el desempeño del sistema y lo hacen frágil al cambio.

    El problema es que no hay suficientes arquitectos con los conocimientos y experiencia adecuados. Entonces, como hay pocos, y quieren ganar mucho porque se sienten muy buenos, pues hay que “desquitarlos” entre varios proyectos. Sería mejor tener “lead designers”, asignados a un proyecto y punto.

  8. Gracias a todos por lo comentarios, como siempre ayudan a entender mucho mejor el tema.

    Omar, la forma de trabajar que explicas en tu último párrafo es, en mi opinión, la mejor. Cuando el arquitecto tiene que “padecer” su propia arquitectura, es cuando mejores resultados se consiguen.

    José Juan, estoy de acuerdo contigo en que parte del problema es la juventud de esta disciplicina y en que lo de “arquitecturas emergentes” suele ser un poco utópico. Un poco de planificación “upfront” suele ayudar a que las cosas sean más fáciles.

    Juan M, no tengo muy claro que la solución sea una mayor formalización, sinceramente. Hasta ahora, un exceso de formalización en la parte metodológica ha sido más contraproducente que otra cosa, y en cuanto al perfil matemático… bueno, creo que la elección de una arquitectura u otra tiene que tener en cuenta factores muy difíciles de encorsetar dentro de la lógica matemática (equipo, producto, expectativas, etc.).

    Pedro, no sé cómo será en otros países, pero en España el problema no es tanto que los arquitectos cobren mucho dinero, sino que a cualquiera con unos años de experiencia, independientemente de sus conocimientos, se le considera arquitecto y se le pone a liderar equipos de gente sin formación. Supongo que a las empresas (especialmente a las cárnicas) les sale más rentable eso que formar buenos desarrolladores.

  9. @Juanma Si hay una solución total, es la formalidad. Lo demás son aproximaciones o ñapas xD

    “un exceso de formalización en la parte metodológica”

    Quizá me expliqué mal. Con formalizar me refiero a modelar matemáticamente el proceso de desarrollo de software o lo que es equivalente, un sistema que acepte requisitos formales y genere soluciones en base a esto. Por supuesto aún estamos muy lejos y ni siquiera está claro que se consiga (http://en.wikipedia.org/wiki/Automated_reasoning).
    El papel de dicho arquitecto sería traducir el requisito informal del cliente a uno que acepte el sistema (si lo pudiera hacer el cliente, no existiría el arquitecto). Útopico.

    El punto, es que es imposible predecir (sin un mecanismo de dicha formalidad) como va a ser a posteriori un proyecto complejo (por supuesto, tampoco se conseguiría “explorando” ;) ). Parece que el proceso de desarrollo de software (cambio de requisitos y demás) sigue la teoría del caos xD (http://es.wikipedia.org/wiki/Teor%C3%ADa_del_caos)

    Así que para mí, sí, hoy un arquitecto tiene que estar “en las trincheras”. O ser un total fuera de serie (T.Caos).

  10. Omar del Valle dijo:

    @Juanma Gracias a ti por regalarnos estos artículos..

    @Bruno, algún día tendrás que explicarme esa nueva visión que tienes :D aunque te adelanto que al igual que no creo que la “culpa” sea de los arquitectos, tampoco creo que sea de las “arquitecturas o modelos de desarrollo” sino del uso que hacemos de ellas, han pasado de una simple resolución a un problema a una moda en la que hay que usar lo último que salga.. (muchas veces, como bien dices, sin entenderlo) ;)

    Nos leemos..

  11. Uf, detengan las prensas y avisen al gang of four y a los cientificos en computación que el escritor de un blog cualquiera descubrió que la arquitectura de software no sirve! Pronto espero tu articulo en una revista de computer science y tú libro citado por otros artículos y usado como libro de texto en universidades del mundo. Un bloguero cualquiera anónimo descubrio los fallos de la arquitectura! El mundo jamas sera el mismo!

  12. Hola “alguien”,

    Gracias por dejar tu opinión, cualquier punto de vista, especialmente si es distinto al mío, es bienvenido en este blog.

    Tal vez no me haya explicado bien en el post; pero en ningún momento digo que la arquitectura de software no sirva para nada, más bien al contrario. Lo que digo es que no es posible crear una arquitectura de software adecuada si no se está participando activamente en la implementación de la misma.

    Si no estás de acuerdo en ese punto, estoy realmente interesado en conocer tus argumentos al respecto.

    Un saludo,

    Juanma

  13. La analogía de la arquitectura y los edificios es terrible para el software y son legión los acomplejados que cierran filas alrededor de esa idea.
    En mi modesta opinión el software se asemeja más a construir ciudades que a levantar edificios.
    Intentad construir una ciudad desde cero y cerrando todos los requisitos. Un edificio permanece practicamente durante toda su vida pero una ciudad cambia continuamente.

    Saludos y muchas gracias por compartir tus ideas.

  14. Yuri, yo también creo que la analogía entre software y arquitectura es peligrosa; me gusta el ejemplo de la ciudad que pones.

    Otro ejemplo que me gusta es el de la jardinería: no puedes predecir al 100% como crecerá una planta, pero puedes tener una idea general y luego irla podando según evoluciona hasta alcanzar el resultado que necesitas.

  15. Otro alguien dijo:

    Encuentro sumamente escueto el artículo, y es molesto cuando se explota un título llamativo para decir prácticamente nada, tanto que podría resumirse en: Un arquitecto que no está preparado como tal y/o que no se involucra en el proceso de desarrollo es contraproducente.

    “la arquitectura de software es algo demasiado importante para dejarlo en manos de los arquitectos” lololololol
    Amigo, poner eso en negritas no era necesario, por supuesto que le saltará a cualquiera que pase los ojos por ahí.

    Creo que debes tener más cuidado al tratar estos temas, siendo que van orientados gente inmersa realmente en el desarrollo. En un estudiante puede causar malos entendidos, y a un desarrollador avanzado da igual si en lugar del post le dices 2+2=4.

  16. William Valencia dijo:

    Lo que también perjudica a un proyecto (durante el diseño) es la falta de una disciplina o proceso arquitectónico que incluya la validación de la arquitectura propuesta. Existen varias técnicas de validación, pero básicamente las más utilizadas son las pruebas de concepto y las listas de verificación. Lógicamente los Arquitectos tendrán que trabajar con los usuarios, analistas, administradores de infraestructura, testers, etc. Por otra parte, es cierto el hecho de que algunas empresas de desarrollo mentalizan los proyectos como análogos de la ingeniería civil o la construcción, cuando en realidad es mas parecido a un cultivo, reutilizas componentes (semillas), preparas el terreno (ambientes), siembras (implementas), lo haces crecer (desarrollo iterativo) y cosechas (liberación del producto terminado). Todo depende del enfoque, la experiencia, y la actitud del equipo (del cual forma parte el Arquitecto) para lograr el fin esperado.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

*

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>