Virtualization. Applications Anyhwere. What, why, how? Nici Cooper, Wolverhampton University
•Download as PPTX, PDF•
1 like•543 views
Presenter: Nici Cooper, Assistant Director, University of Wolverhampton Overview: As part of a Digital Campus Transformational Change, Wolverhampton University aim to deploy software applications to staff and students anywhere, on-demand. With a large software portfolio and silo based structure the challenge to give better access to software was large. This presentation covers how Wolverhampton University answered the following; - How to deliver a better experience for everyone - How to address the issues of application virtualization - How to ensure a successful virtualization project Application virtualization, VDI and teamwork are highlighted within this presentation. Awesome :-) More at www.software2inc.com
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Virtualization. Applications Anyhwere. What, why, how? Nici Cooper, Wolverhampton University
Similar to Virtualization. Applications Anyhwere. What, why, how? Nici Cooper, Wolverhampton University (20)
Recently uploaded
Recently uploaded (20)
Virtualization. Applications Anyhwere. What, why, how? Nici Cooper, Wolverhampton University
- 1. Applications Anywhere what, why, how? Nici Cooper, Asst Director and PM Mat Flower, Consultant (Desktop)
- 2. A bit of context • Digital Campus Transformation Programme • One of five Foundation projects – Digital Platforms, Student Portal, VLE, Business Intelligence • High level sponsorship • First to go live
- 3. A little bit of history … • Large software portfolio • Long requirements gathering period • Multiple specialist monolithic images • Restricted access • Once per year opportunity • No link to other University processes • 70% remains unchanged
- 5. Project Objectives • Better access to software for everyone • Review and revise software management • Metrics to support decision making • Review and re-define processes • More responsive • A better experience for everyone
- 6. Not just about technology … • Six work-streams – Technology – Applications – Processes – Software and Licensing – People – Communications
- 7. Project Recipe • Plan B • Ground Rules • Buckets & Whiteboards • Teamwork • Environment • Discussion
- 16. Challenges and Lessons • Procurement • Academic Testing • Ageing PC Estate
- 17. Success?
Editor's Notes
- Good morning everyone, may I take this opportunity to say how thrilled we are to be hosting the Software 2 Customer day here at our Telford campus. I want to thank Tony for giving us the opportunity to talk about our AppJ journey. We have named our project Applications Anywhere and I’m intending to share with you what it is, why we took it on and how we have delivered it.
- To start with a bit of context might be useful … This project, Applications Anywhere, is part of a Digital Campus Transformational Change Programme, a five year, University funded programme of activities which seeks to deliver: An online environment, open to all members of the university community A digital space which supports lifelong learning and personal development A community and ecosystem that transcends traditional university boundaries The aim of the programme is to ensure the digital campus is as important as the physical campus. It is one of five high profile, big bucks Foundation projects and is a direct result of student feedback regarding access to specialist software to support teaching and learning. The first phase is to deliver Windows software to University-owned computers but ultimately we are aiming to deliver University software to any Windows device on or off campus All projects have high level sponsorship, our sponsor is the Dean of Students. Bit of a double-edged sword, it makes it a bit easier to argue for resources or push others for co-operation but it also means any failure is highly visible and undesirable Our project is the first of these five to go live
- SW Portfolio – 423 Windows applications, excluding Linux, Mac and other specialist areas such as networking and games lab areas. The portfolio increases in size each year and the images were becoming unwieldy to manage. Requirements gathering starts in February with the aim of being complete by May to enable specialist images per faculty/school to be built, tested and deployed over the summer. In reality this is rarely achieved and requirements from academics keep coming in all over the summer build period which means that the builds are ever later completing and deployment is a mad panic The students have told us very clearly that they were dissatisfied with access to specialist software and could not make use of the areas with the longest opening hours, eg the learning centres or get access to software at weekends Inflexible and means that Faculties have only one opportunity per year to request software for teaching. The summer window of opportunity for doing the builds and deploying the software is reducing year on year No link to other University processes, for example the Academic Development Process when new courses are designed and resources identified. Books and other resources needed to support modules are identified but software is never considered – this needs to change Every years we build the specialist images from scratch despite the fact that 70% of the portfolio remains unchanged year on year. Applications are rarely, if ever, retired. There can be a number of different applications to do broadly the same thing because the portfolios are based on individual academic preference and nothing is ever challenged because we have no usage data By the time we hit the new academic year the result for our staff is ….
- They have worked stupid hours including weekends, are exhausted and sometimes bad tempered and have no break before they are back into the day to day BAU.
- make Windows software applications required for teaching available to students and staff wherever and whenever they need them on a Windows device of their choice develop and deliver a solution to enable Apple users to download and install software applications to both University and personally owned Apple devices an audit and assessment of existing and new software applications for their suitability to being made available via new methods of delivery identify and understand issues around software licensing associated with the new method of delivery define and develop appropriate monitoring and reporting of software licenses define and develop processes to enable a whole lifecycle software management approach from request to deployment embed an agile, well governed, “business as usual” approach to the request, approval and delivery of specialist software review the immediate requirements and future structure of the people needed to deliver the service ensuing they are appropriately skilled and trained ensure effective and timely communication with all stakeholder groups
- As you will have seen from the objectives on the previous slide this project is not just about technology. That said the lions share of the work since the project has kicked off has been mostly about the technology, the applications and the outward communications. Technology – the identification, procurement and installation of a ‘best of breed’ solution suitable for our current computing environment. I can’t take credit for the solution, Application Jukebox had already been identified as the best solution to meet our needs before I took over the project, I’ve never doubted it but I had a devils own game to convince procurement! Applications – ensuring that applications are suitable and ready for ‘Applications Anywhere’ delivery. Words taken straight from the PID as the audience for that document would not have understood our terms of verification and packaging Process – up to this point we have focussed only on our internal processes to ensure the safe delivery of this project. Next will come work to define the processes to support transition into BAU and the development of a whole lifecycle software management approach from request through deployment to retirment Software and Licensing – An audit of our centrally managed software licenses was undertaken as a piece of pre-project activity and a case was made to a high level committee to shift the funding for software from faculties to a central pot managed by us, this received in principle agreement pending a review of the wider software lifecycle process. Future activity in this area will be around monitoring and reporting on usage which will help the faculties to refine their portfolios and hopefully identify software that can be retired People – This work-stream will seek to identify and implement a fit for purpose structure and the on-going development of appropriately skilled people. Communications – As you would expect leading up to go live there has been quite a lot of activity in this area. We have presented an overview of the project to our colleagues across our department to ensure they had awareness and could communicate the basic concepts. I have briefed colleagues with a remit for academic liaison, we had a desktop icon designed, launched a set of web pages, had a massive poster and digital screen marketing campaign and also havve a pop-up screen on all studfent computers that has a direct link to the hub and a link to the web pages.
- I’ve given you some context and a bit of history so now I want to change the focus and tell you about how we’re making it happen. These six things are the basic ingredients of our recipe for project success.
- Very early in the life of the project we made a bold decision that there would be no Plan B! We decided that we were not going to undertake specialist builds, two out of three faculties were deemed low risk and one, FSE, medium to high as this was by far the biggest portfolio. I want to make it clear that we weren’t ignoring the risk or crossing our fingers and toes that it wouldn’t happen – we acknowledged and understood it and felt that we could manage it. Our approach was that everything targeted at a managed Windows build would be attempted first through AppJ unless the validation stage had deemed this to not be appropriate, for example license, hardware restrictions or environment. Only applications with these restrictions or which otherwise proved unsuitable for virtualisation during development or testing were deployed through other methods such as scripted through Group Policy, sent live through Config Manager or as an absolute last resort as a manual install. So what did we do to make sure we delivered Plan A …
- The ground rules for this project were very simple and were set out by me at the beginning of the project: We knew we had a mountain to climb so hard work was inevitable. Having fun was not optional, and yes there were difficult times but generally our get togethers always had light hearted moments Speak Freely – this was really about trust. The team needed to feel that issues could be raised, conversations could be open and honest, people would not be blamed and we were all in this together!
- We had a sound set of processes developed over time from previous builds through from requirements gathering to development to image deployment. So we weren’t starting from scratch. We tested these by mapping out the steps that each piece of software would have to follow from when it was requested right through to when it went live. Validation step – license, technical Assigned to relevant workstream – majority were managed Windows build so to AppJ Initial dev and test with the packagers Quality Assurance – with the Desktop Engineers, issues resulted in going back to packaging, if ok External/Academic testing Deployment In the main these steps worked across all the different work-streams We wanted something that would give a simple and single view into where we were at any given point in the process. Had to be simple otherwise people would have worked round it and we would have lost our definitive view Wanted something that worked around the idea of these virtual buckets And so our Webby tool was born!, known by everyone other than me as AppDB Live demo
- For a technology project our use of whiteboards may seem archaic but our experience is that they are invaluable for: Allows us to capture things in the moment Helps to visualise complex issues and break them down step by step Manging and prioritising our issues
- Once again we claimed squatters rights on the space usually operating as the Mac deck in the main Faculty of Science & Engineering Building. Why? For a number of reasons… Firstly our normal open plan environment isn’t suitable simply because of the number of likely interruptions and there is just not enough space. We had used this space for a number of years and had proved to be an ideal environment, although the temperature during the Summer wasn’t ideal. We were able to have defined areas for the different buckets e.g. packaging, QA, testing and also enough space to to setup a comprehensive representation of our varied and in some cases vintage PC estate. Fundamentally it meant that we had the right people in the right place to enable effective communications, collaborative working and room for multiple whiteboards. The extensive supply of haribos and other sweet treats were a key ingredient in contributing to the output of the team however Nici did try and introduce fruit once….just the once.
- Relatively small but perfectly formed project team given the size of the task at hand which also included the complementary work required to deliver this years teaching portfolio. 1 (very inexperienced PM) 1 (relatively experienced) Op Lead. You will recall from one of my earlier slides our virtual buckets and alternative deployment routes – this role managed those buckets, associated dependencies and brought everything together 1 Tech Lead who had involvement in a small-scale pilot the preceding academic year and at project inception was one of the few people with experience of the packaging process 4 on our packaging team (2 internals seconded from one of the support team) working with two external packagers provided by S2. Reality was only three people packaging full-time as the fourth post was used to oversee the packaging process and deal with any resulting issues. I do want to say at this point that Matt and Andy had a difficult job being the externals and coming into a team where everyone else knew each other well, Andy had the additional challenge of working off-site for most of the time. They both coped admirably and were valued members of our team. 3 Desktop Engineers, each with specialist knowledge of the three main faculty portfolios –undertook QA, assisted with issue resolution and one because our infrastructure and provisioning specialist. They also undertook license server work, led on other deployment solutions 1 Systems Administrator – data verfiication, management of the external testing process and general liaison with academic staff, oversaw the effective running of the Operational and project meetings 1 Asset Manager – responsible for software costing, procurement and licensing. Ensuring the packagers had access to the media they needed 1 Academic Account Manager – primarily responsible for Faculty liaison and requirements gathering but not for the life of the project as her little girl decided to put in an early appearance! In addition to thast core group we had cross department contributions from a number of individuals and teams. We didn’t always agree but we could have open and frank discussions about the most appropriate way forward without people feeling they had ‘lost’ if compromise was needed.
- Effective and appropriate project team communication was key. Apps Anywhere was just one part, albeit a major part, of the work needed to deliver software for teaching. FSE lite – (Netsupport school and Virtual Linux VMs) Linux physical and virtual Networking Lab Games lab Mac build Other deployment methods when AppJ not deemed suitable Weekly Operational Meetings, chaired by the Operational lead (now forever known as the bucket manager!) everyone involved in any aspect of the summer build attended these meetings and they were a great opportunity to discuss and resolve outstanding issues. The scope was set to be seven days either side of the meeting date with an operational focus. Each meeting afforded a round robin opportunity for participants to provide updates, highlight any forthcoming absences. We also had weekly project meetings attended by a small sub-set of the team (PM, Op Lead, tech lead, Packaging lead, Asset Manager and System Administrator) these meetings focussed on the activity needed to keep the project moving forward or to focus on single issues that needed thrashing out. Daily 15 minute catch-up meetings between the packagers and the DEs with one of the external packagers who primarily worked off site joining by skype. A number of meetings initiated by S2 as general catch-up and progress update meetings. These ensured we could address any issues and served to re-assure us that we had good support from them. These helped to develop and strengthen the partnership between us.
- Any heart Stopping Moments? Well a couple but that’s probably to be expected for a project of this size and complexity A priority 1 service desk call when we broke our lecture capture solution because we were not aware of a limitation with ADFS (Active Directory Federated Services) in terms of the number of groups people could belong to. Identified and Resolved within a couple of hours and no disruption to service Upgrading the hub two weeks into ‘go-live’ starting at 4pm on a Friday evening – not ideal in anyone’s book but we had a reasonably high degree of confidence that we could do the upgrade without a break in service and assurances from S2 that we wouldn’t make things worse. Didn’t actually fix the issue but the upgrade did address some early functional shortcomings identified by our users, such as an improved Search cosmetics and will also enable us to categorise applications. Took us all of 30 minutes to break 160 applications, however if you’re going to fail you should apparently fail fast so we could put a positive spin on this!!
- However long you think it will take you to navigate the rats nest that is educational procurement, double it and then add some!! We weren’t able to do as much academic testing as we would have liked due to the availability of academics over the summer period, a perennial problem but especially tricky given the newness of how we were deploying the vast majority of our software. It is worth noting that this should be better from this point forward as we move away from this once per year activity peak to a more phased and even spread approach. Early in the project we identified a major risk in the form of our ageing PC estate which has not kept pace with increasing software requirements. We also had a significant number of thin clients which we identified as being unsuitable for a significant part of our software portfolio. Some mitigation was made by securing funding which was used to reduce the number of thin client which then enabled additional resources to be allocated to the remainder improving their performance. It has also enabled a conversation with the Director of Finance about the early release of funds to replace the oldest parts of the pc estate.
- Just shy of 4 months and 349 applications – that’s 82% of our Windows applications now delivered via AppJ Small project team, short timescale, over the summer holiday period and the absences that invariably entails, no weekend working or overtime and I think we came through t without breaking anyone – Does that constitute success? Yes - We think that it does! Team would you like to make yourselves known by standing up and giving everyone a wave? The team and I are happy to take questions, time allowing, or feel free to catch us over lunch. Thank you!