2b Business Model HTML

8/6/2019 2b Business Model HTML

1/28

COMET - Business model

Table of contents

1 Introduction........................................................................................................................ 3

2 Modelling framework for the business model....................................................................4

3 The context statement.........................................................................................................5

3.1 Modelling objectives......................................................................................................5

3.2 Methods and techniques.................................................................................................5

3.3 Deliverables and notation.............................................................................................. 7

4 The vision statement...........................................................................................................7



4.3 Deliverables and notation.............................................................................................. 7

5 Risk analysis.......................................................................................................................7



5.3 Deliverables and notation............................................................................................ 10

6 The goal model.................................................................................................................10

6.1 Modelling objectives....................................................................................................10

6.2 Methods and techniques...............................................................................................10


7 The community model......................................................................................................12

8 The business process and roles model..............................................................................13




9 The business resource model............................................................................................24



Copyright 2004-2006 SINTEF ICT. All rights reserved.


2/28


10 Work analysis refinement model (WARM)................................................................... 25

10.1 Modelling objectives.................................................................................................. 25

10.2 Methods and techniques............................................................................................. 25

10.3 Deliverables and notation...........................................................................................28


Page 2/28Copyright 2004-2006 SINTEF ICT. All rights reserved.


3/28


4/28

WARM is not a separate model as such, merely refinement of a model from an earlier

stage in the process.

It is most important to note that the above structure is only a structure. It should not bethought of as defining the sequence of activities for developing these work products. Thus,for example, although the Context Statement and Vision for Change would obviously bestarted and well developed before significant development of the other elements takes place,they are not cast in stone at the beginning of the project, and may be revised at any timesubsequently. Similarly the Goal model may be revised as the Business Process and Resourcemodels are developed. Finally, and most commonly, the Business Process model and theResource model are almost invariably developed in parallel.

2. Modelling framework for the business model

Figure 6: Business Model Structuring Concepts

The figure below shows a suggested package structure where a Business Model is part of afull Platform Independent Model.




5/28

Figure 7: Package structure for Business Model

3. The context statement

3.1. Modelling objectives

The purpose of the Context Statement is to define the scope of a business model and toposition it in its context. This may be done by identifying relationships to some otherbusiness models or by developing and getting agreement to a more informal representation ofthe target business being modelled in its environment. This informal representation takes theform of a domain picture aiming to give an overall understanding of the domain. It focuses ondescribing stakeholders and their relationships and identifies stakeholders concerns. Ittypically covers key value-chains and information flows. The emphasis is on the process ofbuilding it, agreeing it with subject matter experts and thereby understanding the context.Thus, it may not be maintained in subsequent phases of the development of the Product.

3.2. Methods and techniques

The first step in developing any business model is to identify and record the names of all




6/28

people who will have an interest in having the Product developed or in its use, the business

stakeholders, together with the nature of their interest. This list may change over time butshould always include representatives of all having an interest in the Product in any way. Thefollowing are examples of business stakeholders who should be involved:

people who will authorise funding for development of the Product; people who are responsible for design and maintenance of the business processes to be

supported by the Product;

people who will use the Product; people who will be responsible for the acceptance of the Product; people who will be responsible for managing operation of the Product

The approach taken to developing a Context Statement depends on the existence or not of

some higher level business model of which the new model forms a part. Whatever theapproach, however, the process consists of fact finding, discussion and agreement with allbusiness stakeholders, using one or more small workshops or interviews followed by one ormore feed-back sessions at which draft models are presented and walked through.

It is most important not to get bogged down in detail at this stage, and therefore it may be thatthe workshops or interviews are very short, and they may, where the Context Statement canbe agreed, be combined with the workshops and interviews used to develop the later businessmodelling work products. However, it is equally important that the full scope (and limitationsto scope) of the project is clearly understood, and that all stakeholders agree to this. In allevents, progression to subsequent business modelling work products should not commenceuntil this agreement is reached, even if only informally.

Where no higher level model exists, an informal representation of the context of theComponent to be developed may be prepared. This may use Use Case modelling techniquesas described under Requirements Modelling. Alternatively the concepts of a Rich Picturemay be used. This is a highly informal modelling technique, and subtle nuances of meaningshould be avoided or disregarded. The key point is the understanding of the business contextthat all share at the end of the exercise, to which end it may only be said about the resultantmodel that the business context is something like this. Informality and lack of rigour at thisstage does not matter, as it will be added in the other business modelling work products.Thus, where a Rich Picture is used for this Work Product, it should be remembered that itwill be superseded by the more formal models that are later developed. A Rich Picture should

