Operations as part of the data platform
Data platforms are usually discussed in terms of how they are built: which source systems get connected, which metrics come out of it, how long the rollout takes. Building is the visible part of the project, and the part that gets planned and budgeted.
What happens afterwards is discussed far less often, even though it largely determines the benefit. A data platform does not create its value on completion, but over time: by keeping the numbers it delivers complete, current, and traceable over months and years. That is exactly what operations are for.
Why a data platform keeps moving
A data platform processes data from operational systems, so it reflects processes that change all the time. It therefore never reaches a final state. It follows the changes in the company and in its system landscape.
Three kinds of change come up regularly:
Changes in the source systems. Software updates change field names or data formats, interfaces are switched over, and business teams create new categories and master data keys. Such adjustments are part of normal operation for the operational systems, and as a rule nobody announces them to the data platform.
Changes in the business. Sites, legal entities, and product areas are added or redrawn. Metric definitions are adjusted, for instance at the start of a financial year. If the platform does not follow such an adjustment, the analyses stay technically available but no longer represent the facts correctly.
Changes in the organization. Joiners and leavers, moves between departments, and stand-in arrangements have a direct effect on who is allowed to see which data. Permissions have to follow these movements so that the access rules always match the actual situation.
Without ongoing care a platform stays available, but loses accuracy step by step. Because the process is gradual, it usually goes unnoticed for a long time unless it is checked systematically.
The four tasks of operations
Ongoing operations break down into four areas of work.
First: monitoring data delivery. The platform loads data from the source systems on fixed cycles. What gets monitored is not only whether that process completed, but also whether the volume delivered was complete and the data recent enough. A source system that delivers the same state for several days in a row produces no error message and shows up only if someone checks for it.
Second: checking data quality. Loaded records are checked against defined rules: mandatory fields filled in, amounts and dates plausible, record counts compared with earlier periods. Records that fail these checks are set aside and documented instead of flowing into the analyses unnoticed. That keeps it visible what data quality each source system actually delivers.
Third: tracking changes. New fields, revised calculation logic, additional reporting requirements from the business teams, and connecting further source systems. This area takes the most effort, and it is also the one through which the platform keeps pace with what the company needs.
Fourth: maintaining access rights. Roles, department assignments, and joiners and leavers are reflected in the permission model. If this information is taken from the existing user directory, the effort is small and the result consistent. If it is maintained separately per system, the effort grows and so does the risk of mistakes.
Available is not the same as correct
A pipeline run that fails is the harmless case. It raises an alert, someone works on it, and that is the end of it.
Harder are the cases where processing runs without technical errors but the business result is wrong. After a changeover, a source system delivers only part of its records. A renamed category causes a share of revenue to land in a catch-all line. A field that used to be filled arrives empty after an update, so a metric is systematically understated.
Technically, nothing is broken in these cases. In business terms, the analysis is wrong.
Deviations like these cannot be spotted by watching the state of the system. They only show up in comparisons: record counts against earlier periods, distributions across categories, anomalies that the development of the business does not explain. If these checks run automatically alongside, they raise an alert before an analysis is used by the business teams.
That gives a simple yardstick for the quality of operations: whoever runs the platform should know about anomalies before the business teams do.
What this asks of the organization
Ongoing operations do not rest on daily manual checks. Monitoring and testing largely run automatically in the background and speak up only when something deviates. The effort therefore does not come from the normal case, but from the exceptions and from further development.
Those exceptions are rarely alike. A changed interface, a revised metric definition, an unexplained deviation in the numbers, and an adjustment to the permission model each call for different knowledge: the platform and the cloud environment, data modeling, a working understanding of the business processes, and familiarity with the source systems. In practice a team covers that, not a single role. On top of it comes continuity, because the work arises regardless of vacation periods and closing phases and needs proper cover.
For mid-sized companies this creates a trade-off. An in-house team with that breadth of skills ties up specialists who are scarce on the market, and in normal operation it is rarely fully occupied. The common alternative is a service provider who takes on automation, alert handling, and further development, while ownership of definitions and requirements stays with the company. In either case it should be settled who is accountable for the reliability of the numbers and within what time frame deviations get dealt with.
Conclusion
Building a data platform creates the basis; operating it preserves the benefit. Only when analyses stay reliable over a longer period does the habit of double-checking numbers just in case disappear, and the platform becomes a routine basis for decisions.
For planning, this means not treating operations as a follow-up question but settling them together with the build: which checks run, how deviations are reported, who works on them, and within what time frame changes are tracked. Those decisions determine how dependable a company’s numbers really are in day-to-day operation.