BIAN Service Domains must be ‘Elemental’
To define a canonical standard (i.e. a specification that can be consistently interpreted in different deployment situations) it is essential that the business functional scope of a BIAN Service Domain is ‘elemental’ in nature. This means that its associated capability addresses a single discrete business purpose or role. If a Service Domain supported multiple roles then different combinations of these might be adopted in different deployment conditions. As a result the behaviour of the Service Domain and its associated service boundary would no longer be canonical.
As described in section 2.2, the approach BIAN uses to scope a Service Domain is to define it as the combination of an asset type with confirmed unique business context that is acted on by a single dominant functional pattern. This usually results in the definition of an elemental business capability.
The exception to this is for some asset types where the decomposition boundary that defines the limit of unique business context may sensibly vary for different banks. For example for one bank the decomposition of types of customer may be appropriate to the level where corporate and consumer customer types are considered to be distinct. In another bank, the definition of a consumer customer type may need to be further categorized to differentiate between banking and card consumer types. For the first bank there would be Service Domains corresponding to functions performed on two types of customer, for the second there would need to be Service Domains covering three customer types.
Another example where the asset type decomposition hierarchy can vary by bank is in the area of product fulfilment capacity. In this area a Service Domain should support the fulfilment of a discrete product/service type. But different types of bank may wish to categorize their product hierarchies with different groupings and levels of precision. In this area BIAN seeks to find a sensible middle path and individual banks can then adjust the BIAN model to suite their specific product categorization.
For example, consider the categorization of loan product fulfilment. Is it appropriate to define a loan as a single product type? If this is the case there would be a single Loan Service Domain that would need to support many different possible types of loans (such as mortgages, education loan, etc.) with configurable variations to its service operation calls as necessary. Alternatively there could be a collection of different fulfilment service domains for different categories of loan (such as corporate and consumer loans).
Current BIAN guidelines are that product types that have significantly different processing states/cycles and that would also usually be booked as discrete profit centers should be modelled as different Service Domains. As a result the preference in the prior example would be to define discrete Service Domains for different types of loans. These guidelines are being ratified and expanded based on practical experience as BIAN develops more content.
As noted, BIAN seeks to find a mid-point in its Service Landscape by defining Service Domains that can be easily adapted to align to the level of granularity suited to a particular enterprise. The BIAN designs can be interpreted by either concatenating or duplicating and specializing BIAN Service Domains as shown in Diagram 14:
Diagram 14: Rescoping a BIAN Service Domain
When two or more Service Domains are combined into a single Service Domain a review of their service operations is undertaken to merge the combination and eliminate any overlaps while retaining all of the features of the source Service Domains. When a Service Domain is duplicated and specialized the service operations are copied and then augmented with any unique features associated with the more specialized functional behaviours.
Note the approach to adapting BIAN Service Domains in deployment is covered in more detail in the third document of the BIAN ‘How-to Guide - Applying the BIAN Standard.’