《电子商务 E-business》阅读文献_Designing and evaluating e-business models

e ent E-BUsiness Designing and Evaluating E-Business Models Jaap Gordijn and Hans Akkermans, Free University Amsterdam B usiness models are usually represented by a mixture of informal textual, verbal and ad-hoc graphical representations. However, these representations typically limit a clear understanding of the e-business issues that confront the stakeholders and often perpetuate the existing gap between business executives and the lt developers who nust create the e-business information systems. This The value viewpoint article presents a conceptual modeling approach to Requirements engineering entails information This article presents e-business-called e--value--that is designed to help systems analysis from several distinct perspectives define how economic value is created and exchanged Figure I shows what requirements perspectives are an e-business within a network of actors relevant to e-business design: the articulation of the Doing e-business well requires the formulation of economic value proposition( the e-business model), modeling approach an e-business model that will serve as the first step in the layout of business processes that"operational requirements analysis fore-business information sys- ize"the e-business model, and the IT systems archi that combines the tems. The industry currently lacks adequate methods tecture that enables and supports the e-business for for mulating these kinds of requirements. Meth- processes. These perspectives provide a separation rigorous approach of ods from the IT systems analysis domain generally of concerns and help manage the complexity have a strong technology bias and typically do not requirements and design IT'systems analysis eflect business considerations very well. Meanwhile Our emphasis on"the value viewpoint"is a dis- approaches from the business sciences often lack the tinguishing feature of our approach. There are with an economic rigor needed for information systems development. already several good ways to represent business A tighter integration of business and IT modeling process and IT architectural models, but the indus- value perspective from would most certainly benefit the industry, because the try lacks effective techniques to express and analyze integration of business and T systems is already a dis- the value viewpoi tinct feature of e-business. This article shows some We illustrate the use of the e-value methodology ways to achieve this kind of modeling integration. Our with one of the e-business projects where we suc e-value method is based on an economic value- cessfully applied our approach: provisioning a value oriented ontology that specifies what an e-business added news service. A newspaper, which we call the model is made of. In particular, it entails defining, Amsterdam Times for the sake of the example, wants deriving, and analyzing multi-enterprise relationships, to offer to all its subscribers the ability to read arti- business scenarios, and operations requirements in cles online. But the newspaper does not want to pass oth qualitative and quantitative ways. Our e-value on any additional costs to its customers. The idea is approach offers distinct advantages over traditional to finance the expense by telephone connection rev- onintegrated modeling techniques. These advantages enues, which the reader must pay to set up a tel include better communication about the essentials of phone connection for Internet connectivity an e-business model and a more complete under- This can be achieved by two very different e- standing of e-business operations and systems require- business models: the terminating model and the orig- ments through scenario analysis and quantification. inating model. Figures 2 and 3 illustrate these mod- ULYIAUGUST 2001 1094-71671100002001IEEE Authorized licensed use limited to: FUDAN UNIVERSITY. Downloaded on December 21, 2009 at 19: 57 from IEEE Xplore. Restrictions appl

JULY/AUGUST 2001 1094-7167/01/$10.00 © 2001 IEEE 11 Designing and Evaluating E-Business Models Jaap Gordijn and Hans Akkermans, Free University Amsterdam Business models are usually represented by a mixture of informal textual, verbal, and ad-hoc graphical representations. However, these representations typically limit a clear understanding of the e-business issues that confront the stakeholders, and often perpetuate the existing gap between business executives and the IT developers who must create the e-business information systems. This article presents a conceptual modeling approach to e-business—called e3-value—that is designed to help define how economic value is created and exchanged within a network of actors. Doing e-business well requires the formulation of an e-business model that will serve as the first step in requirements analysis for e-business information sys￾tems. The industry currently lacks adequate methods for formulating these kinds of requirements. Meth￾ods from the IT systems analysis domain generally have a strong technology bias and typically do not reflect business considerations very well. Meanwhile, approaches from the business sciences often lack the rigor needed for information systems development. A tighter integration of business and IT modeling would most certainly benefit the industry, because the integration of business and IT systems is already a dis￾tinct feature of e-business. This article shows some ways to achieve this kind of modeling integration. Our e3-value method is based on an economic value￾oriented ontology that specifies what an e-business model is made of. In particular, it entails defining, deriving, and analyzing multi-enterprise relationships, e-business scenarios, and operations requirements in both qualitative and quantitative ways. Our e3-value approach offers distinct advantages over traditional nonintegrated modeling techniques. These advantages include better communication about the essentials of an e-business model and a more complete under￾standing of e-business operations and systems require￾ments through scenario analysis and quantification.1 The value viewpoint Requirements engineering entails information systems analysis from several distinct perspectives. Figure 1 shows what requirements perspectives are relevant to e-business design: the articulation of the economic value proposition (the e-business model), the layout of business processes that “operational￾ize” the e-business model, and the IT systems archi￾tecture that enables and supports the e-business processes. These perspectives provide a separation of concerns and help manage the complexity of requirements and design. Our emphasis on “the value viewpoint” is a dis￾tinguishing feature of our approach. There are already several good ways to represent business process and IT architectural models, but the indus￾try lacks effective techniques to express and analyze the value viewpoint. We illustrate the use of the e3-value methodology with one of the e-business projects where we suc￾cessfully applied our approach: provisioning a value￾added news service. A newspaper, which we call the Amsterdam Times for the sake of the example, wants to offer to all its subscribers the ability to read arti￾cles online. But the newspaper does not want to pass on any additional costs to its customers. The idea is to finance the expense by telephone connection rev￾enues, which the reader must pay to set up a tele￾phone connection for Internet connectivity. This can be achieved by two very different e￾business models: the terminating model and the orig￾inating model. Figures 2 and 3 illustrate these mod￾This article presents an e-business modeling approach that combines the rigorous approach of IT systems analysis with an economic value perspective from business sciences. Intelligent E-Business Authorized licensed use limited to: FUDAN UNIVERSITY. Downloaded on December 21, 2009 at 19:57 from IEEE Xplore. Restrictions apply

