matcarr

Leaving home at around 7am this morning, I noticed a pale disk in the clouds looming above the trees surrounding Shaw Rd where it meets Scenic Drive.

IT Projects at the edge: a view from the centre

A presentation for the inaugural internal IT conference at the University of Auckland in November 2008.

Centre and edge. The spatial tension within an organisation where the centre shifts depending on context. The University is a collaboration of centres. The term centre is often used to describe areas that are actually peripheral to the core activities of the institution.

The German Pavilion in Barcelona (originally built in 1929 by Mies van der Rohe as Germany’s presence at the Barcelona Exposition) is a precision engineered construction with shifting centres. Layers and vistas slide around as you move through this building. “Structure” and “ornament” appear to merge, though this is an illusion, but something the subject willingly indulges. The horizontal spatial flow of the building contrasts with the static almost tomblike treatment of the vertical surfaces.

The pavilion resembles modern server rooms in many ways. But server rooms tend to emphasise the differing roles of their constituent objects.

There are parallels between these spaces and the University’s thinking about IT.

The contrast and similarity can be seen as analogous to the double edged issue relating to the tension between the perception of centre and edge.

 

Lost projects. Things we started and let go of, or that have become institutionalised in a way that discourages play… Lost projects are an artefact of an imperative to a mode of centralisation, where the support/service unit considers itself central and the activity/actors are peripheral or purely consumers.

 

These examples were deployed as constructive facilitating possibilities in ad hoc contexts, and have been subsumed into “central” service catalogues, that start defining boundaries to the possibilities. There seems to be a trend to codify innovation. The domain-range of the technologies involved shrinks through this codification. The users are seen almost as ornamental on the structural technological achievement.

 

A specific detailed example includes a lost opportunity to explore a mode of technology delivery that is considered normal in many places outside of this institution. Everything was lined up, including deep planning and policy, but “central” agencies rejected the proposal for financial criteria that were really out of scope for the project.

 

So, we indulge in projects at the “edge” to deal with the central “business” of the institution, supporting the teaching and learning activities of the academic staff and the students. These projects are managed with in the centres demanding the specific services, complementing and supplementing central provisioning, and in some cases filling gaps left behind in planning that does not look much deeper than 5 figures. The projects tend to be rapid deployments with ongoing development and tweaking, responding quickly and flexibly to the immediate feedback provided by users.

 

The NICAI Xsan. Built as a solution to growing demand for capacity in the areas of student activity. Large collections of various media types congeal around student users, and the demand is not satisfied by many of the immediately available solutions. The XSAN was seen more as a means of supporting the teaching requirements, than as a general storage solutions for students, but the differentiation of such use is not wrapped in any policy that can be used to develop a technical solution. So we needed something that could grow rapidly as required.

 

The XSAN began life as a dream of a storage area network servicing some of the high demand areas of the faculty.

 

NICAI storage network

 

NICAI storage network (post upgrade)

 

…

 

The XSAN at September 2008

 

The NICAI staff research collection toolkit. A mechanism for capturing current and significant past research activity for public exposure through the NICAI web site. Initially it was thought that such information could be syndicated through the University’s “central” research management tool, but this never eventuated. In 2008 access to the information collected for PBRF administration is still not available in a form that makes it easy to publish via the various web interfaces available.

 

A similar project as done in 2005. This original system and the feedback gained from staff during the “build phase” of this earlier project informed the development of the new project.

http://itadmin.creative.auckland.ac.nz/projects/research/
project notes: http://itadmin.creative.auckland.ac.nz/faq/software/ResearchCollector/project/

 

The material collected through the old tool, was published via a public interface that essentially drew the information “live” from the database in which it was stored.

 

The new tool was constructed through September-October. It was given a nice interface with plenty of safety rails, warning bells, etc. The granularity of the information collected was made a lot finer than this tool’s predecessor. Advice was sought from various groups, but the time available for feedback was fairly limited (due to the project delivery requirements) and development was done with little input from the relevant experts. After its “release” changes were made on the fly based on suggestions from users.

