Challenge: Support calls drained resources
Greg Perrott, Software Architect at RBNZ, is responsible for the performance of several critical financial applications. He works with a team of 15 developers on the support, maintenance and enhancement of existing applications, as well as development of new applications.
When an end user calls the helpdesk, resources are shifted from proactive to reactive tasks. This meant that Perrott's team was not as productive as it could have been on other projects. “Our ability to deliver enhancements was greatly affected by support,” Perrott said. “There were occasionally periods of a week or more when no development progressed because of ongoing support issues.”
Slow transactions and stalls related to .NET services were persistent problems. Because time-series data was calculated on-the-fly in application logic and memory (rather than using stored procedures in the database) some requests took too long to complete. Perrott's team found they had to extend the time-out period for the client in order to reduce the number of failed transactions. “It wasn't ideal because the end user still had to wait, but at least that way the application would eventually return data,” Perrott said.
Targeting these transactions was an ongoing project for Perrott, but without adequate visibility into the application, it was a daunting task. “Without access to production data we simply couldn't find which areas we needed to redesign in order to improve the slowest services and scale the application,” Perrott said.