Page tree
Skip to end of metadata
Go to start of metadata
Table of Contents

Advisory Group Mandate

As sponsor of the Berkeley Tools and Services Registry (TSR), Michael Mundrane formed an advisory group to define the initial scope and functional capacity of the TSR project given its business case. Further, given that the TSR was to become the primary means of exposing IST service information to the campus, it was important to identify what data elements would be required and how migration of this data would impact other tools.


Business Case
IST has a number of disparate venues where we provide information of varying quality and with differing durability. Our community is looking to both consume information that might be provided by IST as well as to contribute to its formation and assessment. We believe that a framework that can house technology information in a lightly structured way, will facilitate both a greater quantity of information that will be both more complete and will be more resonant with our community. To contribute to the partnership aspect of IST's relationship with campus, we want information that we produce to have their input and we would welcome the creation of content from them as well.
-Michael Mundrane, 17 Dec 2010



Participants

The advisory group was represented by IST service providers, Technical Account Managers from IST-Client Services, Knowledge Base service providers, Security and Policy consultants, and the TSR project management team. The services represented included those that were offered as business-to-business services (B2B) and business-to-consumer services (B2C). Further, the services represented multiple types of services: commodity services 1 and web-based services.1,2

Participant

Role

Unit

Service Name

Service Model

Service Type

Mike Blasingame

Service provider

Infrastructure Services

Virtual Private Servers

B2B

Commodity

Karen Eft

Policy consultant

Security and Policy

 

 

 

Ian Crew

Project Team

Data Services

 

 

 

Karen Kato

Service provider

Database Services

Database services

B2B

Commodity

Russ McBride

Knowledge base provider

Service Desk

 

 

 

Rich Meyer

Project Manager

Data Services

 

 

 

Michael Mundrane

Sponsor

IST

 

 

 

Gladys Oddone

Service provider

Infrastructure Services

Telephony services

B2B and B2C

Commodity

Ronnie Ong

Service catalog provider and customer consultant

TAM-Client Services

 

 

 

Harold Pakulat

Knowledge base provider

Service Desk

 

 

 

Tony Roybal

Knowledge base provider

Service Desk

 

 

 

Jovie Soliman

Service provider

Infrastructure Services

Telephony services

B2B and B2C

Commodity

Susan Tobes

Service catalog provider and customer consultant

TAM-Client Services

 

 

 



Context

The sponsor communicated assumptions and guiding principles which framed the discussion and impacted recommendations.

Assumptions

  • Contributing to the TSR will require CalNet authentication
  • The TSR will be completely community sourced; i.e. any authenticated campus-affiliate may edit any data except individual reviews and ratings data.
  • The TSR will have versioning with immediate rollback capability
  • Notifications will be set up to inform service providers of any definitional data^3^ changes related to their service.
  • The IST web presence will be streamlined for primarily administrative and organizational purposes. The TSR will serve as the primary means of communicating
    IST service offerings to the campus.


Guiding Principles

  • As we design and structure the TSR, we will assume the trustworthiness and goodwill of our constituency.
  • As we design processes and structures, we will assume that simpler is better; we will remove complexity wherever possible.
  • Service providers are expected to represent their own services and service data.


Process

The advisory group met weekly from mid -January to late February with assigned work between meetings. The advisory group

  1. identified core, required data elements necessary to represent an IST commodity and web-based service; professional services have yet to be discussed
  2. identified sources of IST service information
  3. consolidated and organized these data elements into proposed data stores
  4. identified the authoritative source of each data element
  5. between the TSR, the knowledge base and the service catalog, identified where identical data elements would need to source other tools or applications. This sourcing discussion is incomplete; sourcing of data to/from SciQuest, Service Now, and Pinnacle^4^ have not taken place.



Data Elements for an IST Service

Caveats

  1. These data elements reflect required data fields for IST services only. Non-IST services can be contributed to the TSR with a minimal data stub including a name, short description, and URL.
  2. In assessing the required data elements of a discrete IST service, it was noted that certain resource data such as a criteria matrix to help a consumer self-select from a range of similar services will most likely require its own node type.


Required

IST Commodity Services

IST Web-based Services

IST Professional Services

  • Product name
  • Provider name (i.e. IST)
  • Short description (one sentence)
  • Long description (either text or link)
  • Contact Information for
    • questions about the service
    • for support of the service
    • for procurement
  • Restrictions (alternate name: Limits)
  • Pricing (either text or link)
  • Audience
  • Tags
  • SLA (either text or link)
  • Product name
  • Provider name (i.e. IST)
  • Short description (one sentence)
  • Long description (either text or link)
  • Contact Information for
    • questions about the service
    • for support of the service
    • for procurement
  • Restrictions (alternate name: Limits)
  • Pricing (either text or link)
  • Audience
  • Tags
  • SLA (either text or link)
  • WSDL/WADL Definitions
  • WSDL/WADL Definition Version
  • Protocol
  • Endpoint documentation
  • Service Instances

TBD


Required, if available

IST Commodity Services

IST Web-based Services

IST Professional Services

  • License
  • License
  • Downloads of test scripts

 



Data Sources of IST Service Data