http://faculty.creative.auckland.ac.nz/internal/research/ The tool itself is a modular collection of php documents that manipulate information stored in an MS SQL based database. The tool “interacts” information from various databases. Ideally, it would be able to leverage data housed in “central” repositories, but access to such things would have ramped up the project in a way that would have required an unplanned (non-existent) budget, months of planning and endless constraints. Unfortunately this tends to be a repeated pattern for projects like this -an essentially straightforward requirement gets lost in the maintenance and operation aspects of the central provider.

 

The tool subjects material entered into it to a workflow geared for the communications and marketing team (CMT) with in NICAI. CMT check the document for essential style compliance. The mechanism I used in building the researcher and editor interfaces allows the possibility of a peer review stage in the publication . Once published, the data can be consumed via some simple web services.

There are two basic modes of presentation: staff lists, and staff profiles. Lists are a collection of staff and roles organised by role or sorted by name. The items listed are generally grouped by academic/centre affiliation, but can be the result of arbitrary keyword searches. Profiles are an individual summary of published research outputs. http://research.creative.auckland.ac.nz/common/library/research/ demonstrates the use of an xhtml export mode for lists and profiles.

 

The information collected in the tool was intended for use in the new University cms built on the Jahia platform. I saw the primary means of exporting data as being xml. The default output of the web service is an xml structure. Either a listing or a profile. The data contains the information needed to put together something like the previous demonstration, and so I built xsl transformations by way of a demonstration.

 

And to prove it can work in a hosted non-connected web environment I developed a simple demonstration in the cfml based shado cms which was still the primary content management mechanism for the University while this project was underway.

