Human Views for MODAF Dr Anne Bruseberg Systems Engineering & Assessment Ltd, UK on behalf of the Human Factors Integration Defence Technology Centre (HFI DTC) The need for Systems Engineering (SE) is increasingly recognised as essential in ensuring a systematic approach to new systems development. SE provides an overview perspective where the integration of many disciplines is needed for complex projects. It is also increasingly recognised that Human Factors Integration (HFI) needs to be understood and practiced as an integral part of Systems Engineering (SE). This is not always common practice, however. Human Factors (HF) practitioners and SE practitioners often find that there are communication difficulties due to differing philosophies and languages. SE practice uses Architectural Frameworks (AF) to integrate different disciplines based on common models of current and future systems. In the UK, the use of the Ministry of Defence Architectural Framework (MODAF) is now encouraged by the MoD for the support of Acquisition processes, and partially mandated. MODAF has been adapted from the US original, the DoDAF (Department of Defense Architectural Framework). Although MODAF has departed in some details from DoDAF, it still has significant commonalities. MODAF has been recognised widely as an essential tool to support capability-based acquisition, which enforces the requirement for moving away from technology-focused development. There has been growing concern as to whether both DoDAF and MODAF adequately consider HFI issues for military acquisition. 6 February 2008 Integrated EA Conference 2008 anne.bruseberg@sea.co.uk

The need for Human Views Ensure Human Factors Integration (HFI) SE needs HFI Enable socio-technical systems design Need to specify people-related design decision areas Explicitly; Correctly; Early MODAF (version 1.0) has shortfalls in that HFI needs SE Coping with design of complex systems Opportunity for early involvement

What is HFI?

Organisational & Social HFI domains Human Factors Engineering System Safety Manpower Training Personnel Health Hazards HFI Organisational & Social

HFI Functions HFI creates value through: Raising potential issues and preventing risks Establishing validated insight Providing methods, processes, data, standards, expertise Enabling user involvement Undertaking a design mediation and communication role

HFI Value Chain

HFI Value Chain

HFI Value Chain

What are Human Views (HVs)? Capturing specific human-related components of Enterprise models to enable effective HFI Ensures common modelling approach Helps HFI to relate to SE concepts/methods HFI design decision areas that can generally be perceived as formal definitions. Not: the ‘soft’ issues that may be observed Informal dependencies and behaviours (they are constraints and results) Functional definitions extending traditional meaning of ‘functional’ to HFI design areas “Human Factors Integration (HFI) is a systematic process for identifying, tracking, and resolving human related issues ensuring a balanced development of both technologies and human aspects of capability” (www.ams.mod.uk). HFI is an integral part of Systems Engineering (SE). It cannot be conducted in isolation. HVs ensure that MODAF captures all fundamental elements needed to manage the design of socio-technical systems at a structural level. HVs model human design requirements by capturing the relationships between HFI design elements at different level of abstraction. HVs help to formulate and track the reasoning behind acquisition decisions. An essential objective in defining the HVs has been to separate the ‘soft’ issues that may be observed in enterprises from those that can be clearly defined and objectively affected through decisions that change future operations. Thus, the design decision areas can generally be perceived as formal definitions. Informal dependencies and behaviours have an effect of such formal definitions. They may establish patterns, sometimes over long periods, which can constrain design decisions in the future. The HVs for MODAF: Map HFI design decision areas; Define values that help assessing the effects of the decisions; Capture dynamic factors that link structural definitions to behaviours. Whilst before, HFI concerns have largely been understood as constraints on technology design, HVs now establish that changes in technology may also be conceived as constraints on HFI design – thus widening the definition of what is perceived as ‘functional’ to include the ‘human infrastructure’. Whether or not this wider philosophy will be accepted, the HVs also have a role in better clarifying HFI constraints on technology – primarily those that have a profound impact on how equipment is defined.

The HFI question “Can this person/these people, in this job, with this training, perform these tasks, using this equipment, to these standards, under these conditions”? SE and HFI have many differences in how they approach design problems – in terms of underlying philosophy, terminology, and scope. The main question asked by HFI practitioners is often this: “Can this person/these people, in this job, with this training, perform these tasks, using this equipment, to these standards, under these conditions”? The question SE architects may ask is: “Can these capability requirements be achieved through these operational activities/nodes/information networks, fulfilled with these technology functions and structure, over these timescales, given these connectivity standards, technology trends, and organisational structure?” SE promotes a top-down approach, moving from high-level system requirements to solutions, whilst HFI takes a bottom-up approach where people are in the centre of the attention. HFI often takes the role of informing design, whilst SE often takes the role of managing design.

