In one of the articles that just hit recently around our upcoming "Architectural Validation" feature in VSTS 2010 Team Architect, there was concern around how to "maintain all those diagrams" in context of the Architectural Validation or Layer Diagram feature. I wanted to shed a bit more light on how the association between your code and the diagram is made and maintained. We have not really discussed this nearly as much as we should, other than a quick "Map your physical assets..." comment I made in step five of this post.

Basically, I want to point out that the risk of the Layer Diagram and your source getting out of synch really depends on how you choose to use the tool.

1. Association with artifacts can occur in the following ways
1. Link to a single artifact e.g. a class
1. Out of sync risk = medium high
2. Depending on the number of deletes and renames, layers linked to classes can have stale links. However, these are shown as warnings and can be cleaned up quite easily.
2. Link to a group of artifacts using a container e.g. namespace
1. Out of sync risk = low
2. Linking a layer to a namespace indirectly links the layer to all classes in the namespace. Validation will start at the namespace and process everything in it. This indirect link allows the validation to adjust to changes to individual classes rather well.
3. Namespaces themselves do not change as often.
3. Link to a group of artifacts using a query
1. Out of sync risk = very low
2. A query links to dynamic collection of artifacts. The query is evaluated every time you validate. Hence, like the namespace example above, changes to the results of the query are automatically factored in.
2. Build time validation
1. The integration with builds and check ins make this feature a lot more useful and bring it to the forefront of the development process. This also has the side benefit of forcing updates if they’re required.