(@2010, see http://www.creative.auckland.ac.nz/uoa/home/about/research/)

 

 

vrooooooommmmm!!!

Auckland <-> Nelson: $209
Auckland <-> Christchurch $239
(includes return flight, excludes accommodation and local transport)

158 more video events to go.

What about, Auckland<->Frankfurt…

James Harton What do you call it when a project is too rickety to be in production? Business as usual. Gah!

A whimsical decision that began life as a glint in the glossy brochure and disguised as a consultative framework, beats its competitors into submission through doublespeak wrapped sabot munitions packing bunker busting policy rounds.

Logistical planning conducted covertly in the airtight bunkers of the surviving players favours tried and true trench warfare techniques for strategic advancement.

Shock and awe through the focussed deployment of massed superior technology overwhelms the opposing forces with the dead weight of the acceptable collateral damage riding the wave…

Customer cannot see stuff they would normally expect to see due to reduced photon density in the visible EM spectrum.

head count: 1

After making several attempts to reboot the device tasked with maintaining a suitable level of photon density and verifying that other such devices in their environment appear to be performing at or in excess of the level agreed within the SLA, this person will probably attempt to contact the service desk (SD).

The resulting “customer in the dark” incident would be the normal entry point into the system. In modern environments, this initial contact would probably be handled through an automated agent.

A review of pertinent SACM derived metrics and a search for related incidents will determine whether localised restoration processes need to be pursued.

Assuming the issue cannot be accounted for with respect to current service status, the service history of and any current status information for the specific CI involved (the lightbulb) will be reviewed.

If the lightbulb is a known variant of a baseline, the usual work arounds will be tested. Current fixes for this incident type held in the KEDB (eg. “have you tried restarting it?”, “is it plugged in”) will be tried.

Given the nature of the CI (electrical), this work will probably carried out by an authorised representative of the technical operations group (TOG).

head count: 2

Should these quick fixes fail, it is assumed that a new CI will be required. The incident will raise a service request activating a standard change. This templated request fulfillment process avoids the need to delay till the next CAB meeting, or to form an ECAB. This saves quite a few heads.

NB.

If the lightbulb is a specialised CI then there may be a need for the activation of external “assets”, which would require appropriate authorisation from a suitable customer representative as per the SLA.
The potential path of the process involved in replacing specialist facilities deviates too far from the standard to be usefully documented here.

So, following the standard change process, release authorisation(s) for the transfer of a new, or appropriately functional “old” CI from the pool will be forwarded to Inventory Management (a derived function involving collaboration between finance and facilities management functions).

If no CIs are available immediately an acquisition process will be invoked.

Financial management processes around asset transfer will be invoked whatever happens -these may be purely logging activities depending on the tier of SLA for light provision within the corporate agreement for services associated with particular CI.

While this step could be automated, it would be wise to ensure some human oversight on any financial/inventory activity -especially where CIs are being transferred.

head count: 3

To ensure that an appropriate value is delivered to the customer, testing of the CI would be normal -a suitably qualified Quality Management (QM) specialist may need to sign off on fitness for purpose. Assuming good practice, a further head will be counted.

head count: 4

While it is possible to do specific user acceptance testing (UAT) at this point, it is normally acceptable to have done testing of the class of CI depending on the quality of the goods supplied.

An engineer (qualified in Photon Density Improvement Management -PDIM) will be dispatched to the location of the (assumed) faulty CI. This person may have custodianship of the new CI, or may contract to meet with an authorised lightbulb transportation agent (ATA, probably the same head counted above).

head count: 5

In all likelihood the customer has probably vacated the affected location so a request may need to be made to Access Management (AM) to authorise an extraordinary penetration warrant (PWEx). Such things may be part of the standard change, but it is prudent to ensure that verification is possible through the cross referenced activities of agents.

head count: 6

If the location is adversely photon deficient it may be necessary to second a temporary localised PDIM agent (PDIMA temp). The customer (if present) or AM agent may be suitable candidates.

Somewhere around here the original CI is removed, and all going well the new CI is placed into the live environment.

Localised release and deployment processes may need to invoked. These could be greatly accelerated if the customer is present. AM and PDIMA temp agents are not qualified to sign off for quality measures, and are certainly not able to certify quantitive measures.

To ensure SLA compliance of the new CI a QM agent will need to conduct a utility examination. A customer agent may need to be involved as well.

head count: 7

Post-screwing-in activities may include disposal (transfer of the CI to a non-definitive collection), root cause analysis, supply management review, etc.

Of course, none of these bodies need to be ITIL trained, but it would probably help.

ridiculous…

eval
{
	$incidentid = ars_CreateEntry($ctrl, $schema,
		"2",		"SIT ARS engine",
		"7",		"1",
		"8",		"Testing",
		"200000003",  "Application",
		"200000004",  "Remedy",
		"301290300",  "0",
		"900000000",  "unkn098",
		"1000000000", "Testing",
		"1000000001", "The University of Auckland",
		"1000000010", "Faculty of Science",
		"1000000014", "IT Support",
		"1000000018", "User",
		"1000000019", "Unknown",
		"1000000020", "",
		"1000000022", "7000",
		"1000000026", "1",
		"1000000027", "1",
		"1000000030", "###",
		"1000000048", "",
		"1000000054", "",
		"1000000056", "###",
		"1000000063", "Application Delivery Services",
		"1000000064", "Application Support & Maintenance Service",
		"1000000079", "SGP000000000103",
		"1000000080", "PPL000000009561",
		"1000000082", "The University of Auckland",
		"1000000099", "0",
		"1000000151", "Heaps of stuff could end up in this part of the call",
		"1000000161", "$newincidentid",
		"1000000162", "4000",
		"1000000163", "4000",
		"1000000164", "3",
		"1000000217", "SIT Sector 300",
		"1000000251", "The University of Auckland",
		"1000000342", "IT Support",
		"1000000422", "SIT Sector 300",
		"1000000426", "The University of Auckland",
		"1000000427", "SGP000000000103",
		"1000005781", "The University of Auckland"
		);
}
or do
{
	$keepon = "no";
	$reason = "Unable to create the new incident";
	$reason  .= "\n\n<pre>\n" . $ars_errstr . "\n</pre>\n";
	$incidentid = "0";

};

Pondering my memory of beaudrillardian hyperrealities in the context of my desktop environment.

Wondering if I can make an email monitoring widget…