not form any part of a delivered Products formal documentation.Where a higher level model exists, then the Context Statement would be prepared through aprocess of examination of the higher level model in order to identify those items that haveany impact on the business model being produced. Thus it would identify, for furtherdetailing:

all roles that appear in, or interact with roles that appear in, the business model beingproduced;

all actors associated with those roles; all resources associated with those roles




7/28

3.3. Deliverables and notation

The notation used for the Context Statement depends on the existence or not of a higher levelBusiness Model. Where that exists, the notation will be the notation of the subsets of thatmodel used. Where no higher level model exists, the notation may be a Rich Picture or a setof Use Cases.

In all cases, it will be accompanied by a list giving details of all Business Stakeholders.

4. The vision statement

This work product is a statement of what to improve, the motivation (i.e. what is wrong withthe current situation), a description or indication of what the improvements might be and agap analysis (a clear understanding of difference between the current and desired situations).


This work product adds detail to the scope given in the Context Statement, so that BusinessStakeholders can make informed judgements about approving the (appropriate phase of)development of the Product.


This document would be produced by a series of meetings, and the preparation andcirculation drafts until agreement on its content is achieved by the Business Stakeholdersidentified at the start of the Project.


The vision for change document is short and describes what the Product will be and why it isneeded. It will consist of some or all of the following elements:

General business/product vision and goals, including background explaining why the

Product is needed; Business opportunities and business benefits; Product description and technical business vision how the Product might be deployed

and used;

Presentation material summarising the above.

5. Risk analysis

The risk analysis describes marketing factors that might influence the product, good or bad,




8/28

and things that are required that are not described in the business vision and product

description work product. An estimate of the anticipated return of investment (ROI) is alsopart of this work product.


The objective of the Risk Analysis is to identify all risks to the project and ensure thatsuitable contingency plans are in place.


The approach to developing the risk analysis is to examine all possible ways that theprogramme, from development through to the Products in service life, might go wrong, andto identify the level of risk involved (probability of a bad thing happening), the cost thatwould be incurred if it happened, and contingency plans to reduce that cost to acceptablelevels. All types of risk should be considered, including commercial risk (failure to give theintended return on investment), business risk (impact on the business of failure of theProduct, either before or after deployment), programme risk (failure to deliver on time),development risk (Product development is more difficult or costly than expected) and supportrisk (high cost of user support or maintenance because of Product fragility).

Factors to be considered when investigating and considering risks are dependent of the typeof Product being developed, and this also influences how much effort to use on the risk

analysis. The following questions should be asked: Does the Product concern any critical or core part of the business? What is the size of the investment? What is the size of the project? Is it crucial to follow up the idea in order to stay in business?

When doing risk analysis, start with making a list of risk factors. Be creative and brainstorm alot when creating this list. Some issues that typically should be considered are:

What market and market trends that will influence the project? Who and what are the competition? What are the strengths and weakness of the competitors?

What are the technology dependencies? Are there Legacy systems to interface with? What is the expected time frame for the product? How many users will there be? What are the availability requirements? What is the likely steady state and peak number of transactions?

Be sure to include all the things that can go wrong; only writing down things that you wouldlike to happen is a sure recipe for disaster. Some common examples of things that might go




9/28


10/28

Figure 8: Risk analysis - Importance control square

A Return On Investment (ROI) document may also be part of the risk analysis, and is createdby using appropriate economic models. The business vision, product description and the listof risks serves as input on the early iterations. In later iterations analysing the evolving usecase model (function point analysis) are done for estimating the amount of investment.Involving people that are experienced with doing ROI analysis is important.

During the inception phase the first risk analysis is created. The list of risks will typicallyevolve and change through all phases of the project. The risk analysis is important whendeciding which use cases to implement in the different iterations of the construction phase.Following a risk driven system development approach implies development of the use casesassociated with the highest risks early.


The deliverables of the risk analysis work product are:

A document with categorised and prioritised list of risks and preventative measures. A document listing the assumptions A Return On Investment (ROI) document

6. The goal model


