The last application lifecycle

All application life cycles - even the funky new Agile/DevOps ones - will degenerate into the trad old generic app support model as the business loses interest and the build team loses funding, unless of course the app gets retired first.

When I wrote about Multi-Speed IT Capability, I introduced the idea in that post that eventually Operations ends up with everything, there is One Lifecycle That Rules Them All, one last lifecycle.

I want to separate that idea off here as a new post of its own because I think it is an interesting idea that I'd like to hear your views on. I was reminded of it when i read Mark Smalley's post on Feral Applications:

Feral applications are domestic applications that have returned to the wild. They have no owners to care for them. They hiss and growl at maintenance programmers as if their intent was spaying or neutering. Yet it has to be done, and it’s usually up to the corporate IT department to do it. To domesticate them again. To find an adoptive owner with a good heart who’ll take on the responsibility for application lifecycle management.

In the Multi_speed IT post I presented this scenario:

    A system starts life as new, unusual, experimental. the team have special circumstances that justify doing change in some new way. The business has a high appetite for risk, because they want agility as they explore a new space, probing it to learn what works and responding quickly when they do. Trusted and senior staff develop the lifecycle they require, with a free hand so long as they stay within the policy. The lifecycle is a highly nimble one with rapid unconstrained changes. The team operate and support the system.

    After an initial period, the system stabilises and settles down to known kinds of changes. These get standardised so they can be automated, and a regular cadence of change is adopted after the users get change fatigue from the wild early days. The team find support too distracting from development, and Level 1 is transferred to the central Service Desk. The team becomes a Level 2 and 3 resolver group, as well as iterative developers.

    The team goes through a cost-cutting event and a number of staff are moved out. They no longer have the resources to operate the infrastructure and databases themselves, even though the servers are in the cloud. They persuade central IT Operations to take them on. the servers are moved off Amazon into the private corporate cloud and the central database team start doing maintenance.

    After a year or two, the system is stable, it has become part of business as usual, is changing much less. The business loses interest in funding it, the development team is disbanded except for one developer, and it needs to be operated and supported. The code then goes through all the stages of a traditional waterfall release to production and is handed over the the core Applications Maintenance team as just another system to support. They change it when needed using their conventional conservative change cycle.

That's four different change lifecycles through the lifetime of the system.

Ultimately all systems trickle down to central IT to own as "legacy".

(Unless of course the app gets killed off beforehand, either by replacing it with a new app that gets new funding, or by retiring the whole service.)

So a generic Applications Maintenance or Support team will always have a role. And agility is less likely to be a KPI for them than is cost and stability.

They'll need some generic tools, methods and lifecycles to support as wide a range of systems and technologies as possible. In any environment that includes legacy systems, is that need likely to drag them down to the "lowest common denominator" of a slow controlled release cycle, a good old waterfall approach?

Syndicate content