Software Ecosystems: From Software Product Management to Software Platform Management

Transcription

1 Software Eosystems: From Software Produt Management to Software Platform Management Slinger Jansen, Stef Peeters, and Sjaak Brinkkemper Department of Information and Computing Sienes Utreht University, the Netherlands {s.jansen, Abstrat. Presently, it is impossible to use software produt management praties and tools for software platforms that operate in software eosystems. The extensive and mature Software Produt Management Competene Model annot easily be applied in this ontext. In this paper the Software Produt Management Competene Model is ported towards keystone players in software eosystems, to reate the new Software Platform Management Competene Model. If a keystone player implements the apabilities desribed in these new tools, it an manage stakeholders, know and align their interest, and thereby further enable value reation by itself and eosystem members. Keywords: Software Produt Management; Software Eosystems; Keystone; Partners; Direted Approah; Software Platform Management 1 Introdution When software produts grow larger, external parties may wish to extend produts to reate nihe solutions for nihe markets. The produt grows to a platform on whih third parties build extensions, omponents and appliations. Iansiti and Levien (2004) define a platform as a set of standard servies, tools, and/or tehnologies that funtion as resoures for other members. In this ase, the software ompany and its platform provide ore tehnology that funtion as a basis for a Software Eosystem (SECO). Jansen, Finkelstein and Brinkkemper (2009) have defined a SECO as: a set of ators funtioning as a unit and interating with a shared market for software and servies, together with the relationships among them. If a software produing organization is going to manage its produt as a platform it is taking a direted SECO approah. Cusumano (2010) presents several reasons for software ompanies to take a direted SECO approah, suh as when (potential) ustomers ome from a plethora of nihe markets. Due to time onstraints and limited R&D investment budget, satisfying different types of ustomers with software that fit their needs annot be solely done by one keystone software provider. Expanding the produt to a platform on whih externally reated omponents or appliations an be built is an instrument for reating the required nihe funtionality and is a basis for the reation of a SECO. 5

2 Software Produt Management (SPM) plays a key role in produt software organizations in reating suessful produts. Organizing SPM well inreases the quality of the developed produts. Researhers have instantiated many initiatives to improve the ativities with regard to SPM. The results of these studies have led to an approah to organize the management of requirements, releases, produts and portfolio of produts; i.e. a omplete framework with all relevant management praties (van de Weerd, Brinkkemper, Nieuwenhuis, Versendaal, & Bijlsma, 2006). Taking a SECO approah affets how ompanies look at their SPM. Those software ompanies that are able to manage their software platform, relationships and surrounding environment in a suessful manner reate a sustainable and profitable business for themselves and their stakeholders. The urrent SPM framework already ontains praties that take into aount external parties, suh as Monitor Partner Network. The urrent model, however, does not suffiiently aommodate ompanies that take a direted SECO approah, as it laks, for instane, the identifiation of SECO player types, the use of multiple distribution hannels (app stores), and the ertifiation of partners to develop for and on top of the platform. Aording to Bosh (2009) the keystone (i.e. platform developer) an take a SECO approah ranging from direted to undireted. If a keystone takes a direted approah it identifies speialized market segments (i.e. nihe markets) to offer solutions for and ollaborates with third parties to develop domain speifi funtionality. In the undireted approah every external party that wishes to build new funtionality on or with the offered platform an do so without permission of the keystone. This study fouses on SPM for software produing organizations with a direted SECO approah. To determine how SPM with a direted SECO approah (i.e., Software Platform Management) needs to be organized, we investigated the adequay of the instruments of the state of art of SPM, and if it is not, what needs to be hanged. The instruments are: The SPM Competene (SPMC) Model: a framework whih presents an overview of all important areas and praties for SPM (Bekkers, van de Weerd, Spruit, & Brinkkemper, 2010; van de Weerd et al., 2006). The SPM Maturity (SPMM) Matrix (Bekkers & van de Weerd, 2010): a maturity matrix in whih all praties of the SPMC Model are presented in a best pratie order for implementation. The SPMM is not presented in this paper for reasons of brevity. We have found several lues that suggest that the model and matrix are not adequate for appliation in a ompany that is a keystone player. First, partner requirements in SECOs may be of a higher priority than ustomer requirements. While a ustomer only represents the value of one ustomer, partners usually have many ustomers and thus represent a larger possible value for the keystone organization. Seond, it may affet release planning beause the onfigurations of features in new releases have onsequenes for the externally reated omponents. To synhronize releases with partners, the reation of widely aepted release definitions is essential. Third, besides a roadmap for the platform of the keystone organization eah partner may have a roadmap for its solution(s). If the roadmaps in the SECO are not aligned orretly, it an lead to major problems. For example, the vision for the platform 6

3 might not be reonilable with solutions reated by partners. On the other hand, the platform ompany does not want to get in a release stasis as well, in whih it does not dare to innovate its platform. Fourth, the externally built solutions may ompete with other produts built by the organization. These problems and many more may arise when taking a direted SECO approah, whih are explored. The paper ontinues with a desription of how design siene was used for the researh design. Furthermore, interviews and a questionnaire were used to find legitimate andidate hanges for the tools and models. In setion 3 and 4 related literature on the topis of SPM, the SPMC Model, the SPMM Matrix and SECOs is desribed. In setion 5 the results of the study are presented, with an emphasis on the SPMC Model. Setion 6 disusses the results and shows the weaknesses in the researh approah in terms of validity. In Setion 7 is onluded that the SPlaM is future proof and enables keystone players in software eosystems to better manage their platform within the omplete eosystem. Furthermore, future researh topis are suggested that further develop the maturity models in the domain of software platform management. 2 Researh Approah For this study is hosen to use the Design Siene Researh Cyle as desribed by Takeda, Veerkamp, Tomiyama, and Yoshikawa (1990). Five steps are defined that represent the design researh proess. The five steps are: 1) awareness of the problem, 2) suggestion, 3) development, 4) evaluation and 5) onlusion. First, during the step Awareness a relevant problem to ondut a study was found. Seond, during the step Suggestion was suggested what solutions ould possibly solve the stated problems. A literature study on the topis of the SPMC Model, the SPMM Matrix, SPM, SECOs, and ativities related to these researh domains was performed. Fig. 1. Researh steps in the development of the SPlaM. 7

