Design Solution Analysis for the Construction of Situational Design Methods

1. Design Solution Analysis for
the Construction of
Situational Design Methods
Sit ti l D i M th d
Prof. Dr. Robert Winter
Institute f I f
I tit t of Information Management
ti M t
University of St. Gallen
robert.winter@unisg.ch
b t i t @ i h
www.iwi.unisg.ch

2. No Single (Design Solution) Size Fits All (Design Problems)!
g
 A set of reference solutions should each
address a class of design problems
(e.g. quadratic vs rectangual vs round roofs)
 Reference solutions should be adaptable to
specific problems within that class
(e.g. building size, height)
 Still all/many solutions might have certain
common elements/components
 We designate
– such design solutions “situational”
– dimensions along which problem
classes are defined “design factors”
(roof shape. building height)
shape
– resulting problem classes “situations”
– reusable solution components
“fragments” © Apr-11, IWI-HSG
Slide 2

3. When Using Euclidian Metrics, Ultrametric Distances can be
Calculated that Allow to Arrange Concrete & Generic
Solutions in a Tree Diagram
Design
Solution
genericity
Selected range of design problems
© Apr-11, IWI-HSG
Slide 3

4. Design Dimensions Better Help to Understand the
Mutability of (Concrete & Generic) Solutions
Solutions…
Design
Dimension 1:
Shape of roof
two sided
four sided
round Design
Dimension 2:
Height of
low
l high
hi h building
© Apr-11, IWI-HSG
Slide 4

5. Using Design Theories (if Available), Solution
Fragments are Constructed Along Design Dimensions
DT1:
combination
if t wide
too id
DT2:
Double
oub e
roof
© Apr-11, IWI-HSG
Slide 5

6. Proposed Situational Method Engineering Procedure
 Phase 1: Analysis of existing design solutions
– Goal: Understand artefact mutability within design problem class
– Input: Set of design solutions; Potential design factors
– Output: Relevant design factors; Design situations (incl. context
types, project types)
– St
Steps 1-7
17
 Phase 2: Derivation of situational design method
