Improving App Management with Google

One of the more troublesome areas of mobile device management is application distribution. This particular task has been a long standing challenge rather than a particular issue with mobile devices.

The distribution of locally installed Windows applications is seen by many as a 'black art', employing technologies such as installation packaging, application virtualization, sandboxing and any number of software suites that all claim to make the task easier. The issues surrounding app deployment in an Apple environment are equally well documented and mainly involve trying to adapt what is essentially a consumer system into something an enterprise or school can use effectively.

SaaS promises to deliver some benefits in this area. The deployment of these ‘apps’ is an easier task since most services are simply links to external websites which have few dependencies with the local platform.

Although the Apple, MS Windows and SaaS distribution models are dissimilar they all attempt to reduce the management overhead by using user groups hosted by software suites such as MS Active Directory or an MDM (Mobile Device Manager) to assign apps, rather than trying to handle multiple associations with individual user accounts.

Google G Suite for Education (GSfE) and GPfE (Google Play for Education ) provide the same group management function for schools handling a Chrome/Chromebook/Android rollout and although I've attempted to use these tools to develop a similar methodology I always seem to hit a fundamental limitation of the platform.

This is a bit worrying since thousands of schools use GSfE to deploy apps, so I can only assume they know something I don’t (which is entirely possible) or school admins are just working within these limitations. Either way it's not a good situation.

As far as I'm aware the current situation can be summarised as follows;

Within GSfE the rules that control applications are linked to units known as sub-organisations and these have two functions.

• As a container for users and/or managed devices.
• As an object that an administrator can set policies against.

This is all very well except for the one feature of sub-organisations that make them completely unsuitable for app management, namely that a user or device can only ever be in one sub-organisation.

This type of grouping works well in a simple scenario where all the pupils in a lower year require the same app but it falls apart rapidly when you consider subject sets rather than year groups.

It’s a fact of nature that a child will only ever be in one year group but he/she will be in many classes sets and GAfE does not support a one-to-many relationship with respect to sub-organisations.

What this means is you can’t create subject classes using sub-organisations in GSfE because a deployment of the type below is impossible.

Sara       History sub-organisation
Philip      History sub-organisation

Philip      French sub-organisation
Jill          French sub-organisation

Jill          Maths sub-organisation
Sara       Maths sub-organisation

Unfortunately the most useful object for application deployment is the subject class set.

The year group is has a role but you need to be able to deploy against the subject/class area especially for the older pupils. The problem is eased by free apps that you can throw about like rice at a wedding but if you purchase an expensive Chemistry app you need to be able to deploy it directly to that class  - but you can't create a Chemistry class as a sub-organisation.

A Google Group can support a one to many relationship but groups have no role in app management. Even in GPfE (Google Play for Education ) where groups make a cameo appearance it’s only as a shortcut to populate a user list. Within GPfE groups are not persistent objects for the purposes of app management.

So let’s imagine we live in an ideal world where all things are possible.  How would it work?

Well, not with a sub-organisation because it doesn't currently meet the requirement. Google Groups are better but they’re far too clunky in the way they are exposed through GSfE,

Fortunately there’s another candidate which is far better suited.

What if you could assign apps directly to a Google Classroom through GPfE or GSfE.

Behind the scenes the User -> App relationship would still be maintained but this would be hidden by a higher level Classroom -> App relationship. Even better you should be able to create an “Apps Set” a grouping of applications that you could also manage as a unit.

Open GPfE, assign an AppSet to a Google Classroom - job done till next year.

This maybe a bit fanciful but the reality is that the sub-organisation is unsuitable as a unit of management and the User-> App relationship in GPfE is unworkable at scale.

Google must know this and probably have the 'smarts' locked in a room munching jelly beans sorting it out at the moment.

If they could build on the success of Classroom and integrate the two features the result could be a show stopper.

UPDATE: 
In February 2016 Google announced that it was dropping the Google Play for Education Program.  It would be nice to think that there is an alternative strategy in the pipeline based on Classroom or at least similar to that described above. Here's hoping.

