Confirm agreement on questions raised by APM examples

[karensmiley]

Original question on KPI-ML syntax:

• Formula
Some APM metrics, eg Cost of Unplanned Downtime (CUD), can be calculated with any of several equations, e.g. either as (quantity X estimated average cost) or as a sum of actual costs over the quantity. The units are the same regardless of which equation is used. Is it appropriate to list two separate Formula elements for the two equations? If so, I’ll do this, as it makes a better example. If not OK, I can just pick one equation and comment on the other variant in Notes.

In the case of PercentRAV and ChangeInPercentRAV, would you recommend combining them into a single KPI Definition with two Formulas, or should they be handled as two related KPIs and files?

In general, is the multiplicity of Formula meant for

• variants of the equation, as in CUD?
• multiple distinct equations where the second and subsequent Formulas define how to calculate components of the first Formula, as in PercentRAV/ChangeInPercentRAV or as in estimating the average cost component for the first CUD equation?
  Or is the KPI-ML standard flexible on this usage aspect?

• Duration and Recurrence
The APM metrics are exemplified as annual, year-over-year measures, although obviously they can be calculated for any time period. I am not clear on the correct syntax to specify an example TimeRange with annual Duration and Recurrence for the KPI Definition or KPI Instance.

The XSD says Duration and Recurrence are of DateTimeType. A natural time period string like “1 year” makes a readable example but will not convert correctly to a DateTime data type. The KPI-ML Word doc discusses TimeRange with respect only to KPI Value, where specific start and end dates obviously make sense. For KPI Definition and KPI Instance, a more generic TimeRange seems suitable. In ISO 8601:2004, all Duration formats start with the letter P and are specified in 4.4.3 in formats such as “P1Y6M” or “P2W” or “P0002-00-00”; all of these will fail to convert to a DateTime or even a TimeSpan.

What would be the best Duration and Recurrence format to use for our examples? Or should I omit these properties for now?

[karensmiley]

Responses from @Dennis-Brandl and @Emers :

4. We had a patch for the Recurrence (changed to xsd:string) and Duration (changed to xsd:duration), but I’m not sure it ever got published. Part of the reason to move to GitHub. [See Update Recurrence and Duration #8 ]

5. Documents & References: My suggestion is to put each reference in a separate elements. This way you can include multiple references and you can put a whole UML in a single description:
   a. http://www.example.com?param1=abc&v=1

6. Formula: In the ISO 22400 we put the mathematical formula into the element and the text description of the formula in a element.
   a. CUD (Cost of Unplanned Downtime) = UDTI (Number of Unplanned Downtime incidents) x ACPI (Average Cost Per Incident)
   b. CUD = UDTI * ACPI
   c. In ISO 22400 there is a separate section that defines each of the elements that make up a formula, and they are assigned abbreviations to make it “mathematical”.
   [DE] In KPIML we took the easy path by making formulas text and not machine actionable. We felt this was good enough for the first release and if there was a need for parsable formulas then the work could be done as an enhancement. Karen what are your thoughts on this?

7. Formula: The spirit of ISO 22400 is a single formula for a KPI, so it is unambiguous. If there are different formulas, then I think the committee would want different formulas. For example there is a difference between CUD using actual vs estimated costs. One would be ECUD (Estimated Cost of Downtime) and the other ACUD (Actual Cost of Downtime).
   [DE] I strongly agree with Dennis. More than one formula per KPI definition will cause confusion.

8. Formula: In the case of PercentRAV and ChangeInPercentRAV I recommend two separate KPIs

9. GENERAL: I changed the file names of the KPI-ML files to remove the version numbers, as a test before we put them on GitHub.

10. Only one UnitOfMeasure is allowed for a unique KPI. That;s in ISO 22400, but maybe something to talk about with them.