How can you invest more in new IT initiatives by spending less on legacy applications? It’s a common dilemma faced by IT leaders within big and small companies. We’ve found that the answer often falls within the group developing and implementing software applications, not the group supporting applications. Here are five surefire ways to reduce long-term support costs through better development and implementation practices.
- Use common design patterns and development technologies: Widely adopted patterns provide proven, repeatable practices. For your interactive applications, evaluate your needs and establish MVC, MVP, PAC, etc. as a standard. For integration, determine your guidelines for real time versus bulk integration needs. Similarly, pick a programming language and stick with it. C#, Java, Ruby, PERL, etc. all have strengths and weaknesses, but one consistent language, warts and all, is better than a hodgepodge of languages developed with different technologies. A portfolio of support applications implemented with countless patterns and technologies means more support time. More time means more money.
- Standardize your hardware and software infrastructure: Whether it’s on premise, public cloud, private cloud, or some type of hybrid environment, a standard infrastructure will enable your support team to more efficiently troubleshoot problems and deploy updates. They won’t have to remember the intricacies of the Snake Eyes application that resides onsite in a virtual Windows environment versus the Scorpion application that lives in the cloud in a Linux environment. The support team also won’t require skills across multiple hardware and software manufacturers. A production environment with various infrastructure platforms means more support time. More time means more money.
- Avoid leading edge technologies without strong justification: As developers, we love new and shiny. As support specialists, we love tried and true. Many of us have experienced the pain of an implementation gone off the rails due to newer technologies not fully understood during design. Unfortunately, in many cases, the development team uses bubble gum and duct tape to get the solution into production. The support team then inherits the nightmare application with poorly implemented and misunderstood newer technologies. The support team must spend significant time learning the technologies and fixing the production hacks. More time means more money.
- Document your applications and comment your code: We often underestimate the time required to transition application knowledge to the support team. Solid requirements, design, testing, and deployment documentation coupled with well-commented code can dramatically reduce this ramp up time. Alternately, sparse or non-existent documentation requires the development and support team to spend substantial time in knowledge transfer, and the development team is often involved in ongoing support. More time means more money.
- Test your applications thoroughly before production deployment: Our teams talk constantly about how the relative ease of a project’s front end can lull us into comfort, making us susceptible to mistakes. Front-end activities like user story identification, product backlog definition, and test case development are so critical yet so easy to underperform. Unfortunately, for many projects, bad habits on the front end catch up to the development team during testing. Once again, a struggling development team often turns to bubble gum and duct tape to get across the finish line. The support team then spends considerable time rewriting buggy code and incorrect functionality. More time means more money.
You may be thinking that none of these suggestions are new or earth shattering. They just represent common sense. You are absolutely right, so start implementing them. Standard and consistent platforms, technologies, process, and documentation are critical because no one knows everything. A production environment that looks like a landfill of miscellaneous technologies requires a larger support team due to the multitude of skill sets. A larger support team means more time and more money.
There may be a Sasquatch and a Loch Ness Monster, but there are no Purple Squirrels who know everything. Besides, if there were, the development team would steal them.