Your first answer to the headline question today will probably relate to Bitcoin transactions. That would indeed be a clever answer but there is more potential in blockchain for OSS / BSS than just crypto-currencies.
I figure that it could be applicable for the following use cases and probably many more:
Thanks to my friend Mike for bouncing ideas around on this one! Interestingly, Mike feels that SSL could be made redundant, especially considering the rumoured security breach of some certifications back in 2011.
What opportunities do you feel blockchain opens up for OSS that I’ve overlooked?
Over the years, I’ve often referred to The Corkscrew Analogy or Momentum Spiral to describe a mindset of incremental improvement that’s needed to keep an
We’ve embarked on a journey of trying to plan for the future of OSS/BSS, not by predicting the future, but by seeking ways to be
As discussed in the previous article, “Future Scenario Planning: Have you given up on doing an OSS transformation? (part 1)” part of the fun of
Earlier in the week, a friend mentioned he was reading “Alchemy” by Rory Sutherland. It’s not an OSS book per se, but does provide some
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
2 Responses
could you give some details on how you imagine the use case for “Data reconciliation across interfaces” to be implemented on a blockchain?
thanks
Great question Franz!
Let me preface this by saying we sometimes get a bit carried away with new tech and claim new ways of using it unnecessarily – which is often the case with blockchain – when plain old databases could easily do the same task.
Where blockchain comes into play is in its characteristics of being distributed / immutable and as a proof-of-work mechanism when tied to smart contracts.
One of the examples I had in mind when writing this post was a complex data handover scenario for a client where there were:
– two carriers involved,
– multiple different business units within those carriers,
– multiple handover / hand-backs as the data transitioned from one state of ownership to another,
– data sets handled singularly (for transfer of single data units) but in aggregate (for payments for a whole service area / boundary),
– third-party involvements (eg field audits, approvals, payments, SLAs) and
– contractual ramifications (eg readiness for service, SLAs, payments, etc).
The whole process was very manual, lengthy, prone to errors and very political. However, it did follow a quite consistent set of steps (ie not many side-loops). The concept I had in mind was to use smart contracts (on a blockchain) to track the various steps in the transition of each data set, demonstrate proof-of-work (in some cases a manual process, in some cases just auto-logging), to help automate the process, to speed it up and de-politicise it.
Point of Interconnect sometimes have elements of these too, but generally don’t have quite the same complexity as the scenario described above.