'CapabilityConfiguration. A composite structure representing the physical and human resources (and their interactions) in an enterprise, assembled to meet a capability'

'System. An integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements (INCOSE SE Handbook V4, 2015).'

1) As defined CapabilityConfiguration in including interactions and providing a capability is closer to being able to represent a System than the System element itself
2) CapabilityConfiguration is a legacy MODAF element. In the early days of MODAF in the MOD Architectures Lab it was common place to use the CapabilityConfiguration element to represent a system. The MoD never really addressed the problem and left the two distinct elements. There seems to be no good reason to have both or, if there is, what is the differentiation [remembering that the definitition shouldn't refer to any other metamodel element as it must be atomic and self-contained. Being connected to different other metamodel elements doesn't mean that the type is distinct - this can be corrected by changing the metamodel wiring to the CapabilityConfiguration or System element.

'No new terms and definitions have been required to create this specification. All terms are available in the normative references or bibliographic citations for detailed explanation'

This is clearly untrue - there are terms, such as 'View Specification', which if distinct from Architecture Viewpoint needs to be defined to differentiate it.

As an authorative standard that claims to have semantic underpinnings this is wholly unacceptable - what is the master source to be used/referenced in an implementation? There is no traceability. From an engineering perspective any design implementation must be provided with the means to create full traceability to the UAF spec and, where appropriate, the particular source definition.

Definition: 'A type of a human being used to define the characteristics that need to be described for ActualPersons (e.g., properties such as address, telephone number, nationality, etc.).'

1) 'sub-' anything is never a type. The 'sub' simply indicates a position in a hierarchy but the type is the same.

2) An Organization is not a Human Being

3) The definition of a type should be atomic and self-contained - it cannot depend on any other element such as 'ActualPersons'

Organization is defined as 'A group of OrganizationalResources (Persons, Posts, Organizations and Responsibilities) associated for a particular purpose'. This shouldn't include other metamodel elements for the same reason i..e not OrghanizationalResource etc.

Fig 7:3
Definition - 'A Tuple denotes a relationship that exists between elements.'

This is incorrect - it defines a relationship (as it says). A tuple has to also include the start and finish nodes as well to form the smallest tuple - a triple.

Looking at the diagrams it is the legend definition that is incorrect because the green coloured elements are relationships not triples. A clue is in Fig 8:28 on p49 ActualResourceRelationship is identified in green and is clearly just a relationship.

'Further, The UAF conforms to terms defined in the ISO/IEC/IEEE 42010 standard for architecture description, where the terms .... form correspondence rules specified as constraints on UAF.'

This is incorrect. Terms / definitions cannot form correpondence rules.

It isn't obvious whether there are any correpondence rules in the UAF given that it is the definition of the individual AF that defines the rules for the content of any particular view - the UAF just provides the "kit of parts" to enable the user to create them. If the UAF does itself define its own correspondence rules this would need to specified separately and somehow deal with potential inconsistencies wrt what does conformance etc then mean.

Definition: 'A type of a current or future state of the enterprise.'

This looks as thought it's a legacy MODAF 1.2.003 definition.

1) A state is an abstract reference to a set of property values or conditions. A phase is a reference to a duration. This would be better defined as a distinct stage in the life? of an Enterprise. The problem is otherwise that there is no connection between the element name and definition.
2) 'current' or 'future' is irrelevant and incomplete - if it occurs in the past is it therefore no longer an EnterprisePhase? The definition shouldn't depend on a particular time value.
3) 'type of' shouldn't be in the definition. All the elements in a metamodel are types so it cannot form part of any differentiating feature.

toBe: Boolean[1] Indicates whether the ArchitecturalDescription represents an Architecture that exists or will exist in the future.

This is incorrect. This is a property of the Architecture not the ArchitectureDescription i.e. an ArchitectureDescription of a future Architecture not a future ArchitectureDescription of an Architecture.

This is another consequence of not differentiating properly between 'architecture' and 'architecture description'.

Definition
'Interest in an EnterprisePhase (EnterprisePhase is synonym for System in ISO 42010) relevant to one or more of its stakeholders'

1) This doesn't conform to the ISO 42010 definition of a Concern and hence invalidates claim to be compliant
2) An EnterprisePhase is not a synonym for System, and certainly not in ISO 42010

In Fig 9:211

1) the 'concern' role name placed against Concern on the Viewpoint - Concern relationship is meaningless - using the same label as the name of the adjacent node element is in effect leaving the relationship with no name whatsoever - it proviode no information about that relationship. In ISO 42010 this relationship is named 'frames' - this should be . The cardinality is incorrect - it should be 1..*.

2) the relationship between Stakeholder and Concern should be named 'has'. The cardinality is incorrect - it should be 1..*

3) There should be no relationship between ActualEnterprisePhase and Concern

'A type used to denote a model of the Architecture, described from the ResourcePerformer perspective.'

A model is not an architecture - it might, however, describe an architecture description. The definition is therefore that for a type of architecture description not architecture. The definition is wrong and needs to be changed - suggestion is to base on the ISO 42010 conceptual model - 'architecture'.

It is also an error to include in any definition any relationship - definitions of elements should be atomic / self-congtained and not depend on any other element or relationship otherwisse a) you're not defining the element - it might be a triple b) if the structure/ relationships change then the element definition no longer holds.

'The UAFP can be used to develop architectures compliant with:
• Department of Defense Architecture Framework (DoDAF) version 2.02'

This is incorrect. Architecture Descriptions might be compliant with an AF such as the DoDAF but architectures them selves are certainly not. This is a general problem - the lack of differentiation between 'architecture' (the thing being described) and 'architecture description' (the description). It probably isn't helped by loose casual everyday talk but in a document with defined semantics it is an error - it's the equivalent of confusing the 'duck' with the 'photo of the duck'.

It also looks as though this has affected some of the metamodel element definitions e.g. ResourceArchitecture

Reported in behalf of Boeing.

Continuing the progress we have been doing on getting rid of tag properties and replacing them by dependency type of relationships, there are still some tag properties to be replaced between the view, viewpoint, concern, architecture description, and stakeholder. Having tags, they cannot be properly displayed on the diagram, where dependencies can.

