The STG’s programme included updates on projects of the members as well as previews of the synthesis of the Flexible Service Delivery programme of which the STG is a part, and a preview of the University Modernisation Fund programme that will start later in the year.

The main event, though, was a series of parallel discussions on business problems where shared services or cloud solutions could make a difference. The one I was at considered a case from the CUMULUS project; how to extend rather than replace a Student Record System in a modular way.

View from the King's anatomy theatre up to the clouds

In the event, a lot of the discussion revolved around what services could profitably be shared in some fashion. When the group looked at what is already being run on shared infrastructure and what has proven very difficult, the pattern is actually very simple: the more predictable, uniform, mature, well understood and inessential to the central business of research and education, the better. The more variable, historically grown, institution specific and bound up with the real or perceived mission of the institution or parts thereof, the worse.

Going round the table to sort the soporific cloudy sheep from the exciting, disputed, in-house goats, we came up with following lists:

Cloud:

• email
• Travel expenses
• HR
• Finance
• Student network services
• Telephone services
• File storage
• Infrastructure as a Service

In house:

• Course and curriculum management (including modules etc)
• Admissions process
• Research processes

This ought not to be a surprise, of course: the point of shared services – whether in the cloud or anywhere else – is economies of scale. That means that the service needs to be the same everywhere, doesn’t change much or at all, doesn’t give the users a competitive advantage and has well understood and predictable interfaces.

Following the JISC’s FSD programme, an increasing number of UK Universities started to use the ArchiMate Enterprise Architecture modelling language. Some people have had some introductions to the language and its uses, others even formal training in it, others still visited colleagues who were slightly further down the road. But there was a desire to take the practice further for everyone.

For that reason, Nathalie Czechowski of Coventry University took the initiative to invite anyone with an interest in ArchiMate modelling (not just UK HE), to come to Coventry for a concentrated two days together. The aims were:

1) Some agreed modelling principles

2) Some idea whether we’ll continue with an ArchiMate modeller group and have future events, and in what form

3) The models themselves

With regard to 1), work is now underway to codify some principles in a document, a metamodel and an example architecture. These principles are based on the existing Coventry University standards and the Twente University metamodel, and the primary aim of them is to facilitate good practice by enabling sharing of, and comparability between, models from different institutions.

With regard to 2), the feeling of the ‘bash participants was that it was well worth sustaining the initiative and organise another bash in about six months’ time. The means of staying in touch in the mean time have yet to be established, but one will be found.

As to 3), a total of 15 models were made or tweaked and shared over the two days. Varying from some state of the art, generally applicable samples to rapidly developed models of real life processes in universities, they demonstrate the diversity of the participants and their concerns.

All models and the emerging community guidelines are available on the FSD PBS wiki.

Jan Casteels also blogged about the event on Enterprise Architect @ Work

For one thing, EA is still a bit of a minority sport, as Tim Westbrock reminded everyone: 99+% of organisations don’t do EA, or, at least, not consciously. Nonetheless, impressive, linear, multi-digit growth in downloads and training in The Open Group’s Architectural Framework (TOGAF) indicates that an increasing number of organisations want to surface their structure.

Question is: where does that activity sit?

Traditionally, most EA practice comes out of the IT department, because the people in it recognise that an adequate IT infrastructure requires a holistic view of the organisation and its mission. As a result, extraordinary amounts of time and energy are spent on thinking about, engaging with, thinking as or generally fretting about “the business” in EA circles. To the point that IT systems or infrastructure are considered unmentionable.

While morally laudable, I fear that this anxiety is a tad futile if “the business” is unwilling or unable to understand anything about IT – as it frequently seems to –, but that’s just my humble opinion.

Mike Rollins of the Burton Group seems to be thinking along similar lines, in his provocative notion that EA is not something that you are, but something that you do. That is, in order for an architectural approach to be effective, you shouldn’t have architects (in the IT department or elsewhere), but you should integrate doing EA into the general running of the organisation.

