Upcoming SlideShare
×

# ME2011 presentation by Winter

851 views
817 views

Published on

Design Solution Analysis for the Construction of Situational Design Methods

0 Likes
Statistics
Notes
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

• Be the first to like this

Views
Total views
851
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
0
0
Likes
0
Embeds 0
No embeds

No notes for slide

### ME2011 presentation by Winter

1. 1. Design Solution Analysis forthe Construction ofSituational Design MethodsSit ti l D i M th dProf. Dr. Robert WinterInstitute f I fI tit t of Information Management ti M tUniversity of St. Gallenrobert.winter@unisg.ch b t i t @ i hwww.iwi.unisg.ch
2. 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. 3. When Using Euclidian Metrics, Ultrametric Distances can be Calculated that Allow to Arrange Concrete & Generic Solutions in a Tree Diagram Design Solutiongenericity Selected range of design problems © Apr-11, IWI-HSG Slide 3
4. 4. Design Dimensions Better Help to Understand theMutability of (Concrete & Generic) Solutions Solutions… DesignDimension 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. 5. Using Design Theories (if Available), SolutionFragments are Constructed Along Design Dimensions DT1: combination if t wide too id DT2: Double oub e roof © Apr-11, IWI-HSG Slide 5
6. 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. 7. Phase 1 (Analysis)Steps 1-3 131.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. 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. 9. Survey SampleData sources 4 EA conferences in Germany and SwitzerlandTime frame June through September 2009Data 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. 10. Explorative Factor Analysis Fragestellung 1 2 3 4 5 6 7 8Ergebnisse des UAM werden genutzt für IT‐Entwicklung 0.800476 0.141426 0.058388 0.148150 0.174145 0.000467 0.125034 0.162510Ergebnisse 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.114084untereinanderErgebnisse 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.114114Die 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.124161Ergebniss 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.346665Abhä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.051119Fachbereiche und IT suchen aktiv den Rat der Architekten. 0.154259 0.698418 0.071800 0.148902 0.157063 -0.009069 0.191750 -0.102167Ergebnisse des UAM werden genutzt für Kommunikation mit Management 0.166219 0.679039 0.211608 0.178273 0.137576 0.100136 -0.059417 0.095936Die Stakeholder der Unternehmensarchitektur werden in das UAM eingebunden. 0.219151 0.672739 0.257067 0.133971 -0.093445 0.185147 0.252024 0.101925Geschäftsleitung nutzt die Ergebnisse für Managementaufgaben. 0.100490 0.617092 0.193176 0.089953 0.256505 0.030861 0.116287 0.411982Geschäftsleitung nimmt UAM als ein nützliches Instrument wahr. 0.050413 0.590328 0.061192 -0.042414 0.052259 0.222092 0.136852 0.431051UAM wird mit Geschäftszielen abgeglichen. 0.147210 0.544520 0.086018 0.452659 -0.005170 0.036958 0.058382 0.252239Architekten 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.224562UAM‐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 128992Es 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.212421Ergebnisse 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.074145Unternehmensarchitektur(modelle)Es existiert ein einheitliches, unternehmensweit gültiges Architekturmodell. 0.359543 0.258189 0.522918 0.066051 -0.186065 0.279077 0.094033 0.250569Architekturdaten liegen zentral beim Unternehmensarchitekturmanagement. 0.132761 0.291882 0.521510 0.192821 0.149752 0.219872 -0.163923 -0.129651UAM ist wesentlicher Teil der IT‐Strategieableitung. 0.042494 0.119321 -0.086886 0.715277 -0.001038 -0.044658 0.317121 0.111199UAM ist wesentlicher Teil der IT‐Governance. 0.138114 0.199293 0.246463 0.649011 0.100401 0.169442 0.210665 0.029940Ergebnisse 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.385662Ergebnisse des UAM werden genutzt für IT‐Governance 0.413656 0.271562 0.263245 0.431554 0.254310 0.059682 0.004517 -0.161787Ergebnisse 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 153104Ergebnisse des UAM werden genutzt für Operations und Maintenance 0.409120 0.018416 0.295503 0.040941 0.483887 0.018000 0.167212 0.244452Ergebnisse des UAM werden genutzt für Business/IT‐Alignment  0.238235 0.096592 0.107113 0.450093 0.463476 0.142554 0.257626 0.248158Ergebnisse 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.130883Es 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.097980von 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.036255Architekturboards 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.070931Ergebnisse des UAM werden genutzt für Unternehmensentwicklung 0.123951 0.158184 0.260378 0.193434 0.166341 0.095552 0.120478 0.720681 discoveredErgebnisse 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. 11. Phase 1 (Analysis)Steps 4-7 474. 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. 12. Extended Meta Model for Fragment-based SituationalMethod Engineering [Bucher et al., 2007] © Apr-11, IWI-HSG Slide 12
13. 13. Cluster Analysis 3 Clusters discovered © Apr-11, IWI-HSG Slide 13
14. 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. 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. 16. As-is EAM Approach “green”:Passive, IT biasedPassive 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. 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. 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. 19. Phase 2 (Method Derivation)Steps 8-10 8 108. 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