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.

Allow non-initial needs_0 and non-final produces_0 associations

Change the needs_0 and produces_0 <<class>> associations into <<association>> classes with "src" and "tgt" associations. This transformation allows needs_0 and produces_0 to have features, but otherwise does not change the representation in MOF.
Add a "non-initial" Boolean feature to needs_0 whose default value is False, meaning that the Outcome would initiate a new execution of the Capability. A default value of True means that the Outcome enables the current execution to continue.
Add a "non-final: Boolean feature to produces_0 whose default value is False, meaning that the Outcome produced does not signal the end of execution of the Capability. A default value of True means that the Outcome is produced at the termination of execution of the Capability.
Add a "depends" <<shortcut>> association from AbstractCapability to AbstractCapability. If Capability A depends on CapabilityB, there should be a chain of associations and classes such that Capability A produces a non-final Outcome OA that is needed by Capability B, which produces an Outcome OB that is needed non-initially by Capability A. This pattern may be extended by Outcome decomposition.
Add the following as the PathSpecification tagged variable on the "depends" <<shortcut>> association: "depends_0.AbstractCapability.produces_0.Outcome.stateOf.AbstractBusinessObject.^related_1.ObjectRelation.related_1.AbstractBusinessObject.^stateOf.Outcome.^produces_0.AbstractCapability.depends_0"

Note: the attached DOCX file discusses the rationale for this change and provides an example of use.

BACM11-65 resolved BACM11-64 by undoing a prior proposal that added StatefulThing to the model. However, there were impacts on the OperatingModel diagram (7.3.7.1) that were not noticed at the time.

Fix errors and simplify OperatingModel diagram (7.3.7.1)

Resource is removed along with generalization - was changed to AbstractBusinessObject in BACM11-67 resolving BACM11-66.
Performer and generalization deleted - specializes AbstractBusinessObject.
Offering and generalization deleted - specializes AbstractBusinesssObject
ObjectRelation and generalization deleted - specializes AbstractBusinessObject
StatefulThing was inserted in diagram replacing AbstractBusinessObject with generalization then removed in BACM11-65 resolving BACM11-64 with AbstractBusinessObject replacing it.
All other classes and generalizations remain.
All classes and generalizations have been repositioned for clarity.

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.

Add uses_0 and uses_1 indicating use of AbstractOperatingModel concepts by Means and Initiative

Remove the require_0 and require_1 class associations from the model.
Remove the implements_3 class association from the model.
Delete all classes from the diagram.
Delete the StrategyNeeds diagram (7.3.7.3).
In the Strategy diagram (7.3.7.2):
rename impacts_0 and impacts_1 as baseline_4 and baseline_5 respectively.
add uses_0 <<class>> association from Means to AbstractOperatingModel
add uses_1 <<class>> association from Initiative to AbstractOperatingModel

The result of these changes is that the execution dependence of Means and Initiatives on concepts of the AbstractOperatingModel is represented by the uses_0 and uses_1 associations. Consequently, the StrategyNeeds diagram (7.3.7.3) is redundant and is deleted from the model.

The renaming of impacts_0 and impacts_1 creates a uniform interpretation of baseline WRT Ends and Change such that the Ends and Change describe desired changes to the AbstractOperatingModel and AbstractValueModel elements targeted by baseline.

Note that the same AbstractOperatingModel concept may be targeted by both baseline and uses, meaning that the concept is used by the Means/Initiative and must be changed to be successfully used.

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.

The generalizes_0 association in MOF should not be translated into OWL

The OWL 2 ontology language already has generalization as a primitive, allowing both rdfs:subClassOf and rdfs:subPropertyOf as predicates in the language. Generalizes_0 is a meta-association whose instances would be used by modelers to represent generalization between two model elements. The BACM OWL ontology does not distinguish meta- and model levels and model instancing is effected by specializing meta-classes and meta-properties as model classes and model properties, using the existing RDFS predicates. Removing generalizes_0 from the set of meta-associations translated into OWL does not reduce the representation capabilities of the metamodel and its ontology. Translating it as an object property gives the wrong semantics. The Python program that generates the OWL ontology from the MOF XMI is changed to eliminate the translation of this association into OWL.

