A Comparative Analysis of Business Model Notations

Although there were many comparative literatures of Business Models, there were not clear comparison criteria. Therefore, these comparisons were fragmented based on different viewpoints. In general, questions on business models can be categorized by interrogatives. In other words, the interrogatives imply a set of key features of business model notations. The feature category of business models using the interrogative will provide a unified way to compare different business models. The paper first defines the fifteen key features of Business Model Notations with five interrogatives. Then we concretely compare typical Business Model Notations based on the key features. The result clarifies the difference of Business Model Notations by using the proposed comparison framework. The result also implies a method to choose appropriate business model notations by using a set of interrogatives which correspond to important questions on business models.


Introduction
As spreading the concept of Business Modeling, many Business Modeling Notations are proposed to describe Business Models. At the same time comparative studies of Business Models also are increasing.
However, there was a problem that previous comparative studies on the Business Modeling approaches use various different criteria. The cause of the problem is there is no unified concrete comparison framework.
Matters of stakeholders who are interested in the business model may be variable. Some stakeholders may want to ask the "How" questions. Other stakeholders may not want to ask "How" questions, but may want to ask "Why" questions. It is useful if we provide a method to choose Business Model Notations based on the set of interrogatives what are important for the stakeholder. In general, questions on business models can be categorized by interrogatives. In other words, the interrogatives implies a set of key features of business model notations. The feature category of business models using the interrogative will provide a unified way to compare different business models. This paper proposes a clear evaluation framework to compare Business Model Notations by using interrogatives. Then ten Business Model Notations are compared by using the proposed comparison framework.
The notations of business modeling have continuously evolved. This section reviews previous researches on business model notations.
soft goals (non-functional requirements), and resources. In setting goals, judging criteria and conditions are clarified, and procedures for achieving goals are defined based on tasks. The i* framework consists of two models-Strategic Dependency (SD) and Strategic Rationale (SR). The SD model is used to analyze interdependencies between actors; the SR model, those within actors. Using these two models, the current operation (as-is) and the operation after system implementation (to-be) are compared and analyzed, and the results can be applied in transforming the business process.
ARM (Actor Relationship Matrix) had been proposed by Yamamoto et al. (2009) to resolve problems to create i* goal models. The business modeling approach using ARM has been discussed in Yamamoto (2016a).  proposed the e-Health business model review method using ARM by analyzing interrelationships among stakeholders. Yamamoto et al. (2018c) proposed a business modeling method for e-Healthcare based on ASOMG analysis. ASOMG stands for Actor, Service, Object, Means and Goal. Although the approach identifies services, objects, means and goals for actors, the interdependency among actors has not been considered. Niven (2006) showed that the Balanced Scorecard (BSC), proposed by Kaplan and Norton (1992), can be used to analyze corporate management strategies using a strategy map and performance evaluation indicators. The strategy map of this approach is a framework based on goal decomposition for developing, implementing, and evaluating strategies in a multidimensional manner from the four perspectives of financial, customer, business processes, and learning and growth (innovation). BSC places strategic goals seen from the financial perspective at the top, and the strategy map is then used to decompose these goals hierarchically into sub-goals-for example, those for achieving the top goal from the customer perspective, those representing business process goals for achieving the customer perspective goals, and those for learning and growth in order to achieve the business process goals. GQM provides questions related to data items for evaluating goal adequacy, and it evaluates whether the goals are achieved by using the answers to those questions as measurement criteria, or metrics. Basili et al. (2010) proposed the GQM+ Strategy Approach as a method for linking business strategies and software development using GQM. This approach links business, software, and projects, and it defines goals using GQM. What makes GQM+ Strategy Approach unique is the way in which it links software for enabling business and that software development project. The strategic goal that an organization is trying to achieve is its business goal; the approach specified by activities in order to achieve the business goal is its strategy.
The Goal Structuring Notation (GSN) (Kelly, 1998) had been used to organize discussions concerning system dependability by structuring them in the form of goals (claims), strategies, assumptions (contexts), and rationales (evidence, solutions). Using the same structure as GSN, Yamamoto (2016b) proposed the BGSN approach to decompose business goals into sub-business goals using the strategy node. The context node is then used to describe rationales for decomposing the goals, such as perspectives, activity procedures, issue status, and the like. CSFs for the business goal are described in the bottom claim, and evidence nodes are used to describe achievements related to KPI values in order to achieve the CSF's. In this way, the BGSN approach employs GSN as is, while also adopting node descriptions for business goals. The meta-model of MBJT has also been proposed. Zhou et al. (2019) proposes an approach for business innovation using EA models. EA has also been used to model healthcare business services. For example, Sharaf et al. (2017) discussed EA in the mobile healthcare cloud service domain. Yamamoto and Zhi (2019) (2015). Although BMM defines the core concepts of business means, end, influencer and assessment, it did not provide visual symbols for these concepts. Gomes et al. (2017) proposed a method to support business continuity process by using ArchiMate.
Yamamoto, Olayan and Morisaki (2018a) suggested the representation levels of EA model might be used to compare the capability of models. This paper uses the representation levels to compare business modeling notations.
The rest of the paper is organized as follows. The comparison framework is proposed in section 2. Section 3 shows a result of the comparison of Business Model Notations using the proposed approach. The effectiveness, novelty and limitations are discussed in section 4. Finally, section 5 concludes the paper.

Method
To compare Business Model Notations, we define the key features according to five interrogatives and representation levels.

The Features of Business Model Notations
Business model describes key elements of businesses. The role of the business model is to capture the economic value of the new technology such as the e-Health solution. We identified the fifteen feature elements using five Interrogatives as shown in Table 1. The "Why" column of Table 1 describes the motivation elements of the business models. The motivation elements are the concerns, goal, and value chain. The concerns show the reasons to create the business goals. The value chain describes the reason why the business succeeds. An example question to ask "Why" feature is why the business model is needed?
The feature examples of the elderly emergency service are as follows.

