The "Architecture Phase"

I got this question from Eliyaho:

[Everything is nice and dandy until the "architecture" gets into the hands of the architecture breakers. Many times I've found myself (just seconds from releasing all my acquired know-how) in hand-to-hand combat with some developer. As you said, the architect's role includes tight supervision and aggressive code review all along the way. More than once I've seen code like MyView.MyController.MyFacade.MyBL.MyDal.FooAccessor.GetValue or similar rubbish, and then I need to make the developer redo all his (hard) work. This is where the architect needs to have authority. Sometimes I wait for developers to take a vacation to refactor their code and I excuse this by saying we needed something urgent and he was not present (so that he will not take offense). My question is at what level of coercion should the architect use -- at the module and core guidelines level or at the "each and every class" level. What happens is that during the project, the architecture is not good enough -- it is lacking, either because requirements change, poor performance or over flexibility. These shortages decrease the value people see in the architect -- which is a problem.

Well, There are few issues we need to address here:

• How do we know someone does not adhere to the architecture?
• What do we do once we find such a violation?
• How can we avoid architecture violations in the first place?
• How involved should the architect be?
• How do we make sure "the architecture" is relevant throughout the project?

I'll address the last issue (ensuring the architecture is relevant) in this post and the rest of the issues in the next post.

There is no "architecture phase" per se. The architecture should stabilize in the first few iterations and it would probably not change much after that (unless you get major requirements changes -- which will prompt you to re-evaluate and possibly redesign). Note that the architecture is dependant mostly on quality attributes of the system and these tend to be more stable than functional requirement (even though, in a startup I worked for, we once made a wee change in our target customers --from SMBs to Fortune 500 which really turned almost everything, except maybe the splash screen, upside down.)

Thus, in my opinion the question should have stated "What happens is that during the project, the [initial] architecture is not good enough", which would be a reasonable statement since the initial architecture matches your initial understanding of the system. Unless the project is really trivial, I do find it useful to have an initial architecture phase (where you don't deliver features and concentrate on architectural decisions) -- I usually try to limit this initial phase to one iteration (usually 1 month) and have it end with a working skeleton that demonstrates how all the components play together.(e.g. by implementing one thread through a use case or implementing a central user story). But, again, this does not mean the architecture is "done" -- it means we (hopefully) have a sound foundation to start building the software.

The goal of the initial architecture is to leave enough leeway to allow changes without having to throw everything. The more you are familiar with similar projects the more you can expect the architecture to be close to final but the opposite is also true, if you are new to a project type you can expect the architecture to be far from final.

So how do you keep the architecture relevant throughout the project? You keep yourself involved in the project, validate the architecture against the requirements and be ready to evolve the architecture if needed. You should strive to stabilize the architecture after the first few iterations -- to do that the architect should try to find the use cases/user stories that challenge the architecture or that are risky and prioritize them higher. Note however that the customer has precedence and the initial iterations might be focused on delivering some business value that doesn't challenge you architecture; that is why I recommend you have architecture iteration(s).

Posted by Arnon Rotem-Gal-Oz at 05:23 PM  Permalink