Why Lifecycle Management can’t be a mere afterthought anymore

Reading Time: 4 minutes

The world we live in has changed significantly over the past few years. We can no longer afford to use our traditional approach to IT. We need to adopt a new way of thinking. In my opinion, this way of thinking doesn’t end with maintenance, but starts with lifecycle management.


The traditional approach

Old ToolboxEnterprises and companies of all sizes, that I have worked with, have traditionally thought in projects. Projects that serve a goal, are planned and have a clear beginning and end. This was all fun and games in a world where IT meant we had to buy physical server capacity, purchase licenses, implement the stuff and then write everything off over a period of, traditionally, four to seven years.

After this period of time, the solution would have served its goal (whether it be supporting some process or making loads of money in return) an would then be decommissioned, migrated or replaced. In the mean time it needed some maintenance; updates and upgrades to the Operating System or other software, monitoring, auditing, back-ups, etc.


The world has changed

When I first started in the industry, I choose to accept the challenge to design stuff for a long(er) period of time, and keep maintenance as small as possible, Former colleagues will tell me I managed the challenge pretty well. I actually replaced several iterations of functionality at some customers over the years.

However, the world has changed…

Virtualization has made it easier to allocate compute, storage and networking. Upfront capacity planning is fast becoming a thing of the past, Need more? allocate more. Need even more? Add a host to the virtualization platform and place the resource hogs on the newest hosts. High Availability is easily achieved through the hypervisor for any resource you’d want. P2V is a process to get resources onto the virtualization platform without downtime, in most cases.

SCRUM, DevOps and other agile development techniques (use by both IT developers and IT Pros) have propagated the Minimum Viable Product and Minimum Viable Service. Getting functionality displayed fast and iterating to gain a more solid solution, also has its downside. Technical Debt is just around the corner and I see cloud providers changing the tables on their customers by eliminating serious debt by completely changing the API(s). The virtue of starting over?

The more recent cloud initiatives offer even more flexibility through its Pay as you Go mantra and turnkey magic. The cloud has also made it clear to many organizations adopting it, that there is a distinction between making a solution available and getting the most out of a solution. Departments responsible for the first, have seen their responsibilities dwindle. Departments responsible for the latter, have seen their work expand from on-premises to the cloud.

… and the world is changing ever faster.


Where are we now?

Many organizations are adopting clouds. Many of them are implementing a hybrid scenario where on-premises resources, systems, platforms, applications and services interact with cloud-based resources, applications and services, in tandem.

In the ‘trust, but verify’ way of thinking, displayed with choosing this scenario (over completely cloud-based), some typical IT processes are discarded from the responsibility set of the organization, like Vulnerability Management (VM) of the cloud components, and others are becoming essential responsibilities, like Security Incident and Event Management (SIEM) and Technical State Compliance Monitoring (TSCM).


The irony

While the cloud gives organizations flexibility and agility, in these hybrid constellations organizations have to keep up with the cloud provider(s).

I feel Microsoft deserves a compliment for the way they allow their customers to postpone upgrades to their cloud resources (like the year organizations could defer the upgrade from BPOS to Office 365) and provide support for on-premises technology that is considered ‘old’ in cloud years (I believe cloud years are like dog and cat years) to give organizations the ability to plan for upgrades, like DirSync with its support ending in April 2017.

Azure AD Connect Lifecycle Management on a typical Agile Backlog

It’s not always easy to convey this message to organizations using ‘the traditional approach’, but most of them get it, eventually.


A new approach

Taking Security Incident and Event Management (SIEM) and Technical State Compliance Monitoring (TSCM) as perfect examples, the split between traditional thinking and cloud thinking becomes even more evident. Development of solutions using agile technologies, without starting with the end in sight, inherently provide technical debt. Without sufficient development velocity, the cloud component of the solution changes faster than the on-premises component is able to align, never taking off beyond minimum viable. Terms like continuous integration come to mind.

New ToolboxWe have to face, that we can’t create solutions for years to come, anymore. With Technical State Compliance Monitoring (TSCM) in mind, every change in the Technical State (whether it’s in a cloud or on-premises component) needs to trigger a design reevaluation, change management processes, an n state and n+1 state and the automation scripts to actually make the change, audited using SIEM.

Yes, that means I think we need to go back to the drawing board for every large change. And yes, I think this is something that is more intricate then mere maintenance, because the world is changing faster. Maintenance is something organizations do to keep things working in a world that doesn’t change (much).

I feel we can only achieve this when we begin with Lifecycle Management (LCM) as the first step of everything we do as IT Pros.

One Response to Why Lifecycle Management can’t be a mere afterthought anymore


    Thank you for this writeup! very interesting for the future of our customers and IT partners.

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.