UCISA 2010: Doing the impossible

Tim Marshall promising to be good value for money talking about current climate for HE and how we need to learn to do the impossible.


National debt is equivilant to 2,600 x the running costs of the University of Leeds. Pundits are saying that public funding is likely to be cut by 25% over the next 3 years, that requires a fundamental shift.


I think I can see what might be coming here - a please for more public sector shared services - cloud based HEI applications? Makes sense to me ....


Tim suggesting that we just aren't ready for the change that's coming. His key tips:


- CIO's need to know your numbers. The ability to read financial statements is going to be more important for a start.


- The importance of trust will be even more important. Certainly that's true for achieving succesful shared services.


- Tell the team what you want, not what to do - then you harness a lot more experience.


Tim's 5 factors: Know your business, know your numbers, stive to be trusted, empower the team and see over the horizon.

Good presentation, but dissapointingly Tim didn't make any suggestions or proposal for how he saw the sector tackling the issue. It was only in questions that the issue of Shared Services was raised. With the government sector publishing the g-cloud ICT Strategy as a key plank in their bid to reduce costs through shared services surely we should be looking seriously at the same thing in HE.

I remain convinced that nothing is going to change until the funding models change to drive shared service forward. Perhaps this is something that UCISA need to start taking a lead on ....

UCISA 2010: student attendance monitoring

In discussion session about student attendance monitoring. A key issue for many with immigration regulations the main driver, but retention also featuring. Many still using semi-automated faculty/school based systems. Some looking at bio-metrics Eg: fingerprint registration. A lot of interest in Bedfordshires approach of statistical monitoring of student 'touchpoints' with different student interactions that are already recorded Eg: purchasing card transactions, physical access systems, computer login, library usage etc bring gathered and statistically analysed to identify outliers that don't conform to the typical interaction pattern for that group of students.

Lots of issues around DPA and use of information as well as student reaction to that kind of system. Technically best option is still single access token Eg: smart card for everything or better still a biometric token.

The key issue remains that getting this kind of project high enough up the priority queue is hard given the complexity and costs of solutions for relatively little benefit. We are all under so much pressure that anything with a manual or semi-automatic workaround jsut can't compete for resources.

UCISA 2010: King's College outsourcing programme

First full day for me at this annual event, arrived last night.


http://www.ucisa.ac.uk/events/2010/conference2010/programme.aspx

First session this morning was Gartner talking about negotiating techniques. Essentially a presentation of their research paper on the subject. Usual stuff, which we need to get better at.

Now listening to Lynne Tucker, Chief Technology Officer from King's College London talking about their major outsourcing programmes.


http://www.ucisa.ac.uk/~/media/Files/events/ucisa2010/4%20%20%20Lynne%20Tucker%20pdf.ashx

An unusual approach for an HEI, certainly wasn't an option for us in the early stages. Kings now have three major outsource contracts to manage - ranging across thin client provision as well as bespoke software development.

Very interesting that they are using SITS and StuTalk the XML web service plug-in for integration of student data into other systems - something we are trying to do.

The whole thing was kicked off by the need for major infrastructure investment eg: data centres.
Key features of their approach were:

- Web-enabled access
- Multi-sourced, partnered approach (staff expertise, data centres, 24/7 support)
- Out-hosting of infrastructure where appropriate (Tier 2/3 data centres, not necessarily with the same supplier)
- Concentrate on value-add in house (e.g. identity management) and harness internal skills and expertise (e.g. data and information management)

Staff skill sets switching to managing relationships with vendors rather than in-house technical skills. VRM critical - ie: vendor management so you know who is meeting with vendor, when and why and manage that relationship.

Loss of control is offset by processes for escalation that everyone understands.

Rigorous change management is essential.


It's not a cheap option, but long term pay back might be 3 x.


Major cost was the effort that needed to go in to making it happen. Key benefit was reducing risk - not having to worry about the infrastructure and getting in-house staff focussed on use of business applications.

The financials were complicated and there an overall revenue cost uplift was required as well as the capital investment.

Asked the question about whether it would be possible to make a business case especially a financial case for this kind of initiative in the current financially constrained times - the view was probably not. A more multi-sourced approach is probably the best bet and Kings are already brining some stuff back in-house.

