Data Governance Versus Data Management
Over the last four years, RHB has engaged hundreds of institutions in their strategic implementation and use of Technolutions Slate. Our activity in this space affords our team a unique vantage point on team structures, procedures and campus politics that often inform (or disinform) a successful build or independent project in Slate. During my first week at RHB back in 2018, I wrote this article on the 5Ws of Slate Implementation and it’s an article I regularly point both new and active teams toward as they think about maintaining in an ever-evolving system that has the ability to grow tendrils across an entire campus. This week, Megan Miller, Josh Henry and yours truly presented a webinar on data governance versus data management, focusing on the first (and most important) W in the aforementioned article, people.
When building teams around systems, we constantly hear things like “bad data, bad system” or “bad data in, bad data out” almost to the point of being cliche. The focus is almost always on the data, as it should be. But often, that’s where it stops. You know you need good data, you’re coming from systems where things were a mess and you make internal commitments to cleaning it up this time. Whether you were there for the initial implementation of the system from which you’re transitioning or not, everyone has the same goal: do it better this time.
Easier said than done. And that’s because we jump right into building. Event templates are assigned to our event coordinators to run with. Application and evaluation processes rest in operations. We need an inquiry form quickly, so someone just spins that up. Marketing hops in on the communications. And very quickly (or not quickly at all in many cases) we end up with a system with modules that collect data in different ways, redundant fields, misaligned process configuration and no clue what we should be putting in the export back to our SIS.
Trouble.
While it’s tempting to jump right in when you finally get your hands on Slate because of all of the amazing things you can do, it’s so important to take a step back and lay a foundation for decision making. It’s important to develop a governance model.
When we discuss governance with institutions, many teams immediately identify the individuals who will be responsible for the build or automatically assume they’re set with the captains they have in place. That’s management and we’ll get to that in just a bit. We have to drive the conversation higher. Governance is about establishing the people, procedures, policies and priorities necessary to ensure data is captured in a way that makes sense at micro and macro levels.
You’ve heard it before: “IT isn’t needed for your implementation.” This is an incorrect mindset to approach Slate (or any system) implementation for a number of reasons. Most notably, IT/IS will aid you in establishing what data elements are necessary in Slate to remain functional and advance operations in the SIS or any other systems you may need to link in. But the focus here isn’t just on why IT is a valued player at the table, it’s also in assessing who else requires (not deserves) a seat. Security. Marketing. Institutional Research. Going beyond admissions? Student affairs. Advancement. Finance. The list will vary per institution and per build but assembling this core governance team will ensure all voices are heard.
All of these voices will inform what data needs to be captured at what stages of the lifecycle. They’ll inform how data is used across their organizations in ways those of us at the input stage may not have ever even considered as we think about how we use the data ourselves. These voices will shape the ways in which we capture data for extraction into other systems for things like modeling or data visualization: how we secure data, when we delete it, how it’s processed across campus, as examples. This governance team will also discuss what has worked in the past, what hasn’t and how we can set the system up in ways that improve outcomes for all of these departments.
Those outcomes are driven by the procedures that are defined. That’s the responsibility of this team as well. How do we mitigate risk? How do we ensure we have clean processes for capturing information at different stages? How often should we allow for updates or changes and how does this impact our ability to be agile while also setting guidelines and expectations across campus? Who is responsible for ensuring all players adhere to these decisions? The procedures we’re focused on here aren’t necessarily geared at developing workflows in Slate from an operational perspective. Rather, they’re the procedures that outline how the system will be managed.
Policies are an important component here that run across all areas of governance. For example, defining when and what data should/shouldn’t be retained and for how long. Or, identifying decision makers and the policies for change and change management. How will onboarding and ongoing training be handled? How should permissions and roles be deployed? All of these considerations are vital in establishing policies that dictate steps that must be taken, decision-making chain of command and overarching maintenance of the system. Policies beget structure. Without structure, everything falls apart.
The final component of your governance model includes priority setting. Too often our team is exposed to conversations where priorities for implementation are not aligned. That’s usually a result of not having the right individuals involved. You see why we start this conversation with people? Are priorities for the build driven by timelines for opening applications? Are there other systems being sunset? Are you bringing search in house? Great, but these are all Slate-centric.
What about higher-level priorities and institutional goals? Boosting enrollment in certain markets? Driving an increase in giving by X% toward a specific campaign? Streamlining the student experience when scheduling advising appointments? The governance team is responsible for all these priorities and more. Decision-makers on this team need to be equipped to understand how these priorities relate to one another and then what other elements cascade from there. There will be disagreement in ensuring team members are aligned here, but eventually, the team will be aligned.
And when that alignment happens the build can really take off and that’s when we shift into the concept of data management or more specifically for this context, database management. Before we dive too deeply into the database component, it’s important to acknowledge that data management differs from data governance in that management is focused on putting the people, procedures, policies and priorities into practice. Data management is the custodial responsibility for ensuring that the data enters clean, stays clean and that all users are stewards of these processes.
Your captains might be on the governance team above or they might not be. But your captains will 100% be tasked with data and database management. These individuals are responsible for setting the strategy for the implementation and maintenance of Slate that meets the goals and priorities set forth by your central governance team. Where the governance team sets a priority, the management team determines the best course of action for defining the infrastructure necessary to ensure the system is capable of providing a solution toward that goal. As the Slate is a tool and not the solution, it’s important to remember that even here, the build needs to be defined by strategy and other stakeholders will be integral for success.
The database management team is responsible for building the fields and prompts, defining clean templates that consistently capture data, setting expectations of end users and keeping the governance team informed of progress and any shifting priorities or needs. As Slate evolves, part of the responsibility of these individuals is to inform the governance team of system enhancements or changes that might impact larger conversations and decisions on campus with regard to technology.
As Slate continues to expand and institutions are becoming increasingly creative in how the system can be leveraged outside of what we tend to think of as traditional implementations, the importance of strong governance models and strong database administrators focused solely on Slate will only continue to grow. Without these in place, institutions risk unwieldy infrastructure, disappointed stakeholders and skewed data.