Current name can be confused with "provider" association that links Outcome with LegalEntity. This association links LegalEntity with Offering. Affects all product diagrams.

No consensus was reached on this issue

The change would not significantly affect the ability of the metamodel to represent business concepts and there was little enthusiasm in the RTF for the change.

On reviewing the non-generated content, errors were noted.

Editorial changes to the shell document

Editing to correct editorial mistakes in the 1.0 specification document.

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.

Add implements_6 to Roles, update documentation, add staffs shortcut

Add implements_6 between CapabilityImplementation and AbstractProcess with the meaning that a CapabilityImplementation represents an implementation configuration of the AbstractProcess.

Change documentation of implements_7, PerformerRole and ResourceRole to clairfy that Roles are not shared - they belong to the CapabilityImplementation, AbstractCapability or AbstractProcess. When implements_5 or implements_6 exists, the Roles of the AbstractCapability or AbstractProcess should be "cloned" and specialize the Role each is cloned from and these clones are owned (implements_7) by the CapabilityImplementation.

Add "staffs" shortcut between OrgUnit and CapabilityImplementation with the meaning that the OrgUnit(s) will supply Performers and AbstractBusinessObjects to be assigned to Roles of the CapabilityImplementation.

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

produces_1 and produces_2 become shortcuts

The produces_1 and produces_2 relations become shortcuts (ValueStream). The supports relation becomes an assertion, not a shortcut. Capability and AbstractCapability are added to the ValueStream diagram to show the shortcut paths for produces_1 and produces_2. The CapabilityValue diagram is deleted because it duplicates ValueStream.

The process diagram does not provide a way to represent that one process must precede another.

Add follows relation between AbstractProcess and itself

The follows relationship allows the modeler to represent that one AbstractProcess follows another. The relationship is many to many and has no provision for semantics that would allow a translation to fork/join. There is no provision to specify a message that would be conveyed. The UML association is stereotyped <<class>> so the relationship is reified and may have properties and participate in associations.

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 requirement to support variability can be met in other ways

Capabilities can be associated with CapabilityBehaviors and CapabilityImplementation. Both of these elements can be specialized to account for variations in the behavior and the structure of a capability. A variant CapabilityImplementation can implements_5 a variant CapabilityBehavior, tying the behavior variation and the implementation variations together to create the equivalent to a capability variation.

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.

The desired matrix can be created by querying the model

A matrix showing the connection between Capability and ValueItem can be created by a query that joins the Outcomes produces_0 by the Capability with the Outcomes values by the ValueItem. Given that the produces_0 and values relations likely have small fan-out, the cross-product resulting from the join is likely to be accurate. However, there probably needs to be a restriction to Capability of a certain level to avoid including Capabilities in the composition hierarchy.

The text of the BMM 1.3 document appears to indicate that CourseOfAction can indicate that an Asset is needed by the CourseOfAction. Asset is a superclass of both FixedAsset and Resource. It would seem that this need should be modeled by the Liability that claims the needed Resource, but there is no way to specify that the CourseOfAction creates a Liability.
In addition, CourseOfAction can deploy/need a Fixed Asset or even an Offering, but the same CourseOfAction cannot discharge a Liability claim on a FixedAsset because the abstract syntax permits only discharging Liability for a Resource, not a FixedAsset

This is an issue with BMM 1.3 not BACM

This issue was raised by mistake on BACM. It is being discussed with the BMM 1.4 RTF.

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.

Strategy concepts become specializations of InformationItem

Make Means, Ends, Initiative, Change and StrategyModel specializations of InformationItem - This allows Capabilities and Processes to produce Outcomes that establish stateOf these strategy concepts.

Without changes to the metamodel, suggest using Roles to capture the concept of executive/managerial authority and responsibility. It is not necessary to create a specialization of PerformerRole to accomplish this as the modeler can create such Roles at the model level. It may be desirable to have a distinguished PerformerRole subclass with the intended meaning of executive/managerial authority and responsibility. This suggestion allows a Performer or OrgUnit to be assignTo such a PerformerRole with the implication that the Performer or OrgUnit acquires this authority through the Role. This allows, for example, a CEO Performer to have authority of the Strategy Management Capability and for that Capability to produce an Outcome that establishes the stateOf Means and Ends of a StrategyModel.

