Extending a Digital Ecosystem for
the Internet of Everything – Part 2

Previously I wrote about the process to extend an digital ecosystem to include connected devices; collection, connection, crafting and combination, now I’ll address other areas that are crucial to ensuring that any services that are developed are dependable as well as useful.

What about quality control?

Unfortunately, it’s not only a case of orchestration, analytics and API exposure. To guarantee the quality of service there are a whole host of other related issues that need to be managed, mostly around the task of making sure all the components involved are working as expected, making sure that there is a robustness to them, and that the proper control mechanisms are in place to support the expected volume of calls to use the service. Without these, no one calling upon the exposed services can really depend on it, so they will be less willing to incorporate a call to it as part of their own processes. It’s about building a level of trustworthiness in what you are providing.

Some of this may involve tools, for example, for error handling and recovery or for application monitoring, other may be purely policies such as data management and backup policies. It may well be that your organisation has many of these controls and functional abilities in place already, but I’d suggest that these could be impacted by adding device data, certainly when it comes to having to deal with the new volumes and velocities of data. It could be here that you start to review the chain of the sources of data and discover areas of weakness or gaps in capabilities.

At this point, device management itself must also be considered. You should be able to understand what could be the likelihood and impact of installed devices failing on the quality of the data service that they support, what is the expected reliability of such devices, and what is the process then to replace those devices? We’ll need to have something in place to support swapping faulty devices and to be made aware that a device needs to be swapped. Everything here is to work at making the service as fit for purpose as possible.

And data privacy?

Another important factor to consider is the privacy implications of the data that has been created, trust in the quality of combination and analysis applied to data sets and engagement with both the owners of data and those who may consume it. If data is coming from various sources, how can you be sure that the quality is sufficient to allow you to use it within your own business processes? That may also raise the question of what happens when you create another service based on it and allow others to use it. You need to build a model of trust so that the providers will guarantee a level of quality and you may need to create some incentive to ensure that level is maintained over time. If not, you may need to consider the implications if your service is used by someone else and something goes wrong based on your inputs. This drives the requirement to engage with both providers and users of data - you will need to agree who owns what, how data is secured and how any benefits are shared. Again, it’s making sure that the service created is fit for purpose and ultimately provides value to a customer.

Once you've built a service, how do you make the most of that? One answer would be to provide a marketplace to allow others to know about it, try it out and purchase usage of it. First thing would be to decide what services you would like to share – that could be within an organisation, to a limited set of partners or maybe the wider public. You may also need to decide what to charge for that access, and as part of that you will need to define usage policies or rate limits and bill per those usage models.

Making the most of the service

When you have built up the service into a shareable, or saleable, product, then you need to publish it, which includes providing documentation to allow a developer to understand how to call the service and what responses they can expect. We want to make it easy for someone to start using it and incorporate calls to it within their own business processes.

Finally, as you may need to make sure that the owners of the data know who is using that service, or make sure those using are billed correctly, you will need to authorise only those you allow to use the service. It may be the case that one of you customers can then enhance that data yet again in a way that you cannot, and that could be something that you will want to access and use to improve your own processes and data.

To recap, there is a process to build a useful digital ecosystem that can also include connected devices, something that builds upon the existing capabilities of any organisation and that enables the collection, connection, crafting and combination, needed to make the most of existing investments.

About the Author

Chris Hughes - is the Business Architect at Torry Harris Business Solutions, working with global clients to translate business vision into IT architecture strategies and roadmaps.

Related Posts

GenAI implementation strategies for telcos

GenAI creates new content, including images, and texts, by learning from training datasets. Its ability to simulate complex behaviors, generate novel and personalized content, adapt in real-time, and remain robust even in the face of data scarcity sets it apart from traditional AI and Machine Learning (ML) models.

What it means to drive continuous transformation

Data analytics and customer research, personalization, multichannel presence, and intelligent outsourcing can make a world of a difference in the way you are perceived by your customers. When done well, this results in generating customer loyalty and translates to revenues.

Building resilience: Mitigating risks in transformation

Transformations aren’t easy, they don’t happen overnight and without governance and reporting measures, there is a strong possibility of failure to change and a loss of credibility for the teams involved.