Why You Should Hire An IBM i Database Engineer

February 15, 2017 Alex Woodie

You likely know the IBM i platform as an all-in-one, self-contained bundle of computational glory and efficiency that doesn’t need an army of specialists to run like the platforms from “those other guys” do, thankyouverymuch. While that largely continues to be the case, you may consider making one exception for a certain type of technical expert: the database engineer.

There’s a growing chorus coming out of IBM Rochester that IBM i shops should consider hiring database engineers, or DBEs. Folks like Alison Butterill, the product offering manager for the IBM i server, DB2 for i Business Architect Scott Forstie, and DB2 for i guru Mike Cain, are getting increasingly vocal about the need for DBEs.

One of the big factors behind the DBE push is the ongoing migration of business logic away from RPG, Java, and other high-level languages and into functions controlled by the DB2 for i production databases. While an experienced RPG code-thrower may have expertly worked all sorts of complex data manipulations into his work in the ’80s and the ’90s, progressive IBM i shops today realize there are real advantages to using stored procedures, built-in functions, constraints, and other SQL-based goodness that the smart folks up in IBM Rochester have cooked into the database.

“We have some shops that are getting into the world of doing a lot of work with the database,” Butterill told IT Jungle recently. “They’re actually starting to let the database do a lot of work for them, and there’s a lot of things we’ve put in over the last couple of releases that do require some planning and some thought on how to do it.”

According to the 2015 IBM i Modernization Redbook (which is as big of a smash hit as you can get in the IBM i Redbook publishing racket), somebody with DBE skills is increasingly being called upon to perform a variety of functions, such as defining SQL naming conventions for tables, indexes, views, and columns, or choosing which access method is the best one to use for a particular situation.

“For example,” the Redbook authors write, “they might determine that new SQL objects should be used in File Definition Specs (F Specs) or that SELECT * FROM… in SQL statements should not be used. The DBE works with application staff to teach SQL, enforce SQL rules, and help with performance tuning.”

The DBEs can be found working with tools like InfoSphere Data Architect or IBM Data Studio to lay out the relationships between entities, the Redbook writers continue. Additional jobs include evaluating temporary indexes created by the system to decide if they should be permanent and diagnosing performance and SQL issues in the database.

In years past, AS/400, iSeries, System i, and IBM i shops may have talked about the need for a database administrator (DBA). But as Cain argues in a 2012 blog post, the more apt job description here is the DBE, who carries deeper technical skills than a mere administrator and is also able to communicate effectively with business leaders.

Cain argues that a DBE for IBM i would have four main responsibilities, including: database architecture, design, and implementation; data availability, control, governance, and integrity; data-centric application design and programming; and database performance and scalability.

But above all, the most important part of an IBM i DBE’s job is to design, implement and support a proper data model. When it comes to getting the most out of DB2 for i, the data model matters,’ he writes in a 2016 blog post. “By telling DB2 about your data centric business rules, the data element attributes, and the relationships between sets, DB2 can do more work on your behalf. This results in higher productivity, greater efficiency, and better performance.”

IBM i shops can still claim that DBAs are mostly unnecessary roles in the average IBM i shop, since the DB2 for i database can handle many of those duties through its super powerful software. But it’s also becoming clear, especially in this day and age of SQL, that IBM Rochester recognizes that doing a bit of database design work up front can pay big dividends down the road.

“We don’t need somebody doing some of the administration tasks that so many other databases need,” Scott Forstie told Paul Tuohy in a recent “i Talk with Tuohy” story over on IBM System Magazine.

“But when you ask question[s] like ‘Do you know the most expensive database workload, what it is? Do you know about the most expensive database queries that are coming through and by which users? Do you understand your index strategy and how healthy it is; should it be changing?” Forstie says. “Those are some of the kind of prompting questions that you can respond to well ‘Oh, my DBE should know that…'”

So, how do you know if you need a DBE? If you’re using some of the more modern features of the database, such as SQL query engine (SQE), as opposed to the older DDS-based record-level access techniques used by many legacy RPG programs, then you’re more likely to be getting into DBE territory. If you’ve moved business logic from RPG programs into DB2 stored procedures, BIFs, and other database artifacts, a DBE could be for you. If you’re finding that you’re asking your programmers to revisit your SQL indexes more frequently, you might be a candidate for a DBE. If you’re managing monstrous databases containing many terabytes of valuable customer data, and doing all manner of heinous sorts on them, then a DBE could be in your future.

Bigger IBM i shops tend to run into these problems more often than smaller shops. But company size isn’t always the main factor at play in the DBE decision, explains Butterill.

“It’s truly an ‘it depends,'” she says. “We do have some small customers who are doing a lot of progressive work in the area of analytics and the area of mobile support, moving to interfaces with different systems–that’s the kind of complexity that might require a DBE. It’s really the complexity of their solution.”

Before you start worrying about how to free up budget to hire another technical staffer for your shop, consider that you may not need a full-time dedicated DBE. “It doesn’t have to be a whole person,” Butterill says. “Maybe it’s just part of somebody’s job that they do that kind of planning of the database.”

As IBM i shops modernize their environments, the DBE position figures to play a prominent role. While the possibilities of advanced analytics on the box are growing, the IBM i platform primarily functions as a transactional system at most companies that use it, and the database is the heart of those transactions.

If your company values the data – and most companies that claim to be “data-driven” do – then getting serious about database engineering will likely lead down the path to the DBE.

RELATED STORIES

The Data-Centric Depiction Of IBM i

Admin Alert: What Should an IBM i Administrator Do, Part 2