Secrets Of IBM i Magic Act Revealed
April 17, 2017 Dan Burger
Can IBM i shops find a way to replace their RPG-oriented staffs with magicians? The answer, in many cases, is that they already have. The RPG staff members are the magicians. They’ve abra-ka-dabra-ed their way to doing more with less for something like 30 years. The clever companies employing these magicians have parlayed this IT staff magic into new technology investments that perpetuate the more for less phenomenon.
One of those technologies is the modern managed services provider, which causes system management to disappear and gives the IT magicians something new to work on . . . like database modernization, for instance.
As IBM i shops strive to remain competitive but are facing several challenges: skyrocketing technology costs are rubbing up against unyielding IT budgets; intellectual property invested in heritage applications need to be retained and leveraged, but advances in analytics, cloud, mobile, and database engine technologies cannot be ignored; and problem solving through database modernization remains largely untapped.
“In the early years, developers were often forced to create monolithic programs, as that was the programming model of the time, due to compiler restrictions.” Marinus van Sandwyk notes. “As a rule of thumb,” 80 percent of the lines of code in these monoliths dealt with database relationships and database validations. Additionally, there was little-to-no separation of function, which made maintenance increasingly problematic as we now see massive maintenance backlogs and frustrated users.”
van Sandwyk is in the database modernization business. He is the founder and CEO of TEMBO Technology Lab, a company specializing in DB2 for i modernization. The company just released a white paper titled The Essential Guide to IBM i Database Modernization.
“IBM i shops realize the need to modernize their databases,” he says, “but most have no idea where to start. They are stuck in analysis paralysis.”
Old database techniques, which in many cases are still being used today do not use DB2 to its full potential, which includes reducing the amount of coding at the app dev level and creating a database that is better integrated with other databases. It’s an ongoing productivity bottleneck for companies that value their application investments and reinvestment. A modern database also becomes a priority project for those who foresee database integration as becoming increasingly important.
Maintaining database status quo is rooted in cultural preferences, a lack of investment in skills, and a misunderstanding of the benefits a modern database provides. DB2 is a modern database. It just isn’t used like one.
“We find it remarkable that people say the average IBM i programmer resists change,” van Sandwyk says. “We’ve found quite the contrary. The reason the developers fall back into the old methodology is because of pressure from the C-suite to deliver functionality a rapid pace. That prevents the transition to data-centric design constructs. If provided with a mechanism to gradually transition, we see IBM i developers quickly adopt the new ways. We have clients that have done this.”
Data-centric development allows the database to do more work keeping track of and securing the data. SQL becomes the database language, which, for some developers, is a new way of combing their hair. On the application side, the use of SQL by IBM i programmers has been on a gradual but steady climb in recent years. The data-centric database emphasis has yet to benefit from that.
Companies that have started down the path of modernization making the user interface a priority. That process often opens the door to other areas that could benefit from modernization. The database is the most obvious.
“If it’s not an application modernization project that focuses attention on the database, it is company growth that puts pressure on the existing database,” IBM i business architect Tim Rowe told IT Jungle during an interview in 2015. “The recognition that SQL can be the answer for a database that is growing and projected to keep growing is another instigator of database modernization projects.”
“Not everyone is going to completely modernize their databases,” Rowe says, “but there is a component to that process and a desire to leverage that technology. Many of the projects I am aware of are iterative. Companies pick and choose pieces of the database to modernize over time. It allows them to start with small bites that provide benefit.”
“Our philosophy is modernize as you maintain,” van Sandwyk says. “Focus on the application elements that are not delivering what is required. There should be as little disruption as possible. Disruption increases risk and increases the resistance from users.”
IBM i shops that haven’t made the database investments are facing some decisions that will affect the future of their organizations and can’t be kicked down the road much farther, unless the company is in slow growth/no growth mode. Naturally, there is hesitation to increase IT operational budgets unless revenue gains are certain to follow.
According to the most recent IT Spending and Staffing Report from Computer Economics, the number of companies increasing their IT budgets is the lowest since 2013 and within that slice of organizations that are making IT investments, the expected increase in IT operational budgets is a meager 2 percent.
Efficiency and productivity gains are tied to cost reductions, which play a role in revenue gains, but improved integration with other databases belonging to business partners in the supply chain or customers in business-to-business transactions is another factor.
“The perception of the DB2 for i database by the outside world is problematic,” van Sandwyk says. “We define our database differently than the outside world. The six-to-eight-character field names are an example of the database presenting itself as legacy. Outsiders need a technician to explain the naming. The transition to the SQL database engine is a big hurdle for the average IBM i development shop. To make a smooth and successful transition, it must be gradual, but using DB2 to its full potential is part of the data-centric development skill that pays off.”
RELATED STORIES
SQL And Database Shine As Next Tech Refresh Approaches
DB2 For IBM i: Made But Not Mastered
TEMBO Adds Development Tool to Database Modernization Kit
IBM i Execs Put Database On The Map
No Seats At Cruikshank’s SQL Database Sessions
“We find it remarkable that people say the average IBM i programmer resists change,” van Sandwyk says. “We’ve found quite the contrary. The reason the developers fall back into the old methodology is because of pressure from the C-suite to deliver functionality a rapid pace. That prevents the transition to data-centric design constructs. If provided with a mechanism to gradually transition, we see IBM i developers quickly adopt the new ways. We have clients that have done this.”
I’d call that a textbook case of volunteer bias.