Skip to end of metadata
Go to start of metadata

The reading for this week was a white paper by Rick Jaffe on Providing Services for the Enterprise vs Supporting Research.


Divide between concerns of central IT and researchers
Differences in goals, priorities, timelines, budget practices, resources, rewards
Makes partnerships difficult
Researchers' trust in central IT is essential -- must earn and protect that trust
Faculty don't see themselves as "customer", "the enterprise of campus is research/teaching"
Services, shared services -- raises hackles
Lots of unspoken stuff that we need to understand to develop this relationship
What can we do about it? How do we become a trustworthy partner?
Enterprise service -- low-touch service by definition
Research computing understood to be high-touch
Establishing expectations (cost, support vs self-support, etc.)
Need to understand where a service lies on that spectrum, sign up for that upfront
Secure data falls back to users-- don't have staff to vet everything
In beginning phases, with service definition, looking at business value to campus
Has to be scalable at a certain scale, and has to not do certain things
Saw that best path was to retreat from initially high-touch service (Media Vault)
Thought that Research Hub would get there -- product roadmap, local engineering, etc.
At the time, bSpace had crude file management tools, Calshare not usable on Mac, didn't have Box/Google
Now there's a better bSpace, Box, Google -- now how to define service and make it competitive, but also question of adding/subtracting services
Library IT sent out emails out about Box and Google when they became available, but message has never gone out about Research Hub
Communication can't be underestimated -- importance of framing and relating to customers
Have to frame discussion when you're rolling things out -- can't always tell a happy story
IST -- does have more resources for communication, but it does take real effort
Engineering is expensive, risky, etc. -- often focus on user needs, engineering a solution
Could live with it as is, focus on awareness, have conversations about what we have vs. don't
Overlap between Box and Research Hub -- not dealing with sysadmin stuff frees you up to do outreach (in favor of adopting external products)
Research data management program is critical
People aren't passionate and engaged about general services, they just want it to work
Opportunity to tap into that energy, engagement
If we'd had success around research data management around Research Hub, would've gotten us closer
Will always have a small team, how to leverage campus energy
Needed to have a programmatic component, even beyond the service
What is meeting point between what ETS is working on, RIT work
Roles of teacher/researcher involve different packages of services
How to avoid duplicating effort, fill in the gaps
Question of how ETS works with BRCO, Center for Teaching and Learning, involvement with questions around pedagogy
Strong communications in ETS compared to IST
D-Lab also does communications well
Aggregating demand -- 1500 faculty, they don't think about moving things up the organizational chain the way we expect in IST
D-Lab is embedded on research side
Grad students could also use something like Research Hub
BIDS -- lots of different things, not a unified perspective
3-5 year support guarantee vs. 3-5 year worry something will be around (how long do you have to keep old things around?)
How easy is it to migrate to the next system?
Be willing to be flexible, because we're here to support research and teaching
Lots of needs are similar, but expressed in different vocabulary -- have to speak in their language
Opportunity to do something at scale that meets needs of different groups
Sometimes language isn't the problem-- there's a legitimate gap
Administrative users are used to using frustrating systems; faculty will just say no if it gets in the way of their research
People want an integrated suite of things -- if something does 80-90% of what they want, but doesn't meet security needs, they'll use it anyway
Have to make an argument to campus-- people will do things that will put the university at risk, but we're not enforcers
Individual researchers won't take on the issue of campus risk
Researchers may use cheap storage because it's not backed up, even though it's in violation of data management plan
In that case, campus needs to price appropriate services more competitively
HPC - result of multiple fronts; losing faculty, losing money on grants, campus needs to deal with this
Research hub -- thought it was a service for researchers
Research data management -- also designed for researchers
Sustainability: realization that there were a lot of administrative uses as well (records management); this necessarily splinters any staff trying to deal with end users and tell a story
Dealing with a series of verticals, not the one you identified -- can't split up a person to deal with horizontal and vertical service
Research data management can help with research data issues, but won't fix issues around other potential users around this, whether we should address verticals
Research data management -- natural connection, but can't involve taking on administrative and records data management
Records management makes sense here, but turning it into something that could be funded would require a large transition project
Lots of things make sense, but need someone to champion it
Didn't go to VCR and ask for money -- faculty were feeling pain, wrote to CIO/VCR with request
Lots of work to put together a program
Larry was willing to contribute $1 million, and this brought in more funding
Very compelling story -- can quantify grants we're losing
What's a vision for the thing that you can craft a story around?
Research Hub -- remarkable how inexpensive it is,  this is problematic in budget
When you just need $50-100k, lots more competition at that level
Honest cost of running Research Hub -- $300k/year
Bits and pieces were sharded together, never put forward boldly with sponsorship
If CDL integration were pushed from the beginning, super-compelling use case
"Why you not Box?" -- that's a clear story
Spent a year trying to define the differences
Name "research hub" but URL hub -- straddling the fence
Were hoping researchers would be interested, but wanted to free up subdomains
Faculty aren't organized in a hierarchical structure, so communication path isn't always clear (can't just send it to the deans)
Only way to do it is to network with people who deal with faculty (Library, ETS, D-Lab)
Networking takes work, but that's part of marketing/communications
Balance between end-user support, backend support, and then marketing/communications
Does physical location matter?
People walking by your office -- they're busy and don't want to talk
Find the places/times when they do want to talk
Indirect network of connections to faculty
"Marketing" doesn't translate well -- some people think we shouldn't be doing marketing because we're in higher ed
CIO's job is marketing
Researchers don't know what they want, but they know what they DON'T want
Not that they don't want to be cooperative, but don't know how to manage records and don't want to do it-- want it to magically work
Our job is to promote prima donnas
In other places, everyone has to be on the same page or they don't have a job
Contract with Google isn't guaranteed for 3-5 years
University's own services seem to be held to a higher standard
Google may decide to back away from apps for higher ed
Google could easily provide more services if they wanted (or less)
Google/Box -- can share something with anyone
Had strict requirements for sharing, guest accounts in Research Hub -- holding selves to higher standard?
Need better coordination from IST as a whole
Better data management, longevity -- key value
Who do you talk to to make it more evident to researchers?
Talk more amongst ourselves about how we do portfolio management, making more consequent decisions
Either someone is assigned to be a champion who has to find a functional owner, give it a timeframe, otherwise it gets shut down
Can't have all these loose threads everywhere
Want portfolio management to itself be manageable
Demand has to come from academics, researchers, grad students, whatever governance there
Shouldn't spend lots of money building mousetraps when units that are more closely aligned with the "real enterprise" need money
IST isn't here to just make up stuff 
Not that IT should be invisible -- researchers don't want to track IT developments
Enterprise services that just work should be invisible
Need to do some education, "this is what we should do"-- can't do it without them buying into it, but we can advocate for doing it differently
Big gap: bright grad students who know about technology, but aren't IT architects
Media Vault failed -- didn't have IT architecture perspective from the beginning
Would like to do workshops for the grad students who support research
Trying to figure out how to make this clear to faculty -- don't want to impede innovation, too expensive to hire as developers, but maybe do workshops
Strategic consulting activity -- engagement re: what you should do about storage (we're not providing it, but working between them and storage team re: what's available, etc.)
How to get the word out about workshops? No reliable mailing list to get the right people
Within every department, part of structure is someone to be touch point for IT from teaching/research perspective?
Trying to accomplish this through IT Managers forum
Once you're in touch with them, how do you get them to make contact with their customers?
80 departments on campus w/ 1-2 people doing IT for them, mostly completely isolated
IT people don't have connection with what's going on in research mission -- lots of desktop support
  • No labels