4 The literature study was used as the knowledge base on whih eleven strutured interviews with Duth produt managers were onduted. The interview data were lassified per topi within the SPM and SECOs literature, as to ollet as many fats about speifi SPM praties. The interviews onsisted of an introdution, some generi questions about software platforms and platform management, a deep-dive into the SPM model, and a wrap-up. During the disussions surrounding the SPM model, proposed hanges were doumented arefully. Interviews took an average of 2 hours, mostly beause of the lengthy disussions about the SPM model. Interviews were typially interrupted by a offee break. # Experiene in Table 1. Interviewees and experiene. RM RP PP PM Gained at i1 x x x Ordina, Infra Design, Unisys i2 x x x x PinkRoade i3 x x x x Everest i4 x x NetAspet i5 x x x x ThinkWise i6 x x AFAS Personal, Yunoo i7 x x x x Everest i8 x x ANVA, Cap Gemini i9 x x x x BakBase, SDL Tridion, Pallas Athena, Data Distilleries i10 x x x x Everest i11 x x Everest Sum Third, during the step development the data of the interviews was used to reate an overview of all proposed hanges from literature and from the interview data. This resulted in several pages of proposed hanges, whih were used to reate a draft version of the SPlaM. In those ases where proposed hanges were onfliting, the interviewees were ontated to iron out differenes. Pratially all definitive hanges in the resulting model were made based on what the majority of the produt managers wanted to see hanged. However, some minor and relevant hanges (e.g. expanding the examples in the desription of a SPM ativity) were performed without a majority vote from the software produt managers. Fourth, during the step Evaluation, the previous interviewees were asked to evaluate the new model in a pen-and-paper survey where the researher was present. Eah of the proposed hanges was evaluated. Furthermore, the main evaluation questions were: Whih andidate hanges are not relevant for a direted SECO approah? Whih andidate hanges still require additions or larifiations? Are they made in the right plaes of the SPM model? Whih andidate hanges are still missing in your opinion? 8

