You're a DBE, now what?

In between client engagements this past week, I had the opportunity to sit down with a long time member of my Center of Excellence team and all around super consultant Jim Denton.  We talked about the progress made in getting more and more of our IBM i users to embrace the idea of a DB2 database engineer. The notion of having a person (or persons) in the building who really get, and truly focus on "DB2 for i" is taking hold, and it's paying dividends for those companies that are forward thinking.

Jim was relaying an interesting question he received from one of our favorite clients over in Dayton, Ohio.  This particular company has fully embraced the wholesale and winning combination of acquiring data centric knowledge and skills, as well as embarking on a targeted and well managed database modernization and re-engineering project.  Good for them!

The question posed goes something like this:

"Hey Jim, now that I'm a database engineer, what should I be doing day to day?"

First, this is a really insightful question. It means that the person is thinking strategically and is ahead of the curve.  Well done!

The What and Why

What you should be doing day-to-day as a DB2 for i engineer basically falls into two categories:

1. Reactive
2. Proactive

Both reactive and proactive activities generally involve: monitoring, analysis and something else.

The something else will depend on your focus and your client (i.e. who are you providing value to).

Why you should be doing this seems self explanatory, but if it's not, consider this:

Partnering with leaders on solving data centric business problems and getting more value out of data is of the utmost importance. Doing it proactively makes YOU more valuable and your company or organization more viable.

In terms of monitoring, assume you are an investigator.  You need to peek behind the curtain, look inside the black box, ask the probing questions. In short, you need to learn more about your data, the usage of data and the life cycle of data. You need to discover who is using the data and for what purpose.

Here are a few ideas to get you started. If you need more, please reach out and we can help you identify and prioritize activities that provide a good return on investment. We can also help you get better at identifying and partnering with your colleagues.

The Ideas

Narrow your scope to the top 10. Once you have a repeatable process, open the aperture and expand.

Profile your data. Learn more about the properties and trends of tables and indexes. How large are they. How fast are they growing. Who is using them.  How are they used. Who has access to the data. How is the data accessed. When is the data accessed.  Get the idea?  Know your data.

Take periodic and consistent snapshots of the the query plans. Store this data and use it to develop trends. What are the longest running queries. Who is running the queries. What are the attributes of the query requests (do you see simple statements, or complex statements).  Who is reading the three million results from the query run twice a day, every day (I can tell you... no one - this is an extract!).

The DB2 for i catalog is your friend. Get to know it. Use it.

Make a blueprint of your current data model. Pick a subject area or application and model the database objects, such as they are. Use reverse engineering tools and methods to be more productive. While you're at it, take this opportunity to learn a proper database modeling interface. Something that has more colors than just green.

Use the blueprint to identify gaps in your organization's relational database best practices. SQL queries are based on and driven by the data model. A bad data model means more work for the SQL query. A good data model means less work for the SQL query. If the model behaves well (i.e. well defined sets), then the SQL will behave well (i.e. good set operations).

Using the current data model and your gap analysis, define a future data model, build a new blueprint. Formulate a plan to modernize and re-engineer the database to incorporate the foundational elements that support data centric processing.

Watch and wait for an opportunity (i.e. business requirements) to implement the modernization and re-engineering plan. We like to do this on a targeted and cost justified basis. Better yet, don't wait; engage the business to understand pain points and new initiatives.

Get out of your office or cubical. Go meet people. Talk to your colleagues and clients at every level. Find out what they are struggling with. Find out what they are using the data for. Find out what the data is NOT providing them.

The information seekers in your organization are requesting data from IT. The data is extracted and downloaded to a PC. Once on the desktop, the real magic occurs. Peek behind the curtain, look inside the black box, ask the probing questions about what the data is used for and why. Better yet, ask the information seeker "what problem are you trying to solve?". This is how you get in a position to provide value on a proactive basis.

This is how you become relevant and stay relevant.

What else?

Well... what about you?

I recommend you strive to learn something new every week. Take an hour (or two) each and every week for yourself. Crack open the SQL Reference manual. Initiate a project for yourself. Do a proof of concept or proof of technology. Develop and hone your soft skills.

All work and no play makes Jack a dull boy.