Between 2005 - 2008 I led a database team during a period of frenetic change. One of the first recruits was an experienced contractor called Dave. Dave had learned data-centric development while working under Richard Barker (author of the Oracle Case Method) at Oracle. He effortlessly and repeatedly absorbed the awkward and incomplete problem specifications, producing blueprints that both described and addressed the problem more accurately, more completely, and infinitely more plainly than its author or sponsor had begun to articulate it. And with infinitely more clarity than any accompanying documentation.
His designs were complete, correct and concise. They were rarely substantially re-drafted, largely proofed against challenge, and almost magically adaptable to "new" requirements. The resulting software was delivered on time, and worked. The designs and resulting software seemed to define the essence of the subject quite completely. To my eye they were done with more than a degree of artistry.
I was forced to accept that Dave had perfected a practical art-form in our professional domain, an art-form in which I was no more than a neophyte, and in which it was clear most of our peers lacked both skill or even interest.
I was compelled to learn how this was done. I don't believe there is a process to follow. Rather, as fortune favours the prepared mind, there are concepts and techniques which prepare a data architect's mind to understand, design and communicate information problems and solutions.
What follows, will I hope, be a formalisation of what I learned: from Dave's zen-mastery of this art, and from the other expert practioners I have been privileged to work with.