In the 1st blog in the series, an overview was shared of the journey to managed enterprise IoT, which we divide into three levels of maturity. In my second post you will learn more about the first level: Enabling the use case.
Once you have determined the IoT use case you need to ensure that the solution is secure, accurate and predictable – i.e. it delivers sustainable value – in the face of increasing quality of devices, edges, continuous data flows, and technologies. This is enabled through ‘non-functional requirements’ (NFRs) and spans both execution qualities and evolution qualities. This is going ‘beyond the use case’.
By focusing on ‘how’ the use case is delivered, instead of ‘what’, you can realize the following benefits:
- Quality: If your products and services cannot extract value, the data, and opportunities, it is lost.
- Risk: Complex IoT use cases can put business continuity at risk; reduce it through strong NFRs.
- Productivity: A use case has little value if it stops working after 6 months or in peak load periods.
- Future-proofing: Your system should be built for low cost and simple improvements / evolution.
Realizing this require you to define, discuss, document, and design your NFRs as you enable the use case and beyond it. Extending the timeline from the previous post, the following activities take around 12-24 months:
- Project: Design solution, install and implement IoT solution from core to edge, integrate into your existing business systems as well as ensure system security – including building ecosystem of partners.
- Business Platform: Scale-up and industrialize the use case to a full platform, do further roll-outs, integrate into your existing business and enhance parts of the system to delivery sustainable value.
Below is a non-exhaustive list of topics and example questions to be considered for NFRs:
|Execution||Availability||Does your E2E use case need an operational uptime of 99.99% or 95%?|
|Continuity||What are you E2E RTO/RPO? What are the business impact / cost of your use cases being down for 1 or 60 minutes? How does this impact backup or disaster recovery? How do you enable HA, backup or disaster recovery in a distributed architecture?|
|Manageability||How will you update millions of devices? When and how to push new functionality? How to handle a million+ devices all calling home sick? Will you have 24×7 operations?|
|Interoperability||How will data be handled across different silos? Do your platforms work together?|
|Performance||How quickly do you need to access the data? Does it need to be processed at edge?|
|Resilience||How will the system do backups and ensure service continuity? How will you ensure high uptime of distributed architecture? How will errors be handled ‘gracefully’?|
|Security||How will data from connected objects be trusted? How will you ensure security in new and high risk environments? How will you reduce attack surface? How will you ensure internal and external compliance, auditability as well as alignment to standards?|
|Usability||How will you reduce the head count of managing such E2E complexity? How will you optimize latency issues to improve real-time outcomes and / or use experience?|
|Evolution||Maintainability||How will defects be corrected? Will the system and components have self-healing? How will uptime be ensured without sending people / parts onsite?|
|Modularity||Will your system be built on principles of separate independent functionality?|
|Scalability||Will it scale up/down to meet peak demands?|
By focusing on ‘how’ you enable value from and not just ‘what’ the use case is you will derive much greater long term value for your business. To do this, you need to define, discuss, document and design them into the use case from the start. If you are not already doing this I suggest you look at facilitating it as soon as possible.
I have spoken to many clients who have rolled out IoT solutions which are ‘the future of the businesses’. It is therefore unfortunate when they stop working effectively or if the operations team only know of problems when they are informed by the customer. It is normally at this point that they ask for expertise on going ‘beyond the use case’. A few common outcomes are re-building the app, creating a new platform, facilitating rapid scalability or enabling an operations team with E2E monitoring; either way, it costs time and money that were not predicted in the business case.