Third World Agility

When do you determine the architecture of your whole system? Do you go with an architecture you've already seen and used, or one that you know will be most effective for your solution? Do you go with the best and feature full, or the fastest and easiest to deploy?

All week I will be writing about making architectural decisions -- when to choose robust feature full solutions, and when to use the light, quick and "dirty" solutions. It's all in the light of making design decisions when you're already working on the user stories.

So when do you choose the architecture?

In Agile settings, you choose the architecture for the solution everytime you need to -- which translates to, almost everytime you write code. When talking about architecture, the discussion covers the hardware and software components of the whole solution -- and how the system should look like from afar. That is, from a higher level -- higher than the code.

This seems like a simple task, but it really isn't all that simple -- there are a lot of things that need to be considered: budget, timeline, problem domain, scale, core competencies, among many other things. It also assumes that you have a host of architectures already in mind -- otherwise, that's yet another discussion.

In the next few days, I will be outlining criteria I use to determine which architecture (infrastructure wise, containing both software and hardware solutions) to deploy in different settings. I will be providing hints and insights into different domains that I've had the privilege in working with.

A good design looks good and gets better when it's actually built. A bad design just breaks everything. So design it as good as you can, and hope it doesn't break too much in the end.