Work Organization

Our goal is to better organize our work for its presentation and planning.

We currently have an overwhelmingly large collection of detail. That's handy when we need details, however it's not very useful for presentation or planning.

Our work data seems fundamental to the problem. We want a useful characterization that isn't overwhelming, and that can be used for presentation and planning of our work. We need categories of work that our clients (especially upper CS management) can relate to.

The categories can't be so numerous as to be overwhelming, while at the same time they can't be so few that the category contents are overwhelming in size. A simple example of the problem is the current "Activity" field. It has a handful of values, and thus is easy to comprehend. However as a result of so few values, each category is overwhelmingly large.

Planning includes the assignment of both money (budgeting) and people's time, and hence requires categories with sufficient detail. Presentation requires starting with simple summaries, with optional detail a possibility.

Thus, we need to be able to reason about both specific categories, and groups of categories. One way to group is via a hierarchical naming system, e.g

  Service
    Student Computing Environment
      Graphics Lab

There are likely multiple ways to categorize our work. We must choose the approach that most closely meets the above requirements.

Services

Given that we are a service group/facility, it seems natural to describe our work in terms of the services that are being supported.

To start then, we need to determine the set of "services".

A CSCF "statement of purpose" could be taken to be:

CSCF exists to facilitate the mission of the Cheriton School of Computer Science through the provision and support of computing technology.

It's the case that we support most of the technology we provide, and provide most of the technology we support. Exceptions likely exist only for research support.

So that suggests the possibility of starting with our major computing environments (student.cs and core.cs), and adding to that.

http://www.cs.uwaterloo.ca/cscf/internal/rtDoc/fields/service

is a starting point, used to provide sufficient data to aid in understanding the problem. It can be replaced as we learn more.

Determining the right set (of services) will likely involve asking CS management for a judgement, as well as polling our clients.

Components

Categorizing our work in terms of the services being supported is only a partial solution. We have a lot of work that's not specific to any one service; i.e. infrastructure. So we need a useful characterization of that work as well. We can choose these categories without reference to our clients; they are intended to be the internal implementation details of the provided services.

They should be generic categories of computing infrastructure support. As a starting point, we have

http://www.cs.uwaterloo.ca/cscf/internal/rtDoc/fields/component

As with the service list, it was only used to provide data to experiment with. It can be replaced. E.g. It's possible that there are too many categories.

The name of the category currently chosen is "Components". An alternative that has been considered is "Building Blocks", as the current description of the category is

the building blocks of the services, typically a specific technology that happens to be involved in the work; a typical service involves multiple components.

which is the observation that categories suitable for describing infrastructure activities can be just as suitable for the support of a specific service. Another possibility is "Implementation Details". The name Components was chosen over Building Blocks because it's a single word.

The Debate

We are just beginning to debate what a suitable set of Services and Components ought to be (if not the above). There are multiple ways of defining our services, and hence divergent views. And there is a long list of unanswered questions based upon examination of live data. It's not yet included here.

The Name "Services"

The term "services" turns out to be quite value-laden for some, expected by some to reflect general technologies. We could call this "client expectations" instead. However a single word is handier than two.

Function vs Environment

A fundamental debate is whether services for all computing support organizations are essentially the same, e.g. provision of mail, www, file storage, ... The above proposal is specific to each constituency, with the Components being common to all technical activities.

Services vs Components

Clients often identify a service with a specific technology (and hence service component) because there is often a single technology that dominates. E.g. the "Mac Labs". Thus we can expect significant duplication with service names. However a specific service usually has multiple components. E.g. the "Mac Labs" involve Mac hardware, MacOS, multiple directory services, additional software, networking, and classroom infrastructure.

Research Support

One of the questions with the above approach is whether there should be standard functional subcategories for the "specialized computing environments" (a service proposed in the above), or whether distinguishing by subscription code is adequate. Or both, or ...

Analogies

The list of "services" is like a menu in a restaurant, it's what the clients choose between, and the "components" are what goes on in the kitchen to produce the food listed on the menu.

In general, every restaurant has a different menu, to appeal to their particular client base. For that matter, a given restaurant will change its menu to account for changes in their clients tastes over time. People have no trouble recognizing a restaurant for what it is, because the menu is all about food. They don't really care about how it was made, as long as it meets their culinary needs (e.g. tasty and clean). Different restaurants will tend to employ similar technologies to produce the food, although even there, there can be differences; convection ovens, microwaves, gas ovens, open pit barbecues ...