Only in winter do we know that Evergreens exist
Has winter arrived at your company? And has the desktop remained evergreen?
Conventional practice on desktops skipped major versions of the operating system to avoid the painful logistics of a desktop upgrade, but now it seems the expectation is for continuous refresh. Just how do you fit in all that application testing? Or more accurately how do you cope with the problem that you cannot test everything before putting an update live? The cost of disruption from a service loss has tended to make infrastructure teams very cautious: “Don't do anything that you wouldn't feel comfortable reading about in the newspaper the next day!”
Many years ago, I was invited to a workshop on software distribution to the desktop at my company. Application teams were complaining that the process for rolling out a new application, or an upgrade, was slow and unreliable. Going into the meeting, it was clear that the process could be automated and placed much closer to the application teams to meet their request. “But …” came the objection, there could be conflict between two teams. There may be a shared component and, if the order is not managed, then an earlier version may overwrite a newer version of that component before the registry was updated by a reboot. So, within ten minutes, the workshop was going to break up and everyone return to the slow, cumbersome, inaccurate manual process. Fortunately, someone said “wait!”. We considered how frequently this actually happened in practice (it didn’t) and whether it would be better to repair on occasions where it did. We concluded that our current cure was worse than the sickness.
The same is true with desktop evergreening. The desire to avoid inadvertent error can lock you into practices that just frustrate everyone. But the answer is not to just to roll out the change and hang with the consequences. We have written a position paper on good practice for managing an evergreen desktop which avoids the worst of a “risk averse” culture on one hand and a “risk exposed” one on the other. The paper lays out eight practical ideas to manage the risk differently. In summary:
- Invest in developing isolation and resilience in key applications, rather than protecting the application from any change at desktop operating system level
- Make your corporate build the vendor’s build with management and security from configuration, not specialization
- Deployment Rings – one step on from pilot and release - provide a pragmatic way of reducing the risk of change
- The risk of the application failing reduces if the desktop is not the only access point to it. Look at what works on smartphones in the company too
- Use the evergreening operating model as the risk control, not the change approval process
- Keep challenging for improvement in that operating model. A mindset that tolerates an error because at some level it is unavoidable should not prevent trying to do things as well as possible
- Consider what used to be included in desktop migrations and make sure these don’t get forgotten when changing to evergreen practice
- Look at the modern practices that have arisen with common approaches around smartphones and desktops for process improvement and risk reduction
If you are considering the move to an evergreen desktop model and would like a copy of the full position paper, please contact us and we will happily give you a copy.