Build evolution

The first intention concerns the evolution building. Its goal is to show how to define the evolution models with the IS-SM entities in order, later, to simulate the evolution and identify the resulting impacts.

As stated previously (Chap. 5), evolution steering requires an understanding of the evolution, and models are necessary means to understand it. They are particularly valuable in complex situations such as IS evolutions which are not observable phenomena and which lie in the intertwining of the IS dimensions.

Building evolution models is a process of abstraction which reduces the amount of information to process in order to keep only the most relevant information, and therefore to reduce complexity.

It allows steering actors to communicate among each others and with the organisation, to work collaboratively, to support the decisions related to the project of evolution and finally to facilitate the evolution operationalisation in each IS dimension with information as a

"common language".

E

a) START

f) STOP b) Build evolution

c) Assess risks

d) Do the transition

e) Operate the evolution

5) by assessment 1) by conception

2) by analysis

3) by preparation

4) by commitment

IAG E.ab1 – Build evolution by conception

The strategy "by conception" specifying how to reach the intention "Build the evolution" from

"Start" is a complex process. Therefore, the IAG representing this map section is refined into a more detailed map E.ab1 show in Figure 145.

Figure 145 – The map representing the IAG E.ab1: Building the evolution by conception IAG E.ab1.ab1 – Define the evolution impact space

The strategy "by analysis" leading to the definition of the evolution impact space is detailed by another, lower level, map E.ab1.ab1 shown in Figure 146.

Figure 146 – The map representing the IAG E.ab1.ab1 - Definition of the evolution impact space by analysis

a) START b) Build evolution 1) by conception

E.ab1 - Building the evolution by conception

e) STOP

IAG E.ab1.ab1.ab1* - Identify entity for the Dyn_Space by abstraction

The identification of the Dyn_Space (entity "Dyn_ISSM") (see above section 5.6 p. 138) is done by abstraction. It aims is to do a mapping between the initiative concepts and the IS-SM entities (see above Chap.3).

Three situations may occur as Figure 147 illustrates: an initiative concept relates to one IS-SM entity ("s1"), an initiative concept relates to several IS-IS-SM entities ("s2") and an initiative concept relates to no IS-SM entity ("s3").

Figure 147 - Mapping between initiative and IS-SM

This mapping is done by abstraction: indeed, according to [Leppänen 2007] the process of abstraction is applied to suppress details of a particular thing, but also to emphasize features that are pertinent to the problem at hand. Four basic abstraction principles are distinguished which apply either on primary things or on their predicates: classification/instantiation ("instance of"), composition/decomposition ("part of"), generalisation/specialisation ("is a") and grouping/individualisation ("member of") (Table 9).

Signature: <Start, Identify entity for the Dyn_Space by abstraction>

Overview: Product Model:

Process part:

For each initiative concept do:

Search related IS-SM entity by classification ; Search related IS-SM entity by instantiation ; Search related IS-SM entity by composition ;

a) START b) Identify entity

for the Dyn_Space 1) by abstraction

Evolution

IS-SM_Entity

Dyn_Space

Evolution_Impact Dyn_ISSM

Search related IS-SM entity by generalisation ; Search related IS-SM entity by specialisation ; Search related IS-SM entity by grouping ;

Search related IS-SM entity by individualisation ; Populate IS-SM entities "Dyn_Space" ;

Populate IS-SM entities "Dyn_ISSM" ; End

Table 9 - IAG E.ab1.ab1.ab1

For example, the evolution E1 concerns the change of position of a person in the same organisational unit. Based on IS-SM, its Dyn_Space is defined as a set of the entities:

Dyn_Space(E1) = {Activity, Activity_Person_Position, Person, Person_Position, Position}

ISG E.ab1.ab1.b * – Progress from Identify entity for the Dyn_Space

In order to progress from the first set of entities identified for the Dyn_Space by abstraction (see IAG E.ab1.ab1.ab1* - Identify entity for the Dyn_Space by abstraction), there are two possibilities: either completing the entity set by ascendant/descendant query (to loop on the intention "Identify entity for the Dyn_Space") or identifying the entity for the DM_Space (to progress to the intention "Identify entity for the DM_Space"). It is recommended that the completion should be executed first (Table 10).

