Data Governance Matters

Projects, Process, Architecture, and Governance

Where does Data Governance take place? a client recently asked me. Do I need to look at projects, process, or architecture?

My answer? Yes, yes, and yes.

Obviously, if you’re going to enforce data-related rules, you need to look at how you do projects. There are places in your SDLC where you’ll want to embed Data Governance. There are only a small number of insertion points, but they’ll be critical to achieving your governance goals.

But projects start and finish, I continued, and lots of what you do never is addressed through a project. So you’ll look at processes – business processes, technology processes, and risk/compliance/security/audit processes – where you’ll also want to insert Data Governance.

And of course you have to align your efforts with those of your architects, I continued. You could undo each others’ work in a heartbeat if you don’t carefully align what you’re doing.

And by the way, you left out a category, I continued. Governance itself. You have other governance mechanisms – IT Governance, Change Control, etc. – that you also need to align your efforts with. Chances are, efforts that would require 10 steps if you do them independently could become a simple line item in an existing governance process. You need to add all these types of folks to the list of groups to meet with when you’re roadmapping your program.

When I was finished, he looked tense. That’s a lot of work, he said. A lot more meetings than I thought I was in for. Are you sure this is all necessary?

Nope, I answered cheerfully. You can skip any or all of this. As long as you’re willing to make decisions that don’t stick, to undo the hard work of your peers, and to have them step all over what you do.

Now maybe there are leaders out there who would sign up for that path. But not this one, thank goodness. He reached in his drawer and got out a fresh sheet of paper.

OK, he said. You’ve convinced me. So let’s start over, from the top.