Get best of the week

Agile nos enseña el verdadero significado de la arquitectura

imagen

¿Qué es la arquitectura? ¿No ciudades o edificios, sino una versión organizativa: arquitectura empresarial, arquitectura de soluciones, arquitectura de aplicaciones, arquitectura de software, arquitectura empresarial, arquitectura de infraestructura? Los pelos de mi cabeza comienzan a moverse cuando nosotros, arquitectos, pasamos a este tema desde nuestra molesta torre de marfil, creada para la reflexión, que divierte nuestro orgullo. Pero esta vez tengo que tocar este tema, ya que es un requisito previo para considerar el tema de la deuda (arquitectónica, técnica) y la arquitectura, todos juntos se convertirán en una historia de tres artículos.

Ágil y lo que dice sobre arquitectura


La arquitectura se menciona oficialmente en el Manifiesto Ágil , que establece que uno de los principios fundamentales es: "Las mejores arquitecturas, requisitos y decisiones de diseño nacen en equipos autoorganizados".
Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados.
(De: Los Principios del Manifiesto Ágil )

El problema no es solo que no da una definición de qué es la arquitectura, sino solo de dónde viene, sino también que es bastante ingenua .

Agile no solo tiene partidarios serios (y me considero uno de ellos), sino también una buena cantidad de fanáticos que tienden a creer (y a veces obligan a su liderazgo a creer) que "trabajar en agile" te da una habilidad infinita para cambiar y que puede hacer todo tipo de cambios , incluidas grandes conversiones. Incluso tenemos marcos bastante grandes como el Scaled Agile Framework (SAFe), que se puede aplicar para cambios basados ​​en principios flexibles para los niveles estratégicos más altos.

Tales marcos tienen algo en común con los marcos integrales que se crearon anteriormente (FEAF, MODAF, TOGAF, etc.). Nadie realmente usa todo el asunto. El alcance de los marcos generalmente no es fácil de entender para todos aquellos que trabajan en su contexto limitado. Me parece que los fundamentos de las prácticas laborales actuales se han extrapolado para crear un marco completo. Aunque el "relleno" nunca se ha probado, sin embargo, todo se vende por completo como "mejor práctica".

Veamos TOGAF y SAFe, están firmemente basados ​​en el mundo del desarrollo de aplicaciones. Esto es evidente cuando TOGAF basa una de sus dos definiciones de arquitectura en la definición de arquitectura de software ISO.
– , , .
(: ISO/IEC/IEEE 42010:2011)

O, cuando SAFe nos dice que hay características y habilitadores, y uno de los habilitadores es "infraestructura" (aunque, por supuesto, puede abstraer este concepto). Los marcos a menudo son un poco pesados ​​en definiciones y detalles, intentan ser exhaustivos. Por lo tanto, a menudo crecen con el tiempo para definir y aceptar cada vez más. Pero los marcos grandes generalmente se usan solo parcialmente, porque el marco completo en la mayoría de las situaciones es un exceso burocrático. Lo que a menudo se ve en la "enfermedad de la definición", el deseo de crear definiciones estrictas para todo, incluso para las cosas que ignorarán tales definiciones en la realidad ( Ludwig Wittgenstein ).

Si bien los marcos grandes se pueden ver con un ojo crítico, el concepto Agile en sí mismo (aunque no es nuevo) es de hecho una respuesta muy práctica (al menos en parte) a la complejidad y, sobre todo, a la variabilidad. Ágil es la reacción a la mayoría de los cambios y transformaciones en las organizaciones complejas de hoy. Complejidad porque TI permitió ser complejo . Variabilidad, porque en comparación con las fábricas llenas de equipos pesados, la TI es bastante fácil de cambiar. Sigue siendo software e incluso hardwareno tiene una vida útil como, por ejemplo, las paredes de un edificio. Las organizaciones complejas de hoy producen cambios más autónomos que las organizaciones "de papel" del pasado. La cascada con Big Up-Front Design (BUFD) se ha vuelto tan poco práctica que en el mundo actual con una carga de TI, se ha vuelto casi imposible. Por lo tanto, obtenemos una evolución paralela masiva permanente en nuestras organizaciones sobre la base de muchos equipos (ágiles) que trabajan en paralelo.
, - . - , , , . - — , — .
( , )



Como dije anteriormente, las discusiones sobre "Qué es la arquitectura" suelen ser un desperdicio de energía; es mejor gastarlo en desarrollar buenas soluciones de diseño para su organización. Hay muchas definiciones de arquitectura, he indicado las más utilizadas anteriormente. Hay otra definición en Mastering ArchiMate, y admito que en parte me gusta: la

arquitectura empresarial se trata de comprender todos los diferentes elementos que componen una empresa, y cómo estos elementos están interconectados.

