archivo

Archivo de la etiqueta: arquitecto software

Hay conocidos antipatrones como son “los arquitectos juegan al golf“, “los arquitectos no programan” o “diseñar por diseñar” que tienen como elemento común una brecha entre el equipo de arquitectos (y analistas orgánicos) y los programadores y como elemento secundario, pero no menos importante, una brecha en la visión de los objetivos del proyecto entre unos y otros.

Esa falta de comunicación, de entendimiento, se traduce en problemas.

André Bensoussan tuvo ambos roles en su trabajo dentro del área de desarrollo del sistema operativo Multics y resume en una cita esta situación: “Por regla general, un programador dice, ‘sí, pero…’ mientras que un diseñador dice, ‘sí, y…'”.

Y probablemente ambos perfiles tengan razón, siendo lo realmente interesante y útil alcanzar una solución donde converjan las opiniones de unos y las de otros.

En el antipatrón “los arquitectos no programan“, nos encontrábamos con que la organización consideraba que este tipo de perfil era lo suficientemente caro como para que participasen en el proceso de implementación del software, aunque sea como supervisores del trabajo que se está realizando o para resolver diferentes dudas que se encuentren los programadores en aspectos relacionados con el diseño o con la arquitectura.

Otra vertiente de ese antipatrón (que en muchos casos se produce de manera conjunta con la anterior) era el hecho de que los arquitectos prescindan o no den suficiente peso a la opinión de los analistas o programadores que van a tener que realizar el desarrollo.

Este antipatrón es una variante del anterior y se produce en alguna de las siguientes situaciones:

– El arquitecto aplica el antipatrón “arrojar al otro lado del muro“, es decir, ellos hacen lo que entienden que es su trabajo y después que sean los analistas y programadores los que se entiendan con el problema.

– Cuando se decide subcontratar el proceso de construcción, se envían las especificaciones y la arquitectura a utilizar y se vuelve a aplicar el antipatrón “arrojar al otro lado del muro”.

Defiendo absolutamente la posibilidad de que en una organización se pueda progresar horizontalmente de manera que técnicos que disfruten con la programación y con la ingeniería del software puedan tener la oportunidad de conseguir mejores condiciones laborales si su desempeño, experiencia y conocimientos les hace merecedores de ello.

Lo anterior es absolutamente compatible con una carrera profesional de índole más técnica orientada a la arquitectura del software.

Es posible que a un programador solo lo puedas vender dentro de un umbral precio/hora (es el reverso tenebroso de los proyectos tipo taxímetro o bolsa de horas), pero en proyectos donde prestas un servicio tener a desarrolladores altamente cualificados, motivados y productivos puede ser la diferencia entre ganar o perder dinero.

Un apunte: No hablo de sobredimensionar la cualificación de los equipos, ya que eso puede jugar incluso en contra del proyecto ya que puede provocar en algunos casos (proyectos de complejidad medio o baja) pérdida de motivación y de rendimiento, lo que unido a mayores costes, puede hacer que el proyecto no sea tan rentable como cabría pensar y encima tienes ocupado en el mismo a gran parte del potencial de tu organización.

Cuando el coste/hora y no la productividad es la que marca los pasos, se pueden llegar a tomar decisiones poco comprensibles como que arquitectos software o analistas orgánicos centren su esfuerzo en definir arquitecturas, frameworks o diseños y dejen a un lado el día a día de la programación.

Todos sabemos como evoluciona el mundo del desarrollo de software y eso hace que ese tipo de decisiones se consideren un antipatrón, ya que cuanto más alejado esté un arquitecto de la realidad de la codificación, más alejadas se encontrarán sus soluciones de las necesidades que pueda tener el equipo de programadores y el proyecto.

La creatividad desmesurada que nos caracteriza puede provocar que el arquitecto elija soluciones más teóricas (cuando no experimentales) que prácticas, alejando al proyecto del objetivo de simplicidad máxima que cumpla las expectativas del usuario. Este defecto lo tiene cualquiera que realice análisis, diseños o arquitecturas y empeora sensiblemente cuando se está alejado del día a día de los proyectos (un analista que no trata con usuarios y con sus problemas, tenderá a hacer soluciones más complejas).

Este antipatrón recibe el nombre de una canción infantil. Os la pongo tal cual:

Oh, The grand old Duke of York,
He had ten thousand men;
He marched them up to the top of the hill,
And he marched them down again.

And when they were up, they were up,
And when they were down, they were down,
And when they were only half-way up,
They were neither up nor down.

Como podréis ver describe simplemente la acción de subir una colina, para después volverla a bajar. Se considera como una metáfora del esfuerzo invertido de manera gratuita o innecesaria.

