Get Database Skills for Career ROI

November 8, 2010 Dan Burger

The IBM i job market is meat grinder these days for IT workers. The lucky ones are fighting to hang on to the jobs they have, while the unlucky are struggling to put their IT talents to work again. On either side of that great divide, there are people benefiting from having better tools in their toolboxes than the person next to them. I’m talking about specialized skills and, in particular, I’m talking about database skills where there is short supply and a growing demand.

You may have noticed that dramatic economic retardation causes only a minimal reduction in data. Every company, every organization continues to pile up data. It keeps pouring out and flooding into companies, and it is generated internally as employees create new data–and it never gets thrown away. The upshot is that information management is a much tougher problem to crack than data storage or data processing.

It takes a special skill–one that most people working in IBM i shops don’t possess. It’s a legitimate choke point for i-oriented shops, especially those facing multi-platform realities. Turning data into information is adding value. If you get good at this in the IBM i environment, that skill will transfer to other environments as well. Add that to skills you already have as an RPG, COBOL, or Java programmer, and your toolbox is a lot more valuable. The key to that, however, is SQL.

Just a few weeks ago, I spoke with Mike Cain, a member of IBM‘s senior technical staff for DB2 on i. That conversation resulted in an article about why IBM i shops are using SQL and, in some cases, modernizing their databases. That conversation led to another that focused on skills.

Don’t get the idea that every IBM i shop needs a database expert. That’s not the case. There are still a great number of shops that run on autopilot with a Power Systems server, an iSeries, or even an AS/400 running in black box mode with a skeleton staff doing minimal development and mostly concerned with application maintenance.

It’s also not the case that if you don’t learn database management skills your next job will be flippin’ burgers at McDonald’s.

In his role at IBM, Cain and the team of database experts that he manages consults with dozens of companies each year, providing project advice from both the technical and business perspectives. He’s also an instructor for database training provided by IBM as well as at venues such as the RPG & DB2 Summit, COMMON, and local user group technical conferences.

Cain has had numerous conversations with executives concerning the staffing and skills required to analyze database performance and scalability, create new features and functionality, recognize what not to change, and identify where changes are appropriate.

Roles and responsibilities change depending on the company and the size of the staff, Cain says, but education and training of existing staff will be necessary. This is how he sees it from the IBM i perspective. And traditional RPG and COBOL application developers need to embrace SQL as the language to access the database, among other new skills that will have to be acquired.

“The biggest mental hurdle RPG and COBOL programmer have is with native high-level language,” Cain says. “They are used to telling the system what to do and how to do it. With SQL, we only tell it what to do, not how. We have to trust that the query optimizer and the database engine are going to do the right thing.” The programmer needs to become familiar with the concepts and syntax of SQL, and understand set-at-a-time operations versus record-at-a-time operations,” Cain says. “I recommend basic SQL education. Some individuals might pick up a book, they might hire an educator, attend a class or Webinar, or use online resources such as tutorials and the SQL Reference Guide.”

This learning process is similar to learning any new language, he says, because the learning involves syntax, constructs, and rules–just like RPG, for instance. Building skills includes knowing the SQL best practices that take advantage of RPG and/or COBOL running in IBM i.

“Writing SQL apps or embedding them in a program is analogous to what a Java or PHP programmer would do or what a programmer does when using ODBC,” Cain points out. The educational priorities are learning to code and implement logic using SQL and getting the data-centric features that are enabled by SQL.”

The data-centric features include having a database that does more work keeping track of the data, making inferences, taking care of repeatable processes such as coming up with logic so the operator doesn’t have to, and, by doing all these things, increasing efficiency.

Additional skills include data modeling and learning to architect a solution. In larger companies where staffing allows, these responsibilities come under the realm of the software engineer or application engineer. The person in this slot is going to modernize or build net new applications that are data centric. When staffs are smaller, the programmer and the engineer hats might be worn by the same person. In the traditional IBM i environments, database administrators may not exist. When they do, their responsibilities are generally focused on performance and scalability considerations. In an SQL environment, maximizing the use of stored procedures, triggers, and functions are among their top priorities.

“A lot of shops realize they need to change their organization or insure the folks are educated, enabled, and energized,” Cain says. “They actually have a position such as database engineer or database administrator that makes an organizational statement. They recognize the need for a specific position that focuses on database and SQL and best practices. They also see that education takes place over time and continues to provide value.”

Cain advises executives to add staff that can develop data-centric programs and emphasizes ongoing education where a lifeline can be in place for the in-house people to consult with others who are implementing programs and experiencing similar situations.

“There still is a stumbling block based on the assumption that in-house people can do this job on their own,” he says. “Through experience, I can shine the light on things others may not perceive as an issue. This isn’t trivial. There’s a lot there. Going it alone is risky, but that’s not to say it can’t be done. Some people have experience and all they need to do is connect the dots. But those with even more experience can maybe point out where a situation might be different than what’s been done before. Folks do need some education and some guidance and some assistance to get started. It can all be called education or whatever, but without it people go off into the ditch and then call for help. You can accelerate a project and minimize risk by bringing in experts that the staff can learn from.”

Executives ask Cain, “Where do I get a DB2 for i person?” And he tells them they’ll probably have to build one. There’s no supply. You won’t find them on CareerBuilder, Dice, or Monster. Recruiting specialists can’t pull them out of a hat.

“As a career move,” Cain says, “this field is a good area to concentrate on.”

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search