====== Differences ====== This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | |||
mvf:compliance_points [2017/06/07 15:52] ebarkmeyer_thematix.com |
mvf:compliance_points [2017/06/12 17:30] (current) ebarkmeyer_thematix.com [Discussion of view and compliance structure] added Fred's "evolution" writeup |
||
---|---|---|---|
Line 35: | Line 35: | ||
===== Discussion of view and compliance structure ===== | ===== Discussion of view and compliance structure ===== | ||
- | [fac] My point is to recognize these levels of evolution [sic] as corresponding to the evolution of the market and thus the business opportunities for language implementers and vocabulary developers. | + | [fac] The development of vocabularies should go through a process of evolution starting with |
+ | - individual enterprises that need to share models of a single modeling language with activities that prefer different natural languages, | ||
+ | - possibly expanding to concepts and vocabularies across different modeling languages for the same enterprise, | ||
+ | - development of concepts and vocabularies developed by professional groups for specific business domains, and | ||
+ | - development of integrated, concept supersets and associated vocabularies developed by an interdisciplinary, business standards organization. | ||
- | [ejb] These compliance points are what the tool can or cannot do as a system component. MVF is not a modeling language standard with “levels of compliance” as ever larger sets of modeling capabilities. It is a standard for making a system by linking two previously unrelated capability sets. Modeling tools and vocabulary tools can do entirely different things and still conform by importing and exporting MVF vocabularies, but only modeling tools can import and export linked models. Only a vocabulary management tool can support [service interfaces], and only a modeling tool has any reason to support [MVCLI]. A modeling tool that moonlights as a vocabulary management tool can do it all, but may choose to support only [MODEL1] and [VOCAB1]. But whether it can do it all or not, I may restrict its role in my system to ‘xxx modeling tool’. These compliance points enable roles. There may also be compliance points that represent levels of capability in each role, but that is about details of support. | + | [fac] Each level of evolution will be driven by different business values and increasing levels of effort and collaboration. MVF should support this evolution without increasing the cost and level of collaboration beyond that required at each level of evolution. This might be addressed by different levels of compliance. MVF must recognize these levels of evolution as corresponding to the evolution of the market and thus the business opportunities for language implementers and vocabulary developers. |
+ | |||
+ | [ejb] Fred's view seems to be that only a modeling tool will comply with MVF, and he describes the evolution of the market for modeling tools that act as vocabulary managers. This ignores the fact that formal industry vocabularies and vocabulary management tools already exist in the enterprise marketplace. | ||
+ | |||
+ | [ejb] These compliance points are what the tool can or cannot do as a system component. MVF is not a modeling language standard with “levels of compliance” as ever larger sets of modeling capabilities. It is a standard for making a system by linking two previously unrelated capability sets. Modeling tools and vocabulary tools can do entirely different things and still conform by importing and exporting MVF vocabularies, but only modeling tools can import and export linked models. Only a vocabulary management tool can support service interfaces [MVSCx], and only a modeling tool has any reason to support [MVCLI]. A modeling tool that moonlights as a vocabulary management tool can do it all, but may choose to support only [MODEL1] and [VOCAB1]. But whether it can do it all or not, I may restrict its role in my system to ‘xxx modeling tool’. These compliance points enable roles. The compliance levels below represent levels of capability in each role, but that is about details of support for the role. | ||
Recommendations for changes to structure? | Recommendations for changes to structure? |