The purpose of the Goal Model is to agree with the Business Stakeholders the business goalsthat will be met by implementing and then using the Product, so that a set of required highlevel business processes can be identified for further analysis in the Business Process Model.Once produced and agreed, the goal model serves as a reference, throughout the Product'slife, that ensures that a full assessment may be made of all the business implications of anyproposed changes to the Product which have any impact on the business processes itsupports.


The goal model describes a loose hierarchy of goals of the business within the particular areaof concern, starting with the goals of a Business Stakeholder in developing or buying theProduct, and leading to the detailed business goals met by the Product or its users when usingit.

The Goal Model is discovered by a process of workshops and interviews involving allstakeholders. The initial question is "What is the desired state of affairs that we wish to bring




11/28

about as a result of implementation of the Product?" There may be one or a (small) number of

answers to this question, and the implications of these answers may lead to further refiningquestions of the form "If that is our high level goal, what, if any, sub-goals can we identify,the attainment of which will further that primary goal?", and by this means aquasi-hierarchical set of goals is identified and detailed.

Goals must be achievable, preferably measurable, and not self-evident, and should have clearand detailed implications. It should be reasonable (but not necessarily appropriate, and almostcertainly not correct) to assert an alternative. The implications should be expressible in termsof a set of sub-goals or enabling processes. Thus "to have total customer satisfaction" isprobably not a useful goal, as it is neither achievable nor measurable, and the alternative (nocustomer satisfaction) could hardly be argued. A more useful goal in this case might be of theform "95% of all customer complaints are resolved to the customer's satisfaction within 2hours".

One of the key aims of Goal modelling is to identify the things that have to happen in thebusiness for the goals to be met. These are the enabling processes which form the startingpoint of the Business Process model.


The Goal Model is the first part of the Business Model to be produced using the UML basedbusiness modelling conceptual model. Initially it may take the form of text but it must then berepresented in a UML model as a loose hierarchy of classes each stereotyped as

and presented in a class diagram. The figure below shows a view on the goals of theComponent Centre.




12/28

Figure 9: Goal Model for the Component Centre

7. The community model

The Community Model is a container for that part of the Business model that details the

business processes and business resources that are relevant to the Product. It is called"Community Model" because the concept of Community (which represents a collection ofresources working together, in one or more processes, to achieve one or more goals) is thekey to performing recursive, parallel, and decomposition of both behaviour and structure,essential for successful business process modelling. Thus the model's primary structure is of aset of communities, each of which is itself structured in terms of what it is (resources) andwhat it does (processes). The first step in preparing the Community Model, and thecontained Business Process and Resource models, is to create a package to contain theCommunity model, and, within it, a further package, stereotyped as , to




13/28

represent the top level community. Within this package, create two further

packages to contain respectively, the Resources visible at this top level, and the enablingbehaviours that support the goals defined in the Goal model.

The Community Model is prepared through a combination of three modelling activities:

Business Process and Role Modelling, which prepares a behavioural model that defines,in terms of roles and steps, the business processes of the domain which are relevant to theProduct, and which will enable the goals to be met, and gives a full definition of the rolesin the business, including those fulfilled by the Application Components which are to bedeveloped.

Business Resource Modelling, which prepares an information model that identifies anddefines the concepts of the domain that are relevant to the Product, including the actors

that do things, and the artefacts that have things done to or with them. Work Analysis Refinement Modelling (WARM) which further refines the Resourcemodel and the Process model by categorising resources by the kind of role they play (e.g.Human user, tool, business service, etc), and by identifying, for every step in the Processmodel the responsibility in the system for performing it. Note that the WARM is not aseparate model as such, merely refinement of a model from an earlier stage in the process.An important refinement is Work Element Analysis, which identifies groupings of thebusiness processes and resources that map to major resources-as-artefacts, and also to setsof processes typically carried out by a single department or division in the business.Given the CBD nature of the Architecture Model, these "work elements" are goodcandidates for a first-cut component design.

8. The business process and roles model

The Business Process and Roles model (generally called the Business Process or Processmodel) defines

the business processes of the domain which are relevant to the Product, and which willenable the goals to be met, and:

the roles of the resources that perform those processes.

This model may be at a number of levels of detail, from a high level description of thebusiness processes down to the WARM, which is a set of detailed specifications for the

