The "recordedAs" and "stateOf" associations between Outcome and AbstractBusinessObject overlap.
CustomerJourney, CustomerJourneyStage and Touchpoint are missing from this diagram
Two generalization relations are missing from this diagram between Organization::Resource and Organization::Performer as less general and Strategy::AbstractOperatingModel as more general
IRI is not a primitive type in UML. In the beta document, a class with the name IRI was used to represent an IRI type. But, the IRI type is better represented in UML as a DataType.
A participating stakeholder in a value stream is a Performer role in a Capability that produces an Outcome that is valued by a ValueItem produced by a ValueStreamStage. This relationship is missing from the metamodel
On investigation and after Ballot #7, it was discovered that the issue was incorrectly stated. The source to destination of both assignTo associations are correct. However, the text label direction arrowhead for PerformerRole assignTo Performer is reversed.
Section 5 Symbols and Abbreviations is largely empty. There are, however, a number of acronyms used within the submission that should be specified there. The acronyms present in the listing of Normative References is fine as is, but “SPARQL”, “OWL” or “OWL 2” perhaps, and “RDF” (RDF* is listed in the normative references, but the citation does not spell out the acronym).
The definition of shortcut does not match its expression in the MOF translation.
There are duplicate association names in the EA model. Because nearly all of these associations are stereotyped with <<class>> or <<shortcut>>, they are transformed into a class association pattern in MOF and duplicate names for classes are not allowed. The transformation program de-duplicates these names, but coherence is lost between the UML model of the specification (and the specification document generated from the UML model) and the generated MOF XMI.
Section 7.2 identifies a case where same named associations with identical src end types are to be treated as a single association with dst end types that are a union of the end types of the designated associations. This can be eliminated by substituting an abstract class that is a superclass of the class to be unioned and having the dst type be this superclass. This change simplifies the transformation program and eliminates possible misunderstanding of the specification.
Conformance statements are incomplete and distributed through section 7. Provide an updated Conformance section that addresses conformance requirements, This issue resolution also resolves BACM-26, BACM-55 and partly resolves BACM-84 (with respect to conforming with the requirement to implement SMOF).
The beta specification states that SMOF is a requirement for implementors. However, SMOF lifts the MOF restriction that each instance have one and only one metaclass/meta-association. Consequently, the specification is ambiguous about what elements should be disjoint. Some meta-classes should be disjoint (e.g. business objects and capabilities).
This omission also affects the issues raised in BACM-83.
A prior vote of the FTF approved the removal of this content from the specification. The FTF must now decide what to do with this content.
The "owns" association denotes strict composition at the model instance level. Business architecture methodology disallows non-strict composition for capabilities and value stream stages and value streams, but makes no statement about other cases. Business architecture methodology also disallows specialization of capabilities, value stream stages and value streams. The metamodel needs a "does it make sense" review to determine if "owns", "agggregates" and "generalizes" are properly expressed in the model.
Following vote #3, the specification document was not completely updated as the result of an editing mistake. Consequently, some elements that were deleted in the BACM_Model package are referenced in the diagrams and prose of other packages.
The quantification patterns for the special associations (owns, generalizes, aggregates) are inconsistent in the specification and the MOF XMI file.
The specification displays classes with SMM:: namespace designations, but the model does not explicitly import SMM and it does not explicitly specialize the corresponding SMM metaclasses. By formally importing SMM, the BACM metamodel would be coupled with a particular version of SMM and would have to be revised to accommodate integration with other versions of SMM. On the other hand, the current normative text may not be sufficiently precise to allow an implementer to create a conforming implementation of this integration.
MEF replaced the categorization mechanism per request from the AB reviewers. The beta specification document does not define the compliance requirement for MEF.
Compliance statements for shortcuts and touchpoints, while these are optional compliance points, seem hard to evaluate.
This issue depends on acceptance of the proposal BACM_5 to remove Annex B from the specification document. It seeks proposals to dispose of this content.
During the AB approval process, the BACM_Model package diagram was changed to eliminate imports of the other packages. The submitters failed to include these changes in the final document that was sent to the OMG publications team for re-publication as dtc-22-06-01.
The beta document describes ValueStreamStage produces ValueItem as a shortcut association and also describes Capability supports ValueStreamStage as a shortcut association, creating an unresolvable mutual dependency. In addition, the prose describes ValueStream produces ValueProposition as a shortcut association, but this is missing from the EA model
The specification has this as an aggregates association but the quantification suggests ownership. Resolve whether owns or aggregates and change owned end quantification to match.
ProductOfferings can be aggregated by not contained or generalized. This appears to be an omission that would compromise the usefulness of the specification. It would be a minor change to the Product diagram.
The issue refers to the metamodel schema for instancing n-ary associations that are represented in the metamodel by an association stereotyped class and a single association named "related". The specification text states that when an instance is created, the legs of the instance instantiate the "related" meta-association but may be assigned distinct (role) names. The UML specification uses a similar device to allow n-ary associations from its MOF metamodel. In BACM, such n-ary associations are typically restricted to instances of a specific meta-class (e.g. AbstractBusinessObject). NOTE: this issue was accidentally combined with BACM-34 and is separated with this issue.
The text definition of the AssignTo association between Resource and ResourceRole clearly states that the Resource is AssignedTo the ResourceRole, defining the direction of the association as being from Resource to ResourceRole. However, in the diagram and the generated test, the direction of this association is reversed.
Element notes fields for BACMEntity, BACMRelation, BACMPlainEntity and BACMShortcut have Usage Notes: instead of Usage:. This causes the glossary generation tool to operate incorrectly.
IRI notes lack the Definition: bold prefix
There is extensive use of “M1” which is terminology that is no longer part of MOF (it was dropped at MOF 2.0). “M1” should therefore be explained/included in the Terms.
SIMF does have a RFP, though that does not seem to be proceeding.
The use of “parent” to mean not a superclass but the class of an instance is unconventional and likely to confuse.
It’s not clear who “the user” is at the end of para 4 and elsewhere. Can other property names in this specification be “modified”?
Section 9 consisted of responses to RFP requirements to address alignment with other OMG specifications. This information should probably have been placed in Section 0 of the submission and be deleted prior to publication as a beta specification. Moreover, the information in this section is informative and is expected to evolve rapidly as the BACM specification is used by architects. Consequently, the recommended action is to delete Section 9 and republish it as an informative adjunct to the normative specification.
There seems no attempt to meet requirement 6.5.2.4 “Submitters shall identify shared terms and clarify any differences in definitions in UPDM/UAF, VDML, ArchiMate™, TOGAF Content Metamodel, BPMN, DMN, and CMMN.“
Section 0.5 - It would be nice to have the OWL 2 ontology provided as a machine readable file, even if only informative. Did the generation use MOF2RDF?
It’s odd that some references are version-specific, others are not - was that intentional?
Section 0.6 has a very useful description that would be better in the body of the spec - section 0 will get stripped off after adoption.
This diagram represents the capabilities that would be required to carry out a means or initiative. Often, these capabilities are not a part of the organization and must be added, e.g. by contract. The issue is that abstract process should be included because it represents a perspective that abstractly represents the operations of the business that is distinct from the capability perspective but at the same level of abstraction.
The BACM specification, diagrams and text, specifies the BACM model using stereotypes that are not consistent with MOF. Consequently, the XML of the specified model is translated to a MOF-compliant XML as required by the RFP and interoperability of implementations. Both XML models are unnecessarily complex since there is no need to use stereotypes. MOF associations are sufficient, and the model would be more straightforward. The implementation Intent can be adequately specified in text with constraints, if necessary. The intent appears to be an effort to over-specify the expected method for development of an application of the model.
The treatment of n-ary associations as a set of distinct tuples seems unnecessary and logically suspect.
The term “class association” is used in several places - it should be “association class”.
The notion of Touchpoint as defined in the RFP does not IMO require the open-ended query capability included here. Which is completely under-specified. On the other hand it does not seem to provide the Though it does say (in 8.2) “2) the modeling tool can integrate the BACM model with another model using a supplementary metamodel to join the concepts in the BACM metamodel to the concepts in the other model;” it does not provide that metamodel or any more details. It seems to me that this is what the RFP was looking for.specific links between classes in different metamodels that the RFP seemed to have in mind. Rather than allowing modelers to link specific elements from different models, it requires them to formulate some sort of query.
The RFP says “This RFP defines scope in terms of a collection of perspectives”, however the submission only seems to be addressing 6 of the 10 perspectives in the RFP (Policy, Information, Initiatives, Value seem to be missing) in addition to the declared omission of an IT alignment.
There is no Glossary in the perspectives as required in 6.5.2.2 of the RFP: only a combined glossary of camelcased metaclass names.
This important Scope section should describe the spec in its own right and not reference the RFP. Nor, indeed, what other OMG models may or may not exist.
The categorization mechanism was removed from the specification draft and replaced by requiring MEF, which effectively allows the specification of stereotypes in a conforming tool. As in UML, these stereotypes may carry properties not present in the model instances. Mentions of category and categorization remain present in the beta specification document.
The paragraph state:
For an implementation of the metamodel, the normative XMI that is part of this specification is intended to be an unambiguous and precise way to create an implementation that is equivalent to the underlying graphical predicate model. The non-normative XMI that is provided with the specification must be interpreted according to a set of rules to create a conforming implementation that is not based on MOF.
This paragraph is unclear and refers to a non-normative XMI that is NOT part of the specification.
This paragraph states:
"In general, metamodel classes in the diagrams in this document will become meta-classes (class prototypes or templates) in an implementation. However, classes stereotyped as “association” will become associationclasses. These entities are binary or n-ary associations that can be specialized (from other meta-associationclasses), have features, and participate in other associations. UML binary associations with a <<class>> stereotype should be implemented as binary meta-associationclasses."
This description is unclear. It mentions association classes that are not part of MOF. It does not adequately describe how to interpret the stereotypes <<class>>, <<association>>, <<shortcut>> and <<individual>>
Likewise “The user may also indicate that one instance generalizes another, but the implementation is not obligated to determine that the instance model is consistent.“ - what does generalization even mean between instances and won’t it depend on the metaclass? E.g. what would it mean to be a generalization of LegalEntity IBM Corp?
The prose of this section is difficult to understand. It needs to explain how an instance of a class can be a class and how individuals are represented as singleton sets. It is unclear that the singleton set interpretation can be imposed in the MOF model without a change to the metamodel to add an Individual abstract metaclass that is specialized by the MOF classes resulting from the translation of <<individual>> stereotyped EA classes.
This issue arises from the resolution of BACM-45 and BACM-43. Taken together these proposals create an interpretation of the BACM model elements that does not syntactically distinguish elements representing sets from elements representing individuals. Rather, it represents individuals by an OCL constraint that allows only a single model element to have a given metaclass. This solution works for the only case in the current BACM spec, but does not resolve the underlying issue of the inability to represent individuals and make assertions about them.
7.2.1 states the following “UML visual modeling is used in this specification as a visual notation for an underlying graphical predicate model. The underlying model can be given a concrete form in RDF* (https://arxiv.org/pdf/1406.3399.pdf) or a property graph language (e.g. Cypher openCypher_V9). Most of the semantics of the metamodel (except for shortcuts and co-occurrence constraints) can be specified in OWL 2.” Which is not really true since those forms are not actually provided and what is specified is a MOF metamodel, which has different semantics than UML. Though the ODM specification does provide an interpretation and a profile for use of UML for RDF, this has not been referenced in this specification.
It’s not clear why the “leg” construct is introduced when association classes already exist in UML and have properties instead of legs. As do n-ary associations. Though neither are part of MOF officially, I don’t see the justification of the “leg” terminology.
The last para says “In this case, instances may be created with an arity specified by the user and with instance leg names specified by the user.” but no indication as to how this might be done (such dynamic meta-level property renaming or multiplicity changing is not even part of SMOF).
It gets further confusing in “the target end of a leg” when early it says that a leg itself can be a “target” (or source).
· Section 7.2.1 Interpreting… “src” and “tgt” are introduced, but not defined. Relatively trivial as they are not referenced again, but specifying what they stand for in the first instance is a best practice.
The first part of Annex B (B1) is irrelevant given the changes made to the implementation of the <<shortcut>> stereotype in both the model and the MOF-compliant XMI. These changes were approved by the Architecture Board and accepted by the DTC. But the required changes to the specification were not made prior to publication.
The second part of Annex B (B2) while technically correct, does not match the model shown in the diagrams. It is planned that this part will be rewritten and submitted as an informative document associated with the specification.
The recommendation is to remove Annex B in its entirety
