Does Software Architecture Modeling on the start of the project considered as an Agile Aproach?

Question

I am used to making an architecture plan during the start of the project. In an Agile Process it seems that the architecture are being done or improved during the iterations.

Answer 1

Technically an architecture should cross over iterations as an architecture says this is how we will scale or this is how we will do communication, etc. During developement you only build what you need for that iteration. If you don't need to scale you don't include that part of the architecture into your project. As part of Agile is to use tests, if you need to revisit that code later to make it scale, then whilst it will include rework, you should have the confidence to make those changes and to the current architectural recommendations for scaling.

Answer 2

It depends, you need to have a vague idea of where you're going in order to get there, so you can start with a Walking Skeleton and flesh out in the individual parts as you go, but equally you don't want to make decisions too soon. So you may start with an architecture diagram which contains certain entities, but you don't specify their concrete implementation until you've evaluated each one in turn.

Answer 3

Agile doesn't means no plan at all.

You create the sprint 0 that will consist of setting up the development environment and architecture goals.

Keep it simple at the beginning, it will pays on the long term.

Answer 4

Agilists disagree about planning and architecture. XP tends to advocate no (or little) architecture up-front (i.e., planned design), but people like Martin Fowler say they do planned design maybe 20% of the time. Chapter 14 of XP Explained (Kent Beck) has a nice articulation of the XP design philosophy.

Michael Keeling has a good explanation about why agilists (and others) disagree. He says to pay attention to two dimensions: your knowledge about solutions and your knowledge about problems. When you know lots about solutions in this field (e.g., web systems), then you are more likely to defer planning. But when nobody has ever built a Mars Rover before, you do more planning. To me, this explains why engineers in different situations do different things, yet what each does is rational.

Chapter 3 of my book on software architecture is devoted to answering the question "How much architecture should you do?" In brief, the answer is "Do architecture until risks fall off your radar". If you're not worried about scalability or security, don't bother planning those. But if you're worried about auditability (e.g., regulatory compliance) then work on it until you think you've got it handled, or can handle it using evolutionary design. That chapter is available for free download.

If you're being agile, you should avoid shoving lots of up-front design into an Iteration Zero. Put another way, if your Iteration Zero is three months of design, you are not really very agile.

Your question is specifically about architecture models -- just one of the things that you would do in planned design. Models are a means to an end (the end being a running system). Used well, they can help you reduce risks, but nobody will be happy at the end of the project if you have a great model and no system.

Answer 5

The same could be said from planning and other project activities. You need to do a bit of the overall in any of those activities to get the project going, but you shouldn't go deep in details that are best addressed / belong to each iteration.

It is vital to have a very clear idea of what the project is about at a very high level at the very beginning. If that isn't the case, the very first effort that needs to be done is that. The same needs to be done for the architecture, we are talking about a very short time in here, with the right people involved that can make all the difference in starting to build a completely wrong thing.

As you are doing the above at an extremely high level, you'll naturally get plenty of new somewhat high level info as each iteration progresses. Also note that you could have identified at the very beginning that making sure something can be done at all is essential to know if the project can work at all. This impacts the focus on the team and the actions that needs to be done to ensure it'll be a healthy project.