5 As the model had been disussed before with the interviewees, the evaluation did not lead to heated disussions. Finally, during Conlusion step, the study is onluded by presenting the study results to the sientifi ommunity. An overview of the interviewees experienes in the different fields an be found in Table 1 and shows an even spread aross the four disiplines in SPM. 3 Software Produt Management The apaity of a software produt to satisfy the needs and expetations of stakeholders determines its quality (Berander, 2007). Therefore Berander (2007) states, a software produing organization needs to gather, selet and plan the right set of features for a produt to find the highest value for all stakeholders. However, SPM overs more responsibilities. SPM onerns the definition of a strategy for, distribution of, launhing of, providing support for, and phasing out of a produt; i.e. all phases of the life-yle of produt software (Ebert, 2007). The same author says about SPM that it assures winning produts by implementing business ases, agreeing on and implementing marketing, reating funtional and tehnial roadmaps, managing produt life-yles, and aligning and optimizing the organization produt portfolio. The SPM Competene Model (Bekkers, van de Weerd, Spruit, & Brinkkemper, 2010; van de Weerd et al., 2006) gives an overview of the key areas of SPM. Its objetive is threefold: aiding software ompanies in organizing and enhaning their SPM, struturing eduation on SPM and struturing researh on SPM. The model onsists of four business funtions: Portfolio management, Produt planning, Release planning and Requirements management. Its struture is hosen beause a software produing organization possesses a portfolio of produts, whih onsists of one or more produts, whih has multiple releases, and a release represent a set of requirements. Development ativities are not part of the model, simply beause it is not part of SPM. Eah business funtion onsists of a highly ohesive group of fous areas, whih in turn represent a group of highly ohesive apabilities (i.e. relevant SPM praties). The external stakeholders are the: market, ustomers, and partners. The internal stakeholders are the (business units): ompany board, sales, marketing, researh & innovation, development, support, and servies. The SPM Maturity (SPMM) Matrix (Bekkers, van de Weerd, Spruit, & Brinkkemper, 2010) is based on the SPM Competene Model; the matrix has the same struture (i.e. the business funtions) and the same omponents (i.e. the fous areas and apabilities). However, the apabilities on whih the fous areas are based are spread in a best pratie order for implementation over several maturity levels. In this way, produt managers and software organizations an determine how mature their SPM organization is (i.e. the level orresponding to their apabilities) and what the areas of improvement are (i.e. the missing apabilities orresponding to the desired level). 9

