NPN For Dummies: PART VI
Index of contents:
“You are, and do not know’t: The spring, the head, the fountain of your blood Is stopp’d; the very source of it is stopp’d.”
W. Shakespeare, Macbeth
Here, in but one line of Shakespeare’s Macbeth we see one of its dominant symbols multiply like the heads of the hydra. From familial bonds to feudal villainy to the essence of life itself, blood in its many faces provides a perfect analogy for this, our next chapter on the body electric that is your non-public network. And here, like a pint of the messy stuff, we’ll draw out that metaphor to reflect on the whats and hows of its very beating heart, its Applications & Users.
A mantra for the service-based architecture -, these what/how logical conditions – quickly come into focus as its raison d’etre. That is because, in our NPN, whatever the integrity of its substructure of bones and brawn, brains and veins, is no more functional than a zomby without lots of warm, fresh blood in the form of application data and users to consume it.
Who cares & why bother?
No warehouse, no factory, no office or stadium builds its own mobile network for the simple fun of building it. It is fun, don’t get me wrong, but without a business case to drive it is nothing better than a white elephant. Thus, when we look at the real business case for an NPN – the thing that will get decision makers to stand up and “buy in” – it is not at all a singularity, but a multiplicity of many business cases. In the language of engineers and product designers they are calleds use cases. But that is no way to suggest they are removed from the bottom-line-pointing spreadsheets that move money toward transformative technology projects like these.
And here we find a perfect lens through which to view the economics of the network that will indeed live and die by the sword of its applications. The ROI of your network, which will be essential in selling it, will be built one use case and one application at a time. When you are done building it, the costs of transport, central core processing, cloud and radio capacity, will all seem like table stakes compared to the value of the applications that run atop of them. Did this even bear mentioning?
And now we return to that symbol of blood, the same that split onto the treacherous hands of Macbeth and his lady, and spilt in such quantity in fair verona between the warring houses, Montague, Capulet and, the blood of family. With that in mind we move to another, decidedly more modern and monstrous literary pillar, the story of Frankenstein. There is method to our madness, but to fully understand, dear reader, do read on.
The overriding theme in Mary Shelley’s masterpiece is that of familial responsibility, the bond of blood, or by proxy in Frankenstein, the bond of spawning the monster’s creation. That same familial bond is the one that you and each of your monster network builders must take on. How and why your applications run and serve, rather than undermine your purpose is with all intentional seriousness, your responsibility, just like it was for young Victor Frankenstien. And so we begin…
But not without throwing yet another literary log upon the fire.
Brilliant Deduction?
To understand the non-public network, its DNA and purpose is to understand it in contrast to what it is not, namely a public network. Here is a perfect opportunity to pick up the idea of a network and look deeply through both ends of it, as if it were a telescope. In logical inquest we see pursuits divided along binary lines, between the oft confused “deductive”, and “inductive” modes of reasoning.
To help light the gas lamp on these, we can position ourselves in an old London attic office between the two sparring minds of Sherlock Holmes and Dr. Watson…”brilliant deduction my dear Watson!”, exclaimed Sherlock. But was it really that? A deduction? Not so much. In fact, the art of Holmes and his erstwhile sidekick is rather correctly that of induction – the science of building a general system (hypothesis) from a large number of specific observations or requirements. This is, in essence,the job of the non-public network architect. To add clarity, it is quite exactly the opposite of the public network barker, who from the outset announces himself like a sweeping social program designed to serve the many, at the expense of the few. The logical end product of the “deductive design” is best effort – or the lowest common denominator of a service framework.
The logical end product of the “deductive design” is best effort – or the lowest common denominator of a service framework. The value of the Non-Public network is … rather, (sic) the smiles on the faces of its users.
… Continue reading: