For example, an Initiative Management capability will need to interact with the Job Management capability, the Asset Management capability, the Plan Management capability, Business Entity Management and other capabilities. The current metamodel does not provide a type-specific relationship between capabilities that designates dependency.
In addition, “produced” Outcomes are generally held to be final. But, Outcomes associated with dependencies are typically not final but represent an exchange of state information between capabilities.
Whether the “aggregates” relationship between AbstractProcess and Process is a dependency is unclear. There are no Outcomes associated with this relationship.
CapabilityImplementation is intended to represent a configuration of Roles, AbstractBusinessObjects and Performers in an actual or planned implementation of the Capability. There may be many CapabilityImplementations of a Capability, each with different Role assignments. This cannot be the case if the Role linked to a Capability is also used by every implementation of that Capability.
Additionally, CapabilityImplementation should be capable of implementing AbstractProcesses.
The current draft provides OutcomeRelation as a template for the model level definition of relations between outcomes. Recent work on entry and exit criteria for value streams as well as capability and process flows has informally used logical relationships that instance/specialie OutcomeRelation and effectively define an Outcome that is the logical union or other Outcomes. The issue is whether the metamodel should define a set of specifically logical relations. For example include, exclude, include complement could be used to create an Outcome by conjunctive composition where the semantics of the Outcome is the union of all facts from included Outcomes, no facts from excluded Outcomes (i.e.not known whether these are true or false), complement facts from included complement Outcomes. This is just an example; specific proposal to be worked out.
The process diagram does not provide a way to represent that one process must precede another.
Capabilities are not allowed to be specialized because architects tended to misuse specialization when creating capability maps by decomposing capabilities. The problem occurs when specializing and then decomposing, resulting in different decomposition hierarchies for each specialization and duplication of capabilities.
UAF and VDML both have a concept of capability that is more like a capability specialization than a capability because it recognizes that capabilities may be variants. The BACM does not have a single concept that aligns with the concept of capability in UAF and VDML. Instead, the BACM splits this concept into CapabilityBehavior and CapabilityImplementation.
The ability to associate products with customers is important. In the current metamodel, this connection can only be made by joining a customer targeted by a value proposition with a product offering where the value proposition is of the product offering. Should the metamodel include a direct relationship between product offering and customer? Should this relationship be a shortcut?
Some organizations have developed what they call operating value streams. Sometimes these arise from application of "Lean" methdology. But, they may also arise from a desire to model the creation of value associated with particular product lines and analyze those representations of value with respect to the generic models of value creation provided by value streams.
Specialization of value streams and stages is disallowed by the BIZBOK (to avoid the common methodological mistake of conflating value streams and processes). Is there a need for operating value streams? Is there a way to represent this that does not violate the BIZBOK?
A frequently used matrix showing relations between product value items and capabilities can be created by query on the model. Adding a shortcut to the metamodel would allow the architect to specify intent that such a relationship exists in advance of actually creating the details in the model.
Consider Capability supports ValueStreamStage as the shortcut, justified by Capability producing Outcome valued by ValueItem produced by ValueStreamStage. This avoids a shortcut whose definition falls outside of the Customer package and would put it in the Capability/ValueStream crossmap package (per BACM11-9).
JSON is an increasingly popular serialization format. JSON-LD provides some key additional capabilities.
Current name can be confused with "provider" association that links Outcome with LegalEntity. This association links LegalEntity with Offering. Affects all product diagrams.
BACM has this as an association prototype with semantics of inheritance between instances (that are also classes) to conform to MOF. RDFS already has the subClassOf and subPropertyOf predicates and generalizes_0 should be translated into one of these predicates.
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.
On reviewing the non-generated content, errors were noted.
In the current model, strategy is disconnected from capability, except for the ability to define capabilities needed to execute the strategy. Strategy can currently establish Ends and Change for concepts of the AbstractOperatingModel. The ability of an "executive" capability to define Means, Ends, Initiatives, Change and StrategyModel is missing from the metamodel. If this connection is added, the modeler can define an "executive" capability with the ability to produce Outcomes that establish definitions of Means, Ends, Initiative, Change and StrategyModel. This "executive" capability can have an "executive" Role that represents givernance responsibility and decision making authority with the Role assigned to a Performer/OrgUnit.
belongsTo_2 has AbstractBusinessObject as target. Perhaps this should be StatefulThing, which allows ObjectRelations as a subclass.
The "stateOf" target must be an AbstractBusinessObject. It is not possible for a model to use "stateOf" to specify the existence or non-existence of a relationship such as ObjectRelation since this target type is incompatible with AbstractBusinessObject.
The metamodel allows Performers to belongTo OrgUnits, but not AbstractBusinessObjects. Need to find a suitable phrase to label this relationship once it is added to the metamodel.
Since the addition of StatefulThing, the Capability diagram is very complicated.
CapabilityImplementation can aggregate Performers, but this is abstract and used for planning. It should be possible to designate a Performer/OrgUnit as an implementation (actual or planned) for a CapabilityImplementation.
CapabilityImplementation can implement_5 AbstractCapability, but cannot implement Process because the meta-association to allow this is missing from the metamodel
The text of incorporates_3 states that it "refines the incorporates_0 association". However, there is no syntactic indication of this and no tagged value. Consequently, the generalization assertion that should appear in both the MOF and the OWL is missing. This is also the case for incorporates_4 in the OutsourcedServiceOffering diagram.
Some composition ("owns_") associations are ordered but ordering does not translate to any OWL theorems.
Adding this specialization would open a lot of other connections to Capabilities (e.g. that produce Offerings)
The target of isAbout is currently restricted to BusinessObject but should be broadened to any concept in the AbstractOperatingModel or AbstractValueModel (except abstract constructs such as ValueStreams and Capabilities as those are documented in the business architecture model)
Resource only appears as the target of a ResourceRole relationship. It would only be used in a model in conjunction with another metaclass such as BusinessObject. So a building used as a resource would have two metaclasses: BusinessObject and Resource. The Resource metaclass is only needed to allow use of the ResourceRole relationship. Changing the metamodel so that AbstractBusinessObject is the target of ResourceRole eliminates the need to define model elements with two metaclasses to allow them to be used with ResourceRole.
EA notes must contain definition and may contain usage and constraint paragraphs.
In MOF metamodeling, OCL and other constraints apply to instances. In the BACM, these instances are also classes and inherit from their meta-classes (same for associations). In the translation to OWL, there is no instance/metaclass association and no mechanism (other than punning) that is useful. The instance model in OWL is created by specializing the BACM base model. E.g. VS is a specialization of ValueStream and VSS is a specialization of ValueStreamStage. But [VS owns VSS] must be stated for VSS to exist and [VS1 owns VSS] may not be stated for VS1 not equivalent to VS. This is a requirement on the ontology maintainer, not a requirement on the individuals that can be addressed by an OWL reasoner.
The abstract syntax of this allows for value fit between value item and customer segment to be rolled up into an overall value fit between the value proposition and the customer, but it permits a lot of nonsense constructions as well. Consider splitting ValueCharacteristic into two parts: one between ValueProposition and Customer, and the other between ValueItem and CustomerSegment and have the latter owned by the former.
The MOF XMI owns_0 association is translated to an owl:ObjectProperty that is used with appropriate cardinalities in object property restriction axioms. But there is nothing that indicates that the association and its object property restrictions should have the cascading delete semantics. In the MOF2RDF specification, this is indicated by marking the object property as a subproperty of a "well-known" object property named "hasPart". The OWL version of BACM should follow this pattern.
Policy is a common business concept. It is specified in the BIZBOK. Policy is also defined in the BMM.
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.
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.
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.
The BIZBOK introduces the notion that value streams include the concept of a binding business object(s) whose state, together with entry and exit criteria controls the sequencing of value stream stages. How should BACM represent this concept? Is it explicit in the metamodel, or is it the result of analysis or some combination of these?
The metamodel does not require Outcomes to be Produced by a Capability. Such Outcomes are used to model events that occur outside the capability map of the business, such a customer requesting to purchase an item the business has. The BACM metamodel does not have a way, other than an annotation, to indicate that the source of an Outcome is a Performer(Customer). An alternative approach would allow the customer to have capabilities that would produce such outcomes, but this would add model complexity with little benefit other than providing a connection between a Customer and an Outcome. Note that if BACM11-22 is adopted, outcomes are used to trigger value streams and such a connection between Customer and Outcome becomes critical.
If such a relation is added to the metamodel, it should have a plausible interpretation when used to link an Outcome to a Performer that is in a Role with the Capability that produces the Outcome.
The BACM allows definition of an Outcome that is needed by a Capability and/or is an entryCriteria for a ValueStreamStage. Such an outcome can often be identified with a causation agent that is external to the organization. A modeler could resolve this by inventing a Capability (e.g. responsible for having a Customer create an order for a Product) that is in the external stakeholder environment and not in the enterprise environment. Alternatively, a new association could be created allowing such Outcomes to be associated with a Customer and indicating causation.
ValueStreamStages are commonly ordered in display.
There is a question about whether this implies an operational ordering that disallows temporal overlap and what semantics this ordering might be based on. This issue also relates to BACM11-3 concerning entry and exit criteria for ValueStreamStages.
There is also a technical issue. UML allows for ordered associations. In practice these involve tagging links with an ordering value that is used to control the order in which links are iterated. This is also permitted in MOF. However, the actual ordering cannot be specified for the meta-model elements, only for their instances (which are the model classes).
One solution would be to add a property to the ValueStreamStage whose value controls the ordering. However, MOF properties are typically translated to OWL as DatatypeProperties and have semantic consequences for individuals. A better solution for OWL would be to define an AnnotationProperty that either orders ValueStreamStages directly or defines an ordering value. This implies a UML/MOF Comment attached to each ValueStreamStage, whose body contains a predefined keyword and an ordering value. Alternatively, a Comment could link to two ValueStreamStage instances and specify the ordering relation between them.
The BACM uses Outcomes to connect AbstractCapabilities, AbstractProcesses and (with BACM11-22) ValueStreamStages. These Outcomes may imply ordering relationships between these activity meta-concepts. In addition, architects often want to define high level processes and workflows to associate with ValueStreams. Should the BACM define an ordering semantic and provide guidance on how to use it? What would the ordering semantic look like.
The addition of entryCriteria linking Outcome to ValueStreamStage appears to eliminate the need for the triggers association, since triggering is one of the functions subsumed by the entryCriteria relation and would imply the existence of an identical entryCriteria relation.
Consider whether/how to implement this concept which is defined in the BIZBOK and the Guild Metamodel whitepaper.
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.
In the OWL, namespaces were translated as IRI segments. Object properties and datatype properties were considered to be in the namespace created by their owning class (class stereotyped associations are reified in the translation to XMI and OWL). This made the use of qnames infeasible as the name part of the qname cannot contain multiple segments. Yet simple names cannot be used in the XMI or OWL because of name conflicts that are resolved by including the owning class namespace.
For versioning analysis, it is useful to have stable UUIDs for each element in the metamodel. These appear in the XMI and are used to link together elements of the metamodel. They are also in the EA UML model, but are not typically shown to the modeler. The properties of an element may change in editing, but the UUID does not, allowing change analysis to be performed on different versions of the metamodel. The OWL generation did not include the element UUIDs.
When the association names were suffixed to avoid duplicate names, some of the shortcut PathSpecification tag values were not updated. The program that generates the MOF XMI file was not reporting the validation failures because of a programming error.
See summary
Many ontology programs rely on or optionally support "rdf:label" for the display label in lieu of using the actual URI. This is recommended practice.
Shortcut constraints appear to be duplicated. This is not the case in the UML model, so the problem appears to be in the program that converts the EA XMI export to MOF XMI.
The justification for namespaces is to permit parts of the model to be used independently. The current packaging is close, but crossmaps between value stream and capability are defined in Capability and crossmaps between ValueItem and Outcome are defined in Customer. Customer mixes together Journeys and Value Streams. Consider repackaging to eliminate crossmaps from the core packages and add new packages with just the crossmaps. This would also benefit use of the OWL as a group of ontologies instead of one large one.
The turtle file currently uses the old, insecure http protocol and per SMSC policy must use https.
The resolution to this issue mainly impacts the machine-readable turtle file and should not impact the specification document aside from any place where the URI for the turtle file is mentioned.
Having this axiom explicit means that these classes can never be made subordinate to an ontology that is reusing the BACM ontology (e.g. such as an integrating or bridging ontology).
This association between Outcome and AbstractBusinessObject is undocumented. The association documentation is in generated material and several sections will be regenerated.
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.
Defer to Revision Task Force
This Annex provided an example of the external model query facility. This facility was replaced with an adaptation of the SysML V2 external reference in order to gain approva of the OMG Architecture Board.
The annex was removed from the specification in a prior FTF vote.
The example in the annex uses XQuery to access information from the XML serialization of a BPMN process model.
It is a valuable work that is not incompatible with the external reference model as it could become a query part of a de-referenceable URL or it could also be the content of an HTTP POST operation. It can probably survive as an adjunct, non-normative document with some editing to show how to use it with the external reference facility.
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.
Defer to Revision Task Force
These relationships did not appear in any version of the submission and constitute a material change to the beta specification. Recommend that this issue be deferred. Entry and exit criteria can also be determined by analysis of the outcomes of capabilities supporting the value stream stages and selecting specified outcomes to serve as entry and exit criteria. An architect following the BIZBoK Guide(tm) would be able to perform this analysis based on information in a BACM model.
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.
Defer to Revision Task Force
The content of this part of the submission would need substantial revision and it is not material to the completion of the specification document and to the submission of MOF compliant XMI.
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.
Defer to RTF
The changes to the specification are material. See Jim Rhyne comment on the issue, reproduced below:
Diagram 7.3.7.3 adds Means and Initiatives "require" AbstractCapability. This represents capabilities that may be needed to carry out the Means and/or Initiatives; these may not be a part of the steady state model of the business. The issue to be resolved is whether AbstractProcess can also be "required" by Means and/or Initiatives. This would represent processes and activities that would be needed to carry out the Means and/or Initiatives. It is unclear whether this new relationship is primary or can be derived from other relationships (e.g. via required capabilities).
It also adds "implements" from CapabilityImplementation to Initiative. CapabilityImplementation represents an abstract specification of resources and performers. The "implements" association should be a shortcut, as it is supported by role assignments of the Resources and Performers to the Roles of AbstractCapability which is "required" by Initiative.
CapabilityImplementation Resources and Performers can also be assigned to Roles of AbstractProcess. There is no shortcut association "implements" between CapabilityImplementation and AbstractProcess. This should be added to avoid having to specify the details of such assignment as individual Role assignments.
Once the "implements" shortcut association between CapabilityImplementation and AbstractProcess is added, the "implements" shortcut association can be added between AbstractProcess and Initiative.
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.
Resolution requires substantial change to the BACM metamodel
Implementing a domain of individuals and assertions (e.g. OWL 2) would require adding many more classes and associations to the metamodel with consequences unanalyzed at this time.
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
Add the participate association as a shortcut
Add the participate association as a shortcut. Define OCL 2 expression of the shortcut function. Create new diagram "Participant" to show the metamodel elements referenced in the OCL expression.
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.
Edit the EA model to reverse the text arrowhead direction
Edit the EA model to change the direction of the text label arrowhead.
Generate the SVG version of the diagram. Generate the replacement RTF for 7.3.4
Two generalization relations are missing from this diagram between Organization::Resource and Organization::Performer as less general and Strategy::AbstractOperatingModel as more general
Add the missing generalization relations to the 7.3.7.1 OperatingModel
Add the missing generalization relations to the 7.3.7.1 OperatingModel
CustomerJourney, CustomerJourneyStage and Touchpoint are missing from this diagram
Add the missing classes and the generalization relations
Add the missing classes and the generalization relations
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.
Revision to generally allow generalizes, owns and aggregates between BusinessElements
The EA metamodel is revised to allow generalizes, aggregates and owns associations between BusinessElement concrete subtypes, subject to the constraint that the participating instances must be of the same concrete type. This is enforced by a set of OCL 2 constraints associated with the BusinessElement.
In addition, OCL 2 constraints on Capability disallow generalizes and aggregates links between Capability instances.
In addition, OCL 2 constraints on ValueStream disallow generalizes, owns, or aggregates links between ValueStream instances.
In addition, OCL 2 constraints on ValueStreamStage disallow generalizes and aggregates links between ValueStreamStage instances.
In addition, OCL 2 constraints on CustomerJourney disallow generalizes, aggregates or owns links between instances of CustomerJourney.
In addition, OCL 2 constraints on CustomerJourneyStage disallow generalizes and aggregates links between instances of CustomerJourneyStage.
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.
Clarify the SMOF requirement and provide additional diagrams
The changes affect all of section 7.3.1 which is to be replaced by the attached Word file. Prose changes clarify that SMOF allows multiple metaclasses and eliminates the MOF requirement of classifier disjointness. Consequently, additional diagrams are introduced to explicitly specify disjoint constraints. These disjoint constraints also appear in the MOF compliant XMI as OpaqueConstraints specified in the SMOF language. The consistency of the resulting model is tested by translating it into OWL and using a reasoner to determine any inconsistencies.
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).
Section 2 of the document is replaced
Section 2 of the document is rewritten to establish conformance levels in four independent aspects: content completeness, SMOF capability, Shortcut capability, MOF extension [MEF] capability.
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.
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).
RDF, OWL, SPARQL and RDF are references, not symbols or abbreviations*
Change the places where these abbreviations are used to make it clear that they are references. Update the Non-normative references to be the current versions of each specification
The definition of shortcut does not match its expression in the MOF translation.
Changes to 7.2.1 and 8.1 to clarify the interpretation of <<shortcut>>
Changes to 7.2.1 adopted in BACM-44 and BACM-39 clarify that <<shortcut>> stereotypes are treated as <<class>> stereotypes with the addition of specializing BACMShortcut. No changes are proposed in this resolution.
Changes to 8.1.1 clarify how <<shortcut>> associations are represented in the MOF compliant XMI and how the OCL constraints representing the shortcut semantic are structurally specified and how they should be implemented by a modeling tool.
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.
Rename duplicate named association in the UML model
Rename the duplicate named associations by suffixing them with an underscore and a number. Add prose to section 7.2 of the document to describe the effective interpretation.
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.
Add abstract superclass and terminate single association in superclass
UML does not provide a way to specify multiple types for association ownedEnds or a semantic that would interpret this case as a union. Change the UML model to add an abstract superclass in the three cases where this occurs in the model and terminate a single association at this superclass. Add generalization arrows from the classes to be unioned to this superclass. Then delete 7.2.6 from the specification document. The new superclasses are JSTP in the ValueFit diagram, APCICB in the OutsourcedServiceOfferingDiagram and VSVSS in the Process diagram.
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.
Replace class named IRI with datatpe named IRI
Delete the class named IRI. Create a datatype named IRI. Change the type of the resourceIdentifier ownedAttribute to refer to the datatype named IRI. Change the pkgele.py module to handle uml:DataType elements.
Change the BACMMOF2OWL.py program to recognize the IRI datatype and map to xsd:anyURI.
The "recordedAs" and "stateOf" associations between Outcome and AbstractBusinessObject overlap.
Edit model to separate affected associations
Edit model to separate affected associations and republish
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.
This issue is about the process of producing the specification and not its content
N/A
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.
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.
No changes are made to the specification
As noted in the comment of 2/16/2023, the submitters decided to resolve the conflict between visual and descriptive complexity in the specification document by using stereotypes in a UML model that is transformed into a MOF model. The issue author feels that the specification document should actually use the MOF model and not the UML model. It is not an OMG requirement to do this and other specifications have taken this path prior to BACM. Addressing this issue would require months of work in creating a new document that would be very different from that approved by the AB and the DTC and would likely require re-approval. It is not clear that this degree of change would comply with the P&P policies for FTFs. Consequently, this proposal recommends rejection of the issue.
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.
Changing of names is allowed in instancing
When an instance is created of an association, the instance becomes a member of the association type. When instances can be named, there are no restrictions on the names that can be used. When an association instance is created, the link ends become instances of the owned ends and member ends of the association and must satisfy the semantics of those owned ends and member ends with respect to instance types and quantification. These instances are reinterpreted as MOF associations, creating a new MOF model that is consistent with the MOF metamodel.
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
Change EA model and regenerate diagrams and prose
Change the stereotype of ValueStream produces ValueProposition to <<shortcut>> and add PathSpecifications tagged value to the produces association to implement the constraint that this association is consistent with the ValueProposition aggregating some ValueItems produced by ValueStreamStages owned by the ValueStream..
Change the stereotype of ValueStreamStage produces ValueItem to <<shortcut>> and add PathSpecifications tagged value to the produces association to implement the constraint that this association is consistent with the ValueItem valuing some Outcomes produced by Capabilities that support the ValueStreamStage.
Change the stereotype of Capability supports ValueStreamStage to <<class>> and delete the PathSpecifications tagged value.
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 beta specification is clear and unambiguous about inclusion of SMM
The beta specification defines specializations of SMM classes and associations in the SMM subpackage. Adding an import of the SMM metamodel to the BACM metamodel, along with the specializations explained in the BACM specification would not add any new information to the specification.
Makes changes to document shell docx and the EA model to eliminate the terms and concept
Change the document shell docx to eliminate mentions of ValueCategory and categorizes. Regenerate the text documentation from the model and replace the affected sections of the document (Capability and Customer) with the new sections.
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.
Merge this issue with BACM-83
The proposal to resolve BACM-83 is able to address this issue. A convincing argument to restrict the associations between ValuePropositions to being only that of owning was not found. The default model will allow generalizes, owns and aggregates at the discretion of the business architecture modeler.
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?
The OWL 2 Turtle draft ontology made available as informative adjunct
On approval, an OMG document number will be obtained for the attached OWL2 Turtle file (or its revision).
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.
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.“
This issue should be merged with BACM-6
BACM-7 (a proposal to resolve BACM-6) which has been adopted by vote, proposes to remove Section 9 from the specification. Another issue has been recorded to publish the Section 9 content and other material as informative guidance. There are no proposals at this time to resolve this issue.
SIMF does have a RFP, though that does not seem to be proceeding.
Remove the reference to SIMF
Delete the following prose from page 2 of the specification.
"[SIMF] Semantic Information Modeling for Federation (SIMF) http://www.omgwiki.org/architecture-ecosystem/doku.php?id=semantic_information_modeling_for_federation_rfp"
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”?
Replace ambiguous uses of "user" in section 7 with "business architecture modeler'
Replace 6 occurrences of "user" in 7.2.1 with the term "business architecture modeler".
Replace 2 occurrences of "user" in 8.1.2 with the term "business architecture modeler".
It’s odd that some references are version-specific, others are not - was that intentional?
Revise the reference section
Replace all version specific URLs with the generics.
Move references to the non-normative subsection.
Delete RDF-star and OpenCypher references
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
Fix the notes in EA then regenerate the document.
N/A
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
Replace 7.3.1.1
This proposal incorporates model changes to support the generation of MOF-compliant XMI by transforming the XMI generated from the source model according to the normative specifications in section 7.2. It also incorporates editing changes that were made in the BACM_Model package to remedy a failure to update the text associated with changes to the diagrams published in BACM 1.0b1 (dtc-22-06-01).
Because the diagrams and text of section 7.3 are generated from the UML model, the number of editing changes would be very large. Consequently this proposal replaces 7.3.1.1 in its entirety. These changes do not effect the remainder of the specification.
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.
Close this issue as it duplicates an issue already in ballot
Duplicate of ballot #1 Issue #1
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.
Section 7.2.2 is replaced and Section 7.2.3 is deleted
The attached Word document replaces section 7.2.2.
Section 7.2.3 is to be deleted in entirety and the following parts of 7.2 are to be renumbered accordingly.
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 was resolved prior to publication of the beta specification
The categorization mechanism was replaced prior to AB approval of the beta specification. The issue was recorded to preserve the history of changes. The beta specification requires MEF, which can be used to create profiles allowing for the categorization of BACM model elements by the definition of stereotypes and application of these stereotypes to model elements.
An issue has been created to address compliance requirements for MEF
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.
Remove Section 9 from the specification document
Section 9 consisted of non-normative responses to non-mandatory requirements in the RFP about alignment of BACM with other OMG specifications and with IT architectures. This material is provided as guidance to architects and organizations wishing to use BACM in conjunction with other OMG and non-OMG specifications. The material is expected to change rapidly. The proposal is to remove Section 9 from the specification and publish it as an informative adjunct document.
The use of “parent” to mean not a superclass but the class of an instance is unconventional and likely to confuse.
Replace "parent" with more specific terms
Replace use of the term "parent" with more precise terms such as "meta-class", "aggregator", "owner", "generalizing"
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 issue is moot as the query mechanism is not present in the beta specification
This issue was addressed prior to the release of the beta specification as the query mechanism in the submission was replaced by the external reference mechanism adopted from SysML V2. This change was approved by the AB.
However, an example was presented in Annex B of the beta specification, and this example has been removed in Ballot #1 of this FTF. So there is no longer any substance to this issue.
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.
Define M1 in section 4 of the specification
The document uses the term "M1" to designate models that are derived from the BACM metamodel. The OMG has dropped this terminology, so its continued use in the specification must be supported by a definition. This proposal provides such a definition in section 4 of the specification.
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.
Edit the diagram in the EA model to reverse the direction of the association
Edit the EA model to change the association direction.
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?
Rewrite and consolidate prose description of instancing
This proposal is mostly resolved by the proposal attached to BACM_44 (to resolve issue BACM-43) and a proposal (BACM-67) to resolve issue BACM-45.
The remaining part of this issue, that the BACM metamodel does not have a distinct domain of individuals (viz. the domain of classes and object properties as distinct from the domain of individuals and assertions) is unresolved. This proposal creates a separate issue (BACM-68) with a proposal to defer.
The treatment of n-ary associations as a set of distinct tuples seems unnecessary and logically suspect.
Substance of the issue is unclear
As noted in the comments, the use of tuples to define semantics of n-ary associations is well-defined in the literature and is neither unclear nor "logically suspect".
The use of "tuples" occurs in 7.2.1, which is rewritten in proposal BACM-44 (to resolve issue BACM-43).
It also occurs in 7.2.5. This section was reviewed and found to be both clear and logically sound.
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 RFP only requires a Capability perspective
The RFP only requires a Capability perspective. The submission includes that and other perspectives deemed as very desirable in the RFP.
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.
The Glossary in Annex A is deemed sufficient
It is possible to read the RFP as requiring a glossary for each domain of the metamodel. However, this was not the understanding of the RFP writers and no issue was raised during the RFP issuance. The specification provides a required glossary in Annex A.
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 issue appears inapplicable to the beta specification
This issue appears to address a prior submission, not the specification as approved by the AB and issued as dtc-22-06-01.
The term “class association” is used in several places - it should be “association class”.
Both class association and association classed are used in OMG specifications
A review of OMG documents and Policies and Procedures was unable to determine that this was an improper use.
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
Remove Annex B from the specification document
Remove Annex B from the specification document. An issue is created to determine the disposition of the Annex B content.
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 term leg is defined in BACM-44 the proposal to resolve BACM-43
The term "leg" is justified because this section of the specification is defining the translation from the UML-based diagrams in the specification to MOF-compliant XMI. Since n-ary associations and association classes are not part of MOF, these forms are translated (reified) into classes and generated associations. The term "leg" designates the generated associations to distinguish them from other associations.
If BACM-44 is approved, this issue should also be resolved
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.
Replace the second paragraph of 7.2 in its entirety
Replace the second paragraph of 7.2 -
"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."
with
"An implementation of the specification must conform to the metamodel expressed in the normative XMI file that is part of the specification. The diagrams in this document make use of stereotypes to eliminate detail that is present in the normative XMI file and make the diagrams more readable. The following paragraphs and subsections in this document explain how to interpret these stereotypes and how they are translated in the MOF-compliant, normative XMI file. In any case where the diagram and the interpretation rules appear to disagree with the normative XMI, the normative XMI is the authoritative source."
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>>
Attached file replaces 7.2.1 para3 et seq
The description of the translation to MOF is completely rewritten and all paragraphs of section 7.2.1 starting with paragraph 3 are replaced by the attached Word document content.
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).
Add a reference to revised section 7.2.2 in the paragraph of 7.2.4.2
A revision to section 7.2.3 is proposed in BACM-44. This revision explain that some model elements that are instances of metaclasses represent collections of things with identical or similar characteristics (i.e. they are sets defined by the structural properties of the model element). This association allows the modeler to create semantic hierarchies of such model elements.
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.
A MOF-compliant XMI file is produced by a transformation program
A Python 3 program was written to input the exported EA XMI file, perform the transformations defined in section 7.2 of the beta specification, and output a MOF-compliant XMI file. This file has been subjected to automated and hand checks for correctness. It has also been analyzed by the OMG XMI compliance tester, producing some minor errors.
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).
This issue is resolved by proposal BACM-44 to issue BACM-43
The revisions proposed in BACM-44 explain the "leg" as designating associations generated in the transformation to MOF-compliant XMI that reifies n-ary associations and association classes. The term "leg target" refers to a model element that is at the opposite end of a "leg" association from the metaclass that is generated to represent the n-ary association or class association. A "leg target" may be a generated class resulting from this transformation process. The abstract syntax for this is in Diagram 7.3.1.6 and the transformation description in the proposal BACM-44
· 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.