the term DataElement is no longer used. should update definition of ResourceExchange.conveyed from:
"ResourceCommunication, the conveyed element must be stereotyped «DataElement» or its specializations,"
to
"ResourceCommunication, the conveyed element must be stereotyped «ResourceInformation» or its specializations,"

We keep getting error while importing. It tries to load the file and fails when trying to read the first character, with a "invalid byte" message. Not sure if this has been reported before. If so would it be possible to share updated UAF.xmi? If not, would it be possible to share the name of the tool it was created with?

I learned that the OMG has deprecated UML 1.x XMI 1.x well over 10 years ago when it was replaced by UML 2.x XMI 2.x.

Also learned that the OMG UAF.xmi file is in UML XMI version 1.x. Probably generated from a tool like Sparx Enterprise. Because UML 1.x is an outdated version it is not possible to import the current UAF.xmi file posted on your site for analysis, causing import errors.

This requires providing the UAF.xmi files using the current UML 2.x XMI 2.x version.

Please provide/replace the UAF.xmi files posted on your site with UML 2.x XMI 2.x version to import the specification in to a modeling tool for analysis.

p213 Viewpoint is defined as 'An architecture viewpoint frames (to formulate or construct in a particular style or language) one or more concerns.'

1) Doesn't conform to ISO 42010 'work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns'
2) This definition doesn't define what an Architecture Viewpoint is - only one of the relationships with Concern. Definitions should be atomic and not include related elements otherwise a change in model structure invalidates the definition. Also, semantically, they have to be standalone.

3) The element should be named 'Architecture Viewpoint' as the definition states. This is important as pointed out earlier to differentiate it from the casual use of 'Viewpoint' and anchor it to ISO 42010.

4)There is a general problem with diagrams where role names are used which have the same name/label as an adjacent element - see Fig 9:215.
The role names provide no additional information and in effect you have unlabelled relationships. In this particular case the relationships should take the names from the 42010 conceptual model. 'language' should be 'architecture description language'. Unclear why 'purpose' is there as distinct from framing one or more concerns i.e is the purpose different from framing the concerns, if so, how?

5) 'View' should be 'Architecture View' to differentiate it from other meanings e.g. as a collection of view definitions.

6) The cardinality between View and Viewpoint is wrong if conforming with 42010 - it should be 1:1 between an Architecture View and its governing Architecture Viewpoint.
7) To conform with ISO 42010 the relationships should take the same names i.e. Viewpoint governs View, Viewpoint frames Concern (and should show Stakeholder has Concern)

8) There is an error in ISO 42010 conceptual model replicated - the requirement for an Architecture Description to contain one or more Architecture Viewpoints - Architecture Viewpoints may be held externally as what used to be termed Library Architecture Viewpoints.

On page 4 the document states 'The UAF conforms to terms defined in the ISO/IEC/IEEE 42010 standard for architecture description'. It also states in section 4 Terms and Conditions 'No new terms and definitions have been required to create this specification. All terms are available in the normative references or bibliographic citations for detailed explanation'

Despite these claims the document frequently uses 'viewpoint' with a different meaning from that of ISO 42010 i.e. not as a specification against which an architecture view is prepared and interpreted but:-
1) 'viewpoint' = collection of architecture view definitions having a common subject area (e.g MODAF::Viewpoint)

It does this with no identification of any difference in meaning and nor any definition. It often uses the different senses of 'viewpoint' in the same sentnce and paragraph:

'The aligned and renamed viewpoints from the various frameworks provide a common generic name for each viewpoint. It should be noted that the term viewpoint is in the context of ISO 42010 where a viewpoint is the specification of a view. The UAF viewpoints are mapped to the corresponding viewpoint in the relevant contributing framework. It is the viewpoints described in the DMM that provides the basis for the Unified Architecture Framework (UAF)...'

It looks like the 'viewpoints' and 'UAF viewpoints' are collections of view definitons which is confusingly and erroneously compared with the ISO 42010 definition wjhich is not the same thing at all. It also looks like the last use of 'viewpoints' might be a collection but by this point it's impossible to tell because the authors do not define the terms that they use.

In 7.2 UAF Grid it presents what seems like MODAF::viewpoint, ISO::architecture viewpoint and UAF::view specification in the same place/graphic.

p5 Type 1 Conformance 'Type 1 Conformance: - UAF View specification conformance. A tool demonstrating view specification conformance shall implement a version of all the view specifications defined in the UAF Grid, with the exception of the view specifications in the Metadata Domain. Optionally the tool vendor can implement other donor framework viewpoints, for instance DoDAF, MODAF or NAF ..'

Here 'viewpoint' = collection not a single specification. 'view specification' appears to be indistinguishable from ISO 42010:architecture viewpoint

It is extremely confusing and far from clear and non-ambiguous which are key qualities of any good requirement.

No where in the document is 'view specification' defined despite it being used in 7.2 and as a package name in the metamodel.

In ISO 42010:2011 an 'Architecture Viewpoint' is defined as 'work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns' and in the ISO 42010 conceptual model is has a 'governs' relationship with Architecture View i.e. an Architecture Viewpoint is a specification containing a set of requirements against which an Architecture View is prepared and interpreted. How then is 'View Specification' different? This is particularly the case as 'View Specification' seems not to merit a UAF metamodel element.

(typo) Page 72, View Specifications::Resources::Roadmap::Resources Roadmap: Evolution has a Stakeholder named "Implements" and I think you mean "Implementers" as is used in other areas.
(typo) Page 83, View Specifications::Projects::Taxonomy::Project Taxonomy doesn't put the Stakeholders, Concerns, Definition, and Recommended Implementation on separate lines like every other View Specification does.

Page 31, View Specifications::Operational::Connectivity::Operational Connectivity and Page 37, View Specifications::Operational::Constraints::Operational Constraints both have a Stakeholder named "Architects" whereas all other View Specifications specify one or several types of Architects. Are all other named types of Architects assumed?