6 4 Software Eosystems The term Software Eosystems (Jansen et al., 2013) and their underlying theory are based on biologial eosystems. The biologial eosystem is the result of the interations between its members and the physial environment (Dhungana, Groher, Shludermann, & Biffl, 2010). SECOs involve the organization of its members (i.e. software vendors, third-party developers, suppliers and users) and its platform (J. Bosh, 2009). Taking a direted SECO approah implies that the platform developer takes a ommunity perspetive, in whih internal and external stakeholders are taken into aount (Friker, 2010). A well-known example of a suessful eosystem is Apple with its Appstore. The large quantity and quality of the produt software (apps) offered in this store ould not be devised and produed by Apple on its own. The suess of this and other eosystems lie in the opportunity for a large set of developers to use the platform to reate and distribute software. Two key types of members in SECO literature are reurring (van der Shuur, Jansen, & Brinkkemper, 2011); the keystone and the nihe players. Iansiti and Levien (2004) state the keystone is: a benevolent hub in the network that provides benefits to the eosystem and its members. They say it typially gives other members (i.e. nihe players) the neessary spae to grow and prosper and nihe players (i.e. the other members of the network) do not try to ompete with the keystone. They leverage the resoures of the network to reate solutions whih are targeted at nihe markets (i.e. speialized segments of the market). Thus, the keystone reates and delivers a keystone produt (i.e. the platform) and surrounding servies, whih enable nihe players to reate and deliver nihe solutions. 5 Software Platform Management Many authors use the term platform when they talk about the keystone its produt (and surrounding servies) that is provided to enable other members to reate value (e.g. in Geir K., 2011; Iansiti & Levien, 2004; Iyer, Lee, & Venkatraman, 2006; Kilamo, Hammouda, Mikkonen, & Aaltonen, 2012). The keystone opens its produt to external entities to reate a platform by whih business and SECO objetives an be reahed. Thus, management needs to be fous on how the keystone and other members of the SECO an reate value. Kittlaus and Clough (2009) named this approah platform planning. Companies that ondut suessful platform planning will realize several benefits (Robertson and Ulrih, 1998), they will: have a greater ability to reate nihe produts for nihe markets or ustomers; lower the osts to reah nihe markets or ustomers; reate nihe produts that more losely meet the needs of them. We define platform management as onsisting of four proesses: Portfolio management, Produt planning, Release planning, and Requirements management. Sine 10

7 these platform planning proesses are similar to those in the SPM framework, the framework under development is alled the Software Platform Management (SPlaM) framework. 5.1 Candidate Changes Based on the literature andidate hanges for the SPMC Model are defined, lassified in the following topi groups: foster the sharing of resoures, manage the involvement of partners, manage the ommuniation of requirements, raise the quality by means of ertifiation, initiate and manage (new) partner relationships, reate a healthy SECO produt portfolio, and initiate and manage (new) SECO (sales and distribution) hannels. A large number of andidate hanges were identified. For example, based on literature on the topi of foster the sharing of resoures, a andidate hange is made: the identifiation of ore assets proess is expanded to inlude ore assets reated by third parties as well (see Table 2). Imagine, for instane, the role of the Faebook appliation on the iphone, whih an be onsidered a ore asset in the iphone eosystem, even though it was not released and developed by Apple. Table 2. Candidate hange ore asset identifiation. fous area andidate hange proessed as Core asset Common omponents/funtionality (ore assets) Expand apability b. Core roadmapping is systematially identified among the eosystem s produts and deliverables surrounding these produts. asset identifiation with this andidate hange or add it as a new apability. 5.2 SPlaM: The New Model As explained earlier the urrent model and matrix onsists of four business funtions: Requirements management, Release planning, Produt planning and Portfolio management. No (new) business funtions are added or removed. Although the high level business funtions are not hanged, new fous areas and apabilities are added and existing fous areas and apabilities are hanged. The following tables (Table and Table ) desribe what hanges were made to the model. In the part olumn is desribed what is hanged; it an be the name of a new or hanged apability or the desription of a fous area. In the /n olumn is desribed if it is a new (i.e. n ) or hanged (i.e. ) apability or fous area. For the sake of brevity unhanged apabilities, unhanged fous areas and (hanging) maturity levels are not presented. For more information on the unhanged apabilities and fous areas, please see Bekkers and van de Weerd (2010). All hanges made to (the desription of the) fous areas are based on the hanges made with regard to new and hanged apabilities. A final remark has to be made about the Partnering & ontrating fous area of the urrent SPMC Model. Due to the fat that nine new apabilities are added to it, it is split up into three new fous areas. The three new fous areas are Contrating, Partnering and Channel development. Three of the five apabilities of the old Partnering & ontrating fous area are unhanged and therefore not desribed in the 11

