All BIAN Service Domains Share a Common Operational Structure
All BIAN Service Domains have the same operational structure. As already described the high level role/purpose of a Service Domain is to enable some type of business function (defined as a functional pattern) that is applied to instances of some type of asset/entity. One occurrence of this role being executed for a full life-cycle or from start to finish is managed using an instance of the Service Domain’s control record. The full life-cycle is further defined by identifying the main externally visible states that the control record instance and/or the Service Domain may transition through. For example if the role of the Service Domain is to maintain reference details for a supplier it must do this from the time the supplier is first identified, through all possible working arrangements/states until the supplier has no further contact with the bank. If the role of the Service Domain is to operate an ATM network it is responsible for the network activation, any subsequent network re-configuration, all ATM transaction execution support and the eventual termination of the ATM Network operating session.
Diagram 9: Structure of a Service Domain
Later in this guide and in the second guide of the series, BIAN How to Guide – Developing Content, the use of functional patterns, states and standard service operations used to access Service Domains are described in more detail. The types of externally visible states that a Service Domain may pass through depends on its particular functional pattern. Service operation calls may only be allowed when a Service Domain is in one of a pre-defined set of states and the service call may itself result in a state change for the individual control record instance or the overall Service Domain. Some examples of external states for selected functional patterns for reference are as follows:
Diagram 10: End to end states for the functional patterns
Note that these states only define the externally visible states that the Service Domain may pass through. There will typically be more detailed states for individual control records. It is also the case for some of the more complex Service Domains in particular that there will be many finer grained functional state cycles contained or encapsulated within the internal processing of the Service Domain. Additional definitions of the state behaviours of Service Domains will be addressed in later releases.
Specialized service operations
As described later in this guide, BIAN defines a standard set of default service operations for a Service Domain based on its particular functional pattern. In some cases the internal state cycles are for business functions that are important enough to merit additional specialized service operations to access them. For example the Current Account Fulfilment Service Domain handles the processing for a Current Account product. When a customer requests the set-up of a standing order against that current account the standing order has its own state cycle within the longer Current Account state cycle. In recognition that the business functions associated with handling the standing order have their own particular business significance there are additional specialised service operations defined for the Current Account Fulfilment Service Domain that are dedicated to handling just standing orders.
Currently there are no formal BIAN guidelines as to when additional specialized service operations need to be defined for a Service Domain. Working Groups add the specialised service operations on a case by case basis. One indication of the need for specialised service operations is where it has been found necessary in practice to develop Business Scenarios to explain the particular business activity/event.
Furthermore, for a business function that has been determined to merit its own specialized service operations the question often follows whether it should be elevated to being its own discrete Service Domain. Creating a new Service Domain is only considered when it can be confirmed that its business function/role (the standing order in the example above) represents a business capability that will be shared by many Service Domains (i.e. many different products may make use of a generalized standing order capability).
General Service Domain properties
The execution of the Service Domain’s role for the full life cycle is tracked/managed using an instance of its ‘control record’. Depending on the Service Domain’s business role it may make sense for it to handle only a single occurrence of its role at any one time (using a single control record instance) or there may need to be many concurrent instances at different stages in their own life cycles. Furthermore, also depending on the business role, the life cycle can be quite short (measured in seconds) or could extend over many years. A summary of the Service Domain design properties with some explanatory examples is shown in Diagram 11:
Diagram 11: Design properties and service domain schematic
The discrete business capability represented by a Service Domain can be considered as being broadly equivalent to an organizational unit of the enterprise that combines the ‘People, Process and Technology’. In some cases the corresponding capability may be largely automated or it may be people intensive and make limited use of supporting technologies. As BIAN’s focus is on improving application interoperability, most attention is paid to the supporting systems’ role for the Service Domain and the aspects of the service exchanges between Service Domains that are supported in some way through technology, as illustrated in Diagram 12.
Diagram 12: A service domain represents an organizational capability
The BIAN specification of a Service Domain is currently limited to a brief description of its role along with the definition of its control record that identifies the asset type acted upon and the functional pattern that characterizes the main behaviour of the Service Domain. The semantic descriptions of its offered service operations and delegated/accessed service operations along with example Business Scenarios provide additional context to infer the inner workings of a Service Domain.
In practice this description is not always sufficient to provide an unambiguous definition of the Service Domain for use in solution design and development: additional example descriptive specifications are required. As with the Business Scenarios that provide examples of Service Domain interactions these additional descriptions are not part of the canonical BIAN standard. They simply provide examples of possible Service Domain characteristic’s that can be referenced. They are not intended to be complete, they may not always apply and may need to be interpreted differently in different implementation scenarios.
Two types of extension to the Service Domain descriptions are under consideration at this time. One is the Service Domain feature list that captures prevailing functional and non-functional features of the Service Domain. An example of Service Domain feature table can be found in the third guide of the series: BIAN How to Guide – Applying the Standard. The second is the definition of some form on information or object model that captures the information/data governed and referenced by the Service Domain. There are no working examples of this information/data model suitable for general publication at this time.
The Responsibilities of Well Defined Service Domain Could be Outsourced
An informal test of a well-defined Service Domain is that a practical situation can be envisaged where its business function could be offered by a 3rd party organization. This test confirms that the partition represents a discrete business capability and that the service dependencies have been fully exposed. It does not require that such an outsourcing arrangement is preferential from a business performance perspective, nor that such an outsourcing arrangement would involve just one single Service Domain rather than a related collection of Service Domains. It merely poses the question: ‘if necessary could a third party provide the business service defined by the Service Domain through its defined service operations ?’