The metamodel states that an InformationItem informs_0 an AbstractCapability, meaning that the Capability may select behaviors based on the content of the InformationItem. Add informs_1 linking InformationItem to AbstractProcess to mean that the InformationItem content may determine the actual behavior of the AbstractProcess. Also add informs_2 linking InformationItem to Performer to mean that the actual work done by the Performer can be influenced by the content of the InformationItem. The consequence is that Means, Ends, Initiatives, Change and Directive are all capable of influencing behavior of Capability, Process and Performer. In the case of Directive, the influence should carry the additional meaning of being mandatory.

Making the strategy concepts specializations of InformationItem means that they are descriptive (and desired). The informs_? relationships capture the idea that the Capabilities, Processes and Performers interpret and act on their interpretation of the strategy concepts.

Add uses_0 as a relationship between Means and AbstractOperatingModel with the meaning of indicating AbstractOperatingModel concepts that would be needed to implement the Means.

Add uses_1 as a relationship between Initiative and AbstractOperatingModel with the meaning of indicating AbstractOperatingModelConcepts that would be needed to implement the Initiative.

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.

Add code to BACM2MOF.py to fix the generated XMI

A <<class>> association may specialize another <<class> association by redefining the ownedEnds of the specialized association to reference the ownedEnds of the generalizing association. However, both associations are transformed to a class with the same name and a "from" association and a "to" association. After this transformation, the class generated for the specializing association needs to specialize the class generated for the generalizing association. Additionally, the "from" association needs to specialize the generalizing "from" association, and the "to" association needs to specialize the generalizing "to" association. The change is to be added to BACM2MOF.py, the program that converts the EA generated XMI file into a MOF XMI file.

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)

Allow isAbout to target StatefulThing

Define the target of isAbout to be StatefulThing This allows an InformationItem to be "isAbout" a business object such as an assembly robot. Note that isAbout can only capture intrinsic properties of StatefulThing. The recordedAs relationship should be used to capture state.

Since the addition of StatefulThing, the Capability diagram is very complicated.

Create a new diagram and move Outcome related concepts

Create Outcome diagram in Capability package and move the Outcome related concepts into this diagram.

Adding this specialization would open a lot of other connections to Capabilities (e.g. that produce Offerings)

Resolved by BACM11-65

BACM11-65 resolves this issue along with two other issues.

Some composition ("owns_") associations are ordered but ordering does not translate to any OWL theorems.

Ordered associations are removed from the metamodel

All ordered associations have been removed from the metamodel. ValueStreamStage ordering is specified by a class (static) attribute whose value is undefined in the metamodel. Modelers should specify a value when creating instances/subclasses. This defines a strict ordering for presentation.
CustomerJourneyStages are ordered by a follows_2 relation that is many-to-many in the metamodel. In the case of many follows_2 successors, the metamodel does not allow criteria to specify which groups of successors are entered. It also does not allow criteria to specify which groups of predecessors are allowed to enter a successor. The modeler is expected to provide descriptive text and/or annotation text to describe the expected behavior. The alternative resolutions were deemed too complex for business architects and can be specified in execution-oriented models such as BPMN.
AbstractProcesses are ordered by the follows_1 relation with semantics and usage as described for follows_2.
Touchpoints can be ordered by the follows_3 relationship.

CapabilityImplementation can implement_5 AbstractCapability, but cannot implement Process because the meta-association to allow this is missing from the metamodel

Create implements association

Create implements_6 shortcut association between CapabilityImplementatioon and AbstractProcess representing that the CapabilityImplementation implements the AbstractProcess. The shortcut should check that the CapabilityImplementation includes Roles that are associated with the AbstractProcess.

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.

Create staffs shortcut

Create a staffs shortcut association between CapabilityImplementation and OrgUnit to represent that the OrgUnit provides Performers and AbstractBusinessObjects to staff the CapabilityImplementation.

Replace the assignTo_3 shortcut association with an aggregates_3 association that collects Roles in the CapabilityImplementation.

Change the implements_5 and implements_6 relationships to class associations from shortcuts.

