IDG Contributor Network: Life cycle management: Let the sunshine in

Enterprise architecture is about the landscape of your organization. A landscape of people and IT and of the behavior of both. These landscapes have become very complex. In itself that complexity and the problems it brings has led to many efforts at standardization and . Not too many brands of an operating system, for instance. Not six different operating systems, but two. Not five different workflow engines, but one. Not too many different networking or computing technologies. Less is better.

Even when you are standardized, an additional complexity comes from the life cycles of IT. Putting IT in—any IT, even standardized—doesn’t mean you are done. For software this is the most obvious: new versions are released on a regular basis. There are many reasons for new versions, a very important reason are fixes of bugs, both in terms of the primary function, but also for instance in terms of security. Platforms that are used to run applications get updated all the time with security and bug fixes. And then there is a constant stream of new functionality, which in itself also means new functionality that can have bugs.

Having old IT in your landscape is generally not a good thing. Old stuff is one of the most important sources of security problems. If your landscape still contains Flash, very old Java or dotNet versions, outdated operating systems, it is very likely not that secure.

Companies are aware that they have to manage the systems and make sure that they are up to date. This is life cycle management (LCM). LCM also takes place with IT hardware. Hardware also gets old. It wears. It can fail. Hardware has a lifetime of a few to maybe ten years. And then, you generally cannot replace it with exactly the same as it is not for sale anymore. Technology has moved on. New versions and products are forced into your landscape, even if you do not have new demands (but generally, you have).

All these products often depend on each other. A patched operating system or application framework may suddenly result in an application not working properly anymore. A new version of a platform may offer new possibilities, but also lose old ones. You may want to update your Windows server from Windows Server 2012 to Windows Server 2016, or from RedHat Linux 6 to 7, because the old version is going out of support, but will your application that runs on it still work?

Or you might want or need to update an application, but the new version requires a different platform version. Which you do not support yet. And most of your landscape is not built but bought (or rented) and the suppliers are in control over their LCM and what they support (and what not). Will you be using that old Windows Server 2003 that is no longer updated with security patches? Is there an old application that forces you to keep using it?

,” this is likened to playing a chess game where—while you are making a move—hundreds of other players are making moves as well.

generally did not solve the issue, the real world of dependencies was too complex to be governed by them. I should update as a new version N+1 has arrived, but I can’t because…

A proposal to get a grip on life cycle management

First, it is important to understand what is in your landscape is in the end your choice. There are some legal limits (e.g. if you do not have the license to go on using something, you’re legally not allowed). But for the rest: your landscape (your architecture), your choice. Do you want to keep running that unsupported old piece of soft- or hardware? Nobody stops you.

Then, for every product or system or platform or application or service you use, you define a set of your own periods when it can be used. For managing the use of systems and their full LCM the periods are:

Sunrise

Sunshine

Sunset

And there is an aspect, called Quarantine, which is independent from it, but generally may play a role during Sunset.