Enterprise Mission in UAF is a specialization of Actual Enterprise Phase. But in what sense is a Mission some kind of Phase? Mission is defined in UAF as "captures at a high level what you will do to realize your vision". A Phase is not "what you will do" but rather organizing a collection of things to do to achieves goals assigned to that Phase. Need to put Mission into UAF the way it was done in UPDM. Mission is more like an Enduring Task. In UPDM a Mission was an extension of a Use Case. Need to also add a way to capture a Mission Thread.

See attached slides.

The UAF Modeling Language (UAFML) especially suited for modeling an enterprise and as such it is appropriate for modeling a large and complex mission architecture along with its variety of scenarios, vignettes, MTs, METs, etc. The following extensions to UAF will provide support for Mission Engineering and alignment with best practice.
The following elements need to be added to UAF to support Mission Engineering.
1 Mission The task, together with the purpose, that clearly indicates the action to be taken and the reasoning behind the mission. (JP 1-02)
2 MissionThread A sequence of end-to-end mission tasks, activities, and events presented as a series of steps to achieve a mission. (OUSD(R&E))
3 ActualMission A particular mission to accomplish assigned mission objectives
4 ActualMissionPhase A particular phase in the accomplishment of an overall actual mission
5 MissionScenario Description of the geographical location and timeframe of the overall conflict. A scenario includes information such as threat and friendly politico-military contexts and backgrounds, assumptions, constraints, limitations, strategic objectives, and other planning considerations. (OUSD(R&E))
6 MissionVignette Same contents as a MissionScenario except that it can represent small, ideally self-contained parts of a scenario. (OUSD(R&E))
7 ActualMissionScenario A particular mission scenario within which an actual mission is to be accomplished
8 ActualMissionVignette A particular mission vignette within which an actual mission is to be accomplished
9 MissionTask A clearly defined action or activity specifically assigned to a system, individual or organization that must be completed. (MEG 2.0).
10 MissionTaskAction The usage of a MissionTask within a MissionThread.
11 MissionEngineeringThread A sequence of end-to-end mission-related resources, functions, actions, states, and events presented as a series of steps that supports a mission thread
12 ConflictsWith Tuple that indicates elements acting against or in opposition to each other. This means that there are elements in the model that disagree about something important or are incompatible with each other in some way
13 Opposes Tuple that indicates an open clash between two opposing groups (or individuals). This means that elements in the model are fighting against each other or are providing strong resistance to progress towards some goals
14 OpposableElement Type of element that is categorized to allow for it to have an Opposes relationship to some other opposable element.
15 DesignationKind Defines the type of structural element with respect to purpose, intent and capabilities of that element.
16 Doctrine A formal expression of military knowledge and thought, accepted as being relevant at a given time, which covers the nature of conflict, the preparation of the military forces for conflict, and the method of engaging in conflict to achieve success... it is descriptive rather than prescriptive, requiring judgement in application.
17 Defines A tuple that links the Mission and the Activity that implements it.
18 MissionKind An enumerated list of kinds of missions. These include:
19 Battle A hostile encounter between opposing military forces
20 Campaign A series of related major operations aimed at achieving strategic and operational objectives within a given time and space. (JP 5-0)
21 Engagement A tactical conflict, usually between opposing lower echelons maneuver forces. See also battle; campaign. (JP 3-0)
22 MajorOperation A series of tactical actions (battles, engagements, strikes) conducted by combat forces, coordinated in time and place, to achieve strategic or operational objectives in an operational area. (JP 3-0)
23 NationalPolicy A broad course of action or statements of guidance adopted by the government at the national level in pursuit of national objectives. (JP 1)
24 Other A different kind of mission.
25 SmallUnitAndCrewAction Small unit and Crew Action is the combat deployment of platoons and smaller units in a particular strategic and logistic environment
26 TheaterStrategy An overarching construct outlining a combatant commander’s vision for integrating and synchronizing military activities and operations with the other instruments of national power in order to achieve national strategic objectives. See also national military strategy; national security strategy; strategy. (JP 3-0)
27 ForceDesignation Indicates whether the structural element is an enemy, ally, neutral or other force. The colors may vary according to country so can be replaced as required. These include:
28 BlueForce Structural elements corresponding to the instigating or friendly force.
29 RedForce The structural element is an enemy force.
30 GreenForce The structural element is an ally.
31 GrayForce The structural element is a third party force.
32 Unknown The structural element is unknown.
33 WhiteForce The structural element is neutral.
For support of Doctrine, a new element will need to be created called Doctrine which is a subtype of both requirement and standard. It will contain the following fields:
1 createdBy The organization or creator of the standard or doctrine.
2 publishedBy An entity responsible for making the resource available.
3 createdStandards A relationship between an actual organization and the standards created by that organization.
4 publishedStandards A relationship between an actual organization and the standards published by that organization.
For enterprise architectures and mission engineering we need to be able to define a new type of a constraint which is an assumption.
Assumption EnumerationLiteral added to RuleKind Enumeration indicating that the element is accepted as true or as certain to happen, without proof.
The following Diagrams will need to be created to support modeling of Missions:
1 Resources Processes: Mission Engineering Threads
Stakeholders: Solution Providers, Systems Engineers, IT Architects.
Concerns: captures activity based behavior and flows performed by resources and organizational assets.
Definition: describes the functions that are normally conducted in the course of implementing operational activity(ies) in support of capability(ies). It describes the functions, their Inputs/Outputs, function actions and flows between them.
Recommended Implementation: SysML Activity Diagram, SysML Block Definition Diagram."
2 Operational Processes: Mission Threads "[Need a new description according to the template below]
Stakeholders: Business Architect, Systems Engineers, Enterprise Architects
Concerns: captures activity based behavior and flows performed by mission actors and related operational and strategic assets.
Definition: describes the activities that are normally conducted in the course of achieving business goals that support a capability. It describes operational activities, their Inputs/Outputs, operational activity actions and flows between them.
Recommended Implementation: SysML Activity Diagram, SysML Block Definition Diagram, BPMN Process Diagram."
3 Strategic Processes: Mission "[Need a new description according to the template below]
Stakeholders: Program/Project Managers, Portfolio Managers, Enterprise Architects, Executives.
Concerns: capability phasing.
Definition: shows the relationship between strategic phases and the Capabilities that are intended to be developed during the strategic phases, and the actual organizations involved.
Recommended Implementation: SysML Block Definition Diagram."
4 Parameters: Mission Vignette and Scenario "[Need a new description according to the template below]
Stakeholders: Capability owners, Systems Engineers, Solution Providers.
Concerns: defines the environments and conditions for execution of mission(s)+C10
Definition: shows the elements and relationships that are involved in defining the environments and conditions applicable to capability, operational concept or set of systems.
Recommended Implementation: SysML Block Definition Diagram."