The HV question? “Can these operational and capability requirements be achieved - grounded in these HFI objectives and standards, through these technological and organisational structures, with these human resources, fulfilling these functions, interacting as part of these organisational/task/process dependencies, in these roles/jobs, requiring these skills and characteristics, in these locations, using this equipment, over these timescales?“ HVs provide a link between architectural models and HFI concerns. The HFI questions have to be asked at the scope of architectural frameworks, but need to include the HFI design decision elements. Thus, the HV-specific question combining both SE and HFI concerns may be: “Can these operational and capability requirements be achieved, grounded in these HFI objectives and standards, through these technological and organisational structures, with these human resources, fulfilling these functions, interacting as part of these organisational/task/process dependencies, in these roles/jobs, requiring these skills and characteristics, in these locations, using this equipment, over these timescales?“

Both MODAF and DoDAF have undergone several developments. MODAF developments

MODAF v. 1.1 (6 Viewpoints, 38 Views) MODAF version 1.1 made significant changes in definitions underlying the Views to better incorporate all DLOD and support the creation of enterprise architecture including the human element. All System Views were changed from the single focus on systems as technology only, to take on a wider meaning. The SVs now model ‘resources’ instead of systems only, thus widening the models to be able to include human resources. SV-1 now models human ‘roles’ alongside ‘systems’. ‘Resource interaction’ in SV-1 explicitly includes human-system and human-human interaction, besides system-system interaction. Functions have been defined wider so that they can include human functions. Many of the new examples in the documentation clearly state that system concerns need to be modelled alongside human concerns. This also has implications on how all other SVs are used. Likewise, for OV-4, TV-1, AcV-2, StV-3 and StV-5 the definitions have been widened, and the visualisations have been updated, to better account for human-related aspects. The OVs have been kept at the ‘logical’ level (i.e. abstract), to reflect requirements rather than solutions or individual resources. They purposefully do not capture statements about specific human resources or solutions. The Meta-Model has been updated and streamlined to be simpler and more accurate. The MODAF documentation is now easier to read, and has several chapters that explain the use of MODAF, for example how it supports the DLOD, and how to use if for trade-off analyses. The descriptions of the HVs have been updated to reflect the changes in MODAF and to relate the HVs to the new concepts.

Architecture characteristics Separation of component concerns Generic: Conceptual Data Model / Meta Model Instantiation: Logical and Physical Data Model View: window/snapshot onto model Architectural products Viewpoints Levels of abstraction Complexity Requirements-solutions MODAF, like other architectural frameworks, uses the following modelling structure: The complex concerns of the enterprise are broken down and separated into component notions. These notions, and their dependencies, are described at the highest level in the MODAF Meta Model. “The MODAF Meta Model (M3) is the information model for MODAF, defining the structure of the underlying architectural information that is presented in the Views.” (www.modaf.org.uk). DoDAF version 1.5 calls this the Conceptual Data Model. They define (abstract) notions that can be understood as design artefacts (e.g. Capability, Node). Whilst the Meta-model is a generic model of any Enterprise, each of the components needs to be instantiated with specific models for a particular Enterprise. This may include ‘as-is’ and ‘to-be’ models. The underlying architectural data are stored in computer-based tools or repositories. It is important that data repositories and modelling tools are using common modelling standards, so they can be shared collaboratively, or reused. DoDAF describes this through Logical and Physical Data Model levels. Views are used to query the Data Model and provide visual representations of architecture components and their dependencies. Views are specific perspectives on the Enterprise structure, or “windows onto an underlying model”, and “snapshots of underlying architectural data”. Thus, “the same information may be represented in more than one View” (www.modaf.org.uk). Views are grouped into Viewpoints. Each View can be instantiated by ‘products’, which are particular versions of the actual representations developed for each View. The representations usually evolve, as more detail becomes available, throughout acquisition programmes. Models are developed at several layers of abstraction to capture requirements-solution relationships in a top-down approach. The higher levels of abstraction are developed early in the system (enterprise) lifecycle, but remain as the guiding principles throughout.