In general, what are your definitions/assumptions for Business Architects versus Enterprise Architects versus IT Architects, all of which are used as Stakeholders in various View Specifications?
What are your definitions/assumptions for Solution Providers versus Implementers, both of which are used as Stakeholders?
What are your definitions/assumptions for Decision Makers versus Executives versus Owners Responsible for Operational Agents, all of which are used as Stakeholders in various View Specifications?

Page 37, View Specifications::Operational::Constraints::Operational Constraints contains a Stakeholder called Program Sponsor. What is your definition for "Program" or that overall Stakeholder?

Though here is a view called Strategic Constraints, there are no elements available to capture them. Strategic Constraint element needs to be added to the specification consistently with constraint elements in other domains, e.g., Operational Constraint.

Strategic Constraint added

Strategic Constraint element added to support Strategic Constraints View Specification

Update in Appendix A (Traceability) document to reflect changes in the normative documents is needed. Mapping tables to source frameworks like DoDAF, NAF, MODEM are necessary to be updated to demonstrate continuation to comply with source frameworks as indicated in the UAF RFP requirements,

Appendix A (Traceability) document updated to reflect changes in the normative documents

Appendix A (Traceability) document updated to reflect changes in the normative documents:
-Mapping tables to source frameworks like DoDAF, NAF, MODEM are updated to demonstrate continuation to comply with source frameworks as indicated in the UAF RFP requirements,
-Backwards compatibility to UAF 1.1 and UPDM 2.1 are updated.
-Mapping table to SysML is updated.

Update Appendix B (Example) document to reflect changes in the normative documents by
-adding new view specifications
-new elements
-removing deleted elements
-updating existing view specifications

Appendix B (Example) document updated to reflect changes in the normative documents

Appendix B (Example) document updated to reflect changes in the normative documents by
-adding new view specifications
-demonstrating the use of newly added elements
-removing deleted elements
-updating existing view specifications

Add support for Value Streams in UAF. Please consider Value Streams implementation as described in Business Architecture Metamodel. Provide support for strategic value streams, value stream stages, before/after relationship between different value stream stages, value networks, operational value streams, and outcome (value) produced by the value stream.

Reported in behalf of Boeing

Value Stream concept added to the Strategic Viewpoint

Added support for Value Streams in UAF. In addition added before/after relationship called Sequence and OwnsValue relationship.

Users of UAF need a guide on how to use UAF to develop architecture models. The Guide needs to be part of the UAF Specification to ensure it can be properly referenced in organizational documents, contracts, handbooks, etc. The Guide can be a non-normative component of the UAF Specification.

UAF EA Guide document introduced

EA Guide for UAF was developed based on a comprehensive workflow that addresses all of the UAF views in v1.2. Each step in the workflow has a conceptual schema for the key concepts associated with the UAF views in that step. Each step is described in terms of what the view contains for that step. The EA Guide is a non-normative component of the UAF spec.

UAF currently claims complying with 42010; but usage of the term “model kind” in DMM is not in line with ISO 42010 (Clause 3.9 model kind = “conventions for a type of modelling”).
In DMM, “Model Kind” refers to a column of the UAF grid, which is more what is called an “Aspect” in the update of the ISO 42010 reference.
Similarly, the rows of the UAF grid, currently called “domain” ―term undefined in UAF― could be called “Perspective”, as it is worked in the update of ISO 42010.

Terms updated to be better compliant with ISO 42010

All appearances of the terms Domain, Viewpoint, and Model Kind renamed in all the documents.

Domain renamed Viewpoint (compliant to ISO 42010)
Viewpoint renamed to View Specification (UAF specific)
ModelKind renamed to Aspect (compliant to ISO 42010)

Opportunities to be pursued can present additional Risks to the enterprise or to its stakeholders. Need to expand Risk to cover more than security risks. Risk Mitigation should be more general than that which performs security process or satisfies security control (shown in presentation).

Opportunities can be negated by associated Risks. Important to balance new Opportunities with associated Risks. At enterprise level, Opportunity Management can have greater impact than Risk Management.

*Risk concept generalised *

Risk in v1.1 was only associated with those that are mitigated by security controls as they pertain to views in the Security Domain. Risk is more general notion that can be applied to any element in the architecture, so a new Risk element was added and the old Risk element was made a subtype name Security Risk.

Should create a new Architecture Management Domain to collect management-like views and add new ones.

This would help provide better support to portfolio management and transformation planning:
-Capture this additional information on front end for support to Analysis of Alternatives (AOA) activities
-Capture Architecture Governance decisions and directives
-Portray architecture change metrics with goals and achievement levels

Can collect other views into this area:
-Can move Summary and Overview into this Domain, as well as Dictionary
-Can move Requirements and Standards views into this Domain (since these are in practice used as means to manage changes to the architecture)

Metadata renamed to Architecture Management and additional view specifications added

Additional views were added to address architecture development method, architecture principles, architecture roadmaps and architecture traceability, views that are needed to help manage the development of the architecdture. Hence the name of this domain changed from Metadata to Architecture Management.

There some discrepancies in the display of the UAF classes.
Can the color consistency be checked automatically?

See the legend figure, and an example of two classes having different colors in two diagrams.

The issue fixed in the previous release

The issue no longer exists in formal/19-11-05.

“A Domain Metamodel (DMM) uses UML Class models to represent individuals, types and tuples that aggregate the concepts defined in DoDAF, MODEM, NAF, DNDAF and other frameworks. “ is not correct… and in fact not possible.

Same terms and concepts provided by the available architecture frameworks are unfortunately not all compatible.
I do recommend either removing this sentence or elaborating on the compatibility of the UAF terms and concepts with those of the other Architecture Framework.
This compatibility definition is a starting point for interoperability between architecting environment and tools.

Text updated

formal/19-11-05 page 11 text revised:
from: A Domain Metamodel (DMM) uses UML Class models to represent individuals, types and tuples that aggregate the concepts defined in DoDAF, MODEM, NAF, DNDAF and other frameworks.
to: A Domain Metamodel (DMM) uses UML Class models to represent individuals, types and tuples that maps the concepts defined in DoDAF, MODEM, NAF, and other frameworks.

Considering the current UAF specification (V1.1beta) available to me, I think that it is not acceptable to do have a part or chapter or at least DMM Clause 4 providing a clear set of definition.
I.e. Key terms are used and not formally defined. In particular, there is no definition for:

