In this fourth installment in our blog series, we will focus on IoT prototypes. If you've not had the chance yet, you might want to take a look at the previous installments first
Prototyping is a crucial part of every project. It supports the design phase in your project by evaluating the feasibility of your solution design long before the implementation phase. It can also help to understand whether your solution satisfies customer-specific guidelines and specifications, such as the IT strategy or the security strategy.
Lots of facts and statistics back up how valuable it is to invest substantial time and effort in the early phases of this kind of project. If not identified during prototyping, any mistakes made during the design phase can become very costly to fix later on in the development cycle, especially so if they have to be remedied in a productive environment. [1]
What is a prototype and what types exist?
Unlike proofs-of-concept, which have the job of proving that something can be done, prototypes serve to simulate the subsequent implementation of your idea. A proof-of-concept might be used for example to prove that a specific technology is capable of supporting a specific design idea, whereas a prototype would simulate the actual implementation of this design idea.
As mentioned above, there are many good reasons to build prototypes. As well as obviating potential redesign costs later on in the project, risk mitigation and quality improvements are other powerful arguments in favor of prototypes.
There are various types of prototypes available, each for a specific purpose, such as design, development or implementation. Some months back I wrote a blog entitled “How can I identify the right scope for UX improvement prototypes in my project?”. I can still highly recommend this, as it provides valuable information about different types of prototypes, their value, and how to find the right scope for your own prototypes. Although I wrote this blog with UX in mind, 90% of what I wrote can easily be re-used for other areas, like IoT.
What is so special about prototypes in the context of IoT?
As I mentioned above, what I wrote in earlier blogs can often be re-used for IoT. The point in IoT is that there are a lot of other things that need to be considered as well.
In the context of IoT, the two concepts of IT (Information Technology) and OT (Operational Technology) are distinct but connected.
IT is of course, a well-established concept that represents computers, hardware, software, communication technologies and the like.
OT is a concept that some might not be all that familiar with. This represents the technology that is very close to operation fields. What we call “Things” in the Internet of Things belong to OT. Examples here are sensors that are directly connected to machines or other places where data can be collected directly from an operating environment.
The connection of these two distinct concepts in IoT, forces IT people to familiarize themselves with the specifics of the OT world, and means in turn that OT people have to get to grips with IT. The two major topics of interest here are communication back and forth between these two fields and the security aspects that have to be considered.
With our focus on IoT-relevant prototypes, it therefore becomes obvious that, together with security-related activities, communication within and between OT and IT is of key interest.
Communication and security are not the only aspects specific to IoT prototypes however. Other equally important ones are data and device management.
The “walking skeleton”
In IoT, you will usually see two scenarios:
In IoT, you will also see huge amounts of data, especially the data produced by sensors in the field of OT. It is necessary to understand different aspects of the incoming data, like data format, data transfer frequency, and data volumes in the early design phase of your project, as these factors will influence your IoT solution design. By building a prototype first, you will be able to do the following:
It will become increasingly important to create a prototype as a walking skeleton that covers all of these different data movements, the integration between the hardware (machines, devices and business systems), the management of devices and things, and all necessary security scenarios including integration into the business context.
In the near future, we aim to dedicate more blogs and videos to this topic. We also plan to add valuable content to SAP EA Explorer in order to provide more guidance.
Conclusion
Prototyping is one of the most important activities in an IoT project. While a lot of experience gained from earlier prototyping can be reused, IoT places its own special demands, especially in terms of handling the large amounts of data generated by sensors, device management, integration of all components, and in terms of the security aspects that need to be considered. The walking skeleton model enables you to test across complete scenarios.
We plan to produce more blogs dealing with this topic. And of course, this series will continue with part five, where we will discuss how to formulate the IoT strategy and the roadmap.
Thank you for your reading - and please stay tuned for the next installment.
All the best,
JJ (@JJComment)
PS: The next blog of this series is “Characteristics of an Enterprise IoT Strategy – Part 5: Define your IoT Strategy“
Reference
[1] https://www.linkedin.com/pulse/hidden-impact-late-phase-requirements-change-steve-thomson
Prototyping is a crucial part of every project. It supports the design phase in your project by evaluating the feasibility of your solution design long before the implementation phase. It can also help to understand whether your solution satisfies customer-specific guidelines and specifications, such as the IT strategy or the security strategy.
Lots of facts and statistics back up how valuable it is to invest substantial time and effort in the early phases of this kind of project. If not identified during prototyping, any mistakes made during the design phase can become very costly to fix later on in the development cycle, especially so if they have to be remedied in a productive environment. [1]
What is a prototype and what types exist?
Unlike proofs-of-concept, which have the job of proving that something can be done, prototypes serve to simulate the subsequent implementation of your idea. A proof-of-concept might be used for example to prove that a specific technology is capable of supporting a specific design idea, whereas a prototype would simulate the actual implementation of this design idea.
As mentioned above, there are many good reasons to build prototypes. As well as obviating potential redesign costs later on in the project, risk mitigation and quality improvements are other powerful arguments in favor of prototypes.
There are various types of prototypes available, each for a specific purpose, such as design, development or implementation. Some months back I wrote a blog entitled “How can I identify the right scope for UX improvement prototypes in my project?”. I can still highly recommend this, as it provides valuable information about different types of prototypes, their value, and how to find the right scope for your own prototypes. Although I wrote this blog with UX in mind, 90% of what I wrote can easily be re-used for other areas, like IoT.
What is so special about prototypes in the context of IoT?
As I mentioned above, what I wrote in earlier blogs can often be re-used for IoT. The point in IoT is that there are a lot of other things that need to be considered as well.
In the context of IoT, the two concepts of IT (Information Technology) and OT (Operational Technology) are distinct but connected.
IT is of course, a well-established concept that represents computers, hardware, software, communication technologies and the like.
OT is a concept that some might not be all that familiar with. This represents the technology that is very close to operation fields. What we call “Things” in the Internet of Things belong to OT. Examples here are sensors that are directly connected to machines or other places where data can be collected directly from an operating environment.
The connection of these two distinct concepts in IoT, forces IT people to familiarize themselves with the specifics of the OT world, and means in turn that OT people have to get to grips with IT. The two major topics of interest here are communication back and forth between these two fields and the security aspects that have to be considered.
With our focus on IoT-relevant prototypes, it therefore becomes obvious that, together with security-related activities, communication within and between OT and IT is of key interest.
Communication and security are not the only aspects specific to IoT prototypes however. Other equally important ones are data and device management.
The “walking skeleton”
In IoT, you will usually see two scenarios:
- “Device to device”
Data exchange from a device to a business system and back to a device or from a device to a device via an IoT gateway. Just as a side note: Direct communication between devices falls under the concept of Machine to Machine (M2M) communication - “Device to action in business system”
Data exchange between devices and business systems
In IoT, you will also see huge amounts of data, especially the data produced by sensors in the field of OT. It is necessary to understand different aspects of the incoming data, like data format, data transfer frequency, and data volumes in the early design phase of your project, as these factors will influence your IoT solution design. By building a prototype first, you will be able to do the following:
- Data Analysis
Review existing data and think about how to prepare the data at or near to the point of collection. Here you can consider which data is really required, how it could be filtered and where it could be stored. Could it be filtered already in the software of the sensor? Or maybe in the IoT gateway? Could the data be stored in the IoT gateway, or somewhere else in the cloud? What are the sizing measurements of the different components and the communication channels? Of course, one major goal of this analysis is to ensure that the amount of data reaching the business systems in the backend is small but valuable. - Device Management
Understand how the devices can be connected with your business systems in a secure and manageable way. Learn how devices will be authenticated, or test scenarios where devices are temporarily unavailable or are malfunctioning. Figuring out how to operate devices in terms of optimally updating device drivers or changing device configurations is also part of this. - Integration
Evaluate how the integration between OT and IT components can be established in a secure environment at both data and process levels. The integration scenarios might involve both SAP and non-SAP systems. - Security
Perform a security validation of your IoT solution in accordance with the basics of modern information security, including PREVENT, DETECT and REACT. (See related topic in SAP EA Explorer)
It will become increasingly important to create a prototype as a walking skeleton that covers all of these different data movements, the integration between the hardware (machines, devices and business systems), the management of devices and things, and all necessary security scenarios including integration into the business context.
In the near future, we aim to dedicate more blogs and videos to this topic. We also plan to add valuable content to SAP EA Explorer in order to provide more guidance.
Conclusion
Prototyping is one of the most important activities in an IoT project. While a lot of experience gained from earlier prototyping can be reused, IoT places its own special demands, especially in terms of handling the large amounts of data generated by sensors, device management, integration of all components, and in terms of the security aspects that need to be considered. The walking skeleton model enables you to test across complete scenarios.
We plan to produce more blogs dealing with this topic. And of course, this series will continue with part five, where we will discuss how to formulate the IoT strategy and the roadmap.
Thank you for your reading - and please stay tuned for the next installment.
All the best,
JJ (@JJComment)
PS: The next blog of this series is “Characteristics of an Enterprise IoT Strategy – Part 5: Define your IoT Strategy“
Reference
[1] https://www.linkedin.com/pulse/hidden-impact-late-phase-requirements-change-steve-thomson
- SAP Managed Tags:
