Business model Introduction

The business model is used to express the part played by the product (system or component) being developed in the context of the business that will fund its development (or purchase it) and use it. It also provides elements that link extremely well to the architecture model. The business model includes goals, business processes, steps within business processes, roles and resources. The scope (or domain) of the model is any part of the world defined as interesting for a company, organisation or others, and which has some impact on the required behaviour or other characteristic of the product. The business model might be broadly or narrowly scoped, e.g. describing the entire business of a company or describing the immediate environment and context of a product under consideration. Thus, the business model is recursive in the sense that some business models might detail aspects of another more broadly scoped/higher level business model. The set of work products of a business model is outlined below. A business model consists of the work products listed below.
y

y y

A set of scoping statements, consisting of the following: o The context statement, which defines the scope and positions this business model in its context. o Vision for change, which describes what to improve, the motivation (i.e. what is wrong with the current situation), a description or indication of what the improvements might be and a gap analysis. o Risk analysis, which identifies the business and technical risks related to a development project for the proposed Product. A goal model, which describes the business goals that will be met by implementing and then using the Product. A community model, in which is prepared through a combination of three modelling activities: o 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 the product, and which will enable the goals to be met, and gives a full definition of the roles in the business, including those fulfilled by the application components which are to be developed. o Business resource modelling which prepares an information model that identifies and defines the concepts of the domain that are relevant to the Product, including the actors that do things, and the artifacts that have things done to or with them. o Work analysis refinement modelling (WARM) which further refines the resource model 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 process model, the responsibility in the system for performing it. The WARM activity also allows identification of work elements, which are used by the architecture modeller (or mapping tool) to derive its first-cut component

model. Note that the 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 be thought 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 be started 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 time subsequently. Similarly the Goal model may be revised as the Business Process and Resource models are developed. Finally, and most commonly, the Business Process model and the Resource model are almost invariably developed in parallel.

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 a full Platform Independent Model.

Figure 7: Package structure for Business Model

he context statement
Modelling objectives
The purpose of the Context Statement is to define the scope of a business model and to position it in its context. This may be done by identifying relationships to some other business models or by developing and getting agreement to a more informal representation of the target business being modelled in its environment. This informal representation takes the form of a domain picture aiming to give an overall understanding of the domain. It focuses on describing stakeholders and their relationships and identifies stakeholders concerns. It typically covers key value-chains and information flows. The emphasis is on the process of building 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.

Methods and techniques

The first step in developing any business model is to identify and record the names of all 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 but should always include representatives of all having an interest in the Product in any way. The following are examples of business stakeholders who should be involved:

y y y y y

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 the approach, however, the process consists of fact finding, discussion and agreement with all business stakeholders, using one or more small workshops or interviews followed by one or more feedback 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 that the workshops or interviews are very short, and they may, where the Context Statement can be agreed, be combined with the workshops and interviews used to develop the later business modelling work products. However, it is equally important that the full scope (and limitations to scope) of the project is clearly understood, and that all stakeholders agree to this. In all events, progression to subsequent business modelling work products should not commence until this agreement is reached, even if only informally. Where no higher level model exists, an informal representation of the context of the Component to be developed may be prepared. This may use Use Case modelling techniques as described under Requirements Modelling. Alternatively the concepts of a Rich Picture may be used. This is a highly informal modelling technique, and subtle nuances of meaning should be avoided or disregarded. The key point is the understanding of the business context that all share at the end of the exercise, to which end it may only be said about the resultant model that the business context is something like this. Informality and lack of rigour at this stage 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 it will 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 a process of examination of the higher level model in order to identify those items that have any impact on the business model being produced. Thus it would identify, for further detailing:
y y y

all roles that appear in, or interact with roles that appear in, the business model being produced; all actors associated with those roles; all resources associated with those roles

Deliverables and notation

The notation used for the Context Statement depends on the existence or not of a higher level Business Model. Where that exists, the notation will be the notation of the subsets of that model

used. Where no higher level model exists, the notation may be a Rich Picture or a set of Use Cases. In all cases, it will be accompanied by a list giving details of all Business Stakeholders.

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

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

Methods and techniques

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

Deliverables and notation

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

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.

Risk analysis
The risk analysis describes marketing factors that might influence the product, good or bad, 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 also part of this work product.

