Bridging the Gap between Functional and Technical: A Telecom Story


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.Bay Bridge Lighting up at Sunset

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.


Filed in: Technical Debt
  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Razak Ellafi
Razak Ellafi Senior Product Manager
Razak Ellafi is a former Senior Product Manager at CAST and is passionate about leveraging Software Intelligence products to reduce software risk. During his tenure, Razak successfully launched several innovative IT governance products aimed at exposing software vulnerabilities.
Load more reviews
Thank you for the review! Your review must be approved first
You've already submitted a review for this item