A New IBM i Team Is Needed

August 5, 2013 Dan Burger

Sparks will fly when application development teams get this news. Someone set the stun gun for high voltage. Let the yowling begin. Management has decided that following an IT strategy that was begun in the last century is not appropriate for this one and a decision has been made to move from application centric development to data centric development. IBM midrange shops shudder at the thought of this, but here’s a scenario where it could come to pass.

Mergers and acquisitions have put a small to midsize company into a much bigger arena. And in this hypothetical situation let’s say the number of products has doubled. The number of customers has doubled as well. And it’s no stretch of the imagination to formulate the geographic area being served has multiplied by a factor of four. The new supply chain dwarfs the old one.

With this comes the realization that the database is unable to keep up with the business expansion, and the executive management doesn’t want to hear that kind of news. They want answers, not excuses. If you can’t make that DB2 for i database perform, there will be replacement systems lined up before you can say, “Get the database administrator in here right away.”

Oh, yeah. There is no database administrator. Never thought we needed one. Never thought this day would come.

Maybe this would a good time for an IT skills assessment. Someone on the application development team must be well acquainted with the database. That could be true, but more often than not that person or persons will see the database from an applications perspective rather than a database perspective. And more often than not it will be a database view that has remained unchanged since the days of the System/38 or System/36, depending on which side of the tracks they started out on. It’s an applications-first perspective that mostly ignores the power of the database and data-centric development.

When application developers and operations personnel possess modern skills the transition from application-centric to data-centric development is much easier, but all is not lost even if development skills are somewhat less than fresh. As long as you can assemble a team of on-site employees–who share a vested interest in the business and the longevity of the company–there’ a good chance for success. It would help if they also had a vested interest in their careers, which includes an interest in modern technologies, even if they haven’t had an opportunity to put that interest to use in the past.

Dan Cruikshank has been in circumstances that call for database team building of this order. His strategic perspective is decidedly data-centric and he’s helped companies successfully navigate the transition from application-centric development to data-centric development. Team building is the number one priority in his book. He looks for team members who can grab hold of the strategy and understand that data keeps companies in business. Protecting data is a large part of the strategy and data-centric development is a better way to protect data because data access is better controlled.

“This is not a team to outsource,” Cruikshank says. “The team members are a close partner with the business.”

The team trains so everyone is brought up to date with the capabilities of the database. Beyond the security aspect, there’s the coding at the database level that reduces the coding at the application level, which ultimately saves time and money. Cruikshank says it could take from one to three weeks to train a team in data-centric development, SQL/DDL optimization, and the use of modern tools. If the company is growing, he says, it won’t be using DDS, a methodology tied to green-screen development.

In a data-centric approach, some of the activities that have been traditionally part of operations and application development will become the responsibilities of the database team–especially the creation and management of the database. Taking away the creation of database artifacts from the application developers seldom occurs without pushback. In fact, the word seldom may be an overstatement.

Cruikshank has wrestled these alligators more than a few times and has pulled projects from the jaws of defeat. He lays the cards on the table face up.

“There’s no reason for the application developers to be creating physical files, logical files, triggers, functions, procedures, or handlers,” he says. “The database team takes care of it and gives the application developers their view of what they need. Same with the end users who want access to data for business intelligence. They get a view. But there’s no direct access to those objects outside of the people on the database team.”

Although the application team continues to use the same language for reads and writes, you may know developers who would bristle at the thought of “limited” data access and database development that replaces traditional application development. But if executive management has already been convinced that database modernization is the correct strategy, individuals throwing up roadblocks do so at their own risk.

“Every manager has a tool,” Cruikshank quips. “It’s a two-word phrase: ‘You’re fired!’ Those people who can’t learn something new can go on their way.”

Cruikshank refers to this low tolerance for complainers as “The Cortes School of Management.” (Cortes was a Spanish conquistador during the 1500s. He was not particularly friendly with those who impeded his progress.) Cruikshank’s motto is: “We’re going forward. There’s no going back.”

An important part of this story when it comes to explaining it to executive management is the existing investment in the IBM i platform, which has the integrated DB2 database. The system is already purchased and it also contains SQL support, security, virtualization, and single-level storage. There are no separate databases to purchase, which would be the case if the proprietary DDS-based DB2/400 gets replaced. Knowing that DB2 for i is a modernized version of DB2/400 is part of understanding what a company already had and being able to make an informed decision on what needs to be purchased.

The development tools (graphical not green screen) include free items such as IBM Data Studio, DB2 Express-C, and Application Diagrammer. That’s not to say everything can be done with free tools. That depends on the project. Data Studio allows all development and the storage of artifacts to be done offline. And DB2 Express-C can be used as a test database prior to the database conversion.

The tooling also provides the capability to visually examine a database and see entity relationships, check referential integrity, do physical data modeling, and maybe even perform reverse engineering.

Details of the visual database tools could fill a separate article. That’s for another time.

Making a case for database modernization involves tooling, and it’s important to know what is available in that regard and to know that IBM is spending more research and development time on DB2 for i than any other area of IBM i development. But the bigger pieces to this are training and teaming learning new technologies that make the database less proprietary and more interoperable and selecting the database team, which is a new way of thinking for IBM i shops.

Training, teaming, and tooling all have an important role to play. Bad attitudes and a lack of information about what DB2 for i can accomplish, will ruin any attempt at building a new team for a modern business.