Choice, Responsibility, and the Cloud
Earlier this week a conversation started on the EDUCAUSE CIO list regarding individuals (and departments) picking their own tools to perform their job functions even if it duplicates something offered centrally. I responded with some partial thoughts that I thought I’d try and flesh out here.
So yes, everyone should have choices. But as every super hero knows, with great power (and choice is power) comes great responsibility. If departments or individuals want to pick their own tools, that’s fine. They then have the honor of supporting them. Basically, the logic looks like this:
- Institutionally selected tools: supported by IT
- departmentally selected tools: supported by department
- individually selected tools: supported by individuals
Support is this case includes everything, including things like user training and questions, data integration, contract review, security audits, procuring permission from appropriate institutional areas for data sharing, and the list goes on. That seems pretty straight forward, expect I find this is where the wheels tend to fall off. Every area wants to be able to choose the tools that they think are right for them, but few want to be responsible for supporting those tools. If you don’t want the responsibility, then the only suggestion I have is to use the institutionally selected tools and move on.
The question then moves to how central IT can enable an environment where we can have conversations about choices and responsibility. The most straight forward (and likely hardest) answer is a set of institutional APIs that allow pull and push of data based on a set of permissions developed and maintained by your data governance group (if you don’t have a data governance group, please stop, get that going, and then come back here). The second (also hard) option is a set of defined import and export files agreed upon by the community and, again, maintained by the data governance group. Either way the result is the same. Departments and individuals approved to access or update institutional data can do so with whatever tools they want using either an API or a pre-defined import/export file format.
Over a decade ago I worked at Duke University in one of the decentralized IT areas (Student Affairs). During my stint there the University moved to Peoplesoft, and early in that process the central IT group brought together functional and technical folks from across the institution to have a conversation about data exchange. Several months of work resulted in a defined export file of student data available to any department with permission (there was never any serious conversation about importing data into Peoplesoft). So as a distributed IT person, I got access to a file of student data (updated daily) that I could use without any further support from central IT. I still had to get permission from the Registrar if we shared any non-directory information with outside companies, and I had to adhere to any FERPA holds students placed on their records. I had to review contracts and security for outside firms. And it was my job on the line if something went wrong. And with all that, we did some really interesting work in student affairs using departmentally selected systems that we supported locally and not by central IT.
So what does the cloud have to do with all this? At some basic level nothing. In a very real way though, the cloud has everything to do with this issue. It has made new services available to more people faster and with a lower resource threshold for start up then ever before. Organizations that are fortunate to have a robust data and IT governance structure are likely able to adapt to cloud services much more easily. Those that don’t will need to get those structures in place so that they can begin the conversations about how to handle the integration and support of known and unknown services.