• Domain.
• Enterprise
• Architecture
• Model
• Language
• Enterprise Architecture
• Enterprise Model
• Enterprise Model
• Enterprise Modeling Language.

Glossary added into the UAF EA Guide document

Text updated in the UAF DMM document chapter 4 to:
No new terms and definitions have been required to create this specification. All terms are available in the normative references or bibliographic citations for detailed explanation. The modeling concepts specified in this standard e.g., MetaModel Elements, Viewpoints, Aspects, View Specifications, etc. are defined in the appropriate section for that concept. Additional terms are defined in Appendix C: Enterprise Architecture Guide (EAG).

Personnel Domain identifier is "Pr". Process Model Kind identifier is also "Pr". Would be helpful if Personnel used a different identifier to avoid confusion with Process. Suggest the use of "Ps" identifier for Personnel Domain.

A list of abbreviations updated

formal/19-11-05 updated by:
1. page 15 text revised
--from Pr
--to Ps

In the View Specifications::Operational::Structure::Operational Figure 8:10 - Operational Structure
OperationPerformer and OperationalArchitecture are generalized by OperationalAgent and so the generalization end open triangle arrowhead is missing at OperationalAgent on the association between the three elements.
The correct generalization open triangle arrowhead is shown in the definition of OperationalPerformer on Page 135 in Figure 9:59 and in the definition of OperationalArchitecture on page 133 in Figure 9:56.

Generalization relationship displayed correctly

formal/19-11-05 updated by replacing Operational Structure diagram with the updated one (attached). Updated diagram contains updated arrowhead of the generalization relationship between Operational Performer and OperationalAgent

Figure 8:15 - Operational Interaction Scenarios shows elements associated with Resource Interaction Scenarios, not Operational Interaction Scenarios. The Elements list below the figure is correct.

Editorial mistake

There was an editorial error where incorrect diagram was copied to the Operational Interaction Scenarios viewspec. This diagram will be replaced by the correct one.

General observation:
Throughout the dtc/19-06-16 DMM PDF there appears a broad right margin in light grey.

Individual observations:

p4 1.4 Related Documents

The specification includes a metatmodel and description as separate documents.

-> metamodel

Other appendicies are also provided as separate documents.

-> appendices

p5 Type 4 Conformance

A tool demonstrating model interchange conformance can import and export conformant XMI for all valid UAFP models.

-> can import and export conforming XMI

p59 View Specifications::Personnel::Roadmap::Personnel Roadmap: Evolution

Definition: provides an overview of how a organizational structure changes over time.

-> an organizational

p89 View Specifications::Actual Resources::Structure::Actual Resources Structure

Concerns: the analysis.e.g. evaluation of different alternatives, what-if, [...]

-> the analysis, e.g. evaluation

p157 ResourceParameter Description

A type that represents inputs and outputs of an Function.

-> a Function.

p164 ResourceMessage Description

Message for use in an Resource Event-Trace which carries any of the subtypes [...]

-> in a Resource Event-Trace

p166 top, DataRole Description

A usage of DataElement that exists in the context of an ResourceAsset.

-> in the context of a ResourceAsset.

p192 Domain MetaModel::Actual Resources

Concerns: the analysis.e.g. evaluation of different alternatives, what-if, [...]

-> the analysis, e.g. evaluation

Issue no longer exists in the official version of the UAF 1.1. specification

Documents formal/19-11-05 and formal/19-11-07 no longer have editorial errors specified in this issue. Obviously the issues existed in the earlier versions of the specification formal/19-06-15 and formal/19-05-10.

Information and Data Assets. “Asset as applied to Security views, an abstract element that indicates the types of elements that can be considered as a subject for security analysis.” Limited in the model to making these assets “secure”.

Need to add Knowledge as a Strategic Asset. Key element in doing Portfolio Management. Much value of the Enterprise can be tied to the Knowledge that it owns or controls. Some capabilities deal with acquisition, utilization, selling, and protection of Knowledge.

Assets need to be expanded for use beyond just the Security Domain

Strategic Information added

Issue resolved by adding new element called Strategic Information which is a type of Strategic Asset that maps to one or more Enterprise Goals/Objectives. Strategic Information is also a Strategic Exchange Item.

Opportunities represent a “possibility due to a favorable combination of circumstances”. Opportunities are identified and prioritized based on their ability to address the Challenges identified in the upfront identification of enterprise Drivers. Opportunities for changes to the enterprise and its underlying operational and resource assets are identified to serve as basis for assessing architectural tradeoffs.

Opportunities can present additional Risks to the enterprise or to its stakeholders. Need to expand Risk to cover more than security risks (see other issue on expanding use of risk beyond security). Risk Mitigation should be more general than that which performs security process or satisfies security control (shown in attached file).

Opportunity element added

Opportunity added as a new element to represent a “possibility due to a favorable combination of circumstances”. Opportunities are identified and prioritized based on their ability to address the Challenges identified in the upfront identification of enterprise Drivers. Opportunities for changes to the enterprise and its underlying operational and resource assets are identified to serve as basis for assessing architectural tradeoffs.

Need a way to specify the “final consequence or product” for the enterprise as a whole. Alternative capabilities and effects (using MOE’s) are assessed for ability in meeting the set of desired Outcomes for the Enterprise as a whole and for understanding the trade space. When capability target measures are established based on the Analysis of Alternatives, then an Enterprise Phasing structure is devised and Enterprise Goals are assigned to each phase.

Cannot use Enterprise Goal for this since it is tied to a particular Enterprise Phase. Need to have a separate element to capture Outcomes for the Whole Life Enterprise. Outcome is related to “measures of value” or “measures of utility” (hence, it must be measurable). Aim is maximize for MOU for a given set of resources.

Outcome linkages needed:

• Actual State elements linked to relevant Effects
• Operational Activities linked to relevant Effects
• Effects linked to relevant Outcomes and Missions

ActualEffect and ActualOutcome added