It would be great to buy that kind of piece of mind though!

Sometimes all it takes is a bit of poetry

This morning, during a fairly animated discussion about an ongoing political issue, one of the team recited this rather wonderful poem, and it's kept a smile on my face all day long, no matter how big amd fierce the dragons ... (thanks Martin!)


KNIGHT IN ARMOUR

Whenever I'm a shining Knight,
I buckle on my armour tight;
And then I look about for things,
Like Rushings-Out, and Rescuings,
And fighting all the Dragons there.
And sometimes when our fights begin,
I think I'll let the Dragons win ...
And then I think perhaps I won't,
Because they're Dragons, and I don't.

A.A. Milne
Now We Are Six

Educause 2009 - Sharepoint 2007 - Yes Please!

Arrived slightly late for the session, so hoping that it's the right one .... we have committed to Sharepoint for our VLE (or LMS, whichever you call it) and for corporate document management, content management system etc. So I'm keen to hear from other who are further down this path than we are .....

Speaker is showing an IT service web site - with integration with data from underlying systems displayed - service incidents etc. Each IT Function department has its own area which looks different if they are logged in as a member of the team with a lot more information and the ability to post, also integrated with document management where they keep all files and documents - AhHa! - screen looks like Sharepoint - so I am in the right presentation!

They also have their service catalogue on Sharepoint with all the services that they offer - it looks great and exactly where we want to go with our Sharepoint implementation. When they load documents onto Sharepoint they can decide which documents should be published as public - rather than having to have a seperate public folder. They also have it integrated with Remedy as their helpdesk solution. (We use Support Works, but same principles apply).

95% of the development was done through the browser and only 5% needed to be done through the development tools - that sounds good!

Comment from the developer was that it is a bit like a blank canvas and you have to provide a structure in terms of metadata, forms, schemas etc ie: an Intranet template and then push that out to customers who can use it to create their own Intranets. Usage of this is now starting to approach the functionality of web content management, and they are evaluating whether or not this is how they should do their web content management (if you're using it for document management and your Intranet already why wouldn't you?)

They showed an example of a Sharepoint content managed web site which they thought was a very good case study http://www.cps.edu/

The presenter rutns out to be from the University of Iowa - Information Technology Services, and the Intranet he was showing us is called Ohana. http://its.uiowa.edu/

Next up is a project manager from the ITS department. The sharepoint intranet has proved very useful for communicating about projects and for reinforcing the project management process and why it's there. The Intranet has a list of all the current projects. There is an on-line form with all the fields you would expect to see on a project mandate/pid. The data in these fields in then used to drive how the information about the proejct is used elsewhere. All the related documentation for the project is also stored here. This form is something that the customer fills in (Crikey! I wasn't expecting that!). The customer then submits this to a weekly 'review' meeting where the form and documentation can be viewed on-line be the review committee. They can then approved or reject the project on line. Am I hearing this right. On-line Project Governance - or how to say No automatically! They must have a fantastic relationship with their customers! :-)

The project manager is now saying that a key benefit is being able to access all historical documentation about a project. There is a tool on the internet that allows you to search through all project documentation involving a named individual and reports on what that individuals current work load is, it looks like they have fairly large IT function. They also use it as a time management system so ITS staff can fill in hours worked against different projects and services. It all looks very impressive but it does come across as a bit of a 'command and control' way of doing things - perhaps it's just that they already have a very trusting and collaborative culture and automating all these things that normally need lots of delicate handling is just not an issue. It would be good if we could!

Next speaker was from the Open University of Hong Kong and talked about use of Sharepoint 2007 for Communciation, Collaboration and Learning. http://www.ouhk.edu.hk/

They are a distance learning university - (Note to self: LDS back home may well be interested in this!) 13,000 distance learning students with 700 courses.

Speaker gave an overview of Sharepoint functionality: BI, collaboration, Portal, Search, Content Management, Business Forms, BI - all good tools for sharing information, managing workflow and team collaboration ie: all the kind of stuff you need for an LMS (VLE)

They are using Sharepoint in 8 main areas: Portal, Document Management, Team collaboration (esp. research), student support and administration, teaching and learning, workflow and process improvmeent, BI, social computing.

