FOTE09 - Robert Moores: Google Apps - One year on

1,184 views
1,144 views

Published on

Robert Moores' talk at ULCC's Future of Technology in Education conference on October 2nd, 2009

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,184
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Thanks Tim and Frank for inviting me to speak and for you for being prepared to listen
  • When I rashly accepted the invitation to speak today my first thought was – we have over 300 people from all ends of the spectrum of technology and education. When I’m standing there in front of them what is the single, burning question that is going to be be crashing around in their heads ? For the answer I took refuge in maslow’s hierarchy CLICK TO REVEAL SLIDE I decided that wasn’t a bad place to start from – keeps you sharp And to be fair, that’s not a bad way to summarise our experience – which is that Google Apps essentially does what it says on the lid - so we can spend our lunch break fixing some other problem instead !
  • As I’m presenting this for free we first have to view the sponsor’s ad … So this is the very basic context for our implementation: Leeds Met has been growing year on year since the nineties, In the 2008 – 09 academic year, we had over 30,000 students and 3,500 staff, on two locations – Leeds City Centre and our Headingley Campus.
  • Why did we implement Google Apps? – To improve the Student Experience. In July 2007 it was apparent that the student email system at Leeds Met was not meeting the needs of the students, as it was originally designed at a time when few students had email or even internet connectivity. The original email system was considered to be the core of the University’s communication strategy between the itself and the students, an important medium that allowed both academic and administrative staff to communicate directly with students quickly and easily. With a small amount of disk space allowed per user, many of the students were using external third party systems, which allowed the student gigabytes of storage, and also calendars, task lists, and online office applications. Many students were avoiding using the University email account as their main or primary email account, as they knew it would be deleted when they left the institution. Many of these students did not configure their University email accounts to forward to their primary email account and as a result, many messages from the University were not getting through, or if they were accessed, the messages were often not read in a timely manner. We realised that students had an ever growing demand for disk space, fuelled by the use of digital photographs, digital video, online and digital resources and electronic submission of assignments. We also had a desire to maintain a long-term relationship with the students, and to encourage them to maintain the relationship with Leeds Met – an email address for life could help with this. As a starting point, we looked at providing a fit for purpose student email system. This would require at least one Gigabyte of storage space, and would need to be easy to use, accessible from any location or PC, and be available 24x7x365. Our initial costings for an in-house system to do this came out at approximately one million pounds over four years, then the refresh cycle costs would kick in. In today’s (or any day’s) economic climate, this did not make sense – but the status quo could not continue. So we had all the good things in place – except a winnable business case in the light of other priorities for finance … when along came the silver bullet in the shape of Sam Peters from Google.
  • The software runs on the provider's premises, not the customer's, and payment is by subscription spread over the term of the contract rather than as an upfront license fee (or in Google Education’s case – free) The most important is that we, and our customers, don't have to wait for a custom technical implementation. With conventional on-premises software and hardware, there is a substantial time lag after purchase, before the software is ready to run. On demand licensing enables software to become a variable expense, rather than a fixed cost at the time of purchase. It also enables licensing only the amount of software needed versus traditional licenses per device. Software already installed and basic configuration done – still needs business-level config Software as a Service removes constraints such as location-based access (because it’s usually web-based), phasing in, capacity and availability - thereby removing some of the supply-related barriers that have traditionally limited the long tail of demand. This allows real space for innovation and value-add ! However - APIs are crucial to integration of Software as a Service - can an object created in a Software as a Service Application be captured as a record in a Corporate Business System, and vice-versa?
  • How could we, as a University service, add value to the Software as a Service? We held meetings and seminars with Faculty Registrars and staff, Library staff, Students, focus groups such as the Technology Enhanced Learning teams, to explain what we were proposing, to to gather feedback and gain buy-in.
  • We implemented the pilot for 3000 students (all volunteers) within two months, and most of that time was the integration work. Getting to pilot / trial the software very early is a great way to validate your current business requirements. In a traditional waterfall development environment, the software delivery is often way down the line – not only do you require a leap of faith that what you get is what you want, but what you want may well have changed by the time you get there ! After the pilot, we surveyed the students who had used the new email system, and 99.2% rated it Good to Excellent. We integrated and overlaid our CMIS timetabling system with Google calendars, to give the students a single view on the world. Helped instill a mindset that this is not just about email but about communications, productivity and collaboration. We integrated the Google sign-on into our Integrated Identity Management system, so that – The Google login was created as part of the Student record creation. The Google login was part of the Integrated Identity Management System, so the student still only had a single sign-on We integrated the Google sign-in link to our Portal. We ran workshops, stands, leaflets, a student-produced video, regular staff bulletins, hoodies, integrate with our student email and acceptable use of IT policies
  • Google Security (also known as Postini) We had a requirement to quickly implement something that could provide a additional security service in addition to our standard firewall and anti-virus services. We had come under attack from Phishers, who were trying to gain access to our systems, mainly email, to allow them to use us as disseminators of spam. Even with the systems we had, this was taking up a lot of staff time and effort, and we looked for a better way. We chose Postini, and in the week of implementation, this reduced ingoing and outgoing spam by 60%, and we expect to raise this to high 9’s But this also gives us future capabilities, as it also stops viruses, phishing, denial of service (DoS), directory harvest attacks (DHA), and other attacks, with a five nines availability. Postini also has the capability of email archiving and discovery, should we decide to go down this route in the future, as well as enhanced web security tools. We had this up and running within two weeks of signing up. This fits more into the model of Software as a Services, as we pay an annual subscription per email user for this.
  • Obviously we did a lot of support at the start then iHelp did more as time went on. Interestingly we had no how do I use this questions. This is actually less than we had with the old system. There was a few phone calls as you may recall on the 24th of February this year as the service was down for half a working day.
  • As the Apps mature, we will review them and see if we can support them internally We will also re-assess their suitability for staff - particularly email, calendar and sites Now we have had a full academic year, we can assess what guidance and policies can be improved – eg. IT use / email / information security In a sense it’s almost been TOO easy – and we need to make sure we don’t lose focus as other priorities compete for our attention
  • QR (Quick Response) Codes are a popular type of two-dimensional barcode, which are also known as hardlinks or physical world hyperlinks. QR Codes store text, which can be a URL, contact information, telephone number, even whole verses of poems! QR codes can be read by any device that has the appropriate software installed. Such devices range from dedicated QR code readers to mobile phones. The Chart API generates the appropriate QR code QR code reader software is available from many sources. Google offers a QR Code reader library, Zebra Crossing (ZXing), for free
  • Is this a good thing or a bad thing – as ever it depends who you ask, and when ! But it IS a potential scenario
  • As shared services – will be seen as less risky than public cloud and less potential for conflicts of interest than institutions selling spare capacity 3 years away to full acceptance Disaster recovery / data centre 5 years to on-demand computing for peak periods such as admissions and results, and academic computing (latter can be satisfied elsewhere)
  • Service orchestrator, service manager will also grow in importance- and these are relatively well understood, but if we are to get any kind of control over our users then we need to accept what is happening already , not try to fight it head on.
  • In summary Google Apps has been very good for us to date – great benefits, low support My advice would be to get stuck in rather than spending too long developing policies around these areas. Get up and running in some non-critical areas and learn from experience. and to recognise that if you don’t, your users will just do it anyway – you can lead them or you can follow them – your choice ! Thanks once again to the organisers for inviting me to speak and for you for listening. I’ll make a version of these slides available to Tim to put on the FOTE site, and I’d welcome talking through our experience or any of the issues I’ve covered today Thank you
  • FOTE09 - Robert Moores: Google Apps - One year on

    1. 1. Google Apps One Year On
    2. 2. The One Burning Question “ is it really a whole hour until lunch ?”
    3. 3. Leeds Metropolitan University <ul><li>30,000 students, 3,500 staff </li></ul><ul><li>2 main sites: City and Headingley Campus </li></ul>
    4. 4. Problem Solution Executive support Business case Strategy meets Serendipity
    5. 5. SaaS Benefits For Us <ul><li>No capital expenditure </li></ul><ul><li>Flexible licencing </li></ul><ul><li>No technical design or implementation </li></ul><ul><li>Export our carbon emissions ? </li></ul><ul><li>Easy in – easy out ? </li></ul>
    6. 6. Engagement Technical Hearts & Minds Contractual Easy / Cheap Hard / Expensive
    7. 7. What We Did Provisioned email accounts: IDM – mail API Provisioned timetable: CMIS - calendar API 3000 user pilot Lots of student and staff engagement No data transfer
    8. 8. One Year On - We Love It More Google: Postini & YouTubeEDU Very high student satisfaction levels Very low support requests Acceptance of downtime !
    9. 9. Support Requests <ul><li>1418 queries of which 393 about Google Apps </li></ul><ul><li>Google Error Pages: 11 </li></ul><ul><li>Can’t find old email: 12 </li></ul><ul><li>Username / Password: 57 </li></ul><ul><li>Change of Name  / Email Address: 29 </li></ul><ul><li>General Login and ‘captcha’ Reading Issues: 67 </li></ul><ul><li>Calendar Make Public (requests not issues): 130 </li></ul><ul><li>Calendar missing: 17 </li></ul><ul><li>Forwarding (How to set up): 18 </li></ul><ul><li>Portal to Gmail (No pass-thru): 11 </li></ul><ul><li>Alumni from Early Adopters wanting to keep accounts: 13 </li></ul><ul><li>Google Docs Compatibility: 5 </li></ul><ul><li>Where are my contacts: 9 </li></ul><ul><li>Novell Driver issue resulting in failure to create account: 11 </li></ul><ul><li>Speed of email compared to internal service: 3 </li></ul>
    10. 10. What Now ? <ul><li>More Google … </li></ul><ul><ul><ul><li>Integration into policy and procedure </li></ul></ul></ul><ul><ul><ul><li>Apps as functions mature </li></ul></ul></ul><ul><ul><ul><li>App Engine </li></ul></ul></ul><ul><ul><ul><li>Android </li></ul></ul></ul>
    11. 11. Favourite Feature ! QR Codes http://chart.apis.google.com/chart? cht=qr&chl=<FOTE09>choe=<UTF-8>&chs=300x200
    12. 12. What Now ? <ul><li>Growth of niche SaaS … </li></ul><ul><ul><ul><li>Non-critical </li></ul></ul></ul><ul><ul><ul><li>User-selected </li></ul></ul></ul><ul><ul><ul><li>IT Department involvement ? </li></ul></ul></ul>Strictly imho …
    13. 13. What Next ? <ul><li>Shared services private clouds … </li></ul><ul><ul><ul><li>JISC / MAN backed </li></ul></ul></ul><ul><ul><ul><li>DR / DC </li></ul></ul></ul>Strictly imho …
    14. 14. Changing role of the IT Department <ul><li>From service provider to… </li></ul><ul><ul><ul><li>Service broker / intermediary </li></ul></ul></ul><ul><ul><ul><li>Service accreditor </li></ul></ul></ul>Strictly imho …
    15. 15. Google Apps One Year On

    ×