What is Shadow Architecture?

Shadow Architecture is method of communicating architecture to others on your agile team. The idea is that components and classes cast "shadows". These shadows are simplified views of the code base. UML is a type of shadow. We can look at a UML model of a piece of code and we can say some things about the code but we know that it isn't "the code". Sometimes though, when we want to teach a new team member where things can be found in our ever growing code base, we draw a quick UML diagram. Anyone see BDUF in this example? No, good.

Another example of where "shadows" come in handy is when we are making an architectural change during an iteration. We draw out what we want the architecture for our code base to look like at the beginning of an iteration (or during it) and refactor the code accordingly. Multiple developers can work on these architectural changes simultaneously since they are all on the same page. But they can't unless they really are on the same page and a "shadow" gives us a place to start from. Of course, constant communication during these refactorings is also a must. You might redraw the architecture when you encounter problems or learn more. Common sense, right?

So we call the first example, the one where we have an existing code base and describe it using a modeling language, a trailing shadow. Trailing shadows are used to communicate what exists in our code. The second example is a leading shadow. We use leading shadows to talk about what we want the code base to look like. Both shadows are descriptions of the code base and should be generated (by hand or machine) in no more than a couple of minutes. Certainly not BDUF.

OK - so here is the most important part. At the beginning of an iteration, we can talk about refactoring the code base architecturally to allow us to add additional functionality (remember Ward's definition). We would quickly provide a leading shadow and get to work, adding the new functionity! As the sun sets on the iteration, the leading shadow should be gone and all that remains is the trailing shadow. Definitely not BDUF if every architectural change that you make spans the scope of an iteration.

To give credit where it is due, I collaborated with Bill Gross (of VSTS Architect) on Shadow Architecture. I believe that he came up with the name. MSF v.4 had this concept (perhaps convoluted as that much of the process seems to have been in retrospect). I also have to give cudos on this to Scott Ambler because it is definitely an extension of Agile Modeling.