Applying Service Domains in Different Technical Environments

The Service Domain mapping approach is outlined for three general technical environments. But before describing these it helps to consider two discrete aspects of the Service Domain specification as these aspects play different roles in different technical situations. A Service Domain can be considered as the combination of its functional ‘core’ and a service boundary or ‘wrapper’ that handles the orchestration of the service based connections with other Service Domains as represented in Diagram 25:

Diagram 25: Service Domain split into two key components

The functional core contains the internal capabilities of the Service Domain, needed to fulfil its offered services. BIAN does not attempt to define the internal working of Service Domains so the description of this functionality is limited. BIAN has defined a simple table to capture prevailing functional and non-functional features for a Service Domain as described in more detail in the third document of the How-to Guide – Applying the Standard. These tables will not be part of the formal standard but as with Business Scenarios they help with the correct interpretation of the standard by providing examples and context. Service Domain Feature tables can be developed and used to define requirements and to map and compare application options.

The way the Service Domain specifications can be interpreted for systems solution development is considered for three different technical implementation environments:

• Conventional (legacy/core) system rationalization
• Host renewal/ESB integration and application/system assembly
• Loose coupled distributed/Cloud systems.

It is likely that all three technical environments will exist in combinations in many of the larger banks today.

Type 1 - Conventional (legacy/core) system rationalization

The BIAN Service Domain standard partitions can be used to assess, realign and repurpose the transactional mainframe based host systems. The BIAN Service Domains define non-overlapping functional partitions and the required connections/interfaces between them. The Service Domains specifications can be used to create a framework that is then used to assess the coverage of host systems.

The functional ‘footprint’ of the hosts systems can be overlain on the Service Domain framework by matching their functional coverage. The Service Domain Feature tables mentioned earlier can provide a simple checklist to help with this exercise. Because the Service Domains define discrete, non-overlapping functional partitions, the core system mapping quickly reveals gaps, redundancy and misalignment (where a system suited to one purpose is over-extended to support other purposes) in the overall application portfolio, as shown in Diagram 26.

Diagram 26: Using Service Domain partitions to do comparisons

When competing host applications/systems are compared using the Service Domain framework it is possible to do a more structured ‘like for like’ comparison by considering their respective coverage one Service Domain at a time. The framework is useful for getting a big picture view of the application portfolio. It is used to rationalize duplicated capabilities – a situation that is common in enterprises where there has been siloed development and/or many company acquisitions over the years.

The individual Service Domain partitions can then be used to define these overlaps in more detail to help identify and eliminate fragmentation of the functionality and data within the application portfolio. Consider the example of multiple product fulfilment business applications – a consumer banking application, a credit card fulfilment application and a mortgage processing application.

We will assume that these product fulfilment applications have been implemented independently and currently operate largely as stand-alone operational capabilities. As a result there will significant functional duplication such as customer reference information, customer access and servicing capabilities and customer transaction and accounting records.

At this stage the focus of the assessment is to determine to what extent this duplication of function and data leads to fragmentation and consistency problems (solution re-use is considered later). The assessment is performed for each Service Domain in isolation, considering all ‘mapped’ business applications – the three product applications listed above for this simple example. The impact can be assessed for the two key facets (function and data) as follows:

• Duplicated Functionality – to what extent will the user or customer experience different functionality when it would be expected/preferred that the experience should be identical or similar. If in this example a customer has all three products, how awkward is the experience of accessing each through a different application interface? Are there obvious synergies in terms of common or shared actions that could be exploited?
• Duplicated Business Information/Data – to what extent is the same business information/data duplicated across all business applications leading to problems of consistency and synchronization. If a customer changes their address on one application will it get reported to the others?

The point of these assessments is to determine the extent to which the duplicated functionality and data needs to be ‘synchronized’ in order to maintain the integrity of the overall operation. These simple examples are only intended to clarify the basic concepts for using Service Domains to assess and rationalize existing applications. More detailed examples and approaches can be found in the third guide of the series: How-to Guide – Applying the Standard.

Type 2 – Host renewal/ESB integration and application/system assembly

