Recently, I helped a client set up a Data Governance program driven, in part, by compliance requirements. One focus area for the program was formalizing access management for enterprise data and reports. We discussed options for data classification categories and role-based rules for access to reports, and then it was time to move on to raw data.
“We know we need this,” the program leader said, “but we’re not sure how to get started. It looks like a prohibitively large effort. And, we’re not sure how to organize it.”
“To begin with,” I suggested, “why don’t we identify core data and create simple CRUD charts. Then, you can issue management directives that match those CRUD charts. Finally, we’ll insert governance into your data-related processes by ensuring your staff grants permissions only in accordance with those charts.”
My advice was met with silence and confused looks. Eventually, someone asked, “What’s a CRUD chart?”
Yes, I had an honest-to-goodness AHA! moment. I realized this little tool, this simple chart that’s mastered and used by data managers around the world, isn’t necessarily familiar to business managers. Here’s a chance, I thought, for those who use this tool to shine, to bring value to the business, and to help solve compliance-based business problems.
Before I go further, let me say that some of you might object to the characterization of CRUD as a “four-letter word.” Yes, it’s actually a four-letter acronym for CREATEREAD- UPDATE-DELETE—the four types of traditional data access permissions that DBAs grant to credentialed users. But hey, an acronym is technically a word, so give me a break.
Once used almost exclusively by DBAs and technical staff to facilitate the job of granting permissions, CRUD charts are becoming compliance management tools. Why? Limiting access to data is a key requirement of many compliance initiatives, and CRUD charts can illustrate a complex set of access rights in an easy-to-read, easy-tocommunicate format.
I explained to my client that his data management team was no doubt familiar with these charts, these matrices with users listed in one dimension and data subject areas (or even individual data fields) in the other. I explained that his team was probably OK with the reality that permissions today might be a bit more complex than the acronym would imply. “For example,” I said, “the ‘C’ could actually encompass creating data, collecting it, or even acquiring it from third-party sources.”
“The ‘R,’ I continued, “stands for the technical concept of ‘reading’ data. However, using business terms, we might instead refer to permission to see data, to pull that data into another system or feed or report or process, or to use it in some other way. ‘U’ stands for updating the field, and ‘D’ stands for deleting the data, although in today’s environments we might use additional letters to illustrate a more complicated lifecycle involving storage, archiving, retiring, and deleting information.”
I sketched out a little sample chart, illustrating with a mix of letters scattered across the matrix how existing permissions that were currently documented deep within technical tools could be summarized in a compact chart. We discussed compliance records that might be simple attestations stating that users had been granted permissions according to access rights that were documented in dated and versioned CRUD charts. His concerns that compliance documentation might take reams of paper and hundreds of hours evaporated.
And I smiled, thinking of his DBAs and data architects who were about to be given a few moments in the spotlight.
So, what does it mean to you? How does this four-letter word reflect a compliance option?
If you’re trying to sell your compliance team on an alternative to the “reams of paper” approach, you must be able to explain the alternatives. This isn’t a challenge with relational databases; it’s easy to picture database tables as grids, with columns of fields and rows of records. It’s easy to imagine replacing the rows with user roles, then filling the squares of the new grid with C’s, R’s, U’s, and D’s.
But mainframe data architecture constructs, with their fields within fields within fields, can be harder to visualize and understand. So, that’s your challenge: to translate your lists of data subject areas into columns in a matrix, so you can construct a CRUD chart.
Somehow, I think you’re up to it. Z