During the past year, were you invited to participate in your organization’s formal data governance efforts? Chances are, you will be asked to become involved in 2009. So let’s talk about what you—with your mainframe perspective—might bring to the table.
First, let’s talk about your first meeting. Walk into the conference room, and you might notice something interesting about the people there: It’s almost the same group you’ve been working with for compliance!
So, why do you need a different effort? Sometimes you don’t—governance and compliance are agenda items at the same meeting. But sometimes they’re different groups because of the drivers involved. Compliance teams deal with requirements that aren’t optional. They exist to tell management teams and workers what must be done. Governance groups, on the other hand, bring cross-functional perspectives together so management can collectively decide what to do, or how, or under what “rules of engagement.” So, governance efforts may be a little “fuzzier” than compliance efforts, with a little more politics and a few more compromises.
So, you don’t do politics? OK, but do you want a voice in setting standards? In clarifying the definitions of the data you work with? In deciding what projects should get done? In establishing policies for how work gets done? Put another way, do you want system architects who know a lot about relational database systems or SOA services (but nothing about mainframes) making decisions for you?
If you answered “yes” to the first set of questions, or “no” to the last one, then you probably want a voice in governance decisions. Here’s how you might be asked to participate.
You might be asked to be a data steward. This role might be a member of a decision-making committee, or it might be one of a large group of people who touch data and provide input to a committee member. Your work as a data steward might be a few hours a week, or it might be a few minutes here and there, as you adhere to decisions and point out issues to a member of a data governance stewardship team.
Alternately, you may never be asked to be a data steward. In some organizations, these titles are reserved for business roles. In this case, technology experts may be designated as Subject Matter Expert (SMEs) or data custodians—people who take care of data as it moves through their systems and processes, but who don’t “own” the data or vote on how to use it.
Regardless, you should remember that you’re also a customer of data governance—a data stakeholder—because the decisions made could have an effect on your work. As a stakeholder, you should have a voice in the process.
It’s especially important to ensure your perspective is represented when governance and compliance decisions are made by groups that might not understand your environment, drivers, and constraints. Here are some questions you should consider inserting into any governance-related, requirements-gathering discussion:
1. Will this decision/requirement require us to stop doing something, start doing something new, or do something differently?
2. How will this affect the availability of information? Is it designed to restrict access to information? If so, are we taking an application-centric view of the situation, or have we considered all the places the information resides in the extended mainframe environment, and all the ways individuals and systems can access that information?
3. Are we concerned about monitoring the flow of information, and if so, what assumptions have been made about that flow of information?
This last question might just prompt some interesting discussion, especially if governance and compliance participants are used to thinking about the mainframe as one big “box” on a data flow diagram. They may be surprised to know about different mainframe environments and how information in staging areas compares to data in report-ready marts and tables.
You may just get a long-overdue opportunity to educate corporate decision-makers about how mainframes manage their information. Wouldn’t that be great?