Business Strategy Bumps Into Database Deficiency

November 28, 2011 Dan Burger

Most IBM i-based companies do not have a well documented database. It’s likely to go unnoticed until new business requirements uncover the rat’s nest as plans to extract more information from data through business intelligence or advanced queries run smack into database policies that are haphazard or relics of the past. The IBM i operating system includes a modern database management system, but it is limited by data that is poorly defined. To one degree or another, everyone is having this problem.

The solution lies between two extremes. On one end is not understanding how to solve the problem and so nothing gets done. New business requirements are perpetually put on hold. On the other extreme is the decision to start over and rewrite the database. Typically that involves a different platform where staffing has modern database skills that meet new business requirements. Starting over is needlessly expensive. The value of business logic in the existing database is completely disregarded or vastly undervalued until it becomes apparent later on in the rewrite process pushing the return on investment on that decision into the next ice age.

A much better choice is found between those two crippling options.

But first a few words in defense of the “If it ain’t broke, don’t fix it” viewpoint. There are businesses or specific parts of businesses that are doing fine with existing database performance. Wall-to-wall changes are rarely necessary. Existing IT infrastructure can almost always be enhanced and extended to meet business requirements.

“There is a series of steps that begins to put more knowledge into the database so the database management system understands the data,” says Mike Cain, one of IBM‘s top technical brainiacs for DB2 on i. The benefits, he says, are realized because the management system is able to do more and the programmers have less application coding to do. And beyond that, it greatly expands the capability to solve business problems.

“I’m talking about existing applications that have been running for 20 years and continue to run and meet business requirements. This is about how to extend and enhance those applications to continue to meet business requirements moving forward,” he says.

Getting a handle on what Cain calls database re-engineering (also referred to as database modernization) begins with identifying business requirements that drive the need to make changes. It’s a process of prioritizing business pressure points and looking for gaps in the current technology.

Understanding the current state of the database and the technical requirements for enhancing it fits in with the forward-looking business goals. And, of course, it has to make sense in terms of return on investment.

Understanding what it takes to create a good data model and good database design from a data-centric perspective is important. So is application development from a database perspective.

“Prioritize the business goals and the target areas,” Cain advises. “They could point to finance, inventory, sales, or something else. Look at the state of the database as it affects those specific areas. Compare what is there with best practices and what the future state of the database should look like. Look at data growth and growth rates. Many organizations are experiencing data growth and have no plan for effectively dealing with it. Get a handle on the velocity of growth. Understand the types of data being stored and whether they are being accurately represented.”

Good data modeling means good relationships between all entities and it’s done in a fashion that allows the database to understand these relationships. A common occurrence is that relationships are only known by the programmer. This is not efficient database management. The better option is data-centric processing. The database management system needs to understand the data so it can do more work and the programmer can be more efficient when writing code.

Cain has examined more DB2 on i databases than possibly anyone on the planet. He routinely finds substandard data modeling. Sometimes there is no data modeling whatsoever. How each table and file is stored and the relationships between tables and files typically could use some enhancement, he says. It’s not normalized and the relationships are not defined by the database.

Determining the cost and the amount of time necessary to make the changes is a function of the discovery phase.

Let’s say the business objective is to get more out of an order-entry system. Then that becomes the focus. It is necessary to understand the number of files, the current state of those files, and the data in them in order to determine what needs to be done, how long it will take, and to determine an estimated cost. If all the data is in physical files and logical files, there will be a process to convert them to SQL-based objects. The length of time it takes will vary depending on the overall condition of the data.

Details that Cain pays attention to include fixing anomalies in the data model, making sure every file has a primary key, and that strong relationships between files exist. Everything is done on a file-by-file basis. Estimating time and cost is based on the number of files and how much information is uncovered in the discovery phase.

There are tools and processes to help automate the project, but determining how many files, what shape are they in, and what are the business requirements are the keys to estimating a project time frame.

A lot depends on project leadership.

“This isn’t just about what an organization wants to do, but also pointing out what it needs to do,” says Cain. “It’s understanding business requirements, reconciling conflicts, understanding technical requirements, and doing analysis. Are you taking data out of applications and putting it somewhere else to meet business requirements? Most are. Are you dissatisfied with system? Do you understand why the current system is not meeting needs? Moving data to another system is not always the best idea to solve business problems. If there is no person with that responsibility or knowledge about the database on the IBM i, but there is someone with that knowledge on another platform, then that other platform gets the attention.”

The thing the DB2 for i database needs, more than anything else, is a champion.

“In many cases data is being moved off the IBM i database because there’s a champion, someone who can articulate and fully understand the capabilities of those other platforms from a database perspective who are winning the day. We need people on our side who appreciates and understands database capabilities on an IBM i.”

So, is that going to be you?

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search