g
– Goal: Provide situated method support for relevant design situations
– Input: Relevant design factors; Design situations (
p g ; g (incl. context types,
yp ,
project types)
– Output: Design method fragments; Configuration rules (fragment-
situation assignment)
– Steps 8-11
© Apr-11, IWI-HSG
Slide 6

7. Phase 1 (Analysis)
Steps 1-3
13
1.
1 Delineate the design problem class (= EAM)
Find appropriate definitions, envision the solution artifact and
develop an idea about design goals.
2. Literature analysis: Identify potential contingency factors for
EAM (= relevant stakeholders/concerns, scope, competences,
( l t t k h ld / t
etc.)
3. Conduct a field study in order to analyze design problems of
that class in practice. As a result, the list of potential
contingency factor candidates is reduced to a smaller set of
relevant “design factors”. Design factors might be aggregates of
several contingency factors that need to be semantically
interpreted.
© Apr-11, IWI-HSG
Slide 7

8. Potential EAM Contingency Factors
 Understanding of EAM
 Organisational embedding of EAM
– Organisational units responsible / involved in EAM
– Stakeholders and users of EAM
– Continuous implementation of EAM
 EAM utilization and functionalities
– EAM ser ices and their cons mption
services consumption
– EAM functions
 EAM planning
l i
54 Questions
© Apr-11, IWI-HSG
Slide 8

9. Survey Sample
Data sources 4 EA conferences in Germany and Switzerland
Time frame June through September 2009
Data sets 119 (minimum of 90% questions answered)
Participants 53.8% user companies, 36.2% vendors & consultants
Number of employees Industry
Verarbeitendes Gewerbe
Handel
20-49
Telekommunikation
50-99
100-249 Banken
250-499 Versicherungen
500-1000
500 1000
Öffentliche Verwaltung
Ö
>1000
Softwareanbieter
Andere
© Apr-11, IWI-HSG
Slide 9

10. Explorative Factor Analysis
Fragestellung 1 2 3 4 5 6 7 8
Ergebnisse des UAM werden genutzt für IT‐Entwicklung 0.800476 0.141426 0.058388 0.148150 0.174145 0.000467 0.125034 0.162510
Ergebnisse des UAM werden genutzt für Koordination verschiedener IT‐Entwicklungsprojekte
0.734350 0.107586 0.096274 0.317765 0.201942 0.096149 0.109258 0.114084
untereinander
Ergebnisse des UAM werden genutzt für IT‐Planung/Infrastrukturarchitekturgestaltung
g g g/ g g 0.665297 0.013101 0.261714 0.395075 0.136232 0.163523 0.010733 0.114114
Die IT‐Bereiche nehmen UAM als ein nützliches Instrument wahr. 0.570033 0.322220 0.047324 -0.134532 0.049200 0.097636 0.447276 -0.124161
Ergebniss des UAM werden genutzt für Analysen auf Architekturmodelle (z. B.
0.510317 0.222308 0.314706 0.036033 0.022402 0.212943 0.129632 0.346665
Abhängigkeitsanalysen, Abdeckungsanalysen)
Die IT‐Bereiche nutzen Ergebnisse regelmässig für ihre täglichen Aufgaben. 0.504131 0.404084 0.109916 -0.058693 0.394738 -0.032843 0.259232 -0.051119
Fachbereiche und IT suchen aktiv den Rat der Architekten. 0.154259 0.698418 0.071800 0.148902 0.157063 -0.009069 0.191750 -0.102167
Ergebnisse des UAM werden genutzt für Kommunikation mit Management 0.166219 0.679039 0.211608 0.178273 0.137576 0.100136 -0.059417 0.095936
Die Stakeholder der Unternehmensarchitektur werden in das UAM eingebunden. 0.219151 0.672739 0.257067 0.133971 -0.093445 0.185147 0.252024 0.101925
Geschäftsleitung nutzt die Ergebnisse für Managementaufgaben. 0.100490 0.617092 0.193176 0.089953 0.256505 0.030861 0.116287 0.411982
Geschäftsleitung nimmt UAM als ein nützliches Instrument wahr. 0.050413 0.590328 0.061192 -0.042414 0.052259 0.222092 0.136852 0.431051
UAM wird mit Geschäftszielen abgeglichen. 0.147210 0.544520 0.086018 0.452659 -0.005170 0.036958 0.058382 0.252239
Architekten verfügen über ein umfangreiches Netzwerk im Unternehmen. -0.046960 0.542203 0.098489 0.252419 0.336306 0.260939 -0.115322 -0.025435
(Unternehmens‐)Architekturmodelle werden regelmässig gemessen und/oder bewertet. 0.040821 0.040484 0.783751 0.004489 0.049957 0.041990 0.251924 0.224562
UAM‐Prozesse werden regelmässig gemessen und/oder bewertet. -0.036934 0.039946 0.782813 0.023666 0.135823 0.041259 0.126394 0.378657
0.215561
0 215561 0.151211
0 151211 0.750274
0 750274 0.045588
0 045588 0.251292
0 251292 -0.006799
0 006799 -0.062555
0 062555 0.128992
0 128992
Es existieren definierte Pflegeprozesse für (Unternehmens‐)Architekturmodelle und ‐daten.
Es existieren definierte UAM‐Prozesse. 0.142311 0.192492 0.695351 0.172625 0.107889 0.131033 0.241531 -0.212421
Ergebnisse des UAM werden genutzt für Dokumentation/Nachführen der
0.283364 0.435609 0.538289 0.091555 0.087244 0.108379 -0.044629 0.074145
Unternehmensarchitektur(modelle)
Es existiert ein einheitliches, unternehmensweit gültiges Architekturmodell. 0.359543 0.258189 0.522918 0.066051 -0.186065 0.279077 0.094033 0.250569
Architekturdaten liegen zentral beim Unternehmensarchitekturmanagement. 0.132761 0.291882 0.521510 0.192821 0.149752 0.219872 -0.163923 -0.129651
UAM ist wesentlicher Teil der IT‐Strategieableitung. 0.042494 0.119321 -0.086886 0.715277 -0.001038 -0.044658 0.317121 0.111199
UAM ist wesentlicher Teil der IT‐Governance. 0.138114 0.199293 0.246463 0.649011 0.100401 0.169442 0.210665 0.029940
Ergebnisse des UAM werden genutzt für Entwicklung von IT‐/Unternehmensstrategie 0.315881 0.206874 0.067868 0.600566 0.012236 0.012150 -0.105159 0.385662
Ergebnisse des UAM werden genutzt für IT‐Governance 0.413656 0.271562 0.263245 0.431554 0.254310 0.059682 0.004517 -0.161787
Ergebnisse des UAM werden genutzt für Informationsversorgung von Fachbereichen
0.322593 0.333750 0.240836 0.138419 0.609760 0.214063 0.037826 0.136209
(Dienstleistungsfunktion)
Ergebnisse des UAM werden genutzt für Informationsversorgung von IT‐Bereichen
0.514331 0.265781 0.364177 0.059373 0.514643 0.087056 0.052446 0.161004
(Dienstleistungsfunktion)
Die Fachbereiche nutzen Ergebnisse regelmässig für ihre täglichen Aufgaben.
Die Fachbereiche nutzen Ergebnisse regelmässig für ihre täglichen Aufgaben 0.181034
0 181034 0.438281
0 438281 0.222279
0 222279 -0 042660
0.042660 0.507995
0 507995 0.137776
0 137776 0.328672
0 328672 0.153104
0 153104
Ergebnisse des UAM werden genutzt für Operations und Maintenance 0.409120 0.018416 0.295503 0.040941 0.483887 0.018000 0.167212 0.244452
Ergebnisse des UAM werden genutzt für Business/IT‐Alignment 0.238235 0.096592 0.107113 0.450093 0.463476 0.142554 0.257626 0.248158
Ergebnisse des UAM werden genutzt für Moderation zwischen Fachbereichen und IT‐Bereichen
0.408141 0.409507 0.089034 0.313720 0.442384 0.201688 0.011645 0.102206
(bzw. jeweils untereinander)
UAM findet mit einem interdisziplinären Team statt. -0.050428 -0.033509 0.197490 0.004789 0.146615 0.826350 0.175494 0.130883
Es findet regelmässiger Austausch zwischen UAM‐Team und Fachbereichen statt (z. B. in Form
0.175375 0.323456 0.070511 0.061291 0.165969 0.759521 0.069835 0.097980
von Architekturboards o.ä.).
Es findet regelmässiger Austausch zwischen UAM‐Team und IT‐Bereichen statt (z. B. in Form von
0.410923 0.314195 0.049128 0.218196 -0.104324 0.657814 0.212544 0.036255
Architekturboards o.ä.).
UAM hat Einfluss auf die Gestaltung der IT‐Infrastrukturarchitekturen.
UAM hat Einfluss auf die Gestaltung der Anwendungsarchitekturen.
UAM hat Einfluss auf die Gestaltung der Geschäftsarchitektur.
0.047357
0.277847
0.108147
0.123176
0.086487
0.230733
0.193450
0.342529
0.089942
0.153073
0.207563
0.118149
0.720609
0.650584
0.250139
0.020106 8 Factors
0.407154 0.086374 0.145291 0.397435 0.076207 0.157453 0.547972 0.070931
Ergebnisse des UAM werden genutzt für Unternehmensentwicklung 0.123951 0.158184 0.260378 0.193434 0.166341 0.095552 0.120478 0.720681 discovered
Ergebnisse des UAM werden genutzt für Strategische Planung (z. B. Produktplanung)
Ergebnisse des UAM werden genutzt für Strategische Planung (z B Produktplanung) 0.257772
0 257772 0.115211
0 115211 0.158296
0 158296 0.339130
0 339130 0.161227
0 161227 0.170475
0 170475 0.120380
0 120380 0.571930
0 571930
© Apr-11, IWI-HSG
Slide 10

11. Phase 1 (Analysis)
Steps 4-7
47
4. The design problem class is redefined by specifying value ranges
for the design factors. This means that “outliers” are ignored from
factors outliers
further analysis in order to create homogeneous problem sets and
subsets.
5. Those field study data of observations which still belong to the
redefined design problem class, are used to calculate ultrametric
distances between specific design solutions. Th calculation i
di b ifi d i l i The l l i is
based on certain ‘similarity’ metrics– usually the Euclidian distance
with regard to the observed values of design factors
factors.
6. A useful level of solution generality is determined. Usually
clustering errors related to the number of clusters are used for this
analysis.
7. Using the desired solution g
g generality, the resulting design
y, g g
situations are specified. The situations should not only be
specified formally (by value ranges of the design factors), but also
should b i t
h ld be interpreted semantically (“design problem t
t d ti ll (“d i bl types”).
”)
© Apr-11, IWI-HSG
Slide 11

12. Extended Meta Model for Fragment-based Situational
Method Engineering
[Bucher et al., 2007] © Apr-11, IWI-HSG
Slide 12

13. Cluster Analysis
3 Clusters
discovered
© Apr-11, IWI-HSG
Slide 13

14. As-is EAM Approach “blue”:
Active Business to IT EAM
Business-to-IT
 Extensive IT operations
support, management support,
IT strategy support
 Integrative role and d i
I t ti l d design
impact is high
 High maturity suspected
 53 out of 94 EAM cases
© Apr-11, IWI-HSG
Slide 14

15. As-is EAM Approach “red”:
“Lightweight” EAM
Lightweight
 Very limited realization wrt
every design f
factor!
 Low maturity suspected
 22 out of 94 EAM cases
© Apr-11, IWI-HSG
Slide 15

16. As-is EAM Approach “green”:
Passive, IT biased
Passive IT-biased EAM
 Focus on IT operations and on
IT alignment
 Low values for design impact,
integrative role and business
support
 Passive role!
 Focus on documentation not
documentation,
on innovation support
 19 out of 94 EAM cases
t f
© Apr-11, IWI-HSG
Slide 16

17. Problem Situation = Context Type X Project Type
Project type A Project type B Project type C Project type …
Context type A Situation 2 Situation …
Context type B Situation 3 Situation …
Situation 1
Context type C Situation 4
Context type … Situation … Situation …
Context type examples: Project type examples:
 Multinational company  Company-wide introduction of SOA
 T l
Telecommunications company
i ti  MMerger of units A and B
f it d
 Financial service company  Introduction of standard software C
 Process reengineering in unit D
Adapted from [Bucher et al. 2007] © Apr-11, IWI-HSG
Slide 17

18. EAM Design Situations
(Based on EAM Maturity Model)
To-be Approach To-be Approach To-be Approach
“green” “red” “blue”
As-is Approach
Situation 1 Situation 2 Too difficult
“No
“N EAM”
As-is Approach Situation 3
No progress
“green”
g
As-is Approach Situation 4
“red” No progress
As-is Approach Already most Already most
“blue” advanced advanced
© Apr-11, IWI-HSG
Slide 18

19. Phase 2 (Method Derivation)
Steps 8-10
8 10
8. By linking back analysis results to the characteristics of the
underlying design problem descriptions, design f factors ( result
(=
of principal component analysis) and design situations (= result
of agglomerative cluster analysis) of the design problem class
are interpreted semantically.
9.
9 Those combinations of design (problem) situations and 1 or 2
design factors are identified where the selected design factors
represent best an elementary problem solution fragment.
10.By linking desired properties to design factors, ideal problem
solutions are related to the n-dimensional system. If many
y y
observations in the data set have already reached such desired
state(s), there might be even one (rarely more) “design
situation(s)” where the problem has already been solved – i.e.
there might have been cluster(s) identified that represent(s) ideal
problem solutions.
bl l ti
© Apr-11, IWI-HSG
Slide 19