4.2.1 Basic abstract workflow . . . 126 4.2.2 Basic abstract subworkflow for impact analysis . . 129 4.2.2.1 Analysis of essential artifacts . . . 129 4.2.2.2 Identification and analysis of additional
artifacts . . . 140 4.2.3 Basic abstract subworkflow for recovery analysis . 150 4.2.3.1 Analysis of essential artifacts . . . 150 4.2.3.2 Identification and analysis of additional
artifacts . . . 170 4.2.4 Basic abstract subworkflow for recovery tracking . 179 4.2.4.1 Analysis of essential artifacts . . . 179 4.2.4.2 Identification and analysis of additional
artifacts . . . 184 4.2.5 Basic component architecture and basic realized
workflow . . . 188 4.2.5.1 Basic external interfaces . . . 188 4.2.5.2 Basic internal components . . . 193 4.2.5.3 Model/dynamic input/output data engine 197 4.2.5.4 Model/dynamic input/output data ac-
cess area . . . 198 4.2.5.5 I/R analyzer . . . 199 4.2.5.6 Basic realized workflow . . . 202
4.3 Impact Analysis Framework . . . 213
4.3.1 General characteristics/aspects for design of im- pact dependency models . . . 216
4.3.2 SIDepMod(Gen) and BIDepMod(Gen): Generic SI and BI dependency models . . . 220 4.3.3 BIDepMod(Char): BI dependency model using
business degradation metrics . . . 223 4.3.4 SIDepMod(Subj:Sv): SI dependency model with
degradation dependencies of services . . . 228 4.3.5 SIDepMod(Subj:SvInst): SI dependency model
with degradation dependencies of service instances 235 4.3.6 SIDepMod(Subj:Fcty): SI dependency model
with degradation dependencies of functionalities . 237 4.3.6.1 Subdivision of services into functional-
ities: concepts and notations . . . 242 4.3.6.2 Refined types of functionality . . . 244 4.3.7 SIDepMod(Subj:Fcty/Inst): SI dependency mo-
del with degradation dependencies of functiona- lity instantiations . . . 249 4.3.7.1 Functionality instantiations and func-
tionality parameters . . . 255 4.3.7.2 Resource usage instantiations and re-
source usage parameters . . . 264
4.3.8 SIDepMod(QoX) and SIDepMod(QoXInst): SI
dependency models with dependencies of QoX degradations . . . 265 4.3.9 SIDepMod(Coop): SI dependency model with dy-
namics at a time instance . . . 273 4.3.10 SIDepMod(DynOT): SI dependency model for
dynamics over time . . . 283 4.3.11 Implementation of impact dependency models . . 285
4.4 Recovery Analysis Framework . . . 290
4.4.1 Design of impact rating models . . . 292 4.4.2 Design of recovery action dependency models . . . 298 4.4.3 Implementation of impact rating models and re-
covery action dependency models . . . 311
4.5 Recovery Tracking Framework . . . 315
4.5.1 Design of recovery change tracking dependency models . . . 317 4.5.2 Design of model adaption dependency models . . 321 4.5.3 Implementation of recovery tracking dependency
models . . . 328
4.1. Idea and Approach Taken
Here, the core of the thesis, the generic framework for impact and recovery analysis is developed. Sect. 4.1, as an overview, introduces the approach for the development of the framework in general, while in Sect. 4.2 to Sect. 4.5 the subsequent steps of this development are performed and discussed.
4.1
Idea and Approach Taken
The issue of this thesis is to develop a framework to support the performing of I/R analysis with as much automation as possible. In the following, this whole framework is referred to as the impact and recovery analysis framework (I/RAFw).
In chapter 2 necessary requirements for such a framework were identified. The complete framework developed here should lastly cover all these require- ments.
Because the framework should be applicable for any given service provisio- generic
framework and its instantiation methodology
ning scenario, it will, as already indicated in chapter 2, consist of the following parts: a generic part and an instantiation methodology to apply this generic part to any given scenario. The generic part (or the instantiated version of this) has to fulfill all above identified requirements: The requirement classes service modeling, service degradation modeling, business (financial/reputa- tional) impact modeling and recovery action modeling are concerned with the modeling of some specific pieces of information for the I/R analysis, whereas the requirement class workflow modeling is specifically concerned with the actual run of I/R analysis by using modeling information fulfilling the first four requirement classes.
Therefore it is reasonable to divide the framework into a model part (con- model part and workflow part
cerned with the first four requirement classes) and a workflow part. Conse- quently, the generic part of the framework is consisting of a generic model and a generic workflow, which both can be instantiated by the instantiation methodology to a specific model and a specific workflow.
To sum it up, the framework will comprise these parts:
• (1) generic part:
– (1a) a generic model for all information required for I/R analysis – (1b) a generic workflow for performing I/R analysis by using the
model (1a) and specified interfaces with existing management con- cepts/areas/tools
• (2) a instantiation methodology to apply the generic model (1a) and the
generic workflow (1b) to a given specific scenario
In this chapter the generic part, the generic impact and recovery analy- sis framework (I/RAFw), is covered, whereas its instantiation methodology (I/RAFw InstMeth) is treated in Sect. 5.
Actually, the generic framework I/RAFw, is consisting of four framework parts, which are accordingly developed in four consecutive, specific steps. Fig. 4.1 illustrates these specific steps for the approach for the development of the I/RAFw (I/RAFwAppr). They are introduced in the following.
Figure 4.1: Approach for the development of the I/RA framework: basic framework and its extensions
At first, the basic framework (BFw) is introduced in Sect. 4.2. This serves
parts of I/RAFw - steps its development
as a generic basis for all following extensions. That is why it is concerned with all 3 phases of I/R analysis, i.e., impact analysis, recovery analysis, and recovery tracking, but only to be covered in a generic manner. From Sect. 4.3 to Sect. 4.5, extensions of the basic framework are developed and discussed, each covering one of the specific phases. So there are the following extensions of the basic framework: the impact analysis framework (IAFw) discussed in Sect. 4.3, the recovery analysis framework (RAFw) covered in Sect. 4.4, and the recovery tracking framework (RTFw) treated in Sect. 4.5. There, each extension framework is introduced and developed in an iterative manner, cov- ering the set of requirements related to it in a step-by-step manner. Finally, in Sect. 4.6 the complete development of the framework is summarized.
Concerning a particular one of these four steps for the development of
development in
a particular step I/RAFw, the following general statements can be made: In general, it com- prises a workflow specification and a corresponding data model, at least it extends and refines the ones of the basic framework. In turn, the workflow specification comprises a set of consecutive workflow activities, i.e., model- ing and processing interactions to be performed, which have various input and output artifacts. The used artifacts may comprise parts of the data model, as well as additional input/output data necessary. For each workflow activity it specified which (mostly already existing and reused) components, concepts, or techniques are used for the actual realization of the activities.
4.1. Idea and Approach Taken
Moreover, for each particular step of the development the workflow speci- fication may be designed iteratively, distinguishing an abstract, conceptual workflow, and a realization of this abstract workflow, a realization workflow. For the conceptual workflow only the activities and the used artifacts are con- sidered in an abstract manner. Based on this, for the realization workflow it is specified, in concrete and detailed manner, which (ideally already exist- ing reused) techniques, components, and concepts as well as parts of the data model are used to actually perform the workflow activities.
The following list summarizes the relevant issues which are addressed in this chapter for each step of the development:
• data model: for all information involved, as far as required for I/R ana-
lysis.
• workflow: (ideally existing reused) components/techniques and activi-
ties (steps), i.e., interactions of components with necessary input/output artifacts, designed in an rough abstract, as well as a detailed, concrete way.