Concerns: Health and safety
Goal: Safe and secure anytime, anywhere Value chain: Value exchange flow of actors

Where
The "Where" column of Table 1 describes the situations of the business models. The situation elements are the problem, cause, and channel. The problem shall be resolved by analyzing the cause. The channel shows the means to provide the solution. An example question to ask "Where" feature is where the business model is used?
The feature examples of the elderly emergency service are as follows.
Problem: The number of elderly people who are concerned about medical care and nursing care is increasing rapidly.
Cause: Emergency call is difficult anytime, anywhere.
Channel: Home security service channel.

What
The "What" column of are contained in the business model?
The feature examples of the elderly emergency service are as follows.

Asset: Operation center, Nurse
Product: Smart device for emergency call Information: Customer contract, Emergency call record 2.1.5 How The "How" column of Table 1 describes the behavior of the business models. The behavior elements are the business process, customer relationship, and cost structure. An example question to ask "How" feature is how does the business model work?
The feature examples of the elderly emergency service are as follows.
Business process: Customer relationship: Emergency response Cost structure: Smart device development and maintenance cost, Operation center expenses

Representation Levels of Business Model Notations
The five representation levels of notations are defined as follows: 4: the feature is symbolized by a corresponding visual icon.
3: the feature is visualized by using a visual node.
2: the feature is identified by a specific label.
1: the feature is indirectly described.
0: there is no means to describe the feature.

Result
In Notations are compared below using the comparison framework described in section three.
BMC provides specific labels for the partner, asset, channel, cost structure, value chain, business process, goal, customer relationship and customer segment. However, BMC did not provide notations for the problem, cause, concerns, product, and information.
CVCA provides visual symbols for the provider, partner and customer. CVCA also provides specific labels for the channel, cost structure, value chain, business process, customer relationship, product and information. However, CVCA did not provide notations for the problems, cause, concerns, asset, and goal.
e3Value provides visual symbols for the concerns, channel, provider, partner and customer. e3Value also provides specific labels for asset, cost structure, value chain, business process, customer relationship, product and information. However, e3Value did not provide notations for the problems, cause, and goal.
BSC provides visual symbols for the goal. BSC also provides specific labels for the cost structure, business process, customer relationship, and customer. BSC can indirectly describe concerns, channel, provider, partner and asset. However, BSC did not provide notations for the problems, cause, value chain, product and information. BGSN provides the visual symbol for the goal. BGSN can indirectly describe the problem, cause, concerns, provider, partner, customer, customer relationship, asset, channel, value chain, cost structure, and business process. However, BGSN did not provide notations for the product and information.
GQM+ Strategy can describe the cost structure by using the visual node. GQM+ strategy also provides labels for the problem, concerns, provider, partner, business process, goal, and customer. However, GQM+ strategy did not provide notations for the cause, asset, channel, value chain, customer relationship, product and information.
i*framework provides symbols for the provider, partner, asset, business process, goal and customer.
i*framework also provides visual nodes for the concerns, cost structure, channel, value chain, customer relationship, product and information. However, i*framework did not provide notations for the problem and cause.
ARM provides actor labels for the provider, partner, and customer. ARM can indirectly describe the problem, cause, concerns, asset, channel, cost structure, value chain, business process, goal, customer relationship, product and information.
MBJT provides symbols for the problem, cause, provider, customer, goal, and product. MBJT also provides visual nodes for the concerns, channel, value chain, business process, and customer relationship. However, MBJT did not provide notations for the partner, asset and information.
ArchiMate provides symbols for the problem, cause, provider, partner, asset, channel, business process, goal, customer relationship, product and information. It also provides visual nodes for the concerns, cost structure, and value chain. Table 2 shows the result of comparison using the comparison framework in Table 1. The values in Table   2 are the representation level values for the corresponding feature categories. For example, the Interrogative representation levels of BMC are (6, 4, 2, 2, 6) in Table 2.
The result shows that ArchiMate is the most powerful Business Model Notation in the comparison. Let X and Y are as Business Model Notations. X>Y if every feature of X is not smaller than those of Y.
The following expression is derived from the Table 2.
ArchiMate>MBJT, i*framework>e3Value>ARM, (BMC>GQM+Strategy), BGSN, BSC, CVCA Based on the above expression, Figure 1 shows the representational power lattice. The representation power of the upper notations is greater than those of the lower notations in Figure 1.

Discussion
This section discusses the effectiveness, novelty and limitations of the proposed comparison approach.

Effectiveness
The proposed the comparison framework is effectively applied to compare Business Model Notations.
As the comparison task is achieved by counting feature elements based on the five categories, it is easy and concrete. There is no ambiguous decision on the way to evaluate features of Business Modeling Notations.
The features of the comparison framework will be used to clarify the relationship between different Business Modeling categories as shown in Figure

Limitations
The number of compared Business Modeling Notations is ten. It is necessary to compare other Business Process Modeling Notations, such as BPMN, DEMO and URN. We intentionally omitted these Business Process Modeling Notations, because these Notations did not have features than "Who" and "How" features.
The comparison framework only contains conceptual elements. It does not contain the criteria for the relationships between elements. The comparison framework also omits the criteria such as understandability, quality of models, and productivity to develop models. These criteria are difficult to evaluate objectively. Therefore, different research approaches using case studies might be needed.
Moreover, as intuitive opinions of practitioners shall be necessary to evaluate these qualitative criteria.
The result depends on the expertise of practitioners who use Business Model Notations.