Conceptual, Technical and Business Pilots · Mykola Galushka SAP [email protected] Michael Nolan Intel [email protected] TIMBUS WP8 - Industrial Project 2: Civil Engineering

Copyright TIMBUS Consortium 2011 - 2014

Conceptual, Technical and Business Pilots

WP 8 – Industrial Project 2: Civil Engineering Infrastructures

Delivery Date: 31/12/2014

Dissemination Level: Public

TIMBUS is supported by the European Union under the 7th Framework Programme

for research and technological development and demonstration activities (FP7/2007-2013) under grant agreement no. 269940

TIMBUS WP8 - Industrial Project 2: Civil Engineering Infrastructures

Deliverable D8.5 - Conceptual, Technical and Business Pilots

D8.5_M45_Conceptual_Technical_Business_Pilots.docx Dissemination Level: Public Page 2


Deliverable Lead

Name Organisation e-mail

Sven Euteneuer SQS AG [email protected]

Contributors


Torsten Möllenbeck SQS AG [email protected]

Achim Parzentny SQS AG [email protected]

Daniel Draws SQS AG [email protected]

José Barateiro LNEC [email protected]

Joao Cardoso INESC-ID [email protected]

Goncalo Antunes INESC-ID [email protected]

Barbara Kolany-Raiser ITM [email protected]

Internal Reviewer


Mykola Galushka SAP [email protected]

Michael Nolan Intel [email protected]





Disclaimer

The information in this document is provided "as is", and no guarantee or warranty is given that the

information is fit for any particular purpose. The above referenced consortium members shall have no

liability for damages of any kind including without limitation direct, special, indirect, or consequential

damages that may result from the use of these materials subject to any liability which is mandatory due to

applicable law. Copyright 2014 by SQS AG, LNEC, INESC-ID, ITM.





Table of Contents

1 EXECUTIVE SUMMARY ............................................................................................................................. 9

2 INTRODUCTION ......................................................................................................................................... 10

2.1 OBJECTIVE ........................................................................................................................................... 10

2.2 SCOPE ................................................................................................................................................... 10

2.3 CONTEXT .............................................................................................................................................. 10

3 ASSESSMENT MODEL ............................................................................................................................... 11

3.1 APPLICABLE STANDARDS ..................................................................................................................... 11

3.2 ASSESSMENT METHODOLOGY .............................................................................................................. 12

3.2.1 Process Reference Model ...................................................................................................... 12

3.2.2 Considered Capability Levels................................................................................................ 12

3.3 MODEL OVERVIEW ............................................................................................................................... 13

3.3.1 Processes ............................................................................................................................... 14

3.3.2 Process Dimension ................................................................................................................ 15

3.3.3 Capability Dimension ............................................................................................................ 15

3.3.4 Assessment Indicators ........................................................................................................... 16

3.4 PROCESS PERFORMANCE INDICATORS .................................................................................................. 17

3.4.1 Process Group Risk Management ......................................................................................... 17

3.4.2 Process Group Planning ....................................................................................................... 18

3.4.3 Process Group Preserve ........................................................................................................ 23

3.4.4 Process Group Redeploy ....................................................................................................... 24

3.4.5 Process Group Monitoring .................................................................................................... 26

3.5 PROCESS CAPABILITY INDICATORS ...................................................................................................... 28

3.5.1 Level 1: Performed process ................................................................................................... 28

3.5.2 Level 2: Managed process ..................................................................................................... 28

4 ASSESSMENT CONTEXT .......................................................................................................................... 30

4.1 ORGANISATION .................................................................................................................................... 30

4.2 BUSINESS CASE .................................................................................................................................... 31

4.3 PRESERVATION CASE ........................................................................................................................... 32

5 ASSESSMENT RESULTS ............................................................................................................................ 34

5.1 EXECUTION .......................................................................................................................................... 34

5.2 RESULTS OVERVIEW ............................................................................................................................ 34

5.3 RESULT DETAILS .................................................................................................................................. 35

5.3.1 PLAN.1 .................................................................................................................................. 35





5.3.2 PLAN.2 .................................................................................................................................. 36

5.3.3 PLAN.2.1 ............................................................................................................................... 37

5.3.4 PLAN.2.2 ............................................................................................................................... 38

5.3.5 PLAN.2.3 ............................................................................................................................... 39

5.3.6 PRES.1 .................................................................................................................................. 39

5.3.7 DEPL.1 .................................................................................................................................. 41

5.3.8 RISK.1 ................................................................................................................................... 42

5.3.9 MON.1 ................................................................................................................................... 43

5.3.10 MON.2 ................................................................................................................................... 43

6 CONCLUSION .............................................................................................................................................. 45

6.1 PROCESS APPLICATION ......................................................................................................................... 45

6.2 PROCESS APPLICABILITY ...................................................................................................................... 45

7 RECOMMENDATIONS .............................................................................................................................. 46

A WORK PRODUCT CHARACTERISTICS ................................................................................................ 47

A.1 GENERIC WORK PRODUCTS .................................................................................................................. 48





List of Figures

Figure 1: TIMBUS DP High-level Process Overview ......................................................................................... 13

Figure 2: Processes and enterprise architecture overview ............................................................................. 31





List of Tables

Table 1: Process assessment standards .......................................................................................................... 11

Table 2: ISO/IEC 15504 capability levels .......................................................................................................... 13

Table 3: Overview of assessment results for LNEC ......................................................................................... 35

Table 4: Detailed results for PLAN.1 ................................................................................................................ 36

Table 5: Detailed results for PLAN.2 ................................................................................................................ 37

Table 6: Detailed results for PLAN.2.1 ............................................................................................................. 37



Table 9: Detailed results for PRES.1 ................................................................................................................ 39

Table 10: Detailed results for DEPL.1 .............................................................................................................. 41

Table 11: Detailed results for RISK.1 ............................................................................................................... 42

Table 12: Detailed results for MON.1 .............................................................................................................. 43

Table 13: Detailed results for MON.2 .............................................................................................................. 44





List of Acronyms

BP Business process (used: BP-1, BP-2, etc.)

BP Base Practice (used: BP.1, BP.2, etc.)

CAD Computer Aided Design

CAM Computer Aided Manufacturing

CMMI Capability Maturity Model Integration

DP

ERM

Digital preservation

Enterprise Risk Management

GP Generic Practice

GR Generic Resources

GWP Generic Work Product

ISO International Standardization Organisation

IT Information Technology

LNEC Laboratório Nacional de Engenharia Civil

PAM Process Assessment Model

PRM Process Reference Model

SPICE Software Process Improvement and Capability Determination

WP Work Package





1 Executive Summary

This deliverable presents the output of Task Conceptual Technical Business Pilots of work package Industrial

Project 2: Civil Engineering Infrastructures. The work described in this deliverable deals with an assessment

of the application of the TIMBUS Process on the LNEC use case defined in deliverables D8.1 [2], D8.4 [4] and

D8.7 [6]. In this use case the LNEC organisation is seeking to digitally preserve three core business

processes by means of the TIMBUS process, methods and tools.

In order to understand the degree to which the use case has been able to successfully utilize the above

mentioned contributions by the TIMBUS project, a process assessment methodology has been defined. The

maturity of TIMBUS process implementation at LNEC can be measured by this process assessment

methodology. This information can be used to understand how well the TIMBUS process and its associated

assets support the digital preservation of LNEC’s business processes. This insight shall help in understanding

the applicability of TIMBUS process and developed tools to real-world preservation needs.

The SPICE ISO standard [3] on process assessment was altered to match this difference in focus. Instead of

assessing how well the use case followed the defined TIMBUS process, the assessment documented in this

deliverable is focused on figuring out whether the TIMBUS process [1] and the developed tools are suitable

for the intended cause.

The assessment results document that the TIMBUS process and its methods were applied systematically

and consistently by LNEC. The business processes in question were preserved and redeployed successfully

according to the requirements defined by LNEC. Additionally, it could be witnessed that the applied

process, methods and tools by and large worked well in supporting the preservation activities.

Three subprocesses in the planning and monitoring domains, however, could not be implemented in the

context of this use case. The root cause of this is connected to how specific subprocesses and outcomes of

these subprocesses are supported by some of the TIMBUS tools. Further analysis and research is necessary

to define next steps, i.e. to adapt the process or to extend and modify the tools in use to better facilitate

the implementation of the process.

Additionally, some smaller improvement potentials were identified in the remaining processes, offering

input for further development of the process and its underlying methods and tools. These small-scale

improvement suggestions can be found documented throughout Section 5.

In summary the results indicate that the TIMBUS process, its methods and tools support the

implementation of digital preservation of business processes in a real-world scenario. Aspects such as the

subprocesses not implemented or the improvement potentials related to tool support and context

modelling indicate areas for additional research and development of the TIMBUS assets.





2 Introduction

2.1 Objective

The purpose of this deliverable is to document all information related to the performance of an assessment

on the preservation case at Laboratório Nacional de Engenharia Civil (LNEC). It describes the Assessment

Model (the assessment approach) in Section 3. Section 4 describes the assessment context. This contains

an overview of the LNEC organisation and the business case which was preserved. The results of the

assessment are documented in section 5. Defined goal of the assessment was to evaluate the suitability of

