OSS swivel-chairing

Many OSS systems were initially not linked to each other and often required manual intervention. For example, consider the case where a customer wants to order a new telephone service. The ordering system would take the customer’s details and details of their order, but would not be able to configure the telephone exchange directly — this would be done by a switch management system. Details of the new service would need to be transferred from the order handling system to the switch management system — and this would normally be done by a technician re-keying the details from one screen into another — a process often referred to as “swivel chair integration”. This was clearly another source of inefficiency, so the focus for the next few years was on creating automated interfaces between the OSS applications — OSS integration. Cheap and simple OSS integration remains a major goal of most telecom companies.”

In the ideal world (ie a world where “cheap and simple OSS integration” exists), you’d want an OSS with no swivel-chairing at all… ever. You’d have a best-of-breed OSS where everything is perfectly integrated with everything else, it was all automated and any faults were self-healing / self-optimising.

A no-swivel-chairing policy makes perfect sense for many reasons – no double handling of data (ie reduction in typing errors and ideally no primary data entry at all), no copy and paste between applications, consistent formatting of data, infinite possible queries because data sets are already perfectly linked, etc.

However, in the current world of OSS, we have a thing that’s colloquially termed an “integration tax,” whereby integration tends to be neither cheap or simple. There are times where you need to perform a quick benefit analysis to determine whether swivel-chairing, for all it’s inefficiencies, is actually the better option.

Examples may include:

  •  Where disparate systems are quite incompatible (eg available data interfaces don’t integrate well, available user interfaces don’t gel well for the given workflows, data sets aren’t easily relatable, etc),
  • Where workflows rarely require information cross-over between applications
  •  Where tightly-coupled integration creates data migration and ongoing reconciliation/maintenance nightmares (eg when having to ensure data relationships / hierarchies),
  • Where delivery deadlines are so tight that machine-to-machine integration isn’t viable,
  • etc.

Sometimes the quick and dirty swivel-chair approach just makes more sense… not that us OSS architects/engineers are willing to admit it oftentimes. Integration is often like a moth to a flame… for us to prove how brilliant we are unfortunately….

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

2 Responses

  1. I also experienced one of the main reason to leave the swivel chairing was project deadlines. Also there are cases the integration is considered “not worth it” as the southbound systems may be considered obsolete.

    But based on the years I worked with Telcos, the obsolete systems seems to be still running in production 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.