Esto es de Institute for Enterprise Architecture Developments. No es que no esté de acuerdo con todo lo que escriben, pero esta "O" no dice "Cómo" por alguna razón. Y "Entender" es una palabra igualmente resbaladiza. Entonces todo esto realmente no te ayuda. Existen muchas otras definiciones, del MIT, el gobierno de los EE. UU., Etc. Una de ellas de la Fundación ArchiMate: “Un conjunto acordado de principios, métodos y modelos que se utilizan en el diseño e implementación de la estructura organizativa de una empresa, procesos comerciales, sistemas de información e infraestructura. ".

Pero la definición que se ajusta a mis propios sentimientos fue que Martin Fowler, en su conocido artículo de 2003, " ¿Quién necesita un arquitecto?"". Allí, termina de definir la arquitectura como "cosas que son difíciles de cambiar". Esto no es diferente de la definición de Grad Buch, quien dijo:

Toda la arquitectura son decisiones de diseño, pero no todas las decisiones de diseño son arquitectura. La arquitectura representa decisiones importantes que forman un sistema donde la importancia se mide por el costo del cambio.

(Nota: una cita más completa tiene un buen punto sobre "ciencia y arte"). También creo firmemente que, después de todo, la arquitectura no es más que decisiones de diseño, y que el deseo de separarlas realmente viene en parte de "[el deseo] de hablar sobre decisiones de diseño, pero [querer] inflarlas para que sonaban importantes ”(Fowler). Entonces, en nuestro mundo de la arquitectura, podemos decir:La arquitectura es decisiones de diseño que son difíciles de cambiar . Por supuesto, es realmente difícil cambiarlos solo cuando se implementaron. El documento aguantará todo, y las letras cambiarán fácilmente (a menos que estés en una discusión arquitectónica infernal de 6 meses). Pero la arquitectura, como medida de la importancia de las decisiones de diseño, es una buena definición, y mucho mejor que en ISO, ArchiMate, TOGAF, etc.

Sin embargo, existe una sutileza con la característica "difícil de cambiar".

Suponga que tiene una solución de diseño que describe a sus desarrolladores cómo deben estructurar su código Python. Si tiene mucho código, tomará mucho trabajo cambiar todo este código de una estructura a otra. En otras palabras, es difícil. Por lo tanto, esta solución elegida es "arquitectura", en este caso, arquitectura de software. Pero un desarrollador puede ignorar fácilmente esta decisión y escribir código que haga las cosas de manera diferente. Al final, hacer "cambios" al software es fácil. Aunque es difícil cambiar toda la arquitectura implementada, a menudo es bastante fácil cambiar solo partes individuales en ella (ver Ralph Johnson arriba). La arquitectura, por lo tanto, es algo "pesado" que consiste en muchos "ligeros". Lo ves en todos los niveles, por ejemplo,si su decisión de diseño es usar solo bases de datos Oracle, y de repente, aparecen bases de datos PostgreSQL separadas que son bastante fáciles de configurar y, por lo tanto, aparecen fácilmente (lo que hace que su paisaje sea más complejo, por lo general esto no está aprobado). Pero reemplazartodo Oracle en PostgreSQL en su paisaje es pesado (y esto puede no ser del todo factible). Por lo tanto, se forma la siguiente definición:

Arquitectura: decisiones de diseño que son difíciles de eliminar por completo de las implementaciones.

(Aunque la contracción de Fowler es "difícil de cambiar" en la mayoría de los casos). Otro comentario con respecto a los "difíciles de cambiar", puede ser difícil eliminarlos debido a la dependencia de otros, por lo tanto, el significado de la palabra "implementación" es amplio, por ejemplo, cambiando tanto a los fabricantes como a los consumidores del servicio. "Pesado" siempre debe considerarse desde la perspectiva de su organización, un buen ejemplo de por qué el área de la arquitectura suele ser más amplia que el área de una solución, proyecto o producto.
Nota: 1) Esta definición no depende de TI. 2) Se puede argumentar que de esta manera revelé el significado de la palabra "fundamental" en la definición de "Arquitectura" según ISO.

Ágil y arquitectura, diferentes extremos de la misma escala.


Resulta una relación muy interesante entre el mundo de Agile y el mundo de la arquitectura. Agile está diseñado para hacer los cambios lo más posible, para que los cambios sean fáciles (o al menos no difíciles ). Y por otro lado: la arquitectura, como hemos notado, es donde los cambios son difíciles . En otras palabras, están en los extremos opuestos del espectro; son un giro fundamental en su organización.

Apoyo a Agile y declaro que esta es la mejor manera de realizar cambios en nuestros complejos entornos empresariales cargados de TI. Pero eso significa que todo lo que encontramos que es difícil de lograr usando enfoques ágiles es la "Arquitectura" de facto. Entonces Agile nos enseña qué es la arquitectura .

