In this webinar, James Duncan of Sheridan College, Ontario discusses their decision to purchase AppsAnwyhere, their implementation process and the benefits it has had on IT and their ability to realize key strategic goals.

Watch the webinar & read the transcription below to learn about how Sheridan delivers 100% of applications on-demand to over 20,000 students. James also discusses the effect AppsAnywhere has had upon reducing costs by offloading superfluous desktop virtualization solutions and upon improving the student experience by delivering all applications through a single 'pane of glass'.


Webinar recording

Webinar transcription

Phil Spitze:

All right. Good day and welcome everybody. Before we get started just a couple of points to note. This webinar is being recorded, and a sharing link will be distributed after the processing has been completed. So, you can share that among your coworkers who weren't able to attend. Also, we will be taking a few questions at the end so please use the Q&A or questions panel that you'll see there to submit any questions that you might have.

All right. Well, thanks so much for joining us today. My name is Phil Spitze and I am the Account Management Director for North America here at AppsAnywhere. My goal id to ensure that our customers are satisfied and successful with their use of AppsAnywhere.

For today's webinar, I am pleased to welcome James Duncan from Sheridan College in Ontario, Canada, to share their AppsAnywhere story. As Sheridan College's Director of Information and Communication Technology, James works with a talented team that is responsible for the strategic delivery of IT infrastructure services. The ICT team is currently focused on transformative projects that align to Sheridan's 2024 strategic plan, and that includes digital optimization, Cloud computing, and classroom and learning space initiatives.

I've had the distinct pleasure of working with James and the whole Sheridan team from day one, and I am super excited for you to hear about their journey to AppsAnywhere. So, without further delay James I will turn it over to you.

James Duncan:

All right. Thanks Phil. Thanks for the introduction and welcome everybody. I think everybody should be able to see my screen, Phil if you could just confirm?

Phil Spitze:

We've got it.

James Duncan:

All right. Wonderful. So, today I'm going to share a little bit of our journey obviously with AppsAnywhere with AppsAnywhere. We've had a very kind of long and in some ways maybe tortuous road around BYOD specifically in our academic programs. So, really I'm going to speak a little bit to our journey, some of the things we've tried over the years, where we've had some successes, and areas where perhaps we haven't, and we ended up at AppsAnywhere as a solution for some of the challenges we do have in place, or used to have in place.

So, first just a little bit of context. So, for those that aren't familiar, and I think I do see a few familiar names from the Ontario higher ed area in the meeting. But, Sheridan is a college in the greater Toronto area, west end of GTA. We've got campuses in Mississauga, and Brampton, and in Oakville. We're predominately known as an arts college. We do have a lot of graduates that are hired out into animation studios and art studios as far as away as California. They come and poach our students from Disney Pixar, things like that.

But, we're also known for our business programs, for technology programs. Most of the programs do have a technology component to them. They are technology-rich and well-integrated. So, we'll talk in a little bit about how that changes the requirements for end-user computing environment.

But, we've got about 23,000 full-time students, 3,800 part-time, 17,000 continuing ed students. So, we are one of the larger colleges. One of the top three or four in the greater Toronto area and Ontario. So, we do operate at a fair scale. We have a certain scale and complexity to the things we do. So, that has created some interesting challenges for us over the years. We have 3,700 employees as well. So, a relatively large environment, certainly for our area.

So, our computing environment. We've got about 1,800 Windows desktops. About 1,000 of those are academic desktops. So, we're talking full desktops in the learning commons areas, open access computing environments, as well as dedicated scheduled labs. We've got about 800 administrative desktops. So, those are kind of the dedicated desktops. We've got about 1,700 Windows laptops that are in use by faculty and staff. So, that's a one to one relationship.

We also have, and we're going to talk quite a bit through the presentation about our BDI environment, but we've got about 800 zero clients, so thin clients that are distributed across our campus that people use to access computing environments, Windows desktops, applications.

We have about 130 applications or so. The number fluctuates quite a lot, but we've got 130 applications that our end-user computing team supports across the organization.

So, let's talk about our BYOD program. So, we were very early into the space of integrating laptops into our curriculum. Back in 1998 we started what we called back then, well we still call it to a degree the Mobile Computing Program. It's a little bit of an asynchronous name these days, but what that essentially means is we've got 9,000 students, 51 programs that require a laptop as part of the curriculum. So, students are required to bring a laptop into the program as the learning that they do in the classroom space is dependent on the fact that they bring a device into the environment.

So, when we first started that we actually gave them the laptop. That was something that Sheridan we procured the laptop, we developed the image, we integrated the applications, we handed them a well-managed end to end experience managed device that obviously from an IT perspective was quite eutopic. We had complete control over the environment. Certainly, from a technology user experience perspective, it was quite good. We were able to manage the experience very well, and we'll talk in the next slide that evolved over time to a different model.

