information system biologis

<div dir="ltr" style="text-align: left;" trbidi="on"><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBbP4wnbvFwaE5fbWMRCsuWUNioUjm6fHZf1TxtNWOuzYbAAnJyPJyepgN7mgFUH7qz_6Je9wNc9jFoIH3avYob2NJCtZixEtI0Vf0LP9nwO3NYroGrB0jVYM16Tvt8JcN0hU6qaROtXw/s1600/Keene.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBbP4wnbvFwaE5fbWMRCsuWUNioUjm6fHZf1TxtNWOuzYbAAnJyPJyepgN7mgFUH7qz_6Je9wNc9jFoIH3avYob2NJCtZixEtI0Vf0LP9nwO3NYroGrB0jVYM16Tvt8JcN0hU6qaROtXw/s1600/Keene.jpg" /></a><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">Today’s post is a set of simple, yet somehow deep, thoughts about the systemic nature of different ecosystems related to software. I was trained in the 80s to think about software costs in a “traditional software engineering” manner, using KPI, metrics and a spreadsheet (using cost models that were popularized by <a href="http://www.speakers.co.uk/our-speakers/profile/peter%20g.%20w._keen">Peter Keen</a> in the 90s). Somehow, this shows in my <a href="http://www.amazon.com/Information-Technology-Chief-Executive-Organization/dp/1438911114">second book</a>  where one may find references to the classics (<a href="http://en.wikipedia.org/wiki/Barry_Boehm">Barry Boehm</a>, <a href="http://en.wikipedia.org/wiki/Capers_Jones">Casper Jones</a>, etc.) in the bibliography section. What characterizes this way of thinking is that it is a <i>static</i> approach (even if the system changes, one think about a “snapshot” taken at a given time), <i>controlled</i> (one assumes that all stakeholders cooperate under a common control) and <i>global</i> (the cost model operates on what is thought to be a complete picture).<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">Life in this century is different when it comes to software. Software is a “live thing” – in the sense that it constantly evolves to adapt to its environment -, mostly distributed, with a large number of stakeholders whose strategy escape the control of the software developer. Hence <i>static</i> should become <i>dynamic</i>, <i>controlled</i> should become <i>collaborative</i> and <i>global</i> should become <i>distributed</i>. The dynamic and complex relationships between the stakeholders and between the various distributed players who contribute to building a software piece yield the “<a href="https://mitpress.mit.edu/books/software-ecosystem">ecosystem</a>” label. This word is borrowed from biology and <a href="http://informationsystemsbiology.blogspot.fr/2013/12/seven-keys-for-complex-systems.html">is a signature of complexity</a>.<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;"><br /></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">This observation is actually one of the reasons for the title of this blog “<b>Biology of Distributed Information Systems</b>”. It helps to think about software and information systems by borrowing concepts for biology and ecology, and it is definitely necessary to switch from a <i>static</i> to <i>dynamic</i> analysis.<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">This is a first post on this topic, so I will keep things simple (hence somehow incomplete and arguable), and focus on three ecosystems:<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"></div><ul><li><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;">The OS, platform and application ecosystem</span></li><li><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;">The open-source ecosystem</span></li><li><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;">The application developer ecosystem</span></li></ul><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span style="font-family: Verdana, sans-serif;">I must apologize in advance to real software experts :). First, this is a post intended for readers with no precise skills nor knowledge about software. Second, I will reason in an “abstract category” way that will not dive into interesting but difficult distinctions. For instance, in this post, an “app” is a piece of interactive content, whether it is a “true application” written for a smartphone, a simple HTML page, an HTML5 page decorated with Java script or an hybrid mobile app. For this first post, I am aiming at a “big picture from 10000 feet up”.</span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt;"></div><div style="text-align: justify;"><br /></div><span lang="EN-US"></span><br /><h3 style="text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">1. S</span><span style="font-family: Verdana, sans-serif;">oftware Global Ecosystem </span></span></h3><span style="font-family: Verdana, sans-serif;"><div style="text-align: justify;">The starting point of the argument is the need for software that evolves constantly.  You may accept this at face value because <a href="http://readwrite.com/2007/10/16/the_future_of_software_development#awesm=~oCCRyyaqgZCKuv">it is a commonly heard argument</a>. If you need convincing, the need for constant evolution comes both from the technology (the “what is possible today ?” perimeter <a href="http://mashable.com/2010/12/20/constantly-changing-technologies/">changes constantly</a>) and the users. The complexity (i.e., richness) of software usage today means that the “<a href="https://www.appcelerator.com/blog/2014/04/rutberg-summit/">user is in the driver seat</a>”. That is, software needs to be co-designed with users, which is of the principles of <a href="http://informationsystemsbiology.blogspot.fr/2013/10/lean-startup-lean-innovation-factory.html">Lean Startup</a> (to name one reference, hundreds would apply here). This leads to an incremental model, which in turn requires a (much) faster code production rate. I will assume that you buy this argument, since this is not the topic for this post, and it is a fairly common assumption.</div></span><br /><br /><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">From this we derive <b>two key consequences</b> for software in the 21<sup>st</sup> century (as opposed to the century when I was trained as a software developer):<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"></div><ul><li><b style="font-family: Verdana, sans-serif; text-indent: -18pt;"><span lang="EN-US">Much more innovation is needed</span></b><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;">, which requires the help of an <a href="http://en.wikipedia.org/wiki/Open_innovation">open innovation</a> model. This leads to the concept of platforms, API and apps.</span></li><li><b style="font-family: Verdana, sans-serif; text-indent: -18pt;"><span lang="EN-US">Much cheaper software production</span></b><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;"> is needed, which itself requires a new level of sharing/reuse, based on a common/universal software architecture.</span></li></ul><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">Software productivity, as defined by the cost to produce a <a href="http://en.wikipedia.org/wiki/Function_point">function point</a>, is improving slowly. This is a topic which I have addressed in depth in <a href="http://www.dunod.com/informatique-multimedia/systemes-dinformation-et-reseaux/strategie-et-systemes-dinformation/manageme/le-si-demystifie">the previously quoted book</a>. I have a vested interest with this question since I started my career as a computer scientist trying to build tools (<a href="http://link.springer.com/chapter/10.1007%2FBFb0013534#page-1">languages</a>) that would increase this productivity significantly. It turns out that the world needed a much more efficient way to reduce software development costs as we just saw and has found it through massive reuse, thanks a to common software architecture :<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"></div><ol><li><b style="font-family: Verdana, sans-serif; text-indent: -18pt;"><span lang="EN-US">Open OS</span></b><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;"> : open operating systems (LINUX, Android, etc.) have become, thanks to open innovation in the form of open source, massive repositories of reusable value. For reasons that will become clear in Section 3, the world needs as few of those as possible.</span></li><li><b style="font-family: Verdana, sans-serif; text-indent: -18pt;"><span lang="EN-US">Platforms</span></b><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;">: on top of OS, platforms have emerged. One may think of the most common open source tools such as <a href="http://en.wikipedia.org/wiki/Apache_Software_Foundation">Apache</a>or <a href="http://en.wikipedia.org/wiki/MySQL">mySQL</a>, the <a href="http://www.convinceandconvert.com/social-media-strategy/amazon-google-apple-facebook-and-the-gang-of-four/">GAFA platforms</a> or the web browsers. The rise of platforms over the last 20 years is coupled with the rise of <a href="http://en.wikipedia.org/wiki/Application_programming_interface">API</a>(Application Programming Interfaces) and the associated technologies (XML, Web Services, REST, JSON and the likes).</span></li><li><b style="font-family: Verdana, sans-serif; text-indent: -18pt;"><span lang="EN-US">Apps </span></b><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;">(interactive content) : this is what the end user sees and interacts with. The combination of SDKs and platform APIs, together with open-source libraries, have made the production of apps orders of magnitude more efficient than when I started writing code 30 years ago.</span><span style="font-family: Verdana, sans-serif; text-align: justify;"> </span></li></ol><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4cHt9nBTC02kLbkpc6fxsJIqtBr1dZZy_GS1WYQuQ9Me0WskbGyIsyh7IXfe9dQK2rtx-FlZgSoGOomt6_rd_yrkEea6NUQX1V5ugNWgLV7HhhpiY_4smLml3nBoVeFe7_rzxlMO8Ozw/s1600/TheAgeOfThePlatform.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4cHt9nBTC02kLbkpc6fxsJIqtBr1dZZy_GS1WYQuQ9Me0WskbGyIsyh7IXfe9dQK2rtx-FlZgSoGOomt6_rd_yrkEea6NUQX1V5ugNWgLV7HhhpiY_4smLml3nBoVeFe7_rzxlMO8Ozw/s1600/TheAgeOfThePlatform.jpg" width="130" /></a></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">Please note that the word “platform” is usually ambiguous: it may mean a cloud/service platform (a back-end platform that serves a front-end app) or an open back-end that collaborates with a many apps (or other service platforms) through APIs. Here I use platform in the second sense; the first is always included in the “app” perimeter because of “<a href="http://searchconsumerization.techtarget.com/definition/device-agnostic-device-agnosticism">device agnosticism</a>”. That is, to let the end user pick whichever device is more suited to her current context, each mobile app must have a dual cloud service platform. So, in this post, each “app” comes with associated set of back-office/cloud services and I reserve “platform” for the implicit open innovation approach (cf. “<a href="http://organisationarchitecture.blogspot.fr/2014/03/entreprises-numeriques-et-homeostasie.html">L’age de la multitude</a>”)<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><h3 style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">2. Critical Mass and Software Usage </span></span></h3><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjp4ZR_bnCYHkcdL6IxYSC6ry-52GGiQS8x87NU1OILyKoG8tE4X1NzdD2VcbO-zIbJEWKzGnPXwxLvViHPCovQiVvdgRgiLVOXoZaadDmdObm1aShg7Bowxi2Hpu2dOr4LG1cZ3gyvQr0/s1600/Amas_de_percolation.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="226" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjp4ZR_bnCYHkcdL6IxYSC6ry-52GGiQS8x87NU1OILyKoG8tE4X1NzdD2VcbO-zIbJEWKzGnPXwxLvViHPCovQiVvdgRgiLVOXoZaadDmdObm1aShg7Bowxi2Hpu2dOr4LG1cZ3gyvQr0/s1600/Amas_de_percolation.png" width="320" /></a></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">Even if software development is incremental, launching a successful product requires building a “critical mass” of value before one may start the “<a href="http://theleanstartup.com/">lean startup</a>” positive feedback loop of co-creation. This is the “V” in <a href="http://en.wikipedia.org/wiki/Minimum_viable_product">MVP</a> (Minimum Viable Product): there is a threshold of value brought to the user that one must pass before the <a href="http://en.wikipedia.org/wiki/Percolation_theory">percolation</a>model of viral adoption (helped with proper marketing) may kick in. The analogy with living organisms (“<i>SW as a living thing</i>”) is relevant here: software requires growth, constant change and a sustainable equation of user growth. The MVP aims to reach the tipping point when viral adoption becomes sustainable (what <a href="http://en.wikipedia.org/wiki/Eric_Ries">Eric Ries</a> calls “getting traction”).<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">The “critical mass of value” that is required for this tipping point varies considerably according to the pain point that the piece of software is trying to alleviate and according to the current state of the art. It may be measured in terms of function points (how rich an experience is necessary) and social weight. The complexity of modern experience comes from their social nature (if you think about it, most apps on your smartphone nowadays have a social component). Hence installing a new habit requires fighting against <a href="http://en.wikipedia.org/wiki/Metcalfe's_law">Metcalfe’s Law</a>, and <a href="http://organisationarchitecture.blogspot.fr/2012/06/ecologie-du-temps-libre-et-reseaux.html">displacing a previous social usage requires even more efforts</a>. The value critical mass may be large, which explains why some legacy Microsoft products such as <a href="http://en.wikipedia.org/wiki/Microsoft_Word">Word</a>, which I am still using to write technical papers, have not been easily replaced by open source alternatives.<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;"><br /></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">To reach this “value critical mass”, someone must invest an initial significant software development effort. In a complex world, where the risk to fail is high, one must reduce this initial software development cost, as we explained earlier. This is also a signature of the complex environment we live in: we must switch from ROI (return on investment) to the <a href="http://www.effectuation.org/learn/principle/3">affordable loss</a>principle.<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">The percolation model shows why the ROI principle is no longer relevant: it is very hard to predict how well a successful MVP will percolate. The world is full of software startups with <a href="http://techcrunch.com/2014/02/19/facebook-buying-whatsapp-for-16b-in-cash-and-stock-plus-3b-in-rsus/">amazing valuations</a> because their app found its way to massive deployment and usage. But it would be very difficult to predict such success a few years earlier, when the MVP was still a prototype.<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">The <b>affordable loss</b> approach means reducing the development cost to something that “you may afford to lose”. This means leveraging the previously shown layered architecture, and mostly leveraging the strength of the open source community.  <a href="http://en.wikipedia.org/wiki/Open-source_software">Open source software</a>is a machine that is constantly churning out software platforms that start their own journey towards fame and critical mass. The quality of open source software is directly related to its adoption (<b>because good software is built incrementally through feedback </b>– a key axiom). Adoption is inversely proportional to genericity, hence a using open source software is a “connected art”. One must understand the communities’ sizes and dynamics to select “the pieces of the puzzle”. Open source software yields by construction a nested / layered structure of software libraries with a combination of very high quality stable platforms for the common needs and more experimental gems with specific capabilities. This is why the word “<a href="http://scholarworks.umass.edu/ncdg/34/">ecosystem</a>” is so relevant to open source software. One should not think of a catalog of free software, but of a nested hypergraph of communities, where a collaborative price must be paid. This price is measured in (participation) time and (code) sharing. This represents a culture shift for most software organizations, but the efficiency of those who “play the game right” is such that it becomes <a href="http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar">the only game worth playing</a>.<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEia5FN0_B-3pNnYNwhYtIsD9m9VYjfRhuOpMPHEJvA4sE6gpZZkq0ga6LQn-mXCPtjEpuWkQiyPYai5dbwo_g9WWMEcxwcMUzAmPwjYj1iEkMzjyioMN1-7VPuBPNp24K6LMcnMY_AyzZs/s1600/LesG%C3%A9antsDuWeb.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEia5FN0_B-3pNnYNwhYtIsD9m9VYjfRhuOpMPHEJvA4sE6gpZZkq0ga6LQn-mXCPtjEpuWkQiyPYai5dbwo_g9WWMEcxwcMUzAmPwjYj1iEkMzjyioMN1-7VPuBPNp24K6LMcnMY_AyzZs/s1600/LesG%C3%A9antsDuWeb.jpg" /></a><span lang="EN-US"><span style="font-family: Verdana, sans-serif;"> </span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">This is just a hint of what a proper open source strategy should be, since there are so many aspects that I am not touching here. Open source is not only about software libraries, it is also about development methods, tools and processes, cloud computing and hardware, to name a few. As a follow-up, I would suggest reading Octo’s great book “<a href="http://www.geantsduweb.com/">Les Géants du Web</a>”, take a closer look at <a href="http://informationsystemsbiology.blogspot.fr/2011/11/lean-it-devops-and-cloud-programming.html">DevOps</a>or leverage the value that is found in the <a href="http://en.wikipedia.org/wiki/Open_Compute_Project">Open Compute</a> project.<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span style="font-family: Verdana, sans-serif;"><br /></span></div><h3 style="margin-bottom: 0.0001pt; text-align: justify;"><span style="font-family: Verdana, sans-serif;">3. The App developer's equation</span></h3><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span style="font-family: Verdana, sans-serif;"><o:p></o:p></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span style="font-family: Verdana, sans-serif;"><br /></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span style="font-family: Verdana, sans-serif;"><br /></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">This last part looks at app sustainability from the perspective of the developer. I have used the following (abstract) equation in my presentations for the past 10 years:<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><b><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">Attractiveness = Market x Generosity x Value / Effort   <o:p></o:p></span></span></b></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">In this equation, <o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"></div><ul><li><b style="font-family: Verdana, sans-serif; text-indent: -18pt;"><span lang="EN-US">Market</span></b><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;"> is the size of the potential market size that a given platform is proposing. This equation was developed to understand the fate of mobile OS, but it applies to all kinds of platforms, from cloud service platforms that propose APIs (another dream of <a href="http://blog.programmableweb.com/2007/03/09/bt-launches-apis-for-telephony-mashups/">phone operators</a> for the past 10 years) to <a href="http://readwrite.com/2014/03/08/pebble-appstore-androids-apps#awesm=~oCE2EtJotB7pol">connected objects</a>.</span></li><li><b style="font-family: Verdana, sans-serif; text-indent: -18pt;"><span lang="EN-US">Generosity</span></b><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;"> is the share of the revenue (app price or advertizing revenue) that is sent back to the developer. For instance, Apple keeps a hefty 30%, whereas Android is more generous. Set-up costs should be factored in, for those platforms where some form of license or tools investment is still necessary.</span></li><li><b style="font-family: Verdana, sans-serif; text-indent: -18pt;"><span lang="EN-US">Value</span></b><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;"> is what the platform brings to the developer, as far as the end user experience is concerned. When I said “abstract” earlier, I meant that I don’t have a formula to measure “Value”. Most often, it is a judgment call from the developer, who evaluates what innovative and relevant services may be developed with the platform. There is subjectivity involved, such as the infamous “cool  factor”, which favors sets of APIs & features from which “cool stuff” may be built.</span></li><li><b style="font-family: Verdana, sans-serif; text-indent: -18pt;"><span lang="EN-US">Effort</span></b><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;"> is the amount of time it takes to build “one unit of value”. This is where the difference stands between great players, who provide the right <a href="http://en.wikipedia.org/wiki/Software_development_kit">SDK</a>, community support, testing services, and an efficient delivery (store) platform, and other less qualified players. Many APIs exposure programs have failed during the past 10 years because the effort expected from the developer was much too high. This is also why one should enroll help from qualified actors such as <a href="https://apigee.com/about/">Apigee</a> to develop an API strategy.</span></li></ul><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">Roughly speaking, the equation is an abstract form of “Expected income / Expected Effort”. I have used this equation in the past years to explain why there would be two or at most three mobile open OS in the future, but it actually tells a lot of things.  You may understand why Microsoft announced (at last) that <a href="http://timesofindia.indiatimes.com/tech/tech-news/Microsoft-makes-Windows-free-for-small-devices/articleshow/33144292.cms">Windows Phone would be free in the future</a>. The “Market factor” yields a “winner take all”  dynamic that we have observed for many platforms (the <a href="http://en.wikipedia.org/wiki/Matthew_effect">Matthew effect</a> : the platform with the more users attracts more developers, benefiting from more open innovation, hence attracting more new customers). It also gives a few insights for a successful platform strategy:<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"></div><ol><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzuHxEe6o265N5PfFRf31PxYtMM0IeaD40mXXcWbSwCENqADmV-k-T7TExQjvovQ5WZ9p8p87phrQ6RFaHEE2IwZBLeYovJ8sEmDGr9CE1SBzkQsdVqzWjjRvcl7iwPqSlors1F2xdBCI/s1600/FunVsEffortHumor.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="312" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzuHxEe6o265N5PfFRf31PxYtMM0IeaD40mXXcWbSwCENqADmV-k-T7TExQjvovQ5WZ9p8p87phrQ6RFaHEE2IwZBLeYovJ8sEmDGr9CE1SBzkQsdVqzWjjRvcl7iwPqSlors1F2xdBCI/s1600/FunVsEffortHumor.jpg" width="320" /></a><li><span style="font-family: Verdana, sans-serif; text-indent: -18pt;">Growth : get a critical mass of customers, as quickly as possible. To jumpstart the virtuous cycle (that is, enroll app developers while the market is still not here, one must use rewards and gamification – such as </span><a href="http://www.bbox-actus.com/voir_news.php?article=2639&filtre=all" style="font-family: Verdana, sans-serif; text-indent: -18pt;">hackathons</a><span style="font-family: Verdana, sans-serif; text-indent: -18pt;">).</span></li><li><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;">Expose as much value from your APIs as possible, with a focus on differentiation that is exposing stuff which is both useful and not readily available elsewhere. This is probably the most strategic factor to predict the success of <a href="http://blog.hopkins.io/2013/07/25/withings-api/">connected objects</a> in the future, or larger domains such as the connected (smart) <a href="http://www.environmental-expert.com/articles/exclusive-interview-with-yves-caseau-executive-vice-president-at-bouygues-telecom-france-379180">home</a>.</span></li><li><span lang="EN-US" style="font-family: Verdana, sans-serif; text-indent: -18pt;">Reduce the effort for the developer by embracing the open source and Web standards (languages, development tools, API styles, libraries, etc.). The adjacent illustration of the “Fun vs. Effort” is taken from a humorous site, but thinking in terms of <a href="http://organisationarchitecture.blogspot.fr/2012/06/ecologie-du-temps-libre-et-reseaux.html">value/effort is critical to system analysis</a>.</span></li></ol><br /><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;">This equation gives also a way to evaluate the intrinsic value of a platform. It follows from what was said earlier that the value is the capacity to generate revenue streams from apps. This, in turn, is mostly related to accumulated user data. This leads to the idea, reported by <a href="http://en.wikipedia.org/wiki/Henri_Verdier">Henri Verdier</a>, that <a href="http://www.henriverdier.com/2011/02/mfg-labs-en-direct-de-la-strata.html">data is the new code</a>. The algorithms change constantly, and the best one are produced by external developers (hence the open innovation paradigm). What changes more slowly is the API structure and what accumulates over time is the amount of user data. This is important enough to be worth a future post when I report about the work of our group at the <a href="http://www.euro-case.org/index.php/academy/item/72-national-academy-of-technologies-of-france">NATF</a>on Big Data.<o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><span lang="EN-US"><span style="font-family: Verdana, sans-serif;"><br /></span></span><span lang="EN-US"><span style="font-family: Verdana, sans-serif;"><o:p></o:p></span></span></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><div class="MsoNormal" style="margin-bottom: 0.0001pt; text-align: justify;"><br /></div><br /><div class="MsoNormal" style="text-align: justify;"><br /></div></div>

Software Ecosystems and Application Sustainability

Today’s post is a set of simple, yet somehow deep, thoughts about the systemic nature of different ecosystems related to software. I was tra...

information system biologis

Software Ecosystems and Application Sustainability

Popular Posts

About

Blog Archive