Colin Oakhill isn’t just a management consultant at Insoft Infotel Software GmbH. With extensive experience in database systems such as IMS, Total and IDMS, plus a wealth of knowledge around z/OS and CICS systems, Oakhill is one of the foremost mainframe database experts in Europe. InSoft created a number of groundbreaking products, including the DB/IQ family of software beginning in the mid-90s, and the company eventually joined the Infotel Group in France via acquisition in 2011.
We sat down with Insoft Infotel’s Oakhill (the father of DB/IQ) and Linda Langenbach (a 30+ year mainframe subject-matter expert) to pose a few questions about the origins of the SQL code quality assurance product and some trends they are seeing in the marketplace affecting DBAs, developers and DevOps professionals.
1. What changes have you seen over the years with app development approaches for the Global 1000? How have data security mandates (GDPR, CCPA, etc.) affected app development?
Oakhill: If you think about development in the 1980s, there was no internet around. Anyone developing applications found it very difficult to get information on what they were dealing with – especially in countries like the United States where people aren’t always working from corporate headquarters and the geography is spread out. They could be working from home, connected remotely to their mainframe via modem, all building apps in separate silos. They had no user manual, no access to the internet, no coding standard that told them to all build apps the same way. They really couldn’t get their hands on the information they required to make them more effective developers.
Things started to get better in the 90s when the internet got rolling. Developers got much more information and there were far more tools available. By the time the Y2K scare was on the horizon, companies were building their own internal check-in teams and software to perform date manipulations and simulate how applications would react to the change from 1999 to 2000. Of course, this measure ended up being largely unnecessary on the mainframe – it was really the Windows and open systems that needed updates. But it really illustrated the code quality of mainframes over that course time.
Langenbach: We’re at a turning point for the mainframe world and there are three ways the market is looking at things now. One group has been thinking for years and years about getting rid of the mainframe, but they are way behind with everything they do so they can’t. Another group has outsourced their mainframe needs; they need the mainframe power and processing, but they don’t do it in-house. The third group are saying ‘we are in the mainframe and we are going to stay in it’ : these are the companies we are working with at Insoft Infotel.
So this is what companies are dealing with now, these complex environments for mainframe. Some are outsourcing the mainframe environment – the Db2, the systems – and the third-party provides the environment, the development is still on premise. Other companies have the mainframe but outsource the mainframe development elsewhere in the world, then test on-site. Both types of organizations desperately need a code quality software solution to help manage how their applications are built.
There’s also talk about going into the cloud but there are so many data regulations to overcome and related data security issues that we don’t think that is going to happen anytime soon.
2. How does separation of workflows (work silos) affect app development in large organizations with developers around the globe working on the same project?
Oakhill: People and teams are working toward the same objective. They’re often in close proximity, but that doesn’t mean they’re sharing important information. When people aren’t talking to each other and they’re not communicating, it can lead to wasted time on coding because they both could be coding differently than how their organization wants them to. This leads to missed opportunities for getting applications to production on time.
As far as the various groups – the DBAs in test environments and DBAs in production and developers across the globe – that are all working on the same application, there are really three different kinds of siloes. The two DBA groups do not necessarily need to work together that closely – they both have their own environments, they both have their own problems. They might have to deal with each other in perhaps just 10% of their work.
That means when someone in the test environment finishes his DBA job and is promoted or migrated to production, he’ll know about the application. But all the problems that he’s been through in development will not be valuable for production, and all the problems someone goes through in production will not necessarily be valuable for someone in tests. So, these two are pretty much independent of each other.
What’s really important in terms of communication is the developers. If they’re working across the globe, they really need to communicate with each other in some way. If they don’t communicate, there are going to be lots of expensive problems coming down the line.
3. Has Agile helped at all with the above?
A system using Agile programming forces the development staff to share information. They have to share in order to complete sprints, these so-called scrums, and they share and make sure everybody knows what they need to know about their tasks and responsibilities – this is the great idea behind Agile programming.
And because they are sharing, they can collaborate from the beginning of the dev process to have applications delivered faster. App improvements are delivered in smaller chunks, more frequently, versus the old way of delivering everything at the end of the project, or the old and slow Waterfall method.
4. How can DB/IQ’s QA tool keep developers up to speed with the latest best practices?
QA can definitely train developers on how to code their SQL statements. There’s a knowledge transfer going on there because we have our years of experience built into the software itself, which includes more than 350 quality rules “out of the box.” If they’re coding things that are not up to the standards that the company has set up or not in line with rules of thumb that we know about, then they’ll get messages accordingly and they can adapt. They’ll get explanations why they should do it this way or not do it this way, so they’re getting training on the job more or less just by using this kind of software. The GUI-based Eclipse tool will also give the DBA an estimate of the cost of not coding to the organization’s standards.
5. How does quality of developer training affect application quality?
In earlier days, developers would always remember what they coded when it wasn’t good. If they coded an application and it was a performance killer, they probably wouldn’t code that again in the next application – not immediately, anyway. Maybe two or three years later when they forgot about it and repeated it again. Using a code QA tool, they won’t make the same error because they have to change the SQL statement to adapt to the standardized rules built into the system. They see the code is performing a lot better and are proud of what they are building so they’ll remember it a lot more easily. Our code quality tool is a training tool designed to improve the quality of applications the more it is used. This is really intensive training on that kind of programming, and as we’re independent of programming languages here, we’re talking across the board.
6. Do developers care about code quality when they put something in production or do they just “get it out the door” and move on to the next application?
Obviously if they’re doing 60+ hours a week then they’re not going to care about the quality – they just want to get their job done as quickly as possible. Today, with newer applications being written in Java and different generation languages, they don’t really know what’s being generated – they don’t really know about the quality of code coming out of these code generators.
When it comes to code quality, it’s an 80/20 ruling. 80% don’t care, but perhaps 20% do. That’s also ruled by the kind of development. If you’re talking about applications maintained by developers who are 50+ years of age, in the next few years these developers are going to be retiring. But the applications they built over the years will still keep running, and someone needs to maintain them. It’s already a problem and it’s only going to grow larger in the future.
If you have a system like QA in place, it’s a lot easier for someone to look after these applications. It’s already checked the SQL statements and made them more simple to understand, so it’s easier for someone else to come into the application and understand what they’re up against for years to come.
7. You have said that DB/IQ QA can “audit an application’s improvement or deterioration.” How does this function work?
If an insurance company decides to pass one of their applications across to India for modification, they can set up specifications with QA, saying ‘We don’t want to see any SQL statements accessing our mainframe doing this or doing that, or costing more than a certain amount.’ If the application delivered to the buyer isn’t built within these specifications, they can send it right back. QA makes it very easy for companies to ensure they aren’t investing in rubbish code and poorly performing software.
What QA does is track its results over time periods. If someone’s compiling applications and QA is checking the results, it can stamp those results into a database. We call this the history of results. In this history database, a major DBA or manager can pick up the results for a whole month. Say, for example, I have a hundred people working in development – they’ve been through the QA process 10,000 times this last month. Say in January we had 8,000 defects, where QA indicated that something was not allowed. Then in February, it went down to 5,000 times. Then in February, it went down to 2,000 times. Although the same amount of data was being checked automatically by the system, a manager can clearly see that the quality is improving. That’s the idea with auditing over a period of time – to measure improvement or deterioration and act accordingly to ensure best practice.
8. Can one poorly-performing app or ABEND obliterate a department’s budget?
We haven’t seen that directly, but it can be problematic indirectly. One of our DB/IQ customers was a large bank with an application that would ABEND and shut down ATMs for 24 hours at a time. When that kind of bug comes up, it gets through to the board of directors pretty quickly and that’s what happened here. When that development staff goes to the board and asks for additional money for more tools later on this year, they are going to have a difficult time getting the funds. Budgets can certainly be obliterated by one poorly performing app. It doesn’t happen too often thank goodness, but it did happen that once.
9. It seems like this product is like medicine for business applications – you can diagnose a “sickness” and offer treatment. Is this an accurate portrayal?
Yes, that is accurate but more accurately, having a product like QA can help take a step back and see the forest from the trees. With QA you get a holistic view of what’s happening in your application development and we can assign a cost factor to the potential of the problem. A better analogy would be if you wanted someone to stop smoking in your place of business. You could put a sign up that says “No Smoking” and maybe some people would pay attention. But if you put a sign up that said “If you stop smoking at work, you’ll save $100 a week.” Now that would get some people to stop smoking for sure!
