Sunday 1 March 2015

SaaS and the Technical Refresh

For a school undergoing a technical refresh a SaaS approach has a number of advantages over the traditional model. This becomes clear when you examine some of the common problems encountered delivering a traditional solution and how SaaS solves these issues.

Definition.

Traditional: The traditional approach relies on a standard cycle of meetings, telephone conversations and emails between internal groups and vendors to capture define the requirements and translate them into a formal quote. There is very little structure or continuity to the process and detail is lost in the translation between the the teaching staff, on-site ICT team and the vendor.

In the early stages there is rarely any transparency in the costs and customer often ends up specifying a solution which they subsequently find to be outside their budget and the cycle has to be repeated. There is almost no chance to ‘try before you buy’ and items are ordered in blind faith or on a recommendation from third party that doesn't fully understand the local requirement.


Lastly the service has to be signed off against an final cost which may include a combination of hardware, software and professional services (support/installation/maintenance) all of which makes budget projection going forward very different.  Because of hardware constraints some vendors have break points in the pricing which can make moving between 500 and 501 users an expensive operation. Software sold in licences blocks has a similar effect.

If on-premise hardware is required you can guarantee that at some point this will be out of support, incurring an additional cost which is rarely factored in at the start of the project.

To recover the investment made by the vendor in this inefficient process, traditional services often come with a fixed term contract  - the shortest term commonly being one year locking in the customer in without options for change.

 SaaS: Delivery of a SaaS solution works in an entirely different manner. In a fully developed SaaS model the customer experience will be almost entirely self-service. Costs will be presented as a subscription items with many vendors offering a "freemium" service to trial the service. In addition SaaS services do not require a long term commitment and work with a shorter billing period of one month.

Services are normally itemized as a per unit cost with additional features built into a premium offering.  The ideal metric for a school would be per-pupil costs to allow them to easy estimate costs against a revenue model. The base costs is often kept as low as possible (preferably zero or hidden) to reduce the barrier to entry.

With SaaS the customer should be able to identify the majority of the solution with a with a good idea of ongoing costs before any engagement at a formal level. Everything is organised to encourage trial and experimentation which leads to a completely different management model.



Delivery and Management.

Traditional: The standard management approach to software in schools is to support a fixed set of titles classified as a "software catalogue".  The catalogue defines the all the titles that are either pre-installed into the base image or deployed across the network through supporting systems such as Active Directory.

Because of the high value of the many of the packages and the fact that the licences are non-returnable the teaching team are not encouraged to experiment and may not even have the rights to install software locally. Deployment is normally managed through the ICT team whose principle responsibility of maintain a secure robust environment for teaching - a requirement that runs counter to an the type of exploratory approach which is likely to drive innovation.


SaaS: The ‘software on demand’ model does not require a rigid software catalogue in the same way that a traditional model does. Once the majority of end user devices are using Chromebooks, Android tablets or iPads, local applications can be provided through a ‘store’ mechanism rather than packaged through Active Directory or baked into a base image. Depending on the individual workflow adopted by the school, teacher and student will be able to install and uninstall software on demand from a very much larger menu of titles under overall control of an Mobile Device Manager (MDM).

In addition to locally installed apps SaaS now contributes directly to the range and nature of curriculum software and in many cases there is no barrier to adoption to these titles They they are often free or provide trial periods and have little dependency on the local hardware. The combination of the two factors means that the whole concept of a software catalogue is largely outdated as there is nothing preventing the staff or admin team simply selecting the tool which is best suited to the task either from the vendor ‘store’ or from a SaaS provider. In many cases the new facility is merged with their profile as part of the cloud service, to be accessed as required. Swapping out one device for another delivers exactly the same service profile completely negating the need for a ‘device image’.


SaaS as an Enabler.

Its clear that there is move away from locally installed monolithic software suites. In the future tasks will be achieved using a combination of smaller applets, sometimes web based - others installed local. This software set will be very fluid with applets and SaaS being merged and reformed to meet personal tastes and fashions.

SaaS may have even have an impact on how subject are taught.

Consider the following scenario. Is it worth investing in non-refundable licences for software suites that are currently undergoing radically change as they move to SaaS delivery model?

Which has more value, teaching a student how to do graphics layering in a specific product such as Photoshop or a general approach to the concept of layering that can be applied to a range of applications? In this period of rapid change is it  likely that a student will even recognize a software product in the workplace they were introduced to three years ago in school?

In conclusion the model of software being distributed by a local ICT team through a base image or a tool such as Active Directory Group Policy has been superseded by the concept of a vendor ‘store’ and SaaS managed by an MDM. Users have realized that by using SaaS they don't actually needed an ICT team to distribute and install software and unless their requirements are fulfilled by a more flexible system the standard delivery model will be simply bypassed.

No comments:

Post a Comment