Productising your interfaces

In the struggle between capital and labor, more often than not capital has won, because the real source of value for most companies has historically been the hard assets that they owned and controlled.”
James Surowiecki
.

Yesterday we spoke of the different types of interface “objects” such as probes, robots, MDDs (Mediation Device Drivers), etc and how they are developed to interface with data sources such as the different network device types, etc.

If you’re a vendor, the great thing about developing these objects is that you can then slot them into your product catalogue, allowing you to sell them to additional customers with the same device types. In fact, if you know in advance that you have multiple customers with the same device types, you could potentially amortise your development costs across multiple customer accounts.

From an accountant’s perspective, each of these becomes an asset that has the potential to derive a passive income…. or does it?

Well… yes and no. An MDD will require upkeep.

When first developing an mediation device (let’s say it’s a provisioning MDD for equipment type A), you establish all the set-up stuff (ie establishing a session, security, etc) and then you develop all the message mappings for provisioning commands A, B, D and X because they’re the ones that your first customer makes use of. Great! Now you box that up and put it in your asset list.

But then Customer 2 signs up and they also have equipment type A. The only problem is that their network and service topology is slightly different. They still re-use the connection set-up code, but they use provisioning commands A, E, F and Y. So this means you need to develop some extra mappings.*

Then over time there are upgrades to interface versions, messaging formats may change, etc, etc.

So, the moral of the story is that it’s great to productise your MDDs and look to re-use them wherever possible, but remember that they might need some tweaking before being ready for use by subsequent customers.

* You may ask why don’t vendors just build out every single message mapping all at once? Sometimes they do, especially for really common device types. But others are just not feasible. For example, some of the old PSTN voice switches that I worked on had thousands of different commands, whereas we may’ve only needed 20-30 perhaps for any given customer.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.