For IT software development, there are few industries as challenging as the telecommunications industry. Telecom service providers rely on sophisticated software for the management of their network as well as for all their key operations, like accurately billing customers for their phone calls and internet access, and taking good care of their clients.
The challenge is that telecom’s billing software ranks among the most complex software systems in the IT world. What makes it even more difficult are regulations, marketing, and constant competition that requires frequent and often complex changes of billing systems that need to happen at breakneck speed.
To help put this into perspective, a typical telecom billing system usually involves a set of several applications with upwards of 10 million lines of code, written in four different programming languages: C++, J2EE, high-availability COBOL, and Oracle PL/SQL.
The size and complexity not only makes software development a daily challenge, but is a huge barrier for testing the system before a release. In such environments, it is not possible to cut corners without taking important risks. And just one bug can cost millions of dollars.
But in order to meet scheduled releases, it is necessary to optimize testing and concentrate the resources of Q&A and acceptance teams on the areas and features that have been modified or impacted by these changes. However, given the size of these systems, this cannot be left up to guesswork.
I had the chance to work with one of our telecom customers who asked us to help its testing and support teams meet the challenge of regular releases of its huge billing system.
Its requirement was presented this way: “We need a link between functional and technical language.” This meant it needed to know which functional transaction and features had been modified due to any underlying technical change.
We came up with the idea to map user transactions in the source code from end to end -- from the GUI, down to the deep backend, through all the technological layers. And by analyzing two versions of the applications, we were able to show our customer the modified transactions by identifying whatever code or layer have been changed.
The results -- pushed via a dedicated CAST dashboard -- quickly helped AD, Q&A, and testing managers make the best use of their limited resources and avoid costly billing bugs in production. Managers now found themselves in a new position: They were able to bridge the gap between technical names or objects and functional ones.
After a while, we even found that this technical-to-functional information could be used widely within the IT organization. Not only was it helpful for development, Q&A, and testing, but it was also useful to user-support teams. Whenever they had a call from users about a change or a malfunction, they had the opportunity to immediately check if that feature had been modified in latest release, without having to send a request to the development team.
In most organizations, IT is seen as a foreign land with natives who speak a strange language and participate in esoteric rituals. But the fact is, with the right translator, you’ll find that IT is made up of people just like you and me. They’re devoted to helping you achieve your business objectives and they have the tools to make that more efficient than ever.