The net of these changes is that CapabilityImplementation is now a collection of Roles and possibly Performers and AbstractBusinesssObjects. The Roles aggregated by a CapabilityImplementation should be Roles ofCapability for the Capability implement_5 by the CapabilityImplementation, but this is not enforced by the abstract syntax. The CapabilityImplementation may aggregate additional Roles that are presumably defined by a CapabilityBehavior variant of the Capability.
For AbstractProcess that is implements_6 by a CapabilityImplementation, the Roles aggregated by the CapabilityImplementation should be exactly the Roles ofProcess of the AbstractProcess. This is not enforced by the abstract syntax.

belongsTo_2 has AbstractBusinessObject as target. Perhaps this should be StatefulThing, which allows ObjectRelations as a subclass.

Covered by BACM11-83 and BACM11-65

Covered by BACM11-83 and BACM11-65

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.

Create ValueCharacteristic_1, move item and segment associations

Create ValueCharacteristic_1 as association stereotyped class (will appear as a class in MOF). Relocate item and segment associations from ValueCharacteristic to ValueCharacteristic_1. Create owns_4 association from ValueCharacteristic to ValueCharacteristic_1.

This splits the value characteristic concept into two syntactic parts: an overall part that characterizes the fit of the ValueProposition to the Customer; a detail part that characterizes each ValueItem of the ValueProposition to a curresponding CustomerSegment part of the Customer.

Policy is a common business concept. It is specified in the BIZBOK. Policy is also defined in the BMM.

Create Directive in BACM and define potential alignment with BMM

Add Directive metaclass as specialization of Means.
Specify that Directive can be linked to the Directive metaclass in the BMM.
See attached whitepaper that describes a non-normative conceptual alignment between BACM models and BMM models. Implementing the alignment with BMM can be done using the ExternalRelationship facilities already extant in the BACM V1.0, so no changes to the BACM metamodel or specification would be needed to implement the alignment. The attached document is intended to be published as a non-normative adjunct document to the BACM specification.

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.

Declare the owns_o object property as a subproperty of MOFSupport:hasPart

The OMG MOF2RDF ontology defines a sub-ontology MOFSupport which defines hasPart as an owl:ObjectProperty indicating that individuals in the range of this object property are existence-dependent on an individual in the domain. OWL 2 lacks a proper notion of existence dependency and reasoners cannot execute or validate this requirement, but a query or a subsumption reasoner can identity sub-properties of this property and drive an external agent to maintain the constraint.

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.

Remove "theBusiness", correct "belongs_to"

Delete "theBusiness" from the model.
Change "belongs_to" to target "OrgUnit" instead of "theBusiness"

EA notes must contain definition and may contain usage and constraint paragraphs.

Change notes to match glossary format

Glossary format requires definition paragraph, may have usage and constraint paragraphs.

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.

ObjectRelation specializes AbstractBusinessObject

Make ObjectRelation a specialization of AbstractBusinessObject. Change BACM_Entities to eliminate BACMRelation/BACMPlainEntity contradiction on ObjectRelation. Change isAbout from a class stereotyped association to an association stereotyped class and make it specialize ObjectRelation. Make Offering an InformationItem.

for review:

--------------
Definition: IsAbout is a binary directed relationship between an InformationItem and an StatefulThing. It specializes ObjectRelation. It designates that the InformationItem is metadata about the StatefulThing.

Usage: AbstractBusinessObjects and ObjectRelations have only identity and immutable properties (a.k.a. intrinsic properties). An InformationItem that isAbout an AbstractBusinessObject can only hold metadata bout this identity and the intrinsic properties. To model the recording of state, modelers should use recordedAs.
--------------

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.

Define an owl:AnnotationProperty to identify ownership semantics on the ontology entities

This issue duplicates BACM11-8 and is resolved by BACM11-24

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.

Define belongsTo associations

Add belongsTo_1 class association between Performer and OrgUnit with the meaning that the Performer belongs to the OrgUnit. This is aggregation, not ownership.
Define belongsTo_2 class association between AbstractBusinessObject and OrgUnit representing that the AbstractBusinessObject belong to the OrgUnit. This is aggregation, not ownership.

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.

Material originally in Section 9 of the revised submission is obsolete

