A few months ago, I was talking to my next door neighbor Jeff about what he does for a living. Jeff works at a large private investment bank downtown, and he was tasked with sorting out their organization of data. This particular bank is like a lot of financial institutions in that it has data coming in from various feeds, it has data about its own customers, and it merges and presents this data to various groups within the organization. Each group furthermore has its own uses for the data, and may have come to have its own interpretations of the underlying data due to years of healthy growth. Jeff was asking me if I knew of any good books on the subject of data management that might help him sort through all of the issues that were coming up.
I tried to think of a few titles, and we came inside my house to peruse the bookshelves, but after a few moments of page flipping I had to inform him that I really didn’t know of any good books on the subject that would help him in particular. You see, Jeff already had a good handle on general principles on how to approach the problem (better than most) coming from the management side, and he was quickly picking up the general technical principles and the associated language. And that’s where the problem was: while there were any number of excellent references on general data management from a technical point of view, there were none of which I was aware that would help him further along in his particular situation.
And that seems to be a general principle of projects. If the project is easy, you’ll find any number of books and articles helpful on the subject of managing or completing that project. If the project is hard, then the book or article hasn’t been written yet. And after completing such a project, maybe you’ll have enough material for a book.
As it turns out I am in a similar position as Jeff in my own company, and am struggling with many of the same issues, but from a technical side. And my own observations are a sort of corollary to the above mentioned “general principle of projects.” Namely, I have read any number of books and articles that lay out good practice in data architecture, and I have found such advice to be very applicable in same cases and not at all applicable in others. When the advice is narrowly scoped to the technical domain, or when the advice is very generally scoped to apply to almost any enterprise ever in existence, I have found good advice to be applicable. When good advice is scoped almost anywhere in between, I have rarely found it readily applicable, even if it really is good advice. The reason is that at such scope, the organizational features of my company come into play; and like individual people, every organization is different. Some things work here, some things don’t, and everything at that scope has to be recast into our particular context.
So what’s all this, then? This is my attempt to make sense out of various ideas I have and devices I’ve come up with that fall under the heading of “There’s no good book on that, but gee that’s kind of a neat idea.” Usually these things fall into that “in-between” scope I was talking about above, and probably won’t have much applicability outside of my context, but maybe are interesting and worthy anyway. Along the way, I’ll write about some of the particular “narrow” scope devices that I’ve come across. Hopefully I’ll make enough sense out of this stuff to write a book someday, but I haven’t decided if that book is going to be about programming, woodworking, family, yard work, or whatever else may someday come out of this venture.
