Identification of Business Models Through Value Chain Analysis - A Method for Exploiting Large Technology Projects - A Whitepaper

1

Identification of business models through value chain analysis

A method for the exploiting large technology projects

Daniel Field, Atos

SynopsisLarge and consortium based technology based research projects, as exemplified by the European Commission’s framework programme projects share certain properties which complicate efforts to commercialise the results. They are multidisciplinary, multi-partner and technology-led. Significant lag is present between the inception of the project and its final results, five years in some cases, and the initial business case, if ever described, may be based on assumptions or predictions later found to be false. The final results may differ widely from the original plans, as approaches are changed, technology evolves and emerges, and experiments fail.

Faced with these difficulties, consultants working for the international information technology services company Atos have developed a method for identifying potential business models for the commercialisation of project results through value chain analysis. By incorporating aspects of technology analysis into value chain analysis, different value propositions can be explored and consequently innovative routes to market discovered.

This whitepaper describes the process of developing appropriate value chains and analysing them to identify possible business models. In the course of developing this method it was also seen that it could be applied to existing companies. Through this, the business model of a company can be contrasted with those of other companies sharing similar generic value chains, implying that this method could be used to categorise generic business models. Furthermore, as the analysis effectively predicts possible business models, it could become an effective tool for generating novel business models.

Several examples of the application of this method in European projects are given towards the end of this whitepaper, along with the results that were achieved. It is demonstrated that this method assists not only the development of innovative business models but also in structuring and formalising preliminary models.

Daniel Field V1.0, September 2011

2

Table of Content

sIntroduction.................................................................................................................................3

Overview of the exploitation method..........................................................................................5

Description of the exploitation method and tools.......................................................................6

Identification of assets.............................................................................................................6

Identification of the value chain...............................................................................................6

Development of business scenarios.......................................................................................13

From business scenarios to business models.........................................................................17

Example scenarios from commerce...........................................................................................19

The proprietary model.......................................................................................................19

The Open Source model.....................................................................................................21

Cloud Computing................................................................................................................22

The Freemium model.........................................................................................................24

Examples of the method in technology projects........................................................................27

The COIN project....................................................................................................................27

A FIRE project.........................................................................................................................33

A PaaS interoperability project...............................................................................................37

Conclusion..................................................................................................................................42

About.........................................................................................................................................43

Acknowledgements................................................................................................................43

About the Author...................................................................................................................43

About Atos Research and Innovation.....................................................................................43

About Atos.............................................................................................................................43

License terms.............................................................................................................................44


3

IntroductionThis paper introduces a method and tools for the development of exploitation strategies for large and complex technology research projects. This process has been developed in the exploitation of several large Framework Programme and other subsidized research projects. These projects are by nature multidisciplinary, multipartner and technology-led. In these research programmes there is a large delay between the development of the project idea and plan, and its finalization. From the publication of the call for proposals, to the proposal submission, favourable evaluation and contract negotiation, many months will have passed. Then the project lifetime may range from 12 to 48 months. In total it is not uncommon that the overall lag between idea conception and fruition is five years or more. This means that the initial assumptions and premises on which the project were founded may no longer hold true. Even if a business case was elaborated prior to the project start, the technical results may no longer match the initially foreseen set of results. The projects are invariably developed on a technology-push model rather than a market pull one. Nonetheless, towards the end of the project it is necessary for participants to determine suitable exploitation strategies in order to capitalize on their investment and the innovation of the project. The challenge lies in understanding how the technology can deliver value and how the participants can position themselves to profit from this value delivery.

Often towards the end of the project there are numerous competing ideas on what the technology does and how it can be exploited. The views expressed by one participant can rarely take into account all the business factors required to exploit the technology and it is frequent to find that the lack of formalization of these ideas prevents the participants being able to contrast and develop the ideas in a structured and constructive manner.

Above all, what is required at this phase of any technology-led R&D project is to establish a clear basis for building the exploitation ideas upon. This allows multiple perspectives of the same vision to be recognized as versions of one and the same vision, as well alternative visions to be formalised through a common framework thus enabling constructive debate on how to develop from a technology prototype to a business venture.

Over the course of numerous R&D projects the Atos has developed and fine tuned the method presented here. The intention of this whitepaper is not to teach value chain analysis but to show how it can be used in the area of business model identification. It is assumed that the reader is familiar with the concept of value chain analysis and the initial chapters dealing with identifying a value chains focus on the particularities of large collaborative projects.

Whilst developing the method presented here, it was seen that it could equally be applied to existent companies. Exploring possible alternative business models according to our method invariably uncovers business models already used by competitors or other actors with similar value chains. Examples of this are given here and the implications of this, as discussed in a


4

forthcoming paper1 include that this method can be used to contrast and categorise business models and for the exploration of innovative business models by existing companies.

The final chapters of this paper present the experiences and results gained in three recent projects where this method has been applied, showing the reader that it both fosters innovation and helps rationalise and formalise existing ideas.

1 Field, D., Describing and Identifying Business Models from Generic Value Chains for Technology Systems, eChallenges e-2011 Conference Proceedings Paul Cunningham and Miriam Cunningham (Eds)IIMC International Information Management Corporation, 2011, ISBN: 978-1-905824-27-4. Due to be presented at the eChallenges conference, Florence, Italy, October 2011.


5

Overview of the exploitation methodThe method and tools described in this paper are for use in the exploitation of large technology-led projects as exemplified by integrated projects funded by the European Commission’s framework programme.

This method and these tools can be applied to:

Identify the necessary components of the technical delivery of the project in a commercial setting.

Explore different modalities in which the project can commercially deliver value. Identify the value proposition of the project. Identify the suitable business model of the delivery. Formalise synergic, complementary and conflicting visions of exploitation to facilitate

development. Methodically and systematically approach exploitation activities. Identify the delivery roles that project participants can perform and roles which

require alliances with third parties. Prepare business plans for the commercial delivery of complex technological systems. Analyse existing commercial strategies to identify similarities with competitors and

potential innovative business models.

In essence the method set out in this paper is to formally recognise the value chain or system of the project based on the assets or technical innovations which have been prepared and to develop scenarios for commercial delivery based on activities which are aligned with the competences and business model of each participating organisation

In practice this means recognising the supply chain leading to the delivery of each asset, the value proposition of each component to the next in the chain and the number of different roles which could feasibly be part of a business scenario to establish a generic system value chain.

Once this has done the different exploitation visions of the participants must be mapped on to the generic value chain and the source of value, or overriding value proposition, of that vision recognised.

From this it is possible to recognise when differing visions are indeed different perspectives of the same vision, and when they are distinct scenarios. It is possible to distinguish between trivial differences and those that change the definition of the value proposition or business model. It is possible to identify the true client (he who provides revenues) from other actors that may use or benefit from the system, and it is possible to make some assertions regarding critical success factors, business models, long term strategy and potential risks and mitigation strategies.

Having come through this process, the project is well equipped to generate realistic and viable business plans for the conversion of innovative project prototypes to commercial products.