Henri Peyret of Forrester wasn’t quite so willing to tell an audience of a few hundred people to quit their jobs, but also emphasised the necessity to embed EA in the general work of the organisation. In practical terms, that the EA team should split their time evenly between strategic work, and regular project work.

Tim Westbrock did provide a sharper contrast with the notion of letting EA become an integral part of the whole organisation inasmuch as he argued that, in a transformative scenario, the business and IT domains become separate. The context, though, was his plea for ‘business architecture’, which, simplifying somewhat, looks like EA done by non-IT people using business concepts and language. In such a situation, the scope of the IT domain is pretty much limited to running the infrastructure and coaching ‘the business’ in the early phases of the deployment of a new application that they own.

Stuart MacGregor of realIRM was one of the few who didn’t agonise so much about who’d do EA and where, but he did make a strong case for two things: building and deploying EA capacity long term, and spending a lot of time on the soft, even emotional side of engaging with other people in the organisation. A consequence of the commitment to the long term is to wean EA practices of their addiction to ‘quick wins’ and searches for ‘burning platforms’. Short term fixes nearly always have unintended consequences, and don’t necessarily do anything to fix the underlying issues.

Much further beyond concerns of who and where is the very deep consideration of the concepts and history of ‘architecture’ as applied to enterprise of Len Fehskens of the Open Group. For cyberneticians and soft systems adepts, Len’s powerpoint treatise is probably the place to start. Just expect your heckles to be raised.

Resources

Tim Westbrock’s slides on Architecting the Business is Different than Architecting IT

Mike Rollins’ slides on Enterprise Architecture: Disappearing into the Business

Henry Peyret’s slides on the Next generation of Enterprise Architects

Stuart MacGregor’s slides on Business transformation Powered by EA

Len Feshkens slides on Rethinking Architecture

Which data

What it’s all about. To my unscientific eyeballing, the existence of most every dataset of interest is flagged. You can find them too, with some patience and use of the tags. Clicking through to the source quickly shows that most aren’t available to us yet in any shape or form, though. That’s fine, I’m sure something like that just takes time.

What would be good, though, is some indication which ones are available in the navigation or searching. Where available means: queriable through the SPARQL interface, or downloadable as an RDF dump.

Getting at the data

The main means through which you get at the data is via the SPARQL query service provided. That works, but has some quirks:

From experience, the convention for such services would be that you’d provide one at http://mysite.org/sparql, and that you’d get a human SPARQL query form if you go there with a browser, and you get an answer if you fire a SPARQL protocol query at it from the comfort of your own SPARQL client.

There is a human interface at https://www.data.gov.uk/sparql, but machine queries need to go someplace else: http://services.data.gov.uk/{optional dataset}/sparql Confusingly, the latter has a basic but very nice human interface too…

Of more concern is that both spit out either JSON (in theory) or XML, but not RDF. Including XML and JSON is very sensible indeed, because the greatest number of people can suck those formats up and stick them in the mashups they know and love. But for the promises of linked data to work, there is an absolute need for some kind of RDF output.

Exploring the data

In order to formulate the whizzy linked data queries that this stuff is all about, you have to get a feel for what an open data set and its vocabulary looks like. That is a bit lacking as well at the moment: you can ask the SPARQL endpoint for types, and then keep poking, but making the whole thing browsable on something like the OpenLink RDF browser would be even better. I stumbled on some ways of exploring vocabularies, but that didn’t seem to allow navigation between concepts just yet.

There is a forum and wiki where people can cooperate on how to work on these issues, but I couldn’t see how to join them- hence the post here.

So?

If you’re getting rather disappointed by now: don’t. As far as I can see, the underlying platform is easily capable of addressing each of the points I stumbled across. More importantly, all the pieces are there for something truly compelling: freely mixable open data. It’s just that not all the pieces have been put together yet. The roof has been pitched, but the rest still needs doing.