Many Standards prescribe particular processes (such as ISO 15288, DO-356A, etc). Having a Standards Activity with Standards Process Flows would allow us to model the Standards as processes with inputs and outputs, then show how Operational processes ConformTo the Standards Process.

Viewpoints are defined as a convention for creation, interpretation, and use of an architecture to frame one or more stakeholder concerns.
Views are defined as the information item governed by the Viewpoint that communicates some aspect of an architecture.
Stakeholder Concerns relate to a Viewpoint, and to a View only through its "governed by" relationship to the Viewpoint.
Views may only be governed by one Viewpoint, but Viewpoints can govern many Views.

The problem is that the traceability for a Stakeholder Concern only comes through the Viewpoint (not the View itself) and thus every View that is governed by the Viewpoint is said to relate to every Stakeholder Concern framed by the Viewpoint. This may not be true.

For instance, I will use Resource Connectivity diagrams as an example for a Viewpoint. I have multiple stakeholders that may want to see a Resources Connectivity diagram. One might want to understand the internal connectors of the system. One might want to understand the flow properties of the system. One might want to understand the external connections to the system. If I make three views (one that shows internal connections, one that shows flow properties, and one that shows external connections), then all three Views are governed by the Resource Connectivity Viewpoint, and every stakeholder Concern can be addressed by Resource Connectivity, but not every View does address every stakeholder Concern. Further, I can't use the model relationships to filter my Views by Stakeholder Concern because the traceability provides every view that is governed by the Viewpoint.

