Follow-Up: The missing element of ‘Sunshine’ Life Cycle Management

Roughly 3 years ago, I wrote about a practical way to execute Life Cycle Management (LCM) on products of your landscape. I recently found out that there is a little extra element that you can introduce which makes it even more effective (let’s just say I know from people who have experience with it that ‘Sunshine-LCM’ has worked well).

Sunshine-LCM is based on a few fundamental choices:

• LCM of anything in your landscape is based on three periods
  • Sunrise — the period pre-production when you may find the product in your landscape while you are preparing for production
  • Sunshine — the period that the product is in normal production
  • Sunset — the period that the product is still found in your landscape and in production, but its use is deprecated and all users should be working on moving away from it so that at or before End of Sunset, the product is not found in your landscape anymore. During Sunset, new uses (that is, not a new instance of existing use, but really new uses) can only happen when an exception is granted.

It is as simple as that. For details, read:

The hardest thing about it to explain to people is that the sun-dates are not dates about individual uses or instances, they are dates about the entire landscape. And the hardest has been to get people to accept that there is no exception for going beyond End of Sunset. End of Sunset is a choice of the organisation, but it is not a choice about an individual instance, it is a choice about the landscape. If the End of Sunset for Windows Server 2012 is 31 October 2022 and some Windows Server 2012 user is unable to migrate away from it before that date, then that individual user’s server continuing existence in your landscape means that End of Sunset will have to move. You can’t go beyond End of Sunset, because End of Sunset is defined as ‘it can no longer be found in your landscape’.

Now, the idea behind that is that as long as some product is in your landscape, you cannot pretend it does not exist.So, for instance, if you have use cases for the product in your security monitoring, they must exist as long as even a single instance in your landscape exists. You need to have the skills/know how about the product as long as it exists. Etc. It is an enterprise-focus, not a solution-focus. And moving the end-date for an entire type also feels more serious than that single exception (of which you may end up collecting tens or hundreds, making a mockery of your end date).

A key part of this approach is that during the Sunset period, the users must move away from using the product. And while that generally works (so people have told me), you can end up in a situation that users don’t take action and you end up around End of Sunset with (a) many requests to move the End of Sunset date (there goes your policy) or (b) everybody wanting to move at the same time — overwhelming the resources needed for that move. It also can happen that users aren’t really actively aware that they depend on that product (“Huh? I did not know my SuperApp platform ran on Windows Server 2012. I never look at the platform underneath.”). Or they are are, but they look at the product’s web site and look at the last date for ‘extended support’ and decide they have to move just before that. Migrating is a pain that everyone wants to avoid as much as they can.

A solution for this is not complicated. We can add a new date for every user of a product: the End of Use. Every user of a certain product must set a date when they plan not to use the product anymore. And this date must have been set before End of Sunset starts (don’t set one and you’re in breach of company policy and someone will be cross, very cross indeed. They may use sarcasm on you. Maybe even irony. Or — shudder — satire.

Collecting all the End of Use dates means you have an overview of the Sunset period and can for instance manage the spreading of those migration activities. It also makes it less damaging if you have to postpone End of Sunset for some (always valid) reason. Because if users have set their End of Use and it is not allowed to simply change that without checks & balances, then you prevent that after postponement for one user, that migration gets postponed for everyone. It looks like this:

Imagine we two product owners. One is product owner for Windows Server 2019 in Landing Zone A, they are the providing Product Owner. Your SuperStudio Data Science platform runs on Windows Server 2019. You are the using Product Owner. When you introduce your SuperStudio Data Science platform, it has to run on something, and you choose Windows Server 2019. The providing Product Owner has set Start of Sunset to 1 March 2029 and End of Sunset to 1 October 2030. That means you can already decide today when you want to migrate at the latest, and you set your End of Use date at 1 October 2029. Your LCM people collect these dates and manage progress, risks etc. and report on the state of things.

You will even have stacks of these, because it’s turtles all the way down. Windows Server 2019 has sun-dates. But so has your SuperStudio Data Science platform. You also have users and you provide them with your own sun-dates. Etc.

PS. the definition of product here is not simple. Basically, you need to set dates for every version in every ‘landing zone’ that is managed separately. You can set a single set of dates for a product that is managed differently in different domains in your organisation, but there is hardly ever an advantage in doing so. There is more often a disadvantage: a price to pay in agility. I use the ‘Landing Zone’ concept for that, maybe write about that concept (the phrase is also used in other meanings than mine) later.

Hey! I forgot to digress! 😀

PS. You might look at it this way:

Sunrise	Prepare for Provisioning of the Product inside your organisation
Sunshine	Provisioning inside your organisation by some ‘product owner’ (note: provisioning is an internal choice, this is not something set by a vendor or such)
Sunset	Provisioning of a Deprecated Product (deprecated by your organisation, not by a vendor or such)
Start of Sunshine	Start of Provisioning
Start of Sunset	Provisioned Product becomes Deprecated
End of Sunset	End of Provisioning
Use	Use of an internally provisioned product by an internal ‘user’ (may be another product owner). Lies between Start of Sunshine and End of Sunset. Start of Use is after Start of Sunshine (normally not soon thereafter of course…), End of Use is Before End of Sunset (preferably not immediately before)
End of Use	Date at which a single Usage stops, but Provisioning for others may remain. End of Use must be decided before Start of Sunset. End of Use must lie before End of Sunset. After all Uses have ended, it is possible to end Sunset.