Signature: <(all Dyn_Space entities='identified' by abstraction), Progress from Identify entity for the DM_Space>

Overview: Product Model:

Process part:

There are two strategy options:

Option 1 : Identify entity for the Dyn_Space by ascendant/descendant query (detailed in guideline IAG E.ab1.ab1.bb3);

Option 2 : Identify entity for the DM_Space by analysis (detailed in guideline E.ab1.ab1.bc4).

In order to select a strategy, its related decisional argument must be employed : For Option 1 : <a1> = no additional entity from Dyn_Space has yet been identified by

b) Identify entity

for the Dyn_Space c) Identify entity

for the DM_Space

ascendant/descendant query ;

For Option 2 : <a2> = all additional entities from Dyn_Space (including ascendant/descendant) have been identified.

Table 10 - ISG E.ab1.ab1.b

IAG E.ab1.ab1.bb3 * - Identify entity for the Dyn_Space by ascendant/descendant query In order to complete the Dyn_Space set of entities with their IS-SM ascendants and descendants (see above section 5.6, p. 138), an algorithm is proposed in the Appendix (see Appendix B -, p. 215) to automate this task. To this purpose, IS-SM is considered as an acyclic directed graph⁷⁸ which is recursively visited from each entity of Dyn_Space (Table 11).

Signature: <(all Dyn_Space entities='identified' by abstraction), Identify entity for the Dyn_Space by ascendant/descendant query >

Overview: Product Model:

Process part:

To complete the Dyn_Space by ascendant/descendant query do:

getAscDesc (Graph g, Set[Node] dyn_space)⁷⁹ ; Populate IS-SM entities "Dyn_Space" ;

Populate IS-SM entities "Dyn_ISSM" ; End

Table 11 - IAG E.ab1.ab1.bb3

For example, with evolution E2, if Dyn_Space(E2) = {Person_Position}, then:

 Ascendant(Dyn_Space(E2)) = {Organisational_Unit, Person, Position}

 Descendant(Dyn_Space(E2)) = {Activity_Person_Position, Activity_Position}

 Dyn_Space(E2)' = {Activity_Person_Position, Person, Activity_Position, Organisational_Unit, Person_Position, Position}

78 IS-SM is more precisely a multigraph which allows multiple edges with the same source and target nodes. However, for simplicity reason and as it does not affect our results, we don't consider this

b) Identify entity for the Dyn_Space 3) by ascendant/descendant

query

Evolution

IS-SM_Entity

Dyn_Space

Evolution_Impact Dyn_ISSM

IAG E.ab1.ab1.bc4 * - Identify entity for the DM_Space by analysis

The goal of the identification of the DM_Space entities (see section 5.6, p. 138) is to complete the Dyn_Space entities set with IS-SM entities (entity "DM_ISSM") which may be impacted as well, though not identified by the ascendant/descendant query and which may be important for decision making (Table 12).

It is done by three required and complementary sub-guidelines: the first one is executed by an organisational analysis which is performed on the activity entities of IS-SM, the second by a regulatory analysis which is performed on the regulatory entities of IS-SM and the third one by an information analysis which is performed on the information entities of IS-SM.

Contrary to the identification of the Dyn_Space entities, there is here no algorithm to implement the achievement of this guideline. These sub-guidelines are executed by the steering actors and rely on their expertise, they may be executed in parallel and in any order but they are all necessary.

Signature: < (all Dyn_Space entities='identified'), Identify entity for the DM_Space by analysis >

Overview: Product Model:

Process part:

To identify the IS-SM entities for the DM_Space by analysis do : Analyse the organisational context ;

Analyse the regulatory context ; Analyse the information context ; Populate IS-SM entities "DM_Space" ; Populate IS-SM entities "DM_ISSM" ; End

Table 12 - IAG E.ab1.ab1.bc4 For example, the DM_Space of the E1:

 Dyn_Space(E1) = {Activity, Activity_Person_Position, Person, Person_Position, Position}

 DM_Space(E1) = {Position_Reg_Role, Regulatory_Role, Activity_Concept, Concept}

b) Identify entity

IAG E.ab1.ab1.cd5 - Stop by union

