Search This Blog

Tuesday, March 24, 2009

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

No comments:

Post a Comment