business services that each IT element in the Product will provide. It includes a full definitionof the roles in the business, focusing on those fulfilled by the system or component to bedeveloped.

The Business Process and Roles model is generally prepared at the same time as theassociated Business Resource model.

To build a Business Process model the Business Modelling Conceptual Model (ormetamodel) is used.

Each business process is defined in terms of its steps, and each step performed by a resource




14/28

at a higher level of detail may then be treated as a process performed by a community (of

resources) and further analysed at a lower level of detail. Eventually, using the WARMconcepts of Human Step, Tool Step and Immediate Step, "leaf" steps will be defined, andassigned to specific elements of the Product to be developed. The time to stop analysing iswhen, by analysing the processes, the Product's role in them is defined, and when there are nomore questions about the business to be answered.


The objective of the Business Process Model is to identify and detail all the businessprocesses supported by the Product to the extent necessary to detail the roles of the Product(and its components, i.e. Application Components, Business Service Components and Tool

Components).


The Business Process Model is derived through a set of activities that encompassbrain-storming sessions, structured workshops, interviews and feed-back sessions, anddetailed modelling using a UML tool.

8.2.1. Derive initial process model from the goal model

The Business Process Model is derived directly from the Goal Model. Goals may be thought

of as high level statements of the things that have to happen in a business, each expressed asan outcome, but in a way that leaves unspecified how that outcome is to be made to occur. Asgoal analysis proceeds, the analyst becomes aware that he or she is increasingly describingnot so much a desired outcome as the means by which a higher level outcome is to beachieved, namely an enabling behaviour. The distinction between goal and behaviour toachieve a goal is inevitably blurred and to some extent subjective. The key thing to rememberis that, whereas a goal is some desired state of affairs, a behaviour is a specification forsomething that happens, the end result of which is the desired state of affairs.

Thus, the first step in creating the Business Process Model will be the identification of theenabling behaviours that have to happen for each goal to be achieved. Initially this is done

through a brain-storming process and production of an unstructured list of enablingbehaviours for each goal. This list is then consolidated into a single set of enablingbehaviours that, together, support all goals. This is the starting point for the Business ProcessModel which may then be entered into the tool using the Business Process Modelling Profile.

Each Enabling Behaviour is entered into the package containing the business processes in thetop level Community model as a Class stereotyped either as , where itcan clearly be seen that this behaviour can be represented as a set of steps with a definedbeginning and end, or, where no such approach is apparent, as a .The distinction between the two kinds of Enabling Behaviour may be subjective. The key




15/28

point is that Business Processes should be capable of being expressed as a set of structured

steps, each performed by some actor (resource) representing a concrete person, a machine(e.g. an IT system) or a collection of people and/ or machines.

Associations, stereotyped as , are then created between each goal and eachof the Enabling Behaviours that supports it. The result is a network of relationships thatshows both which Enabling Behaviours support each goal, and which goals are supported byeach Enabling Behaviour. A complete diagram representing all these relationships may bedrawn, but would probably be too complex to be useful.

The figures below show an example taken from the Business Model for the ComponentCentre. The first figure shows the Enabling Behaviours that support the goal to "Meet Marketneeds with IT business solutions".

Figure 10: Linking Goals to Processes

The figure below shows the goals supported by one of the business processes that support thegoal "Meet Market needs with IT business solutions", namely "Product DevelopmentProcess".




16/28

Figure 11: Linking Processes to Goals

In general, it may be expected that Behavioural Policies constrain Business Processes, and,although they represent behaviours, they cannot, in the model, be further detailed to identifysteps that the Product performs. Their presence in the model is, therefore, initially to assist indetailing the business processes, and, subsequently, to show that all the goals identified areproperly achieved by some behaviour, and that, where this behaviour is supported by theProduct, it is represented in business processes that are fully detailed to the level necessary to

identify the Product's role in the Business, as constrained by the Behavioural Policies.

8.2.2. Detailing of business processes and resources

Each business process that involves the Product in any way has to be detailed to the extentthat, when the model is complete, the Product's role in that business process is fullyunderstood and specified.

In general (but not exclusively), the reason for detailing a process is because theactor-resource that performs that process is a composite that includes the Product beingmodelled together with some other resources, not part of this development, such as a user oran interfacing system or component. Thus, it is necessary to detail both the process itself and

