De que hablo cuando hablo de #noArchitecture

Ha pasado ya cerca de un mes desde que publiqué mis ideas sobre #noArchitecture. Ha alcanzado las cien lecturas. ¡Muchas gracias! Nunca me hubiera imaginado llegar a cien lecturas. A la vez, en este periodo de tiempo, he charlado mucho acerca de esto y he ido recibiendo las primeras impresiones. Se pueden dividir en tres grupos principales:

  • La defensa de los modelos tradicionales, que hablan de que desde la arquitectura empresarial no se restringe, sino que se están dando soluciones bien conocidas y establecidas a problemas recurrentes.
  • La idea es buena, pero el modelo no vale. Que esto se tiene que hacer con gente buena y motivada, y de esa hay poca.
  • “De esto es lo que llevo yo diciendo desde hace tiempo”

Para ir aclarando estos de los puntos, y alguna otra cosa, voy a intentar explicar de que hablo cuando hablo de #noArchitecture.

Hablo de arquitectura empresarial

Si entendemos la arquitectura empresarial como “la organización fundamental de un sistema, representada por sus componentes, sus relaciones entre ellos y con su entorno, y los principios que gobiernan su diseño y evolución” (Definición del estándar ISO/IEC/IEEE 42010), debemos centrarnos justo en eso, en definir los principios y crear las infraestructuras necesarias para permitir la construcción de los productos software que permitan a negocio alcanzar sus objetivos. Se ha de abandonar, desde los departamentos de tecnologías de la información, paulatinamente, la responsabilidad sobre la construcción de los productos y las tecnologías específicas de cada uno de estos.

Y sobre todo se deberían ir dejando a un lado, paulatinamente, las ideas acerca de crear soluciones únicas para todos los productos software de la organización. Estas aproximaciones limitan las posibilidades específicas, eso que las hace especiales, de cada producto en aras de una homogeneización de los procesos y herramientas. Y esta homogeneización sólo aporta valor, y no siempre, a los departamentos de tecnología, no a las soluciones de negocio a desarrollar, por lo que se convierten en un limitante a la hora de construir software.

Arquitectura es todo aquello que es difícil de cambiar más adelante

Pero, todo esto no quita que la arquitectura es todo aquello que es difícil de cambiar más adelante. Y debe haber lo menos posible. Debemos progresivamente tender hacia un entorno en el que haya poca arquitectura para minimizar el impacto de los cambios de esta.

Todo esto ha de derivar un cambio orgánico en las empresas; en las responsabilidades de los departamentos de tecnologías de la información y las áreas de negocio que la componen.

Hablo de cambiar el modelo de las organizaciones

Como dice David Parra, “la manera que tenemos de trabajar está en momentos de crisis. Los principios que regían nuestro modo de trabajo ya no lo son más y los viejos pilares en los que nos sosteníamos para poder generar valor, cumplir expectativas quedan obsoletos a gran velocidad. Llevamos muchos años trabajando con las prioridades equivocadas. Es nuestra obligación adaptarnos”.

Las empresas son empresas de software

¿Y en que debe consistir esta adaptación? En conseguir que las unidades de la organización sean conscientes de que las empresas son empresas de software, da igual que sean empresas fullstack o interface owners, el hecho es este. Las empresas son empresas de software. Por tanto el valor que produce una unidad o departamento está directamente relacionado con la calidad del software que produce, porque el software es el facilitador del negocio, y eso ha de hacerles directamente responsables de su producción. Y eso sólo puede ocurrir cuando los departamentos de negocio sean propietarios de los procesos de diseño y construcción, de sus costes y mantenimiento. Y para que esto ocurra han de ser dueños de las decisiones sobre dicho software, tanto funcionales como tecnológicas.

A día de hoy las empresas son empresas de software. Fullstack o interface owners, pero empresas de software

Otra de las implicaciones es que los departamentos de TI han de dejar de ser los propietarios del desarrollo del producto. Por tanto han de limitarse a definir los principios que rijan los procesos de producción y explotación, así como la gestión de las operaciones de TI.

Todo esto simplemente tiene que ver sobre como se organizan las funciones y responsabilidades, pero no implica la desaparición ni de tareas ni de responsabilidades, solo de su cambio de emplazamiento en la organización.

Hablo de que el software lo hacen las personas

Es evidente que el software lo hacen las personas. Es única y exclusivamente un proceso de diseño. Y el manifiesto ágil ya nos ha enseñado que son las personas, sus responsabilidades y sus relaciones las que permiten alcanzar los objetivos de negocio. Pero no hay que quedarse simplemente en agile. “If the waterfall model risks not building the right product, then agile risks not building the product right.@janl

Los equipos de desarrollo se han de responsabilizar de todo el ciclo de vida de las aplicaciones que construyen

Hay que dar un paso más. La cultura organizativa ha de trasladarse hacia nuevos modelos de software delivery, en los que se implanten filosofías you build it you run it. Es decir, los equipos de desarrollo se han de responsabilizar de todo el ciclo de vida de las aplicaciones que construyen.

Y la implantación de un modelo organizativo basado en #noArchitecture busca justamente eso: marcar los estándares que habiliten modelos de delivery automáticos, definir estándares para facilitar la interoperabilidad entre las diferentes aplicaciones y sistemas, y habilitar mecanismos y herramientas para permitir a los equipos gestionar el ciclo de vida de sus aplicaciones.

Y de que no hablo cuando hablo de No Architecture

No hablo de :

  • Que la organización se convierta en un grupo de silos de desarrollo aislados. Que no se creen reinos de taifas.
  • Que no pueda haber estándares transversales a la organización. Para eso se promoverán los consejos tećnicos, etc. No pueden desaparecer completamente los elementos corporativos, pero han de reducirse al mínimo.
  • Que los la producción de software vaya a ser más barata. Lo que va a ocurrir es que ahora los costes de cada producto van a repercutir directamente en cada línea de negocio. Y se podrá tener mayor control sobre los costes de IT.
  • Que no exista arquitectura de aplicaciones. Lo que no existirá es una única arquitectura. Existirán diferentes arquitecturas con el fin de adecuarse a las necesidades concretas de cada aplicación.
  • Que no exista arquitectura de información. Cosa que curiosamente no está muy implantada en la actualidad.