Life cycle management: Let the sunshine in

Although superficially you can be very standardized, life cycle events of all the parts can still turn the landscape into a hard problem

1 2 Page 2
Page 2 of 2

Anyway, will End of Sunset get extended all the time? No. First, we are still in Sunset and during Sunset new instances of the product/version still do require an exception. And second, by making it visible that the end date moves, you improve the weight of the decision. Those small exceptions largely remain hidden. The move of an End of Sunset date far beyond the end of vendor support for a standard will get noticed. That someone has gotten permission to keep using it while on paper we have ended it is much harder to spot.

Quarantine

Now, it will happen (it does in many organizations) that some product/version is kept in operation while it has gone beyond (affordable) support. Apart from the cost of keeping the product/version running, we need to manage security as we will not be getting patches anymore. One way to do that is to put the not-vendor-supported product in Quarantine. Quarantine is a special separate period. After Start of Quarantaine, the product must be isolated. Maybe behind a firewall, in a separate network segment, or in extreme cases physically. The business owner has no choice. He or she must migrate to a Sunshine solution.

For a product/version, it could be like this:

  • Start of Sunrise: 1 Jan 2016
  • Start of Sunshine: 1 Jul 2017
  • Start of Sunset: 1 Jan 2021
  • End of Sunset: 1 Jan 2022
  • Vendor End of Support (optional, informational): 1 Jan 2023
  • Vendor End of Extended Support (optional, informational): 1 Jan 2024
  • Start of Quarantaine: 1 Jan 2023
  • End of Quarantaine: never (see below)

Again, the vendor support is just informational. It is we who decide if we ‘support’ it being in our landscape, based—amongst other things—on vendor support. And frankly, all these vendors have wildly different support schemes. Many are now moving to a regular short cycle with the occasional ‘long term support’ version, some just move, especially the more modern tools. By the way, we need to make the same choices for open source products where there maybe isn’t vendor support at all (just a community forum).

Now in the above example, if End of Sunset has to move, the business owners that are the cause of this have to pay the extra cost. And if it is unavoidable that the End of Sunset goes beyond Start of Quarantaine, the product goes into Quarantaine.

For example, if you have an old application (technical debt) that depends on Oracle 8, then you will find the database and/or the application behind a firewall. The performance may suffer. But you have choices. In the example, Quarantaine starts when normal Support ends. We have set it that way, because extended support is too costly. But if we have to move End of Sunset beyond Vendor End of Support, we have a choice. Do we put the system in Quarantaine, or do we buy Extended Support and move our Start of Quarantaine date?

It’s important to note that Start of Quarantaine may even be Start of Sunshine. For instance, if you add some appliance to your landscape that is managed by another party (say the people who you have hired to do some facilities work including climate control of your building, they use IT that they manage themselves, they do their own security patching (or not...), etc.

Such a new addition to your networks should be separated from your other systems. That already means Start of Quarantaine. Technically, you might even have End of Quarantaine, for instance for a product that goes into production with security flaws but for which improvements have been announced. As soon as the improvements have been installed, Quarantaine may end.

Roadmap, LCM, LMO—it is all the same thing

Architects have often been tasked with maintaining “roadmaps” and more recently “landing modes of operation” (LMO). An LMO is a description of “what is supported in terms of how we can run applications.” Where the applications end up may be called a “landing zone” (LZ). The LZ is where an application “lands.” LMO is just another name of which products/versions make up your standards of that LZ.

Architects have also often been tasked with maintaining “roadmaps.” Roadmaps are how an LMO develops over time. But in that roadmap, I often only find a few major choices, like operating system brands and versions, database brands and versions, etc. It is kind of arbitrary what ends up in the (often strategic) Roadmap and what not.

The LMOs are often somewhat more precise but lack the dimension of time. This is a disadvantage, as it pays to know that while Windows 2012 is still part of LMO now, but soon it will no longer be. Maybe it is better than for the application owner to choose Windows 2016 now even if 2012 is technically still part of Sunshine.

The Sunshine approach puts it all together. Your planning of all the product deployment choices of everything that you want to control (which also is your choice as an organization) in terms of life cycle is in fact LCM and LMO and roadmap in one. The life cycle administration tells you what the LMO is now, but also what it will be in a few years (as far as planned). Is it too much? No, because the poor enterprise architects are not the ones who have to do all the work.

Each product in the Sunshine administration has a product owner. If your IT department (owner) offers tomcat 8.1-4 (minor upgrades, so when 8.4 replaces 8.3, all migrate—as with a security patch), tomcat 8.5 (major functional changes with respect to 8.1-4), and tomcat 9 application servers for applications to land on, you are having three entries in the life cycle administration, each with its own Start of Sunrise, Start of Sunshine, Start of Sunset, End of Sunset and Start of Quarantaine. If you’re smart, you implement it in tooling with discovery and workflow engine. You manage all the dependencies. You’re in control as much as you want to be.

Owners may be users of the products of other owners. Business owners whose applications run on the tomcat platform IT offers them. Every product (application, platform, etc.) ends up in that administration with dependencies in place. If server X contains platform Y, then the Sunshine events on platform Y have to be managed by the owner of server X. If Application A uses platform Y, the same is true for the owner of application A. Etc.

It is a lot of work to set this up, but it will be not very hard to maintain if you make sure that your model is closely linked to reality as in “the best model of the world is the world itself.”

This article is published as part of the IDG Contributor Network. Want to Join?

1 2 Page 2
Page 2 of 2