Toggle menu
x

 

 

Blog

English version

 

Wees voorbereid voor Windows As A Service

Ervaring:
+ Programming (VBA)
+ Testing (TMap)
+ Testmanagement (ISEB Certified)
+ Problem- and incidentmanagement
+ Project management (Prince2 Certified)
Specialiteit: Government (tax dept. & defence) Banking

Martin Bollen
 
m.bollen@advanced.nl
   

"Wees voorbereid, test efficiënt en migreer voorzichtig"

 

In grote organisaties vergen werkplek Operating System (OS) upgrades traditioneel langdurige testtrajecten om zeker te stellen dat alle applicaties gereed zijn om te draaien op de nieuwe OS versie. Pas na uitgebreide tests en behoorlijk wat aanpassingen aan de applicaties kunnen de werkplekken worden geüpgraded naar de nieuwe versie. Daar staat tegenover dat werkplek OS versies doorgaans meer dan een decennium werden ondersteund door de leverancier, waardoor er ook tijd genoeg was om de upgrades goed voor te bereiden en plannen.


Met de komst van Windows 10 is deze aanpak niet langer toepasbaar. Het Windows 10 OS wordt door Microsoft geleverd As A Service en vereist frequente upgrades om ondersteuning door Microsoft te behouden. Hoewel het daadwerkelijke tempo nog niet helemaal duidelijk is mikt Microsoft op het uitbrengen van een nieuwe versie elke 4 tot 6 maanden. Iedere nieuwe versie bevat niet alleen bugfixes en veiligheidspatches maar bevat ook functionele vernieuwingen en wijzigingen. Ook kunnen potentieel oude functies komen te vervallen. En het valt te verwachten dat andere leveranciers en producten deze aanpak zullen kopiëren. Als gevolg hiervan zal het tempo van changes met potentiele impact op applicaties snel toenemen.

Applicatiebeheerders die verantwoordelijk zijn voor applicaties die afhankelijk zijn van werkplek OS en middleware moeten zich aanpassen aan deze nieuwe werkelijkheid. Het vereist dat ze zich goed voorbereiden op het hoge tempo van wijzigingen, dat ze slimmer gaan testen en behoedzamer migreren.

 
Wees voorbereid
 

Wanneer uit tests blijkt dat een applicatie moet worden aangepast als gevolg van een werkplek OS of middleware upgrade dan komt dit zelden gelegen. Maar door de sterk ingekorte ondersteuningsperiode van de OS- en middleware versies worden applicatie beheerders gedwongen de aanpassingen alleen maar sneller uit te voeren – binnen enkele weken in plaats van enkele kwartalen. Dit noodzaakt ze tot een proactieve aanpak om hun applicatie voor te bereiden op het onbekende. Daarvoor hebben ze twee strategieën ter beschikking.

Als eerste moeten ze erop toezien dat de applicatie wordt gebouwd conform markt standaarden en best practices. Leveranciers zoals Microsoft doen hun best om hun upgrades maximaal backwards compatible te maken. Dit doen ze door hun software uitgebreid te testen voordat ze deze releasen en bij deze te4sts baseren zij zich op de markt standaarden en best pratices voor applicatie ontwikkeling. Hoe beter de applicatie hieraan voldoet hoe kleiner de kans op issues na een update van het OS of middleware.

De tweede strategie om voorbereid te zijn op het onbekende is door de applicatie up-to-date te houden. Veel applicatiebeheerders vertrouwen nog ten onrechte op de mantra “Never change a winning team”. Hoewel deze strategie in het verleden vruchtbaar kan zijn geweest, is deze in deze tijd van snelle veranderingen niet langer valide. Het uitstellen of overslaan van releases die de leverancier beschikbaar stelt, vergroot de kans op problemen bij OS of middleware upgrades.

 
Test efficiënt
 

In het afgelopen decennium is Risk Based Testing al de norm geworden bij de meeste organisaties. Door een zorgvuldige beoordeling van de release notes van de nieuwe OS en middleware versies te combineren met kennis over de applicatie is het mogelijk om een nauwkeurig risk assessment te maken. In veel gevallen leidt dit al tot een aanzienlijke vermindering van de uiteindelijke testinspanning.

Daarnaast is het voor extern aangeschafte applicaties belangrijk om heldere afspraken te maken met de leveranciers over hun verantwoordelijkheid op het vlak van compatibiliteitstesten. Voor een applicatie die de Java Runtime (JRE) gebruikt bijvoorbeeld, mag je van de leverancier eisen dat hij zijn applicatie compatible houdt met de laatste versie van de JRE. De applicatiebeheerder kan zich dan focussen op de maatwerk- en configuratieaspecten van de applicatie binnen de organisatie, zoals specifieke GPO-settings en de processen voor het distribueren, installeren en ontsluiten van de applicatie.

Verstandig testen omvat ook test automatisering. Het automatiseren van tests is vaak tijdrovend en kostbaar en alleen rendabel als het tegelijk met de applicatie ontwikkeling wordt geïmplementeerd. Test automatisering verhoogt niet alleen de kwaliteit en snelheid van het testproces maar maakt het ook goedkoper om frequent regressietests uit te voeren bij de vele wijzigingen aan de infrastructuur.