Modelling objectives

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

Methods and techniques

The approach to developing the risk analysis is to examine all possible ways that the programme, from development through to the Products in service life, might go wrong, and to identify the level of risk involved (probability of a bad thing happening), the cost that would be incurred if it happened, and contingency plans to reduce that cost to acceptable levels. All types of risk should be considered, including commercial risk (failure to give the intended return on investment), business risk (impact on the business of failure of the Product, either before or after deployment), programme risk (failure to deliver on time), development risk (Product development is more difficult or costly than expected) and support risk (high cost of user support or maintenance because of Product fragility). Factors to be considered when investigating and considering risks are dependent of the type of Product being developed, and this also influences how much effort to use on the risk analysis. The following questions should be asked:
y y y y

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 a lot when creating this list. Some issues that typically should be considered are:
y y y y y y y y y

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 would like to happen is a sure recipe for disaster. Some common examples of things that might go wrong are:
y y y y y

Lack of user acceptance Dependence on a technology that changes Not fast enough to market Development team not experienced enough Too many users

y y y

Too short a schedule Too fast to market Supplier failure to deliver a product that we are dependent on.

Take the list of risks and eliminate extremes or those for which effectively no plan can be made (such as a comet hitting the Earth), and prioritise the rest. The importance/control square shown in the figure below might be used to prioritise the risks. In this square the risks are categorised based on their importance and to what extent it might be controlled. Typically market trends are important but hard to control, while handling many simultaneous users might be of high or low importance, but is easier to control. Easier to control means that it is a risk that is independent of external actors and processes, so it is up to you to decide to deal with it. The risks within each square should again be prioritised, for instance sequentially or with a number showing the degree of importance. For each a statement should be prepared explaining, depending on the control level possible, the measures to be taken to reduce the probability of the risk occurring, or the measures to be taken to reduce the impact in the event that it does. As part of the risk analysis, put together and maintain a list of assumptions. These are decisions made with little or no hard data. Assumptions are based on gut feel or experience. This list should be reviewed regularly, if possible try to get some hard data to base the decisions

Figure 8: Risk analysis - Importance control square A Return On Investment (ROI) document may also be part of the risk analysis, and is created by using appropriate economic models. The business vision, product description and the list of risks serves as input on the early iterations. In later iterations analysing the evolving use case 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 typically evolve and change through all phases of the project. The risk analysis is important when deciding 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 cases associated with the highest risks early.

Deliverables and notation

The deliverables of the risk analysis work product are:
y y y

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

he goal model
Modelling objectives
The purpose of the Goal Model is to agree with the Business Stakeholders the business goals that will be met by implementing and then using the Product, so that a set of required high level 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's life, that ensures that a full assessment may be made of all the business implications of any proposed changes to the Product which have any impact on the business processes it supports.

Methods and techniques

The goal model describes a loose hierarchy of goals of the business within the particular area of concern, starting with the goals of a Business Stakeholder in developing or buying the Product, and leading to the detailed business goals met by the Product or its users when using it. The Goal Model is discovered by a process of workshops and interviews involving all stakeholders. The initial question is "What is the desired state of affairs that we wish to bring 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 refining questions 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 a quasi-hierarchical set of goals is identified and detailed. Goals must be achievable, preferably measurable, and not self-evident, and should have clear and detailed implications. It should be reasonable (but not necessarily appropriate, and almost certainly not correct) to assert an alternative. The implications should be expressible in terms of a set of sub-goals or enabling processes. Thus "to have total customer satisfaction" is probably not a useful goal, as it is neither achievable nor measurable, and the alternative (no customer satisfaction) could hardly be argued. A more useful goal in this case might be of the form "95% of all customer complaints are resolved to the customer's satisfaction within 2 hours". One of the key aims of Goal modelling is to identify the things that have to happen in the business for the goals to be met. These are the enabling processes which form the starting point of the Business Process model.

Deliverables and notation

The Goal Model is the first part of the Business Model to be produced using the UML based business modelling conceptual model. Initially it may take the form of text but it must then be represented in a UML model as a loose hierarchy of classes each stereotyped as <<Goal>> and presented in a class diagram. The figure below shows a view on the goals of the Component Centre.

Figure 9: Goal Model for the Component Centre

