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.
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.
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.
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.
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. |
|
|
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