Nota: Es importante tener en cuenta que Agile toma mucho de Lean, que se basó en el enfoque de Toyota a las plantas físicas. Toyota quería que la producción fuera más flexible para hacer frente a la complejidad. Pero hay muchos aspectos de esta configuración que no se traducen fácilmente en el mundo de software de sílex. Por ejemplo, Toyota admite una variabilidad muy limitada, y la mayoría de las cosas no pueden cambiar. En el software, todo puede cambiar, y no es cierto por definición que un método que (ligeramente, pero con gran efecto) sub-optimizado el proceso de producción física pueda ser la base de otro proceso de producción.

Entonces, ¿dónde encontramos la arquitectura, dónde se mete Agile en problemas? Hay varios ejemplos obvios:

  1. feature/defect «», , . ( , , ESB ), . , . , , ( ), .
  2. Agile , , YAGNI (You Ain’t Gonna Need It) (just in time). SAFe Architectural Runway, features defects. SAFe , . SAFe « Runway», features «». YAGNI ( , «»). – , – . , , Agile , « , DevOps» (DRDC). , , Tomcat, JBoss, Session state storage , File sharing, Redis, MongoDB, MQ, IIS .. Lean ( ) YAGNI, , , «» («muda» « » Lean). , , , , ( «muru» «»). , , Runway , , .
  3. Agile , . , , , . , , Agile ( «muri» «»). , . Agile ( : ...) – .

Pido disculpas por usar libremente los términos japoneses aquí. Por lo tanto, Agile se enfoca en el hecho de que la Arquitectura es un objeto, no una práctica, pero la mente dice que: La

Arquitectura es cada decisión de diseño implementada que hace que Agile sea difícil.

La elección de lo que pones en tu "Plan de expansión de pista" depende de lo difícil que será realizar la transformación: esta es la elección de la arquitectura. Y no puede dejarlo solo a los propietarios de productos bajo la presión de los usuarios. La elección también debe hacerse con la participación de las partes interesadas de la arquitectura, por lo que hay controles y equilibrios contra "bunkers" y "a corto plazo". Más sobre arquitectura (como práctica) en la segunda parte de esta mini-serie de artículos.

Definir la arquitectura como una combinación de "cosas pesadas" no es todo lo que necesitamos. Porque además de ser "difícil", necesitamos algunas recomendaciones sobre qué luchar con la arquitectura. A menudo se dice que la idea de la arquitectura es proporcionar flexibilidad creando soluciones flexibles. De hecho, Fowler declaró que la tarea del arquitecto es eliminar la arquitectura. Pero es muy simple. La flexibilidad suele ser costosa, y estos "costos" (tiempo y dinero) no pueden aumentar indefinidamente (ver Johnson arriba). Todos quieren que las soluciones sean completamente flexibles, pero no es barato (y nadie quiere pagar las facturas), no es rápido y ni siquiera es posible. A veces la situación es simple: tienes que tomar decisiones que serán difíciles de cambiar, no puedesadmite todas las opciones (por ejemplo, al elegir una plataforma, no puede admitir todo). Por supuesto, si la elección no es muy costosa, elija soluciones flexibles o posponga la opción el mayor tiempo posible (como sugiere SAFe: no limite sus opciones). Pero en la práctica, a menudo hay que tomar una decisión. Una elección que será difícil de cambiar es una elección arquitectónica. La arquitectura busca minimizar la inflexibilidad innecesaria, porque es ingenuo pensar que habrá un mundo donde todos los cambios sean fáciles y no haya nada difícil. Hay cosas no menos importantes, y más a menudo incluso más importantes que la flexibilidad. Creo que hay tres de ellos: Fiabilidad, Eficiencia y Flexibilidad - Robustez, Eficiencia, Flexibilidad (REF).

Obtenga más información sobre REF, práctica de arquitectura y deuda.en la segunda parte, pero recordé el video "Por qué arquitectura empresarial", que creamos hace muchos años, en el momento en que hicimos la arquitectura más flexible del mundo de BUFD:


Escuche a su médico y abogado.


Y en conclusión, la arquitectura (como un objeto) es lo que es "pesado", pero también se puede decir que "la arquitectura (como práctica) es pesada". Están estrechamente relacionados, la arquitectura (como práctica) es difícil, porque la complejidad actual dificulta el cambio y la inconstancia actual hace que el cambio sea poderoso. Es por eso que tienes que pagar buenos arquitectos de megabytes. Bueno, tal vez no , pero definitivamente debes escuchar a los buenos arquitectos y tomar sus consejos muy, muy en serio. Solo queda una pregunta simple: ¿Cómo reconocer a un buen arquitecto?

More articles:


All Articles