8 following tables. The unhanged apability Intelletual property management is added to the Contrating fous area and the unhanged apabilities Establish and evaluate priing model and Investigate distribution hannels are added to the Channel development fous area. The interviewees mentioned several interesting observations while proposing hanges to the SPMC model. One speifi aspet that was frequently disussed is partner trust: There exists a signifiant danger in opening up the requirements database to anyone. Furthermore, it was added that the type of aess is relevant: Even if you intensely ollaborate with partners, you don t want them to be able to delete requirements from your database.. Also, trust does not only play a role between the organization and its partners, but also partners among themselves: It s utopian to think that partners will not ompete amongst themselves. You an try all you want, there is always ompetition and you do not want to be an arbiter in an endless fight. Another aspet mentioned frequently is transpareny: Sometimes you don t even know your ustomer base is interested in a speifi feature until one proposes it and others get to omment on the feature. Sometimes the ustomers themselves don t even know until they see the idea from another ustomer. The most positively evaluated addition to the SPMC model is the ertifiation of partners: It provides stakeholders with an unmathed transpareny. Customers will know that this is a trusted party and that their extensions are at least ok d by us. Certifiation is also seen as a marketing tool: Partners an go through several phases: from unknown to registered to ertified to preferred. They an even use this for marketing purposes, every promotion is a sign that the partner is a little higher on the ladder to partnerhood. 12

9 Table 3. Part one of the performed hanges table. fous area part /n desription Requirements gathering [desription] Expanded with the sharing of requirements with relevant and authorized external stakeholders. Opening entral database n The entral database with inoming requirements is opened for relevant and authorized external stakeholders. It must foster the sharing of resoures between SECO members. Requirements identifiation Requirements organization Requirements prioritization Release definition Release definition validation Roadmap intelligene Core asset roadmapping Produt roadmapping Stakeholder involvement Requirements ommuniation flows External feedbak n A ombination of three pre-existing apabilities; i.e. the Internal stakeholder involvement, Customer involvement and Partner involvement apabilities. In it all relevant internal and external stakeholders are involved by gathering their requirements. Plus, per produt or release is determined whih stakeholder involvement is most important. Leading to the involvement of the right stakeholders. The requirements ommuniation networks are modeled and analyzed to determine the proper ommuniation tatis for requirements. n Extra feedbak on produt requirements is gathered from external stakeholders. It raises the quality of produt requirements by enrihing its ontent. [desription] Expanded with sharing the gathered requirements with all relevant internal and external stakeholders. Requirement organization Opening requirements history log n Requirements are organized on shared aspets and requirements for externally build produts are reognized and ommuniated to the speifi external developer (i.e. partner). In this way, partners get all the relevant information they need to improve their nihe solutions. Make the history log aessible to relevant and authorized external stakeholders. Requirements will be reusable for other external projets and thereby fosters the sharing of resoures within the SECO. [desription] The prioritization of requirements is only performed by relevant stakeholders. Internal stakeholder involvement Still all relevant internal stakeholders indiate the requirements that should be inorporated in future releases. However, for eah stakeholder is determined how important their involvement for the produt is. External stakeholder involvement A ombination of two pre-existing apabilities; i.e. the Customer involvement and Partner involvement apabilities. In it, all relevant external stakeholders are involved by prioritizing the requirements and per produt is determined whih stakeholder its involvement is most important. Leading to the inorporation of the right requirements. Communiation The original Internal ommuniation apability is expanded with external ommuniation (i.e. ommuniating the release definition to external stakeholders as well). Now, partners will know what will be developed and they an prepare and/or improve their nihe solutions based on the new or hanged features. [desription] Expanded with external parties. External validation n The release definition is heked by external stakeholders as well. It reates a better alignment with externally reated produts, inreases its quality, and generates awareness among the external stakeholders. Legislation n Continuously an overview needs to be reated with regard to hanging legislation for the organization its produt industry in order to keep ompliant with laws and regulations. [desription] Widened to the whole SECO. SECO ore asset identifiation Make, buy or o-reation deision Theme identifiation The original Core asset identifiation apability is expanded to all produts reated in the SECO. Core assets are systematially identified among and surrounding the deliverables of SECO s produts, beause it inreases and simplifies the reuse and maintenane of SECO its ore assets. The original Make or buy deision apability is expanded with o-reation deisions. A proess needs to be in plae to atively investigate make, buy or oreation deisions, beause osts an be redued and time an be saved by using and/or o-reate with external parties. Release themes are identified and maintained together with relevant internal and external stakeholders for internal and external reation. It is expanded with external stakeholders, themes and reation, beause external parties (i.e. partners) are going to develop the new value in a SECO. Consultation The original Internal onsultation apability is expanded to external stakeholders. Relevant internal and external stakeholders are onsulted for the reation of a produt roadmap. To have SECO wide aeptane of the produt roadmap, to use the knowledge of all relevant members and to reate riher and more realisti produt roadmaps. Long-term roadmap Roadmap proedure n A long-term roadmap is reated that spans a time period of maximum two years. The time span is shortened, beause the software industry is hanging so fast it is not possible to reate valuable roadmaps that span more than two years. A deision proedure has to be defined to make partners aware what will happen if no onsensus is reah between the keystone and them in the future plans for the platform. 13