The presenter then talked about the maturity model for BI - ie: from decriptive and evaluative reporting through to predictive reporting for decision making and strategic planning. They have a 'mature' BI tool written in Sharepoint called InfoShare. It took 100 man (sic) days to develop the BI tool and 67 man days to develop their On-Line Learning Environment tool in Sharepoint. Crumbs - that's a bit speedy! Perhaps we ought to talk to them. We were using a third party to help us with our VLE development using Sharepoint but are currently doing much of it ourselves. It might be useful to have a more detailed follow up conversation with the HOng Kong OU about their Sharepoint project. (Note to Self: Pass this info on to the architect working on our project)

The speaker reccomended this document as a resource: http://www.eduserv.org.uk/research/studies/~/media/research/SharePoint%20Study%20LiteratureReview%20Sep2009%20pdf.ashx

It is a report on the use of Sharepoint within HE.

Question time - and an interesting point that emerged was that there is a limit on the number of documents in Sharepoint 2007 of 30,000 after which Sharepoint become unstable. Presenters were asked if this had been a problem, but they said they hadn't come anywhere near that limit yet. Apparently, Sharepoint 2010 removes this limitation. (NB: Couple of comments subsequently posted on this blog to say that the 30,000 limit of Sharepoint 2007 is not correct. See comments below.)

Right - next stop Brenda Gourley's closing keynote. Looking forward to that .....

Educause 2009: Higher Education and SOA

Friday 8.10am, and a session on SOA and student data. A subject that is very hot for us at the moment as we try and implement XML .Net based SOA to tie all our student data together and deliver the information agility that our University needs.


So far and not too technical - presentation starting with quick overview of the problem - increasing need for data and information, data in lots of silo systems, access to data and reporting via 'programmers' based in IT ie: fixed reports and ad hoc reports if you were lucky. Yup - all very familiar ....



Data warehouses and BI tools allow 'Surfacing of Data' - data in the hands of the decision makers, removing or at least reducing silos, creating flexible outputs which the end user can use so that developers can get on with developing rather than having to spend all their time generating reports ..... Ok - agree with all of that ...


BI tools are now changing the expectations of decision makers - predictive modelling, decision processing, point in time analysis (not sure what that means exactly), all being demanded. However there are problems with deciding how granular you are going to need your raw data to be, the context and definitions of your data and the data refresh cycles you need - these are all issues you need to address.


(As an aside this presentation is being delivered as a classic put up the slides and then paraphrase the slide and expand on it - which makes it nice and easy for those of us who are sitting here writing notes as the presentation happens, but maybe makes it a bit slow and repetative otherwise?)


A move from static data to "Dynamic BI" means that you have to start thinking 'processes' in a different way. Process flows and workflows become important and data rules have to be agreed and understood as they are going to be automated so they have to deliver the right thing.

It occurs to me that this is the same old story that was told in the days when BPR (Business Process Re-engineering) was all the rage. Make sure that you don't pave over the cow paths. If you just automate the processes that have evolved over time then you just end up automating inefficient processes, that meander all over the place, and that don't take you from A to B efficiently. You need to start from scratch and re-engineer the processes first (so that you cross the field in a straight line rather than by means of meandering cow paths) before you automate them.

Back to the presentaion - the demand for dashboard functionality and reports also starts rising exponentially (as we have already seen with the implementation of a simple dashboard reporting tool for some of our data)


BI requires - "next-generation architecture" ie: SOA (Service Orientated Architecture). Current architectures are limited. Yup.


Buzz phrase "Change Adaptive" used by the speaker to mean we are working in an era of rapid change - legislative, compliance, business etc and systems need to change at the same speed.

Ok I was already convinced that I need SOA, and now I'm convinced all over again. A different speaker now (hope he's not going to get too techy)


How does SOA help solve these problems? - the underlying data schema can evolve with out requiring a whole load of changes to reporting and systems integration. This means you have to put a service layer inbetween the actual databases and the workflow, integration and reporting functionaliuty you want - Yup - come on we know all this thats why we're sitting here .....


