Get best of the week

Agile teaches us the true meaning of Architecture

image

What is architecture? Not cities or buildings, but an organizational version: enterprise architecture, solution architecture, application architecture, software architecture, business architecture, infrastructure architecture? The hairs on my head begin to move when we, architects, turn to this topic with our annoying ivory towers, created for thought that amuse our pride. But this time I have to touch on this issue, because it is a prerequisite for considering the topic of (architectural, technical) debt and architecture, all together will become a story of three articles.

Agile and what he says about Architecture


Architecture is officially mentioned in the Agile Manifesto , which states that one of the fundamental principles is: “The best architectures, requirements and design decisions are born in self-organizing teams.”
The best architectures, requirements, and designs emerge from self-organizing teams.
(From: The Agile Manifesto Principles )

The problem is not only that it does not give a definition of what architecture is, but only where it comes from, but also that it is rather naive .

Agile has not only serious supporters (and I consider myself among them), but also its fair share of fanatics who tend to believe (and sometimes force their leadership to believe) that “working on agile” gives you some kind of infinite ability to change and that you can make all kinds of changes , including big conversions. We even have fairly large frameworks such as the Scaled Agile Framework (SAFe), which can be applied for changes based on flexible principles for the highest strategic levels.

Such frameworks have something in common with the comprehensive frameworks that were created earlier (FEAF, MODAF, TOGAF, etc.). Nobody really uses the whole thing. The scope of frameworks is usually not easily understood by all those who work in their narrow context. It seems to me that the foundations of current working practices have been extrapolated to create a complete framework. Although the “filler” has never been tested, nonetheless, everything is entirely sold as “best practice.”

Let's look at TOGAF and SAFe, they are firmly based on the world of application development. This is evident when TOGAF bases one of its two architecture definitions on the definition of ISO software architecture .
– , , .
(: ISO/IEC/IEEE 42010:2011)

Or, when SAFe tells us that there are features and enablers, and one of the enablers is “infrastructure” (although you can, of course, abstract this concept). Frameworks are often a little heavy in definitions and details, they try to be comprehensive. Therefore, they often grow over time to define and embrace more and more. But large frameworks are usually only partially used, because the full framework in most situations is a bureaucratic excess. What is often seen in the “disease of definition”, the desire to create strict definitions for everything, including for things that will ignore such definitions in reality ( Ludwig Wittgenstein ).

While large frameworks can be viewed with a critical eye, the Agile concept itself (though not new) is indeed a very practical answer (at least in part) to complexity and, above all, variability. Agile is the reaction to most of the changes and transformations in today's complex organizations. Complexity because IT allowed to be complex . Variability, because compared to factories full of heavy equipment, IT is pretty easy to change. It is still software , and even hardwaredoes not have such a service life, for example, as the walls of a building. Complex organizations today produce more autonomous changes than the “paper” organizations of the past. The waterfall with Big Up-Front Design (BUFD) has become so impractical that in today's world with an IT load, it has become almost impossible. Thus, we get permanent mass parallel evolution in our organizations on the basis of many (Agile) teams working in parallel.
, - . - , , , . - — , — .
( , )



As I said above, discussions about “What is architecture” are usually a waste of energy, it is better to spend it on developing good design solutions for your organization. There are many definitions of architecture, I have indicated the most widely used ones above. There is another definition in Mastering ArchiMate, and I admit that I partly like it:

Enterprise architecture is about understanding all the different elements that make up an enterprise, and how these elements are interconnected.

This is from Institute For Enterprise Architecture Developments. It’s not that I don’t agree with everything that they write, but still this “O” doesn’t say “How” for some reason. And “Understanding” is an equally slippery word. So all this doesn’t really help you. There are many other definitions, from MIT, the US government, etc. One of them from the ArchiMate Foundation: “An agreed whole of principles, methods and models that are used in the design and implementation of the organizational structure of an enterprise, business processes, information systems and infrastructure ".

But the definition that fits with my own feelings was that Martin Fowler, in his well-known 2003 article, “ Who needs an architect?". There, he finishes defining architecture as “things that are hard to change.” This is no different from the definition of Grad Buch, who said:

All architecture is design decisions, but not all design decisions are architecture. Architecture represents important decisions that form a system where importance is measured by the cost of change.

(Note: a more complete quotation has a good point about “science and art”). I also strongly believe that architecture is, after all, nothing more than design decisions, and that the desire to truly separate them comes in part from “[the desire] to talk about design decisions, but [wanting] to inflate them so that they sounded important ”(Fowler). So, in our world of architecture, we can say:Architecture is design decisions that are hard to change . Of course, it is really hard to change them only when they were implemented. The paper will endure everything, and letters will easily change (unless you are in a 6-month-old hellish architectural discussion). But architecture, as a measure of the importance of design decisions, is a good definition, and much better than in ISO, ArchiMate, TOGAF, etc.

However, there is a subtlety with the “hard to change” characteristic.