UPDATE: 
In Google I/O 2016 Google announced that the Google Play store will be accessible on a Chromebook and more importantly it would be able to be managed through GSfE. The upshot of all this is that Google Play for Education Program has re-emerged fully incorporated in GSfE with Android apps running on ChromeOS. Great move, but lets wait and see what that implementation look like.

Android Apps in EDU could create Angry Admins.

End of year report for BYOD.

Was Bring Your Own Device (BYOD) in schools ever a good idea?  Lets take a step back.

The year was 2010 and the web was already full of engaging educational content. The move towards anytime, anywhere learning had the potential to bring  substantial benefits to education but only if students had access to an internet friendly mobile device.

Faced with an aging estate of netbooks and laptops, a dusty old IT suite running Microsoft XP and budgetary constraints it seemed logical to address this issue by allowing students to use their personal smart phone, iPad, or tablet in the classroom. The devices were coming through the school gates anyway so why not turn a problem into an opportunity.

Schools assumed that this would lead to a proliferation of device types but believed that by creating a multi-device classroom students could work collaboratively, choosing to work with the most appropriate device and in the end it would all be well.

Although BYOD addressed the immediate problem it also served to create whole a new set of challenges mainly around the areas of compatibility, security and management and so it might be a good time to see were we are with this initiative.

The BYOD Report Card.

In all truth BYOD never had a hope of meeting the high expectations of education once the realities of the classroom set in.

I have no empirical evidence for this but most BYOD programs that I have come across simply provide the student with a school funded data plan for their smartphone and while BYOD made it to school, it never quite got into the classroom.

In the end it proved to difficult to incorporate a of set devices that supported different application sets,  screen resolutions, graphics plugins, data transfer models and wireless capabilities into a lesson plan that attempted to use the best features of each platform

There was too much temptation to work to the lowest common denominator which helped nobody.

“Could you turn on your device and those of you who have managed to get a wireless connection please go to the ‘flash free’ mobile friendly URL I’ve written on the board. Those of you with a Blackberry and a Kindle…”

A common reaction was to employ variations of the BYO-SAD model (Bring Your Own School Approved Device) which was often viewed as backdoor approach to parental contribution and ran into problems with inclusion since the 'school approved list' normally only ever contained one item - an iPad.

Even with some standardisation the problems were only just starting to emerge.

Schools often found that introducing BYOD impacted the performance their nascent wireless network. From supporting a class-set of laptops the admin suddenly had three hundred disparate devices on the network.

A software management suite became essential and what looked like a quick fix now required a wireless upgrade and the onboarding tools necessary to control access to the network in a secure manner.

But these were personal devices outside the authority of the school. How do you place them under policy control in an acceptable way without incurring a MDM licence that was never budgeted for?

In many cases the management overhead became impractical or too costly and so the grand scheme was reduced to a glorified guest network for students who, to their credit used it as a real learning resource as well as catching up with friends on Snapchat, Wikr and WhatsApp during the recess.

Unfortunately after the first e-safety concerns were raised it was found the edge security solution couldn't filter the traffic and had no way of blocking applications from devices without incurring a another management licence and the displeasure of the student body.

The cheap and easy solution suddenly wasn’t looking so cheap or so easy.

So where does that leave BYOD in 2015, pass or fail.  I think there are two ways of looking at this.

One grade card has an FAIL F-  and proposes replacing BYOD with a properly managed 1:1 programme to solve these issues. The principal driver for BYOD was cost and this has been massively reduced by the introduction of commodity devices such as Chromebooks and cheaper tablet options. We may have reached a point where the amount of time and money used to manage BYOD is fast approaching what it would take to implement a proper 1:1 Chromebook/tablet programme on a unified platform.

Other marker says PASS B- but don't try and manage it because without spending serious money on MDM licences you’re wasting your time.

If you want a ‘managed’ environment you have to control the end user device. The move towards secure encrypted communication in the last few years now means that peeking at the traffic to find out what’s going on is not going to tell you what you want to know.

Students are smart and without complete control of the user device they’ll get around any mechanism put in their way. So if you want BYOD you'll have to open it out and trust your students.

After all it's their device and they are the new masters of the digital world.