Over on ACM Queue's (http://www.acmqueue.com/modules.php?name=News&file=article&sid=360) blog, Terry Coatta has an interesting post about developing specifications. Terry presents two alternatives - developing detailed specifications that contain enough detail to be passed on to a developer, or developing design sketches and then sitting in the same area or war room so that one can tell when, how, and where more detail is needed. Coatta expresses a preference for the latter.
I have often spoke of the importance of being physical present when my specifications, be they data models, process models, or even just issue resolutions, are being implemented. In most shops I've worked, the data and process architects sit somewhere together, away from their development teams. Sometimes, as on a recent project, in another country or even another hemisphere. In those cases, I believe it is important to be virtually present. This often means both sides altering working hours so that each side has enough time to be present.
The problem with being located away from the development team -- even if it is only down a hallway or two -- is that the developers must rely a significantly greater amount on the accuracy and completeness of your models. This leads to more assumptions and guesses being made. It leads to misunderstandings, misinterpretations, and, most importantly, it leads to a perceived culture of "those crazy modelers and their weird and wacky throw-over-the-wall models".
In shops where I've been able to sit within a cube or two of those using the models, I've been able to answer questions, clear up misconceptions, and give clarifications. As an added bonus, the developers who had the insight into what sort of conversations I have with the users and other departments understood that the models documented much more than just a database design.
What I liked most about Coatta's post, though, was the assertion that every project has its own culture and needs:
Overall, the experience is reinforcing a thought that's been bouncing around my head for a while: There's no such things as the universally perfect development process. Development processes are like software in a way. You need to look at what you're trying to achieve with the process, and figure out whether you're getting what you want. And just like evaluating a particular feature for some software you're building, you need to evaluate whether the features of the development process are the best way to get the job done.
Even so, my preference is always going to be to sit with those who use the models, not far away with the "data" crowd. Don't get me wrong; I like my co-modelers, but it's the model users who need my support more than my fellow architects.