The Cognite Solution Support organization

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.

Cognite’s Solution Support

We have presented some models for organization we have seen with our customers. For transparency and inspiration, below is an overview of how we at Cognite have roughly organized our development and support activities for our Solution as a Service offering. Since the difference between Cognite and our customers are many, the comparison is not obvious and should not be taken as a recommendation.

One key difference between us and our customer organizations is that we do not have the data product owners or subject matter experts on your data or business. We have experts in the domains themselves, for example power and utilities, but they will never know enough about your specific organization or data. Another difference is that we don’t have the option of keeping full DevOps teams as our delivery teams are expected to move on to working with new solutions and clients.

Our business units equivalents are organized around the applications or the domains we focus on. We have “profession teams” acting as advisors and providing good practices towards the delivery teams. This is a very thin function in the sense that the full delivery responsibility lies with the business units. All solutions that are to be supported by us under a support agreement are built on our internal infrastructure that enforces some standards in terms of delivery. At the end of a project, the solutions that will be supported are handed over to our solution support team through handover sessions and written documentation following our internal templates. 

During the operations phase, the responsibilities are split across several teams. A service desk handles incoming issues and escalates these to the solution support team as needed. The solution support team works closely with the solution infrastructure team to operate and maintain the solutions and infrastructure. Between them, they handle bug fixes, change requests and upgrades. For issues that require domain competency or deep insight to the solution there is an option of escalating these issues to the delivery team responsible for that domain.

When a customer wants to do any modification to the solution or data product this is handled through a change request where we get back to the customer with a cost estimate and a time plan for the customer to accept or reject.

Overall, Cognite manages with a relatively small support and maintenance team, largely thanks to a good process and by limiting the variability in terms of technology and infrastructure for our deliveries. All teams still need to be sufficiently staffed to allow for on-call support of critical issues. The service desk team is larger, but this team also handles questions and issues related to the product.

A final note on documentation and standardization. A challenge in the current environment is that highly competent and technically skilled domain experts are high in demand. This means that escalating issues to the original team can be easier said than done as they are often attached to new projects and have their hands full. The number of solutions to support also means that it can be hard for the maintenance team to maintain detailed knowledge of each solution. To mitigate these problems, we believe it is important to identify and ensure completion of the most relevant documentation and to enforce standardization where it is possible to reduce the cognitive load for understanding each solution. Not doing so may appear to speed up the initial development, but may slow you down quicker than you think.

Is this type of internal example something you would like us to share more of?