Translating BIAN ‘down the stack’
Translating at the Application Level
In section 4.1.2 above there is a detailed list of the different ways a BIAN Service Domain partition can map to the underlying business applications and their constituent application modules. Points of clarification to add here are:
- A BIAN Service Domain may align to a single business application, several Service Domains may be covered by a business application or a single Service Domain may be supported by a collection of business applications
- It is more likely that at some level an application module within a business application will align most closely to a Service Domain
- It is not necessary that the mapped business application or application modules be implemented with a service enabled external interface. The exchanges can be realized by many types of technical exchange mechanism.
The main purpose of the Service Domain is to define a logical capability partition that can be used as pattern to better structure the application logic. Some examples of the way the Service Domain concept can be leveraged at the application level include:
- Specialization – because the Service Domain supports one ‘elemental’ capability its implementation can be optimized for that specific behaviour. Conversely more complex designs that support multiple behaviours are often forced to adopt technical compromises
- Externalization & Re-use – The Service Domain design partitions make it clear when actions should be delegated to other specialized Service Domains (‘Externalized’) – allowing the Service Domain to focus on its own specific role and for greater re-use of functionality between Service Domains. This important concept is explained in more detail with examples later in this Section
- Service Enablement – though it is not required it is anticipated that the Service Domains are implemented to act as service centers in a service oriented architecture (SOA). The many advantages of SOA are well documented elsewhere
- Loose Coupling and Multi Threaded – features typically associated with SOA, the Service Domain partitions are well suited to an implementation where the required collaborations between service domains are fully asynchronous and defensive (i.e. handle delayed/erroneous responses). Also where the Service Domain is able to handle multiple concurrent streams of activity.
Finally because the business role addressed by a Service Domain is enduring (see Section 2.1) it is often possible to build out and integrate the capabilities of a Service Domain incrementally. It may also be able to add new capabilities as new practices evolve without destabilizing established services, extending the shelf-life of business applications significantly.
Translating at the Infrastructure Level
A Service Domain and its mapped application module(s) can be further related to the supporting technical infrastructure. For simplicity in the explanations that follow it assumed that a single application module has been mapped to the associated Service Domain.
Each Service Domain will have its own non-functional profile in terms of its data storage access and processing requirements that need to be supported by the technical infrastructure. Most technologies provide comprehensive instance partitioning facilities so multiple Service Domains and their associated application modules can operate independently on the same platform allowing for Service Domains/application modules with similar operating profiles to be supported on shared technical infrastructures with the required performance profile.
Some optimization options can be considered for supporting the communications traffic between application modules as represented by the high level Service Domain service operations. Where the volume and frequency of the exchanges is modest most data exchange/communications mechanisms can be considered as is appropriate for the particular technical environment.
Where the exchange is high volume/high frequency it is possible to configure the infrastructure to facilitate the exchange. For example the logical service exchange between two discrete conceptual functions as represented by Service Domains can be mapped to a shared database with each having controlled access to their respective views of the data. In practice this would eliminate the need for a physical service based data exchange to realize the conceptual service interaction. Other technical communications options may be found.
Translating Summary
The mapping of Service Domain conceptual designs down the stack is summarized in Diagram 24:
Diagram 24: Mapping Service Domains down the stack