Welcome to the RevX Billing University Library where you have access to topics that highlight solutions to a variety of customer challenges. Our technology and market experience combine to create a powerful tool that will accelerate your go to market effort. These articles have been authored to capture some of the obscure things many customers fail to consider in their decision making process. FREE access to this repository while seemingly proprietary in nature, only serves to enhance our working relationship because it brings depth and clarity into our conversations by establishing that operations and billing are a detailed part of your business and we have your back!

INTEGRATIONS - they're not all the same.

We're often asked can you integrate with this or that? It should be easy, probably 1 or two days (right!?) ... that statement and reality are often times very far apart from one another and for various reasons.

1) INTEGRATION SCOPE - The goal of any integration is to seamlessly bridge two systems in such a manner the two functionally become one indivisible cog in the back office of a business. The manner in which these systems communicate is enabled through the use of API's ... the purpose of these API's are to facilitate the exchange of business information generated by the operation of the business. The first and most common challenge we experience regarding integrations is incomplete API coverage. Meaning, not all functional operations of a given platform are accessible via API. API’s are often an add-on technology which is bolted onto an existing platform to expose “some” of it’s functions via an integrated experience. Because of this dilemma, we (RevX) stick with a strict policy of 100% functional coverage with our API. As a result, it can be challenging to fill in the missing gaps when the API doesn't go far enough ... this translates to time and more source code to implement the missing functionality. Examples of this in the MVNO world are things like mid-cycle rate plan changes, device IMEI swaps on active SIMs, and SMS messaging to the edge device.

2) ERROR HANDLING - Error Handling and workflow awareness - this is a critical one. API's we often see utilize a fire-n-forget pattern that I liken to those old-fashioned vacuum tubes used at banks we all experienced in the 70's and 80's where a customer stuffs a business request into a tube and closes the door and a human receives it and fulfills the request. Since the point of integration is to automate (eliminate human intervention), we can't rely on humans to interpret exceptions to the communication flow. Suppose an empty or incomplete request is sent through the tube, when the human on the other end receives it, they engage the speaker and ask the customer what they need because the request was either ambiguous or otherwise incomplete. This condition is pervasive in the integration space. Meaning, the integrating party is left to implement their own functional experience around how and what to do when calls with the API are incomplete and/or don't result in the expected outcome. This is an expensive and time-consuming process and varies dramatically based on the maturity level of the system being integrated with. Really good examples of this in the MVNO landscape are platforms which don’t utilize proper error handling. Meaning, the integrating party is forced into a pattern of development that requires polling and asking the hosting system … are you done yet … are you done yet … are you done yet? This pattern has never been a good choice for robust or even reliable systems development. Yet, we often see this in the telecommunications landscape, and we build a facade around it to emulate good error handling practices. As a result of this pattern, it casts some doubt on the reliability of the final outcome of a given API request. For instance, suppose a hosting platform requires polling to ascertain if an attempt to activate actually successfully finished. Suppose the integrating platform had been polling for 20 hours and finally gave up (timed out), yet the hosting platform actually finishes the work in 22 hours … the integrating system is burdened with that workflow all because of how the exposed API’s don’t provide a quality, reliable, and synchronous (sequential) response to the API call. All of these holes have to be filled in and coded.

3) SUPPORT and DOCUMENTATION - This one is particularly challenging because of the technology landscape. There are popular methods for generating self-documenting API's with products like swagger, but sadly these simply fall short because they focus on documenting the details of data types and data structures instead of functional narrative and context. This isn't to say you can't do that with these products, it's just that it's often overlooked because from the outset, it is presumed from the beginning of developing an API layer to an existing system that the tool will generate your documentation so not much effort (if any at all) is afforded for technical writing when it absolutely should be! As a result, integrating parties are left to fend for themselves to define boundaries around the business information and its relevance to an integration. These are often times guesses which lead to failed integrations because part of the functional context is discovered during the test or operational phase of the integration ... this is the most expensive mistake that can be made.

Have more questions? - (949) 200-7589