Some Agile context

As Agile replaced waterfall methodology, project management was completely changed. Much of the old habits in which we delved were upset. Agile methodologies brought about new methods backed by common sense. Roles inside a software project were redistributed and traditional deadlines were removed.

Traditional waterfall project often suffers from a long development cycle and a blatant inconsistency between what was delivered and the current state of business needs. Agile does not only bring better communication, but also a quicker feedback loop. Both are essential to bringing a project as close as possible to its real purpose.



Wait! That's actually what Lean is about. A small feedback loop. Except that Lean adds something more by requiring the smallest possible set of work to fulfill requirements. In order to work this way, requirements also have to adopt a lean approach. Requirements have to be chopped down into unitary bits with evolution and functionality in mind.

Credits to Fred Voorhorst

Greenfield project

There comes a time when a developer is lucky enough to work on a greenfield project. These projects bring architectural challenges to developers, and challenges are good. Developers are challenged into building the best and most fitted architecture for business needs.

Building the best and most fitted architecture for business needs

3 different visions

There are usually three groups involved with software architecture: developers, architects, and business. Each has its own opinion on architecture.



Business brings requirements to the project. Business wants things to move forward. They want things to be planned as much as possible. Business wants to plan for the long-term.



Architects have a company-wide vision of technologies. From existing projects, existing experiences, to runtime constraints. They are usually involved in design choices before the project starts. They are concerned with making the right long-term design decision so as to ensure the project's sustainability. Making sure design decisions last is also a way for architects to work on new projects.



Developers are responsible for implementing the architectural design. They are committed throughout the project and work on it on a daily basis. Architectural decisions have a very big impact on their daily jobs. Developers want design decisions that will make their everyday lives simpler in terms of development, maintenance and debug.


Let's admit it: business needs are constantly changing. And that's a good thing! As said earlier, agility is all about reacting to changing business needs. In such an ever-moving context, how can we ask for a fixed and stable software architecture?

Business needs don't always change radically but instead evolve slowly. Architecture should follow business needs. A project's architecture should try to be adapted to business needs.

Big upfront design

The perspective of a well-crafted architecture is reassuring. It brings a false illusion of stability. The problem is that such an architecture has a cost and such an ivory tower must not fall apart simply because of petty business needs. After all, architecture is more important than business needs... not! Having a pet architecture can lead to wrong priorities. Business should come first when it comes to domain requirements.


Problem with an upfront design is that domain knowledge is at its smallest at the start of a project. So why make such important decisions at the worst possible moment?

Lean architecture

In order to avoid having those wrong priorities due to big upfront design that we won't want to throw away, we should not build big upfront design, to begin with.

Business is concerned with costs and architecture is a cost. That cost should not be spent entirely before the development phase. Actually, development and architecture should be intertwined with business evolutions.

Lean architecture is about building a sufficient technical solution. Such a solution should be simple and therefore not cost as much as an upfront design. Therefore, lean architecture gives way to adaptability.

Don't get me wrong, I'm not saying architecture should be cheap. Only that preparing a full and definitive architecture upfront is as much a bad decision as the waterfall is. Architects are only involved with these decisions made at the worst possible moment, whereas developers are committed to these decisions, which could possibly weigh them down as technical debt.

On the other hand, every change concerning architecture has its costs and should be measured. These decisions should be made alongside coding decisions. As with code refactoring, architectural refactoring should take place in a lean architecture. A clean separation from domain code can really help adapt a software architecture. Such a separation can be done using Hexagonal Architecture.

Domain Driven Design aims at focusing on the domain space over the technical space. Domain space is more important than technical concerns. This is why it should drive technical concerns and why these concerns should come as domain comprehension is clearer.

As with building an MVP, lean architecture doesn't mean that the architecture will change regularly, but out of necessity. Take cathedral architecture as an example. They are seldom like the original design. Actually, many cathedrals, which are built from the bottom up have differences in design and techniques as they are built. Depending on finance, user experience and evolution in techniques, these buildings are quite different from what the first architect imagined.



Stop making critical and hard to change decisions at the beginning of a project. The start of a project is the moment of greatest ignorance and making structural decisions at this time is probably the first mistake in a project. Postponing these decisions until necessary is wiser and can lead to better solutions.

As always, if you have any comment, please leave a message on the Disqus below.