| « Reusable Code | 19th Century MSDN Subscription » |
Telecommunications manufacturing is a cut-throat business. Features, functionality and hardware need to be added and continuously improved at a frenetic pace in order to stay one step ahead of the competition. Engineers must constantly increase their skills to leverage the latest advances in technology to design and build the best product possible at the lowest cost. Slip up just a little, and it can be a death knell for your company.
To save costs, Dog and Bone Corporation (DNB) had eased up on their latest-and-greatest push. Budgets shrank. Progress on adding new features slowed. Hardware upgrades failed to happen. Meetings to justify every little thing began to become the main task in everyone's day. Competitors leapfrogged. Interest waned. Unfortunately, this caused their flagship private telephone exchange (DBX) product to start to stagnate and made some of the engineers begin to feel that their skills were getting to be a little out of date. Engineering-eyes began to wander.
In the white hot heat of competition, DNB needed something to revive sales of their flagship DBX. If it happened to persuade some engineers to stay because there was actually something interesting to work on, then so much the better.
Duncan E. was on the team that helped develop one of the new features: an interface to permit an external computer to not only receive notification of telephone activity within the DNB exchange but to control features and behaviour of the exchange itself! Perhaps not particularly astonishing by standards of today, but in 1990 this was cutting-edge stuff. The latest tools were brought in and the team was trained in a suitably advanced formal methodology, so as to be best equipped to produce an excellent product.
Lo and behold, over many long months the team laboured: analysing the requirements, capturing state transition behaviour, and designing the gateway that would provide the magic window into the telephone exchange. When the magic window was switched on, it worked remarkably well - a strong indicator that formal methods were a valuable tool for DNB's future. For once, management had done it correctly; they gave the engineers the tools, training and blessing to do it right, and it worked. The engineers were also quite pleased with their accomplishments.
Then management reverted to their usual meddling and it began. Delete this. Add that. Change this. Then one of them mentioned that they had read an article about hackers and software piracy.
The DNB management team was worried that nasty software copying thieves would come and take the program from them, stealing all the hard work and effort that the development team had poured into this paragon of software. They wanted their investment in the program to be protected. Period.
And so it was decreed that a dongle would be added. Without this dongle the software would not run. Without this dongle the software would be without worth. Without this dongle, there would be no way to control the DBX. Software would run amok. Skynet would arise. Empires would crumble. And horror of horrors, phone calls might even be rerouted so that only robo-telemarketing calls could be received.
It was Duncan who implemented the dongle code. He took great pains to insert a macro to do the dongle checking rather than using a function call (so as to make it harder for software pirates to hack the dongle-present check).
It was also Duncan who realized that the dongle was an effort in futility, although he left before he told anyone. After all, the software wouldn't run without a DBX to talk to, making the telephone exchange itself the biggest dongle in the world.
Re: The Biggest Boon-Dongle in the World
2013-01-31 08:28
•
by
Former Avaya User
(unregistered)
|
|
This is a easy one... Avaya IPOffice,
I inherited one of these, and I was shocked by the dongle to unlock features... like $1500 for a extra voicemail channel license running on an XP box for Voicemail Pro. (Too many callers at once and they couldn't get IVR, and people would get fast busy at VM boxes. Despite the "IP" in the name, the phones were digital, so $1000s of worthless cat3 wiring. As I understood it, Avaya got the technology from eastern Europe. My favorite was Compact Call Center (CCC), the call reporting software that required a mixture of IIS, prayer, and an unpatched Win 2000. They were trying to compete with Asterisk, which could run circles around them. (Avaya quoted $15,000 for confirmation calls, something done for free with a PHP script querying SQL and Cepstral Text to Speech for $500.) My condolences to anyone who worked on that POS. |
|
Dongles. Bah.
There are two principal problems with dongles. First, they, like all solid-state digital electronics, are prone to assorted warning-free failure modes. When the dongle dies, you lose access to the software. Second, they are prone to accidental (or deliberate) disconnection, at which point you are stuffed, especially if it gets accidentally knocked into a bin and taken away by the cleaners. Dead dongles can usually be exchanged (leaving you without service for a period) without having to buy a new license. Stolen / accidentally thrown away dongles do not offer this flexibility. As Duncan says, from a simple "can we run it" point of view, the PBX ("Private Branch Exchange") could act as a dongle, but only if the PBX cannot be used at all without the software. If the PBX is capable of completely autonomous normal operation, then the (optional) software, if it is to be a chargeable option, cannot use the "PBX-as-dongle" option.[1] "Former Avaya User" correctly points out the other flaw in the PBX-as-dongle plan: optional software modules. If the software is license-controlled by the dongle, then you can switch modules on or off by manipulation of the dongle. You either swap out the dongle for a more permissive one or you use the method used at the end of the 1980s by USData's FactoryLink SCADA package (well, it belonged to USData at that time). Their dongle had sockets in the side where you could connect sub-dongles containing additional permissions. [1] Of course it can use the PBX as a dongle. The permissions to use the software (and which modules to enable if they are separately chargeable) can be stored in the PBX somewhere. Modifying the permissions can be done in various ways with various resistance to hacking. A PBX with access to the Internet can even phone home to verify its permissions. (Access *from* the Internet is not a good idea, unless the PBX also handles incoming VoIP calls.) |
| « Reusable Code | 19th Century MSDN Subscription » |