ActualOutcome added as a new element to specify the “final consequence or product” for the enterprise as a whole. Alternative capabilities and effects (using MOE’s) are assessed for ability in meeting the set of desired Outcomes for the Enterprise as a whole and for understanding the trade space. When capability target measures are established based on the Analysis of Alternatives, then an Enterprise Phasing structure is devised and Enterprise Goals are assigned to each phase.
Desired and Achieved Effects refactored by introducing Effect and ActualEffect elements and renaming dependencies AchievedEffect and DesiredEffect to Achieves and Desires.

Change name of column "Interaction Scenarios" to "Interactions" in the UAF grid for the following reasons:

• the word "scenario" is specific to some application domains, while other words are sometimes used, eg timing diagram, sequence diagram, event/trace, mission thread, execution thread, workflow
• scenarios can also be captured in other columns, eg Processes, States, Taxonomy (define hierarchy of scenarios), Structure (define composition of scenarios, high level composed of lower level), etc
• some use Operational Architecture as way to capture an operational scenario and Resource Architecture as a resource scenario, and the OA and RA are not necessarily captured in the Interaction Scenarios column
• the suggested implementation for views in this column is a SysML sequence diagram (not some kind of interaction scenarios diagram)
• this is the only column name that is two words, going to one word in the name simplifies it

Also change designator from "Is" to "In".

Alternatively, this column name could be changed to "Sequencing" (Sq) if "Interactions" does not work.

Renamed to Sequences

After some discussion we rename it to Sequences following NATO framework. It is in compliance with NAF and SysML.

• Capability in service domain is different than the Capability in the Strategic domain
• Contextualized use of services is not currently available. A concept of Contract needs to be considered
• Connection between Service Specification and Operational Performer/exchange/interface. We need to say that the exchange between Operational Performers is identifying a need of a service or is using already existing service
• Straight forward way to connect Required/Provided Service Layer to Operational and Resource concepts
• Provide a way to show how Resources use Services
• Introduce Service Exchange
• Rename Service Specification to Service to keep consistency

Services layer improvements

Significant improvements has been done to improve the way Services are modelled in UAF. The improvements are as follows:
1. Service Specification renamed to Service to be aligned with the remaining of the UAF specification.
2. Addition of the contract concept to support grouping of OperationalExchanges and relating them to the existing Services.
3. Traceability from Operational to Services.

• Consumes relationship renamed to supports. Direction of the relationship changed.
• GovernedBy relationship added between Service and the ServiceContract.
  4. The way services are used in Resources are changed by introducing ResourceService concept and allowing ResourceServiceInterfaces to be used to type Resource Ports. ResourceServices can Implement Services.
  5. Information Element and Data Element are now called OperationalInformation and ResourceInformation to indicate clearly where which information element is used.
  7. Addition of Service Exchange and Service Signal to have alignment with the Operational and Resource layers
  9. Addition of Service Architecture to be consistent with Operational and Resources layers.
  The list of affected diagrams and texts are captured in the worklog.

Misunderstanding about whether the UAF Profile can be used in modeling an enterprise architecture. Not uncommon for managers to think that they must use SysML to model their EA since they don't realize that the UAFP is already designed with the semantics for modeling enterprise constructs such as capability, enterprise phase, processes, personnel, operations, services, portfolios, etc. This misunderstanding is largely due to fact that UAFP is called a "profile" and many don't understand what is meant by profile.

Suggest changing title of UAFP document to something like "UML Profile for UAF-based Enterprise Modeling". Or "UML Profile for UAF: Definition of an Enterprise Modeling Language".

UAFP renamed to UAFML

The decision has been taken by the group to rename the profile part of the specification to the modelling language following the naming convention of OMG, e.g. UML, SysML, SoaML, RAAML, etc. The change will improve clarity of the purpose of the document as the term "Profile" is not so well understood in non UML modellers community. Plus it is more than just profile. It also brings notation.

UAF v1.1 DMM p92 Figure 8:56.
There is a link to model preventive process (Mitigates).
Is there something to indicate corrective process (once the risk happens)?

Required concepts are already available

There is a link between Actual Resource and Actual Risk to address the corrective process in UAF security viewpoint.

UAF v1.1 DMM - §7.2 Spelling errors
Gird ==> Grid.
because of It is two-dimensional ==> because of its two-dimensional

Typos fixed

Typos fixed in the section 7.2 page 17 of the formal/19-11-05.

The definition of the Roadmap model kind seems to have an incomplete (last) sentence.
"Addresses how elements in the architecture change over time. Also, how at different points in time or different periods of time."

Text refined

Text changed from:
Addresses how elements in the architecture change over time. Also, how at different points in time or different periods of time.
to:
Addresses how elements in the architecture change over time.

According to UAF v1.1 §7.1 table 7.2, two distinct model kinds are addressing the modeling of connections; Structure and Connectivity.

Structure: Describes the definitions of the dependencies, connections, and relationships between the different elements.
Connectivity: Describes the connections, relationships, and interactions between the different elements.

While §1.3 emphasizes the Separation of Concerns supported by a framework.

Are we addressing the same type of connections.
If not, it should be precised there.
If yes, what about the separation of concerns?

Text updated

Text changed from:
Describes the definitions of the dependencies, connections, and relationships between the different elements.
to:
Describes the break down of structural elements e.g. logical performers, systems, projects, etc. into their smaller parts.

Original documentation:
An abstract element that details the ActualOrganizationalResources that are able to carry out an ActualResponsibility.

The class is not connected to ActualOrganizationalResources nor ActualResponsibility giving the room to many other connections.

Connection is inherited

The connection is inherited via generalisation relationship.

In v1.1 SystemConcern was changed to EnterprisePhase (dropping notion of "concern" in the change). Should have been changed to EnterprisePhaseConcern to be technically and grammatically correct.

FROM
enterprisePhase : ActualEnterprisePhase[*]
Relates a Concern to the ActualEnterprisePhase that addresses that concern (ActualEnterprisePhase is synonym for System in ISO 42010).

TO
enterprisePhaseConcern : ActualEnterprisePhase[*]
Relates a Concern to the ActualEnterprisePhase that addresses that concern (ActualEnterprisePhase is synonym for System in ISO 42010).

Duplicates UAF12-42

Duplicates UAF12-42

