Data Management

A portrait of the IT manager as a database object

A relational database lets you define tables and determine relationships among the tables. Bob Artner suggests you look at your job the way a DBA looks at a new application.


You know the saying: “If the only tool you have is a hammer, all your problems look like nails”? With me, it’s not a hammer but a relational database. As regular readers know, before I got into this line of work, I was a database application programmer.

While I haven’t done a SQL query in years, I still tend to look at technology issues from a database point of view: Start by defining the tables and then the relationships between the tables, determine the reporting, etc. This approach has proved useful over the years.

In fact, I want to expand it beyond purely technological problems. In this column, I’m going to propose that you look at your job the way a DBA looks at a new application. Such a viewpoint can give you lots of insights into your organization.

The databases of TechRepublic
This concept might sound a little squishy, so let me show you what I mean with an example—one you already know. Consider TechRepublic. What is TechRepublic?

We like to say that TechRepublic is a community of IT professionals. That’s true. But you can also look at TechRepublic as a collection of different data tables.

For openers, you’re reading a column from our content database right now. We index this database in a number of ways. Here are just a few:
  • Title
  • Republic (the tabs across the top of the page)
  • Channel (the topics within each Republic)
  • Author
  • Time/Date

Most of these field relationships are one-to-one. However, we do have several one-to-many relationships between individual articles and other tables—for example, article ratings, where readers can rate each article. Likewise, a discussion (see the bottom of the page) can include many entries for each article. Finally, there are page views, where you come in—but more about you in a minute.

As you might expect, we use a content management system (CMS) to manage the content creation process. A database entry is first logged as a concept—basically, just a brief idea for an article to be written sometime in the future. If the concept has legs, it gets upgraded to become an assignment, which is given to a writer. Once the author finishes the piece, it gets checked back in to the CMS, which tracks it through the editing process and attaches the metadata we discussed earlier (and does a lot more besides). Finally, when the article is finished, a publishing tool writes it to the site database.

And then there is me. I’m part of a number of databases here at TechRepublic. First, I’m one of many authors here, stored in both the site and the CMS. (Here is my Author Bio. Notice that it contains a one-to-many relationship with all the articles I’ve written.) Second, I’m a TechRepublic member, just like you. (If you’re curious, here is my Peer Directory listing.) Third, I’m an employee of TechRepublic, which is a subset of the CNET Networks employee database. (Sorry, but I can’t show my entry in the CNET employee directory—you’ll have to trust me.)

And then there is you. As a TechRepublic member, you might think of yourself as just a person who reads articles, but you have a one-to-many relationship with various other data tables. If you want to see what I mean, click on the MyTechRepublic link at the top of this page.

What we’ve been talking about here is just a short list of the many different data tables that exist at TechRepublic. More importantly, these are only the formal data tables. There are lots of informal data collections at TechRepublic.

Take me again, for example. Toni Bowers runs IT Manager Republic for us. She is responsible for all the content that appears here, and she deals with all the writers. In addition to the formal data fields in the author database (name, e-mail address, phone number, etc.), she has a number of additional fields that she keeps in her head. For me, it probably looks likes this:
  • Quality of writing: Not bad. Too many literary references.
  • Editing sensitivity: Pretty good. Doesn’t fight most editing suggestions. Note—don’t mess with his jokes!
  • Deadlines: The pits.

Managing in a database world
So that’s a small slice of the database activity that makes up TechRepublic. What about you? What can you learn from looking at your job as the interaction among a number of data tables? Here are a couple of discoveries you might make:

Different views of the same data
Ever wonder how two people could look at the same event and come to different conclusions? Suppose, for example, you’re a project manager. While every project (new, completed, abandoned) is in the project database, you’re only interested in the ones you’re trying to get done at any one time. Therefore, if you need to push the due date of a particular project back a week to accommodate another rush job, that’s not too big a deal for you.

The client, on the other hand, is looking at a different view of the same data. He or she is not looking at all the projects you’re trying to get done, but only at his or her projects. Further, the client looks at these projects in the context of all the projects he or she has ever brought to you. So what from your perspective looks like a simple business decision to push back a delivery date by one week might look to the client like a repeat of the project last year when a one-week slip ended up being a six-week delay that caused a ton of problems.

Discovering dependencies
If we took the simple TechRepublic data tables we mentioned above and mapped them on paper, we’d create a blizzard of connections and dependencies.

For that reason, you may find it useful to do the same thing yourself. Try to sit down and map the connections between the “data tables” that make up your organization. It will probably help you discover some hidden vulnerabilities: perhaps an undue reliance on a single person or single server—with no backup.

Uncovering additional resources
While mapping these relationships will uncover dependencies, it should also help you find some additional resources. Go back to that saying we started with. The problem with most managers isn’t that they have only a hammer, it’s that they always reach for the hammer instead of looking through the toolbox for the appropriate tool.

In the same way, by looking through the entire database, you’ll often uncover underutilized assets.



From the IT Leadership Web log
I often write about database issues on TechRepublic’s new blog for technical managers and their bosses. It’s called IT Leadership—check it out today. It’s free.

 

Editor's Picks