I can solve this by further specifying my Viewpoints. I can specialize Resource Connectivity Viewpoint and require external connections, or internal connections, as related to the Stakeholder Concern. This requires a very high degree of specificity in my viewpoints to ensure that a query across one Stakeholder Concern does not return Views intended for other Stakeholder Concerns.

It may be better to trace Stakeholder Concerns to the Views themselves (having an "answers" or some other relationship) to allow for limitation on this query.

Op-If is mapped with DIV-1, and Rs-If is mapped with DIV-2.

According to Appendix A the correct mappings should be: Op-If <-> DIV-2, Rs-If <-> DIV-3

Fig 3.38 is missing MotivatedBy

MilestoneDependency should be renamed MilestoneSequence to
be consistent with the definition and consistent with ProjectSequence

Dependency is too overloaded

in the standard there is no statement for Sequence about whether the client is assumed to be before or after the supplier... one could
reason it either way... clients should always be dependent on suppliers... and because suppliers should have to finish before
clients can proceed it is assumed that the suppliers are the before and the clients are the after... but this should be made explicit

VersionSuccession does not tell which is the successor in the documentation does not explain which is the successor to whom... the client or the supplier... I am presuming that the client is dependent on the supplier so the client is the newer version and the supplier is the older version... needs to be explicit in the standard

architectureFramework as a String should be in the Attributes... and shown as such in the diagram and the text below needs to be altered

Forcast needs to specify explicitly in the documentation that the supplier end is the older subject and the client end is the newer subject

ComparesTo is ambiguous ... which is the desired, which is the achieved... presuming desired is the supplier and achieved is the client but should be made explicit in the standard

Forcast needs to specify explicitly in the documentation that the supplier end is the older subject and the client end is the newer subject

ProjectSequence is ambiguous ... needs to specify before and after with supplier and client

UAF is missing a CourseOfAction element... would suggest looking at ArchiMate's version of CourseOfAction as an example

Figure 9:336 – ActualService is italics yet it is not abstract... need to change

ActualService in Metamodel is abstract... it is not in profile... need to fix

some places are Project some place are Projects

e.g.
View Specifications::Projects::Roadmap::Project Roadmap

need to have a separate MilestoneSequence from MilestoneDependency

and should add a ProjectDepdency as well

Figure 9:321 – ActualProjectMilestone
Constraints
[1] unnamed1
startTime=endTime

non-named constraint

also ActualState has attributes startDate and endDate... not startTime and endTime

The word ‘realizingArchitecture’ between the [Abstract]Architecture and [Tuple]Implements is misspelled in Figure 8:11 - Summary & Overview. The letter d is redundant.
In addition, thanks to the OMG organization for developing the documentation about UAF, which made me learn a lot.

The description in this section is a copy of View Specifications::Resources::Traceability and View Specifications::Personnel::Traceability. The desciption os also not in accordance with the example problem in section 14.3 of the Sample Problem (dtc/2021-12-12). Also, Ar-Tr is missing from the UAF Grid. In summary, it is difficult to understand the view specification Actual Resources::Traceability. However, we do understand the need for a view specification according to Figure 4:82.

endDate is multiplicity 0

