Relevant Gartner Research:

Service Porfolio vs Service Catalog know_the_difference_between__130882.pdf

Best Practices for Service Catalogs in Higher Education best_practices_in_pragmatic__206868.pdf

Designing Customer Focused Service Portfolios designing_customerfocused_se_103990.pdf

Service delivery release effort overview

We are trying to solve the following issues/pain points:

• no process for expanding or retracting our service offerings and communicating that both internally and externally
• no process for identifying various product and service owners and defining roles/responsibilities
• no central repository for information on components of a service and details of a product
• no central repository for escalation paths by service

We want to create a tool by which to accomplish these things - a database to store and update this data and an interface that allows access.

As part of our discovery process, we have identified existing sources of data (SWRT Product List, IS&T Software Portfolio, IS&T Products&Services List 2008) that are currently isolated and not accessible to many.  The goal is to synthesize this into one repository (a super set of data) that could feed other efforts, such as the IS&T Service Catalog and the Software Download Page (Software Grid).

We would like to review (briefly) the data model that we have created with the help of the Data Management Team IS&T Service Portfolio Conceptual Model

• illustrates what we would like to track
• shows the bits and pieces involved
• illustrated the "moving parts"
• shows relationships between the data points
• PRODUCT is at the center

We have not made any formal business case, but see this as a next step.

No technology decisions have been made.

No project team has been formalized.

We want to discuss how this effort can converge and support the Service Catalog project, and how to coordinate these efforts.

Discussion:

SE effort around the IS&T Website is two fold:

1. rebrand the website
2. redefine the Service Catalog

There is agreement that the Portfolio (as the robust data source) could easily drive the Catalog (web presentation of a subset of this data), thus alignment is key.  We should all be using the same language, in the Portfolio, the Catalog, the Ticketing Tool and Hermes.

In more simple terms, the Portfolio is the backend, the website is one front end.

The website has significant time constraints, and needs to be completed by June 30th, 2011.  This will be an issue in terms of synchronizing and development that takes place.

Agreed on next steps:

• cross pollinate at the conceptual model level and move in parallel
• develop a data dictionary (Portfolio and Catalog together)
• collect the data (Portfolio and Catalog together)
• define layers of website (Catalog)
• define model and repository for procurement thru release processes (Portfolio)
• integration and reconciliation (Portfolio and Catalog together)