The IBM i has one of the best databases in the world. We’re just using it wrong.
Now that I have your attention (and possibly also a few angry comments), let me explain what I mean. It’s a fact that DB2 for i is one of the best databases in the world. This is not something that we just discovered; it’s something that most of us have known for years. However, the functionality provided by that database has evolved over the years, and most (I’d dare say, almost all) applications weren’t updated to make use of those changes. This wouldn’t be a problem if the data volume processed by the applications hadn’t changed. However, the ever-changing nature of business needs (and a little thing called the Internet) made sure that different data and, more importantly, more and more data storing and processing capacity is required to keep up with the competition. What happened in most shops? The systems’ hardware was upgraded, and more workers were hired…to keep doing things the same way!
Since it wasn’t “broken,” nobody “fixed” it. Nobody stopped to think that a proper redesign of the database or even a much simpler use of embedded SQL to replace low-performing sequential reads in data-hungry programs would be a good idea. It’s interesting to see that the myth of embedded SQL’s poor performance is still current in many shops. It’s part of an almost irrational fear of change that runs deeply in the IBM i technical community, which helps to keep that “old and outdated” image that our beloved system unfairly has. Well, it’s time to start changing that!
DB2 Evolved—And So Should We
The DB2 evolution encompasses performance improvements, new data types, new and extremely useful APIs, and a lot more. The problem is the usual “if it’s not broken, don’t fix it” dogma that we’re forced to live by. A database modernization sits somewhere between code modernization and UI redesign, when it comes to getting management support. You can sell it by saying that less-cryptic field and table names (not shackled to the 10-letter limit of DDS) will help users create their own queries more quickly and with less IT support. In turn, this can potentially increase user productivity and free IT resources for other tasks, perceived as more profitable (by the managers) and interesting (by the IT people).
It’s also interesting to note that sometimes the “old and outdated” label comes from the performance aspect of an application. You can have a great green-screen front-end, tailored to the business needs, as good as DDS allows, and still get that bad vibe from users. Why? Well, for instance, if a program is using sequential reads or chains over five different files instead of a SQL SELECT statement over a customized view built on those files, you’re not making use of what one of the best databases in the world has to offer!
But There’s More Than the Database
At this point, let’s sum up the possible modernization approaches you can take:
- Code modernization—This can be achieved by taking advantage of the knowledge about ILE the “RPG Academy” article series provided and by writing structured, modular, and easier-to-maintain code. The TechTips of this modernization series thus far should have given you a solid foundation for redesigning your application structure. The next subseries, which discusses the MVC paradigm, should also help with this modernization area.
- User interface modernization—Listening to your users, redesigning your ages-old green-screens to something friendlier, and, if you’re up to it, migrating to a graphical UI are the steps to take in this area. I’ll provide some pointers on choosing the right tool for the job at hand later in this series.
- Database modernization—Modernizing the database can be a complex process, but there are tools to help you. I’ll provide some guidelines and examples on how you can proceed in a few articles, but my latest book, SQL for IBM i: A Database Modernization Guide, goes into greater depth and takes you on a guided tour of what an application modernization process (usually) entails.
This essentially sums up how to modernize your application, but before going into details, it’s important to stop and ask yourself the million-dollar (or sometimes, even more than a million) question: Is my application worth modernizing?
I’ll discuss that topic and provide you with a few pointers (with the generous help of recognized experts in this area) in the next TechTip of this subseries.