I’ll start this out by mentioning that I know about PLMXML, and it’s not what I want.
Here’s what I want: a standard format that vendors can use to exchange information about the lifecycles for their products. Ideally, there would be standardized lifecycle phases that would mean the same thing across all implementations, and standard lifecycle formats.
Haven’t seen that anywhere here on the Intertubes, and I’m thinking of working on proposing and/or developing a standard for it with others who seem to like the idea, but I wanted to throw the idea out there so that I don’t spend the next three months on a specification only to be told “Oh yeah, we already did that two years ago, and we’re all smarter than you are, so we addressed all these other issues that you didn’t think about.” And then they’d give me a wedgie.
Simple stuff really: I want to be able to import this info into our architecture repository so we can start comparing the technologies used by our apps to the vendor lifecycles, and feed that as a big chunk of data into our strategic planning. You have an app that will still be up and running in five years, but all the technologies it’s running on will be end-of-support-life in one year? Well, then your five-year-plan had better include a project to upgrade it, hadn’t it?
Basic attribute requirements for a high-level component in the XML would be:
- Technology Name
- Technology version/subversion(s)
- Product description
- Technology type (hardware product model, software product version, industry standard version)
- Lifecycles (should be several, these are just examples): Beta, Supported Release, End of Standard Support, End of Extended Support, Discontinued
- Each lifecycle has a start date and an end date, at a minimum. The last cycle’s end date can be “infinite” or “undetermined” or something similar
- Each lifecycle (and the versioning doc as a whole) can have a categorization as to how public the knowledge is, ranging from “freely available” to “confidential”, but that doesn’t mean there’s DRM on the XML doc itself. That’s a separate security and control question.
- Comments for lifecycles and for the component
- URIs to the most recent version of the lifecycle doc for this technology
See? Simple stuff. But so simple I expect someone has at least looked at it.