I n f e Ili g e n f usIness Requireme Stakeholders Requiremen equirement els. Many features and implications of these viewpoint representation e-business models were difficult to discover during the project without help from our model representations. Our graphical model ing constructs are visualizations of constructs COs taken from the e-value ontology, which we Marketeers e-value ontology and UCM discuss in the"The e3-value Ontology"side- Customers bar. Our scenario techniques are based on Use Case Maps, which we outline in the"Use 部 Case Maps for E-Business"sidebar. In Figure 2, by following the colored sce- nario path, you can see which values must be UML exchanged if an Amsterdam Times reader Tactical Processes. workers Activity diagrams wants to read an article online. The reader must information, goods Sequence diagrams and control flows exchange value with two parties. First, the management High-level Petri Nets reader receives an article online from the ams- terdam Times, and in return presents a termi- Class diagrams nation possibility. Termination means that if State transition diagrams someone tries to set up a telephone connection by dialing a telephone number, another actor architecture IT department Hard/software, components, .Interaction diagrams System must pick up the phone. If someone is willing viewpoint data and control flows code organization Architecture description to terminate a large quantity of telephone calls, most telecommunication operators will pay actor for that. Because of its large subscribe Figure 1. For the development of e-business information systems, three distinct base, the Amsterdam Times has the potential perspectives are important: the value viewpoint represents the way economic value is to generate numerous terminations represents the value viewpoint in terms of business processes; and the system oint Second, in Figure 2, the reader pays the local operator (Last Mile)a fee for a telephone architecture viewpoint represents the information systems that enable and support connection. This fee is partly used to pay the telco data runner for interconnection and eventually the Amsterdam Times for termi- ng traffic For hosting services, the terdam Times pays a hosting fee to Hoster. For the entire transaction to be a zero-cost opera tion for the amsterdam Times. the received stimulus termination fees must be larger in total than the paid Internet service provisioning fe model is that the local operator Last Mile sets segment the price for the service mainly provided by Telephone connection the Amsterdam Times, the company that connection owns the content. Figure 2 shows the legend Scenario of the graphical constructs in separate boxes. Local These constructs are graphical representa- Termination Article tions of concepts from our e3-value ontology for e-business models. Note that in figure 2 value Interconnection join we only represent exchanges between nge Termination objects that are of value to actors; we do not represent business processes or information Stop system components exchanging information. Terminatio stimulus In contrast to Figure 2. Figure 3 illustrates how the reader directly pays for the Amster- value interface dam Times. The newspaper, in turn, pays the ISP(Hoster)and long distance carrier(Data Actor - Amsterdam Times Runner). The long distance carrier pays the local loop provider(Last Mile). In this model, Amsterdam Times sets the price Figure 2. The terminating e-business model stead of Last mile computer.org/intelligent IEEE INTELLIGENT SYSTEMS Authorized licensed use limited to: FUDAN UNIVERSITY. Downloaded on December 21, 2009 at 19: 57 from IEEE Xplore. Restrictions appl