(As another aside if you're reading this and you're not familiar with SOA in an HE environment then I can thoroughly reccomend this short JISC animation http://www.jisc.ac.uk/whatwedo/programmes/eframework/soa.aspx which describes it brilliantly and simply even for the non-techie!)


Presenter now showing a schema of a generic SOA layout ..... (watch the animation above and you'll get the idea if you don't know what this might look like)


One change that this brings in is that you need a different data structure for the service layer than for the database(s) underneath it and you need to think about it. The schemas and dictonrys for the service layer are multiple and small. They need to capture 'transformational logic' by which I assume speaker means the rules by which data is changed or processed within the service layer. Each data element (object? artifact?) needs a common service definition in the service layer that applies to all databases that hold that element. What this means is that you need to treat business logic as if it is data - ie: business rules and workflow processes are now automated and therefore have to be defined and captured as data. This I think is the essential BIG change. Administrators and managers are not used to thinking of their processes and ways of working in this discplined way. But the benefits are huge in terms of flexibility of reporting and adapting to changing process requirements.


Speaker now talking through a diagam of how service adapters (chunks of code that define transformational logic and data elements) are used -a bit over my head at this point but I think I get the gist!


Adapters can be used for different things for example they can be used to carry out a mapping of a data element across two databases and carry out a transformation of that data in some way eg: changing the status of a student from application to registration. Or it can be used to access the same data element from different systems and any associated data elements and pass them up to a reporting function within the service layer (eg: tying together timetabling information and course information for a single student from the timetabling system and the student information system). (NB: the eg: are mine not the speakers so they come with a health warning as I may have totally misunderstood!)

We are now going to get a live demo on reporting via a service layer - and at this point it all gets way too technical for me. The demo essentially seemed to be using an open source 'ETL' tool (don't know what ETL is? Extraction Translation Language??) called Talend.


The demo showed to a list of data elements that were defined for use in the Service Layer. Woa! - there's a whole load of code on the screen and most of the blokes with beards are all leaning forward and concentrating intently! I feel like an 'under-cover' interloping CIO! - 3 people have just left ...... maybe they're CIO's too ....

Think I'll stick it out but what would be helfpful for me is to hear more about the challanges of actually implementing this stuff. How long did it take, what where the obstacles, what are the limitations and the BIG question - how do you manage to get the stakeholders to sit down with you to define the processes and data elements that are needed to create a service layer?


Speaker now making the point that you can create user interfaces for different purposes to the data in the service layer which comes from different systems. Now showing some fancy open source reporting tools that you can layer on top of your service layer - much like we will do with our reporting tool Qlikview which when we get SOA in place will sit on top of the service layer instead of sitting on top of data extracted and combined into spreadsheets as at present.


Question time at last - and I asked how did they get the administrators etc to engage with defining the data and processes etc - the answer:


- it took a year and a half!
- the process was iterative - defining requirements of what you actually want to do and what data is needed - defining use cases (I'm assuming UML use cases?), implementing, testing and piloting some of the service layer then going back round the loop again
- looking for commonality of data elements and processes across all the requirements

In a nutshell slowly and with a LOT of effort. Mmmm - this is going to be a tough project for us but one we MUST do if we are going to deliver our corporate strategy.


We need to deliver some solid results by the beginning of next academic year and we're not going to be able to do everything by then - sounds like DSDM might be a good way of tackling this.

Another question was asked from the floor about the difficulty of defining access/permissions. Response was that this took a lot of time too - and when you think about it that's not surprising. You are no longer defining access/permissions to individual databases that are 'owned' by seperate groups of users (or organisational silos). Instead you are having to identify access/permission to a common entity (the service layer) for all groups. It could be complicated and would almost certainly mean changes to the current access requirements to simplify and consolidate them.

Looks like that's it - so the take-away (as our American colleagues say). Implementing SOA is going to be just as hard as we thought it would be, and probably harder - but the benefits are more than worth it and in fact are probably essential for organisational survival given the exponential rise in the volume and pace of changing requirements.

Next stop - coffee!!

Educause 2009 - Learning from failure ...

I've always thought that failure was under-rated and that the best way of improving things was to pay attention to when things went wrong and learn from the mistake. The trouble is you have to do it carefully, otherwise everyone starts getting anxious and muttering about blame cultures. So, I was quite excited when I saw a session at Educause entitled "Houston, we have a problem - Leading through Failure"

The presentation was from a group of senior manager's from different HEI's who all felt that learning from failure was very useful and worth talking about - they described it as 'rich learning'

The session started with a short video from Honda http://dreams.honda.com/videos/failure-the-secret-to-success/ talking about the culture within Honda of encouraging failure and risk taking in order to achieve extraordinary success - it's worth watching.

Each presenter talked about a separate example from of where failure was a really useful learning experience for them.

The first presenter talked about a failure caused primarily by not understanding the context of a project. His advice, to check every so often that you are taking a macro view of the situation. Risk looks a lot smaller and a lot less risky the further you are from the situtaiton. A risk embedded within a single project looks huge to someone in the project team, but is insignificant and possible well worth taking from the view of the VC. It is certainly true that within some of our projects, especially the big strategic ones, we do not always step back often enough to look at things from our customers perspective - and as a result we get caught by surprise with demands for things that we think we are already delivering. Note to self: when it goes wrong, spend more time looking at what has gone wrong and why and learn from it.

A speaker from the University of Hawaii talked about a huge project to put in place a new campus student information system and then the vendor left the project at a critical stage. The positive consequences of the failure was the way in which everyone else, spurred by panic initially, pulled together into a team in a way that would not have happened otherwise and the project plan acted as the stable 'skeleton' around which they could motivate and pull resources together, with more trust and better communication, and they succeded. Fail to plan and you plan to fail, as someone later quipped.

A university librarian talked about a project to tackle running out of space for books. DiscusTo him it was obvious - we have to get rid of the old stock that we no longer use. This was not obvious to everyone. Discussions with stakeholders made it clear that to some the obvious solution was 'let's build a new bigger building'. Key lesson - different minds make different decisions - make sure that everyone understands what the decision actually is. His experience was that although spectacular failures are often the best learning experiences - spectacular failures are often not as spectacular as you might think. One vocal critic can make the failure seem huge and create a lot of fear, but actually they are just one voice and other quieter voices may have a very differrent view.

The next speaker talked about the role of assumptions. This was a portal implementation. Everything was looking good, there was a plan, there was time, it all looked on track. But, after roll out new faculty staff couldn't log on, and there were a lot of them. The HR process for provisioning new accounts was not working in the way that the project had assumed it had. Although assurances had been given they had been given by individuals who did not have the positional authority to follow them through. The lesson learned - watch the assumptions, and watch whose making them and based on what information.

The next story was a 'tale of woe' about a Graduate Admission Application Form that was going to be redesigned and made into an on-line form. There was a perception amongst Faculty that IT were not going to be able to do a good job as they did not provide Faculty with the support and help that they wanted on a day to day basis. So they decided to do it themselves (sound familiar?). As you would expect there were data integration issues, not enough testing, when they asked for help from IT, as you can imagine, tempers flared. Faculty admissions staff thought that IT are being unhelpful and IT thought that Faculty admissions staff are being unreasonable. This went on for two years. It is now up and running but the legacy is a lot of hard feelings. So what are the lessons from the failure? It started because of a perception that IT was inadequate and it was exacerbated by an attitude of do first and ask later, total lack of communication and egos. You have to really look out for the warning signs that communication is not happening, or is happening but is not going well - body language in meetings? failure to return calls and answer emails? lack of any face to face discussions?

I asked the question I started this note with, about how do you manage to create a culture where people are willing to investigate and understand what went wrong in order to learn without seeing it becoming, or being perceived as, a blame culture. Responses from the presenters included ensuring that you are up front about the fact that things have gone wrong and make it clear that we need to get past the 'finger-pointing' and on to the more productive discussion around how do we learn from it. Also as a leader making it clear that if it all goes wrong you will take the wrap and if it all goes well the team will take the credit - something which I completely agree with. But you need ot make sure you don't just say it but follow through if an when it happens.

Another questioner pointed out that continual honest communication is key to all of it and a common thread across the presentations.

I thought it was one of the best sessions at the conference - and it is great to see people talking about the things that didn't work well. Usually the conference sessions are all about the success stories and the best practice case studies - but it's the failures that we learn most from. On Monday, back at the ranch, we have the first meeting of our new, reconstituted, IT governance group and having some honest conversations about why the previous governance group failed will be a very positive initial step towards increasing the chances of success second time round.