Leadership1 publisher2 min readPublished
Four different deadlines hid inside one utility program's 'real time' requirement
On one utility program, operations, billing, payments and finance all asked for fresher data in the same words. Cognizant's Govinda now asks what decision the data triggers before asking how fast a platform can move it.
The Board Room · Leadership desk
What happened
- On a utility transformation program, a Cognizant senior manager found the phrase "real time" repeated so often in reporting discussions that it sounded like one requirement, and it was not.
- The deadlines behind it differed: an operational exception needed attention within minutes, billing was more useful after transactions were processed and validated, and finance ran on completeness, controls and cutoffs.
- Once the blanket term was dropped, business teams could say which delays actually affected customers or operations and which reports simply needed to be fresher than they were.
- Govinda says analytics discussions move quickly toward streaming tools, pipelines and dashboards before the business action is clearly defined. Overengineering can begin there.
Compiled by The Board RoomSomething wrong?How this is made
Why it matters
- cost Cutting latency buys infrastructure, monitoring, data quality controls and operational support along with it, and a process whose action gains nothing from the speed still funds all four.
- exposure Until someone owns the case where the operational number and the reconciled number differ, that reconciliation gets argued out live in a management meeting instead of at design time.
- constraint The evidence is one manager's experience of one program with no cost figures attached, so it can order a board's questions about freshness but cannot price the answer against a vendor quote.
The column names four acceptable-latency bands sitting under the one phrase [20]. Seconds or minutes matter for a service interruption, an equipment alert or a failed transaction, because someone needs enough time to intervene [9]. Hourly or intraday updates suit work queues, exception monitoring and demand trends, which Govinda says need to be current without requiring continuous streaming [10]. Billing, finance and regulatory reporting take the other two, a controlled daily view or a period-end one. A report delivered immediately can be less useful when reversals, adjustments or late-arriving transactions are still missing [11].
One set of source data can therefore carry three designs at once: an immediate alert to operations when a transaction fails, an hourly summary for management, and a complete daily position for finance once reconciliation checks have passed [14]. Calling all three real-time analytics hides those differences, Govinda writes. The confusion arrives later, when a live dashboard and a validated enterprise report show different numbers [15].
Speed can also degrade the answer. Records in transactional environments do not always arrive in a clean sequence. Updates and reversals and adjustments can follow the original transaction, and reference data can change. So a dashboard can refresh every few seconds and still show an incomplete business picture [16].
A low-latency pipeline still needs handling for duplicate events, late-arriving records, incomplete transactions and changing business definitions [17]. "Without those controls, faster access can simply produce disagreement sooner," Govinda wrote [18].
He lists four questions to ask before the architecture is chosen. The first is "What decision or action will the data trigger?" The second asks how quickly someone must respond for the information to remain useful. The third begins "What is the risk of acting before the data is", and the available text of the column breaks off there [19].
The account supports that order of questions. Before asking how fast the platform can move data, Govinda asks what decision the data will support, how quickly someone needs to act, and what could happen if the information is incomplete [5]. On the utility program, that separated true low-latency needs from the cases where hourly or daily processing was sufficient [7]. "For me, that was the point where real-time analytics became a business design discussion rather than just a data engineering one," he wrote [8].
What to watch
- Publication of the column's fourth question, and of any before-and-after latency targets from the utility program, would fill the gap in the current text.
- A case study with build and run costs for the same program would let a board compare the hourly design against the streaming one on price.
- An account from the utility's billing or finance owners would test whether the live-versus-reconciled dispute was actually settled.