els. Many features and implications of these e-business models were difficult to discover during the project without help from our model representations. Our graphical model￾ing constructs are visualizations of constructs taken from the e3-value ontology, which we discuss in the “The e3-value Ontology” side￾bar. Our scenario techniques are based on Use Case Maps, which we outline in the “Use Case Maps for E-Business” sidebar. In Figure 2, by following the colored sce￾nario path, you can see which values must be exchanged if an Amsterdam Times reader wants to read an article online. The reader must exchange value with two parties. First, the reader receives an article online from the Ams￾terdam Times, and in return presents a termi￾nation possibility. Termination means that if someone tries to set up a telephone connection by dialing a telephone number, another actor must pick up the phone. If someone is willing to terminate a large quantity of telephone calls, most telecommunication operators will pay an actor for that. Because of its large subscriber base, the Amsterdam Times has the potential to generate numerous terminations. Second, in Figure 2, the reader pays the local operator (Last Mile) a fee for a telephone connection. This fee is partly used to pay the telco Data Runner for interconnection and eventually the Amsterdam Times for termi￾nating traffic. For hosting services, the Ams￾terdam Times pays a hosting fee to Hoster. For the entire transaction to be a zero-cost opera￾tion for the Amsterdam Times, the received termination fees must be larger in total than the paid Internet service provisioning fees. A specific property of this e-business model is that the local operator Last Mile sets the price for the service mainly provided by the Amsterdam Times, the company that owns the content. Figure 2 shows the legend of the graphical constructs in separate boxes. These constructs are graphical representa￾tions of concepts from our e3-value ontology for e-business models. Note that in Figure 2 we only represent exchanges between objects that are of value to actors; we do not represent business processes or information system components exchanging information. In contrast to Figure 2, Figure 3 illustrates how the reader directly pays for the Amster￾dam Times. The newspaper, in turn, pays the ISP (Hoster) and long distance carrier (Data Runner). The long distance carrier pays the local loop provider (Last Mile). In this model, Amsterdam Times sets the price instead of Last Mile. 12 computer.org/intelligent IEEE INTELLIGENT SYSTEMS Intelligent E-Business Requirement viewpoint Stakeholders involved Requirement viewpoint focus Requirement viewpoint representation Business value viewpoint C*O's Marketeers Customers Values, actors, exchanges e3–value ontology and UCM scenarios Business process viewpoint Tactical marketeer, Operational management Processes, workers, information, goods, and control flows UML • Activity diagrams • Sequence diagrams • Interaction diagrams High-level Petri Nets System architecture viewpoint IT department Hard/software, components, data and control flows, code organization UML • Class diagrams • State transition diagrams • Sequence diagrams • Interaction diagrams • Deployment diagrams Architecture description languages Figure 1. For the development of e-business information systems, three distinct perspectives are important: the value viewpoint represents the way economic value is created, exchanged, and consumed in a multi-actor network; the process viewpoint represents the value viewpoint in terms of business processes; and the system architecture viewpoint represents the information systems that enable and support e-business processes. Reader r 1 Legend Market segment Scenario segment Value object Value exchange Value port Value interface Actor Newspaper: Amsterdam Times TelCo/ISP: Data Runner & Hoster Article online Termination Local operator: Last Mile Termination Termination fee ISP ISP fee Interconnection Telephone connection Telephone connection fee Interconnection fee Stop stimulus AND join Start stimulus AND fork Figure 2. The terminating e-business model. Authorized licensed use limited to: FUDAN UNIVERSITY. Downloaded on December 21, 2009 at 19:57 from IEEE Xplore. Restrictions apply

