ECP-9 Lifecycle Model

Post Reply
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Requirements
The requirement for the lifecycle model is to provide the ability to capture the transition of lifecycle status for any element in the repository (to which a lifecycle status makes sense) in conjunction with the timeframes for these transitions.

E.g. a Technology Product (e.g. Microsoft Windows 7) could have a lifecycle model that tracks the timescales over which it moves from beta, to GA, through to end-of-life as defined by the supplier of that Technology Product.

The intention with the Lifecycle Model is to capture the 'facts' of an element's lifecycle, e.g. a Technology Product. These typically provide drivers for our strategic plans in terms of how the product lifecycle will affect an organisation's architecture.
Therefore, a lifecycle model applies to a single element, e.g. a specific Technology Product. The supersession 'chain' of versions of a product will continue to be captured using the 'superseded version' attribute that is available on all elements and note that this can also be used on Technology Product Roles to relate supersession of standards.

The Roadmap Models continue to provide the capability to capture the evolution of the architecture in terms of how products are used and replaced, typically in response to changes in lifecycle of those products. e.g. We may need to define a roadmap for the standard desktop technology build because Microsoft have announced that Internet Explorer 6 has gone out of support.

These models are managed separately in the Essential repository and can be combined in the Essential Viewer environment.
Essential Project Team
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Proposed solution
Create a new meta class in the Strategy Management section of the EA Support meta model, called 'Lifecycle Model'.

Each Lifecycle Model is directly related to the element of which we are defining the lifecycle. In addition, the lifecycle model will have a set of usages of Lifecycle Status elements, each of which can be related to the preceding and succeeding state, e.g. 'Beta Version' -> 'General Availability'. Note that the set of available Lifecycle Status is user-extensible by creating additional Lifecycle Status instances.

Following the pattern of the Roadmap Models, the Lifecycle Model will also have a set of usages of Time elements which are related to each Lifecycle Status. These provide the ability to define the timeframes for each status in the lifecycle - and to see those graphically in the model.

A View of the Lifecycle Model in the same style as the roadmaps can then be associated as a link to any elements that have lifecycle status, e.g. Technology Products, Application Providers, Business Process. Note that these will be reviewed once the meta model design has been approved and implemented.

Meta Model updates will be provided as an Essential Update Pack (EUP).
Essential Project Team
NJC
Posts: 2
Joined: 29 May 2012, 06:03

Great that this has been kicked off.

Less to comment on solution, but on requirements:

In terms of the reporting / output side it would be great to:

a) View a per vendor view of products on a timeline with one product per line over a multi year view showing a standard set milestones, e.g. BETA, GA etc. Per vendor view may help with commercial / negotiation activities - how much change with this vendor

b) Be able to filter this view in some way with respect to as-is architecture views to show what coming impacts are to architecture, e.g. need to plan for middleware upgrades in my ZZ domain

c) Be able to select an existing business process and show for all the supporting systems, technologies what next 3yr impacts look like in terms of lifecycle events, e.g. what will go end of support for this process

Also not quite sure how this fits as I'm not yet up to speed with EAM but ability to capture latent new capabilities / functions against new product releases - so you can easily report what are top x features / capabilities gained from going to a new product version
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Thanks very much for these - this is exactly the sort of thing that we want to hear!

On a) this is very much in line with what we had in mind for some Views. We also thought that it might be useful to view products by 'Product Family' as an alternative to vendor, to focus on a particular line of products, e.g. Oracle DB, Microsoft Windows and so on.

For b) we like the idea of that one. Did you have any particular things in mind for how you would like to visualise this? For example, for any Technology Product, the summary View provides details of the Technology, Application and Information things that are supported by that Product. This is 'traditional' page view, did you have anything in mind in terms of timelines?

c) Sounds good. We're thinking about something like a timeline per System (Application Provider) and Technology Product that supports (directly or indirectly) that Business Process.

On your last point: on the Technology Provider class, we can map the Technology Functions that a Technology Product (or a Technology Product Build - an architecture of products) offers. Each of these Technology Functions is mapped to the relevant Technology Capability, so that we have captured WHAT that function is about (and could later on evaluate duplication, etc.)

We capture each version of a particular Technology Product as a separate instance and so for each version we can do the mapping to show the relevant Technology Functions (and thereby the capabilities) that each version provides. These are already reported in the out-of-the-box Technology Product Summary View but it would be pretty simple to put together a 'compare the functions provided by all the Technology Products in a Product Family' View.

Without going into too much detail, the Technology Functions are managed in what we call the upper logical layer of the Technology Layer - which means that they are abstracted above specific products. Typically, these are mapped also to the Technology Components (the types or classes of technology that exist) and probably provide the right level of detail that you are looking for rather than the somewhat more abstract Technology Capabilities - but it's simple to complete the mapping all the way to the Capabilities and if it's in the model repository, it's easy to include it in the Views!

Let me know if you have any thoughts on how you saw some of those Views related to Lifecycle being rendered.

Jonathan
Essential Project Team
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Complete ECP
We have been testing the implementation of this ECP in the field and believe it is ready for wider use.

This Lifecycle Model extension is planned to be included in the next release of the Essential Meta Model.
Essential Project Team
Post Reply