By - drmarkhm

Audrine Research Backgrounder: Decreasing “integration tax” has radically changed BSS and OSS architectures and business – and will change them more in the future with microservices [Part 1]

Microservices, part of “cloud native” software architecture, are all the rage today. This Backgrounder post starts a series of short articles on the changes in BSS and OSS architecture arising from the changing underlying data communications, middleware, and data modeling software technology. Here, we look back on the early days of OSS and BSS – in the 1970s and 1980s.
The costs of interfacing software systems and components has radically decreased over the last 40 years. This has had a profound effect on software development methodology and architecture.

During my 40 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 $1M or more! Then, multiply that by the old magic 2.7 to get the cost to the customer, and it meant a staggering price. The adoption of data communications interfaces such as X.25 and the old IBM FCIF (used in TIRKS and other IBM3270-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 and X.25 interface on the system. When quizzed as to why he wanted it, he replied that he wanted to “plug-into” another system and exchange data in real time. He was quite disappointed to learn that implementing a data communications protocol in two different systems did not mean that they could immediately “talk” together – you needed to actually do much 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 are welcomed.)

Dr. Mark H Mortensen