TelCo/ISP. Readers Amsterdam Times Data Runner& Hoster Last mile The value ontology Our ontology and scenario techniques Article fee suitable for value-based business modeling n general-let us represent objects of eco- nomic value that are created, exchanged, and consumed. Multiple actors typically create Article online Interconnection access innovative products, so our ontology can rep- resent a network of actors that together offer a complex product or service consisting of separate products and services. Furthermore Figure 3. The originating e-business model our ontology explicitly represents who doing business with whom, in contrast to the specific e-business risks for traditional sell- prices themselves but the actors who select value chain and constellation approaches ers. For instance, intermediaries, such as bro- the service or product Modeling the actors from business science.2.The value chain and kers and marketplaces, might easily appear who make the selections is important because constellation approaches show how value is and disappear in e-business projects. Buyers e-business may decrease switching costs added along a chain, which is different from might decide to use a middle person to and increases market transparency, thereby who is doing business with whom. ncrease their combined buying power and allowing buyers to select other suppliers In e-business projects, it is important to achieve a better negotiation position. Show- more easily show the exchange of value objects between ing who is doing what with whom is impor- When designing e-value, we opted for a specific actors, because new parties can be tant because e-business is immensely more lightweight approach that could be graphically relatively easily added to or removed from flexible than traditional business. expressed to communicate our ontology eas- the buyer chains. This process of dis- Our approach is also capable of modeling ily to intended users. We believe the industr intern d intermediation presents power elements. We can model not only the needs a lightweight approach because of the The e3-value Ontology of these concepts with formal systems theory ontology The or on no ports at all th-s of the ce objects. A value offering Our e-business ontology-which we have described exten changes in return for othe sively elsewhere'-is based on concepts derived from recent should obey the semanti onnected value interface economic and business science literature We combined several Values are exchang gh a value interface on all its ports ontology components have graphical representations that Market segment. A market segment is a concept that make our model particularly well suited to lightweight use breaks a market (consisting of actors )into segments that share or diagramming purposes, you can download a Visio tool common properties. Accordingly, our concept of market seg encilfromourWebsiteatwww.cs.vu.nl/-gordijn/research ent shows a set of actors that for one or more of their value htm. What follows are some definitions of terms and concepts interfaces, value objects equally we employ in our model Composite actor. For providing a particular service, several Actor. An actor is an independent economic (and ofte actors might decide to work together and to offer objects of legal)entity. By carrying out value activities, an actor makes a value jointly by using one value interface to their environment. profit or increases its utility. In a sound, viable, e-business We call such a partnership a composite actor. odel, each actor should be capable of making a profit. Value activity. An actor performs a value activi Value object. Actors exchange value objects, which are ser- or to increase its utility. The value activity is included es, products, money, or even consumer experiences. A value ontology to discuss and design the assignment of va object is valuable to one or more actors. ties to actors. As such we are interested in collectin Value port. An actor uses a value port to show that it wants that can be assigned as a whole to actors. Consequently, such to provide or request value objects. The concept of port an activity should be profitable or increase utility. ables us to abstract away from the internal business processes and focus only on how external actors and other Ref ference Value interface. Actors have one or more value interfaces, 1. J Gordijn, JM.Ak and J.C. van Vliet, "Whats in an Elec- grouping individual value ports. A value interface shows the tronic Business Model, "Proc. Knowledge Engineering a alue object an actor is willing to exchange in return for another value object through its ports. The exchange of value Berlin2000,vol.LnaI1937,pp.257-273;www.cs.vu.nl/gordijn objects is atomic at the level of the value interface. (current 3 July 2001) Value exchange. A value exchange connects two value 2. W.N. Borst, J.M. mans, and J.L. Top, "Engineer ports with each other. It represents one or more potentia nt⊥ Human trades of value objects between value ports ter Studies, vol 46, 1997, pp 36 Value offering. A value offering is a set of value exchanges 3. P Kotler, Marketing ment: Analysis, Planning, Implementa- that shows which value objects are exchanged via value tion, and Control, Prentice Hall, Englewood Cliffs, N.J., 1988 JULYIAUGUST 2001 computer.org/intelligent Authorized licensed use limited to: FUDAN UNIVERSITY. Downloaded on December 21, 2009 at 19: 57 from IEEE Xplore. Restrictions appl

