Skip to end of metadata
Go to start of metadata
Table of Contents
The root page UCB Tools and Services Registry could not be found in space IST Research and Content Technologies.

Ian

Use Cases

Departmental IT Person

  • Directing users to appropriate tools for their issues
  • Stating which tools are supported in the department at a different level (either above or below) where they're supported on campus
  • Provide guidance about departmental licensing agreements
  • Provide guidance about departmental support
  • Provide guidance about departmental restrictions (policy, legal, etc.)
  • See which tools are popular in the department, and therefore might be good to license or support more fully
  • See which other departments are using/licensing a tool, for use to share support burdens, licensing costs, etc.
  • Become a center of excellence on campus on a particular tool, possibly selling support for that tool as a recharge service (bring in more money)

Central IT Person/IST Management

  • Provide guidance about campus-wide licensing agreements
  • Provide guidance about campus-wide support
  • Provide guidance about campus-wide restrictions (policy, legal, etc.)
  • See which tools are popular on campus, and therefore might be good to license or support more fully

Any IT Person (Departmental or Central)

  • Give guidance about appropriate use of a given tool in a given context (restricted data, safety of data, legal restrictions, reliability of service, etc.)
  • Answer support questions about a service that that IT person runs, in a public forum so other users with the same issue can resolve the problem without contacting support directly.
  • Gather feedback about a tool to improve a service (whether through direct action or by lobbying a vendor)

Any Person affiliated with campus

  • Find a tool to fulfill a particular need
  • Get answers to questions about a particular tool
  • Understand trade-offs between cost/security/privacy/reliability/etc.
  • Publicize a tool that's useful for a particular use case
  • Answer other user's questions based on own experience/knowledge
  • Find other people with similar use cases, interests, etc.  (May be the basis for the initiation or expansion of a community of practice, but supporting that community fully is probably outside the scope of this project.)
  • Rate and share experiences with using the tool
  • Share tips, tricks, workarounds, particularly useful features, etc.

Success Metrics

Adoption

  • People should actively use it

Fresh info

  • This information can get out-of-date really quickly. There should probably be some way of aging or depreciating the information.

Rick