When the set of entities for the DM_Space is defined, the evolution impact space (entity

"Evolution_Impact") is calculated by the union of the two previously defined entities' sets⁸⁰: the Dyn_Space (IAG E.ab1.ab1.ab1* - Identify entity for the Dyn_Space by abstraction) and the DM_Space (IAG E.ab1.ab1.bc4 * - Identify entity for the DM_Space by analysis) (Table 13).

Signature: <(all DM_Space entities='identified'), Progress to Stop by union>

Overview: Product Model:

Process part:

To build the total "Evolution_Impact" of the evolution e, do:

DM_Space(e)  Dyn_Space(e) End

Table 13 - IAG E.ab1.ab1.cd5 For example, the impact space of E1 is:

 With DM_Space(E1) = {Activity, Activity_Person_Position, Person, Person_Position, Position}

 With Dyn_Space(E1) = {Activity_Concept, Concept, Position_Reg_Role, Regulatory_Role}

Impact space(E1) = {Activity, Activity_Concept, Activity_Person_Position, Concept, Person, Person_Position, Position, Position_Reg_Role, Regulatory_Role}

IAG E.ab1.bc1– Identify the evolution structural model by using primitive methods

The goal of this guideline is to identify the evolution structural model using the primitive methods which have been identified in the evolution impact space. This guideline is refined by the map E.ab1.bc1 (Figure 148).

d) STOP c) Identify entity

for the DM_Space 5) by union Evolution

DM_Space Dyn_Space

Evolution_Impact

Figure 148 - The map representing the IAG E.ab1.bc1 IAG E.ab1.bc1.ab1* - Identify atomic primitive with impact space

The goal of the guideline is to identify the atomic primitives which are the elementary elements of the evolution structural model.

This identification relies on the impact space of the evolution previously defined (IAG E.ab1.ab1.cd5 - Stop by union) in entity "Dyn_Space: for each entity of this set, the corresponding atomic primitives are identified: create(), update(), activate() or inactivate() (Table 14)

Signature: <(evolution impact space='defined'), Progress to Identify atomic primitive with impact space>

E.ab1.bc1 - Identification of evolution structural model by primitive methods using

e) create subsequent evolution a) START

b) Identify

atomic primitive c) group atomic primitive

f) STOP

Process part:

For each entity of Dyn_Space do:

Find corresponding atomic primitive (create, udpate, activate or inactivate) ; Populate entity "AP_DynISSM".

End

Table 14 - IAG E.ab1.bc1.ab1

For example, for E1, the following set of atomic primitives is identified:

 P1 Person_Position.Inactivate()

 P2 Activity_Person_Position.Inactivate()

 P3 Person_Position.Create()

 P4 Person_Position.Activate()

 P5 Activity_Person_Position.Create()

 P6 Activity_Person_Position.Activate()

 P7 Person.Create()

 P8 Person.Activate()

IAG E.ab1.bc1.bc2 – Group atomic primitive by analysis

The goal of this guideline is to prepare the composition of the evolution. Once all the atomic primitives are identified, they are grouped following two required and complementary sub-guidelines: i) the analysis of the IS domain and ii) the verification of precedence constraints.

These two sub-guidelines are executed in sequence (the analysis of the IS domain comes first) and they are all necessary (Table 15).

The analysis of the IS domain aims to group the atomic primitives. It is conducted with the experts of the domain at hand in order to build one or more groups of atomic primitives which are meaningful for the practice of the organisation.

The verification of the precedence constraints aims to identify the constraints which determine the order of execution of the atomic primitives. This verification is based on the existential dependencies of the IS-SM, and the object lifecycle (see above

Figure 125, p. 127).

Signature: < (all atomic primitive='identified'), Group atomic primitive by analysis>

Overview: Product Model:

Process part:

To group atomic primitive by analysis do:

Analyse the IS domain ;

When set of atomic primitive correspond to unit of pratice, then do:

Create a group ;

Verify compliance to precedence constraints ; When non-compliance is identified, then do:

Re-arrange group ; End

Table 15 - IAG E.ab1.bc1.bc2

For example, the analysis of the IS domain shows that three groups of atomic primitives (hereafter G1, G2 and G3) can be identified from the set of atomic primitives {P1-P8}. Indeed, they correspond to three domain units: the change of position (G1), the activity assignment (G2) and the employee hiring (G3). The verification of the precedence constraints allows these compositions, because the primitives P2 and {P5, P6} apply on different objects.