No obstante, este antipatrón, aunque en el fondo haga referencia a un esfuerzo de esas características, quiere hacer hincapié sobre todo en una de sus posibles causas.

De igual manera que roles de carácter funcional resultan de mucha utilidad como nexo de unión (que no intermediario) entre usuarios y equipo de proyecto, también es necesario destacar la figura de los arquitectos software y a más bajo nivel los analistas orgánicos.

En el caso de los primeros existe una visión más abstracta del comportamiento funcional del sistema de información y en el de los segundos existe una visión más abstracta de la arquitectura de la aplicación, en ambas situaciones se ve el bosque y no los árboles.

Es frecuente encontrarnos con proyectos donde alguno de los dos perfiles no interviene (cuando no los dos), dejando a los programadores (especialistas en la implementación) prácticamente todas las decisiones a nivel e ejecución de las especificaciones del usuario.

Esto suele provocar (de ahí la analogía con la metáfora de la canción de “El gran viejo Duque de York”) que determinadas decisiones, al tener una visión demasiado a bajo nivel de la aplicación, no busquen la solución más óptima y obligue a hacer esfuerzo de más o incluso a un esfuerzo innecesario.

Por tanto, lo que viene a decir este antipatrón es que equipos de proyecto descompensados entre visiones más abstractas y más concretas pierden productividad.

En muchas organizaciones dedicadas al desarrollo de software los arquitectos comparten tareas propias del proceso de producción y tareas de I+D+I. Salvo que la empresa sea minúscula no me parece un modelo recomendable ya que al final los arquitectos terminarán devorados por ese monstruo llamado día a día, dejando a un lado o dedicándole menos atención de la que sería recomendable a los procesos I+D+I, que son los que te van a permitir ser cada vez más competitivos.

No quiero que se entienda que el proceso de producción no es importante, antes al contrario, es lo más importante, pero no por ello se debe ignorar que la organización necesita evolucionar, mejorar, en servicios, en productos, en gestión y eso se consigue en parte gracias al I+D+I.

Por este motivo, mi recomendación es que exista una diferenciación entre los arquitectos del proceso de desarrollo que se encargarán del mantenimiento de la infraestructura de desarrollo actual y del soporte a la resolución de problemas que ocurran en el funcionamiento ordinario de los proyectos y de los arquitectos encargados del I+D+I que se tienen que encargar del desarrollo de nuevos productos o servicios, de la mejora de los ya existentes, ya sean tanto hacia afuera (hacia el mercado o los clientes) como hacia adentro (a la propia organización).

En función del tamaño de la empresa (también de la complejidad de los proyectos y de los clientes) podrán existir varios arquitectos en el proceso de producción. Si es así, debe existir coordinación porque de lo contrario cada uno hará la guerra por su cuenta y será más complicado que exista una visión coherente en las estrategias de desarrollo desde el punto de vista la arquitectura, lo que al final será menos productivo y no dará una imagen de coherencia y cohesión de la organización, sino que la visión real será la de muchas empresitas funcionando dentro de una más grande.

Por tanto, lo comentado en el párrafo anterior lleva a la necesidad de que exista un Departamento de Arquitectura, formado por los arquitectos software de la organización, personal que los coordine y personal de apoyo.

Por otro lado, también es recomendable la existencia de un departamento I+D+I en el que existan arquitectos pero con dedicación exclusiva (o casi) al mismo, de esta forma se minimizarán las interrupciones provocadas por las contingencias diarias de la producción del software para terceros.

La mayoría de los arquitectos software son creativos por naturaleza y preferirán trabajar en I+D+I, sin embargo su presencia en el día a día es fundamental, por lo que habrá que seleccionar qué perfiles son los más adecuados para trabajar en cada departamento, sin que ello deba suponer un obstáculo para que en un futuro puedan cambiar entre uno y otro.

Habrá productos o resultados del I+D+I que tengan influencia directa en el proceso de producción, por ese motivo también debe existir una coordinación entre ambos departamentos y no solo a nivel ejecutivo, sino también a nivel técnico, debiéndose designar los interlocutores necesarios entre ambos para que la comunicación, demandas, sugerencias, dudas, incidencias, etc… fluyan entre ellos.

Además de todo lo comentado, una de las ventajas de que existan Departamentos de Arquitectura y Departamentos de I+D+I es que permitirán una promoción profesional horizontal en la organización, de manera que determinados perfiles más técnicos puedan tomar otros tipos de responsabilidades sin necesidad de ir subiendo en la jerarquía clásica de las empresas de desarrollo de software, donde se asciende cada vez a puestos más funcionales y comerciales y donde muchos de estos perfiles que marcan la diferencia en lo técnico, terminan perdidos y ofreciendo un rendimiento muy por debajo de sus posibilidades.