SysFEAT - Systemic Framework for Enterprise Architecture & Transformationk

IDENTITY DIAGRAM MAPPING EXTERNAL REFERENCES

IDENTITY - UAF - Motivation

Description	Identifies and defines motivational elements e.g., challenges, opportunities, and concerns, that pertain to enterprise transformation efforts, and different types of equirements, e.g., operational, services, personnel, resources, or security controls. Recommended Implementation: SysML Block Definition Diagram, SysML Package Diagram, tabular format
References	OMG - UAF - View - Motivation
Parent Mapping	UAF Mappings

../images/ef5d11366322a1e4_58ec687d63310e57_i.png

MAPPED ENTITIES

Framework Concept	Framework Definition	SysFEAT Concept	SysFEAT Definition
Asset	An abstract element that indicates the types of elements that can be affected by Risk. Asset as applied to Security views is an abstract element that indicates the types of elements that can be considered as a subject for security analysis References: OMG - UAF - Asset
Assurance Case	The assurance case concept doesn't exist in UAF. It is defined in OMG SCAM specification References: OMG - SACM : AssuranceCasePackage	Assurance Case	An Assurance Case is a claim that a particular enterprise asset or group of Functional Asset adequately mitigates certain identified Risk Types by means of appropriated Control Measures. An Assurance Case shall provide confidence that the concerned assets will function as intended in their environment of use. Privacy Processing Activity(ies), Data Lineages are examples of Assurance Cases . References: NIST - Assurance Case OMG - SACM : AssuranceCasePackage
Operating Asset		Operating Asset	An Operating Asset is a Functional Asset that describes the way Outcome Events are produced and consumed: how (Behaviors) and by whom (Agents). Operating Assets fulfill Capability(ies) (Fulfilled Capability). As any Functional Architecture Asset, Operating Assets are subject to Policy Conformances. In addition, they define Rule Enforcements to indicate how Policy Conformances are met. References: OMG - KerML - Class
Requirement	A Requirement specifies a capability or condition that must (or should) be satisfied. A requirement may specify a function that a system must perform or a performance condition that a system must satisfy. Requirements are used to establish a contract between the customer (or other stakeholder) and those responsible for designing and implementing the system. References: OMG - SysML 1.X - Requirement	Requirement	A Requirement is a generic statement used in system engineering to constrain what a Business System Asset should or should not be. The Requirement concept is kept in SysFEAT to maintain compatibility with traditional system engineering methodologies. The preferred approach is to follow capability-based engineering, as promoted by modern enterprise & system architecture (see OMG - UAF - View - Strategic Views) and agile frameworks (see SAFe© - SAFe Requirements Model). References: OMG - SysML 1.X - Requirement SEBoK - Capability Engineering
Requirement (Functional)	Functional requirements are represented by Capability in SysFEAT.	Capability	A Capability is a functional Asset Property which refers to the ability to produce an Outcome Event. Capabilitys are fulfilled by Agents performing Processes and interacting with other Agents to produce the desired Outcome Event. References: DAU Glossary - Capability OMG - BACM - Capability OMG - UAF - Capability OpenGroup - ArchiMate - Capability OpenGroup - OAA - Capability OpenGroup - TOGAF - Definition - Capability Russell Ackoff - Choice & Communication - FunctionalClass WordNet - Capability
Requirement (Measure)	Non functional requirements related to qualitative and quantitative aspects are represented by the Condition Scale Value concept in SysFEAT.	Condition Property	A Condition Property is a possible value of a Condition Property Type such as a delivery time of 30 minutes, a weight of 20 kg, a high level of confidentiality, stormy conditions. A Condition Property is either a single measure (Measure Property: a weight of 20 kg), an Environmental Property (stormy conditions.) or a Set of Condition Propertiess. Condition Propertys are used to constrain Asset Blocks in the context of non-functional requirement analysis and Value Proposition analysis. Examples: . Cost of 100€ . Delivery time of 30 minutes. . Weight of 20 kg. . Temperature of 18 degree Celcius.
Requirement (Policy)	Non functional requirements related to constraints and guidance are represented by Policy in SysFEAT. Policies range from Regulation Articles, Business Policys to Architecture principles.	Policy	A Policy is a Directive that is not directly enforceable whose purpose is to govern, guide or constrain the structure and Behavior of Agents in the enterprise. Policies provide the basis for rules and govern Behaviors carried out by Agents. Example of Policys are Regulation Articles, Business Policys or Architecture principles. References: OMG - BMM - Business Policy OMG - UAF - Rule
Satisfy	A Satisfy relationship is a dependency between a requirement and a model element that fulfills the requirement. As with other dependencies, the arrow direction points from the satisfying (client) model element to the (supplier) requirement that is satisfied.
Satisfy (Fullfillment)	Satisfy relationship that is fulfillement dependency between an operating asset and a capability.	Realized Functional Asset	A kind of specialization between an implementing Functional Asset and its abstract Realized Functional Asset. Realization relationships are the foundation to establish the mapping between Functional Assets that belong to different Conceptualization Levels. References: OpenGroup - ArchiMate - Realization-Relationship
Satisfy (General)	Generic satisfy relationship is a dependency between a requirement and a model element that fulfills the requirement. As with other dependencies, the arrow direction points from the satisfying (client) model element to the (supplier) requirement that is satisfied.
Satisfy (Policy)	Satisfy relationship that is realization dependency between an operating asset and a policy	Policy Conformance	A Policy Conformance is the conformity requirement that applies a Functional Asset.
UAFElement	Abstract super type for all of the UAF elements. It provides a way for all of the UAF elements to have a common set of properties. References: OMG - UAF - UAFElement	Asset Block	An Asset Block is an Architecture Block used to describe the System Operating Framework - SOF of the enterprise and its systems. References: OMG - UAF - UAFElement OpenGroup - TOGAF - Architecture Building Blocks
Verify	A Verify relationship is a dependency between a requirement and a test case or other model element that can determine whether a system fulfills the requirement. As with other dependencies, the arrow direction points from the (client) element to the (supplier) requirement.	Contraining Operational Policy

