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.

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

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).

The XMI file exported from the EA model is not MOF compliant. It includes class-associations and a profile with stereotypes that effectively define cass associations. Additionally, the semantics of "shortcut" stereotypes on associations must be expressed in OCL.

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 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>>

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.

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.

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.

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?

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 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 treatment of n-ary associations as a set of distinct tuples seems unnecessary and logically suspect.

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.

The term “class association” is used in several places - it should be “association class”.

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.

The use of “parent” to mean not a superclass but the class of an instance is unconventional and likely to confuse.

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.

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.

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.“

SIMF does have a RFP, though that does not seem to be proceeding.

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”?

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

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.

It’s odd that some references are version-specific, others are not - was that intentional?

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?

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.

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.

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.

As a condition of acceptance by the Architecture Board, the FTF is required to produce a MOF compliant XMI file. MOF does not allow profiles or association classes. To allow a faithful translation of the EA model, some new classes were introduced that translate stereotyped associations into a pattern of a class and two associations. To facilitate this, some new classes were added to the BusinessElement diagram and some redundant classes and generalizations were removed. Prose explanations should be added following the new BusinessElement diagram

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

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.

This issue was originally raised in BACM-17 which was proposed to be closed by BACM-54. However, the specification still references meta-classes no longer in the model (e.g. ValueCategory in 7.2.3.1). These references should be replaced.

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.

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.

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.

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.

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.

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.

Metamodel of Business Architecture Guild defines two relationships between Value Stream Stages and Value Item labeled as Entry Criteria and Exit Criteria. These relationships are missing in the BACM.

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).

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.

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.

Metamodel of Business Architecture Guild defines two relationships between Value Stream Stages and Value Item labeled as Entry Criteria and Exit Criteria. These relationship are missing in the BACM.

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.

The "recordedAs" and "stateOf" associations between Outcome and AbstractBusinessObject overlap.

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.

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.

Two generalization relations are missing from this diagram between Organization::Resource and Organization::Performer as less general and Strategy::AbstractOperatingModel as more general

CustomerJourney, CustomerJourneyStage and Touchpoint are missing from this diagram