Towards Designing Modular Structures for Reducing Non-linear Effects of Organizational Change

1. Towards Designing Modular Structures forReducing Non-linear Effects of OrganizationalChange Marien Krouwel May 15th 2013 EEWC 2013 DC

2. Proposition Full-functional modules for organizations in which the impact of a given change is small, are a necessary addition to the field of Enterprise Engineering I willnot do thisalone!

3. Small change, large impact system type Business Information Data Context (environment + demand) Δlaw Δcustomerneeds Function Construction / ontology perspective Construction / implementation people means Context (supply)

4. Even small changes in construction may have a high impact IMPACT IMPACT IMPACT IMPACT 99900 99901 mary@acompany susan@acompany

5. Example 2: Exam marks Change: Procedure v2 N IMPACT IMPACT IMPACT N

6. Example 3: it starts with IT … • Change of IT in e.g. financial department  change of • Processes in department • Interfaces with department • Processes in other departments • IT in other departments • …

7. These effects need to be reduced in order to ease change • Main question • Can non-linear effects of changes in the construction of an enterprise be reduced? • Non-linear effect: any effect of a change, besides the change itself • non-linear implies the effect could also be smaller than the change itself; any other terminology?

8. Normalized Systems: for ITwithout combinatorial effects • Combinatorial effects: special case of non-linear in which the impact of a change depends (also) on the size of the system • Normalized Systems theory: • by adhering to four principles • embodied in 5 modular structures • a stable IS without CE’s can be created • with respect to 8 anticipated changes

9. Benefits of modularity * • Complexity reduction • Comprehensibility • Easy-replacement • Reducing impact of a change * (McIlroy, Parnas, Baldwin & Clark, Sanchez & Mahoney, Simon) • The key for enterprises to be able to deal with change is modularity!

10. Modularity in EE • B/I/D • Production/coordination • Essence/implementation • Essence: transaction and roles • Implementation: assignment of technologies (human, ICT) • Sub question 1:What are the concerns in the implementation of enterprises? • 1b. And to what extent are they generic? • The ontological model of an enterprise is a better starting point for modularization than traditional process models (Terlouw)

11. Ex. implementation concerns * • Employees • Roles/departments/functionary types • Competences • Equipment, devices, applications, databases, infrastructure, etc. • Channels • Workplace/office locations • … * (Op ’t Land and Krouwel, 2013)

12. Organizational modular structures Element Trans-action Actor Role Info. object … … Elements organization = n Instances of Elements • Sub question 2:What modular structures can deal with some of the generic concerns without introducing NLE’s?

13. Example: European Patent Office • Differences in: • Order of working • Language(s) • Deparments • Law • Channels •  IT

14. Example: European Patent Office • Change • Internal structure of core and GC’s changes indepedently • Existence of and interactions between core and GC’s remain

15. Limitation: NLE’s within transactions • Dealing with NLE’s between transactions is a totally different (and larger?)problem! • In NS: how to avoid two action elements that do similar things

16. Conceptual model

17. Approach

18. Gathering implementation concerns • Literature • Enterprise Architecture • Modularity • Organization design • By looking for instabalities in current implementations • What happens if… • Comparing different implementations (e.g. EPO)

19. Inter-dependencies and change frequency • Dimensions may have interdependencies, e.g., • adding e-mail as sales channel, requires an e-mail server, application, desktop, etc. • new application requires new competences • Some dimensions change quickly, others much slower • Quick(er): employees • Slow(er): roles/departments, new channel to offer services

20. Designing modular structures • Principles • Guidelines • Patterns • Elements

21. Experiment (1) • Five groups, randomly assigned, consisting of • enterprise (transformation) architects • IT architects • business analysts • IT managers • Four groups will be given assignment to model the implementation of described enterprise • Group 1: implementation concerns • Group 2: modular structures • Group 3: modular structures + implementation concerns • Group 4: no additional aids

22. Experiment (2) • Group 5 will rank implementations on presence of non-linear effects of some changes • First individually • Then together to reach consensus

23. Planning

24. Expected impact on theory • Extension to/detailing of Framework of Enterprise Engineering (Hoogervorst, 2011) • Applying Normalized Systems theory to the level of enterprises • Clues for identifying non-linear effects • Concerns to look for • People to talk to

25. Expected impact on practice • Implementation concerns enable • better understanding of current organization implementation • to design future organization implementation(s) • to make informed change decisions • designing agile IT • Modular structures enable • designing enterprises that are able to change quickly • in which transformations are easy and successful • TOGAF enterprise continuum

26. Questions Marien.Krouwel@student.ua.ac.be Marien.Krouwel@capgemini.com