This issue is submitted on behalf of the NATO ACAT group and relates to the handling of effects within the UAF domain meta model.

The ACAT group wishes to extend the concept of achiever by adding StandardOperationalActivity as well as ServiceSpecification as possible achievers in addition to the already available ActualResource.

Duplicates UAF12-48

Duplicates UAF12-48

As long as we can read "The profile specification documents the language architecture in terms of UML profiling mechanism." in section 1.1 of UAFP V1.1, I strongly recommend to rename the title of this specification to read "UML Profile for UAF". I.e. The specification does aim at providing a language-independent specification to implement a UAF Profile from any kind of language or from scratch.

Merged with another proposal to rename specification

Merged with UAF12-29

Drivers identified from various (usually external) driving documents: Strategic plans, legislation, regulations, treaties, agreements, charters, etc.

Not all Drivers are relevant. Filtered by Enduring Tasks owned by the Enterprise to ensure direct relevance to its Mission. Drivers are prioritized based on relative importance to achieving Enterprise Goals and Vision.

Relevant Drivers present Challenges to the Enterprise. Challenge is a “demanding or stimulating situation” or a “call to engage in a contest or fight”.

Challenges are conditions that apply to the Opportunities for Enterprise Transformation. Challenges represent the obstacles or roadblocks to success. Assessed for their feasibility in being addressed. Assessed for relative impact on transformation and achieving enterprise goals.

Properly accounting for the motivational factors that drive change in the Enterprise

Driver and Challenge elements added

Driver added as a new element that will be identified from various (usually external) driving documents: Strategic plans, legislation, regulations, treaties, agreements, charters, etc. Relevant Drivers present Challenges to the Enterprise. Challenge added as a new element which defined as a “demanding or stimulating situation” or a “call to engage in a contest or fight”.

To maintain same pattern across layers, and to make a distinction between the "ability to operate" and the ability of the enterprise to achieve outcomes, need to have a separate kind of Operational Capability that is distinct from "Strategic" Capabilities that are relevant in the Strategic Domain.

See here for discussion about difference between Operational Capabilities and System Capabilities and Organizational Capabilities (ie, competence): https://www.sebokwiki.org/wiki/Enterprise_Systems_Engineering_Background

Merged into one issue on Different Kinds of Capability

Merged into a single issue UAF12-17

Competence is a kind of capability possessed by people and organizations. Make Competence a kind of Capability:
Organizational Resource <exhibits> Competence

Then the Competence can be shown on the Capability Roadmap for the Enterprise.

Merged into one issue on Capability Kinds

Merged into a single issue UAF12-17

Need to add a kind of capability called Feature that can be associated with a resource:

Resource Performer <exhibits> Feature

Merged in a single issue UAF12-17

Merged in a single issue UAF12-17

The diagram Service Structure (from UAF DMM V1.1, figure 8:19, p53) does not show the complete relations to support the structure of services.
The relation type is missing while it is shown in a later diagram (figure 8:22 p 56 in BPMN semantics).

Definition: shows the composition of services and how services are combined into a higher level service required to exhibit a capability or support an operational activity.

Type arrow added

Association indicating type relationship between Service and ServiceRole added in the ServiceStructure diagram.

The overall UAF specification has a logo and often this logo is also used to represent the UAF Profile. However, given that the UAF Profile is actually used as an enterprise modeling language then it would be helpful for UAFP to have its own logo (analogous to logos for UML and SysML) to help people more readily understand that UAFP can (and should) be used for modeling the enterprise. This will also help increase the uptake of UAF by enterprise architects and managers of these enterprises.

See attached file illustrates what such a logo might look like. Preferably this logo should be included on the title page of the UAFP document, as well as in UAF presentations.

Not an issue of the UAF specification

This is not an issue of the existing UAF specification. It is the to do task related to the renaming of the profile specification document.

Almost all association ends linking a class X to a class XKind are named kind.
This is not the case for SecurityClassificationKind.

Normal way:
https://issues.omg.org/secure/attachment/17591/2019-12-11%200940%20Other%20Right%20Examples.PNG

Other way to be changed:
https://issues.omg.org/secure/attachment/17590/2019-12-11%200937%20SecurityClassificationKind.PNG

Type renamed to kind

Type renamed to kind in the Security Classification diagram in DMM.

This could be useful to indicate where JIRA issues has been found.

Issue has not been found

Issue description does not contain necessary details to identify exact document, page, chapter/section. Issue reported does not recall details either. We close the issue as we were not able to find it.

Capability Dependency History:
NAF 3.0 ==> Capability Dependency btw Capability Composition,
NAF 3.1 ==> Move of the dependencies to the Capability metaclasses,
UAF DMM 1.0 p20 ==> Direct link btw Capability (not part element),
UAF DMM 1.1 p36 ==> Dependencies btw both Capabilty and CapabilityRole.
Seems to be new compared to UAF 1.0 : only 1 link btw Capability, and no CapabilityRole metaclass.
Definition of Capability seems now the definition of CapabilityRole.

How CapabilityDependency and CapabilityRoleDependency are related to each other?
Is the second one a refinement of the 1st one?
Is there any pattern like this where both whole (Capability) and part (CapavbilityRole) are both having a similar relation?

This is how it is defined in UAF since its first release

Capability Dependency can be drawn between types, which means that Capabilities are always dependent or between Roles, which means that Capabilities may only be dependent in the specific context. Let's say a specific EnterprisePhase. How one relates to another if both are applicable in the model is a subject to the modelling approach. UAF specification is not defining any constraints.

The Strategic State view definition diagram is saturated of extra classes.
UAF 1.0 DMM - Figure 2.4 p21.
UAF 1.1 DMM - Figure 8.4 p 37.
What are the really useful metaclasses to understand the modeling of strategic states?
It seems a lot of metaclasses are out of scope.

All metaclasses are relevant

All metaclasses depicted in the given figures can be used to model desired and achieved Effects. Moreover the list has been extended to include ActualEffect and ActualOutcome as the resolution of another issue reported against UAF 1.1.