The second technical environment considered here builds on the insights gained from mapping existing host systems to the Service Domain framework. Moving on from identifying where duplicated data and function needs to be synchronized this second environment is geared to developing common or shared solutions that eliminate the duplication altogether. This approach is referred to as ‘externalization’ within BIAN. The main stages in the externalization procedure is shown in the following diagram: At a finer level of detail the mapping can be used to identify the opportunity to externalize capabilities matched to Service Domains that are built into standalone systems, but which could be shared by multiple applications. The concept of externalization is shown schematically in Diagram 27:

Diagram 27: The stages of externalization

Diagram 28 includes an informal systems architecture view of a stand-alone loan fulfilment application. A loan on-boarding Business Scenario has been used to identify some Service Domains and position them within the systems architecture. A more comprehensive collection of Business Scenarios would be needed to identify all of the major components but this sample is sufficient for the purpose of this example.

Diagram 28: More detail of loan externalization

In the right-hand view the Service Domains have been classified as being one of two flavours: do they offer functionality that could sensibly be used in another business application or are they likely to be used in only this particular application. Not surprisingly the majority (eight of nine in this example) fall under the first category. As a result the functionality represented by these Service Domains is a candidate for being externalized. In other terms they could be supported in some way by a common/shared solution. In this case we assume this sharing is achieved through service enablement.

The source of the common/shared solution could be selected from the existing host systems if it is possible to isolate and service enable that specific partition of its functionality. Alternatively a new solution can be acquired or developed and progressively integrated across the application portfolio by shutting down the existing internal solution partitions and adopting/embedding the replacement shared service enabled solution. The approach is described in more detail in the third guide of the series – How-to Guide – Applying the Standard.

In the simple stand-alone loans application example the significant majority of the Service Domain partitions were externalization candidates. Early observations are that this is also the case rather than the exception for a significant portion of production business applications. Accordingly there is an opportunity to achieve significant operational efficiencies and simplification through well architected and implemented operational capability re-use. One way to realize this is through the implementation of an enterprise service bus (ESB).

Configuring an Enterprise Service Bus (ESB)

As just described using the Service Domain framework as a guide, host systems can be broken into service enabled application modules. A technical mechanism that can then be implemented to support service based access to these shared service enabled capabilities is the enterprise service bus.

BIAN Service Domains define a comprehensive and non-overlapping collection of the required business capabilities for any bank and each Service Domain has its own unique collection of offered service operations. As a result the combination of selected Service Domains and their service operations can be used to define the service directory for a bank’s ESB. The host systems can be mapped to the ESB offering service based access to their functionality and resolving duplications as outlined earlier. These ESB enabled services can then be assembled to support different business applications.

The different techniques and mitigation approaches for service enabling host systems and the way applications can be assembled in an ESB enabled environment are explored in more detail in the How-to Guide – Applying the Standard.

The ESB systems architecture is shown the following simplified schematic:

Diagram 29: ESB based application assembly

The ESB approach can be used to migrate progressively towards a business application configuration where each operational service is offered by a single source and re-used whenever needed across the overall application portfolio. Such an arrangement would, in theory at least, eliminate operational duplication and maximise business capability re-use.

Type 3 - Loose coupled distributed/Cloud systems

Highly distributed and networked technical environments such as the Internet and more recently the Cloud provide powerful implementation options for interpreting the BIAN designs. The BIAN Service Domains can be used to define service enabled capabilities that can be accessed over the network. Business applications can then be assembled using combinations of these capabilities in a manner similar to the previous ESB example. But in this case the role of the service-enabled host systems acting behind the scenes through the ESB is replaced by any suitable service provider making services available over the network.

Business applications/systems assembled in these networked/distributed service based environments need to be ‘loose coupled’ (fully asynchronous) and defensive (i.e. deal with unsolicited, delayed and erroneous responses). They are likely to use message queue and state management and triggering mechanisms in their implementation. Some example system architectural features are outlined in the third guide of the series: How-to Guide – Applying the Standard.

The way the BIAN Service Domain partitions can be matched to a highly distributed Internet or Cloud based technical environment is summarized in the following schematic:

Diagram 30: Cloud based deployment environment

