La semana pasada hablaba con un cliente cuando descubrí los dos anti-patrones relacionados a arquitectos de software. Ideas que venían dando vuelta en mi cabeza y que había visto reiteradas veces pero recién en esa charla hice click y logré articularlas. Paso a describir.

Cuando digo «anti-patrones» me estoy refiriendo patrones, situaciones que he visto una y otra vez y que en todos los casos que vi tuvieron resultados negativos.

Arquitectos que «no se embarran»: este tipo de arquitecto suele tomar decisiones y «bajar línea», posiblemente hace diagramas, escribe lineamientos y en algunos casos hasta puede llegar a escribir código de una librería o código genérico. Pero lo que lo destaca es que no «sufre» sus propias decisiones: dice «hay que usar este framework» pero él no lo usa, dice hay que hacer las cosas de tal forma pero el no las hace. Esta situación suele derivar en que sus decisiones/lineamientos resultan inconvenientes no porque no resuelvan el problema que pretendían resolver sino porque resultan muy incómodas de aplicar para los desarrolladores y en un punto lo desarrolladores empiezan a ignorarlas (si es que en algún momento las respetaron). Este tipo de arquitectos no suele trabajar en un equipo de desarrollo sino que suele estar en una área de arquitectura que opera de forma transversal a todos los equipos de desarrollo.

Arquitectos infractores: la organización tiene ciertos lineamientos sobre la forma de trabajo, por ejemplo: cada equipo tiene un backlog, planifica cada 2 semanas, hace retrospectivas, su código tiene que tener pruebas automatizadas y una cobertura por encima de cierto porcentaje. Pero resulta que este arquitecto (o el equipo entero de arquitectura) incumple los lineamientos que todos los equipos de desarrollo deben cumplir. Esto tiene múltiples consecuencia como ser falta de visibilidad, falta de credibilidad y resistencia por parte de los desarrolladores (¿por qué yo tengo que hacer esto y ellos no?)

¿y tu?, ¿te haz cruzado con arquitectos así?