the structure of actor resource that performs that process, and the method for detailingprocesses is one in which both concepts are decomposed in parallel. In short,

the process being detailed (which may be some step in a higher level process), a thing thathas to happen, is considered as consisting of a set of steps, and:

the thing that performs that higher level step, an actor resource, is considered, at a moredetailed level, as a community of resources each fulfilling a role, each role beingresponsible for one or more of the steps in the detailed process.

Note that the "sequence" or focus of doing the two decompositions listed above may be either




17/28


18/28

1. For each Business Process, attach an ActivityGraph, with associated Activity Diagram,

both with the same name as the Business Process, to contain: the steps of the process, as SubActivityStates, stereotyped as the resources in roles responsible for performing those steps, as Partitions, stereotyped

as the information flows between steps, as ObjectFlowStates, stereotyped as

.

2. For each ObjectFlowState, identify or create a class, in the Business Resource Model,stereotyped as and set it as the Base Class.

3. Similarly, for each Partition, identify or create an actor, in the Business Resource Model,stereotyped as and set it as the "Represented Object".

An example of the ActivityGraph for one of the Processes is in shown below.




19/28

Figure 13: Example ActivityGraph

When this has been done for all enabling behaviours that have been categorised as businessprocesses, the top level process model may be thought of as complete. However, it is unlikelythat this will be in sufficient detail to identify the required behaviour (as steps) of the Productunder development, so further decomposition will be required. In general, further




20/28


21/28

Figure 14: Example Process Structure diagram

The result at this point, after one such cycle of decomposition, might look like the figurebelow.




22/28

Figure 15: Communities detailing Actor-resources and Processes

In this example model, a development from the initial business model structure, in the toplevel community "The Business" we have identified two business processes: P1 and P2(which support the Goals), two actor-resources, Fred's Group and Joe's Group, and two otherresources, Resource 1 and Resource 2, which appear as artefacts in Process P1. At this pointonly P1 has been detailed, in an ActivityGraph, which has identified a number of steps,including Steps 1 and 3 which are performed by Fred's Group. Decomposition, in order toidentify the required behaviour of the Product that is the focus of this model, has concentratedinitially on the two actor-resources, and communities representing each of these have beencreated within the Business Processes package of the higher-level community. Thus there is a




23/28

community representing Fred's Group and its behaviour in the top level processes (noting that

only P1 has been detailed as yet), and another community representing Joe's Group and itsbehaviour in those processes.