the TIMBUS process and supporting tools for the digital preservation of the LNEC use case. Conclusions and

recommendations derived from the assessment are documented in the Sections 6 and 7.

2.2 Scope

To evaluate the process defined in the course of the TIMBUS project, it was applied to several use cases

and the application was afterwards assessed. The main goal of the assessment was to evaluate the

suitability of the TIMBUS process and supporting tools for the intended purpose.

2.3 Context

This deliverable describes assessment on a preservation case. It includes the assessment model and the

actual assessment results.





3 Assessment Model

This section describes the model that is being used to conduct the assessment of the use case. This

assessment shall establish to which extent the use case has adopted the TIMBUS approach towards digital

preservation of business processes and their underlying IT support systems.

In order to facilitate capturing these aspects, the assessment needs to consider the application of the

TIMBUS digital preservation processes. The assessment will therefore audit the adoption of the TIMBUS

processes in order to preserve the use case’s business processes, i.e. the TIMBUS process forms the process

reference model (PRM) against which the implemented preservation processes are assessed.

3.1 Applicable Standards

Today there exist a wide range of standardised methodologies to assess the implementation of processes in

an organisation. Of this wide range, a majority of standards uses a two-pronged approach: They define both

a set of reference processes that are required to be implemented as well as a maturity measure to rate the

degree of implementation. This degree of implementation is rated against predefined steps or level, usually

ranging from a very immature implementation to a highly mature implementation.

The following table illustrates a number of standards which cover this approach of process assessments:

Table 1: Process assessment standards

Provides

Standard Reference

Process

Reference

Model

Maturity

Model

Capability Maturity Model Integration (CMMI) [Industry

standard, related to ISO/IEC 20000]

X X 1 X

Information technology — Process Assessment [ISO/IEC 15504] (X) 2 X (X) 3

Software Lifecycle Processes [ISO/IEC 12207] X

Information Technology Infrastructure Library (ITIL) [Industry

standard, related to ISO/IEC 20000]

X (X)4

1 CMMI compliance is established to the maturity model by way of appraisal. Alternatively the organisation can also be

appraised against a separate capability model. 2 ISO 15504 used to contain a process reference model of its own but this has been removed from the standard in

2004. 3 ISO 15504 does not provide a maturity model but provides a capability dimension as part of its reference model.

4 No certification for ITIL compliance exists, but compliance to ISO 20000 can be assessed and certified.





Table 1 clearly illustrates the breadth of the available process quality assessment standards but at the same

time shows that for the purpose of the assessment of TIMBUS use cases, an assessment approach based on

ISO/IEC 15504 is the most suitable. Not only does ISO/IEC 15504 not require a predefined reference

process, it is also an international standard that is widely applied across the industry and it provides a

capability model sufficient for the purposes of the use case assessment as well as a description on how to

run an assessment. That way, ISO/IES 15504 can be adapted to assess against a range of reference

processes and is not limited to development-centric processes. While CMMI is geared towards assessing

the maturity of a whole organisation with all its business processes ISO/IES 15504 is focused on assessing

the capability in implementing specific processes. Therefore, ISO/IES 15504 is more easily adapted to the

needs of assessing the adoption of the TIMBUS process in the industrial use cases.

3.2 Assessment Methodology

This section delineates the assessment methodology, i.e. which reference processes the use case will be

assessed against and which approaches will be used to evaluate and rate the result of this assessment.

The assessment makes use of a process quality auditing methodology, as defined in ISO 15504. This entails

that the assessment of the use case is conducted based on the application of the TIMBUS process in the

context of this use case.

In order to perform this assessment, the use case processes are evaluated against a given Process

Reference Model (PRM). This evaluation will identify areas of compliance and compliance gaps with regard

to the use case process landscape, which – in turn – will be used to determine a capability level for the use

case with regard to its application of TIMBUS processes.

In particular, process evaluation methodology and capability levels for this assessment are based on the

respective parts of the methodology and capability levels defined in ISO 15504.

3.2.1 Process Reference Model

For the purpose of this assessment the TIMBUS process model as defined in “D4.6: Use Case Specific DP &

Holistic Escrow” [1] shall serve as the PRM. It clearly defines the involved processes of digital preservation

(DP).

For each of these DP processes the PRM provides the following components:

• Process Name

• Process Purpose

• Process Outcomes

All processes defined in the PRM will be in scope for this assessment.

3.2.2 Considered Capability Levels

ISO/IEC 15504 defines six capability levels (cf. 2). For the assessment of TIMBUS process application in the

LNEC use case not all six capability levels defined by ISO 15504 are deemed applicable.





Table 2: ISO/IEC 15504 capability levels

Level Description

5 Optimizing process

4 Predictable process

3 Established process

2 Managed process

1 Performed process

0 Incomplete process

Only levels 0-2 are considered, due to the following rationale:

• The digital preservation process is a newly developed process;

• This assessment assesses its first time execution;

• Main goal is to determine whether or not the desired outcome could be achieved using the newly

developed digital preservation process.

Considering these constraints, it is deemed impossible for this use case to reach a level higher than

“Managed Process”, whilst reaching even this level is highly unlikely, as it would require not only

successfully implementing all subprocesses but also to establish a process management capability for these

subprocesses in parallel.

Figure 1: TIMBUS DP High-level Process Overview

3.3 Model Overview

This section defines and discusses the Process Assessment Model (PAM) for the TIMBUS process framework

for digital preservation developed by the EU founded TIMBUS Project.

The purpose of this PAM is to enable an assessment that determines whether the TIMBUS Process for

Digital Preservation as defined in the PRM is suitable to achieve its goal to capture the context of a business





process, digitally preserve it in full and redeploy it to a new environment later on. The PAM is intended to

be used to assess three example implementations of the TIMBUS.

3.3.1 Processes

In order to ease the handling of the various (sub-) processes, inputs, outputs and relationships in the digital

preservation process developed by TIMBUS we break down the whole process as follows for the purpose of

this assessment:

The main processes (as shown in Figure 1) will be represented as accordingly named Process

Groups containing their processes as defined in the PRM.

Individual process steps (and/or sub processes) will be represented as Base Practices. In ISO/IEC

15504 a base practice is defined as “an activity that, when consistently performed, contributes to

achieving a specific process purpose” [3].

The concluding structure is laid out in the following paragraphs.

3.3.1.1 Process Group Risk Management

Process Identification Process Name Source

RISK.1 Risk Management [1] 3.4.2.1

3.3.1.2 Process Group Planning


PLAN.1 Acquisition of business process

context

[1] 3.4.2.2

PLAN.2 Assessment of Preservation

Approaches

[1] 3.4.2.3

3.3.1.3 Process Group Preserve


PRES.1 Preserve [1] 3.4.3

3.3.1.4 Process Group Redeploy


DEPL.1 Redeployment [1] 3.4.4





3.3.1.5 Process Monitoring


MON.1 Monitoring of business process

context in source environment

[1] 3.4.5.1

MON.2 Monitoring of preserved business

process

[1] 3.4.5.2

3.3.2 Process Dimension

The Process Dimension of this PAM is defined in Section 4.

3.3.3 Capability Dimension

As stated in section 3.3 this assessment considers only the capability level zero to two. The meaning of

these levels is described by ISO 15504 as follows:

Level 0: Incomplete process

The process is not implemented, or fails to achieve its process purpose. At this level, there is little

or no evidence of any systematic achievement of the process purpose.

Level 1: Performed process

The implemented process achieves its process purpose.

Level 2: Managed process

The previously described Performed process is now implemented in a managed fashion (planned,

monitored and adjusted) and its work products are appropriately established, controlled and

maintained.

3.3.3.1 Capability Measurement

Within the PAM, the measure of capability is based upon three of the nine process attributes defined in

ISO/IEC 15504-2, since only three attributes are applicable to capability levels 0-2. Process attributes are

used to determine whether a process has reached a given capability. Each attribute measures a particular

aspect of the process capability.

The list of process attributes is shown in the following table:

Process Attribute ID Capability Levels and Process

Attributes

Level 0: Incomplete process

Level 1: Performed process

PA 1.1 Process performance

Level 2: Managed process

PA 2.1 Performance management





PA 2.2 Work product management

The process attributes are evaluated on a four point ordinal scale of achievement, as defined in ISO/IEC

15504-2. They provide insight into the specific aspects of process capability required to support process

improvement and capability determination.

In order to achieve Capability Level 1 the TIMBUS process needs to be implemented at least largely or fully.

A partial or no implementation of the TIMBUS process would lead to achieving only Capability Level 0. The

level of achievement for the overall process is determined by calculating the average achievement scores of

all its subprocesses.

3.3.4 Assessment Indicators

With regard to the meaning and usage of assessment indicators this process assessment model is directly

based upon the explanations in ISO 15504[3]. For this reason the following sections are giving only a short

overview regarding the respective topics. For a more detailed explanation of the concepts described here

please confer ISO 15504 [3].

The PAM is based on the idea to break down the whole process into capability indicators. These indicators

should be defined in a manner not only enabling to decide whether or not a process fulfilled its purpose,

but also to which extent and quality. They can therefor help to derive constructive conclusions on how to

improve the process and its implementation.

There are two types of assessment indicators: process capability indicators and process performance

indicators.

While the process performance indicators deal with the basic execution of the process and therefore