G1

P1 Person_Position.Inactivate()

P2 Activity_Person_Position.Inactivate() P3 Person_Position.Create()

P4 Person_Position.Activate() G2

P5 Activity_Person_Position.Create() P6 Activity_Person_Position.Activate() G3

P7 Person.create() P8 Person.activate()

b) Identify

atomic primitive c) group atomic primitive

2) by analysis

ISG E.ab1.bc1.c – Progress from group atomic primitive

In order to progress from grouping atomic primitive there are two intentions: to compose the evolution or to create subsequent evolution.

The creation of a subsequent evolution (see above Section 0, p. 126) must be chosen when the success of a group of atomic primitive is identified as independent from the success of another group (Table 18).

Signature: <(all atomic primitive='grouped'), Progress from Group atomic primitive>

Overview: Product Model:

Process part:

There are two options :

Option 1 : Compose evolution by IS domain analysis (detailed in guideline IAG E.ab1.bc1.cd4) ;

Option 2 : Create subsequent evolution by independence identification (detailed in guideline IAG E.ab1.bc1.ce5).

In order to select a strategy, its related decisional argument must be employed:

For option 1 : <a1> = success of a group depends of another one success ; For option 2 : <a2> = success of a group doesn't depend of another one success.

Table 16 - ISG E.ab1.bc1.c

IAG E.ab1.bc1.cd4 and IAG E.ab1.bc1.ed6 – Compose evolution by IS domain analysis The goal of these guidelines is to compose the evolution primitives by the analysis of the IS domain, after having grouped the primitives (IAG E.ab1.bc1.cd4) and/or after having created subsequent evolution(s) (IAG E.ab1.bc1.ed6) in order to continue structuring the evolution.

Each evolution group is composed by the analysis of the IS domain with experts (entities

"Composite_Primitive" and "Primitive_Composition"). Generally, a composite primitive has a correspondence with the IS domain. When composing the evolution, the actors must bear in mind that failure at a local level, causes the global level to fail, too (see above Section 5.4, p.

134).

Signature: <(All atomic primitives='grouped'), Compose evolution by IS domain analysis

Overview: Product Model:

Process part:

To compose the evolution by analysis of the IS domain do:

For each evolution group do:

When it corresponds to a unit of activity of the IS domain do:

Create a primitive composition (entity "Primitive_Composition");

End

Table 17 - IAG E.ab1.bc1.cd4 and IAG E.ab1.bc1.ed6

For example, the analysis of the IS domain shows for E1 that the triggering evolution can be de-composed with the creation of a composite primitive CP1 which groups P1, P2, P3 and P4.

Figure 149 - Example of composition

IAG E.ab1.bc1.ce5 – Create subsequent evolution by independence identification

The goal of this guideline is to create subsequent evolution (see Section 5.1) by independence identification.

A subsequent evolution is created (entity "Subsequent_Evolution") from the atomic primitives groups when the success of a group of atomic primitives is identified as independent from the success of another group (Table 18).

e) create subsequent

Signature: <(all atomic primitive='grouped'), Create subsequent evolution by independency identification>

Overview: Product Model:

Process part:

To create subsequent evolution do:

For each group of atomic primitive do:

When its sucess is independant from all other groups do:

Populate entities "Evolution", "Subsequent_Evolution",

"Evolution_Composition", "Primitive" and "Primitive_Composition";

End

Table 18 - IAG E.ab1.bc1.ce5

For example (Figure 150), a subsequent evolution is created for E1 where G1 and G2 are part of the triggering evolution and G3 the subsequent evolution. Indeed, the success of G1 and G2 does not depend on the success of G3.

Figure 150 - Example of subsequent evolution creation IAG E.ab1.bc1.df7 – Stop by validation

The goal of this guideline is to validate the designed structural model. Indeed, the evolution structural modelling requires two validations: i) the completeness and ii) the integrity validation. The first one verifies that each atomic primitive identified above is part of a composition. The second one verifies that the resulting evolution model complies with the integrity rules of the structural model defined in the Appendix (see Appendix B -, p. 215).

They are both required and complementary and may be executed in parallel (Table 19).

e) create subsequent evolution c) group atomic primitive

5) by independency identification