De vierde strategie om verstandig te testen is het gebruiken van pilotgroepen. Voorafgaand aan een nieuw OS of middleware release maken veel leveranciers al gebruik van specifieke gebruikersgroepen die deelnemen aan een ‘Insider preview’ release. Het is aan te bevelen om deze strategie ook binnen de eigen organisatie te hanteren. Zodra de voorbereidingen voor een upgrade beginnen kan deze al worden uitgerold naar een pilotgroep in de organisatie. Door deze groep zorgvuldig samen te stellen, met vertegenwoordigers van ontwikkelaars, applicatiebeheerders en eindgebruikers, kunnen eventuele issues vroeg en met minimale inspanning worden ontdekt. Zorg wel voor goede back-up faciliteiten om het draagvlak binnen de pilotgroep niet te verliezen en de downtime voor eindgebruikers te minimaliseren.

 
Migreer voorzichtig
  In het verlengde van het inzetten van een pilotgroep ligt het toepassen van een gefaseerde implementatie strategie om de zeldzamere issues boven water te krijgen die buiten de vastgestelde risicogebieden kunnen optreden. In een typisch scenario begint de uitrol bij de IT-specialisten, gevolgd door de kenniswerkers die alleen standaard kantoorapplicaties gebruiken en eindigt bij de zakelijke gebruikers die afhankelijk zijn van bedrijf kritische applicaties.

Blog

 

 

Get ready for Windows As A Service

Experiences:
+ Programming (VBA)
+ Testing (TMap)
+ Testmanagement (ISEB Certified)
+ Problem- and incidentmanagement
+ Project management (Prince2 Certified)
Specialties: Government (tax dept. & defence) Banking

Martin Bollen
Martin Bollen
m.bollen@advanced.nl
   

"Be prepared, test smart and migrate cautiously"

 

Workspace Operating Systems (OS) upgrades in large organizations traditionally require extensive test projects to verify that all front-end applications are ready to run on the new OS version. Only after thorough tests – and quite some remediation – these OS upgrades could be accomplished. Accordingly, single OS versions were supported for more than a decade, allowing organizations to prepare their upgrades in a controlled and well-planned manner.


With the introduction of Windows 10 this approach is no longer valid. The Windows 10 Operating System is supported ‘As A Service’ and requires frequent upgrades to remain supported by Microsoft. Though the actual pace is not clear yet, Microsoft targets to release a new Windows 10 version every 4 to 6 months. Each new version will not only include bug fixes and security updates, but is also likely to bring new functionality and change - or even decommission - existing functionality. Other products and other vendors are likely to copy this approach. As a result, the frequency of changes with possible impact on your applications increases rapidly.


System owners managing applications that rely on Workspace OS and middleware must therefore switch to a more agile approach on application management. This new approach requires you to be prepared, test smart and migrate cautiously.

 
Be prepared
 

Remediation activities rarely come at a convenient moment and often interfere with current projects and resource planning. At the same time, the shortened lifecycle of OS and middleware forces application owners to speed up the remediation process and implement their fixes within weeks instead of months. This urges them to reduce the need for remediation by pro-actively preparing their applications for the unknown. There are two main strategies to do so.


First you should make sure that your application is developed conform market standards and best practices. Vendors like Microsoft will try their best to maximize backward compatibility of their upgrades. They do so by extensive testing before releasing a new version of their product on the market. Their tests are based on market standards and best practices for developing applications, so the more your development teams have adopted those standards and practices, the smaller the chances are that you will face issues during impact analyses and tests for infrastructural changes like workspace OS or middleware upgrades.


The second strategy for being prepared is to keep your application up-to-date. Many system owners still rely on the mantra that prescribes never to change a winning team. For a long time, this strategy may have proven its value but in the increased pace of OS and middleware upgrades it no longer holds strong. Skipping upgrades your vendor provides, increases chances that you encounter issues when OS or middleware is upgraded.

 
Test smart
 

Fortunately, over the last decade Risk Based Testing has come to full swing in many organizations. By carefully assessing the release notes of new OS and middleware versions and combining this with your knowledge of the application you should be able to make an accurate risk assessment.  In many cases this results in a huge reduction of actual test efforts.
Next to that, for externally purchased applications it is important to have detailed agreements with the vendors, delegating most of the test responsibilities to the vendor. For instance, if your application uses the Java Runtime (JRE), you should demand from your vendor to keep the application able to run with the latest version of the JRE. As a system owner, you can then focus on those aspects that are customized for your organization, like specific GPO settings or the mechanisms used for distributing and installing applications.


Smart testing also involves automated testing. But automating tests is a time-consuming and expensive path which may only be cost-efficient if implemented along with developing your application. Automating your tests not only improves the speed and quality of your development process but also offers a cost-efficient way to perform regression tests when the eco system for your application changes.


The fourth strategy for smart testing is using pilot groups. Before releasing a new OS or middleware version, vendors often allow a specified group of specialists to participate in an ‘Insider preview’ release. It is recommended to copy this approach within your organization as well. As soon as you start the preparations for implementing new OS or middleware versions you can roll out these versions to a pilot group within your organization. By carefully defining your pilot group, representing developers, system owners and end users, you can early find issues in a cost-efficient way. Of course, you should organize backup workspaces for the pilot users to minimize downtime for them in case of any issues during the pilots.

 
Migrate cautiously
  In close relation to using pilot groups to find issues in an early stage, a staged deployment strategy helps to identify those rare issues that occur outside the identified risk areas. In a typical situation one should first upgrade IT-specialists, followed by the knowledge workers only using standard office applications and finish with the business users that rely on high-critical business applications.
   

 

© AdVanced. Alle rechten voorbehouden.