address mainly whether and to which extent it was performed successfully, the process capability

indicators address the maturity of the process implementation.

The process capability indicators are:

Generic Practice (GP);

Generic Resource (GR);

Generic Work Product (GWP).

Process capability indicators are taken into account for capability level 2 and higher.

The process performance indicators are:

Base Practice (BP);

Work Product (WP).





Process performance indicators are used to decide whether a process reaches at least capability level 1.

“The process performance and process capability indicators defined in the Process Assessment Model

represent types of objective evidence that might be found in an instantiation of a process and therefore

could be used to judge achievement of capability.” [3]

3.4 Process Performance Indicators

This clause defines the processes and the process performance indicators, also known as the process

dimension, of the Process Assessment Model. The processes in the process dimension can be directly

mapped to the processes defined in the PRM.

The processes are classified (for the purpose of this PAM) into Process Categories and Process Groups

which are listed in section 3.3.1.

The individual processes are described in terms of Process Name, Process Purpose, and Process Outcomes.

In addition the process dimension of the PAM provides information about the Base Practices, including a

definition of tasks and activities needed to accomplish the processes purpose. Each Base Practice is

explicitly associated to a process outcome.

Where applicable sub processes are described in an equal manner and marked as sub process.

The Work Products table describes work products flowing into and out of Base Practices as part of process

execution. This table lists work products flowing into a Base Practice in the “Inputs” column and lists work

products flowing out of Outcomes in the “Outputs” column. Impacted Base Practices and Outcomes are

listed for each work product.

NB: Any given work product may serve as the input to multiple Base Practices and may be the output of

several Process Outcomes. In order not to unnecessarily increase the size and the complexity of the Work

Products table, in these cases, work products are listed only once as input or output and all impacted Base

Practices or Process Outcomes are listed in one line. If a WP is modified by a Base Practice (e.g. enhanced

by additional information) it is placed in a single line as input and output.

3.4.1 Process Group Risk Management

3.4.1.1 RISK.1 Risk Management

Process ID RISK.1

Process Name Risk Management

Process Purpose The purpose of the Risk Management process is to identify, analyse, evaluate and

treat the risks associated with a business process, which can lead to a decision to

use digital preservation as a mitigation action. This process also decides on which

preservation strategy shall be executed.

Process Outcomes O.1 Context Model of the business process is established





O.2 Risks for the business process are identified

O.3 Risks for the business process are analysed regarding likelihood and impact

O.4 Mitigation strategies are evaluated

O.5 Risks are treated according to chosen mitigation strategy

Base Practices BP.1 Establish Context [O.1]

BP.2 Identify Risks [O.2]

BP.3 Analyse Risk [O.3]

BP.4 Evaluate Risk [O.4]

BP.5 Treat Risk [O.5]

Work Products

Inputs Outputs

WP.05 Business Process Specification [BP.1]

WP.06 Source Environment [BP.1]

WP.02 Context model instance (CMI) [O.1]

WP.02 Context model instance (CMI) [BP.2]

WP.33 List of identified risks [O.2]

WP.33 List of identified risks [BP.3]

WP.34 Report about likelihood and impact of

identified risks [O.3]

WP.34 Report about likelihood and impact of

identified risks [BP.4]

WP.01 Risk Assessment Report [O.4]

WP.03 Process Preservation Plan (PPP) [O.4]

WP.03 Process Preservation Plan (PPP) [BP.5]

WP.18 Preserved business process [O.5]

3.4.2 Process Group Planning

3.4.2.1 PLAN.1 Acquisition of business process context

Process ID PLAN.1

Process Name Acquisition of business process context

Process Purpose The purpose of the Acquisition of business process context process is to establish

an initial Process Context Model that enables the Risk Management to develop

digital preservation approaches if necessary.

Process Outcomes O.1 Decision if business process is well specified and sufficient documented

O.2 Specification of business process, sufficient for preservation purposes





O.3 Requirements of the stakeholders (concern) are known

O.4 Domain specific information of the context is gathered

O.5 Context model instance (CMI) is developed

O.6 CMI with views is developed

Base Practices BP.1 Check whether business process is sufficiently specified [O.1]

BP.2 Refine business process specification [O.2]

BP.3 Identify Stakeholders [O.3]

BP.4 Acquisition of domain specific context [O.4]

BP.5 Context Model & Dependencies Modelling [O.5]

BP.6 Create Views [O.6]

Work Products

Inputs Outputs

WP.05 Business Process Specification [BP.1, BP.2,

BP.3, BP.4]

WP.05 Business Process Specification [O.1, O.2]

WP.06 Source Environment [BP.2, BP.4]

WP.07 Requirements of the stakeholders (concern)

[O.3]

WP.08 Domain specific information of the context

[O.4]

WP.09 Domain specific models [BP.5]


WP.02 Context model instance (CMI) [BP.6] WP.10 CMI with views [O.6]

3.4.2.2 PLAN.2 Assessment of Preservation Approaches

Process ID PLAN.2

Process Name Assessment of Preservation Approaches

Process Purpose The purpose of the Assessment of Preservation Approaches process is to specify

requirements for the preservation process followed by identification and

evaluation of preservation approaches in order to choose the one best fitting the

requirements. As a last step a preservation Action Plan is built, based on the

chosen approach.

Process Outcomes O.1 Context model instance (CMI) is refined and extended to reflect the needs

of this process

O.2 Preservation requirements are identified and documented

O.3 Process context is abstracted where applicable

O.4 Possible preservation approaches are identified, evaluated and





documented in preservation plans

O.5 Process Preservation Action Plans (PPP) are built and delivered to risk

management as decision paper.

Base Practices BP.1 Acquisition business process context for Digital Preservation

(subprocess) [O.1]

BP.2 Document preservation requirements [O.2]

BP.3 Abstraction of process context (subprocess) [O.3]

BP.4 Develop Preservation Plan (subprocess) [O.4]

BP.5 Build Preservation Action Plan [O.5]

Work Products

Inputs Outputs

WP.01 Risk Assessment Report [BP.1]

WP.02 Context model instance (CMI) [BP.1, BP.2,

BP.3, BP.4]

WP.02 Context model instance (CMI) [O.1, O.3]


WP.11 Preservation Requirements [O.2]

WP.11 Preservation Requirements [BP.3, BP.4]

WP.12 Evaluated preservation plan [O.4]

WP.12 Evaluated preservation plan [BP.5]

WP.13 Evaluated Process Preservation Action Plan

(PPP) [O.5]

3.4.2.2.1 PLAN.2.1 Acquisition of business process context for digital preservation (subprocess)

Process ID PLAN.2.1

Process Name Acquisition of business process context for digital preservation

Process Purpose The purpose of the Acquisition of business process context for digital preservation

process is to finalize the Context Model, enabling development of plan and

execution of the digital preservation.

Process Outcomes O.1 Requirements of the stakeholders (concern) are known

O.2 Domain specific models of the context are gathered

O.3 Context model instance (CMI) is finalized

O.4 CMI with views reflecting the needs of the stakeholders is developed

Base Practices BP.1 Identify Stakeholders [O.1]

BP.2 Acquisition context and dependencies

BP.3 Context Model & Dependencies Modelling [O.3]

BP.4 Create Views [O.4]





Work Products

Inputs Outputs

WP.02 Context model instance (CMI) [BP.1, BP.2

BP.4] (version from previous process)


(updated / finalized version)



[O.1]


[O.2]

WP.09 Domain specific models [O.2]


[BP.3]


[BP.4]

WP.10 CMI with views [O.4]

3.4.2.2.2 PLAN.2.2 Abstraction of business process context (subprocess)

Process ID PLAN.2.2

Process Name Abstraction of business process context

Process Purpose The purpose of the Abstraction of business process context process is to remove

unnecessary implementation details from the CMI while preserving all necessary

information for preservation and re-deployment.

Process Outcomes O.1 Abstraction possibilities are identified

O.2 Possible abstractions are implemented

O.3 Abstraction implementation is verified

O.4 Decision about successful abstraction that fulfils all requirements is made

Base Practices BP.1 Analyse context model instance [O.1]

BP.2 Perform abstraction [O.2]

BP.3 Verify abstraction [O.3]

BP.4 Decision [O.4]

Work Products

Inputs Outputs



BP.3]

(For BP.3: both original version and version with

WP.02 Context model instance (CMI) (with

abstracted concepts) [O.2]





abstracted concepts)

WP.35 Suggestions for Abstractions [BP.2]

WP.36 Results of verify abstraction [BP.4]

WP.35 Suggestions for Abstractions [O.1]

WP.36 Results of verify abstraction [O.3]

WP.37 Decision [O.4]

3.4.2.2.3 PLAN.2.3 Develop Preservation Plan (sub process)

Process ID PLAN.2.3

Process Name Develop Preservation Plan

Process Purpose The purpose of the Develop Preservation Plan process is to develop a valid

preservation plan.

Process Outcomes O.1 Components for preservation are selected

O.2 Preservation approaches are defined, including procedure to acquire data,

strategies to maintain significant properties over times etc.

O.3 The defined preservation plan is evaluated against the preservation

requirements

O.4 Results of the evaluation of the different approaches are compared and

the collected data from the evaluation step is prepared for decision

making

O.5 Decision whether Plan is fulfilling preservation requirements or a