Performs in context is a very powerful concept in UAF. However, it is not very well implemented. Currently it connects Activity with Role. Which means it connects element of definition with the element of usage. It does not give much value. It should connect Action with Role. In such case it would connect two elements of usage and in particular reflect the contextualized allocation between structure and behaviour concepts.

The issue is no longer valid

Figure 3:27 – PerformsInContext in formal/19-11-07 depicts that the issue is no longer valid. All what is requested is available already in the UAF v1.1

Supporting service oriented architecture principle, exchange between performers or resources need to support the concept of a contract. Contract may be composed of several exchanges facing different directions. That is something that is missing in UAF specification at the moment.

Issue is reported by Airbus

Duplicates UAF12-33

Merged with UAF12-33

Currently Capability in UAF is representing business level capability, however; there are no corresponding elements at the solution domain. It is common practice in engineering to use a concept of Feature as a technical capability provided by a system or a set of systems. Having feature concept in UAF has beed already discussed in UAF 1.1 RTF and agreed between group members. It is something that has been requested by Boeing and now is also requested by Airbus. Another Airbus request is to make Competence a type of feature provided by organisational resources. This would fit Competence concept into the right place in hierarchy as now it is kind of left alone.

Capability Kind introduced to support the need

CapabilityKind enumerated list is added to classify the capability as e.g. operational, resource, strategic, personnel, service, security, or other. There are no specific constraints added when which of the kinds is supposed to be used. It depends on the methodology used within the organization. The generic use of Capability kinds is addressed in the EA guide document. By the default CapabilityKind is set to undefined.

In v1.1, "systemConcern" was changed to "enterprisePhase". But should have been changed to "EnterprisePhaseConcern" to be more grammatically and technically correct.

FROM
enterprisePhase : ActualEnterprisePhase[*] Relates a Concern to the ActualEnterprisePhase that addresses that
concern (ActualEnterprisePhase is synonym for System in ISO 42010).
TO
enterprisePhaseConcern : ActualEnterprisePhase[*] Relates a Concern to the ActualEnterprisePhase that addresses that
concern (ActualEnterprisePhase is synonym for System in ISO 42010).

No longer relevant

Changes done to the specification as a result of other issues solving makes this issue no longer relevant.
Related changes:
-the addition of the ActualStrategicPhase
-the addition of the Phases relationship between ActualStrategicPhase and Concern.

Identify and update the DMM to reflect new concepts and relationships to existing concepts. Additionally, identify all impact to existing diagrams.

ARM will be one of the major works for the next version of UAF

Deferred due to the lack of domain analysis done and the size of the scope of work and impact.

Portfolio management involves changes to the future plans and current deployments.When to add new capabilities? When and where to change operations or change resources?. When to retire legacy resources, or re-purpose them?

Overall “score” for alternative portfolio configuration is extent to which Outcomes are achieved for the enterprise as a whole. Possibilities for change come from identified Opportunities and their associated Risks. Also these come from identified new/modified Capabilities and their associated Effects.

Portfolio is normally divided into Portfolio Segments
-Could be divided by timeframe (eg, “epochs” such as near, mid, far term)
-Could be divided by “color of money” (eg, R&D, acquisition, operations)
-Could be divided by mission area

Currently using Whole Life Configuration as the Portfolio elements in EA model. WLC is a “set of Versioned Elements”. But would be more convenient to have a different model element for “Portfolio”.
-Alternative Portfolios would be examined for most cost-effective combinations
-Each Portfolio option is a provisional “set of Versioned Elements”
-Then the selected combination gets promoted to a new Whole Life Configuration (becoming the new “baseline” for program planning and scheduling)

Portfolio (kind of) Project does not have the necessary semantics with the features and relationships enumerated below.

WLC element only gives part of the picture of what is in the Portfolio.
-Acts as a “collection” of things with an associated Gantt chart for deployment timelines
-Does not tell us who “owns” that collection of things in the Management Accountability sense
-A Portfolio can consist of multiple Whole Life Configurations

Portfolio needs to have the following features:
-Things it is delivering (eg, in its Whole Life Configurations)
-Who runs it (ie, the Actual Organization)
-Particular programs within it (eg, actual Projects or project elements)
-Alignment with budget elements, assigned Opportunities and Risks, etc
-Assigned responsibility for execution of particular Enduring Tasks (and associated Capabilities)
-Accountability towards achieving Effects (eg, MOE target levels) for a given time period
-Can be assigned responsibility for certain Missions, Enterprise Goals and Enterprise Phases
-Can be jointly managed with another Enterprise for shared Operations and Resources

Might be that Portfolio could be a kind of Whole Life Enterprise (ie subtype) that has the features and relationships noted above

Deferred to the next version of UAF

Due to large scope of impacts, the issue is deferred to the next version of UAF. Inputs from Aerospace Corporation and Airbus are documented and will be used as a basis for issue resolution in the next release.

The elements in the Actual Resources views are instances of the "definitional" elements in other domains. For example, Actual Resource (classified by Resource Performer element types in Resources domain); Actual Post, Actual Person, Actual Organization (<all classified by elements from Personnel domain); Actual Resource for a Resource Mitigation (from Security domain). The new Resource Service element will be classified by a Service in the Services domain.

Notice that not all the elements shown in Actual Resources views come from the Resources domain views (ie, they also come from Personnel, Security, and Service domains). So, the name "Actual Resources" is somewhat misleading in this respect. Therefore, it would better if this domain is renamed to more accurately reflect its intended content. Suggest the name be changed to "Actualization" (Az) domain.

Actual Resources Domain review postponed

The issue requires deep analysis and has a big impact to the existing version of specification. Taking in count other improvements addressed in UAF 1.2 RTF this issue is out of scope and will be deferred to the future release of UAF.

The constraint that a operationalConnector must be implemented by another connector (resourceConnector) is too strict. I would like to be able to implement a logical connector into physical connectors and part properties. The idea can be seen in Figure 14.8 of A Practical Guide to SysML (second ed).

The connection is possible between two Resource Connectors

The connection is already possible and depicted in the Implements diagram Figure 3:34 – Implements in formal/19-11-07.

ISODateTime is currently mapped to literal string. In my opinion it does not make sense. This mapping does not allow to reuse dates in the easy way. Plus we also have the same approach with milestones implemented very differently. I do believe that both approaches need to be aligned. Dates should be easily reusable all over model.