MODAF SV-1 (v 1.1) MODAF now allows and encourages modelling of human roles in the SV-1. Likewise, it models Resource Interactions that can include HCI and human-human interaction.

Organisational Resource MODAF Meta-Model: New Capability Deployment Capability Configuration Physical Asset Organisational Resource configured with Standard subject to doctrine hosted on System owns deployed to Node realised by Operational Activity Function has supports Role is assigned operates conducts The concept of Capability Configuration was defined as part of the MODAF Meta-Model to provide a generic concept for resource implementation that includes humans structures.

New MODAF v1.1 M3 definitions ResourceInteraction (SV-1) An assertion that two <<FunctionalResource>>s interact. Examples: data exchange between systems, conversations between people, people using systems Function (SV-4) An activity which is specified in context of the resource (human or machine) that performs it. Note1: Contrast with <<OperationalActivity>>, where the actor performing the activity is not known (i.e. it is just a logical node). A <<Function>> is implementation-specific. Role (SV-1, OV-4) An aspect of a person or organization that enables them to fulfil a particular function. PostType (OV-4) A type of point of contact or responsible person. Note that this is the type of post - e.g. Desk Officer, Commander Land Component, etc. Several modified Meta-model definitions now clearly include human concepts, and clarify their position as part of the Enterprise model.

SOA focus in DoDAF v 1.5 Operational Activity to Services Traceability Matrix (SV-5c) DoDAF version 1.5 has widened its concepts to include Service Oriented Architectures (SOA) – where the focus can be either on Systems (i.e. technology), or Services. Services can include people structures and processes. In a newly created SV-5c, Operational Activities (as requirements) can be mapped to Services for implementing solutions (not just systems). This implicitly includes people aspects, without actually specifying any details for them. DoDAF has also newly defined the concept of the ‘unexpected user’ – thus widening the definitions of potential stakeholders. DoDAF has not explicitly included human definitions in the way MODAF has done.

MODAF Human Views

UK work: progress / plan Scoping Study HV concepts to IA Draft HV Handbook Input towards MODAF v1.1 Stakeholder Review Revised HV Handbook Published HV Handbook (Issue 1) Applications and Updates end Dec 06 8 Feb 07 12 March 07 30 March 07 end July 07 mid Sept 07 Jan 08 ongoing A set of Human Views (HVs) for MODAF has been developed as part of work conducted under the Human Factors Integration Defence Technology Centre (HFI DTC), a consortium between Industry and Academia funded by the UK MoD. The HVs are proposed as complementary to the existing MODAF Views. HVs clarify the HFI design elements of socio-technical systems. Analysis and original conception of the HVs is based on studying MODAF version 1.0 through the Technical Handbook and the Deskbooks. The HV concepts evolved in parallel to the upgrade of MODAF to version 1.1 by the UK Integration Authority (IA). This work was able to make some important contributions. An initial set of HV concepts were captured in a Draft Human View Handbook, to collect stakeholder feedback. A revised set of concepts has been produced, and will shortly be published as the First Issue of the HV Handbook. It will undergo further iterations.

HVs between OV and SV level This Figure shows the HVs in relation to a subset of the existing MODAF Views, and in relation to the abstraction layers of MODAF. The most abstract definitions are made as part of the Strategic Views (StVs) at the top of an imaginary cone, whilst the System Views (SVs) produce the most concrete models at the base of the cone. The gray lines trace topical areas that can be found in MODAF and need to be extended to human concepts. They include resource availability (captured through HV-A), relationships & boundaries (HV-C, HV-D, HV-F), functions & activities (HV-E), behaviour & dynamics (HV-G), and values & metrics (HV-B).

This Figure shows the relationships between the data elements underlying the HVs – as an HV meta-model. This is a high-level overview version showing how major elements relate and as part of which HV.

HV-A: Personnel Availability (example) Long-term availability of suitable personnel for recruiting is an important factor for which types of roles, posts, and organisational structures can be defined, and for which types of technologies. This can be captured quantitatively comparing demand and supply. It is also essential to capture qualitative cause-effect relationships. For example, HV-A needs to capture causes and effects of personnel fluctuations, to determine the needs for establishing personnel processes. For this example case, a relationship has been mapped between the current practice to minimise training cost, and the potential lack of trained personnel available to work in this post. This may not be a problem, if other factors, such as potentially high injury rates due to health and safety problems, were not present as well.