JULY/AUGUST 2001 computer.org/intelligent 13 The value ontology Our ontology and scenario techniques— suitable for value-based business modeling in general—let us represent objects of eco￾nomic value that are created, exchanged, and consumed. Multiple actors typically create innovative products, so our ontology can rep￾resent a network of actors that together offer a complex product or service consisting of separate products and services. Furthermore, our ontology explicitly represents who is doing business with whom, in contrast to the value chain and constellation approaches from business science.2,3 The value chain and constellation approaches show how value is added along a chain, which is different from who is doing business with whom. In e-business projects, it is important to show the exchange of value objects between specific actors, because new parties can be relatively easily added to or removed from the buyer-seller chains. This process of dis￾intermediation and intermediation presents specific e-business risks for traditional sell￾ers. For instance, intermediaries, such as bro￾kers and marketplaces, might easily appear and disappear in e-business projects. Buyers might decide to use a middle person to increase their combined buying power and achieve a better negotiation position. Show￾ing who is doing what with whom is impor￾tant because e-business is immensely more flexible than traditional business. Our approach is also capable of modeling power elements. We can model not only the prices themselves but the actors who select the service or product. Modeling the actors who make the selections is important because e-business may decrease switching costs and increases market transparency, thereby allowing buyers to select other suppliers more easily. When designing e3-value, we opted for a lightweight approach that could be graphically expressed to communicate our ontology eas￾ily to intended users. We believe the industry needs a lightweight approach because of the Our e-business ontology—which we have described exten￾sively elsewhere1—is based on concepts derived from recent economic and business science literature. We combined several of these concepts with formal systems theory ontology.2 The ontology components have graphical representations that make our model particularly well suited to lightweight use. For diagramming purposes, you can download a Visio tool stencil from our Web site at www.cs.vu.nl/~gordijn/research. htm. What follows are some definitions of terms and concepts we employ in our model. Actor. An actor is an independent economic (and often legal) entity. By carrying out value activities, an actor makes a profit or increases its utility. In a sound, viable, e-business model, each actor should be capable of making a profit. Value object. Actors exchange value objects, which are ser￾vices, products, money, or even consumer experiences. A value object is valuable to one or more actors. Value port. An actor uses a value port to show that it wants to provide or request value objects. The concept of port enables us to abstract away from the internal business processes and focus only on how external actors and other components of the e-business model can be plugged in. Value interface. Actors have one or more value interfaces, grouping individual value ports. A value interface shows the value object an actor is willing to exchange in return for another value object through its ports. The exchange of value objects is atomic at the level of the value interface. Value exchange. A value exchange connects two value ports with each other. It represents one or more potential trades of value objects between value ports. Value offering. A value offering is a set of value exchanges that shows which value objects are exchanged via value exchanges in return for other value objects. A value offering should obey the semantics of the connected value interfaces: Values are exchanged through a value interface on all its ports or on no ports at all. Market segment. A market segment is a concept that breaks a market (consisting of actors) into segments that share common properties.3 Accordingly, our concept of market seg￾ment shows a set of actors that for one or more of their value interfaces, value objects equally. Composite actor. For providing a particular service, several actors might decide to work together and to offer objects of value jointly by using one value interface to their environment. We call such a partnership a composite actor. Value activity. An actor performs a value activity for profit or to increase its utility. The value activity is included in the ontology to discuss and design the assignment of value activi￾ties to actors. As such, we are interested in collecting activities that can be assigned as a whole to actors. Consequently, such an activity should be profitable or increase utility. References 1. J. Gordijn, J.M. Akkermans, and J.C. van Vliet, “What’s in an Elec￾tronic Business Model,” Proc. Knowledge Engineering and Knowl￾edge Management, 12th Int’l Conf. (EKAW 2000), Springer Verlag, Berlin, 2000, vol. LNAI 1937, pp. 257–273; www.cs.vu.nl/˜gordijn (current 3 July 2001). 2. W.N. Borst, J.M. Akkermans, and J.L. Top, “Engineering Ontologies,” Int’l J. Human-Computer Studies, vol. 46, 1997, pp 365–406. 3. P. Kotler, Marketing Management: Analysis, Planning, Implementa￾tion, and Control, Prentice Hall, Englewood Cliffs, N.J., 1988. The e3 -value Ontology Readers Newspaper: Amsterdam Times TelCo/ISP: Data Runner & Hoster Article online Article fee ISP ISP fee Access Access fee Interconnection fee Interconnection access Local operator: Last Mile Figure 3. The originating e-business model. Authorized licensed use limited to: FUDAN UNIVERSITY. Downloaded on December 21, 2009 at 19:57 from IEEE Xplore. Restrictions apply