10 Market analysis Market trend identifiation SECO ustomer win/loss analysis Table 4. Part two of the performed hanges table. There is an ative searh for market opportunities to expand existing or reate new produts for, by doing market researh at all kinds of plaes (e.g. related markets and visiting onferenes). It is expanded by adding market researh via the use of information gathered from partners, beause in SECOs the keystone losely ollaborates with the partners. The original Customer win/loss analysis apability is expanded to all produts in the eosystem. A win/loss analysis is performed to determine why ustomers (of partners) did or did not hoose to buy SECO produts (i.e. the sales proess is reviewed). To learn more about how to generate more ustomers by tuning the development of the platform. Contrating [desription] n Fouses on establishing relations with external stakeholders by reating proper and lear agreements with them. Servie level agreements SLAs are set up for ustomers and partners. It is expanded to partners sine they will ask for speifi servies on whih agreement have to be made. Contrat negotiation proess n A ontrat negotiation proess is set up in whih (e.g.) realisti objetives, agreements on earnings, intelletual property rights, termination lauses, penalties for bad performane and arbitration proedure are determined. Determine information profiles n Information profiles are determined for eah (type of) partner(s) (aording to their role), it makes lear whih partner has aess to whih information to simplify the sharing of information. Partnering [desription] n Fouses on managing relations with external stakeholders and supporting them in reating the biggest possible value for the eosystem. Channel development Produt lifeyle management Register partners Set up partner network Cluster partners Coordinate partner allianes Partner performane analysis n n n All partners are registered in a entral database whih all (relevant) internal stakeholders an aess, to reate an overview of all partners and share knowledge (e.g. best praties and experienes) with regard to the partners. The original Monitored partner network apability is split up in this apability and the new apability Partner performane analysis. Partner networks and/or portals are used to regulate and promote partnering. Partners are lustered into groups with speifi goals, funtions, etetera to simplify the management of them. Partner(s) (allianes) are oordinated to avoid onflits and to foster synergy to reate a stronger and more oherent SECO. The original Monitored partner network apability is split up in this apability and the new apability Set up partner network. A partner analysis is performed on an organizational level to analyze what partners have to offer, what their strengths and weaknesses are, and are going to offer. To reate a lear and orret piture of the performane of partners whih is the basis on whih deisions an be made about maintaining or ending partner relations. Certify partner n Partners are ertified divided over different ranks with different obligations and privileges to make lear what is expeted to raise quality. Certify external omponents n Certify external reated omponents on standard quality rules to raise the quality of nihe solutions. [desription] n Fouses on establishing and managing distribution hannels. Common n Set up a ommon delivery hannel (e.g. the Apple Appstore) to enable partners to delivery sell their produts to a large ustomer base. It makes the SECO more attrative for hannel new partners and ustomers. Model the SECO n Model the SECO at its different levels (e.g. within and between SECOs) to identify distribution hannels, main ompetitors and potential partners. [desription] n Widened to the entire SECO SECO produt The original Produt lifeyle analysis apability is expanded to the whole eosystem lifeyle and by using information from external stakeholders as well. At least one per analysis year the urrent life phase of eah produt in the SECO is determined based on tehnial and finanial aspets. Plus, information is gathered from internal and external stakeholders. It is important to determine if the keystone still want to support the reation of ertain nihe solutions and therefore external stakeholders have to provide information on externally reated produts. SECO portfolio sope analysis The sope of the original Portfolio sope analysis apability is widened to all produts in the SECO. A produt sope analysis is performed to identify overlaps and gaps between the produts in the whole SECO, beause it is important to reate a healthy (i.e. diverse) SECO produt portfolio. 14