Because of changes in the metamodel, the material in this document is obsolete. There is no requirement to revise the material as an ancillary document to the specification as it never appeared in a public version of the specification.

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.

Appendix B material is obsolete

Changes to the BACM metamodel have rendered this material obsolete. While it could be updated, it is no longer considered to be an essential issue to be resolved by documentation.

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.

Add triggers_0, triggers_1 and triggers_2 associations to metamodel

Add a triggers_0 shortcut association from Customer to Outcome.
Add a triggers_1 class association from CustomerJourneyStage to Outcome.
Add a PathSpecification tag: "trigger_0.Outcome.^trigger_1.CustomerJourneyStage.^owns_2.CustomerJourney.^takes.Customer.trigger_0" to triggers_0.
Add a triggers_2 association from Touchpoint to Outcome.
The semantics of these triggers_0 and triggers_1 is that the customer and/or customer journey stage creates an Outcome that is used as the entry criteria for a value stream stage.
Note that outcomes produced by capabilities, processes and value stream stages are experienced by the customer indirectly via touchpoints. The triggers_2 association captures the concept of an outcome that is produced by the customer at a touchpoint. This outcome association does not participate in the trigger_0 and trigger_1 semantics, but represents a customer response to an outcome experienced at a touchpoint.
Updates Customer diagram, ValueStream diagram and ValueFit diagram attached to this proposal.
This proposal relates to BACM11-47 resolving BACM11-15.

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.

Define a non-semantic integer property for display ordering

Remove the ordered constraint from the owns association between a value stream and its stages. This is difficult to implement in OWL and requires the modeler to manage ordering constants that allow for placement of new value stream stages, the deletion of existing stages and the reordering of stages as the model is developed.
Add a property named presentation_order that is a static attribute (i.e. whose value is fixed for each class). When creating specializations of ValueStreamStage for a ValueStream, the modeler will assign integer initial values to this attribute for each specialization. Tools should use this value to define the presentation order. This property has no other semantic implications for the model.

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.

Define value stream stage dependency

Define value stream stage dependency based on a dependency relationship defined by an outcome that is the exit criteria of one stage being the input criteria for a different stage. Extend this relationship transitively to include the entire value stream as dependency completeness.
Note that this resolution adds no new classes or associations to the metamodel. It provides an interpretation of the existing metamodel that facilitates model analysis and provides methodology for checking the validity of value streams.

See summary

Rename owns-0 to owns_0

Rename owns-0 as owns_0

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.

Delete the triggers association from the metamodel

The addition of entry and exit criteria in resolving BACM11-3 eliminates the need for this association that essentially duplicates the semantic conditions of entryCriteria. As entryCriteria and exitCriteria are both <<class>> stereotyped associations, an architect may create specific properties for them when creating instances.
Note that the BIZBOK describes triggering by stakeholder (i.e. Customer), not by Outcome. See issue BACM11-52 and proposed resolution BACM11-58 that address the association of Customer with triggering Outcomes.

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.

Replace Resource with AbstractBusinessObject then delete Resource from the model

Replace Resource metaclass with AbstractBusinessObject metaclass in Organization diagram as target of assignTo_1 association. Delete Resource class from Organization package.

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.

Appears to duplicate BACM11-52

Duplicates BACM11-52, resolved by BACM11-58.

Consider whether/how to implement this concept which is defined in the BIZBOK and the Guild Metamodel whitepaper.

Duplicates BACM11-52

The BACM allows Outcomes that are needed by a Capability and/or act as entry criteria for value stream stages. BACM11-52 asks for a relationship between Customer and Outcome that would obviate the need for a customer capability to produce the outcome. BACM11-52 duplicates this issue.

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.

Fix the programming error in the app that generates the MOF XMI file

Add code to check the result from executing the code to check the path specifications against the actual model and display an error. Fix all path specifications causing errors in the EA source model tagged values.

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.

Define an AnnotationProperty to annotate the entities with their UUID

In the OWL generation application, output an AnnotationProperty declaration and generate annotation axioms for each entity, taking the UUID from the MOF XMI element that generates the OWL entity.

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.

Implement the generation of an rdfs:label axiom

Change the application that generates the BACM ontology from the MOF XMI to output the element name as the object of an rdfs:label axiom for each model element. This is done and tested as of 2024.03.19

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.

