Modelling Service Domain Interactions (Business Scenarios)

It is intended that any and all business activity can be modelled using identified BIAN Service Domains. The primary mechanism BIAN uses to ‘discover’ and refine Service Domain designs is the BIAN Business Scenario.

The BIAN business scenario captures the anticipated activities for a business event. It models an archetypal pattern of service operation exchanges between the involved Service Domains. Unlike a process representation that defines the precise logic and sequence of tightly coupled tasks, the BIAN business scenario simply identifies the Service Domains involved and highlights likely service exchanges that could occur between them.

The purpose of the business scenario is to discover and clarify service operation exchanges between Service Domains by providing the example context of a real world situation. The BIAN business scenario is not canonical nor is it intended to define a pre-determined sequence of necessary tasks as in a business process nor mandate the use of a service operation in a specific situation. Furthermore a BIAN business scenario need not be exhaustive in terms of the participation of service domains it reveals, the steps it includes or its start and end point – it is merely providing meaningful context to help describe the particular service exchanges that it happens to include.

The BIAN business scenario is therefore intentionally a rather simple device, revealing for some business event the involved Service Domains and describing the nature of the exchanges between them. The guidelines for documenting a Business Scenario are shown in Diagram 15:

Diagram 15: An example business scenario with guidelines

The conceptual distinction between a process oriented view and a service oriented view as is captured in a Business Scenario has been described the previous Section of this guide. As the Business Scenario representation has many similarities with the more conventional process model view it is worth highlighting one key difference. The Business Scenario is constrained to capturing a business event at the level where the involved Service Domains are clearly identified, typically between three and ten Service Domains depending on the complexity of the interactions. A Process can be modelled at any level of detail;

• Processes at a higher level of detail – there are few obvious situations where a business activity or event is so high level that it is not possible to represent it as a collection of one or more Business Scenarios
• Processes captured at the same level – for defining business requirements it is common to find process definitions at about the same level of detail as the typical Business Scenario. The role of the Service Domain can be loosely compared to ‘Actors’ in some process model formats. But as noted, the tight coupled sequence of the process has no equivalent in the Business Scenario
• Processes at a finer level of detail – process models can be used to define much finer grained activities as might be found within the internal logic of a Service Domain. BIAN does not presume any particular internal technical architecture for a Service Domain. The best technical design approach should be selected based on the Service Domain’s desired operational characteristics. For example multi-threaded process design versus a state driven object based design.

A more detailed description of the Business Scenario diagram and the type and content definition of the service operations are covered in the second document of the BIAN ‘How-to Guide - Defining Content.’ This includes a description of how Business Scenarios are currently organized. It also describes how the Business Scenario categorization may be extended in the near future for ease of reference in the BIAN repository.