I am a big picture guy. I say this not just because I think a big picture is often needed to understand context, to get a sense of the size of a problem, to see what it is we are all trying to do, but also because I actually draw big pictures, for example, the one shown here:
This diagram (technically a Sankey diagram, because I want to know how much data is going where) is useful to me because it holds on a single sheet of paper most of what I know about a topic, in this instance, how a certain type of data gets created in some of our core IT systems and what happens to that data once it has been created. (This pictures is also useful to at least one other person, Felix of course, who is shown above playing a maze game of his own devising.) I have spent much of my time since January researching and drawing this and a few other diagrams of comparable size in an attempt to understand the environment in which I find myself, and in particular to understand what kinds of data exist in that environment and what use is made of that data, and, too, what use could be made but isn't.
One of the interesting features of big pictures is that you cannot view them, at least not in their entirety, on a computer screen. You have to print them, preferably on a really big printer. And having printed them you have to find a wall somewhere on which to hang them. And once a picture is on a wall, the days of private offices being long gone and the picture being, as I say, big, other people will inevitably see it too. This suits me very well: I want other people to look at these pictures (I make them not only large but colorful for this reason) and to draw from them their own conclusions.
It seems now that a number of people have drawn their own conclusions, not so much about what the pictures represent as about their author. A corporate decision has manifested itself, about my role and, gratifyingly, about how useful it is to have someone drawing big pictures like these. It is for this reason that I say I now know what my job is--namely to illustrate the overlapping system, operational, and data contexts within which the company is trying to address a number of the more substantive challenges it faces and thereby to supply these seemingly unbounded challenges with a frame of reference and some clues about how to address them--and it is also, I suppose, for this reason that I still have a job.
What I do not know even now is how to name this job, and that's a pity, not just for the sake of a more pithy blog post but also because I've been asked to provide my own title. My first inclination, "enterprise data strategist," is a non-starter: the word "strategist" is an albatross. Another obvious choice is "architect," but there are lots of architects at Autodesk, and as best I can tell those with a technical element in their title (e.g., data architect) work within a scope too limited for the issues I am tasked with addressing. I must have data in the title, it's what I most care about, but beyond that at the moment I know only what it cannot be.
Things are changing in my world at work. Autodesk itself was born in the shift from mainframe to personal computers, it negotiated the move to GUI-based operating systems, and now it has to find its way to the cloud. We are growing a consumer-facing business, a relative novelty to us, likewise the social web. All of this and more requires a strategic response, and one element of that response must concern itself with data. Whatever the uncertainty around my title, it's good to know, half a year in, what must be done.
this post doesn't really explain what you do. what is a data architect? phil and i would like to know.
ReplyDelete