6

Description of the exploitation method and toolsThe exploitation method proceeds through the following phases:

1. Identification of innovations and assets

2. Elaboration of the value chain

3. Development of business scenarios

4. Exploration of long term implications

5. Elaboration of business plans

Identification of assetsThe identification of assets should start early in the project lifecycle for both for exploitation and non-exploitation reasons. In terms of technical management it is necessary to have an overall picture of the project’s components and how they work in order to build a complete system. In terms of project management it is necessary to know where resources are being spent and when things will be developed so that the progression can be monitored. From the legal perspective a complete list of components and their associated software licenses is required as certain restrictions may be introduced by the licenses which will affect the business models which can be applied. From the exploitation perspective it is necessary to know not how they work but what they do and which components they interact with. This is fundamental in order to derive the value chain and define the value proposition for them.

Identification of the value chainHaving identified the assets and the components of a project it is necessary to carry out value chain analysis on the assets in order to derive a generic value chain from which our business scenarios are constructed. It is assumed that the reader is familiar with general value chain analysis and in this section we focus on the specific challenges within the context of large collaborative ICT projects. Experienced analysts may wish to jump straight to the application of the method on page 13.

As at the start of any value chain analysis, the business team within a project will typically receive the list of assets and components from the technical management in the form of lists and architectural diagrams. These must be reorganised into a flow which represents the service – or value - that each component or provides.

First we need to separate the components and assets into two categories – the core technology and the peripheral assets. In the core technology we typically find elements of a core platform or central hub into which other components are integrated. In the list of peripheral assets we tend to find non-technical results such as business model research, consultancy models, additional services and other tools and pieces of software that can be used in certain use cases but are not essential to the delivery of the key project objectives.


7

Figure 1 - Typical core and peripheral assets

Next we analyse the core technologies for the value activities contained within them. In order to do this we carry out value chain analysis as introduced to the literature by Michael Porter2. Porter’s work focused on a single business and the analysis of its activities according to the value they create rather than their way they operate.

Porter’s original work segregated two types of value activity: those which perform a concrete function adding value to the input to provide an output with an added value; and those which do not have a single transformational role, but rather act throughout the value chain.