Use Case Maps for E-Business We adapted use case maps' for e-business purposes in con- AND fork splits a scenario path into two or more subpaths, junction with our ontology-based diagramming approach. This while the AND join collapses subpaths into a single path. An sidebar charts some of the most important adapted concepts. OR fork models a continuation of the scenario path into one Scenario path. A scenario path consists of one or more seg- direction that is to be chosen from several alternatives. The OR ments related by connection elements and start-and-stop stim- join merges two or more paths into one path. Finally, the uli. A path indicates which value interfaces objects of value direct connection interconnects two individual segments. A must be exchanged as a result of a start stimulus or as the scenario path must obey the semantics of the value interface result of exchanges through other value interfaces. connected by value exchanges: Either objects are exchange Stimulus. A scenario path starts with a start stimulus, which on all its ports or on none at all. To illustrate this, these parts of represents an initiating event caused, for example, by an actor. the scenario path are colored green, while other scenario seg The last segment of a scenario path is connected to a stop ments are colored red tumulus. a stop stimulus indicates that the scenario path ends Segment. A scenario path has one or more segments. Seg- Reference ments relate value interfaces to each other(through connec- tion elements, for example) to show that an exchange on one 1. R.J.A.Buhr, "Use Case Maps as Architectural Entities for Complex value interface causes an exchange on another value interface Systems, "IEEE Trans. Software Eng, voL 24, no. 12, 1998, pp Connection Connections relate individual segments. An 1131-1155 general agility of e-business projects them Start selves. Most e-business development projects are done very quickly, so having a model that can help rapidly define, explore, and execute a business idea can provide a distinct advan- age over traditional modeling techniques. 4 Market Read article The heavyweight ontologies like Toronto TOVE and Edinburgh Enterprise do not Telephone come with graphical scenario methods connection Another important difference between the e-value ontology and traditional business ontologies is that the traditional ontologies Mile Handle local tend to focus on business processes(distin- Termination guished as a separate viewpoint in Figure 1) rather than on economic value. Our ontology connection based graphical approach should not be con- online connection fused with formal approaches such as the uni- Actor- Amsterdam Times c fied modeling language or other approaches that rely on activity, sequence, or state dia- Termination Article grams. Such techniques do not semantically value represent the exchange of ece onomic value erace which we have discussed elsewhere exten- 2 traffic Article sively. With some effort, it is possible to use UML stereotypes and packages to map most of our ontology constructs onto UML con- structs, but doing so is merely syntacticaL Value Analyzing alternative models Hosting news we instantiate our ontology concepts and articles. Hosting fee. relations for specific use cases. Doing so pro- Hoste vides a basis for analyzing the characteristic and implications of alternative e-business business models and then detailed the mos Figure. 4. A more detailed version of the terminating e-business model. Data Runner d Hoster form a partnership to offer long distance traffic and Internet service romising ones, as figures 4 and 5 show provisioning to Amsterdam Times. The companies decide to have one shared-value interface, thereby offering hosting and Internet access jointly as a bundle for a single The terminating model price, which this model assumes to be cheaper than obtaining the products separately. We enhanced the terminating model Hoster collocates its hardware(servers, access devices, and so forth)on Data Runners shown in Figure 2 into the more detaile network, thereby avoiding costly connections between Hoster and Data Runner. approach shown in Figure 4. The money 14 computer.org/intelligent IEEE INTELLIGENT SYSTEMS Authorized licensed use limited to: FUDAN UNIVERSITY. Downloaded on December 21, 2009 at 19: 57 from IEEE Xplore. Restrictions appl

14 computer.org/intelligent IEEE INTELLIGENT SYSTEMS general agility of e-business projects them￾selves. Most e-business development projects are done very quickly, so having a model that can help rapidly define, explore, and execute a business idea can provide a distinct advan￾tage over traditional modeling techniques.4 The heavyweight ontologies like Toronto TOVE5 and Edinburgh Enterprise6 do not come with graphical scenario methods. Another important difference between the e3-value ontology and traditional business ontologies is that the traditional ontologies tend to focus on business processes (distin￾guished as a separate viewpoint in Figure 1) rather than on economic value. Our ontology￾based graphical approach should not be con￾fused with formal approaches such as the uni￾fied modeling language or other approaches that rely on activity, sequence, or state dia￾grams. Such techniques do not semantically represent the exchange of economic value, which we have discussed elsewhere exten￾sively.7 With some effort, it is possible to use UML stereotypes and packages to map most of our ontology constructs onto UML con￾structs, but doing so is merely syntactical. Analyzing alternative models When developing a specific business idea, we instantiate our ontology concepts and relations for specific use cases. Doing so pro￾vides a basis for analyzing the characteristics and implications of alternative e-business models. Initially, we developed several global business models and then detailed the most promising ones, as Figures 4 and 5 show. The terminating model We enhanced the terminating model shown in Figure 2 into the more detailed approach shown in Figure 4. The money We adapted use case maps1 for e-business purposes in con￾junction with our ontology-based diagramming approach. This sidebar charts some of the most important adapted concepts. Scenario path. A scenario path consists of one or more seg￾ments related by connection elements and start-and-stop stim￾uli. A path indicates which value interfaces objects of value must be exchanged as a result of a start stimulus or as the result of exchanges through other value interfaces. Stimulus. A scenario path starts with a start stimulus, which represents an initiating event caused, for example, by an actor. The last segment of a scenario path is connected to a stop stimulus. A stop stimulus indicates that the scenario path ends. Segment. A scenario path has one or more segments. Seg￾ments relate value interfaces to each other (through connec￾tion elements, for example) to show that an exchange on one value interface causes an exchange on another value interface. Connection. Connections relate individual segments. An AND fork splits a scenario path into two or more subpaths, while the AND join collapses subpaths into a single path. An OR fork models a continuation of the scenario path into one direction that is to be chosen from several alternatives. The OR join merges two or more paths into one path. Finally, the direct connection interconnects two individual segments. A scenario path must obey the semantics of the value interface connected by value exchanges: Either objects are exchanged on all its ports or on none at all. To illustrate this, these parts of the scenario path are colored green, while other scenario seg￾ments are colored red. Reference 1. R.J.A. Buhr, ”Use Case Maps as Architectural Entities for Complex Systems,” IEEE Trans. Software Eng., vol. 24, no. 12, 1998, pp. 1131–1155. Use Case Maps for E-Business Reader r 1 Read article Legend Market segment Scenario segment Value object Value offering Value exchange Value interface Value activity Actor Publishing Amsterdam Times Article online Termination Last Mile Handle local loop traffic Termination Termination fee Internet access Internet access fee Access Hosting Hosting fee Hosting Hoster OR Fork Article fee Article Provide online news articles Inter connection Data Runner Telephone connection Telephone connection fee Inter connection fee Stop stimulus Composite actor Value port Start stimulus AND fork Handle long distance traffic Inet access fee Provide internet access Figure. 4. A more detailed version of the terminating e-business model. Data Runner and Hoster form a partnership to offer long distance traffic and Internet service provisioning to Amsterdam Times. The companies decide to have one shared-value interface, thereby offering hosting and Internet access jointly as a bundle for a single price, which this model assumes to be cheaper than obtaining the products separately. Hoster collocates its hardware (servers, access devices, and so forth) on Data Runner’s network, thereby avoiding costly connections between Hoster and Data Runner. Authorized licensed use limited to: FUDAN UNIVERSITY. Downloaded on December 21, 2009 at 19:57 from IEEE Xplore. Restrictions apply

