I hate gardening. It’s hard physical work, I’m not very good at it, and I don’t really care about plants or flowers – so there’s not really much reward for all the labor.
However, when we lived in Cleveland, my wife allocated part of the front yard for tomato plants – and I was amazed how quickly they grew, and how many tomatoes they produced. I really enjoyed eating fresh tomatoes from the garden as part of my lunch every day – and I was pleasantly surprised that it hadn’t been particularly hard to grow them. (Certainly not for me, since my wife did most of the work…)
Of course, we later moved to California, and with real-estate prices being what they are, we no longer have a yard (no gardening, hooray!). Instead we have a small patio with a few potted plants, and our food production consists of one strawberry plant (see photo below). It produces about one strawberry per week during the summer – but on the plus side it requires very limited care. (Although it could perhaps use a little water right now.)
As the world potentially falls apart it’s encouraging to know that it’s not actually that hard to grow your own food. It may not be possible at our current house, but with a bit more land, we could probably grow enough tomatoes and strawberries for the whole family.
Easy or Scalable?
And I think the same is true for many things. If you’re doing something at a small scale, it’s not that complicated.
- I could probably knit a scarf, but it would take many hours of my time.
- I can make myself a cup of coffee, but couldn’t be a barista at a fancy coffee shop.
- I can make lunch for my family, but couldn’t be a chef at a restaurant.
- I might be able to grow a few tomatoes, but operating a farm is vastly more complex and requires a whole lot more skill.
Translations History
If you’ve been around the Metaswitch ecosystem as long as I have, you’ll have seen three different generations of translations logic. (You can skip these bullets if you don’t know/care about translations on the Metaswitch.)
- Pre-2007ish: The original “old scheme” translations logic assigned each subscriber to a subscriber group, which was based on their rate center, then Number Validation (NV) inspected the dialed number – first in the local calling area table, to see if the dialed number was local, and if not, in the LATA table to see if it was intra-LATA. This was very easy to understand, and worked well if you served a handful of rate centers.
- New-scheme: Most service providers today have a more complicated logic. Each subscriber is assigned (at least) three line class codes to identify the rate center, NPA and LATA. NV then looks at the dialed number and assigns UDAs to identify the rate center and LATA of the dialed number (plus LERG-assigned tandems). And then finally the subscriber’s LCC and the dialed number’s UDAs are compared to see whether the call is local, intra or inter-LATA, and where it should be routed. This is much more complex, but scales well, and you can walk through all the logic in MetaView Explorer.
- File-based NV: The final approach uses the same logic, but removes all the lists of DN prefixes out of regular tables (where you can view and edit them), and instead puts the lists into files. This allows much more scale, and also makes it much easier to perform bulk updates. The downside is that you can no longer really see what’s going on.
Over time, you can see how the approach has moved from being simple and easy to understand, to a much more powerful (but also more complex) methodology.
I’m not saying this is wrong – there will always be a tension between simple and powerful.
How do we approach switch translations?
When we are working on switch translations, we always use the new-scheme or file-based NV. Even if your deployment is currently small, you may one day want to offer service to a broader geographic area – so it’s still good to plan for scale.
More importantly, both the new scheme and file-based NV options allow for easy database updates when the LERG is refreshed. In fact, when we are performing LERG updates for our clients, we usually switch them over to file-based NV for the relevant tables – because the efficiency benefits outweigh the slight reduction in usability.
Transitioning from Simple to Powerful
As I said earlier, the general principle applies much more broadly than just switch translations: there’s always a tension between simplicity and power. But I also see them as a progression – you start with simple, then you move towards powerful.
When you first start doing something (e.g. starting a business, offering a new service, building a business group) it is entirely correct to focus on doing things the simple way. This allows you to get results quickly, and makes it easier for everyone to understand what’s happening and why.
But over time, as you grow, you need to change your approach:
- a business will need more processes and tools
- hosted PBX provisioners will start using templates and import spreadsheets, and
- translations updates can be done using files.
This transition can be hard – especially so if you don’t notice you’re in the middle of it. So today, take a look at how you do things. Are there tasks where you’re taking a simple approach, but you need to invest in a more robust, scalable methodology? Or maybe it’s the opposite – is there a task where you’ve created a powerful system to allow for vast scale, but actually it would be better to just take care of it manually?
Take some time to notice what you’re doing, and whether it’s appropriate. And if you need some help with your translations, or with scaling up some other process in your voice network, don’t hesitate to reach out.
