Decreasing BSS/OSS “integration tax": Part 3 - SOA and data models complete the current picture

This BLOG post is the third, and last, in a series of short articles on the changes in BSS and OSS architectures arising from the changing underlying data communications, middleware, and data modeling software technology. In the last posting, I described how IP and middleware dropped the cost and complexity of integration by an order of magnitude.

About the turn of the century, a new concept (which was really an old concept) appeared on the software scene - what became known as Service Oriented Architecture (SOA). The concept is simple - design software so that the functionality is not only available to a human via its associated user interface, but to another system via a simple, stable interface. In reality, the concept is very similar to the time-honoured remote procedure calls (RPC) of yesteryear (send in some data and define what predefined procedure you want to run, and then get a response). And the interface became to be based on human-readable code - XML (eXtensible Markup Language). But more importantly, the SOA model meant having a design goal of not breaking the interface with later generics (there also are some technical aspects of the interface that makes it easier to add data elements without breaking the interface).

When SOA is combined with the use of a standard meta-model for the data, it becomes even more useful. And when even more specificity is supplied, as in the use of the TMF's Shared Information and Data (SID) model, interfaces become even easier to build and maintain. The SID has been used by many OSS and BSS system vendors and is the preferred data model for nearly all systems integrators and ISVs.

These innovations of the past three decades have brought the cost of interfacing modern software systems from large fractions of a million dollars to a few tens of thousands of dollars and enabled multi-system architectures and automatic flow-through of information, orders, and network control unheard of when I first began my career.

Will this revolution cause the industry to move away from the current "best of suite" architectures, provided bydo-it-all vendors such as Amdocs and Oracle, and towards best-of-breed architectures? Perhaps. It certainly provides some new options and gives the systems integrators, whose influence in BSS/OSS architectures has waned in the last five years, a new set of systems to put into their preferred suites.

Decreasing “integration tax" has radically changed BSS and OSS architectures and business – and will change them more in the future [Part 1]

This BLOG post starts a series of short articles on the changes in BSS and OSS architectures arising from the changing underlying data communications, middleware, and data modeling software technology. Today we look back on the early days of OSS and BSS in the 1970s and early 1980s.

During my 30 years in the telecoms industry, I have seen a radical change in the cost of developing interfaces among BSSs and OSSs. Before the wide adoption of standard data communications protocols such as X.25, the development costs of interfaces between systems was easily $500,000 or more. Then multiply that by the old magic 2.7 to get the cost to the customer, and it meant well over a million dollars. The adoption of data communications interfaces such as X.25 and the old IBM FCIF (used in TIRKS and other IBM 3270-era systems) dropped the costs somewhat. But it only really attacked part of the problem. I recall once in my testing systems days (SARTS, for the old-timers out there) one US RBOC customer who wanted us to implement an X.25 interface on the system. When quizzed as to why they wanted it, they replied that they wanted to ‘plug it into’ another system and exchange data in real time. They were quite disappointed when they were informed that implementing a data communications protocol in two different systems did not mean that they could ‘talk’ together – you needed to actually do some more work. We also had another problem in those days – the X.25 protocol stack implementation was different in every different computer hardware system. So every time you offered the software on a different hardware platform, even from the same manufacturer, you had to re-implement the protocol stack.

The effect on the architecture was that only huge systems, architected by the same group, and implemented and tested by a single vendor, could hope to work together. Interfaces between disparate systems were few – and very expensive to build and maintain.

Next time – IP and middleware make things better.

(As usual, comments welcomed.)

Mark H Mortensen