Evolution

Evolution_Composition Subsequent_Evolution

Primitive

Atomic_Primitive Composite_Primitive Primitive_Composition

triggering

P1 P2

P3

P4 P7 P8 subsequent

P5 P6

Signature: <(structural model='identified'), Stop by validation >

Overview: Product Model:

Process part:

To stop by validation do:

Validate completeness of the structural model;

Validate the structural model by checking the IS-SM integrity rules⁸¹; End

Table 19 - IAG E.ab1.bc1.df7

ISG E.ab1.c – Progress from Identify the evolution structural model

In order to progress from identifying the evolution structural model there are two intentions:

either identifying new evolution structural model(s) or planning the evolution. The latter is chosen after having identified all alternate structural models (Table 20).

Signature: <(one evolution structural model='identified'), Progress from Identify the evolution structural model >

Overview: Product Model:

Process part:

There are two options :

Option 1 : Identify evolution structural model by alternate model identification (detailed in guideline IAG E.ab1.cc3);

Option 2 : Plan the evolution by development (detailed in guideline IAG E.ab1.cd4).

In order to select a strategy, its related decisional argument must be employed:

For option 1 : <a1> = all alternate models have not been identified;

For option 2 : <a2> = all alternate models have been identified.

Table 20 - IAG E.ab1.c

3) by alternate model identification Evolution

Evolution_Composition Subsequent_Evolution

Primitive

Atomic_Primitive Composite_Primitive Primitive_Composition

IAG E.ab1.cc3 - Identify the evolution structural model by alternate model identification There are sometimes one (or more) possible alternative(s) to structure the evolution, i.e. to compose its primitives. These compositions are based on situation-specific arguments related to a position, to an organisational unit, or to a SI, for example.

However, these alternative models must take into account the precedence constraints related to the existential dependencies, the object lifecycle (see above p. 128). Moreover, when designing alternate models, the actors must bear in mind that failure at a local level, causes the global level to fail, too (Table 21).

Signature: < (one evolution structural model='identified'), Identify the evolution structural model by alternate model identification >

Overview: Product Model:

Process part:

To identify the evolution structural model by alternal model identification do:

For each new organisational argument, do : Execute guideline IAG E.ab1.bc1 ; End

Table 21 - IAG E.ab1.cc3

For example, an alternate structural model to Figure 150 can be identified with two subsequent evolutions: "E1bis_sub1" and "E1bis_sub2" (Figure 151).

Figure 151 - Example of alternate structural model

c) Identify the evolution structural

model

3) by alternate model identification

Evolution

Evolution_Composition Subsequent_Evolution

Primitive

Atomic_Primitive Composite_Primitive Primitive_Composition

E1bis P1

P2 P3

P4

E1bis_sub1

P5 P6

E1bis_sub2

P7 P8

IAG E.ab1.cd4 – Plan the evolution by development

After having identified possible alternate structural models, one planning (entity "Planning") is developped for each identified structural model. It includes the sub-guidelines for: i) sequencing the primitives, ii) developing a schedule and iii) allocating related resources. They must be executed in sequence and they are all required (Table 22).

There may be several possibilities for arranging the evolution primitives among the same structural model (regardless of the precedence constraints which have previously been taken into account) and one has to be chosen. Here, only strict (without coincidence) and acyclic orders of precedence are considered.

For example, with the three primitives Px, Py and Pz, if Py existentialy depends on Px, there are three possible orders of precedence as illustrated in Figure 152.

Figure 152 - Possible orders or precedence for Px, Py and Pz

During this planning, initial risks may already be detected and, when applicable, must be documented (Entities "Risk_Goal_Evolution", "Risk" and "Initial_Risk").

The resources allocation mainly implies to take decisions on: i) employees affectation, ii) financial and technical needs.

Signature: <(all evolution structural model='identified'), Plan the evolution by development>

Overview: Product Model:

Process part:

To plan the evolution by developement do:

Py

Possibility 1: Px < Py < Pz Possibility 2: Px < Pz < Py Possibility 3: Pz < Px < Py

Possibility 1: Px < Py < Pz Possibility 2: Px < Pz < Py Possibility 3: Pz < Px < Py

Dans le document Conceptual framework for the steering of Information Systems Evolution (Page 155-172)