Open APIs

TMF API (E.g. TMF620, 633, 634) has a sequence diagram such as: In Study - In design - In Test - Launched - Active - Retired - Obsolete

I'd like to get your take on these lifecycle states:

1) Are these states at the version level or entity level ? 

Some of these states seem to be at the entity level (e.g. Retired / Obsolete) while some can be at version level (e.g. In study/In design/Test/Active). E.g. A retired PO means a PO no longer should be sold, and this concept doesn't seem applicable to version. In contrast, each version can go through a design/test/active cycle.

Is this understanding correct ?

2) Let's say you have launched an entity. It's Active and it has several versions, e.g. v1 and v2. Now, you would like to retire that entity. What's the right thing to do ?

• You update the lifecycle status of the last version (i.e. v2) to  Retired ?; or
• You create a new version v3 with lifecycle status as Retired ?

Thanks for your opinion

Hi Tom,

In our company, we've discussed this topic several times. Let me share the conclusions we've reached - they're just our opinions, not necessarily the best approach for every case:

• We consider the full lifecycle to apply to versions.

• We don't allow more than one Launched and valid (i.e., within its startDate and endDate) version of the same specification at the same time.
  In other words, at any given moment, for a single specification, we could have one version in the Launched state while the previous version is being decommissioned and is Retired, with even older ones marked as Obsolete. Of course, there may be newer versions in Active or earlier states, but those would eventually replace the launched one in the future.

• Every time a new version of a specification is created, it must go through the full lifecycle. In other words, you couldn't directly create a version X in the Retired state, as you mentioned in one of your questions.

Hope this helps!
Best regards,

Hi Abel,

Thanks for sharing your opinion. 

I understand your approach. I have also thought about that approach and saw some concerns:

1) If you adjust the lifecycle state (and also validity period, I assume), you will lose the information of the current lifecycle status. For example:

• Assuming the user has an ongoing version planned to be launched from 1/1/2026
• Now (Nov 10, 2025), he plans to retire the PO from 1/1/2027. So, if he updates the same version, his PO's version will look like (Retired, from 1/1/2027).

       => The user will not be able to tell if at a certain time before the Retire date starts (e.g June 1, 2026), the current version is in the state of Design, Tested, Activated, or Launched because the Retire Version has overridden this information.

2)  Retire, from the business perspective, often means the user no longer wants to offer the PO for sale anymore in the future (i.e. a legacy offer that is no longer for for sale). But if Retire applies at the version level, then you can have a version that's retired while the PO is for sale in the market. Maybe it's a misalignment between business goal vs technical implementation.

Best regards

Hi Tom,

Indeed, there are always pros and cons. In any case, I believe the following points are worth considering:

1. Nothing is preventing us from keeping a history of the changes that catalog entities go through during their lifecycle. This would ensure that no relevant lifecycle information is lost over time.

2. I do not really see an issue with the alignment between the business and the technical implementation. It is perfectly feasible to maintain a product offer version in a Launched state while the underlying services and resources evolve with newer versions as the technical implementation changes. In other words, the Retired concept can be handled at the business level in the product layer, while the technical implementation lifecycle can continue to be managed at the service and resource levels.

Thanks and regards,