refinement is needed is made based on the results of O.4

Base Practices BP.1 Select components [O.1]

BP.2 Define Preservation plan [O.2]

BP.3 Evaluate plan [O.3]

BP.4 Analyze results [O.4]

BP.5 Decision: Plan fulfils the requirements? [O.5]

Work Products

Inputs Outputs



BP.3]

(from BP.2 on including the changes from O.1)

WP.02 Context model instance (CMI) (with

selected components) [O.1]

WP.01 Risk Assessment Report [BP.2]

WP.38 Preservation Knowledge Base [BP.2]

WP.03 Process Preservation Plan (PPP) [BP.3]






WP.39 Results of evaluation of the preservation

approaches against the preservation requirements

[BP.4]

WP.12 Evaluated preservation plan [BP.5]

WP.03 Process Preservation Plan (PPP) [O.2]

WP.39 Results of evaluation of the preservation

approaches against the preservation requirements

[O.3]

WP.12 Evaluated preservation plan [O.4]

WP.37 Decision [O.5]

3.4.3 Process Group Preserve

3.4.3.1 PRES.1 Preserve

Process ID PRES.1

Process Name Preserve

Process Purpose The purpose of the Preserve process is to execute the actual preservation of the

business process, including operational planning and quality assurance.

Process Outcomes O.1 Preservation is planned from an operational perspective

O.2 The data regarding the business process is gathered

O.3 The verification data regarding the business process is gathered

O.4 Preservation action defined in the Preservation Action Plan (PPP) are

performed

O.5 Quality Assurance measures are performed on the preserved process

O.6 Decision if preservation was successful is made

O.7 Preserved Process is stored in archive

O.8 Monitoring events for re-evaluation of the preserved business process are

defined

Base Practices BP.1 Operational planning of preservation execution [O.1]

BP.2 Acquisition of process data [O.2]

BP.3 Acquisition of validation and verification data [O.3]

BP.4 Perform preservation action [O.4]

BP.5 Perform quality assurance [O.5, O.6]

BP.6 Archival storage [O.7]

BP.7 Define monitor events [O.8]





Work Products

Inputs Outputs

WP.13 Evaluated Process Preservation Action Plan

(PPP) [BP.1, BP.2, BP.3, BP.4, BP.7]

WP.14 Selected preservation strategy [BP.1]

WP.15 Execution plan for preservation of the

business process [O.1]

WP.06 Source Environment [BP.2, BP.3]

WP.16 Captured data [O.2]

WP.17 Validation and Verification data for the

preserved business process [O.3]

WP.16 Captured data [BP.4]

WP.18 Preserved business process [O.4]

WP.19 Results of QA [O.5, O.6]

WP.18 Preserved business process [BP.5, BP.6]

WP.20 AIP (Archival information packages) [O.7]


WP.21 Monitor Events [O.8]

3.4.4 Process Group Redeploy

3.4.4.1 DEPL.1 Redeployment

Process ID DEPL.1

Process Name Redeployment

Process Purpose The purpose of the Redeployment process is to deploy an archived business

process into a new environment. This includes preparing the target environment

as well as verifying the redeployment against the previously collected verification

data.

Process Outcomes O.1 Description of the preserved Process is retrieved from archive

O.2 A model of the redeployment environment is developed

O.3 Gaps between the needed redeployment environment and the actual are

identified

O.4 Alternatives to close identified gaps are evaluated

O.5 Data associated with the preserved process is extracted from the archive

O.6 Preserved Process is deployed into the target environment

O.7 Preserved process is re-executed to test the redeployment

O.8 Results of the re-execution are verified against verification data stored





with the process

O.9 Decision to proceed or repeat assessment of re-deployment alternatives is

made

Base Practices BP.1 Retrieve business process from archive [O.1]

BP.2 Capture redeployment environment [O.2]

BP.3 Gap analysis [O.3]

BP.4 Assessment of redeployment alternatives [O.4]

BP.5 Retrieve data from archive [O.5]

BP.6 Setup environment [O.6]

BP.7 Perform re-execution [O.7]

BP.8 Verify results [O.8, O.9]

Work Products

Inputs Outputs

WP.22 Archive[BP.1]

WP.23 Business process description [O.1]

WP.24 (empty) Redeployment environment [BP.2] WP.24 Redeployment environment [O.6] (with

preserved process deployed but not executed)

WP.25 CMI of the redeployment environment [O.2]

WP.23 Business process description [BP.3]

WP.25 CMI of the redeployment environment

[BP.3]

WP.26 Gap report [O.3]

WP.26 Gap report [BP.4]

WP.27 Redeployment plan [O.4]

WP.27 Redeployment plan [BP.5, BP.6, BP.7]

WP.28 Retrieved business process data [O.5]

WP.29 Instantiated environment [BP.7]

WP.30 Redeployed business process [O.7]

WP.31 Monitoring measurements [O.7]

WP.31 Monitoring measurements [BP.8]

WP.32 Validation result [O.8, O.9]





3.4.5 Process Group Monitoring

3.4.5.1 MON.1 Monitoring of business process context in source environment

Process ID MON.1

Process Name Monitoring of business process context in source environment

Process Purpose The purpose of the Monitoring of business process context in source environment

process is to recognize changes in a preserved process' context.

Process Outcomes O.1 Business process description is retrieved from archive

O.2 Current business process context is gathered

O.3 Gaps between archived and current context are identified

O.4 Process Assessment of preservation approaches is triggered in case of

Gaps


BP.2 Acquisition business process context [O.2]

BP.3 Gap analysis [O.3, O.4]

Work Products

Inputs Outputs

WP.22 Archive [BP.1]WP.05




WP.23 Business process description [BP.3]


WP.26 Gap report [O.3]

3.4.5.2 MON.2 Monitoring of preserved business process

Process ID MON.2

Process Name Monitoring of preserved business process

Process Purpose The purpose of the Monitoring of business process is to actively monitor

dependencies and requirements of a preserved process in order to ensure the

capability to redeploy it.

Process Outcomes O.1 Business process description is retrieved from archive

O.2 Current redeployment environment is captured

O.3 Gaps between archived and current context are identified

O.4 Process Assessment of preservation approaches is triggered in case of

Gaps

O.5 Redeployment is planned





O.6 Data associated with the preserved process is extracted from the archive

O.7 Preserved Process is deployed into the target environment

O.8 Preserved process is re-executed and monitored in test the redeployment

O.9 Results of the re-execution are verified against verification data stored

with the process

O.10 Decision to proceed or repeat assessment of re-deployment alternatives is

made


BP.2 Capture redeployment environment [O.2]

BP.3 Gap analysis [O.3, O.4]

BP.4 Plan redeployment [O.5]

BP.5 Retrieve required data from archive [O.6]

BP.6 Setup test environment [O.7]

BP.7 Perform test re-execution [O.8]

BP.8 Verify results [O.9, O.10]

Work Products

Inputs Outputs

WP.22 Archive [BP.1]


WP.24 Redeployment environment [BP.2]

WP.25 CMI of the redeployment environment [O.2]

WP.23 Business process description [BP.3, BP.6]

WP.25 CMI of the redeployment environment

[BP.3]

WP.26 Gap report [O.3, O.4]

WP.26 Gap report [BP.4]

WP.27 Redeployment plan [O.5]

WP.27 Redeployment plan [BP.5, BP.6]

WP.28 Retrieved business process data [O.6]

WP.28 Retrieved business process data [BP.6]

WP.29 Instantiated environment [O.7]

WP.29 Instantiated environment [BP.7]

WP.30 Redeployed business process [O.8]

WP.31 Monitoring measurements [O.8]

WP.31 Monitoring measurements (of original and

retrieved business process) [BP.8]

WP.32 Validation result [O.9, O.10]





3.5 Process Capability Indicators

This section presents the process capability indicators related to the process attributes associated with the

capability levels 1 and 2. A detailed explanation of the attributes as well as their generic practices, generic

resources and generic work products can be found in ISO 15504 [3].

Indicators for Level 0 are not described because Level 0 reflects a non-implemented process or a process

which fails to achieve its outcomes and therefore does not include any indicators.

3.5.1 Level 1: Performed process

The following attributes of the process demonstrate achievement of Level 1 as defined in [3]:

PA 1.1 Process Performance Attribute

This attribute reflects whether or not the assessed process achieves its defined outcomes.

Generic Practices for PA 1.1

Reflects whether Base Practices were performed as intended and associated Work Products

were produced as evidence of the process outcomes.

Generic Resources for PA 1.1

Resources are used to perform the intent of process specific base practices.

Generic Work Products for PA 1.1

Work products exist that provide evidence of the achievement of the process outcomes.

3.5.2 Level 2: Managed process

“The previously described Performed process is now implemented in a managed fashion (planned,

monitored and adjusted) and its work products are appropriately established, controlled and maintained.”

[3]

The following attributes of the process demonstrate the achievement of this level:

PA 2.1 Performance management attribute

“The performance management attribute is a measure of the extent to which the performance of

the process is managed.” [3]


GP 2.1.1 Identify the objectives for the performance of the process.

GP 2.1.2 Plan and monitor the performance of the process to fulfil the identified

objectives.

GP 2.1.3 Adjust the performance of the process.