We moved away from provisioning devices and handing them to the student to varying models where students would own the laptop. They'd lease it from us and they could buy it out to the end. At the end, we kind of gave them the laptop. And now we've moved entirely into a Bring Your Own Device model. So, that started probably the better part of 10 years ago I think at this point. We basically moved to the model, we gave them the requirements for their program in terms of what type of device they need to bring in, whether it's Windows or Mac, what are the specifications, they'd get all of the specifications, they go out on their own, they buy the laptop, they bring it into the environment.

Another interesting thing that probably that might be fairly unique to us, although I'm sure some other institutions have a preponderance of Mac OS as well, but being an arts college we do have quite a lot of Mac devices. We've got probably about 20% of our programs are mobile programs are Mac OS only, meaning that they must bring a Mac OS device into the environment, so that created some additional complexity for us in terms of how we deliver applications.

So, about 80% are Windows. We do have some that are actually hybrid. So, we've got programs that they can bring either Windows or Mac OS, and predominately that's because the software that they need to use might be things like Office, Adobe, things like that that are fairly standard across both platforms.

The interesting kind of tag line at the initiative when we started it was what we were aiming for was kind of anywhere, any device, any time access to applications or resources. Part of the reason for integrating the laptop into the curriculum is we didn't want learning to stop at the edge of the classroom. We didn't want students to come into the environment, do their work in a lab, and then exit and essentially stop their learning experience. We wanted them to be able to take the device with them to be able to continue certainly their work on projects and things like that out of the classroom space and have some more flexibility, but we were trying to build a whole, and largely successful, build a whole program of capabilities around mobile computing where they could collaborate, and communicate, and work on team projects and things like that outside the classroom.

So, mobile BYOD, the advantages and disadvantages. So, when we moved to the BYOD model, this actually started as kind of a petition to the President of the college. While they had a good user experience in the sense that we controlled the environment, we knew the applications worked, it was very seamless, the perception was the students were not getting the full value out of the device, they wanted to have more choice in the device that they used, and they certainly wanted to be able to own the device at the end of the program.

So, we moved more towards the BYOD model. We gave them the specs, they'd go out and procure their own hardware. The challenges that created for us obviously as an IT organization was that we no longer were working with a known consistent environment. We had people that were bringing in different hardware platforms, different operating systems in some cases. I think in fact we have students in Windows programs that show up regularly with Mac devices, and vice versa, so that's always an interesting challenge, and again, we're going to talk about that a little bit.

We had some complexity in managing software licensing. As I'm sure most people are aware there are some pieces of software that must run on college owned devices, so there was some complexity there. We also had the introduction of the problem that now that the students walk out the door with the hardware at the end of their time with us they aren't necessarily able to keep the licensing of the software that was part of their curriculum. So, how do we manage that? That became a complex thing for us to manage over time.

I touched on the software deployment challenges, but again, we've got people coming in with different hardware, different versions of Windows, entirely different versions, and in some cases different localizations. Like a lot of colleges and universities in Ontario, and certainly across North America, we have a large international student contingent. So, we have people showing up all sorts of different language localizations, things like that, that made application deployment very challenging.

And, you know, last but not least, we've got programs that range from diploma programs that are three year programs, two to three year programs, to we are a degree granting institution so we have folks that are here for four years, potentially even longer if they move into from a diploma to a degree program.

So, the specifications that they may have bought in year one, how do we ensure they're still adequate for the learning that they're doing in year three or four, or even beyond. So, you know, the ability to be able to abstract out some of the computing requirements from the hardware that they're bringing in. We have to make sure that there is some continuity there.

Overall, while a net positive for the student, you know, they now have greater choice, they have ownership over the machine, its created us quite a lot of challenges in terms of support and bringing a consistent user experience to the clients over time.

So, of course in trying to solve this we've tried a few different things over the years. We built a custom developed application delivery system. We did our best to integrate in license management solutions so that we could key up the software and be able to control it remotely. That was integrated in. We tried to develop something that was integrated with our previous portal environment where students could pull down the software specific to their curriculum and install it. That was very much dependent on packaging software, kind of an old legacy method. We've tried different things over the years to virtualize software. It was integrated with a portal environment that coincidentally we are retiring and replacing with something more modernized. So, the retirement of that portal environment meant we had to find a new application delivery solution. Strategically we decided we were not going to continue the path of custom developing something.

A lot of our apps were accessed through third party portals. So, Microsoft, whether it's Office 365, the Pro Plus, or whether it's through the IMAGINE program for some of the [academic 00:12:12] and research programs, or Adobe, and things like that. We had a lot of third party portals that people were accessing and they weren't all collected in one place. We didn't have a way of patching applications after install so that created us some management issues over time in terms of being able to provide a secure environment, and kind of not least importantly they had to be on site to install the apps. So, again, if we're trying to aim towards any time, anywhere access to applications, the fact that they had to be on campus to install the apps, and even in some cases use the applications really was not a great user experience.

