Application life cycles and road maps

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.

Preface

A very wide variety of things are called “road maps”.

What are they for? How to draw them? How are they related?

And would it be better not to call them road maps at all?

For example, there are:

A. road maps that may be called entity life cycles - where the entities are applications, technologies, whatever.

B. road maps that may be called work plans - a baseline to target transition state transition - e.g. the "architecture road map" in TOGAF.

And road maps of type A cut across road maps of type B.

Life cycles in general

The software development life cycle (SDLC) is a software development team thing.

Here are two examples:

· analyse, design, build, test, release

· vision, elaboration, construction, transition

An application life cycle is an enterprise architecture team thing.

It is normal to start by defining what might be called the states in a normal life or straight through path.

State	Meaning
Emerging	being watched or in development
Maintained	maintained to meet change requests
Contained	no longer maintained, but operational and supported in production
Out of support	operational but no longer supported in production
Unused	still deployed but not used by people
Archived.

But to define a life cycle fully means defining:

· states

· events that trigger state transitions

· actions that should be performed on a state transition

· actions that are allowed while in a state.

And a life cycle is not always a one-way street, you may need to define:

· quit events – that jump a thing to the end of its life

· undo or reversal events – that jump a thing back to an earlier state in its life.

Having said that, the term road map is used to cover a wide variety of tools and techniques.

They range from simple coloured charts to complex migration paths and programme plans.

Road map styles – from Avolution

Remember, road maps of type A cut across road maps of type B.

A. road maps that may be called entity life cycles - where the entities are applications, technologies, whatever.

B. road maps that may be called work plans - a baseline to target transition state transition - e.g. the "architecture road map" in TOGAF.

Four styles are available in the Abacus tool from Avolution, who say

· Road maps of type A may be drawn using the second style below.

· Road maps of type B may be drawn using the fourth style below.

The text below has been copied from:

http://www.avolution.com.au/about-us/news/how-to-build-an-ea-roadmap-4-styles-to-consider

Heat maps

This style is the most basic and uses a metric like Retain-Redesign-Refresh-Retire or Tolerate-Invest-Migrate-Eliminate

You can color or ‘heatmap’ your business capability maps or technology landscapes to show WHAT is changing: Red-Amber-Green,for example. 

This type of road mapping is simply about making a recommendation of what SHOULD happen, but doesn’t address the other questions such as HOW or WHEN.

Lifecycles and Gantt charts

These roadmaps explore in-flight and proposed change initiatives as the HOW and use actual date/time properties for WHEN the changes are going to happen. 

They require a deeper understanding of Project Portfolio Management (PPM) approaches and the transformational side of the business. 

However, they are limited when dealing with interdependencies.

While they provide a one-degree-of-separation analysis mapping programs and projects to the ‘things’ in the business they directly impact they don’t go any deeper than that.

Dependency/impact analysis diagrams

Dynamic roadmaps exploit the ‘hidden’ dependencies or n-degrees of separation structure that you have at your disposal in your ABACUS repository. 

You are able to understand the cascading effect that a given change might have on every other area of the business. 

For instance, a project is proposing to upgrade a service which requires an application that is hosted in a data centre being decommissioned by another project! 

These sort of hidden dependencies can reveal the true knock-on effect of, for example, putting a ‘hold’ on a project that was going to deliver a capability critical for another project.

The “multiple architectures” roadmap

As you mature in your road mapping approach, you will find yourself asking TWO critical questions: is our target state possible in and of itself?

Is it actually possible to get to our desired target state from where we are today? We call this “feasibility analysis” and “reachability analysis”.

Using ABACUS, you can model multiple states as separate ‘architectures’, comparing planned states with actual states.  

The planned states can be project architectures or transition architectures and ultimately target architectures. 

Comparing each scenario to the baseline or current states will help determine its viability. 

The path / collection of architectures from the current state architecture through the transition architectures to the target architecture IS the roadmap. 

If one exists it proves feasibility and reachability.

More about life cycles

Two kinds of thing may share the same range of states

Business applications and platform applications may have life cycles with the same range of states, but expect different events and actions in each state.

State	Business application	Platform application
Emerging	being watched or in development	being watched
Maintained	maintained to meet change requests	updated as vendor directs
Contained	no longer maintained, but operational and supported in production	no longer updated, but operational and supported in production environment
Out of support	operational but no longer supported in production	operational but no longer supported in production
Unused	still deployed but not used by people	still deployed but not used by business apps
Archived.

One kind of thing can have two parallel life cycles

An application may rest in different states in different parallel life cycles.

A whitelisted application might be emerging, maintained or contained.
A blacklisted application might be maintained or contained in special circumstances under a “waiver” or “dispensation”.

Given the three parallel life cycles below, you might find a state in one life history corresponds to one or more states in another life history.

Life state	Approval state	Deployment state
Emerging Maintained Contained Archived.	Undefined Blacklisted Whitelisted	Not deployed Deployed

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0 15/01/2015 12:55

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see http://creativecommons.org