After identifying the required data elements,  a mock up was created with real service data in order to research where various data elements currently exist and to identify any missing data elements. We migrated data for the Virtual Private Servers service. In assessing the required data elements of the Virtual Private Servers service, it was noted that certain resource data such as a criteria matrix to help a consumer self-select from a range of similar services was not accounted for and most most likely would require its own node type. In assessing the data sources for these data elements, it was noted that the majority of the public data resided either on the IST web presence or a similar public site.(see Virtual Private Server Sources ).



Organizing Data Elements into Consolidated Venues

Given the data sources we found, we then began organizing where these data elements should reside given our desire to consolidate silos and to create a central venue for service discovery and information. Given the assumptions stated by the sponsor, the advisory group identified where each data element should reside, what data would need to migrate, and how various applications or tools might reference each other. We have used shorthand in the table; please see the Glossary for further clarification.


Data Organization Table
This table identifies public web sites that a CalNet-authenticated user could view.  These do not include private web sites used by a service or project team.  

 

IS&T Web Presence

IST Service Catalog

TSR

Public- facing service provider web site

Jive Knowledge Base

Initial Data Elements

IST Organization/Administration data 
Service Catalog link 
TSR link


Service-specific data fed from TSR
Pre-sales product decision fed from TSR  
Alerts or notification fed from TSR
Procurement data and processes  
IST marketing data 
TSR link

Service-specific data
Pre-sales, decision-support data
Opinion data
Service catalog link
Knowledge base link
Alerts or notification data
Non-KB FAQs
News dashboard 
Surveys
Enhancement requests
User Support data

Restricted access data such issues logs or bug reporting
Service Catalog link
TSR link  

Knowledge base articles
TSR link

Future Data Elements


SciQuest Link

Knowledge base articles
New KB articles


 


Formal Objection
While discussing the streamlining of the IST web presence to mostly administrative and organizational data, representatives from the TAM expressed formal 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.


Glossary

  • Definitional data: descriptive data and formal documentation related to a service or product; e.g. name, url, description, audience, version.
  • Opinion data: User submitted reviews, comments and ratings.
  • Support data: User submitted support information; eg. tips and tricks.
  • FAQs: Frequently asked questions produced by the service provider and/or end user. This is intended to be fully editable.
  • Service-specific data: Definitional data specific to a single service.
  • Pre-sales, decision-support data: Decision-making data related to a range of related services; e.g. comparisons and uses cases of all the IST database services.
  • Deterministic support services: An unaddressed data category of potential interest was user-requested support such as "Can I access CalShare with Firefox?"  The need for this kind of support was noted, but its was considered out-of-scope for the TSR.



Project Risks & Mitigation

The project risks documented by the advisory group roughly fall into four categories: community sourcing of definitional data; impact on staff morale with additional work; functional differences and requirements between Wikipedia-style text and the search and browsing needs of a Knowledge Base; and unclear timing and boundaries of potentially related projects. In addition, by migrating data to the TSR along with current editorial and curatorial processes for that data, the TSR will inherit risks of housing significant amounts of stale data. Finally, Gartner Research informed us that the primary cause of failure of social applications was pursuing too large a scope too quickly.

The entire set of project risks associated with the TSR have been documented here.


1. Community sourcing of definitional data

The advisory group saw little to gain and much to lose by providing open editing of definitional data; they were far less concerned regarding community sourcing of the other data.  The two parties of concerns were well-intended campus experts who might ardently publish inaccurate information (Micronet) and students.  Regularly, similar technical discussions refresh themselves on Micronet where technical experts give out inaccurate information regarding an IST service or its capability. Students were seen as having less awareness or concern of impact or consequences based on their misconduct, and were seen as a potential threat for malicious activity.  The probability might be low for this activity, but the impact might require a lot of time to fix a breadth of data.

Sponsor Decision and/or Mitigation
Given the larger vision of increasing partnership between IST and the larger campus-IT community, the sponsor felt it was critical to pursue this new model of community sourcing data around technology. He felt that the probability of campus staff purposely contributing malicious data was extremely low, and that requiring authentication, visibly associating names with contributions, enabling notification of any changes, and version rollback capability was a reasonable means of resolving well-intentioned misinformation.

The sponsor was willing to evaluate whether student contributions should be moderated; but posited that in light of the larger vision of increasing partnership with campus, any staff member should have permissions to approve a student-submitted contribution. The sponsor requests that this advisory group make a recommendation as to whether students should be moderated and a relevant approval policy in accordance with the guiding principles and assumptions.



2. Staff Morale

All service providers in the advisory group viewed there current staffing at full or over capacity.  They posited that staff morale was already low and that increasing staff workload to migrate service data and to monitor notifications of modified definitional data and would depress it further. 

Sponsor Decision and/or Mitigation
The sponsor again noted his perspective that the probability of substantive misinformation was low. Further, he noted that it would provide a resource for service providers to have a known venue to post answers to questions that resurface on a regular basis. The sponsor also agreed to assess how to offer additional staff assistance to these endeavors, potentially through IST/OCIO communications team.



3. Functional Differences between TSR and a Knowledge Base

