Decreasing BSS/OSS “integration tax”: Part 3 – Client/Server and SOA start bringing more “do it yourself”
This BLOG post is the third 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, we looked back at the effect of the introduction of Internet Protocol (or, more properly, TCP/IP) that allowed ‘islands’ of systems to start to be hooked together.
As the century wound down, TCP/IP was well-established, developers were increasingly upset that all of the wonderful ‘busses’ did not work together (the ill-named “Common Object Request Broker Architecture, or CORBA’ in particular infuriated me, as few of the busses could effectively interface).
But new software technology like Java was finding its way into common use and the cost of desktop processing had fallen dramatically. Client/server architectures, which had been around for several years, started making inroads into OSSs. The C/S architecture made use of the processing power of the device on the users’ desktop, dividing the job (roughly) into a database back end, a middle tier where much of the processing happened, and a user device which provided the user interface. (More properly, these were ‘three-tiered client/server architectures’).
Along with the technology changes came a changing design paradigm – software systems designed with integration in mind. This new concept (which was really an old concept) 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-honored 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 TM Forum’s (www.tmforum.org ) 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 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.
Next time: SOA concept is extended to internal “Cloud Native” software architecture.