he 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 of resources working together, in one or more processes, to achieve one or more goals) is the key 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 a set of communities, each of which is itself structured in terms of what it is (resources) and what it does (processes). The first step in preparing the Community Model, and the contained Business Process and Resource models, is to create a package to contain the Community model, and, within it, a further package, stereotyped as <<Community>>, to represent the top level community. Within this <<Community>> package, create two further packages to contain respectively, the Resources visible at this top level, and the enabling behaviours that support the goals defined in the Goal model. The Community Model is prepared through a combination of three modelling activities:
y

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 the Product, and which will enable the goals to be met, and gives a full definition of the roles in the business, including those fulfilled by the Application Components which are to be developed. Business Resource Modelling, which prepares an information model that identifies and defines 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 Resource model 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 Process model the responsibility in the system for performing it. Note that the WARM is not a separate 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 the business processes and resources that map to major resources-as-artefacts, and also to sets of 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 good candidates for a first-cut component design.

he business process and roles model

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

the business processes of the domain which are relevant to the Product, and which will enable 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 the business 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 definition of the roles in the business, focusing on those fulfilled by the system or component to be developed.

y y

The Business Process and Roles model is generally prepared at the same time as the associated Business Resource model. To build a Business Process model the Business Modelling Conceptual Model (or metamodel) is used.

Each business process is defined in terms of its steps, and each step performed by a resource 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 WARM concepts of Human Step, Tool Step and Immediate Step, "leaf" steps will be defined, and assigned to specific elements of the Product to be developed. The time to stop analysing is when, by analysing the processes, the Product's role in them is defined, and when there are no more questions about the business to be answered.

Modelling objectives
The objective of the Business Process Model is to identify and detail all the business processes 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).

Methods and techniques

The Business Process Model is derived through a set of activities that encompass brain-storming sessions, structured workshops, interviews and feed-back sessions, and detailed modelling using a UML tool. 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 as an outcome, but in a way that leaves unspecified how that outcome is to be made to occur. As goal analysis proceeds, the analyst becomes aware that he or she is increasingly describing not so much a desired outcome as the means by which a higher level outcome is to be achieved, namely an enabling behaviour. The distinction between goal and behaviour to achieve a goal is inevitably blurred and to some extent subjective. The key thing to remember is that, whereas a goal is some desired state of affairs, a behaviour is a specification for something 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 the enabling 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 enabling behaviours for each goal. This list is then consolidated into a single set of enabling behaviours that, together, support all goals. This is the starting point for the Business Process Model 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 the top level Community model as a Class stereotyped either as <<Business Process>>, where it can clearly be seen that this behaviour can be represented as a set of steps with a defined beginning and end, or, where no such approach is apparent, as a <<Behavioural Policy>>. The distinction between the two kinds of Enabling Behaviour may be subjective. The key 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 <<Enabled by>>, are then created between each goal and each of the Enabling Behaviours that supports it. The result is a network of relationships that shows both which Enabling Behaviours support each goal, and which goals are supported by each Enabling Behaviour. A complete diagram representing all these relationships may be drawn, but would probably be too complex to be useful. The figures below show an example taken from the Business Model for the Component Centre. The first figure shows the Enabling Behaviours that support the goal to "Meet Market needs 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 the goal "Meet Market needs with IT business solutions", namely "Product Development Process".

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 identify steps that the Product performs. Their presence in the model is, therefore, initially to assist in detailing the business processes, and, subsequently, to show that all the goals identified are properly achieved by some behaviour, and that, where this behaviour is supported by the Product, 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. Detailing of business processes and resources Each business process that involves the Product in any way has to be detailed to the extent that, when the model is complete, the Product's role in that business process is fully understood and specified. In general (but not exclusively), the reason for detailing a process is because the actor-resource that performs that process is a composite that includes the Product being modelled together with some other resources, not part of this development, such as a user or an 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 detailing processes is one in which both concepts are decomposed in parallel. In short,
y

