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
  • No labels