Wednesday 29 July 2015

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.

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.

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.

No comments:

Post a Comment