So, our first and kind of foremost cut was trying to build this custom app portal. That worked to a point, although in more recent times we've seen issues with the OS platforms, particularly Windows 10 Creator Update and Microsoft Edge's browser broke a lot of the custom things that we did. We moved more towards trying to use application virtualization solutions to abstract the application away from the underlying OS. We've tried VMware Thin App, we tried [AppThee 00:13:21], quite a number of years ago we tried a product called [Moka5 00:13:24], which not VDI, it relied on VMware Work Station, but it was a way of trying to stream a consistent desktop environment back to the student. That didn't work very well. We piloted it and frankly it didn't meet our needs in several respects.

So, you know, this is the environment we lived in for a good period of time. We did the best we could to maintain this custom portal, to deliver applications, to deal with a lot of the problematic academic applications that don't deploy well. We've got a lot of interesting, I think I'll say, applications that are integrated into programs that are really not meant for enterprise software delivery. Things that align to, say, pharmacy or nursing programs, dentist environments, things like that, that are really intended to be installed on a handful of machines in a very manual process, so it was a real struggle for us to deliver a lot of those apps.

So, that brought us to VDI as a potential solution. Back in 2012 we started piloting and then very quickly moved into full production of desktop virtualization as a solution for a number of different use cases, not least of which was our BYOD, what we call our Mobile Computing Environment.

So, we looked at VDI in a number of different scenarios, one was the mobile computing environment. The goal there really was to get back to a consistent environment. To be able to deliver a known, managed, consistent desktop experience for our students and our faculty, particularly for the programs that have very complex software requirements or otherwise were very restricted in terms of licensing or the hardware they could run off, things like that.

So, we started moving a lot of our more complicated to support programs into VDI pools. So, they were given basically a full virtual desktop with all of their software built into it.

Other use cases that we used with VDI was distance education. So, you know, VDI did open up an opportunity for us. We were able to deliver courses, curriculum at a distance for folks that otherwise maybe would not have been able to attend those courses. So, we were able to teach things like Microsoft Office, and project management, and things like that remotely. They would access the VDI environment to be able to get the software somewhat because of licensing restrictions and other reasons we couldn't do that through other means, we couldn't deploy the software directly to the home machine, or for other reasons that was difficult to support.

And then, in terms of our physical desktop environment, academic administrative computing, we moved some of our what you would call task worker level people over to virtual desktops using zero clients for access. So, on the administrative side we probably have on the order of a couple of hundred folks who are now accessing VDI through that environment. In the academic environment for the very general purpose labs, and certainly our open access learning commons we've moved them over to zero clients, and that was partially to solve the issue of support in terms of customized images and things like that, but partly created a lot of operational support efficiencies for us.

I would say that the VDI environment has been largely successful for us. We certainly realized a lot of the major goals that we had with it. We've grown the environment over time to at peak around 1,600 concurrent users who use the environment. So, that's a mix of all of the four different use cases we have on zero clients.

We've tried to standardize the pools as much as possible. We're down to about 10 desktop pools for all use cases. That's quite a bit lower than it was, and largely thanks to AppsAnywhere and we'll talk about that in a bit.

But, as you can imagine there are some opportunities to improve over the VDI experience. While it was very good for the time the, particularly for these use cases, mobile computing and distance ed, there's a very high overall total cost of ownership of delivering that as a solution. The backend infrastructure, the full virtual desktop, the licensing, the percentage of the backend infrastructure, the hardware that's involved. At the end of the day the cost per student of delivering this as an experience was kind of far from ideal. It's a very complicated environment to support. On the next slide I'm going to show you very quickly what the VDI looked for us, but at the end of the day it's an extremely complicated way to solve what truly is actually a fairly simple challenge.

From a user experience perspective what students actually need is their applications. It's fairly confusing and far from ideal if they're accessing a second desktop just to get access to a handful of applications. And, of course, in order to use the VDI environment people have to be online. There's no such thing as offline access to the VDI environment and so that created a number of challenges for some of the students that were looking to work from fairly remote locations and things like that.

From the other two use case perspectives, the desktops and the academic computing and administrative computing environment, we did have at the outset a lot of custom pools with software built into it. So, again, looking to kind of abstract that back a little bit to common singular pools over time. So, that's something we were trying to address through the project, the AppsAnywhere project.