flow in the terminating model is initially parable objects of value to their environment. ure 4, we illustrate this graphically using an between the reader and Last Mile, which is Each partnership consists of several acting OR fork in the scenario path, which models only responsible for the local loop data traf- participants. The two partnerships are not the Amsterdam Times' service selection. fic. All other money flows are generated from grouped into a market segment, because the the money Last Mile earns. way in which partnerships value the objects The originating mode Actors might decide to offer or request will differ. In the originating e-business model, illus- objects of value only as a bundle. Bundling The Amsterdam Times can choose, on a trated in a more detailed version in Figure 5, and unbundling in general is a key e-business per-scenario-execution basis, from two dif- we reversed the revenue causality. A start strategy that works especially well for digi- ferent partnerships to offer the article online, stimulus from the reader now causes value tal products and services. You can clearly rep- essentially from an access or a hosting per exchanges at the interface of the amsterdam resent bundling with our methodology For spective. The Amsterdam Times does not Times, which leads to the need to buy Inter- example, in the terminating model, the online want to depend on one provider for access net access and hosting and in turn leads to article, telephone connection, termination, and hosting altogether. By distributing the local loop access. nd connection fee are bundled into one amount of data traffic over these two In the originating model, the reader only value interface from the readers perspective. providers, the Amsterdam Times controls the sees the Amsterdam Times and does not see In this case, the value interface illustrates that distribution of revenues for the two compos- Last Mile. Also, the reader pays the Amster- the reader only actually values an article ite actors and motivates both partnerships to dam Times directly for everything needed to online and a telephone connection in combi- deliver a high-level quality of service. In Fig- read an article online. Because the reader nation with each other. In other words. an online article orthless without the required telephone connection to provide access to it. Because we bundle these value bjects, and because a reader needs to offer Read article a compensation for these objects as a whole. Reader we consider all these objects to be part of the same value interface If a customer buys a product from only one seller regularly, the seller builds a rela fee tionship with that customer and thus- according to our model- owns"the cus- b)、Ate tomer. Owning a customer is important, because it lets a seller offer that customer Amsterdam Provide online news article Publishing more personalized products. If an offering is Article between two actors (a seller and a buyer), the seller owns the buyer for that offering. How- ever, if an offering ns more than one Hosting seller, customer ownership will be parti- tioned For the terminating business model considered here, the reader has to exchange values with the amsterdam times and last Mile. Last Mile is the only party that actu ally receives payment for the delivered ser Access vice. In this case. our model sees this as a shift in customer ownership from the Ams- a accessRunner edam Times to Last Mile, which might be Tee? services unwanted from the Amsterdam Times'point of view In terms of price, Last Mile is in control onnection here. The reader pays for the entire serv delivered through Last Mile. Unfortunately, no one except Last Mile and perhaps a mar ket regulation authority can actually influ Handle local Mile oop traffic ence the pricing structure. Consequently, the uccess of the e-business model depends largely on Last Mile Figure 5. A more detailed version of the originating e-business model. In this mode Figure 4 shows two partnerships or com- the newspaper sets the price of telephone access and gets paid accordingly. Also, Data posite actors. These partnerships are equiv- Runner now offers both the handling of long distance traffic and Internet service alent, in one sense, because they offer com- provisioning ULY 1UST 2001 computer.org/intelligent 15 Authorized licensed use limited to: FUDAN UNIVERSITY. Downloaded on December 21, 2009 at 19: 57 from IEEE Xplore. Restrictions appl

