Subsecties

Proposed business model

What has been discussed in this chapter till now are solution concepts for construction Semantics, the web services that build upon the Semantics, and Specifications as an important illustration of the concept. This section proposes a business model as integral part of the concept: the concept is intended to be applicable in practice.

A desired end-result of the concept solution is a healthy BC information ecosystem. This section introduces the proposed business model for the concept. The concept is not intended to be a theoretical model, but to be applicable in practice, solving real-world problems and improving BC's value adding.

The two main components of the concept, the bcoWeb and the web services will be dealt with separately with regard to a business model. An important basis for the potential success of both is formed by their use of standard NG Internet possibilities that are widely available.

bcoWeb business model

Part of the solution concept introduced in this chapter is to use an open source development model [98] for bcoWeb. The analysis in chapter 3 showed that current development efforts have failed to produce widely-accepted results, thus making an alternative approach an attractive option. Open source itself has been analysed in chapter 4 (section 4.6, see also section 6.2.1).

With an open source development model, the following points are part of the characteristics:

Zero costs
The cost for use of bcoWeb is zero. This means that there are no monetary restrictions for adoption, making it inherently more attractive for users and developers when compared to alternatives that require payment [99]. The downside is that there is no direct monetary profit to be gained from building bcoWeb. This means that development and, for instance, web server space, must be financed through other means [100]. Possible incentives to do this will be covered later in this section.
Cooperation
BcoWeb does not need to be developed by just one single organisation or company. Open source licences allow you to develop bcoWeb cooperatively, with multiple partners developing parts of bcoWeb without needing elaborate legal frameworks to do so. It is possible to build upon each other's results and to re-use previous results. The clustering proposed helps to organise cooperation as the group within which cooperation takes place is of a limited size [101].
Small contributions
Small contributions to bcoWeb are already valuable. If an individual supplier wants to include his--limited--generic product type information in bcoWeb, it is an addition that can be used. On its own, the information is not marketable or sellable. The open source development model of bcoWeb allows contributions like this to be used.

Possible reasons to finance bcoWeb either with money, effort, information or web server space include the following. Profits reaped indirectly from bcoWeb by deploying bcoWeb-based web services can be used to further bcoWeb's quality and quantity. Government or trade organisation's subsidies can be sought; a good selling point is that the open source license makes the subsidy's results generally and permanently available which might make it a more attractive subsidy target than funding proprietary developments. Self interest of BC companies is also a possible investment reason, as bcoWeb might improve a company's value adding process, even when only implemented locally for that company; with a limited degree of completeness, bcoWeb should already provide profitable results.

As no open source BC Ontology effort has been attempted, it cannot be guaranteed that this approach will work. A prototype effort has to be undertaken to get a better understanding. What is possible now is to discuss two common objections encountered often [30] when discussing early open source Ontology ideas in this field.

Objection 1: it is not possible to earn money with it
This point is correct, in so far that one cannot directly earn money with the BC Ontology web. The bcoWeb improves the value adding process, so money earned could be spend on improving the bcoWeb to enable more value adding.

When money is earned directly with the Ontology, it means logically that a certain organisation is paid for the the use of the Ontology. The consequence is that that company has a lot of influence on all communication in BC based on the Ontology. It seems questionable whether BC as a whole is willing to submit to such a single-organisation influence. On the other hand it does not seem likely that other stakeholders than public authorities become early involvers.

Objection 2: nobody will maintain the Ontology for free
The argument goes that something that is free cannot be good, as there is no incentive to provide quality and maintenance. This argument can be disproved by the success and quality of a lot of open source products. Commercial web server and mail server programs form a minority on the Internet; the open source alternatives are used more often and are often even of higher quality.

Perhaps a better example is formed by the wikipedia on-line open source encyclopedia effort [88]. Despite occasional problems with political issues and personal agendas of some participants, it continues to grow and provides often surprisingly high-quality content. The ease by which interested volunteers can create new content and improve existing content is instrumental in both growth and quality, as the efforts of many small contributors are combined into one useful whole.

A bcoWeb being run as a collaborative open source project. That is the foundation for the best chance of success for instrumentation that supports and enables a much more dynamic BC.

Web services business model

Web services itself are not a piece of infrastructure that has to be build, it is essentially a way of building and dealing with applications. So, the question becomes `what is the business model behind building bcoWeb based web services applications'.

Web services provide additional functionality for the user-facing applications. They provide interaction with calculation software, Specification software, regulations, project databases. So there are two different kinds of business models: those for the web services producers and for the consumers.

For applications that consume web services, it opens up a way to offer more functionality with relatively little effort (compared to developing the used functionality inside the application itself). It offers better service to the customers by better and more natural integration with other applications. For example, a bcoWeb-based Specification web service is more attractive to develop for than adding an import/export function for a Specification system's data format, as the latter only works for customers that have that Specification system installed. A per-use fee based Specification web service increases the likelihood that the functionality offered will be used. The market increases enormously, which makes it more attractive to develop.

For web service providers, new markets open up and existing markets get bigger. An example of the increased market was given in the previous paragraph. New markets are opened up for applications that are too small and specialised to warrant separate desktop applications. Too few people get enough use out of it in order to buy the applications, making them economically unviable. With web services, the functionality can be offered to other applications without needing to install software on the client's computer. Innovative and highly technical niche applications, for instance, get a much bigger chance this way; the barrier for adoption is lowered.

What makes this interesting business-plan-wise is that, in most cases, cooperation between just two applications already seems to profit from a web services approach. Every additional application joining in adds to the advantage. This is not a ecosystem that needs total market adoption before bringing in fruits [62], it can bootstrap8.7 itself from a humble beginning.

Reinout van Rees 2006-12-13