For example in the case of a technology that allows intelligent objects such as sensors and devices to be discovered, ranked against historical data and deployed, these three value activities would be considered concrete value functions and would be categorised in the first group. We call these vertical value activities. The second group of activities enable the vertical actions to be used or to function. These are horizontal value activities and include such things as the interface (allowing the user to discover and select the devices, the security features which ensure the user has the right to do so and the platform which manages the retrieval of data from the database and execution of the ranking algorithms, for example.

These are then placed pictorially into the core technology value chain, with the vertical activities in a logical order, forming the top portion of a horizontal chevron and the horizontal activities placed in the bottom half of the chevron showing that they act throughout the entire core technology, as shown below, in Figure 2. The chevron points to the right and the vertical activities logically proceed left-to-right.

Figure 2 - The value chain of the core platform

2 Porter, M.E., Competitive Advantage, ISBN 0684841460, Free Press, New York, 1985.


8

Having reached this point it is necessary to then extend the value chain with all the roles and the goods or services that are required in order for that component or asset to function, and the roles or services that are enabled as a result. This is an extension of the rent chain concept espoused by Baron3 , subsequently generally mixed with the original value chain concept of Porter and now referred to simply as a value chain. It is very similar to the concept of a supply chain, but based on value adding activities, rather than merely input and output activities, as with a supply chain. In extending the value chain we can refer to activities or roles. The activity “device provision” and the role “device provider” are equivalents. However the former is preferred as the latter tends to pigeon-hole organisations by their traditional role.

These activities are shown pictorially using a horizontal chevron pointing to the recipient of the good or service. These chains can be extended in both directions. The upstream activities are those which are required as input to the core technology. The downstream activities are those recipients of the functionalities of the core technology added value, and the subsequent recipients of the services or goods provided by those initial recipients. This is shown in Figure 3.

Figure 3 - Upstream and downstream in the value chain

Separation of activities into upstream and downstream orders is fairly trivial. The activities are identified through discussion or logical analysis and are often chronological. The chains should extend downstream sufficiently to cover the final user of the service and upstream at least sufficiently to cover the first activity of the supply chain which will not conceivably be performed by the organisation exploiting the technology system. This will give a wide context without introducing excessive detail. For strategic purposes it can be interesting to explore the value chains to a greater extent, but this is often better done as a later exercise when other details of the business plan are more concrete, at which point value network4 analysis may also become a suitable tool. Some typical upstream and downstream activities are shown inFigure 4.

3 Baron, D.P., The Nonmarket Strategy System, Sloan Management Review, Fall 19954 Christensen, C., The Innovator's Dilemma: The Revolutionary Book that Will Change the Way You Do Business, ISBN 0060521996, Harper Paperbacks, 2007; Stabell, C.B., and Fjeldsted, Ø.D., Configuring value for competitive advantage: on chains, shops, and networks, Strategic Management Journal Volume 19, Issue 5, pages 413–437, May 1998


9

Figure 4 – Typical upstream and downstream activities

The chains described above are sequential. However in situations where there are more than one input or output to a process it is possible to have value chains in parallel. This is quite common and in our example here we could see that the device manufacture and the device provision would be sequential to each other and parallel to the sequence of hardware provision infrastructure provision.

Figure 5 – Example parallel upstream and single downstream value activities

At this point we have the value chain from end to end, defining the ‘end’ as beyond the sphere of influence of the future provider of the project technology. The next task is to add any ancillary roles, whether of a technical or non-technical role. At this point in the process it is better to be as inclusive and comprehensive as possible.

We start with the periphery assets. As the value chain analysis concerns only value activities, each applicable asset needs to be converted into a value activity. For example the data collected and business models derived during the project are clearly assets of the project which should be exploited. However they are not a value activity in themselves. However we could consider that they could be used by business consultants associated with the solution. The experience in developing and deploying the technology is also an asset but the associated activity would be technical consultancy and training, for example.

Other assets, including technical ones such as the optional services, interoperability functions, plugins and so on used in our early example could be grouped together as considered optional


10

platform enhancements or kept apart according to the likelihood of them being the focus of any business model.

Furthermore in the commercial delivery of the solution there may be other roles not present in an R&D scenario. These would include non-technical functions such as Sales, Management, Maintenance, and so on. These should be included in order to complete the picture.

Having identified these peripheral assets and commercial roles, these must be added to the value chain in a suitable fashion. We approach this with the same method as before, separating them into vertical value activities and horizontal value activities and placing them in the diagram in a logical position. Vertical activities should be placed to clearly show how they receive inputs or feed into outputs. The length of horizontal activities should reflect the set of vertical activities over which they cover.

The example below shows a horizontal ancillary activity. In this example the main value chain shows a simplified series of activities for converting hazardous waste to non-hazardous waste. In this case just the transport and processing of the waste is regulated, so the ancillary activity ‘Monitoring and regulation’ extends the length of just these two activities.

Figure 6 - A horizontal ancillary value activity

At this point the diagram has the potential to become very complicated. It is therefore important to set the level of granularity appropriately. To some extent this cannot be prescribed and each analyst must make some decisions based on the context. However, as the intention of the analysis is to understand the activities that will be performed and by whom, in the context of a large technical project, we can consider the following rules of thumb for setting the granularity appropriately. Firstly in terms of increasing the level of detail and distinguishing between value activities we consider the following:

1. If two possible activities could conceivably be carried out by different, non-competing roles, they can be separated: Eg infrastructure provision and platform provision could be performed by an IaaS5 provider and a PaaS6 provider, respectively, though this may not always be the case.

2. If two activities could only be carried out by the same actor, but would be carried out for a different recipient roles of the good or service, they can be separated. Eg. CRM and regulatory compliance could be performed by head office for the clients and the government agency respectively.

5 IaaS – Infrastructure-as-a-Service6 PaaS – Platform-as-aService


11

3. If two activities could only be carried out by the same actor for the same recipient role, but could have a different focus on quality, cost or pricing they can be separated. Eg. Platform security management and service provision through the platform can only be provided by the platform provider to the platform user, but the latter could be pay-for-use whilst the former included for free.

And on the converse side, to decrease complexity and simplify the value chain we can follow the following rules:

4. If the value added by two separate activities is the same, even if the means and the actor performing it are different, they can be merged. Eg. providing additional, optional functionality in the form of a specific plugin or a specific extension could be provided by different actors through different methods, but the value in the context of the chain (adding functionality) is the same and can be performed by the same role (additional functionality provider). Using a nested chevron, as below in Figure 7, we can emphasise the multiple organisations behind this activity.

5. If activities are different as defined by rules 1-3 above but can be covered by an umbrella term then they can be merged. Eg. strategic management, human resources and financial management would normally be merged into the umbrella activity “management” as such details do not impact the conclusions of the value chain analysis.

Following these rules, the analysts can compile a complete value chain of the provision of the technical solution. An example based on the hypothetical case used up until now is shown below. In this figure we show the extension of management upstream from the core technology as dashed as it is uncertain how much of the chain will be operated by the same organisation. We have shown the additional functionality provider chevron as nested in order to emphasise that there are potentially multiple providers offering multiple functionalities. Finally, we have added an arrow from Consultancy and Training to show that the recipient of these services is the end user, as for reasons of space, it is difficult to otherwise denote this.


12

Figure 7 – An example complete value chain for a system


13

Development of business scenariosFollowing the above process, which will be familiar to many business analysts, we need to start developing business scenarios for the exploitation of the system, and this is where the previous work in deriving the value chain pays off. The value chain becomes the basis of the formalisation of scenarios so that each can be discussed in detail without losing track of the central business premise at the heart of the scenario.

In order to elaborate these scenarios, experience has shown the optimum format is a brainstorming workshop where participants can volunteer and generate ideas on-the-fly. The key difference between this and a typical brainstorming workshop is that we do not start from a blank piece of paper, but a complete picture of the value activities of the system. It is recommended that several copies of this are handed to participants at the start of the session.

Whilst many collaborative projects start exploitation assuming that they must control all activities of their value chain and select the generic business model that is most familiar (often open source or a cloud implementation), we must avoid this. Consider that as each activity of our value chain is by definition an activity which creates value, a business scenario could hypothetically be based on any one of them. In theory each activity could be carried out by a separate organisation with its own business model in a complex system. In practice of course it is unlikely any innovative technology could get off the ground requiring such complexity of business relationships to be engineered in advance. This, though, is an academic exercise to generate innovative ideas. Later these ideas can be pragmatically fine-tuned.

The workshop is arranged around answering two questions. The answers to these provide the business scenarios which are the workshop output. The first question is: What parts of the value chain could we deliver as an organisation, leaving other activities to incumbents in the industry or to newcomers?

Already the answer to this question will give us some ideas for shaping possible business scenarios. However, before doing so we should also pose the second question: Of the activities we provide, which is/are the one(s) we base our business model on, and which ones do we provide because we have to?

It is this second question which will give us the greatest variety of business scenarios for our system. There is no single answer to the question and workshop participants should be encouraged to be bold and challenging as possible.

In answering the second question posed above, our exploitation method considers various types of activity. The first distinction of activity types is whether it is a revenue-generation activity (RA) or whether it is merely an obligatory activity (which we term a cost activity, or CA). For example, in our method, in a typical business the product or service that is being sold would be considered a RA activity and the marketing activities used to drive the sales would be classified as a CA activity. However, not all cases are so clear cut. At times the distinction may seem arbitrary if one cannot exist without the other. Nonetheless, merely denoting an activity as RA or CA immediately, and at times subconsciously sets out thought patterns down the path


14

of advertising pitches, pricing models and so on. Whilst in the workshop we don’t want to be overloaded by detail, these thought patterns provide the spark of inspiration leading to coherent and innovative visions.

We have experimented with two approaches to generating business scenarios on top of the value chain through the answering of these questions. Initially participants were given copies of the value chain and invited to generate ideas on top of this to present to the group. This unstructured method had the benefit of introducing new scenarios which at times required changes in the value chain (such as new activities) and led to a greater variety of scenarios. In other projects we took a more structured approach. We generated different versions of the value chain in turn taking each of the different activities as the revenue generator and then tried to work out a scenario which would deliver that RA. The benefit of this is that it was more exhaustive but that it lost some of the spontaneity of the initial approach. This method can also be done in isolation where a brainstorming session was not possible. The recommendation therefore is for the workshop facilitator to start with the spontaneous approach and then to causally introduce to the group the question of how to make the remaining activities as RA activities.

The output of this approach is a series of business scenarios through which the technology can be exploited. We intentionally use the term business scenario rather than business model here because in truth many business models combine business scenarios to have multiple sources of revenue, from different clients. A clear example is newspapers, which charge the readers for content and advertisers for reaching those readers. Hence, a business scenario is considered an element of a business model. As the process continues the scenarios will evolve into business models.

It is by playing with these activities controlled by the main exploiting organisation and the way that they are carried out that we can discover new


Figure 8– An example of experimenting with RA and CA functions

15

business models and more innovative ways of providing the technology. This is exemplified in Figure 8.

In addition to providing a structured approach to business modelling, as we will see later this process provides strong input for analysing longer term strategic concerns such as the balance of power between roles (which could lead to an erosion of profit margins over time) or the potential for vertical integration by other roles on the value chain (i.e. when a company engages in another value activity up or downstream).

When we apply this analysis tool we often find that scenarios can be separated with just a trivial difference (from a business model perspective). For example in the case of exploiting a technology that runs on top of an infrastructure, such as a platform provided as a service (PaaS), the infrastructure can be owned and maintained by the platform provider or just as easily outsourced to a cloud computing provider such as Amazon. This decision does not affect the business model which may be selling access to the platform or selling access to services through the platform, for example. We can say that this is an operational decision whose optimum resolution is determined by factors such as available capital, overall demand, stability of demand and the cost comparison of the two choices. These factors may change over time and lead the company to reverse their initial decision – but without changing the business model. We would designate this activity as an optional cost activity, likewise, training and consultancy is frequently an extra activity which may generate revenues but does not affect the central value proposition of the technology. In this case the decision to offer these services depends on demand and availability. For this reason we could determine this activity to be an option RA value activity. Strictly speaking, the consultancy RA is a separate business scenario which can be combined with other business scenarios to make a final business model. However, its almost ubiquitous presence calls for this short hand.

There is a third distinction of activities. Although we should assume that in all business scenarios all value chain activities are potentially present, in some scenarios we may recognise that the business model is driven by a third party actor or role upon whom the profitability of our exploitation scenario is wholly dependent. We may wish to underline the nature of this role in defining the business scenario. A common example of this is a marketplace. In the case of eBay, the profitability of eBay itself is driven by the trading of goods by third parties outside the control of the eBay company. If we were inventing the business scenario of eBay from scratch, it would be valuable to acknowledge this formally in the model so that subsequent aspects of business planning take this into account. In this example we would designate these third party traders as a “3rd party RA” value activity.

In order to show these different types of value activity pictorially on our value chain, we have adopted the following convention as shown in Figure 9.


16

Figure 9 – Pictorial description of the different value activities

Having generated a set of business scenarios through the experimentation of the RA and CA functions, we have found it useful to identify an analogy in the commercial world. Frequently the scenario appears to be improbable, but just as frequently there is a well known company applying a similar business model. By anchoring the scenarios in a commercial example, analysts gain both intuition and evidence of consequences of the business scenario, and the scenario gains credibility and others will be more receptive to the idea.


17

From business scenarios to business modelsAt this point the method presented above has served its purpose. The next steps in the exploitation process are common to any entrepreneur. One must analyse the scenarios for the long term implications. In the projects we have done this in two phases, paring down the number of scenarios at the end of each phase as the less interesting are rejected. Later compatible scenarios can be combined if desired to make stronger business models. As we will see in the examples from commerce, multiple revenue sources, implying combined scenarios, are common in practice.

In the first phase we are interested solely in what will happen in the long term from a strategic point of view - looking at such issues as long term profitability, the sustainability of the business model and the way we expect the market to react to the new business being proposed. We try to avoid entering in detail in how the business will work, concentrating on if it will work. At the end of this phase we may be able to reject the scenarios which are unviable in the long term. In the second phase, and with a reduced number of scenarios, we will go into the full details required for a business, such as potential partner alliances, marketing plans, financial forecasts and operational and technology development models - effectively the complete business plan. Where a large number of scenarios survived the first phase we did this iteratively until only one or two scenarios remained to become alternative core business models.

The process for these phases is generally familiar to exploitation analysts. In the first phase we try to extrapolate the scenario and draw conclusions on what will be the main strategic issues. Some standard tools exist for this. The PEST (Political, Economic, Social and Technology trends) (or better, PESTLE, including also Environmental and Legal trends) tool provides a good checklist for finding external factors that will shape the market in the future. It is important not to consider the PEST checklist as the end of the analysis: it is the start. How does each trend affect the market, and as a consequence the business and its profitability? Which scenarios are ahead of their time, and which are going to chase a dwindling market? The well-known SWOT (Strengths, Weaknesses, Opportunities and Threats) analysis is another tool for identifying internal characteristics. This can be done from the point of view of the consortium partners driving the exploitation, or from the point of view of the business idea itself (agnostic to the actual participants). Again the typical SWOT matrix is not the end of the analysis, but the start: Which scenarios play to our strengths? Are we weak or strong in the critical success factors of a given scenario? These are key explorations in identifying the long term profitability of the business model. The third tool we recommend is the Porter’s five forces model7. This model, introduced to the management literature by the same Michael Porter who introduced value chain analysis to the literature, analyses the bargaining power of the suppliers and customers and their potential for vertical integration. It also looks at the barriers to entry for new entrants, the rivalry among existing competitors and the potency of substitutes (alternative products which fulfil the same basic need for the customers). This analysis is extremely powerful for exploring such questions as: How will the competitors react? Are profit margins

7 Porter, M.E. (1979) How Competitive Forces Shape Strategy, Harvard business Review, March/April 1979.


18

sustainable? Is there first mover advantage? As mentioned above, at this stage of the analysis, some scenarios may be rejected outright as untenable – for example it is clear that the incumbent market leaders can defend their position too strongly, or that there is very little way to prevent the emergence of a flurry of me-too companies which compete for market share, or that the dominant position of providers or customers would ultimately lead to an erosion of profit as competitors enter a ‘race to the bottom’. In other scenarios these risks can be identified as strategic risks which are manageable.

With the remaining scenarios, potentially significantly reduced from our initial brainstorming session, we should proceed to develop full business plans, as covered in detail in numerous books on the market and in the management literature in general. A number of tools can be used to contrast the business plans on financial grounds to select the most financially profitable one, but these should be coupled with qualitative analysis looking at the risks of the business plan, the partner competencies and the alignment of the business plan with exploiting partner’s core business. Here we recommend tools such as critical success factor analysis, the balanced score card, or the relatively new Osterwalder business model generation method8.

8 Osterwalder, A. & Pigneur, Y., Business Model Generation: a handbook for visionaries, game changers, and challengers, ISBN 978047087641-1, John Wiley & Sons, 2010


19

Example scenarios from commerceIn applying this tool to various projects, a number of business scenarios reoccur on a frequent basis. It is no surprise that these are seen in the commercial domain and can be exemplified with well known companies. In this section we will show how four companies, each following the business model of one of these common scenarios, can be analysed by the method presented in this whitepaper. The analysis shows how playing with the business scenario of each example uncovers other applicable business models – and we show how other companies are indeed basing their business model on these alternatives. The four reoccurring scenarios are: the proprietary model, the open source model, the Freemium model and the Cloud Computing model.

The proprietary modelThe proprietary model has for a long time been the dominant business model in software development. The concept is that the owner of the software issues the right own a copy of the software and to use it under certain conditions in return for a fee. Usually perpetual use is granted for a one-off payment, but only one copy of the software may be installed on the licensee’s hardware per licence granted. Ownership of the license does not give the licensee ownership of the software product and so modifications, copying and distribution are often forbidden.

An example of a proprietary product is Microsoft Windows. A simple value chain constructed with our method is shown below in Figure 10. We have analysed the value activities thus: There are three value activities that serve as inputs: the provision of software (SW), the provision of hardware (HW) and the provision of the operating system (OS). The Operating system provision has three nested activities – the interoperability with hardware, the OS core and the interoperability with hardware. The output of these activities leads to the integrator role. The Integrator combines the three (SW, HW and OS) to provide a product to the user.

We consider that the OS provider judges their RA function to be the core OS and the OS provision in general. They have two related cost activities: interoperability with HW and interoperability with SW. Critical to the success of the OS is the proliferation of software compatible with the Operating System. Without this the OS has limited appeal. Although Microsoft also provides software for use with its operating systems, such as the Microsoft Office suite, they cannot produce every application as some are very niche products and would require an almost infinitely broad range of competences. Furthermore the initial capital required to sufficiently populate the application domain alone increases the financial risk significantly. For these reasons this box has been highlighted as a 3rd party role that adds to the definition of the business scenario. The interoperability functions were labelled as cost activities on the grounds that the business model of Microsoft centres on selling the overall OS and not interoperability. This was something that was nonetheless a business requirement. The other roles are considered third party but not crucial to the business scenario: The integrator role could be provided by the end user – in the early days of computing users did


20

indeed fill this role. In addition the hardware manufacturer role was an established sector prior to the development of Windows and was therefore not necessary to highlight.

Figure 10 – A value chain for Microsoft Windows

When we examine this value chain we could postulate as to what other business scenarios the initial business team could have devised for the profitable exploitation of operating software. For starters they could have developed the OS as a cost and concentrated their business model on the integrator role. Indeed we find that a number of companies profitably fulfil this role. Acer, Compaq and IBM, for example all have strong offerings concentrating on what is essentially the integration activity. Alternatively Microsoft could have provided the OS core for free (a CA) but charged software or hardware vendors for the ability to interact with it (i.e. SW or HW interoperability would be a RA). This model is seen today in practice by Apple. In addition to charges for the iPhone itself, Apple charges software developers for the iPhone a developer fee and a percentage cut for the right to produce compatible software for the iPhone. They also charge carriers who wish to sell the iPhone, such as Verizon (effectively the carrier subsidises the cost of the phone for the user). This is shown below.


21

Figure 11 – Value chain analysis of the iPhone

Yet another play on the activity distribution in the same OS value chain leads to our next example: the open source model.

The Open Source modelThe business model most commonly referred to as the Open Source business model is based on providing the technology for free and charging for the provision of consultancy and training services. However, this is far from the only business logic behind Opens Source software development9.

An example of this model is Canonical Ltd which offers the OS software Ubuntu for free and generates revenues from service provision. As an operating system the value chain is essentially the same as that of the Microsoft example above. However we add the activity of technical support which was not shown in the earlier example. Furthermore, as is seen in Figure 12, as Canonical has vertically integrated into the integrator role, also offering this service to its clients, therefore this is another Revenue Activity.

9 See for example, Henry Chesbrough, “Open Business Models”, Harvard Business School press, 2006, or The 451 Group presentation, “From Support Services to Software Services – The Evolution of Open Source Business Strategies”, presented at the Open Source Business Conference in San Francisco, May 2010.


22

Figure 12 – The value chain for Canonical ltd with an Open Source business model

Cloud ComputingAnother recurring generic business model we find for commercial technology deployments is the ‘-as-a-Service’ delivery model. Cloud computing, composed of Software-, Platform- or Infrastructure-as-a-Service (SaaS, PaaS and IaaS, respectively) is a growing trend in the IT industry. In the example of Figure 13, based on a generic XaaS software deployment we see that in Infrastructure-as-a-Service the provider provides the infrastructure as the RA activity. In the PaaS model the platform is delivered as the RA function, whilst providing the infrastructure is an optional cost activity, and in the SaaS model, the software provision is the RA whilst the platform and infrastructure provision are optional CA activities.


23

Figure 13 – Value chain configurations for the three cloud computing models


24

The Freemium modelOur final generic example is the so-called Freemium model. Freemium is a portmanteau of the words Free and Premium. The concept as a business model is that the basic product is offered for free and revenues are generated from premium services charged to a subset of the users of the free services. An example of the Freemium model is the social networking site LinkedIn. Users have free access to LinkedIn’s profile publishing service, search service and group networking service. There is also limited access to the site’s database of user profiles and personal messaging service. Premium users gain unlimited access to these latter two services. LinkedIn also receives revenues from advertising and from recruitment tools. Let’s take a look at LinkedIn’s value chain as created via our methodology:

Figure 14 – LinkedIn’s value chain

We see that the infrastructure, platform and free services are provided as cost activities whilst the recruitment tools, advertising and premium services are the RA activities. We see a special instance where one actor actually provides two roles in the value chain. In this case the users of LinkedIn are prosumers. A prosumer is an actor which is both a provider and a consumer at the same time.

Leaving apart the term ‘freemium’, which can be a red herring, let’s see how else these arrays of RA and CA activities are used today in the world of social networking. If LinkedIn was to stop charging for premium services and recruitment tools we would arrive at the current business model of social networking site Facebook, which relies solely on advertising services at present. Returning to recruiting, a similar chain would be given for the Italian and Iberian job postings website Infojobs. Here the users are recruiters in the commercial sector and the profile providers are the jobseekers, but again otherwise the value chain is identical. Infojobs has exactly the same RA designations except in that it also charges recruiters for access to the curriculums of jobseekers, making the database provision a RA function. (See Figure 15).


25

What does this tell us? It shows that these three companies are quite similar in value chains, but are deriving money from it in different ways. They can learn from each other. A clear potential revenue stream for Facebook is to copy LinkedIn’s recruitment tools. A foray into market trends and segmentation services/tools analogous could be a good future revenue stream with Facebook having privileged access to personal information of one sixth of the world’s population. LinkedIn could have organised their RA and CA functions to come up with a different business model. Consider that the database was the RA function, as in the case of Infojobs. Under this business model, it is the retrieval of data for which the client is charged. We could imagine LinkedIn users being charged to see profiles of other users. A pay-per-content model like this is present in the value chain that a number of online versions of journals and newspapers are applying. For example Harvard Business Review provides free access to most articles of the current issue online (so content creation and provision are CA activities), but charges for access to archives (the database).

Alternatively consider now that the RA function is the platform provision. Users are asked to subscribe to the platform and in doing so get free access to all the services provided and the


Figure 15 - Analysis of Linkedin leads to the three alternative business scenarios as currently found in Facebook, Infojobs, and wholesale travel brokers.

26

database. This was once the dominant online business model, inherited from the pre-Internet era. It does, however, continue to be a viable business model in some sectors and is a distinct possibility in the social networking sector. Periodically10 rumours circulate that Facebook intends to move to this model, charging users a monthly subscription fee. Although these rumours are false, the number of people duped by them demonstrate that it is a credible scenario.

10 http://www.snopes.com/computer/facebook/fbcharge.asp


http://www.snopes.com/computer/facebook/fbcharge.asp

27

Examples of the method in technology projectsHaving seen the method applied to the established examples from commerce, we now turn to look at some examples from the research domain. We take three examples, all ongoing projects where the process and tools are being applied. We shall see how the technical and non-technical assets of the project have been analysed using our method to generate value chains for those projects, and how on the basis of that several business scenarios have been recognised.

The COIN projectMaterial presented here has been presented in the ICE conference11 and will be presented in detail in the COIN book and at the Future Internet Symposium12.

The COIN project is a large FP7 project of 27 partners. It focuses on building a generic service platform for enterprise collaboration and interoperability services which are anticipated to become an invisible, pervasive and self-adaptive knowledge and business utility.

When starting exploitation methodology described here in this project, the core technology of COIN was represented by the following sketch (Figure 16) showing how a common access point provides access to clouds enterprise interoperability and enterprise collaboration utility platforms and collaboration platforms. Further architectural drawings in increasing levels of detail were available, such as the high level sketch shown in Figure 17.

COIN UtilityPlatform 1




Other EI/ECUtility Platforms



A Cloud of Federated, Open, Trusted EI/ECUtility Platforms

COIN Access PointFront End

COINfor

Auto

VAS1

VAS2

VAS3

VASn

COINfor

Space

VAS1

VAS2

VAS3

VASn

COINfor

Space

VAS1

VAS2

VAS3

VASn

COINGenericPortal

COINfor

BEs

A Cloud of Federated, Open, Trusted EI/ECCollaboration SaaS Platforms

Non-COINEI/EC SaaS

PlatformNon-COIN

EI/EC SaaSPlatform

Non-COINEI/EC SaaS

Platform

Figure 16 – The butterfly cloud model for COIN

11 http://www.ice-conference.org/12 http://www.fis2011.org/


http://www.fis2011.org/

http://www.ice-conference.org/

28

Figure 17 – Architectural map of COIN

There were a number of opinions regarding the exploitation path of the project. Some advocated a cloud-based provision. Others were seeking an open source approach. The exploitation team set out along the methodology described in this paper and elucidated the following value chain.

Infrastructure Provider

Service consumers

Users’ clients

IT Providers

COIN SU platform

COIN VA platform

COIN AP front end

Hardware Provider

Commercial EI / EC SPs

Free EI / EC SPs (SP = service provider)

Service creators

Service discovery

Service Invoking

… …

Prosumers

Consultancy Training

COIN Management

COIN Marketing & Sales

...

Resellers

3rd party platforms

Service provision

Figure 18 – The complete value chain for COIN

We can see the core platform in the centre, composed of horizontal platforms serving a series of vertical chronological value activities relating to the service discovery, ranking and


29

deployment. Upstream value activities included the parallel chains of service creation and provision, and of hardware and infrastructure provision. Downstream activities consisted of IT providers (integration and installation), service consumers, anticipated to be SME clusters or other industry groups, and finally the user’s clients, anticipated to be individuals or individual SMEs. Below the core platform the non-technical support activities were shown, extending to resellers who act on the IT providers and Service consumers, and above the core platform we find consultancy, federated service platforms and the role of the prosumer, described under the discussion of the LinkedIn model.

From this rather complex value chain a number of scenarios were generated. The 8 principal scenarios are shown below:

The first scenario considered that the core platform was the RA. The service provision would be a CA and users would be charged either a subscription to access a remotely hosted platform or platform use would be metered in some way (e.g. as a PaaS).

Figure 19 – COIN ‘Facebook’ scenario (I)

The second scenario considered that the services would become the Revenue Activity whilst the use of the platform would be uncharged. In this scenario the services would be metered under a SaaS model.


30

Figure 20 – COIN ‘Facebook’ Scenario (II)

In both these scenarios we chose Facebook as an analogy because, whilst Facebook is currently free, one could conceive of Facebook introducing a subscription charge (as discussed above) or introducing charges for the use of some services (such as playing games).

The third scenario was anchored to the classic “open source” business model discussed previously. The concept was to provide effectively unlimited use of the platform and services (Cost activities) to users in the hope that revenues from consultancy and training would more than cover the cost of provision.

Figure 21 – COIN ‘Open Source’ scenario

The fourth scenario was somewhat more innovative. The concept was to incorporate the COIN system into smart devices, such as next generation medical devices, to allow interoperability


31

and collaboration between actors in specific sector. COIN would partner with a device provider in order to share a portion of device revenues, whilst providing the platform as a cost. In addition services could be charged for on top of the device charges, or these could be provided for free. We chose the iPhone as the analogy of this scenario.

Figure 22 – COIN ‘iPhone’ scenario

The next scenario was the franchise model. Another innovative model, here it was conceived that third parties could host sector-specific instances of the platform, for example in health, automobile, finance. Services common to these sectors would be provided by third parties under their own business model (mixture of free and SaaS). The COIN partners would receive revenues for the management of the IPR, the marketing and the central management of sector-independent development, similar to the way that franchises work in other sectors.

Figure 23 –COIN ‘franchise’ scenario


32

Next we returned to more established territory with a scenario that considered allowing users unlimited access to the core platform and to allow third parties to develop and sell services to the users. From this, COIN would take a cut of the trade in services. Consequently we anchored this in the most widely known online marketplace: eBay.

Figure 24 – COIN ‘eBay’ scenario

In the seventh scenario we centred on the role of the prosumer. We considered that the trade in services, as per the eBay model, did not have to be carried out in a standard currency such as Euros or dollars. By potentiating the role of the prosumer we could establish a specific currency ‘tokens’ that could be earned or spent consuming and providing resources. Inevitably some actors would consume more than they provided and vice versa. The revenue would be generated by COIN through controlling these transactions. Whilst this may have sounded unconventional, we anchored this to 2nd life, which applied this very same business model to their free virtual world.


33

Figure 25 –COIN ‘bank’ scenario

The final scenario we referred to as the Spotify model, because the concept was to eliminate the centrally hosted platform and to have this installed on the client’s hardware where it would be accessed under a P2P model. As for the music of Spotify, which is not generated by them, merely traded, the services of this scenario would be traded by third parties, with COIN taking a percentage of the transactions. In many ways this then became similar to the eBay model.

Figure 26 – COIN ‘Spotify’ scenario

Having carried out this work across two brainstorming sessions, the scenarios were analysed further. Several were rejected at the first phase (the bank, as it required too much emphasis on the prosumer, Spotify as it was technically complicated to achieve, etc.). When doing the analysis according to our methodology it was found that several participants, who had previously tried to describe their exploitation vision were able to recognise that their visions fit within one of the above scenarios, and consequently could articulate and contrast this with other scenarios. Several of the scenarios, such as the so-called Facebook and eBay models, had previously been raised in prior discussions but due to the inability to formalise the key difference between these scenarios, discussion was difficult. As a result of the workshop project participants were able to clearly signal which of the scenarios they referred to without resorting to complicated phrases and diagrams. In the end of the process the franchise scenario was evolved and the final long term vision of the project is to base the ecosystem that COIN enables on the franchise model. The development of this scenario is directly attributable to the method of this whitepaper, as, at no point prior to the brainstorming sessions had such a business scenario been considered.

A FIRE projectUnder the Future Internet Research and Experimentation (FIRE) objective there are a collection of projects partially-financed by the European Commission focusing on building and using


34

facilities for research into the Future Internet and for research through experimentation. In one such project, the method was used to research sustainability options.

The starting point for the business scenario exploration was discussions with the technical team as to the core technologies of the project and the identification of other assets or competencies that project was building. The value chain was put together from this information, and was significantly less complex than the chain in the previous example from COIN. Initially a more complex value chain was drawn but this was simplified as the granularity was higher than required: scenarios did not make differing use of the finer grained activities.

Figure 27 – FIRE testbed value chain

The value chain is split into two streams. On the bottom we have the testbed facility. This is composed of testbed sites. These are cloud infrastructures. As there are multiple sites we emphasise this with a nested chevron. These are then linked by a broker, which distributes the experiment to the various test sites in accordance with the experimental parameters. In order to provide an interface with the broker, there is a portal and a series of tools (both technical and non-technical) to aid the experimenter. The upper stream is the series of value activities that convert a research hypothesis into an experiment and then to conclusions. The experiment is designed, executed and analysed. The execution phase occurs through the experiment portal and this links the two streams.

From this a number of scenarios were identified. In the first scenario the value proposition offered to the experiments as is that the project will manage a number of test-sites and provide access to them through a portal. We consider that as the key offering is the capability to run experiments through the portal, this is the revenue activity, whilst the provision of test sites and the brokering between them is a cost activity that the facility needs to incur. In this scenario the facility does not assist experimenters with the design or execution of experiments. We called this scenario the Testbed-as-a-Service scenario, in the vein of infrastructure as a service and the XaaS model.


35

Figure 28 – ‘Testbed-as-a-Service’ scenario

The second scenario is effectively the same as the above scenario except that the project does not manage the individual test-sites. The test-sites are 3rd party sites (eg cloud providers) which are federated to the facility through the broker. Again to the experimenter the main value lies in the ability to carry out experiments through the portal so we keep this as our RA. Users are charged according to the resources they use (this is passed on to the providers) and the project charges either a percentage on top or a membership fee.

A more concrete instance of this scenario was also considered. The facility could become a software test facility. Clients would come to the testbed facility in order to test and debug software. This has the same value chain as the more generic testbed-as-a-service model, but would imply certain changes in the strategy: The duration of the testing phase may be considerably longer than in scientific investigation, where experiments attempt to prove a hypothesis, but the range of capabilities demanded would be lower, as the testing would focus on expected operational conditions.

Figure 29 – ‘Testbed provision’ scenario

Next we turned this on its head. If independent cloud sites would join the scheme it would be because they saw the facility as a useful referrer of new business. They would receive a significant amount of revenues from experimenters that they otherwise would not have. This implies that the testbed could take its revenues for itself from the cloud providers – ie the cloud providers would pay in order to be included in the scheme. In this case the brokering becomes the RA and the portal, which merely provides the entry point for experimenters would become a cost activity.


36

Figure 30 – ‘User provision’ scenario

These two scenarios would be delivered in almost identical ways. The final business model based on these scenarios would most likely involve a combination of the scenarios – the facility would charge experimenters a premium as they receive an added value over accessing the cloud sites independently (the heterogeneity and large scale properties, for example – provided by the broker) and also would receive a kick back from the cloud providers for referring clients. The business scenarios being defined by a single RA are different, in the business model, both would be RA activities.

Next we concentrated on the upper stream. Each of the experimental design, execution and analysis steps could be made into a separate business scenario. These in their purest form would be independent of the testbed provision (and indeed could run on any testbed including commercial clouds) and so their value chains just highlighted the single activity as the RA, with no CA present. However it was logical to combine these value propositions into the experiments-as-a-service model. In this model the concept is that the experimenters come with a research hypothesis. The consultants, through their knowledge of both the Internet of Services and the behaviour of available third party testbeds are able to design an experiment which tests the hypothesis. The consultants execute the tests and analyse the data, returning a report to the client stating the outcome: whether the hypothesis was proved, what limitations exist and what further research is recommended. As a consequence all three of these activities are labelled RA.

Figure 31 – The ‘Experiments-as-a-Service’ scenario

This model spawned two further value propositions, more specific than just experimentation as a service, but with the same value chain. In the first instance, we considered the project as a certification body. In this case the client provides suitable software and a list of claims as to its performance, uses and tolerances. The consultants design experiments to confirm that the


37

software meets the claims made about it, find a suitable testbed, execute the tests and analyse the results. The client is given a report summarising whether or not the claims can be upheld. This for example could work in the case of acquisitions of prototype software, or where a project financier requires independent evaluation of developed software, for instance the European Commission with its projects.

The second instance was the benchmarking suite concept. In this case the consultants develop a suite of tools designed to test various performance parameters and limitations of software (speed, reliability, scalability, etc.) and then take a client’s software to discover the boundaries of these parameters through testing on suitable testbeds. The issued report would be used by the client for marketing the product or for reassuring financial backers.

The project went on to analyse various hybrid scenarios to see if the consultancy-based scenarios and the provisioning-based scenarios could be combined. Theoretically these business models are all possible, running as individual offerings (clients choose which activities they want and pay accordingly), as a all-in-one package (a fixed price regardless of whether or not the client uses all activities), or as a cross subsidy (using for example free experimental design to entice users to pay for the use of the facility). Furthermore analysis of the impact of public funding sources in each scenario was carried out, and whether or not there was a value proposition to be made to public bodies for subsidising the facility according to the scenario chosen. At the time of writing, the project is conducting a critical success factor analysis of the scenarios and will use appropriate tools, as discussed above, to further elaborate the scenarios towards more conclusive business plans.

A PaaS interoperability projectIn this FP7 project funded under the Internet of Services objective, research focuses on resolving the semantic interoperability issues that exist in current Clouds platforms and infrastructures and on introducing a user-centric approach for applications which are built upon and deployed using Cloud resources.

The starting point for the analysis was several high level architectural drawings and discussions with the technical team. A generic value chain was drawn up, of which a simplified version is shown below:


38

Figure 32 – Project value chain

The core technology is held in the central system chevron, separated into specific functionalities and the core hub, front end and PaaS search. This interacts with the Platform as a Service (PaaS) provider and the user (the Software-as-a-Service (SaaS) developer). The activities of these two roles are part of a longer stream. The SaaS developer develops their application on the PaaS. In order to provide PaaS interoperability on top of the system, two upstream activities are necessary: the specific platform adapter, which effectively translates the project interface to the specific PaaS (each PaaS has a specific adapter) and prior to that the generic templates for creating the specific adapters. Finally two further activities are consultancy / training and advertising, which could be delivered to the SaaS developer.

The first scenario our brainstorming came up with was what we have labelled in this paper the open source strategy. The idea is that the templates and body of knowledge required to create the specific enablers is released to the public domain. With a minimal cost, the project would endeavour to keep this resource available and up to date. The central system is provided for free, hosted on a remote server and accessed through the Internet. The consultants, the open source community, or the PaaS provider itself is expected to generate the specific adapters for PaaS platforms not covered so far in the project. This could be done for free by users, by companies who charge for this or by the PaaS providers, each with their own motivations. As this is an essential and currently inexistent 3rd party activity, we highlight it as such. Finally the revenues required to cover the cost activities of system provision and the generic platform adaption templates is the RA consultancy and training.


39

Figure 33 – The ‘consultancy’ scenario

The next scenario we discussed was to provide the central hub as a revenue activity. Again generic adaption templates are made available as a CA and 3rd parties are expected to participate in the specific adapters. The value chain is shown below:

Figure 34 – The ‘hub provision’ scenario

Next we reasoned that if the specific platform adaption role was tightly controlled, for example keeping the IPR of generic platform adaption templates proprietary, this could become a consultancy business for the project. The system is provided free but PaaS providers wishing to become involved in the scheme would have to pay the consortium to have their specific adapter coded.


40

Figure 35 – The ‘platform adapter’ scenario

The final two scenarios considered that the RA activities could be the specific and advanced functionalities of the central system, under a freemium model, or that the free provision of the system could be financed through advertising, as shown below.

Figure 36 – The ‘freemium’ scenario


41

Figure 37 – The ‘advertising’ scenario

Nearly all of these scenarios are combinable in some form in order to make an advanced business model. The exception to this is if the project wished to generate its principle revenues from the specific platform adapter, as to allow 3rd parties to compete would be foolish. That said, this could be feasible, provided this is a mere optional service offered with main revenues generated elsewhere.

Faced with such compatible options, one could argue that the project should control all activities, charging for adapters, charging for consultancy, charging for access to the system, and increasing revenues with advertising. However the consortium recognises the danger of being greedy here. As was discussed in the case of Microsoft, the value of an operating system increases with the amount of compatible software, as part of a network effect. It may lead to quicker and more assured growth if the community can be involved to help propel the system to the market. For example, in all of the scenarios the consortium has hosted the central system. However a final scenario the consortium is looking at is to offload this activity to third party organisation. Options include an independent organisation supported by the PaaS industry, advertising or public subsidy, possibly not for profit. This would leave the possibility to become an independent specific platform adapter, or to convert the generic platform adaption template role into the lead RA, for example sublicensing the use of the templates and simultaneously investing in increasing the capability of such adapters.

At the time of writing, the project is looking at the critical success factors of each scenario, the strengths of the consortium and the environmental factors to gauge the most appropriate manner to proceed. A final consideration is that an individual exploitation strategy could be followed, with different partners following the different scenarios according to their organisation’s priorities. Some would become adapters, others consultants, others providers of the system, and so on.


42

ConclusionThis whitepaper has presented a simple yet effective method for identifying business models through value chain analysis. This method has been developed over the course of several collaborative technology research projects. The method can be used to identify, formalise and categorise business models. It can be used to contrast the business models of existing companies with similar value chains and to generate new ones for existing companies or new technologies. When combined with other tools for the analysis of external and internal trends and for the development of business plans it can be part of a powerful strategy for new business development and growth.


43

About

AcknowledgementsThe author would like to acknowledge the exploitation teams in all the various projects where this method has been developed and applied, , and in particular to those from the COIN project. He would also like to thank his colleagues from Atos, James Ahtes, Josep Martrat and Benjamin Gil who helped develop and apply the method presented here.

About the AuthorDaniel Field is a business consultant and project manager working at Atos’ Research and Innovation department. He received a BSc (Hons) in Chemistry and Management from Imperial College London and the Tanaka Business School in 2004 and has a keen interest in business strategy and models. His thesis investigated on the impact of European Union enlargement on business strategy. He joined Atos 2007, having previously worked as an analyst and product developer in the pharmaceutical sector. He has worked with the exploitation teams of several EU funded projects, through which the method of this paper has been developed, including; BEinGRID (FP6), BREIN (FP6), ALADDIN (AAL), COIN (FP7), BonFIRE (FP7) and Optimis (FP7). He is currently also working in the Future Internet Socioeconomics CSA, SESERV (FP7). He is based in Barcelona, Spain. He can be contacted at Daniel.Field[at]Atos.net.

About Atos Research and InnovationAtos Research & Innovation, the company R&D hub located in Spain, is a key reference for the whole group. Thanks to its large expertise in the R&D&I scope, Atos leverages research activities on new technologies inside and outside Atos and takes the research outcomes to customers, introducing innovative elements in their business processes. See http://www.Atosresearch.eu/.

About AtosAtos is an international information technology services company with annual revenues of EUR 8.7 billion and 78,500 employees in 42 countries. Serving a global client base, it delivers hi-tech transactional services, consulting, systems integration and managed services.

Atos is focused on business technology that powers progress and helps organizations to create their firm of the future. It is the Worldwide Information Technology Partner for the Olympic Games and is quoted on the Paris Eurolist Market. Atos operates under the brands Atos, Atos Consulting, Atos Worldline and Atos WorldGrid. See http://Atos.net/en-us/


http://atos.net/en-us/

http://www.atosresearch.eu/

44

License termsThis work is licensed under the attribution-NonCommerial CC BY-NC creative commons license. If you would like to use this work under any other terms please contact the author.

You are free:

to Share — to copy, distribute and transmit the work

to Remix — to adapt the work

Under the following conditions:

Attribution — You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).