EXTERNAL REFERENCES

Framework reference	SysFEAT Description
OMG - SACM : AssuranceCasePackage	The assurance case concept doesn't exist in UAF. It is defined in OMG SCAM specification Assurance Case An Assurance Case is a claim that a particular enterprise asset or group of Functional Asset adequately mitigates certain identified Risk Types by means of appropriated Control Measures. An Assurance Case shall provide confidence that the concerned assets will function as intended in their environment of use. Privacy Processing Activity(ies), Data Lineages are examples of Assurance Cases .
OMG - SysML 1.X - Requirement	A Requirement specifies a capability or condition that must (or should) be satisfied. A requirement may specify a function that a system must perform or a performance condition that a system must satisfy. Requirements are used to establish a contract between the customer (or other stakeholder) and those responsible for designing and implementing the system. Requirement A Requirement is a generic statement used in system engineering to constrain what a Business System Asset should or should not be. The Requirement concept is kept in SysFEAT to maintain compatibility with traditional system engineering methodologies. The preferred approach is to follow capability-based engineering, as promoted by modern enterprise & system architecture (see OMG - UAF - View - Strategic Views) and agile frameworks (see SAFe© - SAFe Requirements Model).
OMG - UAF - Asset	An abstract element that indicates the types of elements that can be affected by Risk. Asset as applied to Security views is an abstract element that indicates the types of elements that can be considered as a subject for security analysis An abstract element that indicates the types of elements that can be affected by Risk. Asset as applied to Security views is an abstract element that indicates the types of elements that can be considered as a subject for security analysis. An abstract element that indicates the types of elements that can be affected by Risk. Asset as applied to Security views is an abstract element that indicates the types of elements that can be considered as a subject for security analysis. An abstract element that indicates the types of elements that can be affected by Risk. Asset as applied to Security views is an abstract element that indicates the types of elements that can be considered as a subject for security analysis Functional Asset Functional Assets encompasse all Architecture Asset Types used to describe why and how systems operate/function. This includes the Operating Eco-System where system operates to fulfill these purposes (Agents and their Behaviors). Functional Assets include: 1. Blocks defining results of Behaviors of the enterprise or its sub-systems, that benefit to it internal or external customers : Outcome Event, 2. Blocks used to describe information: Information Asset. 3. Blocks used to describe how the enterprise operates: Operating Assets (Agent, Behavior, Service Interface). All Functional Assets are constrained by Policys and are exposed to Risk Types.
OMG - UAF - UAFElement	Asset Block An Asset Block is an Architecture Block used to describe the System Operating Framework - SOF of the enterprise and its systems. Abstract super type for all of the UAF elements. It provides a way for all of the UAF elements to have a common set of properties. Abstract super type for all of the UAF elements. It provides a way for all of the UAF elements to have a common set of properties.

CHARTER

Missing Content

Governance

Provide Feedback