Building out IoT Solutions: Reference Model – Part 4

In Part 1, I discussed the foundational elements of building an Internet of Things (IoT) solution.  In Part 2, I layered in a taxonomy of IoT Solutions. In Part 3, we took a tour of state-of-art in M2M leading to a conceptual similarity between Industrial IoT and IoT. Now, let’s dive a little deeper and see what components we can unearth that can lead us to a reference model.

Based on my experience in the enterprise world, one thing I have repeatedly encountered and so will always prepare solutions for is to expect for extensions or customizations of standard solutions. There are no cookie cutter solutions that will be adopted as is. Each organization, has over the years, stabilized their own unique approach to doing business. While there could be as high as 70% similarity or even more, it is wise to augment every capability space with an appropriate design environment that accommodates changes without violating the architectural principles behind the overall system. Another important requirement from solutions in an enterprise space is to plan for lifecycle management and evolution. There is simply no chance to start with a fresh slate every so often. Systems have to be maintained, patched or migrated with minimal risk and impact to business.

 

My view of the IoT world is as follows:

blog.4.IoT.Ref.Model.v2

 

There is a lot going on in there! Let’s go through it in detail:

  • First, note that this is the same picture with more detail as was discussed in my first blog. There are essentially three dominant or important parts in the solutions
    • Edge: Where the cyber-physical thing resides. Note that this can be generalized to the data from the cyber-physical thing along with relevant meta-data to describe the context.
    • Networks: Where the communication and connectivity details in the physical world (wired and wireless) materialize. Note that I have simplified this to simple lines to indicate different communication options including streaming, replication and synchronization.
    • Core: Where the enterprise magic of working with enchanted objects is realized – as we saw before.
  • Second, note the clear separation between the runtime components and the design time support constructs. Based on my remark above, enterprises need tools to manage their own IoT landscapes to map, extend, modify or customize the solution as their needs and technology landscape evolves.
  • Third, is the set of key capabilities that are needed in the core component. Note that the core capabilities can be deployed in an enterprise data center or also consumed as services from the cloud. The scenario of use, sensitivity of data, maturity of technology landscape management, governance and several other enterprise policies play into this decision. From a solution perspective, this is a simplification to show that the capabilities are not very different even though the deployment choices can be varied.
  • Fourth is the aspect of data related specialization. Given that IoT is a data intensive scenario, it is vital to think about data as a key driver in the final architecture. This is not to say that without big data capabilities the architecture is not ready – instead, the choices that are made should be consistent with expected data loads and the value added operations that are to be performed on it. For example, if operational reporting is important, the focus would be on a shorter time window of data. On the other hand, predictive models benefit with a longer time window of data typically spanning several years and several millions of data points. Immediately it is clear that this is where the M2D from Prakash’s taxonomy maps.
  • Fifth is about compute specialization. This tag tails on the data choices. As more and more data points are gathered, and more and more data sets are to be correlated, the need for efficiency and performance on the compute engine grows. Typically this calls for native operators and capabilities implemented on top of a tiered data model that offers the right mix of compute and data access performance for a given use scenario.
  • Sixth is the unique aspect of IoT which is device management and administration. While we can talk about data and compute requirements in any enterprise class solution, device management is the place where IoT solution architecture differs from other solution architectures. As noted, the dream we are pursuing is when smart things log on to the core systems and autonomously determine how they would like to evolve. This elevates devices to the level of another user of the system and so reminds us of the same set of constraints including provisioning, authentication, access rights, etc. Note that a smart thing is a compute entity on its own right. Thus, we are talking about two computing systems wanting to participate in a mutually consistent way and thereby elevate the overall value in the system.
  • Seventh is where the M2A and/or M2P taxonomy options get realized. This has to be done within the context of an industry or even an enterprise. The variations at this level are hard to predict and so it is often better to offer broad tools, established protocols and best practices to enable timely and useful integration.
  • Eighth is where M2P goes beyond simple integration. Device data offers an enrichment of context apart from operational integration. True value gets unlocked when this enriched context offers insights into optimization and revenue generation. This internal optimization is key to set the stage for networked applications where data derived from internal operational systems are used to drive business transactions.
  • Ninth is when certain reusable constructs within a certain industry can be packaged for accelerated deployment. These could span compute libraries to sophisticated algorithms running on industry specific data models that have been suitably extended to include device data persistence. Mechanisms like data series related compute along with tolerance to data delivery into the persistence layer start to play an important role here.
  • Tenth is a question – what about M2M? We have discussed extensively on the Core capabilities so far. M2M or autonomous interaction in a community of machines or smart devices should also be a managed process. This calls for a higher degree of distributed compute where parts of the enterprise policies are enforced. From an enterprise governance perspective, this could be viewed as an extension of application lifecycle management all the way to the edge in a connected way.

 

I hope this gives you a perspective on how an IoT solution can come together. I have glossed over several topics – particularly in the networking space which is a very fascinating topic in its own right! At the same time, I hope I have given you a flavor on what goes on in this domain, why it is exciting and how to harvest the magic in an economically sustainable way. Good luck in your explorations!

 

VN:F [1.9.22_1171]
Average User Rating
Rating: 4.5/5 (2 votes cast)
Building out IoT Solutions: Reference Model - Part 4, 4.5 out of 5 based on 2 ratings

1656 Views