Agile Architecture in "large" systems

Tuesday, December 12th we had a Open Space knowledge session and one of the Open Spaces we had was about Agile Architecture in "large systems".
The question was how to do architecture: should there be any in the beginning or should it "evolve"? The answer we came up with is not very surprising, it is that a base architecture is needed, but the size of it is variable and the architecture shouldn’t be static but evolve.
The way we came to that conclusion is interesting however. During the discussion, in which a lot of views were expressed, we came up with a list of good old, much used, words, that everyone agreed on are needed. Based on those words we came to the conclusion as stated above.
This blog will list the words on which we based our conclusion, with an explanation on how we arrived at the conclusion.

At the start of the discussion we talked about the meaning of the word Architecture and we came to the conclusion that there are many different layers of architecture: enterprise, domain, system, application and probably even more. We tried to be as generic as possible in our discussion and we tried to map all the words we came up with to all the layers of architecture we thought of.
The words: (not in order of importance, but in order in which they came up in the discussion)

• • Conceptual Integrity
    An architecture should always have conceptual integrity. This make everything in your architecture understandable and maintainable. But to have conceptual integrity, you should at least have talked about what is going to be the “standard” for which part, based on the architecture layer. So for application architecture this could mean that you specify a way to format the code, and the layers used (web, service, data) and so on. With this in mind some architecture is needed before a project start. It could also just be: we will use what will come out of the first project, as long as that it is clear to everyone on that specific architecture layer how things are done.

• • Vision
    A visionary is needed on all levels of the architecture. These visionaries are there to communicate the vision and make sure that the vision isn’t stale. The world isn’t stale, so the vision should not be stale. New insights should be included in the vision. This is not the same as a reference architecture. Those are usually very strict in how to do things. This is (based on the architecture layer) more someone that has the big picture, knows how everything fits in and can make sure that the big picture doesn’t become the “holy blah blah¨ (something big and not understandable).
    This means that the vision is needed from the start, but it can be small (the world then is small). This vision needs to evolve and grow as the world around it also grows.

• • Spike / POC
    Architecture ideas should always be tested before using them. A way to do that is to use a Spike (XP practice, it is like a half-day Proof Of Concept address ing just one problem). Spikes provide feedback that help evolve the architecture.

• • Keep options open
    This one is an easy one, but also easily forgotten: make the architectural “heavy” decisions as late as possible. If you do that, you have multiple options and you are not tightly bound to one solution. This means that if requirements, vision or something else changes that influences the architecture, that you are “agile” and can respond to them.
    This boils down to: Decide as late as possible, but no later! (a special blog post that will go in to this statement will come later)

• • Just enough
    Especially in the Java world we tend to overdo the architecture and make things unnecessary complex. In the discussion we came up with the “just enough” statement to counter this. This also adheres to the lean eliminate waste principle.
    This means that the architecture should always be just enough, not only at the start of the project, but also during.

• • Modularity
    If the architecture is modular, each module can be changed independently, without heavy impact on other parts of the architecture. The modules don’t have to be defined in the beginning of the project, these modules can evolve during the life cycle of a system or project. The “Vision” should adapt or lead in these architecture decisions.

• • Adapt
    One common thing that is already mentioned in some form in the words already described above is adaptation. To be agile, you need to be able to adapt, so the architecture also needs to be adaptable. A lot of words covered here are meant to be a way to do just this, but it still needs to be done. That is the reason this word is also defined in our discussion.

• Technology
  Technology decisions can really influence the architecture. When a specific technology is chosen, it needs to be up to realize the requirements and the choice should be maintained. Since as soon as you choose a technology and started working with it, it becomes harder and harder to migrate. Changing technology could mean redoing everything done so far. This calls for the “Keep Options Open” statement that is already made. This goes double for technology decisions and be sure to do “Spikes” as mentioned before, to be sure you choose the right technology. If you keep technology decisions on the lowest architecture level where they are possible, you can be more sure that the correct choice is made, because the people working with the technology can do the spike, maintain it and they know if something is able of covering the requirements or not.

Based on the "Conceptual Integrity" and "Vision" needs, we need a "Just Enough" architecture in the beginning of the project on all architecture levels and that architecture should evolve during the project and the life cycle of the software.

I hope you are inspired or happy that we confirmed they way you were already thinking… 😉
Comments are welcome.