Suppose you have a design solution that describes for your developers how they should structure their Python code. If you have a lot of code, it will take a lot of work to change all this code from one structure to another. In other words, it's hard. Therefore, this chosen solution is “architecture”, in this case, software architecture. But one developer can easily ignore this decision and write code that does things differently. In the end, making “changes” to the software is easy. Although it is difficult to change the entire architecture implemented, it is often easy enough to change only individual parts in it (see Ralph Johnson above). Architecture, therefore, is something "heavy" that consists of many "light". You see it at all levels, for example,if your design decision is to use only Oracle databases, and all of a sudden, separate PostgreSQL databases appear that are fairly easy to set up and therefore easily appear (which makes your landscape more complex, this is usually not approved). But replaceall Oracle on PostgreSQL in your landscape is heavy (and this may not even be entirely feasible). Therefore, the following definition is formed:

Architecture - design decisions that are difficult to completely remove from implementations.

(Although Fowler’s contraction is “hard to change” in most cases). Another remark regarding “hard-to-change” ones, it can be difficult to remove them due to dependence on others, therefore the meaning of the word “implementation” is wide, for example, changing both manufacturers and consumers of the service. “Heavy” should always be considered from the perspective of your organization, a good example of why the area of ​​architecture is usually wider than the area of ​​a solution, project or product.
Note: 1) This definition is not IT dependent. 2) It can be argued that in this way I revealed the meaning of the word "fundamental" in the definition of "Architecture" according to ISO.

Agile and Architecture, different ends of the same scale


It turns out a very interesting relationship between the world of Agile and the world of Architecture. Agile is designed to make changes as possible as possible, to make changes easy (or at least not difficult ). And on the other hand: Architecture, as we have noticed, is where changes are hard . In other words, they are at the opposite ends of the spectrum; they are a fundamental swing in your organization.

I support Agile, and declare that this is the best way to make changes to our IT-loaded complex business landscapes. But that means that all that we find that is hard to achieve using Agile approaches is the de facto “Architecture”. So Agile teaches us what Architecture is .

Note: It is important to note that Agile takes a lot from Lean, which was based on Toyota's approach to physical plants. Toyota wanted to make production more flexible to cope with complexity. But there are many aspects of this setup that are not easily translated into the flint world of software. For example, Toyota supported very limited variability, and most things could not change. In software, everything can change, and it is not true by definition that a method that (slightly, but with great effect) sub-optimized the physical production process may be the basis for another production process.

So where do we find architecture, where does Agile get into trouble? There are several obvious examples:

  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 ( : ...) – .

I apologize for freely using Japanese terms here. Thus, Agile focuses on the fact that Architecture is an object, not a practice, and the mind says that:

Architecture is every implemented design decision that makes Agile difficult.

The choice of what you put in your “Runway expansion plan” depends on how hard it will be to make the transformation: this is the choice of architecture. And you can’t just leave it to product owners under pressure from users. The choice should also be made with the participation of architecture stakeholders, so there are checks and balances against “bunkers” and “short-term”. More about architecture (as a practice) in the second part of this mini-series of articles.

Defining architecture as a combination of “heavy things” is not all we need. Because besides being “hard”, we need some recommendations as to what to strive for with architecture. It is often said that the idea of ​​architecture is to provide flexibility by creating flexible solutions. In fact, Fowler stated that the architect’s task is to remove the architecture. But it is too simple. Flexibility is usually costly, and these “costs” (time and money) cannot increase indefinitely (see Johnson above). Everyone wants the solutions to be completely flexible, but it's not cheap (and no one wants to pay the bills), it's not fast, and not always even possible. Sometimes the situation is simple: you have to make choices that will be difficult to change, you cannotsupport all options (for example, choosing a platform, you cannot support everything). Of course, if the choice is not very expensive, then choose flexible solutions or postpone the choice for as long as possible (as SAFe suggests: do not limit your options). But in practice one often has to make a choice. A choice that will be difficult to change is an architectural choice. Architecture seeks to minimize unnecessary inflexibility, because it is naive to think that there will be a world where all changes are easy and there is nothing difficult. There are things no less important, and more often even more important than flexibility. I think there are three of them: Reliability, Efficiency and Flexibility - Robustness, Efficiency, Flexibility (REF).

Learn more about REF, architecture practice and debt.in the second part, but I remembered the video “Why enterprise architecture”, which we created many years ago, at the time when we made architecture the most flexible in the world of BUFD:


Listen to your doctor and lawyer


And in conclusion, architecture (as an object) is that which is “heavy”, but you can also say that “architecture (as a practice) is heavy”. They are closely related, architecture (as a practice) is difficult, because today's complexity makes change difficult, and today's inconstancy makes change powerful. That's why you have to pay good megabyte architects. Well, maybe not , but you should definitely listen to good architects and take their advice very, very seriously. There is only one simple question left: How to recognize a good architect?

More articles:


All Articles