Imagine for a moment that you’re sitting in front of a pristine chess board, awaiting the opportunity to make your first move. All of the pieces have been exquisitely carved from stone, polished to a sheen. The rules of the game have been established for centuries, so you know exactly which piece is able to move in which sequences. Time to make the opening move.
You’ve studied the games of the chess masters before you and have planned your opening gambit, the sequence of moves that you hope will launch you into a match-winning position. You’ve even gone one step further. Due to your skills with modern automations, you’ve connected some of your chess pieces with delicate strings, pulleys and weights to implement your opening gambit with precision.
Unfortunately, after the first few moves, your strings are starting to pull the pieces out of position. Your opponent has countered well and you’re having to modify your initial plans. You introduce some additional pulleys and springs to help retain the rightful position of your pieces on the board and cope with in-flight changes in strategy. The automations are becoming ever more complex. They’re taking more time to plan and implement than the actual next move.
The board is starting to devolve into unmanageable chaos.
Are you starting to wonder how you can un-tether the pieces and return to simpler game-play?
Does this story sound like the analogy of a modern OSS? It’s what I refer to as The Chessboard Analogy.
We’ve been at this OSS game for long enough to already have an understanding of all of the main pieces. TM Forum’s Frameworx (TAM, eTOM, SID, OpenAPI, etc) provides as a useful guide. The pieces are modular, elegant and quite well understood by many players. The rules of the game haven’t really changed much. The main use cases of an OSS from decades ago (ie assure, fulfil, plan, build, etc) probably don’t differ significantly from those of today. This “should” set the foundations for interchangeability of applications.
Yet our choice of complex integrations, processes, etc act like the strings, binding pieces together.
Now let’s change tack slightly and look at a modern example of size and sophistication. We see programs of work like ONAP, where millions of lines of code are being developed to standardise (perhaps re-write??) the rules of the game. I’m a big advocate of many of the principles of ONAP and hope it’s a roaring success. I’m just not sure that such a mammoth platform is what’s needed.
It’s not so much in the components of our OSS, but in the connections between them where things tend to go awry.
“The foundation of all brilliance is seeing connections when no one else does.”
This earlier post distills ONAP from its answers back to the core questions. What if instead of building a massive architectural stack, we focus on solving the core questions and the chessboard problem – the problem of minimising connections?
But light-weight integration probably also incorporates what ONAP calls, “real-time, policy-driven orchestration and automation,” to replace pre-defined processes and rules. I wonder instead whether state-based transitions, being guided by intent/policy rules and feedback loops (ie learning systems) might hold the key? That requires an evolving / learning solution that shares similarities with the electrical pathways in our brain, which strengthen the more they’re used and diminish if no longer used.Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email