Customer & Cognite operational responsibilities

If you are curious on how to get the most out of your Cognite Data Fusion subscription, you have come to the right place. This is part of a series of posts where we share some of our experience from working with customers in their journey towards an Industrial DataOps organization. We want to share lessons learned, mistakes made, good practices observed, and observations of pitfalls and risks. This is not the absolute truth, but hopefully a way to spark good discussions around an inherently complex topic!

To quickly introduce ourselves, we are @Arjo Oosten, Digital Transformation Leader, winter sport addict and passionate about driving hands-on digital growth strategies and value based decision making, and @Karolina Luna, Solution Architect, cat lover, and passionate about the lifecycle perspective of everything (like solutions and data products).

To learn more about Cognite Data Fusion, we recommend this post.

Planning your solutions and Industrial DataOps with Cognite Data Fusion

To be able to start planning your organization for running DataOps with Cognite Data Fusion, it is good to start with an overview of what parts should be operated and who is responsible for their governance. This image describes a conceptual overview of Cognite Data Fusion and, more importantly, the activities that are needed by you as the owners of the data and end user solutions to develop, operate, and govern solutions and data products.

Who operates what?

To start with the basics, Cognite Data Fusion is provided and operated by Cognite under a Service Level Agreement that guarantees that the platform and its functionality continues to run smoothly and exceeds your expectations as users. The same goes for Cognite’s official applications.

Without data, the platform does not provide any value. Value is generated when you add, contextualize, and consume the data. The data is a valuable customer asset and needs to be combined with the extensive expertise on the data that only your organization possesses. We suggest planning for the operational responsibilities listed below. Note that one person can cover multiple responsibilities.

• Data sources. In most cases these will be already established systems that have existed for a long time and are already covered by an existing IT organization. As the focus of data grows, additional sources may be added.

• Extractors. Although several standard extractors are developed by Cognite, extractors frequently run on customer governed infrastructure and need to be managed by some form of customer operations. Custom extractors developed by the customer or partners using Cognite’s SDK’s naturally fall within their operational responsibility too.

• Data transformations and contextualization. The business logic for transforming and contextualizing the data to create the data products that meet your expectations and requirements comes from you. These will also need to be updated as the data and organization changes and new solutions are added. Cognite Data Fusion provides a toolset for simplifying these activities, but data handling and governance is still required. Where additional tooling outside of Cognite Data Fusion is also leveraged, such as customized contextualization algorithms, this may need to be operated as well.

• Custom applications. Applications or solutions developed specifically for you by you or your partners. 

• Configurations. Standard applications have a varying degree of configuration to tailor them to your needs.

• Access management. Only you should control who has access to your data.

Looking from another perspective, what does operational responsibility mean in terms of handling support tickets, maintenance, and questions?

Getting the right support

As you know your data products and solutions, you are in the best position to help your end users with questions and issues related to these, even when it comes to Cognite Data Fusion. This can be illustrated by a breakdown of the issues reported to us. These issues typically lands in one of the following categories:

• Access problems. The user has not been provided the access expected by the organization issuing this.

• Data missing or changing. Changes or lack of data is detected somewhere in Cognite Data Fusion and is tracked down to customer operated source system or extractor.

• Other issues that require domain understanding. Something has gone wrong with calculations, transformations, or other operations somewhere in Cognite Data Fusion and domain expertise is required to understand what the issue is and how to address it.

In all of the above cases the customer is needed to resolve the issues.

Issues covered by your SLA are anything related to Cognite Data Fusion or other Cognite products and these should be escalated by your service desk or support organization to the Cognite service desk. 

Cognite Solutions Support

Cognite also offers solutions with Solution Support as an option. This means that Cognite develops and operates a solution on behalf of the customer, including transformations, contextualization, and other operations that can be hosted by Cognite. The downside with this is the lack of flexibility for the data owner to add, update, or change data products and solutions without ordering a new project from Cognite. Cognite strongly believes in empowering you to take control over your data so that you can make the most of it!

For those of you not managing your own data in Cognite Data Fusion today, what is blocking you from doing so? For those of you who do manage your data in Cognite Data Fusion, how did you get started?