Large scope of a change

The issue requires more investigation and has a huge impact on the specification. It is out of scope to the UAF v1.1 and will be addressed in the future releases of UAF.

Portfolio management involves changes to the future plans and current deployments.When to add new capabilities? When and where to change operations or change resources?. When to retire legacy resources, or re-purpose them?

Overall “score” for alternative portfolio configuration is extent to which Outcomes are achieved for the enterprise as a whole. Possibilities for change come from identified Opportunities and their associated Risks. Also these come from identified new/modified Capabilities and their associated Effects.

Portfolio is normally divided into Portfolio Segments
-Could be divided by timeframe (eg, “epochs” such as near, mid, far term)
-Could be divided by “color of money” (eg, R&D, acquisition, operations)
-Could be divided by mission area

Currently using Whole Life Configuration as the Portfolio elements in EA model. WLC is a “set of Versioned Elements”. But would be more convenient to have a different model element for “Portfolio”.
-Alternative Portfolios would be examined for most cost-effective combinations
-Each Portfolio option is a provisional “set of Versioned Elements”
-Then the selected combination gets promoted to a new Whole Life Configuration (becoming the new “baseline” for program planning and scheduling)

Portfolio (kind of) Project does not have the necessary semantics with the features and relationships enumerated below.

WLC element only gives part of the picture of what is in the Portfolio.
-Acts as a “collection” of things with an associated Gantt chart for deployment timelines
-Does not tell us who “owns” that collection of things in the Management Accountability sense
-A Portfolio can consist of multiple Whole Life Configurations

Portfolio needs to have the following features:
-Things it is delivering (eg, in its Whole Life Configurations)
-Who runs it (ie, the Actual Organization)
-Particular programs within it (eg, actual Projects or project elements)
-Alignment with budget elements, assigned Opportunities and Risks, etc
-Assigned responsibility for execution of particular Enduring Tasks (and associated Capabilities)
-Accountability towards achieving Effects (eg, MOE target levels) for a given time period
-Can be assigned responsibility for certain Missions, Enterprise Goals and Enterprise Phases
-Can be jointly managed with another Enterprise for shared Operations and Resources

Might be that Portfolio could be a kind of Whole Life Enterprise (ie subtype) that has the features and relationships noted above

SysML allows the use of CallOperationAction as an alternate means of mapping Behaviors (via Operation->Method metaproperty).
UAF 1.1 includes OperationalActivityAction, ProjectActivityAction, ServiceFunctionAction, FunctionAction or SecurityProcessAction which all extend CallBehaviorAction.
UAF 1.1 also includes OperationalMethod, ServiceMethod, ResourceMethod, which extend Operation, and even has metaconstraints requiring appropriately UAF stereotyped Activity used as the Method.

We recommend allowing CallOperationAction to also be stereotyped by the UAF extensions to CallBehaviorAction listed above.
We also recommend creating ProjectMethod and SecurityMethod as extentions to Operation to be consistent with other Domains.
This would facilitate it's use in Operational::Connectivity, Operational::Processes and Security Processes, Project Processes, Personnel Processes, Resource Processes and Resources Connectivity Diagrams and Tables.
This is especially useful to visualize and take advantage of CallOperationAction target pin and method resolution per UML 2.5 13.2.3.5 Behavioral Features and Methods. It is also useful for fUML 1.2.1 Polymorphic Operation Dispatching ability to execute method resolution during simulation and analysis. Thus a tighter integration of UAF with UML method resolution semantics and executability can be achieved both visually and from a simulation and analysis perspective.

ISODateTime is currently mapped to literal string. In my opinion it does not make sense. This mapping does not allow to reuse dates in the easy way. Plus we also have the same approach with milestones implemented very differently. I do believe that both approaches need to be aligned. Dates should be easily reusable all over model.

Actual Resource Relationship is described as: An abstract element that details the ActualOrganizationalResources that are able to carry out an ActualResponsibility.

This appears to be incorrect. First, this element is not abstract. Second, it should not be restricted to Organizational Resources since it should apply to any Actual Resource. Third, it does not help understand responsibilities of organizational resources.

Description of this element should be changed to read something like: An element that details the ActualResources that are involved in exchanging resources through a realized ResourceExchange.

In the UAF DMM document (https://www.omg.org/spec/UAF/1.1/DMM/PDF), starting right after "7.2 Domain Interrelationships", there seems to be an error causing the Table of Contents (TOC) to incorrectly "Domain Metamodel Diagram Legend" as Chapter 8 insead of section 7.3. This offset continued through TOC the document such that Chapters 8 and 9 are mislabeled.

In the traceability appendix, the undefined "Services Sequences" view is referenced in the DoDAF and MODAF tables, mapping to the SvcV-10c and SOV-4c, respectively. I assume this should be "Services Interaction Scenarios".

The view traceability tables in the body of Appendix A are not numbered in a logical order. They're shown as Table 2:1,1:2, 2:2, 2:3, 2:5. The numbers in the List of Tables (p. v) appear to be correct.

The elements in the Actual Resources views are instances of the "definitional" elements in other domains. For example, Actual Resource (classified by Resource Performer element types in Resources domain); Actual Post, Actual Person, Actual Organization (<all classified by elements from Personnel domain); Actual Resource for a Resource Mitigation (from Security domain). The new Resource Service element will be classified by a Service in the Services domain.

Notice that not all the elements shown in Actual Resources views come from the Resources domain views (ie, they also come from Personnel, Security, and Service domains). So, the name "Actual Resources" is somewhat misleading in this respect. Therefore, it would better if this domain is renamed to more accurately reflect its intended content. Suggest the name be changed to "Actualization" (Az) domain.

Identify and update the DMM to reflect new concepts and relationships to existing concepts. Additionally, identify all impact to existing diagrams.

Add support for Value Streams in UAF. Please consider Value Streams implementation as described in Business Architecture Metamodel. Provide support for strategic value streams, value stream stages, before/after relationship between different value stream stages, value networks, operational value streams, and outcome (value) produced by the value stream.

Reported in behalf of Boeing