The Beginning (3)

Before we explore the data architect role in terms of our overall goal, I should say that I do not intend to go into depth for any of the roles. I mentioned the need for standard processes but didn't specify any of the necessary processes. For one thing, that level of detail is well beyond the scope of this (or any) blog. For another, the processes and standards must be compatible with the organizational culture. I wouldn't go so far as to say that any path will do, but I will say that, if you live in Minneapolis, there is more than one way to get to Miami. The thing to remember is that there are more constraints as you depart and again as you arrive. We ask, "What's the best way out of town if I'm headed south?" And then we ask, "What's the best route to city hall if I'm coming from the north?" But in between we can take the scenic route, the shortest route, the fastest route, the Civil War route or any other route that seems good at the time as long as we keep our eventual goal in mind.

From the standpoint of business intelligence and our four characteristics, we would want to pay special attention to what the programmers are doing or not doing with respect to definitions (semantics). The data architect will have spent considerable effort in researching and compiling information about the data. They will have learned about how various kinds of data relate to each other for different business functions and users and they will have defined quality rules for each kind of data.

The process standards, to be monitored by Quality Assurance and warrantied by Quality Control, will ensure that the programmers have those definitions and rules in a format that they can use and that they do, in fact, use them.

If your programmers work for someone else, the processes and standards will be about acquisition. They will ensure that the data definitions and relationship rules embodied in the application or system are compatible with those of your business. You are going to have to lean hard on your vendors and they will squirm and plead "proprietary." The best advice that I can offer is to walk away from this vendor. Another vendor will be happy you asked because it will allow them to really get close to you and they will be proud of their quality processes. The ones who drag their feet do so because they aren't able to produce the assurance you need. Proprietary is a euphemism for we don't know.

Become interested in these things. Ask questions. Expect answers that you can understand. Don't accept arm-waving and diversionary tactics. You will be well on the way to business intelligence from a high quality, reliable data resource.

Next time: the "business" role

A Hammer in Search of a Nail

Are we all familiar with this metaphor? Abraham Maslow ("Hierarchy of Human Needs") is said to have originated this, but it hardly matters. The concept rings so true that it has probably been known since the first tool.

I have lately participated in some discussions on LinkedIn with the result that I now believe that the vast majority of workers in information technology are in possession of a tool that they are seeking to apply to every problem that they encounter. The really dangerous ones are creating problems to use their tool on. Oh, wait, there's a name for that--it's called marketing.

Notice, too that I said "in possession of" a tool. It is apparently no longer necessary (if it ever was necessary) to actually be skilled in the application of your favorite tool.

I once worked with a guy--a programmer in this case, but I'm not looking to single out programmers--who said something rather like, "We don't support the business. We are the business." The business was rail transportation and it is true that if all of the applications used by this particular company were to suddenly disappear, those "left behind" would no doubt have had to cease operations until they could be reorganized.

That's not the bad part though. the bad part is that this is a really good example of just how far the notion of "where's the next nail?" can take us. When I believe that the world as I know it is held together by this tool that I hold in my hand, I am in the midst of a dissociative process. I don't go home and act this out. When I'm not at work for example, I'm just the guy next door. When I do get to work, though, I'm still the guy next door--it's just a different door. We--most, if not all--live in two separate realities. About the only thing that keeps us from being diagnosed with a dissociative identity disorder (DID) is that we (usually) remember what happened in the other world.

I could go on at length but the bottom line is that, not only is our work life a separate reality from our real life, but there is a completely different reality in the executive suite than there is on the floor, and (for me) most importantly, a separate one for I.T. Leave aside for a moment, the variety of realities we might encounter as we go from networks to servers to DBA, to data architecture, to development to QA--it is absolutely amazing that we get anything at all accomplished.

The poor data architect finds himself stepping into and out of a dozen distinct realities every day. It is certainly a defense mechanism to take refuge in a favorite tool--the "data model." This is the talisman used to shield against the swarm of alternative realities. Unfortunately, the tool was designed for a different purpose, to capture and integrate all the different realities. Nails come in many forms, too.