Johanna Rothman writed about "
letting go of BDUF"
(Big Design Up Front). One statement she makes is that you can't
predict what the architecture needs to be. I can't say I agree with
that, since many times you do know something about the project and you
do have prior expereice that can give you enough confidence to lay some
ground rules. I called this
Just Enough Design Up Front or JEDUF for short.
Another
statement Johanna made, which I wholeheartedly agree with, is that you
should let the architecture evolve. Evolving an architecture sounds
very compelling but it is not a simple feat. Architectural decisions
tend to have system wide implications which means that changing one too
late in the game you'd get a lot of rewrite and/or refactoring to do
.
My strategy to solve that conflict is to:
- Set the first one or two iterations as architectural ones. Some
of the work in these iterations is to spike technological and
architectural risk. Nevertheless most of architectural iterations are
still about delivering business value and user stories. The difference
is that the prioritization of the requirements is also done based on
technical risks and not just business ones. By the way, when you write
quality attribute requirements as scenarios makes them usable as user stories helps customers understand their business value.
- Try to think about prior experience to produce the baseline architecture
- One of the quality attributes that you should bring into the
table is flexibility - but be weary of putting too much effort into
building this flexibility in
- Don't try to implement architectural components thoroughly - it
is enough to run a thin thread through them and expand then when the
need arise. Sometimes it is even enough just to identify them as
possible future extensions.
- Try to postpone architectural decisions to the last responsible
moment. However, when that moment comes -make the decision. try to
validate the architectural decisions by spiking them out before you
introduce them into the project
These steps don't promise that the initial architecture sticks, but in
my experience it makes it possible to minimize the number of
architectural decisions but still have a relatively solid foundation to
base your project on