GP 2.1.4 Define responsibilities and authorities for performing the process.

GP 2.1.5 Identify and make available resources to perform the process according to plan.

GP 2.1.6 Manage the interfaces between involved parties.


Human resources with identified objectives, responsibilities and authorities;

Facilities and infrastructure resources;





Project planning, management and control tools, including time and cost reporting;


08-00 Plan

13-00 Record

14-00 Register

15-00 Report

PA 2.2 Work product management attribute

“The work product management attribute is a measure of the extent to which the work products

produced by the process are appropriately managed.”[3]


GP 2.2.1 Define the requirements for the work products.

GP 2.2.2 Define the requirements for documentation and control of the work products.

GP 2.2.3 Identify, document and control the work products.

GP 2.2.4 Review and adjust work products to meet the defined requirements.


Requirement management method / toolset;

Configuration management system;

Documentation elaboration and support tool;

Document identification and control procedure;

Work product review methods and experiences;

Review management method / toolset;

Intranets, extranets and/or other communication mechanisms;

Problem and issue management mechanisms.


08-00 Plan

13-00 Record

14-00 Register

16-00 Repository

18-00 Standard

20-00 Template

21-00 Work product





4 Assessment Context

This section will specify the assessment context. In section 4.1 the organisation where the assessment will

take place is described. A description of the business case is provided in section 4.2 and the major

requirements for the preservation are shown in section 4.3.

4.1 Organisation

LNEC is an organisation that acts as a technical consultant to the Portuguese Government. Among other

responsibilities, it controls the safety of large civil engineering structures, especially large dams.

Deliverables D8.1 [2], D8.4 [4] and D8.7 [6] discuss in great detail LNEC, their business processes and the

need for digital preservation (DP) so that we will only give a brief overview over the relevant facts. LNEC

has identified three core business processes for which risks can only be mitigated by the implementation of

digital preservation.

The first relevant business process is concerned with the acquisition and processing of sensor data. Sensor

data may stem from a variety of sources, most of them related to the physical properties of civil

engineering structures such as dams or bridges. These sensors record physical properties such as the

movement along a specific axis as a datum or a set of data. This raw data usually requires some form of

processing and storage to make it accessible to further analysis. These activities form part of the sensor

data business process. For this business process the main objectives behind applying DP is to enhance trust

in the correct execution of the business process, in the re-execution to correct for calibration or

computation errors that are identified at a later point in time and for business continuity reasons; dams will

outlive IT-system architectures by decades or centuries.

The second process covers the simulation of structures and their behaviour. These computing-intensive

models and simulations are developed in-house at LNEC and are executed on LNEC’s parallel-computing

cluster infrastructure. Here the main objective to be achieved with digital preservation is to be capable of

preserving the technical environment to solve specific simulations or equations.

The third process is concerned with the preservation of CAD/CAM (Computer Aided Design/Computer

Aided Manufacturing) drawings. These drawings may either be created manually for which a process of

creation, approval and maintenance exists or they may be used to visualize data – in this case the drawings

are computer-generated. In this context, LNEC develops work in the monitoring of the structural behaviour

of concrete dams, not only new dams under construction but all the others under operation, observing

their aging and the possible need of intervention, based on data provided by a set of sensors installed in

the structures. Analysing the structural stability and safety of a concrete dam involves the monitoring of a

set of phenomena, each with their scales, such as temperatures (scalars), displacements (vectors), stresses

(tensors), etc. It is important to perform a careful analysis of these measures and a cautious manipulation

of data, when applied to the CAD design for a correct graphical representation of the phenomena under

consideration.





Therefore, there are a number of scenarios in which the development and use of technical CAD designs are

essential for the analysis of structural safety of a concrete dam, and for the potential constructive solution

to implement in a structural intervention and repair.

4.2 Business Case

Figure 2 shows an overview of the considered CAD business processes (in yellow) and the underlying

software stack that supports them. These processes have to be preserved. In detail there are four business

processes chosen to perform the preservation process. BP-1 Traditional CAD Usage supports the scenario of

Technical CAD designs – Traditional usage; BP-2 Automatic CAD generation supports the scenario of

Technical CAD designs using specific business processes and data obtained from the information system;

BP-3 Automatic CAD generation using a template supports the scenario of Technical CAD designs using

specific business processes, data obtained from information system and CAD template designs; and BP-4

Dam’s Structural Simulation supports the scenario of Technical CAD designs of finite element meshes for

structural calculation. A detailed description of those business cases can be found in D8.4 chapter 7.

Figure 2: Processes and enterprise architecture overview

In this context, the main component of the technology layer (in Figure 2, technology layer is in green) is the

GestBarragens database, which stores all the important data to be used in BP-2 and BP-3 (namely,

automatic CAD generation with and without template). The important data collected from the dam’s

sensors is provided to both processes, while, exclusively for generation with template, the GestBarragens





DB also stores and provides the needed CAD templates (with graphical representations of the dam, where

the desired sensor information can be printed) as well as the drawing coordinates necessary to print

information in such templates. The necessary information to draw a dam’s FEM (Finite Element Mesh) is

stored in various ASCII files, which are read in the process.

In the application layer (in Figure 2, application layer is in blue) there are many software components which

comprise the algorithms of the processes. The “gbDiagr” function is offered as part of the GestBarragens

front-end interface, and consists of a FORTRAN application which gathers the necessary sensor data and

stores it in a CAD file as requested by the user. Similarly, there is another application (written in VB.NET)

which gathers not only the sensor data, but also the dam’s CAD template and drawing coordinates, and

creates a new CAD file, based on the specified dam’s template, with all the requested sensor information.

For a Dam’s Structural Simulation process there are three main software components. First, the FEM

generation application (of which there are many variations coded in Visual Basic, FORTRAN and MatLab,

and also full-bred applications like GiD and ParaView), which takes the ASCII file with the dam’s mesh

information and draws the mesh in a new CAD file. Next, this CAD file is used by structural calculation

software which will perform the analysis and resolution of all the physical equations, defined by a

configured set of actions that could or already affect the dam’s structure, presenting a new CAD with the

results. Lastly, this CAD and its results can be visualized in data visualisation software like GiD or ParaView.

Finally, for the traditional usage of CAD files, there are the software applications that allow CAD creation

and manipulations, with one of the most prevalent being Autodesk’s AutoCAD.

4.3 Preservation Case

For the preservation Case there are four scenarios which have to be fulfilled:

Trust – re-execute the process with same data and parameters to ensure that the process produces

the same results as in previous executions. This scenario requires the redeployment and re-

execution of the process with all its original entities.

Correction – re-execute the process with the same data, but with changed parameters to correct

any anomaly (wrong data selection). The redeployment and re-execution of the process with its

original entities, where data and/or context is partially modified.

Reanalysis – re-execute the process with new or updated data. This is the case when using the

same CAD analysis with extended information.

Continuity – civil engineering structures like dams are expected to operate for a long-time (several

decades). The CAD processes must be preserved and secured in the future, ensuring that the

processes can be continuously executed.

All four described business processes are involved in these scenarios the mapping between them is shown

in deliverable D8.4 Table 3.





To perform these scenarios there have to be reached a couple of goals. These goals have some relations or

dependencies between them. The relations are shown in Figure 2 (This figure is taken out of the document

D8.4 chapter 8.5)

Each goal has several sub goals. To achieve the overall goal all the sub goals have to be achieved. The figure

shows that goal two requires goal one. What is not shown is that goal three also is in a close relationship

with the other two goals. Goal three is the result of an ongoing process. This process is needed to make

goal one (and two) reachable. It is necessary to keep the amount of tools and data types as small as

possible to be able to perform the TIMBUS process. The TIMBUS process is used to achieve goal one and

two. In D8.4 goal three is defined as one goal of the preservation but in fact is a way to make the

preservation easier or possible.

Figure 1: Goals for the preservation case





5 Assessment Results

5.1 Execution

This assessment was conducted as a two-day on-site assessment at LNEC premises in Lisbon, Portugal in

October 2014 and as a subsequent evaluation and documentation of assessment results from the acquired

raw data.

As part of the assessment methodology, a two-person team of assessors interviewed the roles responsible

for the execution of the TIMBUS processes. The interviews consisted of a set of goal oriented questions and

demonstrations of evidence of process execution.

5.2 Results Overview

This section gives an overview about the high level results of the assessment of the application of the

TIMBUS process to the LNEC use case. A tabular overview is shown in Table 3.

The process attribute ratings reflect the extent to which the goals of a process attribute were achieved. The

following ratings are being used:

N/A = Not applicable

o The rated of a process attribute is not applicable for the assessed use case and

therefore remains unrated.

N = No

o The goals of the rated of a process attribute were not achieved at all or the process

attribute was not executed.

P = Partially

o Less than 50% of the goals of a process attribute were achieved.

L = Largely

o More than 50% but not all goals of a process attribute were achieved.

F = Fully

o All goals of a process attribute were achieved.

As the Process Performance Attribute (1.1) clearly shows, none of the process steps achieved its goals in

full. However, seven out of ten evaluated processes achieved a rating of “largely implemented”. As no

process was performed fully, the Performance management attribute (2.1) and the Work product

management attribute (2.2) could not be evaluated, resulting in an N rating.

In an overall view the TIMBUS process was applied to LNEC in fairly complete manner. All relevant