We had a lot of the similar issues with the physical lab machines. We had very dedicated images. So, we've got a lot of spaces on our campuses even today, we're working towards streamlining this, but some programs that require physical hardware, or physical software rather, have to be scheduled into specific rooms. That room has a set of machines that have the software built into it, and that creates very hard scheduling constraints for the OTR, the Office of the Registrar, which really means we're not using our space to the most flexible degree possible. So, we're really looking to address that over time and abstract that back away again. VDI was a method of trying to do that, but VDI doesn't work for all use cases. We certainly have some very, most of the labs that we have that are dedicated are dedicated because they use very specialized software. In a lot of cases very specialized software means fairly high end requirements. They might CAD-CAM labs, they might be otherwise graphic intensive. So, virtualizing those was something we never really did from a cost perspective. The TCO of doing VDI versus physical desktops in this space just didn't pan out so we still have a lot of those hard scheduled spaces that we're dealing with.

So, just for a little context, this is the VDI environment at Sheridan, and I am certainly not going to describe or get into any depth, but suffice to say the message I'm trying to send here is that the VDI environment that we're using to support some of these use cases is extremely complicated. Again, it works well, its been very stable for us, it took quite a lot of effort to stand this up and get it running. At the end of the day, for at least the two use cases, distance and the mobile computing this is quite overkill, and in a lot of ways very expensive. So, we're looking to reduce TCO of the VDI environment over time.

So, that's what brought us to the need to do something different than we were doing. We came back a couple of years ago, about a year and a half ago, again, with the impetus of the portal environment being refreshed, with that driving a need to do something different around software delivery with us approaching the kind of second iteration of our VDI environment. We operationally lease all of our hardware so we were coming up to a very major refresh of that environment. We realized we had an inflection point to revisit how we were delivering software.

So, we sat down as a project team and we kind of went through and decided what the goals we were trying to realize through the project would be. This is the core goals that we came up to.

We were trying to move towards a more flexible kind of familiar app store experience. Of course the experience that most of our students come into our environment with is more of a commodity IT experience. Enterprise IT in some ways is very behind commoditized consumer IT, so if we could move to more of an app store like experience, something that was familiar to people, then the adoption and the user experience of that would certainly be much more positive than what we had done before.

We were trying to consolidate all of these disparate sources for our software access, the Adobe, the Microsoft, the on the hub, you know, all of the different things that we had spread across the organization that were very confusing for students to navigate and find the software required for the curriculum. So, to try and consolidate all of that was important.

We were looking to reduce the total cost of ownership of our VDI environment. Again, coming up to the hardware refresh it was important for us to look for opportunities to trim that cost back and reapply in ways that was offering more value to the organization.

We are trying to move away from the specialized labs. Again, where we don't have people hard scheduled into a particular room because that room has the software they need.

We're also trying to increase our understanding of how software is used around the organization. So, we have, like I said, about 130 software titles. A lot of those, some of those are site licensed, some of them are very specific to programs. In some cases that software is used by multiple programs or departments. So, we don't have today a very good visibility into how the software is being used so when it comes to renewals we don't necessarily have all of the information we need to make data driven decisions around how to rightsize the renewals for the licensing.

We wanted a more robust application packaging than we had before. We were using a variety of different methods. Again, application virtualization, MSIs, dropping straight UXEs. If you named it we probably tried it, and in someways we were running it right up until the point we got into Cloudpaging with AppsAnywhere. So, it became very complex for us to reach into the toolkit every time and figure out what would be the best way to deliver an application. It became a lot of trial and error of trying what we thought was the best method, only to realize it didn't pan out very well and try something alternate. So, we were trying to get to something where we had one packaging or delivery method for applications to our students, staff, faculty.

And the last kind of goal that we're still working on realizing is cross-platform application access. So, I kind of hinted earlier we've got some folks that come into our mobile programs that are, you know, for instance Windows programs, but they show up with Mac OS. That's problematic in a lot of ways, but even beyond that, just strategically we really do want to get to any device, any time, anywhere access. So, we really don't want students to have to care about the type of hardware they come in with, or even the type of platform they come in with. We want to be able to provide applications to them regardless of the environment and the hardware that they're coming into the environment with.

So, the scope and the timelines of our project. As a project scope method, as a project approach, we looked at four major things that we wanted to bring in scope for the project. We wanted to do all of the administrative apps on all of our managed devices, so all of the desktops and laptops that our staff and faculty use. We wanted to bring into scope all of the academic applications on all of our managed devices. So, again, all of the lab machines whether they were VDI or virtual desktop environments.

And then, as much as possible, start to migrate all of the academic applications that were in VDI before and bring them back into this environment. At the outset we talked a lot about how to phase this, or whether we should phase this, and then talking to some other colleagues, we had other colleges and universities that approached AppsAnywhere. Some of them took the approach of phasing it. We elected that we were going to do everything together, all of these use cases together. We found there were certain complexities in terms of everything from communication strategy, to deployment in technology, to mix the environment. To have some folks accessing software via older methods that had to be migrated, as well as folks that would be on the new platform. So, we decided from a complexity point of view it would be better and we could manage it effectively to do it all as one project and one group.