The tools and services registry proposal arose from the Collaborative Tools Strategy that Ian Crew, Aron Roberts and I authored. (See http://collab.berkeley.edu/projects/ucbcts/ucbcts-strategy_20090309.pdf.) Rather than being a response to a particular use case, it developed as a strategic response to a set of IT demand and supply conditions.

Vision

Early on in our research, Ian, Aron and I [collaborative tools strategy team] learned the importance of “Identifying the specific collaborative behaviors that users seek to facilitate or augment,” rather than trying to support collaboration generally. (The quote comes from the Collaborative Tools Strategy Spotlight document, “Tool Selection Criteria,” available at http://collab.berkeley.edu/projects/ucbcts/ucbcts_spotlight-tool_selection_criteria.pdf.) This precept went against the prevailing current of standardizing the campus on a small set of tools: the range of needs and favorites was too great to satisfy with a small toolkit. Since we understood the difficulty (budgetary impossibility) of supporting all the tools in use on campus at the time (i.e., the demand), we sought a way to create communities of practice among campus users around specific tools, expecting that these communities could do much of the heavy lifting involved in providing user support.

Goal 1 of the strategy (page Strategy--6) described the registry and the intentions behind it. The registry would serve as a means to give users information about the tools in use by their colleagues, the degree of support behind a given tool and, importantly, the most appropriate uses of that tool – mission critical, safe for protected data, etc. (This represents the supply.) Goal 2 of the strategy, “Establish a common framework and vocabulary for defining support for collaborative tools” (page Strategy-7), added an important component to the plan. We anticipated that the framework, with its tiered support levels, could serve as a strategic tool for users, providers and policy makers to use in deciding how to steer future investment. Advocates could define a project as introducing a tool to campus at a particular support level or raising a specific tool from one tier to the next: for example, wrapping CalNet authentication around a popularly-used platform to make it even more suitable for (and desirable to) campus members.

Overall, we envisioned the registry as a way of narrowing the pool of tools in use – assuming that the campus’s favorite and most supported tools would become more widely adopted and, eventually, win the day.

Use Cases

Several use cases become apparent, even though they were not the drivers of the strategy:

Academics

Faculty, and especially their graduate and undergraduate students on whom they often rely to discover, implement and support new technologies, could come to the registry to learn from the experiences of colleagues. By joining a community of practice around a selected tool, they could broaden their base of knowledge and support, thereby lessening (hopefully) the amount of time they must devote to technology. The community of practice could serve as a body of institutional knowledge, quickly educating new students who replace graduating student-experts. Staff, too, could use the registry in these ways.

Specifically, a faculty member, student or staff person could come to the registry, search on a tool by name or by purpose – Salesforce.com, data visualization, etc. – and quickly determine if it were the right tool for their case. Searchers could look for recommendations made by people that they know; they could weight their assessments based on some indicator of reputation. By reading the campus support assertions, the user experiences, the vendor documentation and other types of information on the registry, the searcher could make a well-informed decision. Because the registry would be wiki-based or wiki-like, these community members could add their experiences and expertise to the shared body of knowledge.

When in need of a specific answer to an issue with a tool, users could post a question to a discussion thread, knowing that they were asking it to the right audience. In this way, the registry would mimic successful email-list tools already in existence, such as Micronet, MAGNet and, in a very different domain, the Berkeley Parents Network. 

(Note that one could argue that these lists thrive because of their unstructured, undirected nature; there is a risk that attempting to “build” communities of practice within a highly defined Web environment would be unsuccessful in the busy, decentralized, personable UC Berkeley environment. It would be smart to shape the tool with – or, at least, to learn from – the input of the members of these groups. )


IT Providers

IT providers across campus could publicize the tools and services that they provide, assert their level of support for these tools and services (as well as the campus systems and services that buttress them) and identify the audience that they have the means to support. If time and inclination allow, they could promote themselves as campus experts on a given technology (potentially facilitating campus-supported centers of excellence or, perhaps, markets for technology support). Other providers might shape their IT offerings around already-available tools and services, share their expertise and commit their resources to extend existing offerings, or organize users, providers and campus managers around efforts to broaden or otherwise improve the quality of the offerings. 

(The scope of the registry need not end at the campus border, although the proximity and familiarity among campus members would probably help sustain the communities of practice. It would be interesting to see which cases lend themselves to a wider sphere of participants, and how disciplinary or subject-matter bonds, rather than institutional ones, shape involvement.)

IT Architects and Managers

IT architects and managers have need for a way to identify and track the numerous service technologies available across campus. These members of the community could use the registry as an instrument to assess the strengths and weaknesses of the campus IT service portfolio, determining areas of overlap and of need. To enhance reuse, they might delineate the technologies and protocols, services and data standards on which the numerous campus platforms and applications are based. They might also use the registry to quantify adoption or otherwise measure the benefits of a given set of technologies, services and standards; a registry would be a public display of both the demand for these various components and the value gained from their shared use. Use of the registry in this way could guide IT architects and managers in their decision-making and help them sell their vision of shared and reusable IT infrastructure.

Rich

Micronet

Micronet is a group of ~600 participants, the significant majority (95%) of which are campus technologists. It is estimated that ~80% of the group serve as unit/departmental technologists and ~20% are part of IST. Micronet has an active listserv; it is estimated that on average ~50% of the discussion on Micronet involves technologists requesting recommendations about a) which technology product(s), tool(s) or service(s) can best meet a specific functional need or b) whether a specific product, tool or service can meet a functional need. This is a subset of the departmental person listed by Ian.

Searcher
A tool and service registry could provide a site where a micronet affiliate could go to look for products with general descriptions. To be effective it would need to have information strongly categorized and/or searchable by functionality, and have a strong ontology to broaden a search query beyond the initial key words. A searcher would find significant value in reviews of how other users fared with a product in their specific context and how other users rated the product. Searchers would also find value in being able to note whether a review was helpful, allowing the most helpful reviews rise to the top of search results. As trusted experts surface, searchers would value from being able to identify and prioritized these reviews for faster and more trustworthy results. Searchers would also benefit from being able to strengthen future searches by adding their own tags to listed products. Given that that these searchers are primarily technologists, they will also need to know technical requirements and support information. It would serve those comparing various products, to have a consistent matrix across which to compare products – this could include restrictions, departmental support, cost, reliability, popularity.

  • Campus reps
  • Campus contacts
  • Department that use
  • Campus/UC agreements or licensing / idemnification / restrictions
  • How to search specific to a product

Recommender
As questions arise, micronet affiliates could direct people to a specific technology products within the tools and services registry. As questions get frequently asked, it would provide value to have a place to point persons that address these most directly and effectively (FAQ section). If they know of a particular feedback in the discussion archive, it would prove useful to be able to search for that discussion thread and be able to link to it in a response to a request.

Client Services

Application Services

Noise

  • No labels