Change BACM MOF to OWL translator to generate https

Change the BACMMOF2OWL.py to generate https instead of http when generating IRIs and profile statements.

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.

Fix code in the MOF translation app that was invoking the generator twice

A programming bug has been corrected that was invoking the constraint generator method twice for each element. Code changes made and tested as of 2024.03.19.

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.

Add entry/exit shortcut associations between ValueStreamStage and Outcome

Revise the EA UML metamodel to add two shortcut associations labelled: "entryCriteria" and "exitCriteria" directed from ValueStreamStage to Outcome.
Shortcut justifications for exitCriteria: (1) ValueStreamStage.produces_2.ValueItem.values.Outcome; (2) ValueStreamStage.^supports.Capability.produces_0.Outcome. Note that produces_2 it itself a shortcut justified by the second justification above. There is no problem using a shortcut to justify another shortcut as long as the justifications are consistent with each other.
Shortcut justification for entryCriteria: ValueStreamStage.^supports.Capability.needs_0.Outcome

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.

Create dot-separated names for object properties and datatype properties

In the MOF XMI translation that reifies stereotyped associations, name the generated associations as <class_name>.<assn_name>. This name syntax is legal in both MOF XMI and in OWL. It resolves name conflicts by prefixing the association name with the name of its owning class.
Carry out the same name translation for ownedAttributes.
This is an exception to the basic name translation that creates namespaces for packages and classes.

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.

No proposal has been produced.

The intense discussion around this issue indicates that an immediate consensus proposal in the remaining few weeks of this RTF is unlikely to be produced. The issue is deferred to a potential BACM 1.2 RTF.

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.

Lack of consensus that a change needs to be made

The initial complain was about the number of prefix definitions needed in the OWL ontology. This led to a larger issue of whether the BACM should be split into several specifications that would be interconnected. The benefit would be that a tool could implement say capability and value without incorporating other perspectives not needed for a present use. This contradicts the conformance requirement. There was little appetite to accommodate this large change, but the issue is a valid one so it is deferred.

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?

The resolution is too complicated for this RTF

The proposal to replace the two binary shortcuts with a ternary (Customer, ProductOffering, ValueProposition) requires a substantial extension of the shortcut path syntax and a reworking of the transformation code that checks the path specification and generates the OCL. This RTF is closing in less than 60 days and there is not time to develop the algorithms and test them. Consequently, the issue is deferred.

This association between Outcome and AbstractBusinessObject is undocumented. The association documentation is in generated material and several sections will be regenerated.

Write documentation for "recordedAs" association

Write documentation for "recordedAs" association in the EA model.

JSON is an increasingly popular serialization format. JSON-LD provides some key additional capabilities.

No proposal has been prepared

It was intended to reuse the JSON serialization from the SysML V2 API specification. On examination, it appears that this would be challenging to re-purpose for BACM in the remaining few weeks for this RTF. Consequently, it is proposed to defer this issue to a possible BACM 1.2 RTF.

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

Change the MOF to OWL generator to stop creating this axiom

The change to BACMMOF2OWL.py to implement this was made on 10 Jan 24.

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?

Absence of experience and consensus

While some practitioners (e.g. Roger Burlton) have proposed principles and methods to accomplish this, there is not much experience and little consensus on what concepts would be needed to align value streams at different levels. Consequently, the proposal is to defer the issue to a future RTF.

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?

Unclear definition of "binding object"

The term "binding object" is used in the BIZBOK(tm) to denote one or more objects that appear to "have an overarching impact on value stream navigation. For example, the state of a shipment would have an overarching impact on a Send Shipment value stream."
Issue BACM11-3 (resolved by BACM11-22) has proposed to express value stream navigation by expressing entry and exit criteria as associations between value stream stages and outcomes. Outcomes are expressions of state of business objects, so per the BIZBOK definition, binding objects might be business objects whose state is expressed by outcomes that are entry and exit criteria of the stages of value streams.
The example binding objects in the BIZBOK examples are a small subset of the potential binding objects described above and it is unclear what criteria is being used to select them. It does not appear likely that discussions with the Guild will produce a clear definition prior to the expiration of this RTF, leading to a proposal to defer the issue.