the process being detailed (which may be some step in a higher level process), a thing that has 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 more detailed level, as a community of resources each fulfilling a role, each role being responsible 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 the behaviour (processes) of the resource or its structure. It may, in a full model, be a mixture of the two. In some circumstances it may be the case that the structure and broad roles of the constituents of an actor-resource are pre-defined, in which case the appropriate approach may be to say, at the commencement of detailing some business process, "Let us examine the roles played by this organisational entity (modelled as an actor-resource), and, concurrently, examine the detail of the processes in which it is involved." Alternatively, in some circumstances, it may be more appropriate to say, "We know this thing has to happen, and that this high level actor-resource makes it happen; let us examine the way it happens (i.e. the things that are done), and then identify a suitable structure for the high level actor-resource to support it." Doing this in UML 1.4 is not straightforward, but a means of doing so, using the Business Modelling Module in the COMBINE Profile has been detailed. The step-by-step method for developing a process model is described in the following paragraphs. It is assumed that a Business model with the basic structure of Context Statements, Goal Model and Community Model has been prepared, and that the Goal modelling has been completed to identify all the top level processes in which the Product is involved, and that the (goal driven) enabling behaviours have been identified included in the model. The resulting initial model will be of the form shown below.

Figure 12: Initial Business Model Structure

1. For each Business Process, attach an ActivityGraph, with associated Activity Diagram, both with the same name as the Business Process, to contain: o the steps of the process, as SubActivityStates, stereotyped as <<Step>> o the resources in roles responsible for performing those steps, as Partitions, stereotyped as <<ResourceAsRole>> o the information flows between steps, as ObjectFlowStates, stereotyped as <<ResourceAsArtifact>>. 2. For each ObjectFlowState, identify or create a class, in the Business Resource Model, stereotyped as <<Resource>> and set it as the Base Class. 3. Similarly, for each Partition, identify or create an actor, in the Business Resource Model, stereotyped as <<ActorResource>> and set it as the "Represented Object". An example of the ActivityGraph for one of the Processes is in shown below.

