Mobile IT is in its infancy. Smartphones have reached the level of 1980s micros - exciting new models every month but few common standards or obvious market leaders. How can we effectively support mobile IT users? Can we provide people with what they want, without descending into a chaos of incompatible systems and competing demands?
Nick will talk about the Gartner managed diversity support model, or alternatively restaurants. Pick-and-mix is fun but unhealthy. We can't afford a la carte siliver service. Can we agree on a set menu?
Many people are familiar with the benefits of mobile email, fewer people are familiar with the benefits of mobile web. With the Internet on my mobile I am permanently connected to a vast network of information. With Wikipedia and a smartphone we now have the Hitchikers Guide To The Galaxy.
Smartphones are immature toddlers. They have reached the level of 1980s micros - exciting new models every month but few common standards or obvious market leaders. Can we pick the winners? Can we manage the diversity?
But much has changed since the 1980s. Mobiles aren't PCs. Why is a mobile different from a PC?
Mobiles are different to PCs as, despite the P in personal computer, mobiles are the true personal devices. Everyone has one. People develop a very personal attachment to a device you carry all the time. Like cars they can be fashion items and status symbols. What does your mobile say about you? We have an umbilical cord with our mobile - because it connects us to friends and family.
Think about the people. We want a strategy to support people, not devices.
First, forget about the shiny toys, think about the users.
Mobile IT isn't about devices being mobile, it is about people being mobile.
People should be able to work and access IT services at a time and place that suits them.
That might be on a device they carry with them, or on any terminal they are passing. It might be in their office, in the library, in their lounge, on an HDTV, or a projector.
Everyone is mobile to a greater or lesser extent. We should think about profiles for different users.
The Gartner managed diversity strategy (or alternatively restaurants).
Choose from a menu of:
User has the choice from a limited selection of devices, in the exchange the user gets support.
University owned & paid for.
You break it and the university fixes it.
There is an essential responsibility on us to review the range of devices regularly. Like the best menus, they must stay fresh. We musn't be afraid to change horses when necessary.
To ensure we don't have the burden of support old devices indefinitely, we set a clear expectation that each device has a limited lifespan. Users buy mobiles via Telephone Services with a two year contract. At the end of the two year contract it is possible (likely?) that we will expect the department to buy a new, modern device.
Tested to work with university services.
Device can be managed (encryption, remote wipe) .
Applications can be specially written for the platform.
Most suitable for:
Big win for staff: it just works.
Big win for university: we can control costs, control data.
Risks:
Typically employee owned and paid for.
If you lose it, you replace it.
If it breaks, you fix it.
We provide self-support information.
If it doesn't work, it's your problem.
Limited to safe interactions with corporate systems (you don't copy a database of student records onto your personally owned laptop, but you can view it through a terminal server).
Most suitable for people who:
Think about our students - we don't buy laptops or phones for them, this is the only model for students. Increasingly, some of our employees want this as well. Why?
Big win for the university: staff are paying their own phone bill!
Big win for staff: they can use their favourite device or combination of devices to be productive in a way which suits them.
Problems: no guarantees.
If you're wealthy and powerful enough the chef will prepare exactly what you want and the waiter will be very attentive.
Realistically if you're the VC this is what will happen, shouldn't happen for the rest of us.
We can't afford it!
Currently we have a free for all. This causes problems (eg the recent Calendar/Blackberry problem). Instead we want two approaches:
1. Set menu for UOB owned devices.
2. Pick-and-mix (for student and employee owned devices only).
A couple of years ago we did have the set menu, but found that it was unsustainable with current resources. We will need to invest resources to make the set menu strategy work, and kept up to date.
Currently too many people demand concierge levels of service for non-standard devices. If we have a standard we can offer them, plus the strictures of Process Review (the current appetite in the university to standardise and be more dirigiste) then we can overcome this.
Having thought about people, devices and support, now we will move on to talk about how we design services to be mobile accessible.
Old approach: we built a service that only works onsite.
Think about fileservers for example. That was fine - at the time it was what we wanted. Then we realise we need people to work off campus, so we bolt-on a VPN to provide remote access. Problem is that the VPN is an awkward bolt-on - it's an extra step, doesn't always work, and gets in the way. Won't work from your phone for example.
It is like this unfortunate Georgian House: ugly double glazing and an inappropriate shop front tacked on.
A better approach is to build in energy efficiency in the design for a new house. Similarly it is better and easier to build in mobile from the start than retrofit it later. So moving forward, a new approach: we design in mobile from the ground up in each new service.
The mobile market is segmented and changing rapidly. Nobody knows what the long-term dominant platform will be. We must have the ability to support multiple platforms, and switch vendors.
It is essential to use the native applications, and they must understand the data. For example your phone must 'know' what time a calendar appointment is so it can vibrate in your pocket to remind you. You don't want to connect from your phone to a terminal server to view your calendar - the experience would be horrible, and it wouldn't do what it needs to. The key to this is to make data available in interoperable standards.
Please think about these every time you design a new service:
Examples of poor mobile services:
(NB: simply saying a standard is open standard doesn't make it a good choice. Sometimes an open standard is a poor choice because it isn't deployed widely, I'm planning a separate presentation on that)
Web apps built-in to the portal, accessed from any computer with any web browser.
Data in standard formats that can be accessed in the native apps on any mobile platform.