- Minimizing data silos: identify data sources and their role
- Minimizing duplication: discuss how to share duplicate data
- Identify obstacles to adoption / minimize riskks
Data Sources and Proposed Mapping
Based on previous discussions on the various existing data sources related to services and Karen Kato's suggestions on how data should be referenced across data stores, I created the above table. Items in red are assumed topics of discussion.
Kinds of Information related to a service
IST Web Site(s)
External facing provider site
IST Administration data
Strawman proposal of using identical data
Does this make sense
Web Presence Needs
Part of the business case discusses integrating "data from disparate venues." In an effort to do this, the advisory group needed to document what kinds of web venues are currently being used, identify the data elements that have a place in the TSR, how the data might migrate, and identify any orphaned data. In analyzing this we identified three and (potentially four) user facing web presences that we would need to account for: IS&T Services Catalog, IST web site(s), TSR, and, if the TSR is fully community sourced, user facing web sites that are viewable but not editable that display issues, bug reporting, etc. related to services. It was assumed that private sites addressing internal team communication and documentation would have its own space as well. The advisory group agreed that these four web presences adequately reflected the needs of service providers to express themselves and for consumers to find information.
What Goes Where
The Advisory Group then discussed the location of the proposed data. Given input from the sponsor that the IST that he wishes to 1) streamline the IST web site(s), and 2) maintain the IST service catalog, general agreement was held that the proposed data belonged where they are shown in the above table with the following exceptions:
- It was unclear whether we should pursue "How can I do X" within the purview of these web sites. FAQs and and knowledge base info would be available and searchable but that is different than tackling the problem of solving a specific user problem with an direct answer.
- The pre-sales product decision support will have two flavors: 1) those related to any related product and 2) those related to IST-related products. For example, the database team has a self-selection document differentiating the databases provided by IST as opposed to all the databases that exist. It was determined that the information needs to be available to both the services catalog ad the TSR and that one will feed the other. It was not determined whether the pre-sales decision support data should be part of an individual service description node or have its own node.
- As we discussed items on the telephone services web site(s), we identified a long list of hardware items which could be purchased. These are referenced under the Service Catalog entry "Details." The location of these items was not agreed upon as the site was not fully accessible at the time of analysis. It will be researched and discussed at the next meeting.
What Feeds What
Given that identical data will reside in multiple venues, we needed to identify the venue in which data would be stored and the venues that would receive dynamic updated data. Susan Tobes prepared and presented a strawman proposal for these data. After discussion it became clear that how we source the data is contingent on whether the TSR is fully community sourced or partially community sourced.
The advisory group agreed that if the definitional data around a service is restricted to a service provider team, then it could reside in either venue; the TAm preferred that it reside in the Service Catalog. However, if the TSR was fully community sourced, then the definitional data should reside in the TSR as it will be the place contributors have access to make changes.
As we discussed the streamlining of the IST web presence to mostly administrative data, representatives from the TAM expressed objection to this. They posited that a key function of the IST web presence was to provide branding and identity of not only individual IST services but also the entire collection of services provided by IST. They did not see how the branding and identity functions of the web site could be protected in this model.
With limited time, we walked through the identified risks-to-date and how to evaluate them. We walked through a few od the listed risks and discussed how to rank them. It was important to highlight that the risks ere to be ranked given the following caveats:
- assume that the TSR is fully community sourced by students, staff, and faculty
- assume immediate notifications would be sent to service providers given change to definitional data
- assume page versioning was in place and that a service provider would ability to apply a rollback of former pages
I want to note that Russ McBride from the Service Desk team did a strong write up of the potential risks associated with transferring knowledge base data to the TSR. This week we will ask the rest of the advisory team to identify risks associated with this process.
Harold Pakulat aptly noted that community sourcing is a new model to most us and that we are making guesses as to the potential probability and impact of these risks. In response to this I have asked for documentation and formal academic papers from Gartner, Dr. Wagner (EECS researcher in network trafficking) and Dr. Cheshire (School of Information researcher on trust networks in computer-mediated communications) . This documentation should help ground our guesses.
At present, the strong majority of the advisory group are concerned that community sourcing the definitional data of IST services will bring a negative impact and potential create an image that the data is unreliable. As we continue this discusion of risks in our next meeting. Throughout discussion, the most consistently raised worry was around students. A possible option to mitigate this risk is to restrict the editing rights of just the students.