The requirements and implications of service oriented application design for business information and data scoping and precision outlined earlier in Section 4.1.3. of this guide are of particular significance in this distributed environment. It is to be expected that different service centers will reside on different technical platforms with their own data interpretations of the business information exchanged through services.

Note that the service exchanges that are defined in semantic terms can combine physical movements of resources, free-form conversational dialogues but will also typically include some portion of machine representable data. A service exchange may also be implemented as a simple one or two way transfer or may involve a complex negotiation/dialogue. For the machine representable content it is necessary to translate the high level semantic service descriptions into a more detailed collection one or more data messages.

In more conventional technical environments the application-to-application service exchange is typically driven down to the data and communication infrastructure where machine-to-machine message based interfaces are realized. The message data payload needs to conform to a commonly accepted data format/convention for these exchanges to work. This can be a significant design overhead that requires that all data fields conform to a common schema that can be consistently interpreted at the machine level.

In the cloud environment the exchanges are initially resolved at the semantic level – agreeing in general narrative terms the required business participation and service dependencies. From there the appropriate level of precision needed for the correct interpretation of these services exchanges needs to be determined. The level of data precision and definitional alignment in the exchanged machine messages will vary for different types of service exchanges.

For the exchange of financial transaction details it can be anticipated that the required level of precision will be very high (both parties will need to share common data element specifications). But there are some exchanges, typically in areas that are less transactional and more to do with business and relationship development where such a high level of precision is not necessary for the exchange to work. The involved parties can agree the meaning of information items at the semantic level and then their own internal data representation can be different. This looser, ‘semantic level coupling’ is shown in the following schematic

Diagram 31: In the cloud communication can be semantic

For example, both parties can agree on the definition of the term ‘prospect’ as being ‘an individual that has expressed an interest in doing business’. This may then be referenced in any service exchanges between the parties. How each uniquely identifies the prospect and what specific information they might maintain etc. can be handled independently within their respective machine environments.

There are already commercially available cloud based banking solutions in CRM and risk management. The operational behaviours enabled by the technology are particularly well suited to the networked/collaborative nature of the operational activities in these areas. The introduction of the BIAN standard can support standard solution designs that will improve re-deployment and integration activities for cloud based offerings in the industry in general.

Using BIAN Service Domain partitions to define API’s

BIAN recently published a white paper that describes how BIAN Service Domains provide a template for defining and managing Cloud based services. This can include providing application program interface (API) based access to these services. The white paper can be found at http://www.bian.org.

A key consideration explained in the white paper addresses how access to the services can be controlled. Many banks are looking ways to move beyond offering ‘packaged’ products and services to their customers to providing direct access to banking capabilities. This would allow customers and third parties to integrate the bank directly into their operations somehow. Bank’s wanting to provide external access to their capabilities need to find a way to do this in a secure manner.

Achieving adequate security spans many levels, including the platform and application access controls (IAAS/PAAS) that are complex but for which solutions and approaches are already available or are rapidly emerging. The aspect that BIAN can provide help with is in defining the allowed use of offered services.

When a Bank enables service based access to capabilities internally (inside the bank) it can assume and confirm that the services are being used for appropriate purposes by people with the correct access authority. When the service is accessed externally, this is far harder to manage. The bank needs some way to ensure the services are used appropriately and do this in a way where every external service access agreement does not need to be specified and implemented individually.

One way to do this is to use the role of the Service Domain to define the service access context and use this to control its use. The diagram below shows an example for a service call to access customer details using the Relationship Management Service Domain to provide the context.

Diagram 32: Cloud based service access control

The offered service API could be bundled in a software container with the pre-enabled constrained access to services allowing the external user to then develop their own logic within the container.

Combining Types 1-3 – Most banks have elements of all three

As noted it will be the case in most large banks that their existing application and systems portfolio includes legacy capabilities spanning all three types. One additional advantage of adopting the BIAN Service Landscape is that it makes it easier to engineer solutions that combine systems across these environments.

A good example combines wrapped host systems that are accessed through an ESB with external cloud based services. A customer management application may use such a configuration to combine access to internal product fulfilment systems and external cloud based CRM capabilities.

Diagram 33: Client server BIAN design