Is it possible to have architecture guidelines? If so what should be in them?

Question

In the same way we have coding standards, can there be things such as architecture standards?

These would be high level principals that we can pass to our less experienced programmers so when they start designing changes or small applications they know what we expect to see without the more experienced programmers having to correct them (note this isn't instead of review, just preventing obvious mistakes as early as possible).

I'm thinking potentially it could contain things such as "Always normalise your database unless there is a specific and clearly understood reason for not doing so", "Always separate out presentation, logic and persistence".

Do people think that this would be too high level to be of any practical use? Or that such generalisations are almost impossible given the variety of functionality we might be asked to code? Or might it be useful?

If you think they're useful and realistic what would you include?

(If it helps clarify I'm thinking about Java/.NET level programming for corporate style business systems).

Answer 1

This is hard to do which is why the common practice is to always have a more senior team member handle architectural decisions and coding. If it is impractical to have a senior team member do both then at least have that member be an integral part of the design and review process.

Answer 2

In my opinion have your junior developers read Code Complete and The Pragmatic Programmer. These kind of high level idioms are presented in here.

Answer 3

The SOLID principles would be a good place to start

Answer 4

We do have architecture guidelines. They are called design patterns. These are basically formalized, architectural guidelines that you can follow as appropriate.

Unfortunately, part of being an true software architect is being able to decide when and how to apply certain patterns/guidelines/practices. That's not something that's necessarily automatable or printable directly - There is almost always more than one way to do something, and each has costs and benefits. The skill comes in understanding the entire range of these, and making a good decision up front.

Answer 5

"Always separate out presentation, logic and persistence".

Unless there are good reasons for not doing so.

For architectures, which are much more nebulous things than code, such rules would quickly degenerate into hand-waving and get-out clauses. So such guidelines are possible, but I don't think they would be useful. At the end of the day you are depending on the expertise and knowledge of the architect - hobbling him or her with half-baked rules (and who drew up these rules?) does not seem like a good idea.

Answer 6

I would add Unit Testing to the pile. If I could have only one thing on a desert island with my development PC, this would be it.

Practitioners of Test-Driven Development will assert that this is an integral part of their architecture, since the tests essentially define your application's behavior.

Answer 7

How about the guideline don't have architecture guidelines?

Joking aside I think making the most important guideline would be:

Make the architect of any system actively part of the develop team writing actual production code

IMHO, this is the only way to have the level of information you need to make architectural decisions about a system. It also forces the architect to have 'skin-in-the-game' with the obvious benefits that produces.

Answer 8

Have you seen this guideline from MS Pattern & Practices group? They look at it from the application perspective instead of practice perspective.