There are different kinds of functionality and needs built around text-based presentation of information in the wikipedia-style and the rich search, taxonomy and presentation of a knowledge base.  Assuming that both will fit into a single platform seemed risky. Other risk were raised around data quality, and the impact of allowing any user to add articles to the knowledge base without editorial review.

Sponsor Decision and/or Mitigation
The sponsor agreed to postpone immediate integration of the knowledge base and to pursue further analysis to determine the best means integrating both the content and functionality of the knowledge base.



4. Unclear Timing and Boundaries of Potentially Related Projects

The TSR is intended to be the record of source for IST service data. Given this, we want any system referencing an IST service to use relevant data fields from the TSR, we need to identify both the current and upcoming applications that use any of the data elements that we identified in our required fields. To do this, we will need to identify functional owners of each project to discuss how these data elements effect their project and develop decision-making strategies to serve all parties.

Sponsor Decision and/or Mitigation
To enable decision-making around scope, phasing and overall timing, the sponsor understood both the need and value of identifying functional owners of the potentially related projects. He will identify these before April 1, 2011.



5. Inherited Risk: Significant stale data

The current IST web presence, service provider pages and knowledge base are all considered to have a significant amount of stale data.  Migrating this data to the TSR will not eliminate this problem.  If fresh and accurate data is one of the key reasons why people come to the TSR, ensuring fresh and accurate data is critical.  All of these public-facing arenas reference services, but do so in different ways, with different purposes and with different granularities.  Having no gubernatorial unit ensuring the quality of data, upkeep of the data and or integration of these data where services reference each other.

Sponsor Decision and/or Mitigation
The sponsor noted the need to remedy stale data. He communicated the expectation that stale data will need to be culled both from the knowledge base and service data pages before migrating to the TSR. The sponsor also agreed to assess how to offer additional staff assistance to these endeavors, potentially through the IST/OCIO Communications team.



6. Gartner Research: Too Large a Scope at too Quick a Pace

Gartner Research noted that the primary cause of failure among social applications was pursuing too large a scope that was poorly defined. They strongly encouraged to keep our scope small and highly defined; and to move through the development step by step. This strongly suggest starting with a minimal set of features and using agile sprints to increase functionality one piece at a time.

Sponsor Decision & Mitigation
The sponsor agreed with this research and posited that it was reflected is guding principle that "simpler is better." His desire is to start small and add simple functionality in incremental steps.



Proposed Scope

Given the sponsor's mandate, assumptions, and guiding principles; the advisory group's analysis and findings; and sponsor feedback, the advisory group recommends the following scope for the TSR:

  • The TSR will become the central authoritative source for IST service data; and all IST service providers will migrate their non-restricted, public service documentation to the TSR.
  • Outside of individual reviews and ratings, the TSR will be fully editable by any campus staff member; student moderation is still being discussed.
  • The TSR will initially include definitional data, user submitted reviews and ratings, a link to the Service Catalog for procurement and a link to the knowledge base for support data. It will have capacity to house existent non-KB FAQs, a notification system to publish and consume service alerts, and service selection support data.
  • The TSR will include simple, intuitive, user-tested contribution forms, search across free-text and tags, and a basic taxonomy for browsing.
  • The TSR will have staged releases to the community from June to September



Next Steps

  • Advisory Group reviews the Summary Report and provide final feedback, Mar 15
  • Advisory Group recommends whether students should be moderated, Mar 15
  • Sponsor identifies day-to-day functional owner of TSR Mar 15
  • Form next advisory group (for design, prototyping and initial releases), Mar 15
  • Develop milestones and areas of work around community engagement, Mar22
  • Develop a detailed work plan and phasing strategy, Apr 1
  • Select base technology on which to develop the TSR, Apr 1
  • Develop moderation and incentive policies, Apr 1
  • Sponsor identifies day-to-day functional owner of potentially related project, Apr 1
  • Identify roles and high level needs around communications and community engagement, Apr 15
  • Sponsor provides further clarity and timing of other service-related projects, Apr 15
  • Service providers and knowledge base owners begin thinking through data clean up and migration plans, Ongoing



Notes

1. In discussing the various services offered by IS&T, the advisory group identified multiple service types: Professional services such as TAM, Web Applications; Commodity services such as Database services, Virtual Private Servers and Telephone services; and Web-based services such as APIs and documentation for web developers.

2. Although not formally part of the advisory group, the project management team met with Jr Schulden, Director of IST-Application Services to capture the scoping requirements for web-based services. Web-based services fall under the B2B model.

3. Definitional data includes descriptive data and formal documentation related to a service or product; e.g. name, url, description, audience, version.

4. IS&T is currently engaged in multiple enterprise level research and/or implementation investments. Across these investments, products and/or services will be referenced, and display some level of identical data, minimally the name of a product or service. As we define data models and integration points for these discrete projects we need 1) a a functional owner for each project, 2) a common understanding of the intended scope of each project between the functional owners, 3) a common understanding of where source data related to products or services should be stored, 4) how these sources will feed the other projects to minimize redundant data, and 5) the process and responsible party for updates. This image to the right identifies some of the related projects.

  • No labels