processes save for the monitoring process were largely implemented, some to an almost full degree. The





overall maturity of process application can therefore be considered to be on level 1. This offers a solid basis

on which to derive learnings on the applicability of the TIMBUS process to the needs of the LNEC use case.

Table 3: Overview of assessment results for LNEC

Process Attribute

Process ID Process Name 1.1 2.1 2.2 Maturity Level

PLAN.1 Acquisition of business process context L N N 1

PLAN.2 Assessment of Preservation

Approaches

L N N 1

PLAN.2.1 Acquisition of business process context

for digital preservation (sub process)

L N N 1

PLAN.2.2 Abstraction of business process context

(sub process)

L N N 1

PLAN.2.3 Develop Preservation Plan (sub

process)

N N N 0

PRES.1 Preserve L N N 1

DEPL.1 Redeployment L N N 1

RISK.1 Risk Management L N N 1

MON.1 Monitoring of business process context

in source environment

N N N 0

MON.2 Monitoring of preserved business

process

N N N 0

The following sections provide the details on the ratings of the individual processes as well as rationale and

references to evidence.

5.3 Result Details

5.3.1 PLAN.1

For the purpose of the TIMBUS process, the planning phase of the process is subdivided into to processes –

PLAN.1 and PLAN.2.

Table 4 illustrates the detailed results for the PLAN.1 process. The outcomes and base practices defined in

the TIMBUS process have been found to have been fully implemented except for the gathering if domain

specific context information and for the developing of the context model instance, both of which have been

implemented largely.





Specifically, in order to tackle the gathering and development of LNEC’s context model, the domain

independent ontology (DIO) and domain specific ontologies (DSOs) were modeled using the TIMBUS tools

and generated by the TIMBUS extractors. Exact copies of production machines were used as data sources

for the extractors.

In order to use the individual ontologies as part of a joint context model, a tool has been developed to

integrate the ontologies as part of the work on the use case. The resulting model was manually validated

against the real world implementation for three specific components of the CAD/CAM business process to

ensure validity of intermediate results.

Table 4: Detailed results for PLAN.1

1 Performed N P L F

1.1 Process performance attribute x

Outcomes N P L F

O.1 Decision if business process is well specified and sufficient documented

x

O.2 Specification of business process, sufficient for preservation purposes

x

O.3 Requirements of the stakeholders (concern) are known x

O.4 Domain specific information of the context is gathered x

O.5 Context model instance (CMI) is developed x

O.6 CMI with views is developed x

Base Practices

BP.1 Check whether business process is sufficiently specified x

BP.2 Refine business process specification x

BP.3 Identify Stakeholders x

BP.4 Acquisition of domain specific context x

BP.5 Context Model & Dependencies Modelling x

BP.6 Create Views x

Presented evidence showed the creation of the DIOs, the conversion of DIOs using TIMBUS tools, the use of

extractors to create DSOs and the integration into a joint ontology.

The use case interviewees did not recall any issues with applying this part of the TIMBUS process. However,

they noted that at the outset business processes were not formalized and documented but were rather

implicit and, thus, required effort to make explicit and available to the methods of TIMBUS.

5.3.2 PLAN.2

For the PLAN.2 process evaluation results are more heterogeneous. While overall the process is performed

largely, outcomes O.4 and O.5 are not currently performed and outcomes O.1 and O.3 are performed

largely (cf. Table 5).





Table 5: Detailed results for PLAN.2

1 Performed N P L F

1.1 Process performance attribute X

Outcomes N P L F N/A

O.1 Context model instance (CMI) is refined and extended to reflect the needs of this process

x

O.2 Preservation requirements are identified and documented x

O.3 Process context is abstracted where applicable x

O.4 Possible preservation approaches are identified, evaluated and documented in preservation plans

x

O.5 Process Preservation Action Plans (PPP) are built and delivered to risk manage-ment as decision paper.

x

Base Practices

BP.1 Acquisition business process context for Digital Preservation (subprocess) x

BP.2 Document preservation requirements x

BP.3 Abstraction of process context (subprocess) x

BP.4 Develop Preservation Plan (subprocess)

x

BP.5 Build Preservation Action Plan

x

This process is subdivided further into subprocesses PLAN.2.1, PLAN.2.2 and PLAN.2.3 which are discussed

in the following sections. Multiple activities within this process and its subprocesses are tool-supported by

the DPES tool.

With this process, several potentials for improvement were identified as part of its application to LNEC.

Firstly, the mapping of activities to roles is not yet ideal; it needs to be executed by the preservation expert,

while the requirements need to come from stakeholders.

Secondly, the whole preservation plan as foreseen in PLAN.2.3 is not directly visible to involved roles at it is

encapsulated in the DPES tool, meaning that intermediate outcomes are not explicitly available as foreseen

in the process.

5.3.3 PLAN.2.1

PLAN2.1 concerns the refining, extending and finalizing of a context model instance for the relevant

business processes. For this subprocess an overall rating of largely is derived from the detailed ratings of

the outcomes and base practices (cf. Table 6).

Table 6: Detailed results for PLAN.2.1

1 Performed N P L F



O.1 Requirements of the stakeholders (concern) are known x

O.2 Domain specific models of the context are gathered x

O.3 Context model instance (CMI) is finalized x

O.4 CMI with views reflecting the needs of the stakeholders is developed x





Base Practices

BP.1 Identify Stakeholders x

BP.2 Acquisition context and dependencies x

BP.3 Context Model & Dependencies Modelling x

BP.4 Create Views x

All outcomes and base practices of this subprocess have been implemented fully except for the gathering of

domain specific models, which has been implemented largely. This is due to the fact that while software

dependencies were acquired using the TIMBUS extractor tools, hardware dependencies were restricted to

the features of the virtual machines that were used to host copies of the live systems.

Preservation requirements are defined and documented. The requirements posed by the LNEC organisation

towards the preservation were brief and concise, focusing on the requirement for business processes to

work as before after preservation and redeployment. No requirements were posed towards the frequency

or details of the redeployment.

5.3.4 PLAN.2.2

PLAN.2.2 covers the abstraction of the context for the purposes of the preservation. This process has been

rated as “largely implemented” (cf. Table 7).


1 Performed N P L F



O.1 Abstraction possibilities are identified x

O.2 Possible abstractions are implemented x

O.3 Abstraction implementation is verified x

O.4 Decision about successful abstraction that fulfills all requirements is made x

Base Practices

BP.1 Analyze context model instance x

BP.2 Perform abstraction x

BP.3 Verify abstraction x

BP.4 Decision x

The abstraction of the context model is performed, albeit only manually, using the full ontology as a

starting point and ending up with an abstracted view that is used for the purposes of the risk management.

The same DIO was used for all three business processes covered as part of this use case.

Outcome O.4 is implemented only partially due to the fact that the feedback loop to risk management was

not executed as specified in the process. In theory decisions should be made based on a report by the risk

management tool but this was not used in the context of the use case.





5.3.5 PLAN.2.3

PLAN2.3 is concerned with the definition of the preservation plan, its evaluation against requirements and

the selection of the most appropriate preservation approach. It has been rated as “not implemented” (cf.

Table 8).


1 Performed N P L F



O.1 Components for preservation are selected x

O.2 Preservation approaches are defined, including procedure to acquire data, strate-gies to maintain significant properties over times etc.

x

O.3 The defined preservation plan is evaluated against the preservation requirements x

O.4 Results of the evaluation of the different approaches are compared and the collect-ed data from the evaluation step is prepared for decision making

x

O.5 Decision whether Plan is fulfilling preservation requirements or a refinement is needed is made based on the results of O.4

x

Base Practices

BP.1 Select components

x

BP.2 Define Preservation plan

x

BP.3 Evaluate plan

x

BP.4 Analyze results

x

BP.5 Decision: Plan fulfils the requirements?

x

At LNEC this process is implemented by using the DPES tool. This results in the main base practices being

fully automated and not accessible to the involved roles (resulting in an N/A rating) and the defined

outcomes not being available as all information is kept in DPES and no intermediary outcomes were

available for this use case. This results in these parts of the process execution being invisible and impossible

to control to the involved process users.

Subsequently, the fitness for purpose of this process cannot be evaluated due to lack of experience in

applying it as part of this use case.

5.3.6 PRES.1

This process is concerned with the actual preservation of business processes, IT systems, software and data

according to the preservation plan defined in PLAN.2.3. For this process the overall rating is “largely

implemented” (cf. Table 9).

Table 9: Detailed results for PRES.1

1 Performed N P L F



O.1 Preservation is planned from an operational perspective x

O.2 The data regarding the business process is gathered x

O.3 The verification data regarding the business process is gathered x

O.4 Preservation action defined in the Preservation Action Plan (PAP) are performed

x





O.5 Quality Assurance measures are performed on the preserved process x

O.6 Decision if preservation was successful is made x

O.7 Preserved Process is stored in archive x

O.8 Monitoring events for reevaluation of the preserved business process are defined x

Base Practices

BP.1 Operational planning of preservation execution

x

BP.2 Acquisition of process data x

BP.3 Acquisition of validation and verification data x

BP.4 Perform preservation action x

BP.5 Perform quality assurance x

BP.6 Archival storage x

BP.7 Define monitor events x