The other driver we had obviously was the retirement of the portal environment and some current breakages we had in our previous system, [inaudible 00:26:04] things like that that really drove us to take maybe a little more aggressive approach in the timing.

So, the approach we took is obviously we did an RFP. We developed that around December 2017 to somewhere in January 2018. It was released and awarded in March of 2018. The kickoff with AppsAnywhere was around April 2018, and effectively by the end of the Summer, by August we were complete. We had gone through, we had built the product QA environments, and I say "we", this was really a managed service on the part of AppsAnywhere, the build. The really nice thing is we compare this to complexity of the VDI environment, although we worked with a partner, that complexity, a lot of it sits on us. The nice thing about the AppsAnywhere environment is it really is a managed service from AppsAnywhere. We didn't have to build the product QA environments. They did that for us.

They came in, they did a lot of training all of the folks who were managing the apps through to the deployment team, the folks that would be packaging and testing the applications. We've got I think at this point four or five folks that are trained and certified on application packaging and Cloudpaging. So, that went all through the Summer.

And then, we took all 130 of those apps, and repackaged them, worked with our stakeholders for testing and sign off, worked through our communication strategy, and with the exception of a handful of administrative apps were live in September of 2018. I'm not going to suggest it wasn't quite a lot of work. For about three or four of our folks this was really their life for about four or five months. They were not working on much else other than the project. But, I would say its probably been one of the most successful [inaudible 00:27:44] we've done in a number of years. Given the complexity of what we're doing, the number of people it touched, the sheer impact on the overall computing environment, it was quite a project, and, again, really successfully. Really pleased with how it came out.

So, going back to our project goals. I just want to talk a little bit about the before and after of how we achieved and where we are today. So, if we go back and we talk about how we were looking to build a familiar app store experience. So, the previous experience, I was looking for a screenshot but I couldn't dig one out because, again, we retired it this last year, but it's about the worst UI possible that you could think of. It literally is a webpage with a long page of links. It's not pretty. There was no way to filter or sort it. It was a long list of applications that had no context to the user, their environment. You know, they could be logging into the webpage from a Mac but it still would be showing them Windows software. In some cases it show them software that they weren't actually able to run and install effectively. So, you know, it was really not a great UI, but also it had no integration with our VDI environment. It had no awareness or knowledge to the fact that some of the applications that students would be accessing would be done through VDI.

Contrast that to the AppsAnywhere portal, again, a very familiar UI. You're able to filter, search, and favorite. Our VDI environment is integrated into it, even though we're definitely hitting a lot of the use cases for VDI. For the folks that still use VDI today they find their desktops through the environment and launch them there. So, there is that kind of tight integration.

And, again, context is important. When students sign in they see in the available list the apps they have access to, whether it's them as a user, the ones that are assigned to them, or there are general access, the ones that they can run from their device platforms. So, for instance if they're on Windows they don't see the Mac software, and if there is any location restriction it has an awareness of whether their onsite/offsite, and sorts things accordingly.

That said, students can see the software they don't have access to, and the reason they don't have access to it, but as you can see here it's kind of very familiar app store experience. Up here in the upper bar there you can see, I did this from a Mac and I'm an admin user so I don't have all of the academic software. So, I see 26 apps available to me, 67 that are unavailable for a variety of reasons, in some cases because, again, I'm running a Mac. They may be Windows software, or they might be unavailable because I don't have access to them for some reason. So, it's a dramatic difference in terms of UI from where we were coming from. Truly.

Consolidating the disparate portals. Even though we still launched in some cases to things like Office 365 for pulling down the Pro Plus Office, there is one place that they start the experience from, which was very different from before. Students would have to navigate through our IT website and find, you know, a piece of software that was available through On the Hub, or through Office 365, or the Adobe portal, or through our previous portal access at Sheridan.

So, they would have to navigate and sort that through. Now, they go to AppsAnywhere, they find the icon for their application that they want to install or run, and it takes them to the correct place appropriately if they have to install it, otherwise it runs it or streams it down directly.

As I mentioned, it is a gateway to access the VDI pools so, again, we don't have to point people to the different locations to grab the horizon client to access their VDI. They go to AppsAnywhere, they click on their pool, and then it'll either install the software for them or it will stream to the desktop directly. So, it really went a long way in reducing a lot of the confusion we had in our clients in terms of how they get access to the software they need for their business or their curriculum.

The TCO of the desktop environment. So, we've reduced the use of VDI for our BYOD mobile programs by 50%, that's still growing. We still have some pools that we're working through with some of the faculty in some of the programs in terms of transitioning them over, the testing, the sign off, but we're about 50% less use of VDI than we were at the outset, so that freed up some capacity that we could use for things like desktop replacements, things like that, that are more relevant than VDI, a better experience than VDI.

