Business Architecture Core Metamodel - BACM
AbstractAction is used to classify entities that should be disjoint from Capability, AbstractResult and AbstractThing. It is not used for any other purpose in the metamodel.
AbstractResult is used to classify entities that should be disjoint from Capability, AbstractAction and AbstractThing. It is not used for any other purpose in the metamodel.
AbstractThing is used to classify entities that should be disjoint from Capability, AbstractResult and AbstractAction . It is not used for any other purpose in the metamodel.
Definition: The BACMModel represents the root element of a BACM model (i.e. the element from which a tool or person can navigate to every other element in the model)
Usage: A single instance of this class must exist in an instance model
Definition: The BACMElement represents the class of all elements in a BACM model. It provides elements with a name and description and allows elements to be annotated.
Usage: BACMElement is an abstract class and cannnot be instantiated in a model.
Definition: An SmmModel represents the collection of MeasureLibraries and other entities needed to implement a set of measures appropriate to a business architecture model based on the BACM specification.
Usage: SmmModel specializes the corresponding concept from the SMM 1.2 specification. The BACM effectively imports the whole of the SMM specification metamodel
Definition: The StrategyChoices represents a suite of strategies that can be evaluated for selection. Each StrategyModel in a StrategyChoices element shall be considered as alternatives. Alternative StrategyModels may share Means, Ends, Initiatives and Changes.
Usage: There may be at most a single instance of StrategyChoices in a BACM model
Definition: The MeasureLibrary represents a collection of measures (measurement types) that define measurements associated with BACM model elements.
Usage: The MeasureLibrary specializes the corresponding concept from he SMM 1.2 specification. The BACM metamodel effectively imports the entire SMM metamodel.
Definition: BACMBinDirRelation is an abstract class that generalizes the classes resulting from the transformation of model associations stereotyped as <<class> or <<shortcut>>. It specializes BACMRelation to represent binary directed relations and redefines the association between BACMRelation and BACMEntity to designate the start (from_bacm_entity) and end (to_bacm_entity) of the relation directio
Definition: BACMRelation is an abstract class that models n-ary relations with features and the ability to participate in other specializations and instances of this class as bacm_entity ends.
Usage: BACMRelation is the generalization of all classes resulting from the transformation of <<association>> stereotyped classes. The model associations determined to be legs of the <<association>> stereotyped classes are transformed to specialize the association with ends bacm_entity and bacm_relation
Definition: BACMEntity is an abstract class that is characterized by participating in relationships defined by BACMRelation and BACMBinDirRelation. BACMEntity is also a generalization of all classes intended to represent concepts of the modeled business. See the normative XMI file for details.
Usage: Both BACMRelation and BACMBinDirRelation are specializations of BACMEntity allowing these relationships to participate in other relationship
Definition: BusinessElement represents a concept or entity that existing or is planned to exist in the business.
Usage: BusinessElement is an abstract base class for all classes whose instances represent business entities.
Definition: BACMPlainEntity is an abstract class disjoint from BACMRelation that classifies all BACM classes representing concepts of the modeled business that are not specializations of BACMRelation.
Usage: BACMPlainEntity and BACMRelation distinguish classes intended to represent entities from those intended to represent associations
Definition: BACMShortcut is an abstract class inherited by the transformation of all metamodel classes stereotyped as <<shortcut> and all generated classes that result from the transformation of model classes stereotyped as <<shortcut>>. It declares a string (constr) that defines the shortcut constraint and a boolean valued function (hasDetail) that evaluates the constraint string and determines whether it is true or false.
Usage: In the normative XMI, the constraint string defined in the model is represented as an OCL function that determines if there is a specified path between the instances at the ends of the association. The modeler is allowed to use the constraint mechanism to define shortcut associations within the instance model. In this case, the constr attribute will contain the constraint string and the modeler must provide an implementation of the hasDetail function that evaluates the string and returns a boolean result
Definition: Measurement represents an actual measurement, which includes the time and other attributes of the measurement and the measure (measurement type).
Usage: Measurement specializes the corresponding class in the SMM 2.1 specification to define the measurand as a BACM BusinessElement.
Definition: The Scope class represents a collection of BACM BusinessElements that define the scope of a Measurement.
Usage: See the SMM 1.2 specification. The Scope class specializes the corresponding class in the SMM metamodel to allow scope selection by BACM Category
Definition: ExternalRealtionship represents a relationship between a BusinessElement in a provider tool or repository to ExternalData in another tool or Repository. The external data may be a BusinessElement (or a linked collection of BusinessElements) or some other element (or linked collection of elements) from a model that is not a BACM model. The IRI must identify a resource to which the specification String can be applied to identify the element (or linked set of elements) in that resource. The language attribute of the ExternalRelationship identifies the language of the specification String. Note that BusinessElement classifies all BACM classes and associations that are intended to represent business concepts (as opposed to model concepts or analysis concepts).
Usage: The tool provider may elect to provide services to dereference the ExternalData and apply the specification to allow the architect to view and interact with the results. However, a compliant implementation may just implement, import and export the ExternalRelationship, the ExternalData and the links connecting them and connecting the ExternalRelationship to the BusienssElement. If the language string is the string "Natural" or a string that identifies a natural language. then the specification Strong will be a natural language description of the alignment mappin
Definition: Responsible represents an unspecified kind of responsibility relationship between a source OrgUnit and a target OrgUnit. This relationship may also include a BusinessElement that defines the nature of the association.
Usage: Responsible instances may form generalization hierarchies. The business architect may create these hierarchies to represent particular types of responsibility relationships found in the business. When specializing Responsible instances, the source, target and nature association legs may be subsetted to restrict them to particular types of OrgUnit and BusinessElement
Definition: ExternalData is a class that wraps an IRI. An ExternalRelationship instance may be associated with multiple ExternalData instances
Definition: AbstractBusinessObject represents BusinessObjects or InformationItems.
Usage: AbstractBusinessObject cannot be instanced or specialized in a business arcitecture model. The AbstractBusinessObject metaclass has two concrete subclasses: BusinessObject - instances represent tangible things of importance to the business. InformationItem - instances represent intangible (mental) concepts important to the business. The AbstractBusinessObject metaclass provides its concrete specializations with the state_of association to Outcomes and the scopes association to Capability and CapabilityBehavior. AbstractBusinessObject also provides for ObjectRelations that may relate any collection of BusinessObjects and InformationItems.
Definition: AbstractOperatingModel is an abstract metaclass whose concrete specializations are the model elements of the operating model (see the AbstractOperatingModel diagram). This metaclass groups together the concrete metaclasses that may be impacted by a Means or Initiative or baselined by Ends or Changes
Usage: Means and Initiatives describe behaviors that will impact parts of the operating model of the business to achieve the Ends and Changes associated with the Means and Initiatives. While the behaviors are described by the Means and Initiatives, the affected operating model components are represented by the impacts relationship to facilitate analysis of these impacts for feasibility, risk, cost and other measures. Ends and Change describe the new state and behavior of the baselined parts of the operating model of the business. For example, an End may be the improvement of throughput and reduction of wait time for a CapabilityImplementation. The Means may be the addition of personnel and upgrading of an application. The End describes a new baseline for the CapabilityImplementation (relative to the existing baseline associated with the CapabilityImplementation). The Means describes the behaviors to be carried out with respect to the staffing and resourcing of the CapabilityImplementation
Definition: ObjectRelation represents any relationship of any arity among BusinessObjects and InformationItems.
Usage: The architect may use ObjectRelation to indicate that two BusinessObjects are joined together or that one BusinessObject is part of another
Definition: AbstractCapability is not intended to represent a business concept. It is a metamodeling device to provide relationships to Capability and CapabilityBehavior that would otherwise be duplicated.
Usage: The AbstractCapability metaclass has two concrete specializations: Capability and CapabilityBehavior. Only the specializations can be instanced in models. AbstractCapability provides the following to its concrete specializations: to represent the production of an Outcome; to represent the need for an Outcome; to represent the ability of an InformationItem to inform the behavior of a Capability and/or CapabilityBehavior; to represent the ability of a CapabilityImplementation to implement a Capability and/or a CapabilityBehavior; to represent the notion that a BusinessObject and/or an InformationItem scopes a Capability and/or a CapabilityBehavior </ol
Definition: Role represents a specified way for an entity to participate in producing the Outcome of a Capability or a Process. However, only the concrete subclasses of Role may be used in a model.
Usage: Role is an abstract association meta-class used to model relationships between Performers and Resources and Capabilities and Processes. It represents how Performers and Resources participate in behavior descriptions as represented by CapabilityBehaviors and/or in Capabilities. The Role meta-class is stereotyped as an association and its concrete instances are effectively class associations. Specifically, the Role meta-class acts as an n-ary association with three predominant patterns: 1. A Capability is associated with a Performer; 2. A CapabilityBehavior is associated with a Performer, or a choice of an OrgUnit or a System; 3. A CapabilityImplementation is associated with a CapabilityBehavior and a choice of an OrgUnit or a System. These three patterns represent: 1. An abstract view of the business capability with detail added by the Role instance indicating the type of activity to be performed. Since a Capability may have multiple associated Roles, this implies that the Capability incorporates multiple activities. 2. An intermediate view of the business used in planning where details about the specific behaviors of a capability and the type of performer entity (OrgUnit or System) are specified, but the actual or planned assignment of real OrgUnits or Systems has not occurred. 3. A more detailed planning/implementation view of the business in which specific performers and resources have been or are planned to be allocated to a Capability and its CapabilityBehaviors by way of a set of CapabilityImplementations. Neither ResourceRoles nor PerformerRoles may exist without being linked to a Capability or a CapabilityBehavior or a Process or an Activity with the role link. A Capability and a CapabilityBehavior may share a Role, but an assignment to that Role will be the same for both the Capability and the CapabilityBehavior. To indicate that a CapabilityBehavior and a Capability have related roles, the modeler should create a specialization ot the Capability Role for each CapabilityBehavior that delivers the Capability and link the specialized Role to the CapabilityBehavior. A Process and an Activity may not share a Role. A Role may be shared between a Capability and/or a CapabilityBehavior, and either a Process or an Activity. In this case, any assignment to the Role is an assignment to both the Capability/CapabilityBehavior and the Process/Activity PerformerRoles and ResourceRoles may be linked to CapabilityImplementations with the assignment shortcut association. Performers and Resources aggregated in the CapabilityImplementation should be assigned to these roles
Definition: BusinessObject represents a tangible thing that is of significance to a business.
Usage: BusinessObjects may also overlap with other classes in the model; for example a BusinessObject may also be a Resource used by a Capability. Typically, the BusinessObject represents tangible things that are acted on by the Capabilities of a business to create a new Outcome that defines a new state of the BusinessObject. An assembly robot may be a Performer associated with an assembly Capability. The same assembly robot may be a BusinessObject when it is no longer needed and is sold.
Definition: Capability represents generalization over variations in behavior and variations in structure applied to the behavior where the same general Outcome is produced by the behavior.. A Capability represents the ability a business has to produce an Outcome without specifying how that Outcome is produced.
Usage: Capability is defined in this way to allow executives to analyze variation in business behaviors and structures that all produce the same or similar outcomes. In addition, observing problems or successes that recur in most or all of the variations of a Capability is a clue that the business has a systemic problem with respect to the capability. For example, if all behavior variants and implementations of a Capability are underperforming, then one might wish to understand why. Capabilities may be decomposed in a strict hierarchy, but are not allowed to be specialized. The CapabilityBehavior that delivers a Capability is used to represent behavioral variants of a Capability. A Capability may be implemented by a CapabilityImplementation, a collection of Resources and Performers that are assigned Roles in the Capability. The modeler may use any of the following patterns: Capability is defined without CapabilityBejaviors or CapabilityImplementations; Capability is defined with CapabilityImplementations annotated with proposed resources and performers but without Roles, Resources and Performers; Capability is defined with Roles, CapabilityImplementations, Performers, Resources where the Performers and Resources are aggregated to the CapabilityImplementation and are assigned to Roles of the Capability; Capability is defined as in 3. and CapabilityBehaviors are defined delivering the Capability with Role assignments to CapabilityBehavior compatible with the assignments to Capability Roles; Capability is defined with delivering CapabilityBehaviors but no CapabilityImplementation; Capability is defined with Roles and delivering CapabilityBehaviors are defined with consistent Roles; All other configurations are disallowed.
Constraint: Capability instances may own other Capability instances but may not aggregate or generalize them
Definition: CapabilityBehavior represents a behavior description or specification, such as process diagrams, procedures manuals and other means of recording and publishing expected business practices.
Usage: CapabilityBehavior also represents rules, regulations and policies that constrain behavior, whether imposed by statute, regulators or business executives. CapabilityBehaviors deliver a Capability, indicating that the set CapabilityBehaviors associated to a Capability are variant ways of producing the same or similar Outcomes. CapabilityBehaviors may have associated Roles. These Roles define how Performers and Resources may participate in the described or specified behavior. CapabilityBehavior is a subtype of AbstractCapability and inherits associations with the Outcomes of Capabilities. These associations represent the ability of a behavior to produce an outcome. The Outcomes produced by a CapabilityBehavior are usually more specific than Outcomes produced by the Capability. Often the Outcome of a CapabilityBehavior will include side-effects that result from the particular behavior, such as resources consumed in executing the behavior or time taken by the execution. CapabilityBehaviors are not decomposable, but may be associated with Processes, which are decomposable
Usage: This abstract element defines a union type for AbstractProcess, CapabilityImplementation and CapabilityProvider, allowing the specifies association to connect any instances of any concrete subclasses of these classes.
Definition: The CapabilityImplementation represents a collection of Resources and Performers that may be used to implement a Capability or CapabilityBehavior (see the Roles diagram).
Usage: The Resources and Performers are optional; the modeler may create instances of CapabilityImplementation annotated with a description of proposed or planned resources and performers and subsequently add the Performers and Resources.
Definition: Resource represents an entity that is required or needed by a ResourceRole but is not a Performer and does not become a part of a BusinessObject or InformationItem associated with any Outcome produced by the Capability or CapabilityBehavior.
Usage: These relationships are represented by the assignment of structural components of the business to roles of Capabilities/CapabilityBehaviors and Processes/Activities
Definition: The Performer represents entities that are capable of performing PerformerRoles. Performer has two specializations: OrgUnit and System, representing a human components of the business or a system.
Usage: The Performer is concrete to allow modeling the need for a Performer without committing to a human assignment, a system assignment, or a combination of both. Performers are generally described by skills or abilities. The Performer and Resource classes are not disjoint (i.e. an entity may be a Resource with respect to one Capability while being a Performer with respect to another Capability). An entity may not be both a Performer and a Resource of the same Capability
Definition: The InformationItem represents a kind of information.
Usage: The same InformationItem may represent a thought or piece of knowedge and a physical manifestation of that thought or knowledge as a document or a dataset
Definition: An Outcome represents a fact or collection of facts about an experienced state of affairs pertaining to one or more BusinessObjects and/or InformationItems. Outcomes are produced/needed by Iand outputs/inputs of AbstractProcesses.
Usage: For example, a Capability to attach wheels to a vehicle being manufactured would require that a vehicle without wheels be available and that wheels be available. This requirements would be modeled as two Outcomes: 1. A vehicle without wheels is available to the Capability, and 2. A set of wheels is available to the Capability. The result of the Capability is another Outcome in which the wheels are no longer separate but are attached to the vehicle. Separating the state of a BusinessObject or InformationItem from the BusinessObject or InformationItem allows the model to represent many possible states of the BusinessObject or InformationItem and associate each state with the Capabilities and/or CapabilityBehaviors that produce the states. Outcome and its AbstractBusinessObjects must represent a single, consistent set of facts whether viewed from the capability perspective or the process perspective. However, the facts represented by a Outcome may not be at the same level of detail when viewed in a capability perspective as when viewed in a process perspective. For example, a process perspective may represent the wheel assembly activities in greater detail, specifying the additional tools and parts needed to attach the wheels to the vehicle with intermediate Outcomes representing the stages of mounting the wheels to the hubs, attaching the nuts to the hub bolts, and tightening them to the required torque specification. The beginning and end of this sequence of Outcomes are the same in the process perspective and in the capability perspective. Other semantic relationships provided for Outcome are generalization and aggregation.
Definition: OutcomeRelation represents any kind of semantic relationship between Outcomes.
Usage: The architect may create instances of any arity to define semantic relationships between Outcomes. For example, two Outcomes may be specified as alternative that cannot both be produced by a Capability or Process in a single execution
Definition: PerformerRole represents skills, knowledge and willingness to use these in the production of the Outcomes of a Capability.
Usage: PerformerRole represents roles that must be fulfilled by human or automation actors.
Definition: ResourceRole represents the set of roles that must be fulfilled by business entities that are passive participants in the Capability, CapabilityBehavior, Process or Activity. This includes tools, locations and materials that are used in the behavior but do not become incorporated into the Outcome of the behavior. Any materials or entities that are incorporated into a BusinessObject or InformationItem whose Outcomes are produced by the Capability or CapabilityBehavior should be represented as BusinessObjects or InformationItems associated with Outcomes needed by the Capability and not represented as Resources in this context.
Definition: AbstractProcess is not intended to represent a busines concept. It is a metamodeling technical device to share relationships with Process and Activity that would otherwise need to be duplicated.
Usage: AbstractProcess is an abstract meta-class that provides input and output Outcome connection abilities to both Process and Activity. It also provides the role link to PerformerRoles and ResourceRoled. It also provides the implements link to a ValueStream or some ValueStreamStages. Since implements aligns the scope of the Process with either a ValueStreamStage or a ValueStream, it should not link both a ValueStreamStage and the ValueStream the ValueStreamStage belongs to
Definition: The scopes shortcut association allows a Capability and/or CapabilityBehavior to be associated with some BusinessObjects and.or an InformationItems without defining Outcomes produced or needed by the Capability and/or CapabilityBehavior.
Usage: The modeler may elect to subsequently define such Outcomes, which must be consistent with the constraint specified by the scopes shortcut association.
Constraint: Let BO1 be a BusinessObject and C1 be a Capability that are associated by scopes s1. Then there should existin the model an Outcome O1 such that C1 produces O1 and O1 is a stateOf BO1.
Definition: The object shortcut association asserts that the ProcurementOffering incorporates unspecified Outcomes describing the states of AbstractBusinessObjects.
Usage: This association allows the business architect to omit the Outcome in the procurement of some AbstractBusinessObjects for use by theBusiness when those Outcomes are obvious or irrelevant to the purposes of the analysis that is using the business architecture model.
Constraint: Let POf1 be a ProcurementOffering and BO1 be a BusinessObject associated by o1 an "object" association. Then POf1 should incorporate ProcurementOutcomes {POj} that represent either the change of ownership of BO1 or the establishment of a limited right to use BO1.
Definition: ProcurementOffering is an offering by theBusiness to purchase or lease a BusinessObject and/or InformationItem from a LegalEntity
Definition: The object association represents a shortcut relationship between a MerchandiseOffering and a BusinessObject or InformationItem offered for sale or lease to the Customer.
Usage: This shortcut implies that there is an unspecified MerchandiseOutcome of the AbstractBusinessObject that would describe the terms of ownership/use incorporated in the MerchandiseOffering.
Constraint: Let MOf1 be a MerchandiseOffering and BO1 be a BusinessObject associated by o1 an "object" association. Then MOf1 should incorporate MerchandiseOutcomes {MOj} that represent either the change of ownership of BO1 or the establishment of a limited right to use BO1
Definition: A MerchandiseOffering irepresents an offering to sell or lease a good to a customer who may use the good to produce Outcomes.
Usage: The MerchandiseOffering is characterized by some BusinessObjects or InformationItems that would be transferred to the Customer for use by the Customer. The BusinessObjects and/or InformationItems are objects of the MerchandiseOffering
The "state_of" meta-association applies a state to an AbstractBusinessObject instance. For example, a passenger may be transported from one location to another by a Capability, and the Outcome resulting from the Capability execution represents the fact that the passenger is now in the destinationlocation.
Definition: The needs association represents the assertion that a Capability and/or CapabilityBehavior needs, desires or requires a particular Outcome representing a state of an BusinessObject or InformationItem.
Definition: The produces association represents that a Capability and/or CapabilityBehavior may produce the Outcome
Definition: The require association represents that a Capability and/or CapabilityBehavior is required for performance of the Initiative.
Usage: Definition of this association in an M1 level model allows the business architect to record and analyze such requirements.
Definition: Initiatives represent plans to change business functions in order to achieve the business results described by Changes. Initiatives should be linked to the expected Changes with the expects association.
Usage: Initiatives may be decomposed and may share sub-Initiatives
Definition: The require association represents that a Capability and/or CapabilityBehavior is required for performance of the Means.
Usage:Definition of this association in an M1 level model allows the business architect to record and analyze such requirements
Definition: Means represent possible behaviors that will change functional elements of the business (represented by Capabilities, CapabilityBehaviors, CapabilityImplementations, Processes, Activities, Roles, Performers and Resources). These changes are expected to produce the changes represented by the Ends. Each End should be expected to result from the changes described by one or more Means.
Usage: Means can be decomposed and subordinate Means may be shared by aggregator Means
Definition: the object shortcut association designates an AbstractCapability possessed by theBusiness that is intended to produce the ServiceOutcome incorporated into the ServiceOffering. Constraint: Let SOf1 be a ServiceOffering and C1 be a Capability that is associated by o1 an object association. Then there should exist a ServiceOutcome SO1 such that SO1 is incoporated in SOf1 and SO1 is produced by C1
Constraint: Let SOf1 be a ServiceOffering and C1 be a Capability that is associated by o1 an object association. Then there should exist a ServiceOutcome SO1 such that SO1 is incoporated in SOf1 and SO1 is produced by C1
Definition: ServiceOffering represents an offer to provide a service to a Customer. the busienss provides the CapabilityImplementations and CapabilityBehaviors needed to effect the Outcome promised to the Customer by the ServiceOffering.
Usage: A ServiceOffering is a specialization of a ProductOffering such that a Capability or CapabilityBehavior or Process or Activity is performed to produce an Outcome that is incorporated into the service. Unlike a sale or lease, where some incorporated Outcomes represent a change of ownership or poseeseeion/use of a business object, the incorporated Outcomes (such as a cleaned residence) are the primary Outcomes desired by the customer. A business that offers a ServiceOffering must incorporate or arrange for the Capabilities and or Processes needed to produce the promised Outcomes
Definition: The informs association represents the influence of information (represented by InformationItem) on a Capability or a CapabilityBehavior.
Usage: Information, such as weather, production targets, and results of a business analysis project will change how a business behaves and how a Capability or CapabilityBehavior performs
Definition: The implements association represents a relationship meaning that the CapabilityImplementation provides Performers and Resources to implement a Capability or CapabilityBehavior.
Usage: The implements association is a shortcut linking a CapabilityImplementation to a Capability or CapabilityBehavior. It carries a constraints that Performers and Resources in the CapabilityImplementation should be assigned to Roles of the Capability or CapabilityBehavior.
Constraint: Given a CapabilityImplementation CI1 and a Capability C1, if an impliements association I1 exists between CI1 and C1, then paths should exist between CI1 and C1 such that for some subset of the Performers {Pi} aggregated by CI1 and some subset of the Resources {Ri} aggregated by CI1, the Pi are assignTo PerformerRoles PRj and assignTo ResourceRoles RRj ofCapability C
Definition: The implements shortcut represents that a CapabilityBehavior and an AbstractProcess have related Outcomes
Usage: It could also be justified by a common Performer playing a role in the CapabilityBehavior and the AbstractProcess
Constraint: Let P1 be a Process and C1 be a capability associated by an implements association. Then there should exist Outcomes O1 and O2 such that O1 is produced by (needed by) C1 and O2 is output (input) by P1 and O1 and O2 are related such that they are the same Outcome or one is in the extended aggregation of the other or one is the extended specialization of the other or any chain of relationships connecting the two where the chain consists exclusively of being aggregated by or being a specialization of the predecessor Outcome
Definition: The contains association represents that BusinessObjects may contain System.
Usage: In some cases, a BusinessObject and a System may represent different aspects of the same entity; since meta-classes in this meta-model are not assumed disjoint, an instance may have both BusinessObject and System as metaclasses. However, a BusinessObject may contain several Systems and other BusinessObjects as well. In this case, the Systems are not aspects of the primary BusinessObject, and the contains association allows the architect to represent this. An example of this latter case is a primary BusinessObject that is a computer and the System is a software package hosted on that computer (along with other software packages). The software package may be an instance of a System and also an instance of a BusinessObject (i.e. the code
Definition: The System represents the concept of a non-human performer, such as an IT system or a robot. Tools such as jigs and drills are not considered Perfomers for the purpose of business architecture. They should be modeled as Resources
The is about association represents the coupling of information to a business object where the information represents some aspects or characterizations of the business object. For example, a business object that is a car may have a "digital twin", i.e. a collection of information that describes the state of being of the car. Such a "digital twin" is more accessible for controlling and auditing the business than the actual catr.
Definition: The supports association represents the relationship between a Capability and a ValueStreamStage that means that the Capability is needed in the ValueStreamStage.
Usage: For example, an important stage in the creation of value for a manipulation puzzle such as Rubik's Cobe is the production of a manufacturable design of the puzzle. A failure here can result in a puzzle that cannot be manufactured or is not attractive to purchasers. Outcomes providing value are: a positive maniufacturability review; a positive customer reaction in a focus group. The Capabilities needed to produce these Outcomes are: product design, manufacturability analysis, focus group management. For this example, the previous three Capability instances would be associated with the "Design Ready" ValueStreamStage.
Definition: ValueStreamStages represent significant points of value creation in a ValueStream.
Usage: ValueStreamStages are dependent on their containing ValueStream and are not shared with other ValueStreams. When the business architect intends to represent similar ValueStreamStages in different ValueStreams, the similarity should be represented by having the same set of relationships with the supporting Capabilities. ValueStreamStages are often defined by analysis and decomposition of the ValueProposition. They may also respresent stages of completion of a "build to order" product that are of interest to the Customer (e.g. stages where the Customer may make changes in specifications of the ordered product).
Constraint: A ValueStreamStage may only own other ValueStreamStages and be owned by another ValueStreamStage or a ValueStream. ValueStreamStages may not participate in generalizes or aggregates associations.
Definition: The delivers association represents a CapabilityBehavior that produces or is intended to produce Outcomes that satisfy the Outcomes produced by the Capability.
Usage: A CapabilityBehavior that delivers a Capability must provide at least the set of Roles provided by the Capability
Definition: The implements association represents an assertion that one or more CapabilityImplementations are required to perform the initiative.
Usage: Definition of this association in an M1 level model allows the business arcitect to record that specific CapabilityImplementations are needed to perform the Initiative
Definition: The assignment shortcut association represents that a CapabilityImplementation provides Performers and Resources that can be assigned to ResourceRoles and PerformerRoles respectively of a Capability, CapabilityBehavior, Process or Activity. Constraint: Let CI1 be a CapabilityImplementation and PR1 be a PerformerRole, then some subset of the Performers {pj} aggregated by CI1 are assignTo PR1. Let CI1 be a CapabilityImplementation and RR1 be a ResourceRole, then some subset of the Performers {pj} aggregated by CI1 are assignTo RR1
Constraint: Let CI1 be a CapabilityImplementation and PR1 be a PerformerRole, then some subset of the Performers {pj} aggregated by CI1 are assignTo PR1. Let CI1 be a CapabilityImplementation and RR1 be a ResourceRole, then some subset of the Performers {pj} aggregated by CI1 are assignTo RR1
Definition: The informs association represents the influence of information (represented by InformationItem) on a Process or Activity.
Usage: Information, such as weather, production targets, and results of a business analysis project will change how a business behaves and how a Process or Activity performs.
Definition: The triggers association represents that the Outcome allows or initiates the ValueStreamStage.
Usage: It is often useful in analysis to record the Outcomes that constitute the important beginning events of a ValueStreamStage The triggers association allows the architect to record these relationships.
Constraint: Let O1 be an Outcome experienced at a Touchpoint T1 and VSS1 be a ValueStreamStage where O1 triggers VSS1, then there should exist a ValueItem VI1 that values O1 and is produced by VSS1
Definition: The experiences relation represents a relationship between an Outcome and a Touchpoint meaning that the Customer will experience the Outcome at the Touchpoint.
Usage: A Touchpoint experiences an Outcome: 1. when that Outcome is provided as a service or 2. when the Outcome is associated with acceptance of the ProductOffering (e.g. the customer is happy with the contract of sale), or 3. when the customer receives information that resolves a question, or 4. when the customer makes use of a business object that is provided as an Outcome of an exchange transaction
Definition: The Touchpoint represents an interaction between the business and the Customer.
Usage: One or more Outcomes created by the business are experienced by the Customer at the Touchpoint (e.g. the customer finds the answer to a question in a brochure created by the business, or the customer receives the business object that was ordered in good condition and on time). Alternatively, one or more Outcomes created by customer uses of the business objects contained in the ProductOffering are experienced by the customer (e.g. the customer uses the purchased hammer to drive nails). The analysis of value exchanged at the Touchpoint is represented by the ValueCharacteristic associated with the Touchpoint.
Definition: The incorporates association represents that an Outcome is included in a ProductOffering.
Usage: It may be implied that the BusinessObject whose state is represented by the Outcome is also included in the ProductOffering. In the case of a service offering, the Outcome instance represents the intended result of performing the capability as a service for a customer (as opposed to performing the capability for the immediate benefit of the business)
Definition: ProductOffering represents the terms and conditions associated with the acquisition of a product or service by a customer. It would typically include price, delivery terms, warranty and other aspects of these terms. The ProductOffering incorporates Outcomes such as change of possession for a product (BusinessObject or InformationItem) that is sold.
Usage: A ProductOffering (and its specializations Good and Service) are a type of BusinessObject. This allows a Customer to experience the ProductOffering at a Touchpoint and develop a reaction (such as the ProductOffering being a good deal). Such a reaction can be represented as a CustomerSegment associated with the Customer and the JourneyStage that includes the Touchpoint
Definition: The input association represents that the AbstractProcess inputs (requires or can use) the Outcome.
Usage: The input association in the process perspective corresponds to the needs association in the capability perspective. While it is possible that the same Outcome is input to a process and needed by a capability, it will usually be the case that a process inputs an Outcome that is related by generalization or aggregation (or another relation between Outcomes) to an Outcome needed by a capability. The process and capability in this case are semantically related by the relationship between their Outcomes. For example, a CustomerInformationManagement Capability may need CustomerInformation_change_pending Outcome. A process that updates the CustomerAddress (a component of CustomerInformation) may input CustomerAddress_change_pending Outcome, that is related to the other Outcome by aggregation.
Definition: The values association links a ValueItem to an Outcome and provides a valuation of that Outcome. An Outcome may have several ValueItems, reflecting the ways in which different stakeholders perceive the Outcome. Likewise, a ValueItem may value multiple Outcomes that must be valued as a group.
Usage: The Outcome may be present in the business architecture model without an associated ValueItem, but ValueItems may not exist without being associated to an Outcome
Definition: A ValueItem represents the business belief that a Customer will value one or more Outcomes that are experienced by the Customer.
Usage: For example, the ability of a sales representative to answer customer questions about a product is deemed to be valuable to the customer. Another example Outcome is the exchange of a good for money; the associated ValueItem could represent the buyer's feeling of having gotten a good deal
Definition: The output association represents that the AbstractProcess outputs the Outcome.
Usage: The output association in the process perspective corresponds to the produces association in the capability perspective. While it is possible that the same Outcome is output from a process and produced by a capability, it will usually be the case that a process outputs an Outcome that is related by generalization or aggregation (or another relation between Outcomes) to an Outcome produced by a capability. The process and capability in this case are semantically related by the relationship between their Outcomes. For example, a CustomerInformationManagement Capability may produce CustomerInformation_is_current and CustomerInformation_is_correct Outcomes. A process that updates the CustomerAddress (a component of CustomerInformation) may produce CustomerAddress_is_current and CustomerAddress_is_correct Outcomes, that are related to the other Outcomes by aggregation
Definition: Customer represents a customer type or a class of customers. Customer also represents partner businesses and other forms of contracted business relationships.
Usage: Customer effectively owns a set of CustomerSegments, each of which contains a partial description of the Customer. The CustomerSegments of a Customer may characterize CustomerJourneyStages or Touchpoints (i.e. they describe the Customer characteristics and state of mind at the CustomerJourneyStage or Touchpoint. When this is the case, the Customer should take the CustomerJourney owning the CustomerJourneyStages and Youchpoints. The Customer is an acceptor of one or more ProductOfferings and target of the ValuePropositions of these ProductOfferings.
Definition: The AbstractValueModel represents the value-related concepts that the Means and Initiative behaviors seek to achieve by changes made to the AbstractOperatingModel.
Usage: AbstractValueModel model elements represent perceptions of value as seen by a Customer or imagined by theBusiness to be seen by the Customer. As such, they cannot be directly changed by the business, so Means and Initiatives do not directly impact them. For example, the ValueProposition and ValueCharacteristic of an Offering may be improved by lowering its price, but this result is not guaranteed as the price action may be viewed as a signal of inflated worth or diminished quality. The architect may express a conviction that this result will occur in the expects association that links the price Means to the new Ends baseline for the ValueProposition and ValueCharacteristic.
Definition: LegalEntity represents a human organization that is subject to the laws and regulations of a Jurisdiction.
Definition: ValueCharacteristic represents the fit between the ValueProposition of a ProductOffering targeted at a Customer.
Usage: ValueCharacteristic is intended to be used with a semantic tagging mechanism such as that provided by MEF or its equivalent. This allows the creation of tagging frameworks such as the Value Proposition Canvas categories of "use", "pain" and "gain". The ValuePropositions, CustomerSegments and ValueItems should be tagged by these categories. The ValueCharacteristic should be similarly tagged and should represent the fit of like tagged ValuePropositions and CustomerSegments. For example, a ValueProposition that relieves a "pain" should be fitted to a CustomerSegment that describes the "pain" by a ValueCharacteristic tagged as "pain".
Constraints: A top level ValueCharacteristic defines a fit value for a relationship between a single Customer and a single ValueProposition. The ValueCharacteristic may be decomposed and account for fit between ValueItems and CustomerSegments that are part of the top level ValueProposition and Customer
Definition: A CustomerJourney represents a sequence of stages through which a Customer may pass with respect to a ProductOffering and its ValueProposition. The CustomerJourneyStages of the CustomerJourney capture the notion that the customer experience is cumulative.
Definition: The CustomerJourneyStage represents a significant stage in the CustomerJourney. An example of the stages of a customer journey would be: awareness, seeking a solution, weighting alternatives, acquiring the solution, using the solution, disposing the solution.
Usage: CustomerJourneyStages are often associated with decisions by the customer to proceed to the next stage or abandon the journey. However, the CustomerJourney is not a process and has no alternative sequences or paths
usage: This abstract class provides a union type for CustomerJourneyStage and Touchpoint, allowing the characterizes association to link instances of any concrete subclass of these classes.
Definition: The CustomerSegment represents a characteristic of the Customer or a component of customer state of mind. CustomerSegments are owned by the Customer they describe.
Usage: When the owning Customer takes a Customerjourney, CustomerSegments should be created for each CustomerJourneyStage and Touchpoint in the CustomerJourney. These CustomerSegments characterize the customer or the customer's state of mind at the CustomerJourneyStage or Touchpoint.
Definition: The ValueProposition represents a collection of values the business believes it is offering to customers, partners and other stakeholders through a ProductOffering.
Definition: A ValueStream represnts a set of stages that accumulate value represented by the ValueProposition.
Usage: The notion that value accumulation can be broken into components has been central to strategic practices such as Michael Porter's value chains and high level, value oriented process architecture. The notion is well established in business architecture and analysis practice. In some cases, it may be desirable to order the stages in a ValueStream. For example, there is a natural order to the design, build, inventory, sell and service stages of a manufacturing business. However, in other cases, such as health care, it is difficult to order the stages of triage, diagnosis, treatment, prevention. Consequently, no strong semantic interpretation should be associated with the ordering of ValueStreamStages in a ValueStream.
Constraint: A ValueStream instance may not own, aggregate or generalize another ValueStream instanc
Usage: This abstract class provides a union type for ValueStream and ValueStreamStage, allowing instances of the implements_1 association to link to instances of any concrete subclass of either of these classes.
Definition: The takes association represents a relationship between a Customer and a CustomerJourney asserting that the Customer is likely to take the CustomerJourney
Definition: The target shortcut association asserts that the ValueProposition is intended to target the Customer.
Usage: This shortcut allows the architect to assert that a ValueProposition targets a Customer and imply that there is an unspecified ValueCharacteristic that represents the value fit analysis of the ValueProposition and Customer.
Constraint: Let VP1 be a ValueProposition and Cu1 be a Customer associated by t1, a target association. Then there should be a ValueCharacteristic VC1 with VP1 as its proposition and Cu1 as its customer. Also, there should be ValueItems {VIj} aggregated by VP1 that value Outcomes {Oj} incorporated in ProductOfferings {POj} accepted by LegalEntities {LEj} that are also the Customer Cu1. Note that it is commonly the case that the set of individuals represented intensionally by the Customer element are also LegalEntities
Definition: The describes association represents the relationship between a CustomerSegment and a Customer asserting that the Customer is partially described by the CustomerSegment
Usage: If there is no CustomerJourney associated with a Customer, then the set of all CustomerSegments that describe the Customer represent the total customer description. If the Customer takes a CustomerJourney, then the CustomerSegments that describe the Customer may be qualified by the characterizes association to a CustomerJourneyStage or Touchpoint, indicating that the CustomerSegment partially describes the Customer at that CustomerJourneyStage or Touchpoint
Definition: The characterizes association represents a relationship between a CustomerSegment and a Touchpoint meaning that the CustomerSegment partially describes the state of mind or capability of the Customer at the Touchpoint interaction.
Usage: This characterizes association represents the same kind of relationship as the characterizes association between the CustomerSegment and the CustomerJourneyStage. The range of the association is the union of CustomerJourneyStage and Touchpoint.
Definition: The produces association represents the fact of a ValueItem being produced by valuing one or more Outcomes produced by Capabilities that support the ValueStreamStage or Processes or Activities that implement the ValueStreamStage.
Usage: The ValueItems produced in a ValueStreamStage that is part of a ValueStream should contribute to the ValueProposition produced by the ValueStream. The meta-model does not enforce this restriction.
Constraint: The produces association is consistent with the ValueStreamStage being supported by some Capabilities that produce Outcomes that are valued by the ValueItem
Definition: The of association links a VslueProposition to a ProductOffering and represents that is the ValueProposition is about the ProductOffering. Constraint: Let VP1 be a ValueProposition and PO1 be a ProductOffering associated by o1, an "of" association. Then for some subset of ValueItems {VIj} aggregated by VP1 such that each VIj values an Outcome O1 that is incorporated in the ProductOffering PO1. Note that the ProductOfferings typically include Outcomes that are experienced by the Customer at a Touchpoint
Constraint: Let VP1 be a ValueProposition and PO1 be a ProductOffering associated by o1, an "of" association. Then for some subset of ValueItems {VIj} aggregated by VP1 such that each VIj values an Outcome O1 that is incorporated in the ProductOffering PO1. Note that the ProductOfferings typically include Outcomes that are experienced by the Customer at a Touchpoint
Definition: The produces shortcut association represents the creation of a ValueProposition by a ValueStream.
Usage: The produces relation effectively aggregates the produces relations between the ValueStreamStages that are part of this ValueStream and the ValueItems that comprise the ValueProposition of this ValueStream.
Constraint: The produces association is implied by some owned ValueStreamStages that produce ValueItems that are aggregated into the ValueProposition
Definition: The participate shortcut asserts that a Performer is assigned to an unspecified PerformerRole of an unspecified Capability hat supports the ValueStreamStage. Constraint: Let P1 be a Performer participating in a ValueStreamStage VSS1. There should exist a PerformerRole PR1 that P1 is assignedTo and PR1 is a PerformerRole ofCapability C1 that produces some Outcme O1 valued by a ValueItem VI1 that is produced by ValueStream VSS1
Constraint: Let P1 be a Performer participating in a ValueStreamStage VSS1. There should exist a PerformerRole PR1 that P1 is assignedTo and PR1 is a PerformerRole ofCapability C1 that produces some Outcme O1 valued by a ValueItem VI1 that is produced by ValueStream VSS1
Definition: The Jurisdiction represents a legal jurisdictions with powers to charter and/or regulate businesses
Definition: The OrgUnit meta-class represents the various types of human organizations and individuals capable of acting as performers
Definition: theBusiness represents the particular business that is the subject of the business architecture model.
Usage: Only one instance of this metaclass is allowed in a model. This instance should be the sole provider of the top level ProductOffering, representing that the business is responsible for the entire product offering, parts of which may be provided by business partners represented as LegalEntities
Definition: The "legal_jurisdiction"association instances represent the jurisdiction to which an Enterprise belongs.
Usage: The meta-model allows Enterprise instances to be in multiple jurisdictions (e.g. a business that is subject to local, provincial and stage laws, regulations and processes)
Definition: The provider relation represents a relationship between a LegalEntity and an Offering created by the LegalEntity that is intended to solicit the business of designated parties identified by the consumer relation
Definition: Offering represents the solicitation of business from a Customer by presenting Outcomes and BusinessObjects that the business is willing to provide in return for items of value received from the Customer.
Usage: Offering is abstract because the metamodel may eventually include subtypes other than ProductOffering. Offering is provided by the business or a partner and the intended consumer is a type of Customer. The business architecture does not include the concept of a sale directly. Sales are in the past of a business, and business architecture is focused on the possible futures of the business. Sales are useful as predictors of acceptance of future offering and as predictors of future liability for warranties.
Definition: The acceptor relation represents a relationship between a party external to the business and an Offering intended to solicit business from the acceptor party represented by the Customer..
Usage: Note that offering dies not represent a sale; in a sale, each party gives something of value and receives something of value
Definition: The supplier association asserts that the LegalEntity is to be the supplier of the ProcurementOutcome.
Usage: The supplier LegalEntity is not necessarily the same as the provider LegalEntity for the ProcurementOffering incorporating the ProcurementOutcome
Definition: ProcurementOutcome represents the expected Outcome of the procurement. E.g. that the BusinessObject/InformationItem received has the characteristics needed by the procuring business.
Usage: ProcurementOutcome specifies such details and is associated with a ProcurementOfferint that should not duplicate the details of the ProcurementOutcome
Definition: The provider association asserts that a LegalEntity is the provider of the OutsourcedServiceOutcome.
Usage: The provider LegalEntity is not necessarily the same LegalEntity as the provider of the OutsourcedServiceOffering
Definition: OutsourcedServiceOutcome represents the expected Outcome of the performance of an outsourced service (i.e. a service performed for the business by another business)
Definition: The recipient association asserts that the LegalEntity is the recipient of ServiceOutcomes incorporated into a ServiceOffering.
Usage: It is not necessarily the case that the recipient LegalEntity is the same as the accepting LegalEntity of the incorporating ServiceOffering
Definition: ServiceOutcome represents the expected Outcome of the performance of a service for a Customer.
Definition: The buyer association is related to the accepts association and asserts that a LegalEntity (typically also a Customer) is the targeted buyer of the MerchandiseOutcome.
Usage: The buyer of the MerchandiseOutcome is not necessarily the LegalEntity that accepts the MerchandiseOffering in the case when the acceptor is acting as an agent for the buyer
Definition: MerchandiseOutcome represents the transfer of ownership and/or use between the business that is selling the merchandise via the MerchandiseOffering and the LegalEntity who receives the possession and/or use of the merchandise. The LegalEntity may also be a Customer.</i
Definition: belongs_to represents that a Performer belongs to theBusiness.
Usage: In a model, there will typically be semantic overlap between belongs_to and Responsible. However, the metamodel syntax presently does not allow the specification of this overlap. The business architect may choose to use belongs_to in lieu of Responsible or vice versa. It would not be recommended to use both where there is the potential of semantic overlap
Definition: The recipient association assserts that theBusiness is the intended recipient and beneficiary of the OutsourcedServiceOutcome.
Usage: The recipient is not necessarily the same LegalEntity that accepts the OutsourcedServiceOffering
Definition: The provider association asserts that theBusiness is the provider of the ServiceOutcome incorporated into a ServiceOffering.
Usage: The provider LegalEntity is not necessarily the same as the LegalEntity that provides the ServiceOffering that incorporates the ServiceOutcome
Definition: The procurer association asserts that theBusiness is the procurer of the ProcurementOutcome
Usage: The procurer LegalEntity is not necessarily the acceptor LegalEntity of the ProcurementOffering</i
Definition: The seller association asserts that theBusiness is the seller of the MerchandiseOutcome incorporated in the MerchandiseOffering.
Usage: This association does not imply that the LegalEntity providing the MerchandiseOffering is the same as the seller of the MerchandiseOutcome
Definition: Process represents an aggregation of Activities and other Processes.
Usage: A Process aggregated into another Process means that the aggregated Process may be executed as a part of executing the aggregator Process. The abstract syntax does not specify a starting or ending Process/Activity; consequently starting and ending Activities/Processes aggregated by another Process must be determined by analysis of the Outcome connections
Definition: Activities represent atomic (non-decomposable) activities
Definition: The implements association asserts that a Process or Activity implements a ValueStream and implies that Outcomes of the Process are valued as ValueItems incorporated into the ValueProposition delivered by the ValueStream.
Usage: It is not permitted for a Process or Activity to implement both a ValueStream and one or more ValueStreamStages of that ValueStream. A Process implementing a ValueStream may have aggregated Processes that implement ValueStreamStages of the ValueStream
Definition: ContractRelation represents any kind of relationship between Offerings.
Usage: ContractRelation should be instanced as a relationship between Offferings whose arity is determined by the architect. Each leg of such an instance effectively inherits from the relation association
Definition: OutsourcedServiceOffering represents an offering made by the business that solicits a service to be performed by another business
Definition: The specifies association represents a relationship between an OutsourcingOffering and a CapabilityBehavior or Process or CapabilityImplementation, in which the Customer would be required or advised to perform the CapabilityBehavior or Process and/or provide Performers and Resources as specified by the CapabilityImplementation as an implementation of the CapabilityBehavior or Process..
Usage: This association is effectively combined with the two other specifies relation whose source is OutsourcingOffering so that the range of the combined associations is the union of AbstractProcess, CapabilityBehavior and CapabilityImplementation.
Definition: This incorporates association refines the incorporates association between the generalizing meta-classes ProductOffering and Outcome. It asserts that a MerchandiseOffering incorporates a MerchandiseOutcome
Definition: The incorporates association designates that an OutsourcedServiceOffering incorporates some OutsourcedServiceOutcomes.
Usage: The incorporates association refines the incorporates association between ProductOffering and Outcome
Definition: The incorporates association refines the incorporates association between the generalizing meta-classes ProductOffering and Outcome and asserts that the ProcurementOffering incorporates the ProcurementOutcomes
Definition: The incorporates assocation refines the incorporates association between the generalizing meta-classes (ProductOffering and Outcome) and asserts that the ServiceOffering incorporates some ServiceOutcomes
Definition: Change represents desired states of business value and results as represented by the baselined elements of the AbstractOperatingModel and the AbstractValueModel. These states are expected to result from the changes described by the Initiatives.
Usage: Changes can be decomposed and share sub-Changes
Definition: Ends represent changes to elements representing business values, such as ValuePropositions., ValueItems and ValueCharacteristics. Ends also represent changes to business results (i.e. Outcomes, BusinessObjects, InformationItems and ProductOfferings). These element types derive from AbstractOperatingModel and AbstractValueModel.
Usage: A Ends element will typically state the desired result (e.g. improved customer satisfaction) relative to the currently achieved (baselined) result (customer satisfaction represented as an Outcome). Ends can be decomposed into subordinate Ends. Subordinate Ends may be shared by one or more aggregator Ends
Definition: StrategyModel is a collection of Means and Ends and the Initiatives and Changes implementing the Means and Ends. It represents a single, coherent and complete strategy.
Usage: StrategyModels each represent a particular strategy choice. StrategyModels may share sub-StrategyModels. The set of StrategyModels as prepared by the architect and strategist is represented by the StrategyChoices model element and the alternative associations linking it to each StrategyModel
Definition: The baseline association links one or more operating model elements representing business results to change objectives represented by the Changes.
Usage: An operating model Outcome (e.g. cost of executing an activity) is the baseline for a Change (e,g, a 5% reduction in the cost of executing the activity as a result of purchasing a new robot)
Definition: The impacts association links Initiatives (planned changes to operating model elements) to the operating model elements impacted (changed) by the Initiatives
Definition: The baseline association links one or more operating model elements representing business results to change objectives represented by the Ends.
Usage: An operating model Outcome (e.g. cost of executing an activity) is the baseline for an End (e,g, a 10% reduction in the cost of executing the activity)
Definition: The impacts association links a Means (description of changes to be made to business operations) to the operating model elements that will be impacted (changed)
Definition: The baseline association links a value model element (e.g. a ValueProposition where the price of a product is equal to the competitive average price) to an End (e.g. an End that reduces the price of a product to 5% below the competitive average)
Definition: The baseline association links a value model element (e.g. a ValueProposition where the price of a product is equal to the competitive average price) to a change (e.g. a change that reduces the price of a product by 5% ).
This "implements" meta-association links a desired end of a strategy to the specific changes that are expected to result in the achievement of the end.
Definition: The expects association links one or more Changes that are expected to result from the Means described changes
Definition: The needs association represents that one or more Changes are needed to enable the performance of the Initiatives.
Usage: This association must be instanced as an association classifier so that the modeler can express: a rationale for the expectation; note the likely influences of environmental factors, including competitive responses and regulatory actions risks and risk avoidance activities Expressing these concerns may require the modeler to define additional properties and association legs at the M1 model level
Definition: The needs association represents that one or more Ends are needed to enable the performance of the Means
Usage: This association must be instanced as an association classifier so that the modeler can express: a rationale for the expectation; note the likely influences of environmental factors, including competitive responses and regulatory actions risks and risk avoidance activities Expressing these concerns may require the modeler to define additional properties and association legs at the M1 model level.
Definition: The expects association represents that one or more Ends are expected to result from the changes described in the Means.
Definition: The implements association represents the assertion that an initiative implements a Means