January 2013

Posted by Carlyn Foshee Chatfield on January 11, 2013

Multidirectional Data Flow in Higher Education

Steve Riedl, Creighton University

For the first time, we recorded a presentation in the Virtual Coffee Shop!

Steve's slides are attached. Here are Carlyn's notes from the presentation:

• • At Creighton, I work in IT in the school of pharmacy and health professions. Back in March 2013, Creighton hired a data architect to talk about what we discovered along the way, what we learned from others about starting up a data warehouse and a concept we've come up with here that we call multidirectional data flow.

  • this is really about how to include everyone in the discussion for a data warehouse

  • Right off the bat, composite truth is the idea that a single version of the truth may be composed of several smaller versions

  • Departments begin to wonder how they can control the data, what happens if they "send" their data off to a central repository

  • Data types include:

    • • departmental,may or may not be institutionally significant

      • institutional, is institutionally significant

      • external (Core Data, etc)

  • Data integrity is most often maintained by the data owner. When it is your own data, you know what is true or not but when you put your data in a central repository, you have to work with lack of understanding by others who may not know what your data means or says.

  • Security! data CIA Triad - confidentiality, integrity, accessibility

  • Tricky, if something is highly confidential, hard to assure its integrity because only a few people can look at the data and maybe none of those were involved, know the details.

  • Coexist? different data may need to coexist. example: student success office, have to maintain particular pieces of data about students, but may not have access to that data at a central level so we have to depend on time-consuming data extracts. If we can just pull the original data into the central data warehouse, we don't have to have duplicates or the work that goes into them.

  • HUB AND SPOKE model. Tool needs to be flexible enough to centralize (hub) the data but allow the owners (spokes) to do what they need with and around their own data.

  • Accessible? All institutional data should live in the central data warehouse but only some departmental data may be appropriate for the central data warehouse...only the institutionally significant significant departmental data. Example, in the health sciences, we may have real patient data that needs to be available and used by faculty, students, but that private data is not institutional significant for the central data warehouse. How to keep doing business without having to use constraints of central data warehouse? You may only need to pull part of that data, not all of the data.

  • Why go to all this trouble? Slice and dice the data is important, allows better decision making. Tools must be able to pull from multiple sources. One tool we looked at required us to make a lot of effort to get institutionally insignificant data into the central warehouse in order to get the small amount of institutionally significant data into the central warehouse.

  • For true value, tools must be web based and flexible. We use several different tools for departmental and institutional data collection, warehouse, reporting.

  • Build vs buy - you can have a vendor come in, try to understand the business, try to create something useable that provides value, but there are often so many changes that we have to make on an institutional level, we are almost building it even if we buy the initial tool.

  • Staffing and resources: peers indicated somewhere between 8 and 12 people. Centralizing the ability create central reports, even merging all the different spokes' data flow. You will also have business analysts, systems analysts, people actually running the data base. Over a 5 year projection, our vendor's product would cost $250K, plus $150K in vendor consulting, plus 8-12 people - worked out to $4Million project over 5 years.

  • It really takes people internally to achieve the most value, best efficiencies. Our first staff hired was a consultant that did one portion of our warehouse. Spent $100K and a lot of time, since scrapped that. Think carefully about what you want before you hire that first person.

  • Remember, "why are we doing this again?" Many people who stopped by the EDUCAUSE poster session had started a data warehouse, started again, and some even started a third time. Keep the use case first and foremost. The real ROI doesn't exist in the fact that you built it, it is that you use is to positively impact the business process.

  • Can any vendor come in and really understand your organization without spending a lot of time with your constitutents? You have to be able to take some kind of action on the information you gather. If there is no willingness to change a process (departmental level, institutionally), then don't do a data warehouse. Everyone has to be willing to change a little for the overall benefit of the central data system.

  • Don't start with a mad rush to collect data points from constituents, ask instead "what question are you trying to answer?" then we help you find the data that supports that process or research.

  • Don't expect a vendor to deliver a working central data warehouse if you don't have faculty/staff onboard. The vendor has to spend a lot of time with them in the beginning.

  • Q&A time

  • Q: Who owns it?

  • A:Creighton started it in Central IT, but we're convincing the executives that it is owned by the university. We want everyone to be able to keep doing business the way they do business but streaming into the central interface. Looking at hiring a person to head up the "university owned central warehouse"

  • Steve Q: How are you bringing people together to build data dictionaries, etc.?

  • Audience A: Still working with institutional data, in office of CIO have not done much with gathering data analytics, just initiated meetings of different departments. Involved all of the business offices. Brought some people into the project on a part-time basis, actually housed part time in IT to build the university's data dictionary, start project.