The Achiever abstraction bundles in the same hierarchy "production agents" (actual resources) and "transformation agents" (actual strategic phases, actual projects).
While both produce effects: the former (actual resources) are about outcomes delivered by the enterprise, while the latter are about change of the enterprise itself.
Shouldn't we distinguish these two kinds of "changes".
In page 39, indeed, the EA guide states that measurements of effect are different for 'transformation effect" versus "ways and means effects":
"A Measure of Effect (MOE) parameter describes qualitative or quantitative states or levels that directly relate to outcomes. Outcomes are sought by stakeholders, whose interests and perspectives are addressed by the actual measurements of effects. These outcome measurements are different from measurements of associated ways and means."

Proposed resolution:
1. Rename "Achiever" in initiative
2. Remove "Actual Resource" as a sub-type of Achiever

The concept of "Concept Role" is missing in the DMN while it is available in the UML profile specification.
As a consequence, ConceptItems (Location and Asset) are owned by HighlevelOperationalConcept which should not be the case.

"Enterprise Visions" & "Enterprise Goals" are supposed to be valid for the whole life of the enterprise whereas "Enterprise Objectives" are time time-targeted.

Proposal:
1. Remove "Enterprise Vision" as a sub-type of Phaseable Element. Enterprise Vision is "owned" by a "WholeLifeEnterprise" as a kind of "DesiredResult" (Ends versus Means).

