Definition of Business Application Life cycle stage status

[alihamzei]

Dear All, 

We are implementing APM for a company in the Netherland and I need some help in regards to Application Life cycle stage status definition. let me start elaborating my confusion and hope someone can help me. 

Life cycle Stage	Life cycle Stage Status	Definition (My interpretation)	Question
Operational	End of Support	Business Application still in-use however there is no support from the vendor or new feature.	1. What is the definition of the "End of support"?
Operational	Pending Retirement	Business Application is still in-use however there is a plan of the retirement in the pipeline.	1. pending retirement and obsolete can use interchangeably, What is the correct use case for each ? 2. What is the definition of "Pending retirement"?
End of Life	Obsolete	Business Application Reached its end of life however still few users are using it as a process dependent of this business application and successor business application hasn't yet developed/planned/unknown.	1. what is the definition of "obsolete"?
End of Life	Retired	Business Application has reached its end of life and retired.	1. what is the definition of "retired"?

[TaylorJ78]

End of Life - Obsolete would mean an application that is not supported by vendor and no option to move functionality to a new application/platform, but still actively utilized.

Example: Webapp that uses an Oracle 8i database.  Oracle 8i is well out of support, the application is highly critical to my business and there isn't a platform/application available to migrate functionality toward.
I would use the lifecycle: End of Life - Obsolete since I cannot retire it and I do not have an option to move the functionality at this time.

[alihamzei]

Thanks TylorJ78 for the reply. 

this definition is quite same as "End of Support", Dont you think so ?

[TaylorJ78]

They are similar, but with End of Support, you have options.  Usually with Obsolete software, you are looking on Ebay to keep things running.  Here is how I would justify the two..

End of Support - There is hope!  This is for a specific version of application, that version has reached the end of support.  There are additional versions that we can move to, just haven't made the update. We are renewing contracts or migrating to another platform, decisions are being made.  This application hasn't reached the forgotten state.

Obsolete - All talks ended, and have been out of support for a while, there are no additional special circumstance support plans to buy.  We, as an organization, went so far out of "End of Support" we have sealed our fate, now the org has to figure out how to keep it operational since there is nothing to take its place. Migration isn't possible without a complete rewrite, can't turn off due to business requirements.  Someday we can Retire the app, but until then we are Obsolete in our technology.

[Jeff Aldrich]

I would echo Mark Castoe's thoughts that End-of-Life really applies to Software Models, rather than Business Applications.  There are, in reality, multiple "Lifecycles" in play here.  In some ways, it might be helpful if we had distinct names for each Lifecycle, to distinguish them.  I also agree with many who state that these fields and values should be defined based on the needs of your process and the value you are trying to achieve from that.

We've treated the Lifecycle fields on a Business Application as the "application status within our portfolio."  In combination with the Install Status field, we provide a full picture on the state of the application in our environment.  For instance, it is possible that an application could be Obsolete from a portfolio perspective (it should not be used), but still be in use (Install Status = In Production).

On Software Models, there are really two Lifecycles that we want to track.  Manufacturer Lifecycle indicates the manufacturer's stance, e.g., Beta, Limited Availability, General Availability, Extended Support, End-of-Support.  Standards Lifecycle is our enterprise stance on that particular version of an application, e.g., AppX v4.0 is our active standard, AppX v3.0 is Expiring, AppX v2.0 requires an Exception, and AppX v5.0 is in planning (or some such).

[Doron Orbach]

For this part: "Standards Lifecycle is our enterprise stance on that particular version of an application," I suggest looking into the 'Technology Reference Model' which enables to set internal Technology Standards for sw and hw