What’s Rogue One: A Star Wars Story about? The hero’s journey? Intergalactic civil war? Self-discovery?
It’s about data governance.
Maybe Rogue One isn’t only about data governance, but governance is certainly part of it: the Empire has vital data about the Death Star’s one weakness. They lose that data, and they lose the Death Star.
Check out this real intercepted Imperial voice memo to figure out why I call this film Rogue One: A Data Governance Story.
Also, spoilers. Major spoilers.
FROM: Grand Moff Gary, Head of Imperial Intelligence
TO: Stormtrooper THX-1137 (firstname.lastname@example.org), Chief Data Governance Officer, Project Death Star
It’s Gary from Imperial Corporate. Carl, you know I’m not usually a believer in negative feedback, and I hate to do this sort of thing, but we need to talk.
So I just got wind about that whole snafu on Scarif, and how the important information about the Death Star’s whole thermal-exhaust-port weakness was beamed to a Rebel ship.
Nerfherder move, Carl.
As official Death Star data steward, you should have realized that the whole “secure-our-vital-data” thing is a pretty big part of data governance. You know as well as I do that data governance is “an overarching strategy for organizations to insure the data they use is clean, accurate, usable, and secure.” This time, however, we’re the ones who got arched over.
I’ve got a bad feeling about this, Carl. And so should you.
Data Security no-no’s
Admittedly, you’ve done pretty well with three of the four pillars of data governance— keeping the data available, making it usable, ensuring its integrity—which is great, kid, but don’t get cocky.
Carl, I find your lack of data security disturbing.
One of the worst data security mistakes you can make is failing to assess internal threats. We had an imperial cargo pilot—a cargo pilot!—manage to get away with information about the Death Star’s weakness. Now, I realize making round trips to the Death Star several times a day means you’ll know a thing or two.
But when that cargo pilot can help a bunch of Rebel scum find their way to the Death Star R&D on Eadu, that’s just bad security, Carl.
That defector cargo pilot thing also represents a data governance compliance problem. You know how important it is to ensure compliance with laws concerning data governance. And you know as well as I do that Imperial Data Governance rule one is: don’t let the Rebel scum know about your huge planet-destroying weapon’s achilles’ heel. Consequences for non-compliance can be steep.
Data Governance Strategy
Now, I know you’ve got a tough job, Carl. A good data governance strategy walks a fine line between control and access. Users should be able to access the data, but not at the cost of security.
And as much as I value access, I think you erred a little too much on that side this time. If multiple systems access and use your data—and maybe you haven’t noticed, but WE HAVE A LOT OF DROIDS, CARL—you’ve got to have better policies to regulate data’s flow from one point to another, while still meeting security demands.
My point? When a reprogrammed Imperial droid can jack into our security as easily as that reprogrammed K2S0 unit did on Scarif, that’s a pretty scruffy-looking data governance framework flub-up. Could we not tell he was reprogrammed? Did you not catch on when he started shooting stormtroopers?
Priority one when you get back to work today, Carl—see to better endpoint security for those data ports we have everywhere in Imperial facilities. Can you imagine how disastrous it would be if some rogue astromech droid could, say, shut down all the garbage compactors on the detention level of the Death Star? Just spitballing here, but still.
Data governance best practices
Sad to say, but you fell down on a lot of best practices, Carl, and you should know better than to fall down at all, given how many inexplicable heights are in your average Imperial installation (am I right? Why are all our walkways like half a mile up?).
Not trying to be judgy, but here’s some data governance best practices you could improve:
— Data governance best practice 1: A good data governance program has to involve both the IT side, and the end users of the data. Everyone knows how important it is that data professionals be “active participants on development teams” of data governance plans. If data professionals and the admin/business side don’t get along, there’ll be nothing but trouble.
Case in point? I realize Orson Krennick was a hothead, but when an Imperial officer has the whole data science team killed, there’s definitely an IT/end user communication breakdown there, Carl. Yeah, you didn’t give that order, but like Grand Moff Tarkin always says, the credit stops here. Which brings me to…
— Data governance best practice 2: Proper accountability. As Death Star data steward, you were the one “ultimately accountable for ensuring that governance procedures are followed and their team members comply with enterprise data management policies and standards.” You’re also accountable for making sure all stakeholders work together successfully.
And part of that, hate to say, is making sure the end users don’t get so annoyed with data breaches that they annihilate the data science team. I think this was a case where you should have intervened and de-escalated.
There’s ways to get IT and end users on the same page. Get the two parties to talk. Buy them a round of blue milk. Set up a holochess league so they get the chance to have some fun and let their hair down.
— Data governance best practice 3: The need to define “practices and policies to deal with business rule deviations.” Know what’s a pretty big deviation to business as usual, Carl? Half the blasted Rebel Fleet appearing half a mile above our poodoo data warehouse to steal our vital information.
You didn’t consider this, Carl? Not once did you think, “Hey, our everyday business processes might run into the issue of a gajillion space ships trying to blow them up?” I’d say that’s a pretty big deviation, Carl. Should have accounted for that one. Instead, we wound up looking like the sort of doofus who pulls a fleet out of light speed too soon.
— Data governance best practice 4: You also, of course, want to “focus on the relationship of the key data elements and the business processes they support.”
It’s no secret (among we Imperials, at least) that the premiere business process for the upcoming Imperial FY is blowing up planets. But if a key data element, like the existence of a station-destroying chain reaction, gets out, there goes that top-notch business process.
Maybe if you’d better emphasized the connection between data and business case, there wouldn’t have been so many loose lips sinking ships. It’s not that hard, Carl, just get the other stormtroopers in a room and say, I don’t know, how useful fear is at keeping the local systems in line. In other words, use your…
Data governance soft skills
You could definitely have used soft skills a little better, Carl. When you’re trying to set up a data governance framework, you have to be able to communicate, to an employee, why governance matters. You’ve also got to persuade them that the proper governance framework will make their data safer and more accessible.
For instance, you could have asked the users to “spend time explaining… what they do and how they interact with data.” You could have “run workshops with key consumers of data to help them learn how to document requirements in terms of data quality rules.” You could have reminded those guys who fire the giant cannon that they can’t brag about it when they’re on shore leave, and that, no, they’re not getting that railing. I hate to sound bad, but a little more soft skill finesse would have helped. I mean, you’re dealing with individual people here, not just clones of yoursel—
Sorry, Carl. Didn’t think that time.
Planet Alderaan awaits
I’ve got to wrap this up, Carl. Sorry if I’ve come down hard on you—vacation started yesterday for me, so I guess I’m a tad testy. I’m catching a red eye lambda class to Sandals Alderaan for some much needed r&r, so at least there’s that.
As a result, though, your official performance review’s going to be with Lord Vader. I’d suggest you focus on the positives, rather than losing the plans. Or maybe just wait for him to bring it up. He always seems pretty quiet, so I’m sure he won’t force the issue.
Any other data governance lessons from Rogue One I missed? Don’t give up like an R2 unit with a bad motivator, let me know in the comments below!