11 Fig. 2. The Software Platform Management Competene (SPlaM) Model. In Fig. 2 the SPlaM Model is presented. The only hanges that are visible in this figure are the three new fous area Contrating, Partnering and Channel development. The three fous areas are a substitution of the Partnering & ontrating fous area in the old model. Per fous area is indiated if hanges are made with regard to its desription, new apabilities, hanged apabilities and maturity levels. First, at the upper left orner is indiated in orange with the letter D if its desription is hanged. Seond, at the upper right orner is indiated in blue how many new apabilities are add to it. Third, at the lower left orner is indiated in green how many apabilities 15

12 are hanged. Fourth, at the lower right orner is indiated in yellow if maturity levels of apabilities are hanged. 6 Disussion To solve validity issues, tatis with regard to ontent validity were studying the instruments of the state of the art of SPM (i.e. the SPMC Model and SPMM Matrix), performing a literature study on the topis of SPM, SECOs, and ativities related to these researh domains, to now every relevant faet of the objet under study. Tatis with regard to onstrut validity were using strutured predefined approahes in whih no room for own interpretations was possible during the gathering and analysis of the data. To ensure the produt managers knew if and how they had to make hanges, an introdution on the model, SECOs and the researh objetive was given with an introdution that was read to eah interviewee. Tatis with regard to external validity are the use of multiple produt managers from multiple ompanies as the developers and validators of the new model. A redution of external validity results from the fat that only Duth produt managers are used as developers and validators. Thus, the question remains if the result of this study is generalizable to other ountries and/or ultures. Fourth, the result is reliable beause for every ativity a predefined and strutured approah is used. Thus, if this study were to be repliated, we expet it to lead to the same output. During the interviews some of the produt managers questioned whether there should be so muh emphasis on the management of partner relationships within SPlaM. They indiated partnering ativities are more appropriate at a partner management department. We have hosen to inlude these ativities for the following reasons. First, other produt managers did add new apabilities in regards to partnering ativities. Furthermore, the urrent model already ontains partner management apabilities. Thirdly, partners of keystone organizations with a direted SECO approah add value and knowledge to the eosystem. Thus, a produt manager needs to be deeply involved in partner management ativities. Also, Friker (2010) states: Software produt management establishes and maintains a software eosystem by managing stakeholders and studying and aligning their interests. Bekkers, van de Weerd, Spruit and Brinkkemper (2010) also indiate that the produt manager is loated at the enter of the ompany; from its position she needs to keep ontat with every relevant stakeholder to ollaboratively reah goals derived from (business) strategy. Finally, Ebert (2007) desribes that the produt manager needs to find a balane between the needs and wishes of external entities (i.e. ustomer, markets and stakeholders) and guide them in the right diretion. 7 Conlusion and future researh The interviews resulted in fourteen new apabilities, sixteen hanged apabilities, nine fous areas with hanged maturity levels and nine fous areas with hanged de- 16