Within each of these second level communities we have a process package, where weidentify the processes performed by the resource that maps to the community (in the case ofFred's Group there are, at this point, P1 Step 1 and P1 Step 3; it is likely that there will besome steps of Process P2 that will be included when P2 is detailed). We also have a resourcepackage that includes the resources (performers and artifacts) that are required for theprocesses to be executed.

The decomposition process, and the relationships between model elements, is summarised inthe diagram below.

Figure 16: Summary of Decomposition approach

The process of decomposition as described above is carried out until all processes are detailedto the extent that no step in the model is performed by any composite resource that includesboth the Product and some resource that is not the Product.

Where the focus for decomposition is a process and its steps, the equivalent procedure (to




24/28

detail a step, in an ActivityGraph representing a Process in some higher level community) is

essentially the same, with the exception that the lower level community that is used for thecontainer of the detail will only contain those processes that are relevant to some particularpart of the model. Under such circumstances there may be more than on community thatmaps to a single higher level actor-resource.


The Business Process Model is delivered as one or more packages in the overall UML modelfor the Product.

9. The business resource model


The Business Resource Model is an information model that identifies and defines the mainthings (and concepts) of the domain that are relevant to the Product, these being, in general,those things that do things in the business (including the Product itself), and those things thathave things done to or with them, and details the relationships between these concepts.

A Product comprises a complete and consistent set of models for the Product, namelyBusiness Model, Requirements Model, Architecture Model and one or more Platform

Specific Model together with the corresponding Executables


The Business Resource Model is generally prepared at the same time as the associatedBusiness Process & Roles model, and methods and techniques used are similar, i.e.activities that include brain-storming sessions, structured workshops, interviews andfeed-back sessions, and detailed modelling using a UML tool.

The Resources that are of concern to the business will mostly, but not entirely, bediscovered from consideration of the things that have to happen in the business (ascontained in the Business Process Model). All resources either make those things happen,

or are involved in those things that happen, in that, what happens, happens to them. In addition, reference should be made to, and consistency maintained with, the ContextStatement, since that is a representation at a high level of all the main things of interest tothe Product.

The set of business concepts are then refined into a class model, at the level of detailbeing considered which defines the interesting attributes of and relationships between allthe resources (both actors and artefacts) identified in the Business Process Model.

The conceptual model used is the same as for the Business Process model, namely theBusiness Modelling Conceptual Model, with additional freedom to add any relevant




25/28

associations, attributes and state machines, as provided by standard UML.

Packaging of this class model is a modelling choice, but dependencies can be reduced byconfining resources to the communities with which they are involved. Thus, eachCommunity package would contain two packages, one with the relevant BusinessProcess Model, the other with the relevant Business Resource Model.


The Business Resource Model takes the form of a UML class model as part of the PIM forthe Product (see the example model structure). In cases where it is useful it may beaccompanied by state machine models for any of the resources modelled.

10. Work analysis refinement model (WARM)


As its name suggests, the WARM is a refinement of the basic Business model whichconcentrates on "Work Analysis", i.e., which kinds of resources do which kind of work.Specifically, it concentrates on those resources that will form part of the Product beingdeveloped, and the behaviour (expressed as Steps in Processes) that they will be required toexhibit.


The WARM is not a separate model, or even a separately identifiable element in a model. Itis a final refinement of both the Business Process & Roles model and the Business Resourcemodel, (both, themselves, distributed amongst a variety of Community models), in which theSteps in the Business Process model are refined and assigned to specific refined ActorResources. It is from this part of the model that the role, in the business, of a particular ITelement, can be ascertained.

The WARM concepts that specialise Actor Resource are illustrated in the figure below:




26/28

Figure 17: WARM Concepts Resource

Resources are refined to identify the IT elements that fulfil roles in the business, as follows:

A Product in the WARM is an actor resource that fulfils a role in the business and mapsto the executable part of a Product.

A Business Service is a Resource with a role in the business, and represents an IT elementthat maps to a Business Service Component in the corresponding Architecture model.

A Workflow is an actor resource that maps to a Workflow Definition in a corresponding

Architecture model which contains the business logic of a process and determines thesequencing of steps within any instance of that process.

A Human/Tool is an actor resource with a role in the business that is fulfilled by a humanworking with an IT element that maps to a Tool Component in the correspondingArchitecture model

An Other System is an actor resource that represents an external automatic system thatfulfils a role in the Business Process Model

In addition, so that the model can be complete, we identify:




27/28

A Human (user) is an actor resource that represents a human that fulfils a role in the

Business Process Model. The System represents the complete IT facility that supports the business including allProducts and the Infrastructure.

The WARM concepts that specialise the business process modelling concept of Step areillustrated below:

Figure 18: WARM Concepts Step

In WARM refinement of the Business Process model, the kinds of step performed byresources in the model are further categorised as follows:

A Human Step is a step performed by a human with no involvement of the Product beingmodelled.

An Extended Step is a Step in which the intermediate states are of interest to the business,and may have to be remembered. This may be either because there are business reasonsfor such interest, or because other factors, including technology, require that the businessbe concerned. An extended step is a candidate for choreography by a Workflow.

A Tool Step is a step performed by a human user interacting with a tool that is part of theProduct. The human user will use some form of interactive device (e.g. a GUI) to interactwith the Product. A Tool Step is a candidate for realisation by a Tool Component.




28/28

An Immediate Step is a Step that is required to complete as soon as possible, and whose

intermediate states are of no concern to the business. It is performed autonomously, withno intervention from a human. An Immediate Step may be mapped to an Operation on aBusiness Service Component (Process) in the Architecture Model. Each such operationon a Business Service Component in the Architecture will run in an ACID transaction,thereby either completing or leaving state as it was. The Name of the step is the verb orverb phrase that describes the process (for example, "Modify Customer record"). If aresource is specified as part of the name or description (for example "Modify Customerusing Info from Sales Person") then the model should identify the relevant Resources.


As explained above, the WARM is not a separate model, but an extension to and refinementof the Business Process model and the Business Resource model. Thus the deliverables andnotations are as for those models.



2b Business Model HTML

Documents

Transcript of 2b Business Model HTML