Cost cutting is a major focus for the C-Suite, making it a top priority for modern technicians. While technicians in the ‘80s and ‘90s could generally ignore the costs of their platforms and enjoy playing with machine specs, parameters and SMF data, managing the cost of running a data center is now an important part of our daily jobs.
Distributed computing always looks cheaper, in part because the costs are often distributed. Processors are typically purchased as a one-time, capital expense and with a variety of software licensing methodologies, other various expenses are rarely summed up in the ledger the way mainframe costs might be. In addition, chargeback is much more difficult (when attempted) because the metrics we use on the mainframe often don’t exist in granular enough form on UNIX, Linux and Windows platforms.
Your challenge is to find ways to reduce mainframe costs and make the value proposition even more attractive. Cost is not the only factor in a value proposition, but efforts to reduce costs are always appreciated and recognized. While some options are probably already underway (i.e. reducing software costs through IBM’s Variable Workload License Charge (VWLC programs and exploiting zIIPs) there are other options you should consider.
The next best path to reducing costs is getting on top of technical debt in your application code. Technical debt is a fancy word to describe inefficient, clunky and sometimes terrible chunks of code. While it might seem impossible to believe that so much technical debt exists, when you consider how it came about it makes sense that it’s present in every code module in some form, across every platform. Technical debt begins when a project is pushed too hard and developers take shortcuts. It also emerges in a number of ways; when beginning coders are challenged to write programs beyond their current ability, when a company provides poorly articulated specifications to its team and even when code is copied and modified without an understanding of the underlying purpose of the code. A lack of documentation also adds to the challenge. If you’ve ever written any code, ask yourself if you’re a part of the problem. How much documentation have you written? I confess myself guilty of this, along with a fair amount of technical debt; in the early ‘80s, we considered assembler to be self-documenting.
Bad code causes a great many problems, most of which are costing you money. Overall, industry analyst, Capers Jones notes in “Software Quality in 2011 – A Survey of the State of the Art,”
“Poor software quality has become one of the most expensive topics in human history: $150 billion per year in U.S.; $500 billion per year worldwide.” He also noted that programmers were “less than 50 percent efficient in finding bugs in their own software.”
Costs come in concrete terms—hardware and software—but there are also significant costs in other areas. Performance can be sub-optimal due to technical debt and in some cases availability will be less than desired. These two alone can lead to the loss of a customer base. Maintenance of existing software can take much longer and cost more as developers struggle to add new features and find that any changes result in problems. It can even be difficult to figure out where to start. The biggest challenge for many companies is when code designed to support modernization efforts fails to do so because of long existing code problems. For others, these coding problems lead to security exposures.
So what’s a mainframer to do? You’re probably sitting on millions of lines of code. Where exactly do you start? You want a really smart automation tool that can help you find these problems, including badly cloned code. Once you have a database of issues, you can prioritize and manage them based on the importance and value of the application. When the debt database is created, you should engage in continuous process improvement every time you have to touch an application. Check the database and pick the biggest issues to fix before adding other required maintenance. Document wherever you can to make future modifications easier. After all, it might be you having to make the next change.
Another opportunity is refactoring, where you focus on reducing complexity without changing external behavior. Once again, automation can help you with this. Refactoring alone can often reduce bugs or security vulnerabilities that you hadn’t previously detected.
If you’re not in development, team with developers to undergo this effort. The improvements in performance and availability will make it worth your while.
By making an effort to continuously improve code while having a quality assurance group monitor and reduce technical debt, you stand to reduce costs, time-to-market of important features and security vulnerabilities while improving overall performance and availability. Exercise these practices, communicate the value of them and prepare to see your career soar.
Denise P. Kalm is chief innovator of Kalm Kreative Inc.