Regret after a data failure is common.

Repair after regret is rarer.

The difference is ownership.

Having led analytics practices in my career, I have seen teams feel sincere regret after data issues, but sincerity does not fix the issue. The useful turn comes when architects help convert the lesson into ownership, lineage, controls, and evidence.

Every organization has moments when the data was wrong.

A leader used the wrong number. A customer impact was missed. A regulatory report needed rework. A transformation dashboard created false confidence. A planning model assumed clean master data that did not exist. An AI pilot produced a recommendation no one could explain because the source lineage was thin.

Afterward, people usually feel bad.

They apologize. They explain the pressure. They say the team was moving fast. They promise to be more careful. Sometimes they rename the issue, soften the language, or bury it in a lessons-learned slide.

But regret is not repair.

For a Strategic Enterprise Architect, the question is whether regret becomes a change in the enterprise system. Did the owner change? Did the definition get corrected? Did the lineage become visible? Did the control move closer to the data? Did the SAP field, integration rule, exception path, or reporting dependency get fixed? Did the decision forum learn what evidence it should have asked for earlier?

This is where data architecture becomes an accountability practice.

Not blame. Not theatre. Not a hunt for the person who touched the last spreadsheet. Real accountability means the enterprise can name what failed, where it failed, who can fix it, and how the same weakness will be detected next time.

EA coaching can help teams move from embarrassment to disciplined repair. A good architecture conversation gives people enough structure to tell the truth without turning the room into a punishment exercise. It connects the failure to capability, process, ownership, systems, data movement, and decision impact.

Cornerstone’s enterprise architecture support is valuable in exactly these uncomfortable moments because transformation programs need more than regret. They need repair paths that leaders can fund, govern, and trust.

Regret only becomes useful when it changes the design.

Reflection

Where has your organization felt regret over a data issue but stopped short of repairing the ownership, lineage, or control weakness underneath it?

Practice

Take one recent data-quality issue and write a repair note with five fields: failed decision, broken data path, accountable owner, control change, and evidence that the fix is working.

Ever get the response “I’ve tried to cleanse data before, it’s too hard!”?

Darin Paton is the Owner of Cornerstone Consulting Inc., an Alberta-based enterprise architecture and SAP ERP transformation advisory firm serving organizations across complex business and technology change for over 15 years. 30+ years as an EA and advising in SAP transformations.