Volgende: Illustrating the changes to Omhoog: Solution concepts Vorige: eSpecification Inhoudsopgave
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.
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:
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.
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.
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 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.