Die Offenheit von Standards, Plattformen und Schnittstellen ist eine essentielle Voraussetzung für ein florierendes Software-Ökosystem. Hier haben manche Firmen Vorbehalte - gerade vor dem Hintergrund des Verlusts von umfassenden Kontrollmöglichkeiten auch in qualitativen Belangen. Wie können Unternehmen also erfolgreich in Software-Ökosystemen aktiv sein, ohne qualitative Einbußen zu befürchten? In Open-Source Softwareprojekten dagegen ist Offenheit die Regel. Wann aber wird ein Softwareprojekt ein Software-Ökosystem? Und was macht eigentlich das Ökosystem rund um Google aus?
Diese und weitere Fragen hat uns Slinger Jansen im zweiten Teil des IT-Radar Interviews beantwortet.
Druckversion als PDF herunterladen...
Interview mit Slinger Jansen - Teil II (MP3, ca. 13 MIN)
Das Interview zum Nachlesen:
Now let us consider the aspect of opening up a company with regard to interfaces, platform, and the like. I could imagine that there are reservations and even fear to lose the sovereignty over the own products and especially over the quality of these products. How can a company deal with that?
I think many, many companies are afraid of opening up. I have recently written an article for the special issue on software ecosystems in the Journal for Systems and Software regarding the openness of software products, platforms, and enterprises. The first premise of the article is that openness is an essential part of a successful software ecosystem, because otherwise other participants in the ecosystem would have nothing to build upon. Furthermore, I think it is even a little old-fashioned wanting to remain king in one’s own domain with such strenuous force–to me that is an old-school way of thinking.
I think the aim of any software producing organization is to get products and services used as much as possible. If opening up your product to a certain extend helps, then it should always be done. This is basically smart business engineering.
As far as I know, there are great examples of companies who did open up, but are still really strong kings of their domains. Immediately I think of Apple. With the iOS platform they developed a very open platform in comparison to Blackberry, for instance, which follows very clear development standards. Its beauty results from the fact that the quality of the components in the ecosystem is actually checked for compliance thereby enforcing certain quality levels upon the participants in the ecosystem. I think this attitude is rightfully criticized for its opaqueness; it is not transparent, and it is very hard to know what Apple is going to do. But it is a very nice example of a company who is doing greatly in terms of both power and openness. What I think that Apple proves here is that the excellence of products is key in this whole story. So they can be quirky because the market allows for it.
Besides this example of Apple, to me, opening up a company is also a new way of thinking. I think in every software product’s life a point is reached where one realizes „Alright, that‘s it, we can no longer keep up with all the domain specific requirements“; and that is really a critical point, because one has to deal with many requirements from many different domains. Then it is necessary to start doing some domain engineering and answer questions like: „Do we want to go into a county market as well or do we want to go into banking...?“ It becomes hard to choose what should be done, and this is sort of a natural moment to probably react like this: „Wait, let‘s take a step back and let‘s have partners who profit from our product or platform, and let‘s have them solve this problem of all this domain specificity and let them take care of this and let us be the big player, the keystone in this ecosystem, while the niche players take care of all the really exotic functionality that is of course necessary, but that is not the immediate concern in our business model.”
I think some really good examples of this are Salesforce or Microsoft CRM whose products are fairly feature poor, but they designed them so deliberately that the partners gain some serious opportunities with that platform. That is a beautiful way of thinking, and in my opinion software companies should not be so overprotective of their resources. At the end of the day, the policies one determines in his ecosystem will determine how powerful he will be, and this has everything to do with how excellent your product is as well as with how successful your product is going to be.
I am still thinking about the definition of software ecosystems. We named a few examples by now but let us consider, for example, Google in more detail. In the media Google is often called a software ecosystem regarding all its applications and so on. What are the features that essentially make Google a software ecosystem?
If we look at my definition which means looking at the database of organizations or organizational entities and put a filter on it with the word “Google”, then we will have a nice business ecosystem. However, I think there are some specific characteristics about the Google ecosystem making it a special kind of software ecosystem. For example, I think it is a fairly centralized ecosystem where a large portion of people are working on building extensions for its technology, and these people are mostly working within Google. Comparing this with an ecosystem like Microsoft CRM, where probably at least 90% of the people developing for and around the platform are not working for Microsoft directly but for partner companies, Google is quite young and maybe immature in this respect. Regarding the aspects of centralization and decentralization the ultimate decentralized ecosystem is where the power balance is completely on the side of the participants in the ecosystem as in case, for instance, of the Ruby gems ecosystem or the Debian ecosystem. They are almost completely decentralized, and developers determine what happens to a platform being the keystone players.
In that sense, the Google ecosystem is still an ecosystem, it is just very young and it‘s altering is still rather small; hence the community around it is rather immature. Nevertheless, I am sure that in five or ten year’s time we will be talking about the Google ecosystem or specifically the Google app engine system, for instance, in the same way that we are talking about Microsoft today.
We just talked about some Open Source projects. I am wondering if there is a threshold when you say „OK, now it starts being an Open Source ecosystem and stops being just some project”?
I hate that question because I do not know the answer. But this is a question I am asked a lot. I think I have actually asked my own B.A. and Master students the same question, and I take my database of organizations or of entities as the starting point. I believe I have to say something like “anything above two entities”–two is too little–which means as soon as you have three companies working on something you can say „We are now part of an ecosystem“. But then, I would have to state that it is a very uninteresting ecosystem because the power play in such an ecosystem would be very limited.
In the research agenda I define three perspective levels. On the first level you look at the internal company view: at your main suppliers in your products, at the customers, at your partners, and at your distribution channels. Then you can go one level higher, at the second level, where you look at your own ecosystem: at your competitors and stuff. And then the highest, the third level, is where ecosystems are competing amongst each other. I think each level has its own interesting factors but the lowest level is the most interesting level for boardroom discussions so to say. By contrast, when looking at a complete ecosystem as, for instance, the Facebook ecosystem, it is much more interesting to look at power play and the way in which the community is going than looking at just one organization with maybe five or six partners.
A lot of the examples that we had now somehow originate from the web, Google, Salesforce, etc. They have a quite specific strategic alignment, and I guess it is different from those companies that develop applications for software desktop platforms. Are there any advantages resulting from such different strategic alignments?
I hate to be the one to say it, but I think the answer is no. I said I hate it, because I still have a very warm place in my heart for non-web-based companies. I have good contacts with SAP which I think is fairly familiar to you, and I have great respect for that company as well as the ecosystem that is developing around it. I think the on-premises software companies are still the titans of the software industry. And I feel that they are also making the transition towards being SaaS-based (Software-as-a-Service-based), the subscription-based type of business models, and I think they should. In many cases that is the natural way to go. Of course, there are some exceptions like the banking industry, and there are some cases where on-premises may still be the safest choice. One advantage that I do see of being desktop- or server-based is that companies still tend to take you more seriously as a business partner. These companies hesitate to host mission critical data in the cloud. I know cases where that was completely relevant, where it was truly a smart plan not to have data in the cloud. Hence, when “putting on my ecosystem glasses” I am quite surprised how companies need to organize themselves when they are cloud-based.
One thing that I noticed was that if you have a desktop based software system, then the customer or the on-premises owner or the licenser is in charge of the relationships he builds. He is in charge of which company to connect to, which bank to export or import data from etc. By contrast, if a System is cloud-based or SaaS-based, then all of a sudden community management such as APIs and the partners that you will work with are governed by the vendor. With on-premises software, I think, the customer determines which other third parties he wants to integrate functionality and data with, whereas with off-premises the software vendor needs to coordinate all the efforts in his area, and I find that very interesting. I think that has also something to do with power positions. A vendor of an off-premises based platform has much more power over the extensions build for the platform.
To give an example: I could build some very poor quality extensions for SAP and get away with it for quite some time, whereas in the Salesforce ecosystem the appreciation mechanisms and the approval mechanisms from Salesforce themselves will prevent me from doing this quickly. Moreover, the aspect of money is different in these cases, because the distribution channel changes, as I think. If I build a nice SAP extension, I can sell it independently, whereas if I have a Salesforce extension, it would be very opportunistic of me or probably failed pragmatism to put my component in their web or app stores. There are simply more possibilities in terms of distribution.
So if I add all that up, I think that the service-based, SaaS-based, off-premises-based companies in the end will be probably more successful in this sense, but therefore they do give up a lot of control, and now I am talking especially about the niche players.
Read more about the technical view on software ecosystems concerning architecture, processes and organisation in the next issue of the interview.
Das IT-Radar-Interview führte Vincent Wolff-Marting.