2. Potentially remove "Enterprise Goal" as sub-type of Phaseable Element. "Enterprise Goal" is "owned" by a "WholeLifeEnterprise" as a kind of "DesiredResult" .
This was the original intent in MODAF (see quote below from MODAF Handbook")
"Within the StV-1 view, certain Enterprise Goals are identified. These goals relate to the entire enterprise lifetime, they are not specific to an
Enterprise Phase"

3. Add "Enterprise Objective" to enterprise phases. "Enterprise Objective" is owned by enterprise phases as a kind of "DesiredResult" .

PS: The current "Phases" relationship mixes relationhip to "Ends" (Vision, Goals, Objectives) and relatonship to Means (Capabilities).
The best practice is to separate Ends and Means.

The names of Ends on MotivatedBy to not match the EA Guide and the principles establishes by the BMM on which it is grounded.
The EA Guides says that "Enterprise Goals" are "motivated by" Drvers.

Proposal:
Rename "motivatingEnterpriseGoal" in "MotivatedEnterpriseGoal"
Rename "motivatedDriver" in "motivatingDriver".

It is not clear why "Opportunity" and "Challenges" are part of "Motivatedby" as it seems to be a separate topic.

Multiple conflicting [1.1] multiplicities on Implements

Proposed solution:
(1) "Implements" is made abstract
(2) "Implements" relates UAFElement (or better "Class of UAFElement").
(3) Appropriate concrete sub-types are created for Resource, Function, OperationalAgent, etc..

Multiple conflicting [1.1] multiplicities on PerformInContext

Proposed solution:
(1) PerformInContext is made abstract
(2) PerformInContext is relates ProcessUsage to AssetRole
(3) Appropriate concrete sub-types are created for FunctionAction, OperationalActivityAction, etc.

ActivityPerformableUnderCondition bounds "process" (a class) to an individual to individual state (ActualCondition).
This breaks the BORO principle that classes should not be time bounded.

Proposed resolution:
(1) Have actualCondition as a Type
(2) or .. have ActivityPerformableUnderCondition be related to "Condition" instead of "ActualCondition".

Multiple conflicting [1.1] multiplicities on IsCapabletoPerform.

Desirer bounds "Class Entities" (Capability, Resource Performer, ..) to individual state (Actual State).
This breaks the BORO principle that classes should not be time bounded.
There is no way to relate Capabilities to Effect (class).

Proposed resolution:
1. Desirer is made deprecated and kept for compatibility
2. A new relationship is added between capability and effect

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.

UAF is currently trying to be compliant with ISO 42010. To continue with being compliant, UAF needs to be updated to conform to new term and concepts in the new version of 42010 to be published in 20022.

Since UAF is published as an ISO document, the ISO version must be compliant with the ISO style guide which has specific requirements on structure, formatting and style. Recommend that v1.3 of UAF be restructured and reformatted to be ISO compliant.

In UAF metamodel, Personnel view concepts use the Organizational Resource elements which are specialization of Resource Performers. In other words, Resource Performer is a more "abstract" concept than Organizational Resource "performers".

So, given the general pattern of rows in the grid start with most abstract at the top and most concrete at the bottom, it would be better to swap Personnel and Resources viewpoint rows so that Resources (being more abstract) appear above the Personnel (which are more concrete than resource performers).

Both the Strategic row and the States column are designated as "St" which can sometimes lead to confusion. Suggest changing Strategic viewpoint designator to "Sg" to avoid this confusion. (Similar thing was done in v1.2 when Personnel row was changed from "Pr" to "Ps" to avoid confusion with Process (Pr) column.)

NATO framework grid shows three behavioral like aspects as being grouped by Behavior. Suggest doing same for UAF Grid. Also, Taxonomy, Structure and Connectivity columns are three forms of "structure", so we should group these three columns and call that grouping Structure.

Taxonomy views are about more than "typology" and specialization since they can also include referentialization (i.e., references) and composition. These views are typically captured using SysML Block Definition Diagrams (BDD), so it would be better to call this column "Definitions".

Structure views are really about compositions, so it would be better to call this column "Compositions". Connectivity views are about dependencies, interactions or flows, so would be better to call this column "Interactions".

Actual Resources domain covers more than just instances from the Resources domain. Also covers instances from the Personnel domain (i.e., Post, Organization, Person, Responsibility). Suggest changing name to Actualization. Or perhaps merely “Actuals”?. Or perhaps “Instantiations”?. Better represents what is going on here.

See attached slides

Should be more than indication of ToBe or not ToBe. Should be a timeline of planned/expected evolution of the architecture IAW defined
states and transitions in States view. Versions should correspond to which capabilities, missions, actual measurements, etc. will be achieved for that version.

This should show more than merely “Status”. Should be a view showing the progression of maturity states for the architecture.

Should be more than just identification of a methodology (Besides, a methodology is not a process…). Should allow for capturing a process-like diagram.

One of the AM views shown in the Grid does not have corresponding View Specifications in UAFML: Architecture Taxonomy: Architecture Extensions. Add the necessary view specification in UAFML.

See attached slides

Problem with Using Portfolio element (portfolio kind of Project). The Portfolio (kind of) Project does not have the necessary semantics with the features and relationships enumerated below. Can possibly use Whole Life Configuration (WLC) element to represent a Portfolio but this only gives part of the picture of what is in the Portfolio. (a) Acts as a “collection” of things with an associated Gantt chart for deployment timelines, (b) Does not tell us who “owns” that collection of things in the Management Accountability sense, (c) A Portfolio can consist of multiple Whole Life Configurations.

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

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

See attached slides.

Two Architectural Descriptions must be able to reference each other which have no containment relationship to each other. Purpose: This supports the ability for architectures to reference each other when they sit in other separate projects and repository locations. Two Architectural Descriptions must be able to reference each other when there is an intervening containment organization.

See attached slides.

UAF specifies three kinds of Actual Measurements: Actual, Required, Estimate. But if only 1 of the 3 kinds is “actual” then the other 2 kinds are “non-actual”. Only one of the three kinds of Actual Measurement is truly an “actual” measurement kind. This is a logical inconsistency, which is a source of confusion for some modelers. Suggest changing the kinds to: Achieved, Required, Estimated (past tense). Suggest adding new kinds: Expected, and Desired.

See attached slides.

There is often a confusion between typical and actual measurements. Causes some modelers to use these elements incorrectly. Modelers sometimes insert the expected or desired “value” of a measurement into the Measurement element rather than in the Actual Measurement element. Does not make sense to allow Measurement to have any values since the Measurement element is intended to be the “standard” for doing the measuring. That would be like having a meter stick and marking 27 cm on the stick itself. For comparison purposes, look at definitions of Measurement and Measure in dictionary.

Definition of measurement: the dimension, quantity or capacity determined by measuring. Which is really what “actual measurement” element is dealing with. Definition of measure: a reference standard or sample used for the quantitative comparison of properties [e.g., a “yard stick” or “meter stick”].

Proposed element name changes to address this issue. Change name of Measurement element to Measure. Change name of Actual Measurement element to Measurement. As noted above, measurement is defined as being the result of measuring. Change Measurement Set to Measure Set (to align with changes above).

See attached slides.

Need to add Use Cases as a modeling construct in UAF

Need to update the EA Guide to correct some errors with respect to v1.2. Also need to update based on changes to be made in v1.3 of the metamodel and modeling language.

Need to update the sample model to finish incorporating new model views for all of v1.2. Also need to update based on changes to be made in v1.3 of the metamodel and modeling language.

NATO has a methodology for capturing NAF compliant architecture models. Instead of changing UAF to include the specialized NAF concepts, create a separate NATO Framework Guide for UAF.

Location concept in dictionary is "determination" of the "place where something is". Would Location be a more accurate term for Location Holder concept? Location in UAF is currently enumerated with *geometric" parameters such as solid volume, surface, line, point, etc. However, Location is a more general concept.

Sometimes the Operational Architecture uses concept of Platform as the "place where something is" rather than describing the location geometrically. A Platform could be thought of a special case of Location. Also, sometimes the "place where something is" will be called an Organizational Node (agnostic to an Organization resource per se).

Make Location abstract with three kinds of Location elements: Physical Location (for current notion of Location), Platform (where something is mounted or situated), and Organizational Location (a place that has a definite purpose or a place that is responsible in an organizational sense).

See attached slides.

Node was a concept in UPDM but was replaced by Operational Agent in UAF. Needline was a concept in UPDM but was replaced by Operational Connector in UAF. Since Node and Needline are commonly used concepts in the world of operational architectures and mission modeling, add these to UAF as specializations of Operational Agent and Operational Connector, respectively.

See attached slides.

In UPDM there was a Trust Line between Nodes (now called Operational Agents in UAF). There is need to have a Trust Line for security reasons which will help in modeling the security architecture for the enterprise. Add Trust Line concept back into UAF.

There is a need for the concept of Operational Scenario which can perform Operational Activities. Many modelers use an Operational Architecture as the entity to capture notion of a Scenario or Vignette or Use Case. Add Operational Scenario as new kind of Operational Agent. May also need to add Resource Scenario as new kind of Resource Performer.

See attached slides.

An architecture is defined as "fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes" [ISO 42020] An Architecture has no "agency", i.e., an architecture cannot do anything since it is a property of the thing that is being architected. Therefore, Architecture cannot be a kind of Operational Agent since an architecture cannot be "capable to perform" operational activities.

Change Operational Architecture to Operational Configuration. Change Architecture to Configuration. Change Resource Architecture to Resource Configuration. Add Architecture as new separate element and add relationship Configuration <has> Architecture. Architecture is still <described by> Architectural Description. Make Operational Architecture a Capable Element and likewise for Resource Architecture and Service Architecture. Add Service Architecture to Figure 9:130 in DMM since it is missing.

See attached slides.

Capability is defined as an "ability to do something". As such, a capability cannot desire some state or some effect. Only things with "agency" can desire something. Agency is defined as the "means or mode of acting". Operational agents and resource performers have the "means of acting" while a capability does not possess this quality. Only some kind of "action" can lead to effects or state changes. See briefing slides.

Add relationships Operational Activity <leads to> Actual State and Function <leads to> Actual State (and same for Service Function). Remove Capability as a Desirer but link it to Actual State directly with <enables> relationship. Make Capability Configuration <exhibits> Capability.

See attached slides.