HV-A: Personnel Availability HV-A captures: Trend and Development Forecasts; Personnel Characteristics (e.g. current/future; available/required); Personnel Numbers (e.g. current/future; available/required); Formal Personnel Development Structure and Processes.

HV-B: Quality Objectives and Metrics (example) High-level value definitions need to be related to concrete quantified targets. The value categories are specified at different levels of abstraction. This is taking some inspiration from the Abstraction Hierarchy as part of Work Domain Analysis (WDA). WDA specifies Value Priorities only at the second highest level of abstraction, as the basis for functional definitions at the lower levels. The same high-level values can however be broken down also into non-functional values in the same way. Generic value objectives (e.g. Safety), as capability attributes, can be specified further through quality objectives (sometimes referred to as the ‘ilities’). Most human factors measures need to be linked to expected observable behaviour or performance, based on human tasks/functions to be achieved. Then, measurable metrics can be specified to support these. Explicit targets can be specified for each metric through a one-to-one mapping. Otherwise, relationships can be many-to-many (for example, low workload measures may demonstrate both effectiveness and safety). At the same time, measures need to be combined (e.g. workload cannot be taken as the only proof for either). This example illustrates one application of this for how HF standards can be included and expanded through different levels of abstractions for values and metrics.

HV-B: Quality Objectives and Metrics This a repository for qualitative HFI acceptance criteria and performance objectives. It requires several levels of abstraction and detail. HV-C data elements include: HFI Value definitions (level 1 to n) HFI Value definition relationships (between different levels) Human Performance Criteria and Metrics (i.e. what is to be measured) Target Measures (i.e. which quantifiable amount is acceptable) Methods of Compliance

HV-C: Human Interaction Structure (examples) Human relationships need to be captured, and the interactions with the work domain. Generalised Views of information exchanges are needed that clarify role dependency constraints set up elsewhere. Virtual and Physical locations need to be defined for assessment. Both OV-2 and SV-1 implicitly capture human activity and interaction requirements through the functionality of the nodes. However, OV-2 primarily captures a network of communication technology. SV-1 captures its instantiation and actual use. HV-C captures the human network by focusing on what happens at the human elements of the nodes, how human functions may be distributed, and for which human purposes the technology-based communication network enables operations. Thus, it captures essential non-functional requirements underpinning the design of technology. It may also be used as the basis for designing human roles and organisational structures. Two levels of representations arise from this requirement. HV-C captures: Purpose-related boundary definitions underlying information flows; Team/organisational structures supported by technologies, including constraints due to locations and physical network.

HV-C: Human Interaction Structure Human relationships need to be captured, and the interactions with the work domain. Generalised Views of information exchanges are needed that clarify role dependency constraints set up elsewhere. Virtual and Physical locations need to be defined for assessment. HV-C data elements include: Purposes of information manipulation (e.g. access, transmission, sharing) Locations Human Roles Systems

HV-D: Organisation (examples) HV-D distinguishes between two types of fixed organisational dependencies: Part-whole structures – expressing subdivisions of larger units into smaller units to the level of individual posts (often reflecting functional divisions); Individuals’ post/job relationships including: Authority structures (e.g. location of command/supervisory power); Rank structures (status, pay, grade, scope of responsibilities); note that they cannot always be equated with command structures.

HV-D: Organisation HV-D may be seen as an extension to the existing OV-4 and SV-1. It captures additional properties of human organisations that need to be formally defined as part of the organisational set-up. HV-D defines the following structures: Static organisational structure definitions; Task-organised structures; Organisational Processes, Procedures, Values and Policies. HV-D data elements include: Organisational units (e.g. posts/roles; department) Organisational relationships Part-whole Rank/authority structures Formal task-organised configurations Formal process and value definitions

HV-E: Human Functions and Tasks (example) Defining functions as ‘owned’ by either human or system defines them as being either a technical development need, or a human structure development need. A function for a system/technology translates into a requirement to build something enabling that function. A function for a human translates into requirements for how human activities need to be organised, where/how they interface with systems, and how human resources need to be made available. A human function also has implications for further specifying the functionality of system components, in terms of how they will be used. Standard UML diagrams may be used – without yet specifying roles or specific system elements. Note: ‘system’ is used here for hardware/technology (in line with MODAF terminology)

