Minutes of a meeting of Computing Strategy Group, 10am 24th January 2012

Present:

  • Paul Anderson
  • Stuart Anderson
  • Tim Colles
  • Liz Elliott
  • Dave Robertson
  • Alastair Scobie
  • Perdita Stevens

1. Metaissues.

We discussed:

Remit of group: we agreed that CSG has two functions

- oversight: defusing issues that would become bombs if not discussed, kicking along issues that need to increase momentum

- strategy

Some focused issues are best dealt with by task groups that would meet as needed, cf the Web Strategy group. CSG should consider creating such groups.


AP: PS to update remit on CSG page. [DONE]

Frequency of meetings: needs to be frequent enough to permit the first
of the functions to work. After a too-long hiatus, let us aim for
three-monthly, setting the date of the next meeting at the current
meeting. Some meetings can be just one hour long.

Next meeting: 24th April 2012, 10am-11am. Room TBD.

AP: PS to arrange room. [DONE]


Awareness: staff should be made aware that the group exists, that its
minutes are available (which should be made true) and invited to
approach any member of the group if they are aware of something that
should be discussed.

AP: PS to send such a mail (after the web page has been updated as
above). [DONE]

2. Where does what proportion of our effort go?


We discussed the issue of how our available CO and CSO effort is
allocated across areas and types of work, and meta-issues of how that
information can be made clear enough to those of us not in the thick

of it that we can have an intelligent strategic discussion about
it. LE commented that she was glad to see the list of development
projects from the prioritisation meeting, but that most project titles
mean little to most people.

AP: AS to produce a picture giving a high-level abstraction of the
School's computing infra- and super-structure, suitable for using to
help explain what a given project or service is relevant to. (Not to
be an explanation in itself!)

AP: LE to meet with AS, or his delegate, to discuss broad areas into
which projects fell, perhaps with the aid of the picture mentioned
above.

We did have an "aspiration" that 50% of CO effort [i.e., time
available to work, not counting holidays etc.] should be spent on
development. This proved achievable for some units but not all. To aid
planning by matching reality this percentage has been reduced to 40%.

The staff desktop is very "cheap"; the student teaching desktop more
expensive. A lot of our effort goes on support software and
infrastructure, such as the School database, that are relatively
recent inventions. The existence of these enables us to run with much
less manual effort from admin staff than other schools.


AS expressed concern that too much of our effort went on "polishing
the dinosaur": maintaining and enhancing legacy systems. A recurring
concern is the difficulty of withdrawing services which are less used
- we don't always know which things are less used, and even relatively
little used things are often relied on by someone.

3. Attitude to outsourcing services to IS


For some years we have had a policy of migrating from services we run
to equivalent IS services wherever possible. However, three recent
examples of our doing this have hurt us:

1) Mail: we put a lot of effort into migrating to the IS-run mail
service. Relatively shortly afterwards, the proposal to outsource mail
to Microsoft, to our great detriment, arose. Lesson: outsourcing
exposes us to risk that the provided service changes.

2) Subversion: ours is integrated via roles mechanism to school DB, so
it is easy e.g. to produce an SVN respository for a particular
tutorial group. We didn't fully appreciate the implications of this
when we decided to move over to the IS SVN service. Losing that
integration caused problems with e.g. groups of students needing
access to an SVN server for coursework. Another problem was that,
after we had decided to switch, it transpired that IS would impose a
quota on the size of an SVN repository, with a monetary cost to users
requiring more. Lesson: the devil is in the details, including the
cost model details.

3) Mailing list service. IS did a requirements capture, and we asked
for scripted creation of mailing lists from a data source. They
implemented a service that had no programmatic means of creating
lists. Lesson: as (2).

Fundamental problem: when we outsource to IS we lose control but we do
not lose responsibility to our users. Naturally enough IS adopt an
80:20 rule, but our requirements seem to have a tendency to be in the
20 (unsurprisingly, since we are often replacing an existing service,
not getting something new). We have perhaps tended to be willing to
migrate "easy, simple" things which were not costing us much effort
anyway - this gives us risk with little benefit.

Nothing else is under active consideration for outsourcing right
now. We should continue to consider outsourcing when opportunities
arise, but we should be very careful about the details, and not
feel obliged to migrate if the cost/benefit calculation does not work
in our favour. We should be more prepared to put in effort to
investigate migrating large things than small things, since the
investigation itself costs.

4. VLEs.


Current situation: the University is providing Learn 9 for use from
September. Moodle is being used for distance learning courses, and may
be made available for general use later.

SOA remarked that have two different VLEs supported by IS would be an
unstable situation, and that Moodle, while currently popular, may not
be a good long-term solution.

We could run our own Moodle; putting up an experimental one is easy,
but integrating it fully with e.g. the DB is potentially hard. PS was
concerned that there is a danger that we devote a lot of effort to
developing/configuring a VLE solution for requirements that are not
really very different from those of the rest of the university.

Open Courseware is a different, but related, thing. A possible driver
for this is distance students, but we do not have spare capacity and
it is probably best to spend what we have on face-to-face
students. Rather, for us, Open Courseware is interesting as a
recruitment tool.

Student personal portfolios, and personal learning environments, may
become increasingly important. However, different students, and
different staff members, are likely to have different reactions to
these: there is a danger of moving towards something that enthusiasts
like if there is no good default setting that provides something at
least as good as what we have now for no more trouble.

SOA has some funding for investigation of Pebblepad etc.

It is important that this be coordinated properly with our business
needs.

AP: SOA? to ask Gill to convene a task group to discuss strategic
business-relevant directions in student portfolios and personal
learning environments. (This will not be possible before May because
of Gill's other commitments, but that's OK.)

5. Data, data protection.


The recent mobile data survey presented at CCPAG/CCITC revealed that
we may be at risk via e.g. people accessing medium or high risk data
on inadequately protected smartphones. There are simple measures that
staff could and should take to protect such data, such as password
protecting devices and encrypting laptop disks.


AP: PS to draft an email for Dave to send to staff and circulate it
round compstrat for comment.[DONE]

6. Goals for the future


Two aspects:

- goals for 2012 to go in the next instantiation of the (living
document) Plan.

AP: AS to draft these and discuss with PS: this part of the Plan needs
to be updated in the next few weeks. [DONE]

The document, whatever version there is then, to be brought to the next CSG meeting where additions and changes could be made if necessary, but that meeting should mostly focus on:

- goals for 2013 (and onwards).

There is an issue about how to see the wood for the trees in the plan
document: for the immediately coming year, we tend to have a large
number of goals, not categorised, without information on the
provenance of the goal. It might help to have standard slots per goal
to help mental categorisation, e.g.:

Who: [word describing why the goal is in the document, i.e. which
group or individual can champion the goal, justifying its resources]

Area: [word describing what part of the computing systems architecture
it applies to, if applicable].

Cost: [very rough idea of how much we expect it to cost to achieve the
goal]

We do not want to get bureaucratic, however, and it should be fine to
put Misc. or leave blank if there is no natural answer to the question
"where did this goal come from?" or "what does it apply to?", or if it
is impossible to produce even a better-than-nothing guess at the cost.

One thing that is coming up is the possible use of Theon by other
schools, run by IS. It is obviously in our interests if this useful
thing developed here is used more widely. It is not clear, however,
whether the development effort that would undoubtedly be needed for it
to be deployed elsewhere would come from: we cannot provide it.

-- PerditaStevens - 31 Jan 2012

Topic revision: r2 - 01 Feb 2012 - 14:03:32 - PerditaStevens
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies