By: Jesse Cryderman
Philosopher Karl Popper defined the difference between open and closed societies in terms of how much or how little bloodshed is required to overthrow their leaders. From an OSS/BSS perspective, we can’t examine how open standards enable interoperability without first looking at the past.
Rewind to the early ‘90s and you’ll remember it was a dark time, where connectivity meant getting your word processing program to recognize your printer. Back then, developers of such applications needed to write separate device drivers for a plethora of different printers. Worse, for consumers, the availability of drivers dictated what products they could use with which printers. In time, Microsoft incorporated printer support into Windows so that only one driver was needed to handle all the different applications associated with the printer. That driver was written by the manufacturer, not the software developer.
Vendors of industrial automation products faced similar problems; developers of Human Machine Interface (HMI) applications had to write drivers for an array of programmable logic controllers (PLCs). A handful of these vendors formed the OLE for Process Control (OPC) Foundation to define the open standard for which it was named. With its OLE protocol, Microsoft laid a groundwork upon which OPC could build. Just like printer manufacturers, automation product vendors began writing their own drivers. The result: application developers freed up time and resources previously devoted to writing drivers and allocated more of both into the product; and users were afforded the flexibility of being able to choose applications based on features instead of driver availability.
Open standards, as an enabler of automation and self-discovery, have evolved considerably since then; Universal Plug and Play (UPnP) standards have simplified device installation and operation by minimizing the need to search, install and configure drivers. So now, I can plug in a real mouse to bypass the touchpad on my laptop and hook up a full-sized keyboard so I can more accurately, and blissfully, mash buttons. I can even copy image files of my very cute cat to a flash drive and plug that into my television to revel in her cuteness in HD. Important stuff.
Indeed, we’ve come a long way from the tedium of having to manually manage multiple drivers in our PCs at home, so it would stand to reason that, out of the aggregate billions that CSPs spend on OSS/BSS solutions, said solutions should come with that same plug-and-play functionality. Certainly, the multitude of telecom standards should have the potential to drive change in the OSS/BSS space in terms of application integration, right?
For example, a number of developers program CRM solutions using SQL, a language designed for relational database management systems (RDBMS). SQL, however, also serves as a prime example of how an attempt at open standards failed due to self-interest.
What is more compelling is the notion of an overarching Communications Operating System (ComOS)upon which we could bundle a network solution with billing and CRM products into one integrated package, much like a Microsoft Office Suite for telecom. To take this concept a step further, the implication that the purchaser of MS Office at any CSP can also purchase an integrated ComOS suite portends a shift in traditional engineering software from the back office to the IT department.
