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?

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?

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

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

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

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

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.

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.

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.

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.

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.

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.

See summary

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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

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

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

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

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.

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.

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)

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

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

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.

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.

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.

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

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

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.

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

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.

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

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.

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.