Part 2 of Minimum Viable Product Lines and how we designed the Universal Business Language

 Part 2 of Minimum Viable Product Lines and how we designed the Universal Business Language (OASIS-open . org UBL)

Previously I wrote how Minimum Viable Product Lines, MVPL, allows for multiple sets of requirements coded as extensions with a basic common core, and how the Universal Business Language XML format for invoices, orders, delivery advices, and the like, could be called an MVPL approach. Rather than every part (‘element’) of a UBL document being open for extension and restriction (with highly complex implications), a single extension point in every document allows custom extensions to be added without affecting the main standard document.

I wrote how this requires a degree of disciplined governance. When a need is identified for inclusion of data in a document which the standard format does not support, typical MVPL-like questions need to be asked. Is this truly something which the document standard elements do not cover, or cover inadequately? What happens if future versions of UBL (or the usage profile being used) do cater for it adequately? Will the extension need to be replaced with one which allows better use of the new version? 

However, this governance discipline needs to be applied by the UBL designers too. If the core, the main UBL standard documents, are changed to cater for new data, is this going to force people previously including this data in an extension to adopt a new extension format? Can such disruption be avoided? In principle, if an MVPL approach is persisted, might it not be best to minimise changes to the core, the standard, and prefer that new requirements be catered for in extensions? That way they can more easily be adopted experimentally, and more easily discarded if not found to be necessary. The same kinds of questions need to be asked by UBL usage profile designers too. 

As usual, I’ll let AI write a conclusion. 

“In the end, sustaining an MVPL-inspired approach in UBL is a balancing act between stability and evolution. While the core standard must remain dependable and interoperable across industries and borders, extensions provide a practical and lower-risk pathway for innovation, experimentation, and emerging business needs. The responsibility therefore sits not only with implementers, but equally with standards bodies and profile designers to resist unnecessary core changes and to thoughtfully evaluate when new requirements truly merit incorporation into the standard. By maintaining this shared discipline, UBL can continue to evolve in a way that protects long-term compatibility while enabling the flexibility that modern digital business demands.” — ChatGPT