SAP Logo LeanIX is now part of SAP
Learn more About SAP
Solved

IT Component Lifecycle dates - do I need two sets of dates?

  • 21 August 2023
  • 13 replies
  • 464 views
Stephen Gates
Userlevel 5
Badge +1

Building on the definitions of IT Component Lifecycle dates and assuming these dates are provider dates, then I have a dilemma about understanding which IT Component is currently in use. Consider this: 

  • I add an IT Component, say MyFirewall version 1.
  • I use the lifecycle catalog to add the provider lifecycle dates.
  • I notice MyFirewall v1 is in Phase Out.
  • I clone the factsheet and update the version number, and make MyFirewall v2 the successor of MyFirewall v1.
  • I use the lifecycle catalog to add the provider dates for MyFirewall v2 - it is in the Active lifecycle state.

At this point I don’t know which MyFirewall version I’m using in Production because the dates are the provider dates, not my organisation’s lifecycle dates.

It seems to me that using the Lifecycle Catalog only makes sense when the IT Component supports an Application (which gives you your organisation’s lifecycle dates).

Do I understand correctly or am I missing something?

icon

Best answer by Stephen Gates 13 October 2023, 10:09

View original

13 replies

F
Userlevel 3

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

Stephen Gates
Userlevel 5
Badge +1

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?
F
Userlevel 3

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 

 

P
Userlevel 2

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

Thanks 

Francisco

René Wiecha

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

P
Userlevel 2

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

Stephen Gates
Userlevel 5
Badge +1

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? 

Helder.Luz
Userlevel 5
Badge +1

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.

Stephen Gates
Userlevel 5
Badge +1

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 😞

 

Helder.Luz
Userlevel 5
Badge +1

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

Stephen Gates
Userlevel 5
Badge +1

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. 

cholston

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.

Stephen Gates
Userlevel 5
Badge +1

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

Add your votes. 😍 

Reply


Terms & ConditionsCookie settings