HV-E: Human Functions and Tasks HV-E supports resource definition process when moving from abstract OV-5 requirements to concrete SV-4 definitions. MODAF incorporates several levels of Allocation of Function (AoF) definitions. The first of them is the definition of activities as either human or system-specific, and defining the functions and tasks required for resources to be fulfilled. HV-E data elements include: Human Functions/Tasks Human Task Decomposition System Functions Human-System Interface Requirements

HV-F: Roles and Competencies (examples) To be able to determine role requirements, they have to be mapped to human task requirements. Roles, Tasks, and Competencies comprise definitions that mutually depend on each other. For example: Tasks may determine required skills and knowledge; Existing role/post definitions may influence task descriptions; New roles may be defined based on competency groupings; Roles may require competencies for communicating and collaborating. Standard UML notations can be used for these mappings, or matrixes. Note: The ‘A’ in KSA (Knowledge, Skills & Attributes) is sometimes also referred to as Aptitudes, or Abilities.

HV-F: Roles and Competencies HV-F maps human functions/tasks to definitions of roles and competencies. It provides a dedicated repository to capture requirements for defining boundaries of human structures at a detailed level, which can be related to definitions of systems and their components. HV-F data elements include: Human Functions/Tasks Roles Competencies Function-Role-Competency Dependencies Where organisational boundaries are drawn that separate a task to be conducted between human individuals, additional team and communication activities are being defined. Role definitions are a fairly abstract concept that, at some point, needs to be related to more concrete post/job/position definitions (types and actual instantiations) that are to be fulfilled by people. A human role is unique to humans, involving the ability and the requirement to hold responsibility. Roles are often components of post/job definitions.

HV-G: Dynamic Drivers of Human Behaviour (example) Handley et al (2006) suggest the need for visualising role re-assignments during changes in organisational tasking configurations (see Figure 46). Flexible organisational units are defined as ‘cells’, based on groupings of human functions that were derived through an OV-5 decomposition. Handley, HAH, Sorber, TJ, Dunaway, JD (2006) Maritime headquarters with Maritime Operations Center, Concept Based Assessment Focus Area: Organization, Human Systems Performance Assessment Capability Final Report, (September 2006). Pacific Science & Engineering Group, San Diego, CA.

HV-G: Dynamic Drivers of Human Behaviour Design starts and ends with observing behaviour. Capturing aspects of behaviours may have either of two main functions: Inform design aspects by capturing the ‘essence of’ actual behaviour – i.e. capturing aspects of ‘as-is’ behaviour; Conduct behaviour assessments to evaluate design decisions, by modelling essential aspects of ‘to-be’ behaviour. Thus, there is a difference between actual behaviour, as can be observed, and behaviour expectations, as a prediction or a target definition. Underlying both is a set of constraints on what people do, how they do it, and how resources need to be designed and organised. These driving factors are the main focus of HV-G. HV-G does not capture actual behaviour (since this can be very complex and requires a set of tools), but the dynamic factors underlying behaviour (e.g. time constraints, logical order of activities, task rules in response to task conditions). By capturing such constraints on operations, expectation for essential aspects of behaviour can be expressed. These can also be understood as non-functional constraints on functional definitions. HV-G data elements include: Conditions Representative Scenarios – i.e. a combination of conditions (e.g. critical, frequent, typical situations) Time Units States (e.g. snapshots, stable configurations) and Configuration/State Changes, e.g. Task-based changes of organisational configurations; Flexible use of resources (e.g. role switches, adaptive automation); Dynamic behaviour properties/characteristics; Performance measures (as indicators of expected behaviour).  

Summary The need to model an entire Enterprise as a socio-technical system is well recognised. Enterprise Architectures are being conceived to specify requirements and solutions for all DLOD. MODAF version 1.1 has significantly modified many of its underlying definitions. The HVs further expand on this development. The complementary HVs for MODAF aim to bring together SE and HFI as two related disciplines. Whilst SE and HFI depend on each other, each is grounded in a set of approaches and philosophies not immediately compatible. By choosing a SE approach to express HFI design decision areas, HFI professionals are provided with means to communicate to Systems Engineers. HV elements have the potential of changing traditional SE approaches that can be overly technology focused.