Embed Size (px)
Citation preview
Thesis Overview!!29th of August!
Research Objective !
• City of Rotterdam!
• Ruggedised!
• Sharing data!
• Digital city platform!
• Objective: to onboard as many developers as possible !!!
23/06/2017! Daniël Rustenburg ! 2 !
Academic Context!
• Tiwana’s theory on platform ecosystems!
• Architecture and Governance of a platform!
• Focus on APIs !
• RQ: “How does the architecture and governance of an
API platform strategy affect the performance of a platform
ecosystem for digital cities?“ !!
23/06/2017! Daniël Rustenburg ! 3 !
Conceptual Model!
23/06/2017! Daniël Rustenburg ! 4 !
Figure 3: Conceptual Model
18
Data and Methods !
• Multiple case study analysis!
• Within-case analysis !
• Cross-case analysis!
• NCA analysis!!
23/06/2017! Daniël Rustenburg ! 5 !
Table 1: Selected Cases
Case Interviewee Function
Civity Niek Arends Platform DeveloperCity of Ghent Thimo Thoeye Data ManagerCity of Zwolle Wilfred Knol Advisor Geo-InformationCity of Zwolle Harm Russcher Functional Manager GeoKamer van Koophandel Richard Blokhuijs Product ManagerCity of Amsterdam Eelke de Jager Data AnalystCity of Arnhem Walter Bolwerk Sr. Advisor Business IntelligenceCity of Arnhem Alet Loijenga Advisor functional management GeoSportlink Peter Spiering Platform Service Desk EmployeeBeeld en Geluid Maarten Brinkerink Knowledge and Innovation DepartmentPostNL Bas Belder Applicatie ConsultantMonotch Menno Malta Director
partners related to the Ruggedised/Digital City project, such as KPN, also helpunderstand the empirical surrounding of the aim of this thesis.
As stated in section 1.1.6, it is beyond the scope of this thesis to incorporate allpossible attributes of an API in depth. It would be a shame, however, if recom-mendations regarding APIs outside the spotlight of the case study variablesare neglected. If such suggestions arise, they might still be conveyed in thisresearch in the implications for practice section of the conclusion.
4.7 Data Collection
4.7.1 Triangulation
The concept of triangulation is applied in this research, because this thesis takesmultiple cases into account to describe a certain phenomenon. Triangulationholds that multiple cases are used to measure the repeatability of the researchand hence adhere to the construct validity (Pare, 2004, p.247-248). However,the use of multiple cases also leads to multiple perspectives and sources ofdata that, when combined, explain a certain event. As stated in section 4.1, thisthesis adheres to triangulation by using multiple cases to answer the researchquestion, but also by using different sources of data. For example, next to in-terviews held with employees of organizations used as case studies, informa-tion obtained via desk research is taken into account. Lastly, interviews consistof open questions and closed questions, leading to triangulation of differentmethods (Denzin, 1973).
22
Proposition 1!
23/06/2017 ! Daniël Rustenburg ! 6 !
6.2 Reflection on Propositions
6.2.1 Granularity
Proposition 1: The use of fine-grained APIs attracts most developers, and hence im-proves the performance of the platform ecosystem of digital cities.
Table 13: Empirical Evidence on Proposition 1
Coarse Gran. Medium Gran. Fine Gran.High Perf. Sportlink Amsterdam,
MonotchGhent, KvK, PostNL
Med. Perf. Beeld & Geluid
Low Perf. Civity Arnhem Zwolle
Observation Table 13 show the cells that are in line with the proposition.As one can observe, four out of six cases support the proposition, leaving thefindings with a medium level out of the analysis. Moreover, in figure 5, thepositive relation between granularity and platform performance is reflected inthe OLS line. Therefore, the first proposition holds true: fine-grained APIs doindeed seem to have a positive impact on the performance of the platform.
As stated in chapter 4, an NCA analysis can determine whether the high levelof a variable is a necessary condition or not. As can be seen in figure 5 andin table 13, there is no empty space in the upper left table. This means thereis no ceiling zone, and hence the effect size is 0. It can therefore be concludedthat granularity is nor a necessary nor a sufficient condition for a platform tobe successful, as one can observe that it is possible to have a coarse API and ahigh performing platform, which is the case for Sportlink.
Interpretation It seems that in general, a higher level of granularity increasesthe probability of high platform performance. Almost all cases show that theservice intended and the corresponding width of the product range is of greatimportance for the chosen level of granularity on APIs. If the width of the prod-uct range is small and the intended service provided is relatively uncompli-cated, there often is no need for granular APIs. Moreover, one can argue thata broader product range implicates that the platform has more to offer to thedeveloper, and hence the width of the product range influences the granularityand the platform performance. For example, the high performance of the plat-form of PostNL and Monotch is likely to be caused by the width of their pro-vided products, amongst other factors. Next, the intended service is important
61
Figure 5: NCA Analysis on Proposition 1
for the granularity of APIs. As can be seen in the cases of Arnhem, Amsterdam,Beeld en Geluid, PostNL and Monotch, sometimes the service provided to thecustomers is the most useful for customers when particular datasets that flowthrough the APIs are integrated with each other because in that case, the wholeis greater than the sum of its parts, and for other services the opposite holds.Moreover, as one can imagine, the actual service of that is offered via the APIis of great importance for the performance of a platform: even when a plat-form has perfect architecture and governance, if no useful data flows throughits APIs, the performance in terms of applications will be lower. This leads tothe following finding:
Finding 1: The width of the product range and the intended service provided influencethe level of granularity, which all affects platform performance.
Moreover, for the cases of the City of Zwolle and PostNL, the platform man-agers stated that these granular APIs enable the platform manager and the userto get an uncluttered view on the APIs, which makes it easier in terms of main-
62
Proposition 2!
23/06/2017! Daniël Rustenburg ! 7 !
tenance or when migrating towards a new version of the platform. If one APIneeds to be changed, then all other APIs can still be up and running. Based onthese notions, the second finding can be presented:
Finding 2: Granular APIs positively influence the resilience and hence performanceof the platform, as platform managers can easily manage the APIs when it comes tomaintenance or other changes regarding the APIs.
6.2.2 Gatekeeping
Proposition 2: A higher level of gatekeeping leads to lower platform performance forplatform ecosystems of digital cities.
Table 14: Empirical Evidence on Proposition 2
Low Gatekeeping Med. Gatekeeping High GatekeepingHigh Perf. Amsterdam, Ghent KvK Sportlink, PostNL,
MonotchMed. Perf. Beeld & Geluid
Low Perf. Zwolle, Civity, Arn-hem
Observation As one can observe in table 14, two out of eight cases supportthe proposition, not taking variables with medium levels into account. More-over, in figure 6, a positive relation between gatekeeping and platform perfor-mance is reflected in the OLS line. Therefore, the second proposition is rejected:It is likely that a higher amount of gatekeeping leads to a positive impact onthe performance of the platform.
By performing a NCA analysis, we can observe whether high gatekeeping isthen a necessary condition to achieve high platform performance. Similar togranularity, high gatekeeping is not necessary to achieve high performance,as the top left cell in table 14 is not empty because of the high performingplatforms of the City of Amsterdam and the City of Ghent that do have a lowlevel of gatekeeping. This can also be observed in figure 6, as there is no ceilingline visible. This means that the ceiling zone is equal to zero, which leads to aneffect size of zero as well. Therefore, it can be stated that although there seemsto be a relation between gatekeeping and platform performance, gatekeepingis nor a necessary condition nor a sufficient condition to reach high platformperformance.
63Figure 6: NCA Analysis on Proposition 2
Interpretation In the previous paragraph, it is stated that a higher level ofgatekeeping leads to higher platform performance. Gatekeeping could indi-rectly have a positive influence on platform performance, which finding sixpresents later on. In all cases, it came forward that the chosen level of gatekeep-ing has to do with the overall objective of the platform. For companies such asSportlink, Monotch, PostNL and the KvK, one can assume that the (main) ob-jective of the platform is to be as profitable as possible. They will therefore notopenly publish their data without taking necessary predefined criteria in ac-count, based on which developers are granted access to the platform. For allother cases, it is the objective to provide data that is open for everyone, be-cause this data can improve the quality of life of the society, as innovative andefficient solutions can arise based on this data. Therefore, these cases have arelatively low level of gatekeeping. As stated above, in some cases, predefinedcriteria are necessary for a platform to achieve their objective, but from almostall cases it comes forward that although these necessary conditions exist, be-sides these conditions it should be as easy as possible for developers to join theplatform when it comes to gatekeeping. From this, the following finding can
64
Proposition 3!
23/06/2017!!
Daniël Rustenburg ! 8 !
Figure 7: NCA Analysis on Proposition 3
the platform manager and the developer, which naturally improves the overallcontact between the platform manager and the developer. Vice versa, we haveseen that many times the relational control is low for open platforms, becausedevelopers do not need to contact the platform managers prior to using theplatform, and hence platform managers do not even know who uses the plat-form. Gatekeeping is not a necessary condition for communication and hencerelational control. It is namely evident from the cases of Ghent and Amster-dam that organizing hackathons and other events on a regular basis helps toestablish this interaction, even when gatekeeping is absent. However, a relationbetween gatekeeping, communication and relational control can be discerned.Therefore, the final finding holds:
Finding 6: Communication between the platform manager and the developer posi-tively influences relational control, and gatekeeping positively influences this commu-nication, as it establishes initial contact.
67
Table 15: Empirical Evidence on Proposition 3
Low Rel. Control Med. Rel. Control High Rel. ControlHigh Perf. KvK, PostNL Amsterdam, Ghent,
Sportlink, MonotchMed Perf. Beeld & Geluid
Low Perf. Zwolle, Civity, Arn-hem
trol is then a necessary condition to achieve high platform performance. Dif-ferent to granularity and gatekeeping, high relational control is necessary toachieve high performance, as the top left cell in table 15 is empty. This can alsobe observed in figure 7, as there is a ceiling line visible. The ceiling zone is equalto one and the scope is equal to four, which leads to an effect size of .25. There-fore, relational control is a necessary condition but not a sufficient condition toreach high platform performance.
Interpretation As stated in the previous paragraph, we see that when thelevel of relational control is high, it is likely that the performance of the plat-form is high, and that it can even be regarded as a necessary condition. Al-though there is literature that describes that a lower control leads to higherplatform performance, one could argue that higher relational control leads to ahigher level of collaboration between the platform managers and the develop-ers which is in line with the notions of Tiwana (2014) as stated in 3.4.4. Next,relational control is also connected to privacy similar to gatekeeping, albeit to alesser extent. Multiple cases that were scrutinized showed that a more intenserelation with the developer is appreciated to ensure that the privacy-sensitivedata is handled properly. Set aside the exceptions that we have seen betweenthe relationship between privacy and gatekeeping already, Beeld en Geluid enthe City of Arnhem find the extensive gatekeeping process to grant access toprivacy-sensitive data sufficient, and in general privacy-sensitive data is nevershared with other parties. Therefore, the following finding can be presented:
Finding 5: Relational control leads to a higher amount of interaction and collabora-tion between the platform manager and the developer, which ultimately leads to higherplatform performance.
Another pattern that can be observed when comparing the cases, is that theinteraction or contact between the platform manager and the developer is ofkey importance for relational control, as the interaction is a fundamental con-cept for relational control to exist. An unanticipated finding that arises whenone compares the cases, is that gatekeeping and communication are related toeach other, as the process of gatekeeping often leads to initial contact between
66
Revised Conceptual Model!
23/06/2017!!
Daniël Rustenburg ! 9 !
6.3 Revised Conceptual Model
Based on the outcomes of the testing of the propositions and the additionalpatterns found in the cross-case analysis, a revised conceptual model (figure 8)is developed that reflects the relevant concepts of an API platform strategy.
Figure 8: Revised Conceptual Model
68
Conclusion!
• “How does the architecture and governance of an API
platform strategy affect the performance of a platform
ecosystem for digital cities?” !
• Finely-granulated APIs positively impact the performance
of the platform !
• Gatekeeping has a positive effect on the performance of
the platform!
• Relational control influences the platform performance in a
positive manner !
23/06/2017!!
Daniël Rustenburg ! 10 !
Recommendations !
• Fine granularity !
• User-friendly platform with a gatekeeping process!
• Intensive communication!
• Documentation!
• Provide real-life examples!
!
23/06/2017!!
Daniël Rustenburg ! 11!
Limitations !
• Not an exhaustive amount of cases!
• Not all aspects of concepts regarding the APIs and
platform performance covered in depth!
• Not always multiple interviewees per case !
• Only high/medium/low levels used as a scale !
• No predetermined benchmark for performance !!
23/06/2017!!
Daniël Rustenburg ! 12 !
Thank You!
23/06/2017!!
Daniël Rustenburg ! 13 !
