Next session was an overview of the FEAST report, an overview of the adoption of shared services and cloud computing in universities which was funded by JISC.
HE is just too expensive for most economies, especially as an increasing percentage of the population attend University. In the end, the customer pays, either though fees or taxation.
Administrative overheads must be cut, putting more emphasis on front facing services. Why do we compete on services that give no competitive advantage eg payroll?
The transformation of the IT environment requires greater agility than we currently have. The world is changing rapidly!
Government in UK believes that efficiencies will come in back office services through sharing, pooling or outsourcing. They believe we have too much money, we can afford to run 160 payroll systems, data centres etc.
We have an excellent record in shared services eg purchasing consortia, JANET, UCAS. However the sector has been set up to compete with each other. We all want the best students and the best staff.
The report is aimed and written for VCs, Finance directors etc. High level. Intended as a report to be utilised rather than stand alone.
You would expect back office systems would be expensive in small institutions, and cheaper in big ones. Yet, this isn't seen.
Expenditure often based on legacy, not cost justification. Also institutions have no understanding of their back office costs. Know cost of IT systems, but not processes, eg how much does it cost to register a student.
Full report is concerned with emerging technologies with a focus on innovation to support flexible service delivery. The report contains a number of vignettes of shared services, and 6 in depth case studies. Eg University of Canberra have outsourced a lot of administrative systems and processes, with significant cost savings, and an increase in user satisfaction. Major process change took place. Kings College have outsourced a number of services including email and the desktop. The case study highlights a number of successes, but also the people and contractual issues.
Also includes a study of the STEP-F project which looked at the implementation of SOA projects across institutions though the use of an Enterprise Service Bus (ESB). Very rapid deployment of cloud based applications calling data from different student systems have already been demonstrated.
Message is that the pace of change is being driven by an accelerating provision of technologies and end user expectations. New paradigms are rapidly gaining maturity and institutions should prepare for the adoption of many. As IT depts we need to move away from technology and concentrate on processes and people. The obstacle to shared services is not technology, it's culture and people issues.
- Posted using BlogPress from my iPad
9 comments:
Coincidentally, I was at a meeting of the STEP-F project yesterday. I have to say that the actual usage of the resulting 'ESB' is very small-scale - 3 or 4 institutions talking via the ESB to a single application vendor (providing a 'degree validation' service). Not wanting to disparage the good (and as far as I can tell, very successful) work that has been done, I struggle to see how that conclusively demonstrates the possibility of any kind of real cost saving across the community. Will try and blog more thoughts on eFoundations later.
You might be intrested to know we already have a working esb at Sheffield !
James
"implementation of SOA projects across institutions though the use of an Enterprise Service Bus (ESB). "
Yes. We're already doing this at Sheffield.
We've been using an ESB to pass data between our administrative SAP system and bespoke Oracle student systems. This has been successfully operated for at least 5 years now.
More recently connecting to our Academic publications system to register academics seamlessly.
Connecting to an external supplier to send purchase orders electronically, and connecting from our bespoke student system to Blackboard Learn are well under way in Development.
I've also seen first glimpse of the spec. for an SMS messaging system which appears to use the same style web services as Blackboard so we should be able to hook this in using the same techniques.
No limitation on the possibilities really. Our next challenge will be to train up more developers.
Some benefits of the ESB include:
Central definition of integration between systems rather than disparate point-to-point ad-hoc solutions that people lose track of.
Central monitoring of messages passing between systems, so only need to look in one place to see what's going on.
Connectivity via adapters so can plug in legacy and simple systems using JDBC, delimited files etc. where web services are not available.
Yes. We've been using an ESB for the past 5 years to integrate services. Mostly SAP admin systems with bespoke Oracle student system.
More recently between our student system and VLE, and electronic Purchase Orders to external suppliers are working in Development.
It provides the capability to connect between disparate systems whether internal or external to the University.
Very interesting that you have an operational ESB, is it one that you have written from scratch or is it based on Biztalk or similar?
Following the shared services line of thought, are you sharing it (if it has wider reuse potential)?
Hi Dan,
We use SAP PI as it has SAP specific functionality that enable connection using their proprietary IDoc and RFC communication methods.
We're still in the early days of widening use to non-SAP systems. It runs as a self contained system so doesn't depend on the connected systems being SAP. E.g. Connecting our Oracle student system to Blackboard Learn.
We haven't given consideration to sharing outside the institution, but the considerations would be licensing, Contract SLAs etc. As much a technically plugging in the systems.
Hi George,
Thanks for the reply, sounds like a good solution for the SAP systems. I guess it will become interesting (in the Chinese curse sense!) once you move beyond SAP and particularly for systems beyond the campus.
Yep I agree that the non-technical aspects will probably be more challenging than the technology for shared offerings, although the extent of reusability versus bespoke specificity could also be interesting.
So far we have three non-bespoke systems connected other than SAP.
Symplectic Academic Research Publications system. (REST style web services)
Science Warehouse Purchase Orders to external suppliers.(REST web service) - due to go live end of July.
Blackboard Learn. SOAP Axis web services. Being rolled out for the start of the academic year.
It can handle SOAP (including Axis) web services, REST web services, JDBC for legacy database access, and delimited file upload/download for even older systems.
If you want to chat please drop me an email g.credland@sheffield.ac.uk
Thanks George,
This is clearly an area where you have made some interesting progress. I find the Blackboard one particularly interesting, I'm sure that would have wide applicability, especially given the range of technology access you're working with.
Thanks for the email, this is something I cannot investigate too much at this point, but I will aim to look at come early autumn.
Dan
Post a Comment