13 sriptions. During the interview analysis, a seletion was made of hanges suggested by two or more produt managers. These hanges are presented to and assessed by the produt managers by means of the questionnaire. The questionnaire resulted in two new apabilities, three hanged apabilities and one fous area with hanged maturity levels. The new, hanged and unhanged apabilities and fous areas desribe how keystone software organizations should organize their SPlaM praties with a direted approah. Thus, a Software Platform Management Competene (SPlaMC) is developed and validated. The limitations of this study an be the initiation for further researh. First, new studies ould fous on what the relevant SPlaM praties are for software vendors that take an undireted SECO approah. Seond, future researh ould fous on the matrix speifi maturity levels and prerequisites of apabilities of the SPlaMM Matrix. Referenes Bekkers, W., & van de Weerd, I. (2010). SPM maturity matrix (UU-CS ). Utreht: Utreht University. Bekkers, W., van de Weerd, I., Spruit, M., & Brinkkemper, S. (2010). A framework for proess improvement in software produt management. In A. Riel, R. O Connor, S. Tihkiewith & R. Messnarz (Eds.), Systems, Software and Servies Proess Improvement (pp. 1-12). Berlin Heidelberg: Springer. Berander, P. (2007). Evolving prioritization for software produt management. Blekinge: Blekinge Institute of Tehnology Dotoral Dissertation Series. Bosh, J. (2009). From software produt lines to software eosystems. Proeedings of the 13th International Software Produt Line Conferene, San Franiso, CA, USA, Cusumano, M. A. (2010). Staying Power: Six Enduring Priniples for Managing Strategy and Innovation in an Unertain World. Oxford University Press, USA Dhungana, D., Groher, I., Shludermann, E., & Biffl, S. (2010). Software eosystems vs. natural eosystems: Learning from the ingenious mind of nature. Proeedings of the 4th European Conferene on Software Arhiteture, Copenhagen, Denmark Ebert, C. (2007). The impats of software produt management. Journal of Systems and Software, 80(6), Friker, S. (2010). Requirements value hains: Stakeholder management and requirements engineering in software eosystems. In R. Wieringa, & A. Persson (Eds.), Requirements Engineering: Foundation for Software Quality (pp ). Berlin Heidelberg: Springer. Geir K., H. (2011). A longitudinal ase study of an emerging software eosystem: Impliations for pratie and theory. Journal of Systems and Software, 85(7), Iansiti, M., & Levien, R. (2004a). The keystone advantage. Boston: Harvard Business Shool Press. Iyer, B., Lee, C. H., & Venkatraman, N. (2006). Managing in a small world eosystem: Some lessons from the software setor. California Management Review, 48(3), Jansen, S., Finkelstein, A., & Brinkkemper, S. (2009). Business network management survival strategy: A tale of two software eosystems. Proeedings of the 1st Workshop on Software Eosystems, Falls Churh, Virginia, USA, Jansen, S., Cusumano, M., Brinkkemper, S. (2013) Software Eosystems: Analyzing and Managing Business Networks in the Software Industry. Edward Elgar Publishers, 350 pages. 17

14 Kilamo, T., Hammouda, I., Mikkonen, T., & Aaltonen, T. (2012). From proprietary to open soure Growing an open soure eosystem. Journal of Systems and Software, 85(7), Kittlaus, H. B., & Clough, P. N. (2009). Software produt management and priing: Key suess fators for software organizations, Berlin Heidelberg: Springer. Robertson, D., & Ulrih, K. (1998). Planning for produt platforms. Sloan Management Review, 39(4), Shuur, H. W. v. d., Jansen, R. L., & Brinkkemper, S. (2011). The power of propagation: On the role of software operation knowledge within software eosystems, Proeedings of the International Conferene on Management of Emergent Digital EoSystems, San Franiso, CA, USA, Takeda, H., Veerkamp, P., Tomiyama, T., & Yoshikawa, H. (1990). Modeling design proesses. AI Magazine, 11(4), van de Weerd, I., Brinkkemper, S., Nieuwenhuis, R., Versendaal, J., & Bijlsma, L. (2006). Towards a referene framework for software produt management. Proeedings of the 14th IEEE International Requirements Engineering Conferene, Minneapolis/St. Paul, MA, USA,