Hello Stephen,

I see we have duplicated Lifecycle in our configuration for IT Components 

• original one (vendor)
• internal one

But I also did a quick check, and it seems that the internal one is not really maintained (at least not yet).

Frederic

Thanks for your quick reply @Frederic 

• Did you need your CSM to help configure the Factsheet?
• How do reports work with 2 lifecycles? Are you able to choose the lifecycle you report on? Can you share examples?

Hi Stephen,

I am “only” a power user in LeanIX and while in close contact with our LeanIX support team, I am not familiar with the configuration part unfortunately.

We have (had) a tendency to create many custom attributes, objects which complexified LeanIX a lot IMHO.

Like in this case, we have the double Lifecycle but neither of them if maintained properly so far and I don’t see any pre-build reports.

I would suggest getting in contact with your CSM to start with yes.

Frederic 

Is it possible to have two sets of Lifecycle dates for a Factsheet type such as IT Component?

Thanks 

Francisco

In our case, we distinguish between the lifecycle components (linked to the LeanIX lifecycle catalog), which contain the OEM lifecycle, and IT services, which are offered internally. The IT services in our case contain an internal lifecycle (e.g. license view) and in turn use lifecycle components.
Both objects are of the type IT component and can be connected with applications. By linking them together, an aggregated obsolescence risk can be determined in comprehensive reports. 

Example: Application -> IT service -> lifecycle component

Thanks René,

Understood! I think that the usage is different then. What we’re trying to do is keep different lifecycle information from what the vendor of a specific software (both Applications and IT Components), from our own internal support lifecycle. 

For example, a vendor might say that product A has an End of Support date in December 2024, but we’ll end our internal support at a different date, say September 2024. So that our End of Life projects would have to take in consideration the September 2024 date instead of December 2024.

We’re interested in keeping track of both lifecycles, so we’d like to be able to see is the Landscape reports for Applications and IT Components using either of the lifecycle dates. Though, not necessarily at the same time.  

Thanks again and regards.

Francisco

Thanks for your replies. Just to reiterate, my issue is if you have an IT Component (e.g. a Firewall) that is not connected to an Application, and you’re using the Provider Lifecycle dates, how do you represent your organisation’s lifecycle dates for that IT Component? 

One (unfortunate?) way I can think of is to define a special umbrella Application (e.g., “Common Infrastructure Services”) and connect those generic components to it. Then you have the capability to have different versions of one component used at the same time and get the effective from and to dates. If those two dates are not sufficient (like, if you want to reflect phase out, etc.) or if you want to note specific use (e.g., a Firewall used at two distinct DC / Location) then you could use the approach that René mentions above.

Interestingly the IT Component definition is,

IT Components represent the technology or services your applications depend on. They can provide information on both development & operations. They are used to model operating costs as well as technological risks.

This would suggest that perhaps I shouldn’t store IT Components that aren’t related to an Application. This contradicts using the TBM Taxonomy for the Technology Categories which does include Infrastructure elements.

Confused 

This contradicts using the TBM Taxonomy for the Technology Categories which does include Infrastructure elements.

Not sure it does. I my opinion there are two distinct views of IT Components:

• The technology view (classified via the Technology Category) - This is to show what the IT Component can do. It makes sense to use this view to manage the technology landscape (including arch endorsement/guidelines and related risks like obsolescence).
• The functional/operational view - This is to show how/what function each IT Component is used for by what Application. It also directly contributes to Application costs (Annual Cost of each IT Component in the relation with Applications).

So, having an IT Component (software or hardware) that is not used by any Application begs the question of what is is used for and where, if anything at all. It can however have a useful role in defining what technologies have beed endorsed or disallowed by the organisation (as in an Approved Products List).

Definitely an area that LeanIX should provide more guidance on...

What I did find in the documentation was a hidden page on Standards Management. It doesn’t address lifecycle dates but this is the Use Case I’m looking for. It seems to me Technology Obsolescence Management and Standards Management are mutually exclusive use cases unless the IT Component has two sets of lifecycle dates.

My CSM tells me you can add two lifecycle dates by request to the IT Component fact sheet. It comes with some limitations on Roadmap reports which can only report on the default lifecycle dates. 

We do the same as Frederic above. Our ITCs have a “Vendor Lifecycle” representing support and “Southwest Lifecycle” representing our usage.

Vendor Lifecycle. End of Life means unsupported.

Southwest Lifecycle.End of Life means it’s gone.

Your statement about limitations on the roadmap reports is correct, those reports exclusively report on the base Fact Sheet lifecycle and can’t change the lane - however multiple other reports work just fine.

Oh! There is now an item for this on the Product Roadmap.

Add your votes.