Current Sprint: Ends roughly end of January.
In brief, our current short-term goals:

• Populate entire "family tree" of Family, Service, Offering data.
• Through this activity, generate feedback on the workflow, fields in the content types, and links between the content types.
• Still no quorum on level of depth and detail. Populate low-level "configuration items" data to generate experiential feedback.
• The portfolio "through time" concept requires we look where content types need "retired" or "in the pipeline" values.
• Lightweight content type to track hardware/platform information for server-based offerings (enterprise systems). This will not be the configuration-mgmt database, though.
• New Views, design pass 1: Incoming Services, Retired Services, Distributed Software (excluding licensed for hosting services only), Service Offerings with the configuration items and assets.
• Refine user roles.

Current Activity for Review
Team, please review the following details.

• Vendors should link to which content types? Service Offerings, specific Asset types, and/or Software Content types?
• Link mapping looks like this, is it correct, or should higher level services be able to link to a specific CI Software Version:
  • Service Offering > CI Software > CI Software Version
  • Service Offering > Server Platform(s) > CI Software > CI Software Version
• Review "Server Platform(s)" configuration item.

Final Approval
Features have been through several iterations already, in need of a "yay" vote or polishing off.

• Assets (Finance, License, Support Agreements): Removed from direct relationship to Services. Can be linked to all Service Offerings and all Configuration Items (CI Software, Software Version, Hardware/Platform). Is this correct?

Needs a Meeting
Or a standup, or a working session, or really thorough comments. You get it.

• Roles and Permissions: Recent team discussions about IT Support role vs. Portfolio Coordinator role. "Preserve the Family Tree," Gresham circa 2011. IT Support role more constrained but we need a careful review.
• Required or not required fields, review of all "select fields." Should not do this until we feel the fields/data design is baked through.
  Future Features
  Features for which we need a real developer and a real design process.
• How to tie together "service family tree" into taxonomy, menus, and breadcrumbs that do not require data re-entry; base requirement is how to help the end user know what type of content type they are viewing since the "family tree" concept is crucial.
• Wizard interfaces for adding support materials (assets, configuration items) to correct components. Select lists are likely to get very long and we need a better UI.
• WYSIWYG text editor. Consulted with web services team. Best not to deal with this in "prototype" mode. They are a configuration pain. Ruled out Wiki Markup since Drupal does not normalize how it stores content.
• Port data dictionary from ISTPROCESS wiki. On hold pending implementation of WYSIWYG editor.

Shared Fields
This are fields shared between content types on purpose; possibly for reporting purposes or just for sensible data design. The example is intended only to be illustrative in hopes the developers get the idea and we can work a real reporting requirement out of it.

• field_vendorlink: To reference a Vendor from another content type.
• field_servpacks: To reference Service Level Assets from another content type.
• field_legalbundles: To reference License Assets from another content type.
• field_finbundles: To reference Financial Assets from another content type.
• field_financeowner: To reference Financial Owner from another content type.
• field_bizown: To reference Business Owners from another content type.
• field_ci_coordinator: To attach a "coordinator" to any of the many CI (configuration Item) content types.

Additional Notes From Portfolio Working Session

• look into plug ins to export views to excel
• look at "who fixes what" data set in Hermes: Who Fixes What
• Steve will try to port Data Dictionary into prototype: IS&T Service Portfolio Data Dictionary (Glossary of Terms)
• Dave will port CI Software and CI Software Versions into prototype
• possible "content manager role" to be created
• new views:
  • service offerings with links to configuration items (assets, software and dependencies)
  • restricted versus distributed software
  • retired service offerings
  • incoming service offerings (pipeline)
• CI Software Version
  • audience
  • support level
  • phase of the lifecycle
• additional service offering fields
  • OS
  • physical vs virtual
  • web app vs database
  • business description as hyperlink to IS&T Website
  • url to product page or web address
• create the various vendors under vendor content types

Homework

Updated version of the Service/Service Offerings list will be sent out by 12/22.  From that, the team has divided up the service families for data entry into the prototype by 1/12 (at minimum services and services offerings in each family, and any information further down the tree that you can input.)

• Communications: Pat
• Identity Management: Garry
• Security Services: Oliver
• Data Management: Pat
• Administrative Services: Chris
• Academic Services: Oliver
• Connectivity/Network: Pat
• Productivity: Dave
• Operational Services: Garry
• Software Development: Dave
• Support Services: Chris