> For the complete documentation index, see [llms.txt](https://engineering.umh.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://engineering.umh.app/product/who-we-build-for/it-platform-and-data-teams.md).

# IT: platform and data teams

IT teams that build their own platforms and data stacks and want UMH to fit into them.

**Some IT teams build their own platforms and want UMH's configuration in Git like the rest of their code.** They are often run as innovation centers and do more than manage existing systems. Their platforms are made of self-written applications, Kubernetes and similar tools.

**In UMH, the OT team can work on a platform team's configuration in the UI.** A platform team needs what the [OT team](/product/who-we-build-for/production-ot-team.md) knows about the machines. Platform teams often struggle to get the OT team to use their tools, because the OT team switches off as soon as something looks like code. In UMH, the platform team writes the configuration in YAML. Because of [code and UI](/product/product-standards/code-and-ui.md), someone from the OT team can open the same configuration in the UI and add what they know about the machines.

**A data team wants the** [**modelled data**](https://docs.umh.app/usage/data-modeling) **from UMH in its own data platform.** Some companies have such a team. It wants whatever UMH does on the shop floor to be part of its platform. So UMH only gets the data into that platform. The team then builds its use cases there.

This raises the question of who owns which use case. We do not want to compete with the company's own data team. UMH never wants to be the company's analytics platform. But data platforms such as Snowflake or Databricks are built to analyse large amounts of data. They do not fit use cases that have to react in real time inside the plant.

How we resolve this is still open. One direction is that use cases for [knowledge workers](/product/who-we-build-for/production-the-shop-floor.md) belong on the data platform. We should nudge customers to build them there. Real-time use cases inside the plant, such as alarms or writing produced quantities into SAP, would stay in UMH.

**Time-series data could be a compromise.** Storing all of it in the data platform gets expensive. UMH handles time-series data well and can store it much more cheaply. Once those costs become a real problem for the customer, the historian could offer a standardized API. The data platform then fetches only the data it needs.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://engineering.umh.app/product/who-we-build-for/it-platform-and-data-teams.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.