The operational planning of preservation was undertaken aided by the DPES tool, as was the gathering of

business process data. For acquiring the verification and validation data, the VPlan methodology developed

as part of TIMUBS was applied, defining nine significant properties. The associated metrics of the nine

significant properties were evaluated manually. The quality assurance on the preserved process as

prescribed by BP.5 and O.5 were, thus, performed manually and only for specific process steps as “quality

probes”.

Outcome O.4 is rated as “not performed” as the PAP is not accessible to the involved roles. Preservation

actions are available through the DPES tools, but there is no way to access the underlying PAP.

A basic redeployment plan is defined on a high-level. The redeployment environment is created manually.

Monitoring events as required in O.8 and BP.7 are not defined resulting in a rating of “not performed” for

this base practice and outcome. Any changes to the business process or to the context are available

through the DPES and risk management tools but are not currently tied into a set of monitoring events. The

interviewees noted a specific type of dependency which many require stronger consideration: The

dependency on knowledge of specific process executors which is only implicit and has never been

documented. This knowledge is not accessible to DP methods unless it is identified and made explicit first.

Evidence on the implementation of this process is captured in deliverables D4.7 and D6.6. A demonstration

of the use of DPES to preserve LNEC business processes was not undertaken as part of this assessment.

With this process potentials for improvement were identified in the areas of process and tool integration

and monitoring: Firstly, the DPES tool currently does not make all outcomes available that are specified in

the TIMBUS process, posing a challenge to correctly implementing the process in full. Additionally, the

monitoring should be revisited to ensure that the required tool support and integration with the process is

available to successfully implement it.





5.3.7 DEPL.1

This process is concerned with the redeployment of preserved business processes, IT systems, software and

data from the preservation archive. For this process the overall rating is “largely implemented” (cf. Table

10).

Table 10: Detailed results for DEPL.1

1 Performed N P L F



O.1 Description of the preserved Process is retrieved from archive x

O.2 A model of the redeployment environment is developed

x

O.3 Gaps between the needed redeployment environment and the actual are identi-fied

x

O.4 Alternatives to close identified gaps are evaluated x

O.5 Data associated with the preserved process is extracted from the archive x

O.6 Preserved Process is deployed into the target environment x

O.7 Preserved process is re-executed to test the redeployment x

O.8 Results of the re-execution are verified against verification data stored with the process

x

O.9 Decision to proceed or repeat assessment of re-deployment alternatives is made x

Base Practices

BP.1 Retrieve business process from archive x

BP.2 Capture redeployment environment x

BP.3 Gap analysis x

BP.4 Assessment of redeployment alternatives x

BP.5 Retrieve data from archive x

BP.6 Setup environment x

BP.7 Perform re-execution x

BP.8 Verify results x

In the LNEC use case this process has been implemented and almost fully automated by the DPES tool. The

only truly manual intervention consists of the re-execution of the business process (O.7/BP.7) and the

verification of redeployed process by way of the VPlan methodology (O.8, BP.8).

Two outcomes and base practices (O.3, O.4; BP.3, BP.4) that are foreseen by the TIMBUS process to be

conducted as part of the execution of DEPL.1 were not conducted as part of the use case. Therefore, their

rating has been set as “not implemented”. Outcome O.2 is rated as “N/A” as this outcome is not made

available by the DPES tool and, thus, is not available to process users.

The redeployment into the target/redeployment environment is done using the DPES tool and works by

redeploying onto suitable virtual machines that are provisioned using a configurable server virtualization

management service such as proxmox.

Evidence on the implementation of this process is captured in deliverable D8.6 [5]. A demonstration of the

use of DPES to redeploy LNEC business processes was not undertaken as part of this assessment.

Based on this implementation in the use case, a number of improvement potentials have been identified.

Firstly, the abstracting of process execution details into the DPES tool reduces the visible complexity but





prevents the explicit execution of all underlying base practices by the process user. Secondly, the

redeployment focuses strongly on usage of virtual machines and does not yet provide additional options –

this is not related to the process but rather to its implementation in the DPES tool. Thirdly, the collection of

metadata did not cover the complete set of metadata relevant for the LNEC use case. In particular,

metadata about parallel execution in the LNEC parallel computing cluster could not be captured and used in

full.

5.3.8 RISK.1

This process is concerned with the overarching risk management activities spanning from very beginning of

preservation-related activities across the full lifecycle of preservation in an organisation. It also provides the

interfaces to corporate / enterprise risk management processes. For this process the overall rating is

“largely implemented” (cf. Table 11).

Table 11: Detailed results for RISK.1

1 Performed N P L F



O.1 Context Model of the business process is established x

O.2 Risks for the business process are identified x

O.3 Risks for the business process are analyzed regarding likelihood and impact x

O.4 Mitigation strategies are evaluated x

O.5 Risks are treated according to chosen mitigation strategy x

Base Practices

BP.1 Establish Context x

BP.2 Identify Risks x

BP.3 Analyze Risk x

BP.4 Evaluate Risk x

BP.5 Treat Risk x

The implementation of the risk management process in the LNEC use case is strongly aligned with the

TIMBUS risk management process as well as with the ISO 31000 standard on risk management. The same

process has been followed for all three business processes that have been the subject of preservation

activities at LNEC.

In order to establish the context, a fully verbal description of the context was identified and analyzed. On a

business process level this first context model was analyzed for known threats. Subsequently, this data was

populated into the TIMBUS risk management tool. This is a manual process with some tool support.

Identification and subcategorisation of risks was achieved by using brainstorming workshops and interviews

with key stakeholders to understand and identify all relevant risks. Here, a clear focus was laid on DP-

related risks, i.e. risks which could not be mitigated by digital preservation were not considered.





Due to this, the evaluation of mitigation strategies was only partially implemented as it resulted by default

in usage of digital preservation by nature of risk selection. Subsequently, the impact of using TIMBUS on

each risk was assessed and simple cost evaluations were put in place.

Evidence for the implementation of this process is found in LNEC’s instance of the TIMBUS risk

management tool.

For this process, a number of improvement potentials were identified. Firstly, the activities around

extracting context information is felt to still offer significant improvement potentials, both in the area of

tool/mining intelligence but also in the reduction of complexity and effort in order to improve the cost-

benefit-ratio of implementing these base practices.

5.3.9 MON.1

This process is concerned with the monitoring of business processes and their context (i.e. the source

environment) in order to identify changes that require preservation activities. For this process the overall

rating is “not implemented” (cf. Table 12).

Table 12: Detailed results for MON.1

1 Performed N P L F



O.1 Business process description is retrieved from archive x

O.2 Current business process context is gathered x

O.3 Gaps between archived and current context are identified x

O.4 Process Assessment of preservation approaches is triggered in case of Gaps x

Base Practices


BP.2 Acquisition business process context x

BP.3 Gap analysis x

No systematic monitoring of the source environment has been put in place for the LNEC use case, so that

none of the base practices and outcomes defined as part of the TIMBUS process can be witnessed. Ad-hoc

activities take place when gaps are identified.

Subsequently, no improvement potentials can be documented for the underlying outcomes and business

practices of MON.1. The process and its support by the TIMBUS tool chain should be reviewed to ensure

that it can be implemented with reasonable effort as part of an overall TIMBUS process implementation.

5.3.10 MON.2

This process is concerned with the monitoring of preserved processes in order to identify changes that

require preservation activities. For this process the overall rating is “not implemented” (cf. Table 13).





Table 13: Detailed results for MON.2

1 Performed N P L F



O.1 Business process description is retrieved from archive x

O.2 Current redeployment environment is captured x

O.3 Gaps between archived and current context are identified x

O.4 Process Assessment of preservation approaches is triggered in case of Gaps x

O.5 Redeployment is planned x

O.6 Data associated with the preserved process is extracted from the archive x

O.7 Preserved Process is deployed into the target environment x

O.8 Preserved process is re-executed and monitored in test the redeployment x

O.9 Results of the re-execution are verified against verification data stored with the process

x

O.10 Decision to proceed or repeat assessment of re-deployment alternatives is made x

Base Practices


BP.2 Capture redeployment environment x

BP.3 Gap analysis x

BP.4 Plan redeployment x

BP.5 Retrieve required data from archive x

BP.6 Setup test environment x

BP.7 Perform test re-execution x

BP.8 Verify results x

No systematic monitoring of the preserved process has been put in place for the LNEC use case, so that

none of the base practices and outcomes defined as part of the TIMBUS process can be witnessed. No tool

support is available to implement this.

Subsequently, no improvement potentials can be documented for the underlying outcomes and business

practices of MON.2. The process and its support by the TIMBUS tool chain should be reviewed to ensure

that it can be implemented with reasonable effort as part of an overall TIMBUS process implementation





6 Conclusion

This section reviews the process’ application at LNEC and derives learnings on the applicability of the

TIMBUS process from the process assessment. It is the desired end product of this work package to be able

to understand on which levels the TIMBUS process worked well and where there is room for improvement.

6.1 Process Application

This assessment shows clearly that the TIMBUS process was systematically and thoroughly adopted by the

LNEC organisation to solve their business need for preservation of core business processes. Only a few

areas of the TIMBUS process were not implemented or were implemented only to a small degree.

Subsequently, this use case is well-suited to draw conclusions concerning the use and application of the

