A change with two parties
Most of what you change in a system, you change alone. You roll out, you see that it works, and if it goes wrong you roll back.
A format change is not like that. It has two parties, and one of them is not yours. The sender decides when a field gets a new name, a new structure or a new resolution. The recipient has to understand it from the same moment. There is no gap in which both are true, and there is no rollback that works on both sides at once.
In a chain with a deadline this is worse than it sounds. The fault is not discovered when the change happens, but the next morning, when something should have been delivered.
Why "everyone switches at once" is an expensive plan
The usual way to do it is a date. Everyone switches on Sunday night, and everyone hopes.
The problem is not the ambition, it is what has to hold for the plan to work. The receiving system has to be fully tested against a format that has not yet delivered real data. Test data rarely resembles it closely enough: it is the rare values that fail, not the common ones. The zeros, the negatives, the missing ones, the ones that arrive out of order.
And what determines whether it went well only shows up in a window where nobody has time to investigate anything.
Two streams, same data, two versions
The alternative is to stop treating a format change as an event and start treating it as an overlap.
The same data can be delivered in two versions at once, on separate streams:
stream A old format → the production system, untouched
stream B new format → the test system, finished in the meantime
Production keeps running on what it has always read. The test environment gets the new data, real and fresh, not constructed. Once the new system has read a week of reality without failing, the cutover is a change of which stream production subscribes to, and nothing else.
The difference is what has to be true in advance. In a date-based cutover you have to believe it works. In an overlapping one you only have to look.
The same mechanism covers the opposite case: the sender changing something before you are ready. The old format is then delivered onwards to you while you catch up, instead of the change forcing emergency work on you because it happened somewhere else.
The keys belong in the message
The other half of the same problem is not about format, but about what meets you afterwards.
A metering pointThe fundamental unit in Elhub - the unique point in the electricity network where energy is measured and settled, identified by an 18-digit GSRN number. has an identifier in the hub. Your system usually has a different one, an internal key that means something to you. When data arrives, the two have to be connected, and that connection is traditionally made in two places: parsing what arrived, and a lookup to work out who it belongs to.
Both can be moved. If the customer's own keys are placed at metering-point level with the sender, they travel with the message, and the receiving system can import directly. No parsing, no lookup table to keep in sync, and no job that fails silently the day a metering pointThe fundamental unit in Elhub - the unique point in the electricity network where energy is measured and settled, identified by an 18-digit GSRN number. is missing from the table.
It is worth noting what this actually removes: not working hours, but an entire layer where errors can arise.
What you lose, and what has to replace it
An older messaging platform gave something real beyond transport itself. One place to look when a message disappeared, a log that was easy to read, and an interface a power user could navigate without help.
That is not an argument against switching. It is a requirement specification for whatever comes next.
A modern alternative should answer the same questions, and preferably more: how many messages got through yesterday, which ones stopped, how long they took, and how the flow looked last week compared to this one. If an operations lead can answer that alone, without asking anyone for a report, the loss is covered. If they cannot, the switch is a step backwards however modern the rest of it is.
Three questions to ask before the next format change
Can I get the same data in two versions at once? If not, every cutover is a date-based cutover, whatever it is called.
How long can the two live side by side? An overlap that lasts a day is a test. An overlap that can last until you are finished is a plan.
Who owns the mapping between their identifier and mine? In the message, it travels along. In a table at my end, it is mine to maintain, and mine to forget.
New functionality in SAMTYGD
The reason this article comes now is that the last piece is in place on our side. SAMTYGDTvimenning platform for Elhub integration - handles all message types and processes to Elhub. sends the metering values onwards the moment they are collected from ElhubNational hub for metering data and market processes in the Norwegian electricity market., rather than your system having to ask whether anything new has arrived. That is new functionality, and it is in production.
With it come the two mechanisms this article is about. The same data can be delivered on two streams in two versions at once, so a format change can be run in test on real data before production is moved. And the customer's own keys are placed per metering pointThe fundamental unit in Elhub - the unique point in the electricity network where energy is measured and settled, identified by an 18-digit GSRN number. and travel with the message, so the recipient avoids both parsing and lookup.
Statistics on the data flow sit in the interface: what got through, what stopped, and how last week looked against this one.
One clarification belongs here, because it is worth knowing before anyone plans around it: the keys are set when the metering pointThe fundamental unit in Elhub - the unique point in the electricity network where energy is measured and settled, identified by an 18-digit GSRN number. is created, and an APIApplication Programming Interface - standardised interface that allows two systems to communicate with each other. for changing them afterwards is being built.