We also had some cost avoidance. We had actually planned to expand the VDI environment, again, at the outset, and that would be, again, to encompass a lot of the BYOD use cases that were increasingly problematic that we were going to have to pull into VDI. So, the budget that we had planned to expand on that expansion we spent on AppsAnywhere instead. So, we basically kind of deferred the cost of the VDI environment and applied it basically to a solution that was a better experience overall.

What this also gives us is the next interval, it's the opportunity to even downsize the VDI environment further. Again, we've still got probably 50% of the BYOD usage in VDI that we're looking to retire. To me the goal is 0. I don't believe at this point there is any reason or any use cases to run any of the BYOD use cases out of VDI. I think at this point it's really just the change management component of working with the faculty, and the programs, and understanding what it will take to effectively transition them over in a way that they show confidence and support in. So, when we get to 0, again, we'll have a much smaller need for VDI even than we have today.

Migrating away from specialized labs. To be frank this is still kind of a work in progress. We do have some specialized labs that are scheduled. We do have cases where we have physical labs with very specific tech and requirements, things like that, that they have a very specific system center task sequence associated. They get Windows, they get that software, and then the scheduling office has to be aware that the specific programs have to go into those rooms.

So, we're looking to get away from that. We've done it in some cases. I didn't have hard numbers ready for the presentation, but we've been successful in migrating some of those labs away. Again, we're looking to get back to 0. Don't know how close we will get, but I think we can get very close to be honest. I think with Cloudpaging, and streaming the applications down through the portal, I think we can get to a level where the hardware might be a little more custom in some spaces to run graphics applications, but realistically we can run a lot more of our curriculum out of any lab environment rather than specific rooms.

We've been undertaking an exercise to do master planning for all of our campuses and understand space utilization, and how do we more effectively use space. I'm sure we're not alone in the fact that we never quite have enough space whether it's for administrative, and meeting rooms, and office space, or even scheduling classes. We're always short on space. Anecdotally we think there's a lot of hard constraints around scheduling that de-optimize the process a lot. So, if we can get to a more flexible classroom delivery model where frequently they can by and large be scheduled fairly freely that will really help with those issues that we've had over the years.

Getting to the reporting capabilities. So, this is one of the things at the outset when we procured AppsAnywhere that we were really excited about and we were really happy to see that there has been a lot of continual improvement and development, particularly in version 2-7. There's a lot of good analytics capabilities around software utilization that's really going to have a really good, strong benefit for our software asset team. We've got a couple of folks in IT that really live and manage software and hardware asset management, and they're responsible for a lot of the renewals, and the sizing around the renewals, and today they are in a lot of ways very challenged to understand the utilization patterns of the software, how they're used can kind of ebb and flow through the year, and certainly whether or not we're sizing the renewals to the right level.

We think there's a lot of good recovery here that we can do in terms of cost over time. Two scenarios that we're looking at is we probably have some licensing that is oversized, and that might be for historical reasons, it might be a lot of licensing that's concurrency based. We have to make certain assumptions in the planning at the outset around how many people would be using the software at any given point in time so we may have oversized that in some ways to be safe. So, now we'll be able to get to a level where we've got reporting capabilities to understand peak utilization for that and kind of size things down accordingly.

The other scenario we've got is, you know, we've got some programs and departments that use the same software and procure their own licensing, and we manage that licensing, but we don't necessarily have visibility into how all of the different areas use the licensing. So, we think there is some opportunity to pool all of that licensing together and kind of size down those different silos accordingly.

So, we didn't do a lot in the business case for going into AppsAnywhere. We didn't have a lot of numbers to kind of suggest what the cost recovery might look like, but we really do believe strongly that over time with the analytics capabilities that we're really going to be able to realize some savings in our licensing.

Robust application packaging system, again, was one of our goals. I kind of mentioned the toolbox approach that we had before. We had things like Wise Packaging Studio to do packaged software into MSIs. We shipped to EXEs. We tried application virtualization solutions like Thin App, and Hyper-V, I didn't put Moka5 in here, but that was another potential solution we had at one point, but every time we packaged an application, again, it was this methodology of "We think it's going to work best as an MSI." Or, "We think it's going to work best as a Thin App." We'd try that, we'd test it, we'd discover some issues potentially, and then we'd go back and we'd try something else. You can understand the inefficiency of that obviously for the technical folks doing the work.

So, what we strode to get towards was one solution that worked anywhere. We actually thought that was kind of a unicorn thing. We didn't think we were going to get there. We had certainly been promised that from VMware for Thin App, and Hyper-V, that this virtualization stack would allow us to get to one way to package and deliver software. We were skeptical at the outset and we've been really pleasantly surprised with Cloudpaging in a lot of ways. I think at this point 100% of everything we've tried to package through Cloudpaging we've done successfully. If we're not using Cloudpaging it's not because we don't intend to, it's just because we haven't gotten there yet. So, at this point we truly haven't found anything we can't do with Cloudpaging. I would say if you were to compare it to say Thin App where probably 75% of what we wanted to do with Thin App we could, leaving 25% behind. Everything we've tried at this point with Cloudpaging has been successful.

