5. Method Engineering Source: Karlsson, F.: Meta-Method for Method Configuration - A Rational Unified Process Case. Linköping University, : Linköping (2002)
6. Exisiting Service Identification Approaches following Börner, R. and Goeken, M. (2009) Identification of Business Services, 15th AMCIS, San Francisco, California, Paper 162 -- not existent - only implicitly o mentioned + defined/used ++ special focus -- - o -- -- - Configurability ++ + ++ + ++ + Results + - ++ + o + Techniques o -- o -- -- -- Roles ++ + ++ ++ ++ ++ Activities Kohlborn et al. (2009) Kohlmann & Alt (2007) Arsanjani et al. (2008) Winkler (2007) Böhmann & Krcmar (2005) Klose et al. (2007)
10. Assigning Methods to Situations following Bucher, T., Klesse, M., Kurpjuweit, S. and Winter, R. (2007), Situational Method Engineering - On the Differentiation of "Context" and "Project Type", in Jolita Ralyté, Sjaak Brinkkemper and Brian Henderson-Sellers (Eds.) IFIP Working Conference, Springer, Boston.
11.
12. Situations – Context Variables (Excerpt) 5.2 SIMM level 4-7 5.1 SIMM level 1-3 5 SOA maturity level 4.4 None available 4.3 Both skills available 4.2 BPM skills available 4.1 SOA skills available 4 Skills and experience 3.2 Low budget 3.1 Generous funding 3 Budget 2.3 Internal and external consumers 2.2 External consumer 2.1 Internal consumer 2 Service consumers 1.2 Large company 1.1 Small or medium-sized enterprise 1 Company size Parameter Value Context Variable
13. Situations – SOA Implementation Goals Provision of services for third parties Standardization Agility and flexibility of business processes Identification of outsourcing candidates Integration of legacy systems SOA Implementation Goals
18. Further research – Method fragments Fragment 16: Breaking Down Business Processes Fragment 15: Composition of Basic Services Fragment 14: Strategic Stakeholder Integration Fragment 13: Goal Service Modeling Fragment 12: Feasibility Check Fragment 11: Analyzing and Improving Reusability of Services (or Candidates) Fragment 10: Developing Reutilization Scenarios Fragment 9: Identifying Business Processes Fragment 8: IT Governance Analysis Fragment 7: Prioritization of Funding Fragment 6: Develop Key Performance Indicators Fragment 5: Compiling Service Candidates Fragment 4: Identifying Activities Fragment 3: Identifying Stakeholders Fragment 2: Asset Analysis Fragment 1: Overview of Existing Process Models Fragments
Title is Towards Construction of Situational Methods for Service Identification So at first short introduction into service identification
First: Service Identification SOA promotes implementation of services that represent business functionality Service Identification very important part of SOA implementation and in service lifecycle Interestingly, most existing methods to identify services are based on a one-fits-all approach
in order to analyze existing methods we looked for elements from meta models there are numerous models for example by Gutzwiller, Karlsson, St. Gallen (Brinkkemper) exemplarily Karlssons approach most commonly used elements of ME: Activities, Roles, Techniques, Results, Sequence of Activities
We used these elements to compare existing approaches in earlier work No approach deals with roles, only arsanjani et al. and Kohlborn et al. hint at roles but don‘t describe any in detail Only few consider a configuration of methods depending on different circumstances such as the goal of an SOA implementation. Even if the latter are considered, the scope of configurations is usually very limited. To overcome this shortcoming of existing approaches we utilize Situational Method Engineering SME advocates adaptable methods configurable depending on a situation at hand to achieve this, method fragments are used that have the same constituing elements
One more than in paper: Kohlborn et al. (2009)
goal of this paper was to set the foundations for a meta method that helps to engineer situational methods for service identification two pillars or main ingredients of such a method are the situations on one hand and the method fragments on the other hand
to identify situation, I use situation identification matrix input 1: SOA implementation goal input 2: Context Parameter Value Combination (CPVC) since there are many variables and parameter values respectively, we need the combination (CPVC) as input for matrix example of parameter values
finally, methods are assigned to one or more situations context-independent methods (1) goal-spanning-methods (6,2) 1:1 relations
First, we need situations relevant in the context of service identification we conducted two explorative case studies implementation of a service-oriented architecture at Suncorp, an Australian Insurance company software development project at SIRCA a provides of financial market data This is an excerpt of the list you can find in the paper
The second constituting part of situations are SOA impl goals we found the following goals to be important and to have an influence on service identification methods so we have all we need to identify situations in the context of service identification
the second pillar of the model are method fragments to derive these fragments by decomposition and exploration we used existing literature and the experience from our case studies this is one example for such a fragment taken from the paper
to 1) list might not be complete, i.e. important factors might not be included proof of the actual impact is weak for at least some variables and has to be improved through more empirical evidence expert interviews and case studies or action research to 2) Using the 9 context variables, their respective parameter values leads to 3,456 context parameter value combinations. Multiplied by 5 implementation goals leads to 17,280 situations in the Situation Identification Matrix. to 3) The more situations you have the more likely is a big similarity of situations that can be covered by one method. The number of context variables and parameter values should be controlled in early stages (e.g. Do we need 2,3 or 5 different company sizes?) to 4) maybe most difficult. What fragments are available and what are rules to combine these fragments? development of best practices for method fragments within certain industries? a method fragment could be marginally, fairly or highly relevant in a situation at hand
in order to proof applicability of the meta method, we applied it to an IT provider located in Frankfurt. This company called Efiport e.g. provides a Campus & Learning Management System (CLM). It wanted to analyze its software as to check if there is a possibility to introduce a service-oriented architecture in Efiport. Using our criteria, we firstly identified the situation based on context factors (as shown on slide) and SOA impl goal which was standardization in efiport‘s case
furthermore, we identified 16 fragments that we deem to be relevant for service identification all these fragments are described with necessary inputs and certain preconditions thus, their combination is not arbitrary
finally, based the situation and considering preconditions for the use of fragments, a situational method for efiport‘s case has been engineered. at efiport, it was the primary goal for us to show that our meta method can be used to engineer one concrete situational method
for efiport itself this had no special value. therefore we continued our efforts and used this concrete method to actually identify service candidates in the CLM system that might be transferred into services that can be reused in an SOA. at the moment, efiport is still considering to replace its monolithic system by an SOA