ITPG Meeting Minutes October 27, 2005

Present: Elise Meyer, Lubomir Bojilov, Deborah Scott, Alan Moses, Jamie Sonsini, Jan Smith, Mark McGilvray, Glenn Schiferl, Jim Woods, Jeffrey Barteet, Jacek Smits, Doug Drury, Arlene Allen, Bill Doering, Matt Dunham, Saturnino Doctor, George Gregg, Randal Ehren, Steve Marks, Kevin Wu, Nathan Rogers.

We listed the known subcommittees of the ITPG, or in the case of GUS, those related to ITPG initiatives:

• BEG – Backbone Engineering Group
• SEC-WG – Security Working Group
• Identity – Identity Management
• NBA – New Business Architecture
• WSG – Web Standards Group
• SLACK – Software Licensing Advisory Committee
• CMS – Course Management System
• DECAF – Distributed Environment Common Application Framework
• GUS Executive Committee

We discussed the formation and purpose of subcommittees:

Subcommittees are usually formed around a specific project or technology that needs broad coordination. There may be a lot of committee effort involved in proposing or defining a service and getting it appropriately funded. In some historical cases, the subcommittee had a major role in implementing the service. Once the service is being provided by an operational unit, the committee may dissolve (assuming the service provider develops an alternative feedback loop.) As the service goes through its lifecycle, gaps may develop, in which case a subcommittee could be formed again to address those gaps. The group that works on the gap may be different from the group that worked on the initial project. In the case of the network, the technology keeps changing rapidly enough that there is no period of just a service. All committees are ad-hoc; some are just permanently ad-hoc.

An IT service should have a feedback loop for its customers. In some cases that feedback loop is part of the relationship between an IT subcommittee and the service provider, in other cases it is a service provider sponsored group. Where the feedback loop is provided by a subcommittee, the subcommittee's relationship with the ITPG allows the ITPG to focus on infrastructure and coordination issues that can occur between services, either campus-wide or others. It can also deal with an intersection of customer needs, e.g., decision on a campus standard web browser. A subcommittee may not be appropriate for all services, e.g., are there campus-wide implications if a customer wants to download their email to their Blackberry.

We discussed the roles and responsibilities of subcommittees tasked to look at a particular area and the operational unit that provides the major service in that area:

A subcommittee or a customer advisory group may recommend something that the service provider may not be able to accommodate due to policy, rule of law, or different priorities for the service provider’s unit or control point.

Subcommittees provide advice; they do not have real authority. For example, Software Depot may ask SLACK to prioritize features and functionalities for the new service and Software Depot may choose to implement those recommendations, or they may determine that something else must be implemented first.

If there is a sustained conflict between the recommendations of the subcommittee and the actions of the service provider, then the issue can be brought to the ITPG.

The network area is an example that might be applied to all of the subcommittees. The BEG (Backbone Engineering Group) is the subcommittee charged with focusing on networking issues. The OIT is a major provider of networking service with the backbone network and the connection to offcampus networks, but there are multiple others who provide network services for their units. The BEG provides tactical advice to the OIT, and there is two-way communications between the BEG and the OIT. The BEG provides advice to the ITPG and provides the focus for the gaps in networking services. The ITPG provides strategic advice to the OIT, and there is be two-way communication between the ITPG and the OIT.

We discussed ITPG's role in the context of the subcommittees and the other Planning Groups:

ITPG is responsible for gaps, architecture, infrastructure, and commons. It can address intersections and coordination between services. When it becomes a funding question, then prioritization must become part of the process and that is the sort of function that should happen at the ITPG/ATPG/EISPG level. ITPG has both a strategic and tactical role.

We developed a model along the lines of the 7-layer OSI model to describe the current relationships:

ITPG covers all 7 layers, but it also covers the infrastructure layers for the ATPG and EISPG. The ATPG and EISPG only operate at the top layers. There are subcommittees that operate in both ITPG and ATPG/EISPG space, e.g., CMS and NBA. Most of the others operate in ITPG lower layers. Portals as a technology might be embraced by multiple committees/projects, but not portals as a service.

The group also discussed the Web Standards Group, which is a subcommittee of the NBA. This group consists of webmasters and one of their discussions was how to implement the existing campus policy of using a pop-up window to announce that a web surfer was leaving UCSB webspace. It was recommeneded that they become a direct subcommittee of the ITPG.

There was a question about how subcommittee chairs are chosen. In some cases, the champion of the service is the most directly affected party and they chair the subcommittee. In other cases, whomever is willing to volunteer becomes the subcommittee chair. In the case of WSG the chair was elected. There may be some benefit to not having the service provider chair the subcommittee charged with looking at the service. This provides independence for the subcommittee, although it is essential that the service provider be present to advise on the operational realities.

The group would like to develop "Rules of Engagement" for the subcommittees. These rules would address the areas of:

• Reporting
• Leadership – Selection and term of subcommittee chairs
• Notes/minutes – Timeliness and distribution
• Membership – Appointed representatives, voluntary participation, or other?
• Voting Structure/Decision Process – Does each member or represented unit get a say? It was also noted that voting is somewhat impractical due to the fundamentally advisory role of any group and the operational constraints of the service provider within the UCSB organizational context.

The tasks to be done prior to our next meeting on Monday, November 21, are:

1. Each subcommittee should send the following information to Elise:
   • Name of subcommittee
   • Schedule of meetings
   • Chair
   • Service provider
   • Scope
   • Members
   • Meetings or reporting
   • Charge
   • Website
2. All ITPG members can propose subcommittee Rules of Engagement to the list.