There's a really good community around Cloudpaging as well, so I know that the guys are really active on the forums in terms of sharing recipes and things like that, pointing out recipes for other work that other people have done in paging. That really was helpful in us streamlining the work that we did last Summer to package those 130 apps and get them ready for delivery. I think a lot of the work and the research that those guys might have had to do was done for them. So, that was extremely helpful.

Looking backwards, one thing I would do differently if I did it today is, it wasn't available at the time, but AppsAnywhere has a software packaging service now, and I think to some degree to jumpstart that project and really get that moving along quicker with a lot less pressure on the team I would have leveraged that to a much greater degree, and probably still will going forward, but it would have been really, really helpful for the deployment.

And then, last but not least was providing this groundwork for cross-platform application access. So, I mentioned a lot about VDI, the other thing I haven't touched on is we bootcamp a lot of machines today. For students that bring Mac OS into the environment where they need to run Windows apps, or in a couple of very specific cases, we actually have programs that require both Mac and Windows. They have software requirements for things that will only run on Mac, and also software that only runs on Windows.

So, for them we bootcamp them. If the requirements are more leaning towards that, or if they can be done in VDI we were. What we're looking towards doing, and we're just kind of starting together folks for a pilot is move towards Parallels RAS, or something very similar, to be able to stream the application off a RAS server through, again, access through AppsAnywhere so that folks that are coming into the environment with Mac can run Windows applications on their platform.

That will really get us, again, closer to that vision of kind of anywhere, any time, any device to access applications. Again, the goal we're really trying to get towards is that the students come into the environment with any device, in some cases, you know, as far as we're concerned iOS devices, tablets, Android, things like that would be acceptable in a pinch. We don't really care as long as they can run the apps. So, we're really trying strategically to work towards that.

Yeah. I think I just covered that off. We're really trying to get it anywhere. So, on or off-campus, that really has been a boon with AppsAnywhere. Before, I mentioned that at least to install software you had to be onsite, and again, with a lot of licensing restrictions because we couldn't control it. They had to be on campus to run some of the titles. So, that has been streamlined, and for the most part completely done away with.

For the folks that were using VDI and mobile programs, they had this constraint that they had to be online, and certainly with relatively good bandwidth to use the environment effectively. So, that's gone now. With AppsAnywhere and Cloudpaging at this point once they've done the initial download, or they've cached the application, which can be done on or off-site, they work offline for, don't know offhand the amount of time, but certainly I think it's on the order of weeks if not months before they have to check back in, for some titles at least.

A broad range of devices, whether college-owned, personal devices, different platforms, again, working towards the RAS environment, but that's really been a boon for is that now we have the capability at least to allow folks to run their apps on any platform, and at any time. Again, trying to get away from scheduled access to dedicated labs, trying to allow students and faculty the capability to do their work in the classroom and then exit and do it from somewhere else, which is what we thought was really a large part of the benefit through VDI, but obviously it had its downsides and constraints.

So, that's really the end of my content. I did just want to do one quick plug. AppsAnywhere has an annual User Day in North America, it's going to be October 22nd, 2019, and it's actually going to be held at our Mississauga campus. So, I really would like to see a lot of folks out there. Everybody is obviously really welcome to join us.

One thing I really like about AppsAnywhere is the community. Obviously a lot of the applications, a lot of the partnerships we have with vendors are very cross-vertical. It's really nice when you work with a partner that's very higher ed specific. They really understand the challenges and the opportunities of higher ed, but certainly it means the user community that we're all dealing with very similar challenges.

So, it's really nice to get everybody together once a year and share information. The one last year in Seneca was really good. So, I hope everybody can join us.

I think with that Phil I'm done and I'm ready for any questions there might be.

Phil Spitze:                         

Great. Fantastic James. Thanks so much for sharing that and your time. Really, really a great presentation. Again, folks, there is a questions panel there. If you have any questions for myself or for James please plug them in. I think the one question that I'm aware of anyway so far James is you mentioned you've got at the beginning there are three campuses in the greater Ontario area, how is the AppsAnywhere infrastructure built across those campuses, or is it all served from a single location?

James Duncan:                 

No, no, that's a great question. We've got, so our Mississauga and our Oakville campuses both have data centers in them. Very good, kind of quality data centers. So, we try to build a lot of our mission critical infrastructure to leverage both of the data centers in an active act in that kind of sense. So, certainly the VDI environment, scrolling back to that diagram, was an architect of that way. A number of our apps are. So, AppsAnywhere kind of fell into that bucket as well.

