Gartner Says Take A Hard Look At App Dev And Maintenance

April 21, 2014 Timothy Prickett Morgan

Making the application code and tending that code as systems, conditions, and other code around it all change eats a big part of the IT budget at most companies. And the analysts at Gartner say there is a methodical way to rein those costs in and have the funds available to apply to other projects.

Perhaps even a decent pay raise. . . .

Gartner is hosting an application development summit next month, and as is its tradition, it puts some teaser information out there to whet people’s appetite and get them thinking about what they are doing in their own shops. In a nutshell, Gartner says that on average, application development and maintenance eats up 34 percent of the total IT budget and that by getting rid of legacy applications, simplifying complex architectures, and ceasing outdated approaches to IT staffing, companies can cut those application development and maintenance costs in half.

“Most organizations tend to assume that the cost of ADM can only grow over time due to rising labor costs and the increasing complexity and number of applications,” explains Claudio Da Rold, a vice president and distinguished analyst at Gartner, who tracks application development. “The ADM unit cost can be significantly optimized over time, provided that best practices across the application and sourcing life cycle–strategy, selection, negotiation and management–are followed.”

The common practice in the industry, says Da Rold, is to think tactically about application development and maintenance, asking a few services companies to step in with programmers to compete on price to do any work the inside programmers can’t or won’t handle.

The first thing companies need to do is stop winging it. That means doing an application portfolio audit to find out precisely what applications are running in the company, what they are coded in, how they are linked, and how relatively modern that code is, and at what point in their lifecycle they are at. All code should not live forever, and much of it really belongs in the bit bucket.

Once you know what you have and the relative vintage of the code, you can start grouping applications together and presenting them for replacement or modernization efforts to the CIO, CFO, and CEO.

Personally, I find it hard to believe that as much as 17 percent of the total IT budget can be saved, but perhaps at large companies with thousands of applications and hundreds of programmers, this is true. I wonder how far this data can scale down into the SMB space where most IBM i shops are. The typical IBM i shop has one, two, or three programmers and in the smallest of shops they are often doing double duty as system administrators and VPDPs or CIOs at their companies. But, that said, getting more organized and methodical about the application portfolio is a good thing, and at the very least it helps the next programmers who come into the company get a handle on what is in all that code that runs the business. As for having multiple sources for programming, sometimes the cost is not as important as the quality of the code, and that has to be a weighing factor as well. IBM i shops have shown that they are willing to pay a premium for a better product when it comes to their systems, and I suspect they take the same attitude–and pride–with their programming, whether it is in-house or outsourced.