Multi-channel Bridging
From ViaNovaArchitecturaWiki
- This pattern has been originally described in the article “Architecture Patterns for Enterprise-wide SOA” [Cace, 2008][1]
Figure 1 Multi-channel concept in the Dutch Government Reference Architecture (NORA)
Contents |
Context
Nowadays profit-seeking and non-profit organizations use multiple interaction channels to communicate with customers/citizens (business-to-consumer, B2C). This includes Call Centers, Internet portals, Smart phones and PDA’s, written correspondence (supported by standardized paper-forms), front-office counters (points-of-sale) and partner channels. In addition, this multi-channel behavior is also a vehicle for channel migration: the customer interactions are gradually moved to the channels the service provider prefers, namely the ones that require a minimum or no human assistance on the service provider side (channel substitution).
Problem, Forces and Tensions
Multi-channel behavior is essential for modern, information-intensive enterprises. If business service fulfillment is not shared over channels, the enterprise will not be able to maintain consistent business service delivery.
The already ‘classic’, SOA based solution is to use services to uncouple the customer interactions from the back-end fulfillment. The interactions are supported by ‘front-end applications’ while the service fulfillment is provided by ‘back-end applications’. The front-end applications are specifically made to provide the most appropriate customer experience for the given channel (or channels, when that is feasible and opportune to do - for example Internet self-service users and call center agents may use the same web application. This should be seen only as an optimization afterwards – the principle is to support each channel separately).
The back-end applications expose a number of services that are typically re-used by all front-end applications.
Yefim Natis of Gartner writes [Gartner, 2007]: “SOA is a perfect fit for multichannel applications. Documented separation of the back-end business logic, independent of the nature of the requester, from the requester-specific, front-end logic potentially enables application projects to deliver full application functionality to a maximum number of users in a minimal amount of time. …”
Multi-channeling requires that customer requests are processed uniformly: the processing of an inquiry may not depend on the channel used. It is an absolute requirement to have consistency of information and services across channels.
This business requirement is incompatible with the mature ‘stove-pipe’ information systems. The applications of these ‘classic’ systems tightly couple user interactions with the processing (the business logic and the data) which implies a monolithic user-interaction solution for all channels. There are problems associated with this issue.
Firstly, it is technically difficult to provide multiple user interfaces (mobile phones, Internet portals, call centers and so on) in a single application.
Secondly, the functionality of one such application cannot be properly integrated with the functionality of other applications. Consequently, users need to simultaneously access multiple enterprise applications. In some cases integration on the presentation level may suffice (this varies from the old-day ‘screen scraping’ to the modern ‘enterprise mash-ups’; this should not be understood as a statement against the enterprise mash-ups: those provide a great solution when we actually do want to expose business services separately). However, those do not address the substance of the business issue: customer interactions may not be hampered by the behavior of the information systems that are tuned towards efficient fulfillment of the services.
The separation between the front-end and the back-end presents a major change in the critical business activities of the enterprise. So we need to look more thoroughly at what is required to make our ‘service bridge’ meet the challenge. What constructs do we need to make this solution viable? What sort of ‘traffic’ should we expect to see on the ‘bridge’?
In order to understand the implications of this pattern, let us look at the functionality of the back-end services. That functionality can be logically clustered into three groups:
- In the first place, we need services that provide business functions that correspond to customer inquiries.
- Secondly, there will be services that expose some business logic that is common to multiple channel applications, to augment the first group of services. This includes access to diverse supporting functions like business rules, server-side data validations, inventory checks and the like.
- Finally, there will be services providing access to all other enterprise content that are not directly associated with any individual customer.
The first group can be further subdivided into services that:
- Process requests for a business service delivery;
- Retrieve customers’ personal data such as address, contract information, previous purchases and so on;
- Update customers’ personal data such as e-mail address and telephone number;
- Provide access to the status of a process initiated earlier.
These services corresponds strongly to the use cases that capture the most common customer interaction with the enterprise. That is to be expected, as enterprises intentionally push the implementation of business functionality into the back-end as much as possible.
To make this clear via an example, let us look into the self-service portal that enables citizens to acquire permits from their local authority.
Figure 2: Example use cases for an e-Government self-service: requesting a local authority permit
The functionality associated with these use cases can only be implemented in the back-end systems, which means that we effectively propagate the user’s requests into those systems.
That imposes some challenges regarding the synchronicity of the services. In SOA, we typically prefer all services to be asynchronous – this to allow for better utilization of resources and to keep implementation costs low. However, asynchronous interactions are inappropriate in the case of services that are exposed to channels; the functionality of the services is part of the interaction with the end-user. To match the customer expectations, those services must be synchronous, available 24/7 and high-performing. This applies not only to information retrievals; even some transactions need to be functionally synchronous, like updating a telephone number, an email address or a bank-account number.
On the other hand, service fulfillment is almost always asynchronous by nature (and customers do not expect anything else). The process may involve human interaction or it may be dependent on some external system which imposes unavoidable delays. In other words, the service fulfillment mostly commonly requires a long-lived process.
Based on this analysis we can group all operations as follows:
- Non intrusive operations (information retrievals), all synchronous (retrieval of customer data, retrieval of other enterprise content and diverse supporting functions such as data validations)
- Transactions that require functionally straight-through processing - all synchronous (simple updates)
- Long-lived transactions – asynchronous (the most business service fulfillments)
This grouping of operations imposes constraints that need to be considered when constructing solutions based on this pattern. How to ensure 24/7 availability? How to achieve the best response times? These have to be addressed by smaller patterns, some of which are suggested later in this paragraph.
To summarize, disregarding these considerations, we can conclude that there should be no substantial obstacles to realize this pattern.
Therefore:
Solution
Provide a bridge between the customer interaction channels and the common portion of the service delivery process by exposing a uniform set of services.
Figure 3 Multi-channeling in “Applied SOA: Transforming Fundamental Principles into Best Practices” [Gartner, 2007]
Resulting Context and Consequences
{needs editing}
Ensure that synchronous services are performing well. The asynchronous, long-lived transactions should be modeled as automated processes - consider the Business Process Composition pattern. Typically, customers/citizens require access to the information that that is related to them – use Enterprise Data Retrieval Services. If combined views over multiple data sources are required in multiple channels, consider Composite Retrieval Services. Performance issues can be addressed by Replication in the Middle.
In the resulting context, examine the implications for security and transactional integrity arising from the use of services. Select patterns that are best matching your technology choices (J2EE, .NET etc)
When exposing services to the outside world, consider application and runtime patterns associated with the business patterm EXTENDED ENTERPRISE of IBM [IBM, 2008].
This pattern appears to match the “thin mid-office” pattern as described in ‘Structures to Effectively Share Architectural Knowledge’ [Ponisio, 2007]
Examples
{Example(s) of applying the pattern.}
Example {company name or another reference}
Example {company name or another reference}
References
- [Adams, 2001] J. Adams et al: “Patterns for E-Business: A Strategy for Reuse”, IBM Press, Oct. 31, 2001, ISBN-1931182027. The most of the contents also available in (IBM, 2008) and the so called “Red Books” of IBM.
- [Alexander, 1977] C. Alexander et al, “A Pattern Language”, Oxford University Press, 1977
- [Cace, 2008] B. Cace, “Architecture Patterns for Enterprise-wide SOA”, Via Nova Architectura, [2]
- [Gartner, 2007] Y. Natis, “Applied SOA: Transforming Fundamental Principles Into Best Practices”, Gartner Research Note Id G00147098, 4 April 2007, [3]
- [Ponisio, 2007] M.L.Ponisio, K. Sikkel, E. Vermeulen, E. Poort, I. van Megen, “Structures to Effectively Share Architectural Knowledge”, University of Twente, [6]