Noncommercial — You may not use this work for commercial purposes.

License

THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.

BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.

1. Definitions

a. "Adaptation" means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.

b. "Collection" means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.

c. "Distribute" means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership.

d. "Licensor" means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.

e. "Original Author" means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.

f. "Work" means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works


45

expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.

g. "You" means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.

h. "Publicly Perform" means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.

i. "Reproduce" means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.

2. Fair Dealing Rights. Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.

3. License Grant. Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:

a. to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections;

b. to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";

c. to Distribute and Publicly Perform the Work including as incorporated in Collections; and,

d. to Distribute and Publicly Perform Adaptations.

The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved, including but not limited to the rights set forth in Section 4(d).

4. Restrictions. The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:

a. You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(c), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(c), as requested.

b. You may not exercise any of the rights granted to You in Section 3 above in any manner that is primarily intended for or directed toward commercial advantage or private monetary compensation. The exchange of the Work for other copyrighted works by means of digital file-sharing or otherwise shall not be considered to be intended for or directed toward commercial advantage or private monetary compensation, provided there is no payment of any monetary compensation in connection with the exchange of copyrighted works.

c. If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and, (iv) consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4(c) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply


46

any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.

d. For the avoidance of doubt:i. Non-waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties

through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;

ii. Waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License if Your exercise of such rights is for a purpose or use which is otherwise than noncommercial as permitted under Section 4(b) and otherwise waives the right to collect royalties through any statutory or compulsory licensing scheme; and,

iii. Voluntary License Schemes. The Licensor reserves the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License that is for a purpose or use which is otherwise than noncommercial as permitted under Section 4(c).

e. Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise.

5. Representations, Warranties and Disclaimer

UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.

6. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

7. Termination

a. This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.

b. Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.

8. Miscellaneous

a. Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.

b. Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.

c. If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.

d. No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.

e. This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.


47

f. The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.


Documents

Identification of Business Models Through Value Chain Analysis - A Method for Exploiting Large Technology Projects - A Whitepaper