Figure 13: Example ActivityGraph When this has been done for all enabling behaviours that have been categorised as business processes, the top level process model may be thought of as complete. However, it is unlikely that this will be in sufficient detail to identify the required behaviour (as steps) of the Product under development, so further decomposition will be required. In general, further decomposition is always required so long as there are unexpanded steps, of business significance, which are performed by some resource that is a composite of the Product and some other resource, such as a user or an interfacing component, not part of this development. In this process of decomposition, as mentioned above, the focus may be on the structure, or on the behaviour, or, across a full model, a combination of the two. Here we describe the decomposition process where the focus is on the structure, i.e. the intention is to examine the role of a composite resource and detail the behaviour of its components. Here we take the case where we know the structure of the business resource that performs the processes being detailed, and intend to base the structure of the model (at least at this level of detail) around that structure. 1. Create a package, stereotyped as <<Community>>, that represents one of the resources we wish to detail fulfilling all its roles in the higher level Community of which it is a member, and name it appropriately so that it identifies both the resource to which it maps and the behaviour being detailed. This is an instance of the link "represents" between the concepts "Resource as Role" and "Community" in the Profile model. For model management purposes and ease of comprehension of the model, create two packages within this Community package, to contain, respectively, the business processes that the resource mapping to the community performs, and the resources which comprise this community. 2. For each Step performed by the higher level ResourceAsRole to which this community maps, create, within the namespace of the business processes package of this <<Community>>, a class stereotyped as <<BusinessProcess>>, with the same name as the Step concerned. Attach an ActivityGraph, and an associated Activity Diagram, to this class, both also with the same name as the Step being detailed. 3. Repeat steps 1 and 2 above, to detail this process. 4. Repeat steps 4, 5 and 6 above, for all resources at this level of the model in which the Product is involved (i.e. has some step to perform). Additionally, and optionally, the structure of each process may be represented in a class model, as follows: 1. Create a class diagram for each process, and represent on it, its component steps (as classes stereotyped as <<BusinessProcess>>, each associated with a Composition to the parent process, and the actors that perform them, as shown in the figure below. Note that this is a convenience diagram, used to assist in understanding or presenting the model. It is optional, and there are no essential links from this part of the model to any other part of the PIM.

Figure 14: Example Process Structure diagram The result at this point, after one such cycle of decomposition, might look like the figure below.

Figure 15: Communities detailing Actor-resources and Processes In this example model, a development from the initial business model structure, in the top level 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 other resources, Resource 1 and Resource 2, which appear as artefacts in Process P1. At this point only 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 to identify the required behaviour of the Product that is the focus of this model, has concentrated initially on the two actor-resources, and communities representing each of these have been created within the Business Processes package of the higher-level community. Thus there is a 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 its behaviour in those processes.

Within each of these second level communities we have a process package, where we identify the processes performed by the resource that maps to the community (in the case of Fred's Group there are, at this point, P1 Step 1 and P1 Step 3; it is likely that there will be some steps of Process P2 that will be included when P2 is detailed). We also have a resource package that includes the resources (performers and artifacts) that are required for the processes to be executed. The decomposition process, and the relationships between model elements, is summarised in the diagram below.

Figure 16: Summary of Decomposition approach The process of decomposition as described above is carried out until all processes are detailed to the extent that no step in the model is performed by any composite resource that includes both 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 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 the container of the detail will only contain those processes that are relevant to some particular part of the model. Under such circumstances there may be more than on community that maps to a single higher level actor-resource.

Deliverables and notation

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

The business resource model

Modelling objectives
The Business Resource Model is an information model that identifies and defines the main things (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 that have 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, namely Business Model, Requirements Model, Architecture Model and one or more Platform Specific Model together with the corresponding Executables

Methods and techniques

y

The Business Resource Model is generally prepared at the same time as the associated Business Process & Roles model, and methods and techniques used are similar, i.e. activities that include brain-storming sessions, structured workshops, interviews and feed-back sessions, and detailed modelling using a UML tool. The Resources that are of concern to the business will mostly, but not entirely, be discovered from consideration of the things that have to happen in the business (as contained 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 Context Statement, since that is a representation at a high level of all the main things of interest to the Product. The set of business concepts are then refined into a class model, at the level of detail being considered which defines the interesting attributes of and relationships between all the 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 the Business Modelling Conceptual Model, with additional freedom to add any relevant associations, attributes and state machines, as provided by standard UML. Packaging of this class model is a modelling choice, but dependencies can be reduced by confining resources to the communities with which they are involved. Thus, each Community package would contain two packages, one with the relevant Business Process Model, the other with the relevant Business Resource Model.

Deliverables and notation

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

Work analysis refinement model (WARM)

Modelling objectives
As its name suggests, the WARM is a refinement of the basic Business model which concentrates 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 being developed, and the behaviour (expressed as Steps in Processes) that they will be required to exhibit.

Methods and techniques

The WARM is not a separate model, or even a separately identifiable element in a model. It is a final refinement of both the Business Process & Roles model and the Business Resource model, (both, themselves, distributed amongst a variety of Community models), in which the Steps in the Business Process model are refined and assigned to specific refined Actor Resources. It is from this part of the model that the role, in the business, of a particular IT element, can be ascertained. The WARM concepts that specialise Actor Resource are illustrated in the figure below:

Figure 17: WARM Concepts Resource Resources are refined to identify the IT elements that fulfil roles in the business, as follows:
y y

A Product in the WARM is an actor resource that fulfils a role in the business and maps to the executable part of a Product. A Business Service is a Resource with a role in the business, and represents an IT element that 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 the sequencing 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 human working with an IT element that maps to a Tool Component in the corresponding Architecture model An Other System is an actor resource that represents an external automatic system that fulfils a role in the Business Process Model

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

y y

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 all Products and the Infrastructure.

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

Figure 18: WARM Concepts Step In WARM refinement of the Business Process model, the kinds of step performed by resources in the model are further categorised as follows:
y y

A Human Step is a step performed by a human with no involvement of the Product being modelled. 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 reasons for such interest, or because other factors, including technology, require that the business be 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 the Product. The human user will use some form of interactive device (e.g. a GUI) to interact with the Product. A Tool Step is a candidate for realisation by a Tool Component. 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, with no intervention from a human. An Immediate Step may be mapped to an Operation on a Business Service Component (Process) in the Architecture Model. Each such operation

on 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 or verb phrase that describes the process (for example, "Modify Customer record"). If a resource is specified as part of the name or description (for example "Modify Customer using Info from Sales Person") then the model should identify the relevant Resources.

Deliverables and notation

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

Last Published: 10/21/2010 16:54:51 Copyright 2004-2006 SINTEF ICT.