JULY/AUGUST 2001 computer.org/intelligent 15 flow in the terminating model is initially between the reader and Last Mile, which is only responsible for the local loop data traf￾fic. All other money flows are generated from the money Last Mile earns. Actors might decide to offer or request objects of value only as a bundle. Bundling and unbundling in general is a key e-business strategy that works especially well for digi￾tal products and services. You can clearly rep￾resent bundling with our methodology. For example, in the terminating model, the online article, telephone connection, termination, and connection fee are bundled into one value interface from the reader’s perspective. In this case, the value interface illustrates that the reader only actually values an article online and a telephone connection in combi￾nation with each other. In other words, an online article is worthless without the required telephone connection to provide access to it. Because we bundle these value objects, and because a reader needs to offer a compensation for these objects as a whole, we consider all these objects to be part of the same value interface. If a customer buys a product from only one seller regularly, the seller builds a rela￾tionship with that customer and thus— according to our model—“owns” the cus￾tomer. Owning a customer is important, because it lets a seller offer that customer more personalized products. If an offering is between two actors (a seller and a buyer), the seller owns the buyer for that offering. How￾ever, if an offering contains more than one seller, customer ownership will be parti￾tioned. For the terminating business model considered here, the reader has to exchange values with the Amsterdam Times and Last Mile. Last Mile is the only party that actu￾ally receives payment for the delivered ser￾vice. In this case, our model sees this as a shift in customer ownership from the Ams￾terdam Times to Last Mile, which might be unwanted from the Amsterdam Times’ point of view. In terms of price, Last Mile is in control here. The reader pays for the entire service delivered through Last Mile. Unfortunately, no one except Last Mile and perhaps a mar￾ket regulation authority can actually influ￾ence the pricing structure. Consequently, the success of the e-business model depends largely on Last Mile. Figure 4 shows two partnerships or com￾posite actors. These partnerships are equiv￾alent, in one sense, because they offer com￾parable objects of value to their environment. Each partnership consists of several acting participants. The two partnerships are not grouped into a market segment, because the way in which partnerships value the objects will differ. The Amsterdam Times can choose, on a per-scenario-execution basis, from two dif￾ferent partnerships to offer the article online, essentially from an access or a hosting per￾spective. The Amsterdam Times does not want to depend on one provider for access and hosting altogether. By distributing the amount of data traffic over these two providers, the Amsterdam Times controls the distribution of revenues for the two compos￾ite actors and motivates both partnerships to deliver a high-level quality of service. In Fig￾ure 4, we illustrate this graphically using an OR fork in the scenario path, which models the Amsterdam Times’ service selection. The originating model In the originating e-business model, illus￾trated in a more detailed version in Figure 5, we reversed the revenue causality. A start stimulus from the reader now causes value exchanges at the interface of the Amsterdam Times, which leads to the need to buy Inter￾net access and hosting and in turn leads to local loop access. In the originating model, the reader only sees the Amsterdam Times and does not see Last Mile. Also, the reader pays the Amster￾dam Times directly for everything needed to read an article online. Because the reader Reader r 1 Read article Amsterdam Times Article online Interconnection access Interconnection fee Handle local loop traffic Access Hosting fee Hosting Host Web services Article fee Article fee Article The Last Mile Inet access Inet access fee Inet access fee Provide physical access Data Runner Physical access fee Physical access Provide internet access Provide online news article Publishing Figure 5. A more detailed version of the originating e-business model. In this model, the newspaper sets the price of telephone access and gets paid accordingly. Also, Data Runner now offers both the handling of long distance traffic and Internet service provisioning. Authorized licensed use limited to: FUDAN UNIVERSITY. Downloaded on December 21, 2009 at 19:57 from IEEE Xplore. Restrictions apply