TIMBUS process, its methods and the associated tools in real-world scenarios. It also demonstrates how the

application of the TIMBUS process forces organizations to make core business knowledge explicit – a value

in itself in order to reduce risk and dependencies on singular experts and in order to transform to a higher

degree of organisational maturity.

6.2 Process Applicability

By and large it can be stated that the TIMBUS process has been implemented to a large extent by the LNEC

use case and that it has worked well in its context. This indicates, that the TIMBUS process has indeed

helped solve the business need of LNEC for preservation of not only data and documents, but of business

processes, it systems, supporting applications and information.

For each individual process, improvement potentials and future work has been identified that can further

streamline the process, can make it easier, less complex or less costly to implement and offers additional

potential.

Three processes, however, could not be implemented to a satisfying degree, primarily due to lack of

experience in applying them within this use case. PLAN.2.3, MON.1 and MON.2 were implemented to such

a small degree that their implementation was rated as “not implemented”. For these processes, a thorough

review could be conducted to identify, understand and generalize the underlying issues and to understand

whether changes to these processes, the methodology or the tool support can ease or improve the

implementation of these processes in general. However, we can conclude from the work carried out in WP6

that there is no evidence to suggest that it would not be possible and beneficial to implement them.





7 Recommendations

The Assessment of the LNEC Use Case results in a couple of recommendable areas for future research.

There are three main areas on which future research seems recommendable:

the TIMBUS process itself

the methods and tools supporting the process

the need and legitimation for digital preservation in general.

For the area of tools it is recommended to increase automation and interoperability in order to address the

main issue of the TIMBUS process requiring too much effort to rectify its results. Especially improvement

regarding context model creation and integration would help to address some improvement potentials

mentioned in the assessment results.

The process itself should be improved in two ways:

1. In order to reduce the costs of Context Model creation a step to verify correctness, completeness

and suitability of the Context Model should be defined. This would improve the monitoring parts of

the process as well for which it is recommended to look into ways to reduce complexity and

necessary effort (e.g. by not having to create a Content Model on a regular basis).

2. In order to support and improve acceptance it is recommended to look into ways to legitimize

digital preservation not only by risk management but also to develop methods for cost and effort

estimation for the digital preservation process in general, the Context Model generation and for

preservation approaches. TIMBUS did not have this specific research focus. Projects such as 4C are

entirely focused on that topic. Rather, TIMBUS implemented the existing Life3 model in a modular

way which would allow other models to be substituted for it if desired in the future. The existence

of the 4C project is somewhat of an acknowledgement that no single, best known method for

calculation of preservation costs has been widely adopted but that is not the same as saying that

no models exist. The 4C project has the goal to evaluate and assess the various cost models and

investigate how to improve their adoption.





Annex

A Work product characteristics

“Work product characteristics listed in this Annex can be used when reviewing potential inputs and outputs

of process implementation. The characteristics are provided as guidance for the attributes to look for, in a

particular sample work product, to provide objective evidence supporting the assessment of a particular

process. A documented process and assessor judgment is needed to ensure that the process context

(application domain, business purpose, development methodology, size of the organisation, etc.) is

considered when using this information. Work products are defined using the schema described in Table

B.1. Work products and their characteristics should be considered as a starting point for considering

whether, given the context, they are contributing to the intended purpose of the process, not as a check-

list of what every organisation must have.

Work product identifier # An identifier number for the work product which is used to

reference the work product.

Work product name Provides an example of a typical name associated with the work

product characteristics. This name is provided as an identifier of the

type of work product the practice or process might produce.

Organisations may call these work products by different names. The

name of the work product in the organisation is not significant.

Similarly, organisations may have several equivalent work products

which contain the characteristics defined in one work product type.

The formats for the work products can vary. It is up to the assessor

and the organisational unit coordinator to map the actual work

products produced in their organisation to the examples given here.

Work product characteristics Provides examples of the potential characteristics associated with

the work product types. The assessor may look for these in the

samples provided by the organisational unit.

“(ISO/IEC 15504-5)





A.1 Generic Work products

WP ID WP Name WP Characteristics

WP.01 Risk Assessment Report (RAR) RAR is the result of the Risk Assessment Management process

(as described in Section 3.3.1.1). It evaluates the risks of a

specific business process setting according to their expected

likelihood and impact.

WP.02 Context model instance (CMI) CMI specified the context of a specific business process

including technical, organisational and legal aspects.

WP.03 Process Preservation Plan (PPP) The Process Preservation Plan (PPP) specifies actions to

digitally preserve a business process. It includes:

a specification of the significant properties of the process;

methods to acquire the relevant data from the source sys-

tem;

preservation actions for the components of the business

process;

validation and verification mechanisms including measure-

ment points and data;

archival storage format for the business process;

redeployment procedure;

evaluation of the plan against the preservation require-

ments;

monitoring events for review of the preservation plan.

WP.04 Validation and Verification Plan The V&V plan specifies the validation and verification

procedure for the preserved and redeployed business process.

The Goal of the V&V Plan is to provide measurements to check

whether the significant properties of the process were

preserved over time.

WP.05 Business Process Specification Specifies the business process to be preserved and contains for

example: Models;

Descriptions.

WP.06 Source Environment The environment in which the original process resides.

WP.07 Requirements of the

stakeholders (concern)

Requirements on digital preservation of the process imposed

by the stakeholders. (Mainly based on concerns related to risk

management)

WP.08 Domain specific information of

the context

The business domain specific information before they are

modelled.

WP.09 Domain specific models The business domain specific models of a process or context.





WP.10 CMI with views WP.02 Context model instance (CMI) with Views for different

Stakeholders. For more information about the context models

used here refer to D8.7 [6].

WP.11 Preservation Requirements List of Requirements for the digital preservation of a business

process. (in distinction to WP.07 not ordered by Stakeholder)

WP.12 Evaluated preservation plan A preservation plan that has been evaluated.

WP.13 Evaluated Process Preservation

Action Plan (PPP)

A PPP that has been evaluated.

WP.14 Selected preservation strategy Preservation strategy to be performed on the business

process. Strategy is selected by Risk Management.

WP.15 Execution plan for preservation

of the business process

Document that describes how the preservation is to be

performed from an operational perspective.

WP.16 Captured data Captured software, data and configuration from live system

(e.g. current snapshot of data bases).

WP.17 Validation and Verification data

for the preserved business

process

Captured data for validation and verification purposes during

execution of the preservation and to verify successful

redeployment.

WP.18 Preserved business process Contains: CMI

Data

Software, configurations

Documentation of performed preservation action

Etc.

WP.19 Results of QA Results of the quality assurance step. Includes decision if

preservation was successful.

WP.20 AIP (Archival information

packages)

Format in which the preserved process will be stored in the

archive.

WP.21 Monitor Events Defined Parameters for re-evaluation of preserved business

process.

WP.22 Archive Archive where preserved business processes are stored.

WP.23 Business process description Description of a preserved business process. (CMI)

WP.24 Redeployment environment Environment in which a dearchived process will be deployed.

WP.25 CMI of the redeployment

environment

Context Model Instance of the redeployment environment.

WP.26 Gap report Contains a list of gaps between needed and actual

redeployment environment.

WP.27 Redeployment plan Describes how to do the redeployment of an archived business

process.

WP.28 Retrieved business process data Data associated with the process including: Software;

Configuration;





working data (such as database tables with business data).

WP.29 Instantiated environment Redeployment environment which has been set-up with a

dearchived process.

WP.30 Redeployed business process Business process that has been deployed and executed in the

redeployment environment.

WP.31 Monitoring measurements Taken during re-execution after initial redeployment.

WP.32 Validation result Result of the comparison between the results of a redeployed

process and its verification data

WP.33 List of identified risks A list with identified risks for a specific business process.

WP.34 Report about likelihood and

impact of identified risks

A Report about likelihood and impact of identified risks.

WP.35 Suggestions for Abstractions List of process context contents that could be abstracted.

WP.36 Results of verify abstraction A Document or statement whether the abstracted business

process context still contains all necessary information for

preservation and redeployment.

WP.37 Decision A decision what to do next or whether a process step was

successfully performed or not.

WP.38 Preservation Knowledge Base Knowledge base containing and providing information related

to the past and ongoing preservation work.

WP.39 Results of evaluation of the

preservation approaches

against the preservation

requirements

Results of evaluation of the preservation approaches against

the preservation requirements.





References

1. Strodl, S. et al (2013) D4.6: Use Case Specific DP & Holistic Escrow, W4 – Processes and Methods for

Digitally Preserving Business Processes

2. Antunes, G. et al (2013) D8.1: Use Case Definition and Digital Preservation Requirements

3. ISO/IEC 15504 (2012) Information technology — Process assessment Parts 1-5

4. Vieira, R. et al (2012) D8.4: Digitally Preserving CAD/CAM Business Processes

5. Cardoso, J. et al (2013) D8.6: Refined Digitally Preserving CAD/CAM Business Processes

6. Cardoso, J. et al (2013) D8.7: Digitally Preserving Large Mathematical Simulations

Documents

Conceptual, Technical and Business Pilots · Mykola Galushka SAP [email protected] Michael Nolan Intel [email protected] TIMBUS WP8 - Industrial Project 2: Civil Engineering