Making the Case for a Database Engineer
Why every IBM i shop, large or small, needs to create and staff the position of database engineer.
By Neil Tardy12/01/2017
The loyalty of IBM i clients is easy to understand. Some of the key technology found on current IBM Power Systems* servers running IBM i—including the integrated database and object-based security—was developed 30 or more years ago. What became known as the AS/400 in 1988 was a remarkable hybrid of practicality and forward thinking. It was pitched as an affordable solution that allowed clients with minimal technical expertise to focus on running their businesses. A loyal and enduring following quickly emerged.
I’m skimming over the details, but most longstanding IBM i clients know the history anyway, along with the fact that the key attributes still exist in today’s IBM i technology. Obviously though, the system has evolved through the generations of new hardware and POWER* processors.
On the other hand, for IBM, convincing IBM i clients of the need to evolve, to make needed changes to their IT operations, can be challenging. It’s not that IBM i clients are still living in 1988, but it’s fair to say that IBM i shops, as a whole, are cautious about adopting new technology.
“Clients are resistant to change, or maybe they don’t think they have to change,” says Mike Cain, a database consultant with IBM Systems Lab Services. “For 10, 20, in some cases, 30 years, they’ve been able to grow up and be very successful on the platform.”
Cain and other members of the Lab Services team see this first-hand, because they’ve been tasked with disseminating a simple but important message to IBM i clients: They must take a broader view of database technology. Every IBM i shop, large or small, needs to create and staff the position of database engineer.
Why? For starters, a new world has come to data and databases. “Traditionally, all of the other database platforms, Db2*, Oracle, SQL Server and so on, they’ve all required database administration, and those environments have had long-time roles and responsibilities for database administrators (DBAs),” says Cain. “On AS/400 or even back to System/38, we had a relational database that did not require administration: It’s integrated, it’s configured, it works. So we never needed the administrative side of things.
“That basically propagated into, ‘We don’t need anybody to focus on database at all,’ and that became the void,” he adds.
For an IBM i environment, a database engineer would have an enterprise-wide focus on relational database technology, including database design, database architecture, database implementation, modeling and SQL performance tuning. Again, these sorts of actions traditionally haven’t been done—or even seen as necessary—in IBM i environments.
“The world of database is a lot bigger than you think, and you don’t know what you don’t know.”—Mike Cain, database consultant with IBM Systems Lab Services
Today, the knowledge and skills of a database engineer are needed for all but the smallest IBM i shops. Cain offers this general guideline: If you’re doing custom design and development work on applications, that’s all the justification required for a dedicated database staffer.
“Saying ‘You need a database engineer,’ I know that might be a shock to some people,” he adds. “The world of database is a lot bigger than you think, and you don’t know what you don’t know.”
The Changing World of Databases
So what don’t you know? Here are some things to consider regarding the changing world of databases:
Data. There’s simply more of it now: These days, a single file or a table can be as much as a terabyte in size. In addition to possessing far greater amounts of data, enterprises must now deal with unstructured data: web pages, electronic records, video and image files, and much more. Managing these large database environments isn’t trivial. Who will ensure adequate user response times? Who will implement best practices?
Meeting new business requirements/providing for end users: Every business has initiatives and aspirations, short- and long-term. Maybe you have a new business partner that wants to exchange documents in XML or JSON formats. Do you have someone who’s familiar with those types of documents? That’s a fundamental database engineering question.
Cain points to a starker scenario, noting the need for IT to take the lead in providing for corporate users. Remember years ago when individual business units would purchase and run their own x86 boxes because they weren’t getting the functionality they needed? That sort of unsanctioned acquisition is even easier now. With the availability of MongoDB and other open-source databases, a rogue group can download its own data repository. If there’s no one in IT who has a comprehensive understanding of data in all its forms, motivated users may find another way.
“When IT people are dragging their feet, I tell them, ‘You’re in danger of being bypassed because you’re not keeping up,’ ” Cain says.
Data security, governance and control: Let’s extend this scenario. If you have a department that’s running its own database and conducting its own queries on massive amounts of corporate data, do you think it will occur to these users to provide backup and recovery or otherwise secure this information? Can you afford your own data breech? Obviously, security must be the domain of IT, and the knowledge and skills a database engineer provides makes it easier for IT to fulfill its mandate.
Making the Move
Bringing a database engineer into an IBM i shop isn’t as easy as going to a bunch of job sites and searching on “Db2 for i database engineer.” You simply won’t find many workers out in the world who fit this description. But you do have options.
Four options for finding a database engineer exist:
- Acquire one
- Buy one
- Build one
- Convert one
The latter two options are far and away the most realistic.
“Building” a database engineer involves identifying someone from your own IT department who can fill the role. Obviously this individual would have the knowledge of Power Systems running IBM i while understanding your own business requirements. From there, you’d provide additional education and training in areas such as SQL, query optimization, performance tuning and specific Db2 solutions such as IBM i Client Access for Windows* or Data Studio. IBM Lab Services can provide assistance in these areas.
“Converting” a database engineer is, essentially, the inverse of building one. You have someone in IT with database knowledge such as a DBA working with Db2 for Linux*, UNIX* and Windows (LUW). Then you get this individual up to speed on IBM i.
“They already know about 80 percent of what they need to know about database,” says Cain. “The biggest risk is they need to accept the new platform, because some things will be different. But those that fully embrace IBM i, they love it. It’s like ‘Wow, I don’t have to do the adminis-trivial? I can just do the business stuff? This is awesome.’ ”
A final point: Your need for a database engineer may be temporary. This is actually Cain’s “buy” option. For instance, if you’re dealing with a specific performance issue, you could contract with Lab Services, which makes its technicians available to work at client sites on a short-term basis.
The role of a database engineer extends beyond IT. The database engineer interacts with business leaders and strategists, communicating IT’s goals and priorities. In addition to being properly educated and trained, it’s essential that the position be properly supported.
“The database engineer must have both the responsibility and the authority to do the job, which involves modifying the IT shop over time to make sure that data is a strategic part of the business,” says Cain. “It’s basically a matter of having the organizational willpower to support this person.”
Neil Tardy is a contributing writer to IBM Systems Magazine.