So, we've got the app portal and all of the delivery systems around Cloudpaging and everything are redundant across the two sites. We've got a replicated SQL environment should the worst occur and one of the two data centers completely burns to the ground we're still capable of provisioning and providing software out of the other location entirely.

Phil Spitze:

Cool. And just a quick followup regarding that. You showed the infrastructure diagram for the VDI environment, which obviously is quite complex. In comparison what's the AppsAnywhere infrastructure like?

James Duncan:

Well, regardless of the infrastructure, again, the nice component like I said it's managed, so it's something that AppsAnywhere does manage entirely for us. They provisioned it.

Sorry, I had a phone call coming through.

AppsAnywhere manages the entire environment for us, so the complexity in a lot of ways is very abstract to us. Certainly the initial implementation, but even subsequent upgrades you guys all handle for us. So, from that perspective frankly we're not even aware to a large degree, but from a really if you look at the architecture overall it's very simple. There's a couple of web servers on each site that really manage the portal. I believe there's just a couple of servers that handle the streaming component for Cloudpaging. They're load balanced and they both talk to a SQL server, and that's really it. It's probably about the simplest app that we would have to manage if we had to manage it.

Phil Spitze:

Cool. Okay, here's a purchasing question for you. Were you able to waiver the purchase or is this available on an existing public VOR?

James Duncan:

I'm not aware that it's available on a VOR publicly. I think I know where we're going, that we've had some direction in Ontario very recently around longer term contracts and things and such like that, so this agreement kind of predated that. We looked into kind of going into a waivering program because it is a very unique space, and to a large degree only one, or a couple of players at most in it.

That said, at the time of the conversations with procurement they really did want us to put this out to public tender, and we did, and so that's the path that we took, but I know there were, and I'm trying to remember back conversations I had with different organizations when we were drafting the RFP. I might be misquoting, but I'm thinking of George Brown, and I'm thinking of [Laurea 00:47:51], and I'm not sure if they're right or not so please don't quote me on that, but I think one or both of those went through some sort of a waiver process internally.

Phil Spitze:

Yep. And I can just confirm that we are not yet on any kind of public VOR, however if you do need to go out for an RFP to tender we've just published an RFP template on the AppsAnywhere.com website. So, there's quite a bit of a list of content there that you can pull from and kind of jumpstart building out your RFP if needed.

James Duncan:

Yep.

Phil Spitze:

Here's another question about our favorite four-letter word, Adobe. Have you addressed access licensing with Adobe Creative Cloud products through this solution given that it is user-based and no longer serial number-based?

James Duncan:

In a way. Its a very kind of custom approach. So, yes, we're on the, obviously, the user based Creative Cloud licensing as well. So, from an experience perspective when students or faculty go through AppsAnywhere they do see the individual Adobe products. If they already have them installed, you know, clicking that icon just launches the Adobe software, if they don't then what we actually have created is we've created a system where they'll click the link in AppsAnywhere, it does a call out to a webpage through single sign-on, so we've kind of assembled a single sign-on based process. It passes the user credentials through. That talks to Adobe through an API that provisions them a licensing, and then directs them to the Adobe portal to pull down their software.

So, it's not the most ideal solution for the laptop students. It would be nice if we could provision the software directly out of AppsAnywhere, but that's the solution we came to kind of claim licensing and provision the software.

That said, we've got a site license in place for all of our manages devices. So, if you're on a VDI environment, if you're on desktops the Adobe pieces are already pre-installed. So, that's done through the Adobe shared device licensing. We just migrated that a few weeks ago. So, students still need to sign into Creative Cloud on those devices, but then they have access to the software. At that point if they open up AppsAnywhere on any of the managed devices around the college and click the link they'll get the Adobe software to pop up immediately.

Phil Spitze:

And I'll just followup with from the AppsAnywhere side, the full Adobe Creative Cloud suite is available from our packaging service. All 18 apps in the suite we have already packaged with the named user license so that our customers can take advantage of that and just provision out the apps as they need to.

All right. That looks like that is it for now. If there are any other questions please don't hesitate to reach out to us here at AppsAnywhere. James has kindly provided his contact info there as well. And as always there's a ton of information on the AppsAnywhere.com website.

As always, keep an eye out for new news and events. We've got a pretty full calendar coming up through the rest of Summer and Fall, so let us know if there's anything, topics that you would like us to address and we can definitely try to get that scheduled.

Otherwise, thanks so much for joining us. Have a great rest of your day and enjoy the Summer season. Thanks everybody.

James Duncan:

Thank you everybody. Have a good day.

Learn more about Appsanywhere

Improve student outcomes by delivering a better IT service, on and off campus. Make any app available on any device, enable BYOD and repurpose your dedicated lab spaces, all without the need for complex VDI environments.

Tech Specs

Tech Specs

Technical specs for AppsAnywhere, including server infrastructure, Active Directory integration and other technical requirements.