The financial services industry in continental Europe is in a stage of transformation. Banking has traditionally been an integrated business, where financial institutions exclusively distributed self-developed products via proprietary channels and fulfilled all transaction and support services in-house. To decrease costs and simultaneously enhance customer utility, banks are increasingly focusing on their individual core capabilities while exploring different sourcing options for non-core capabilities. Consequently, they are disaggregating their value chain into independently operable functional units. As communication capabilities reach higher levels of performance and reliability, these functional units are combined across corporate borders, thereby increasing sourcing options and flexibility.
Analogous to software engineering components, these functional units are referred to as modules. From an organizational point of view, these modules are easily manageable and stable units with a high degree of autonomy [4]. Coordination between modules is primarily via non-hierarchical mechanisms1 of coordination [6]. Each module represents a distinctive core capability embodying a set of business functions.
Figure 1 shows a possible sourcing mix of a typical retail bank. In this case the in-house capability “Credit Card Processing” is used by third parties as well as by their Internet platform. Other capabilities, such as “Credit Rating” and the distribution channel “Call Center” are sourced from outside. The underlying business objective is to realize economies of scale through specialization and to enhance flexibility by loose coupling2 of business units [1].
The extent of this restructuring process varies among different areas of the financial services industry. It is quite advanced in the mortgage industry where specialization and modular design now are the norm. The formerly monolithic value chain is decomposed into separate activities fulfilled by specialized entities. Some market participants concentrate on distribution of loans, while others assume responsibility for operations and refinancing or customer service and administration (see the sidebar “The Transformation Process of Rheinhyp/Eurohypo AG”).
This transformation and disaggregation has, however, come at a considerable price. Communication across modules and enterprise borders remains cumbersome with fragmented processes. Data moves between firms primarily by fax, phone, and simple data transfer (for example, the SWIFT system). Manual re-entry occurs frequently when application boundaries are crossed. Traditionally, most IT systems in banks are monolithic entities with proprietary interfaces focused on a specific set of tasks. Consequently, they are obstacles rather than enablers of modular design. A new approach to system architecture is needed that reduces the complexity and costs of coupling information systems as well as increases flexibility to accommodate change.
Service-oriented architectures provide such an approach.3 Service-oriented architectures are a promising step toward modular design of business functionality in banking, providing a method to reduce complexity and increase the flexibility of coupling internal and external business units. IT resources are considered as being available and discoverable as location-independent services on the network. The architecture provides a layer of abstraction that hides complexity of technical implementations, such as the programming languages or platform specifications underlying such services. Access is provided in a flexible, dynamic, and cost-effective manner.
Web services are the key enabling technology that implement service orientation. Being a standards-based approach to distributed computing, Web services reduce the details of interface implementation. This allows value networks to run at lower costs by providing flexibility to connecting applications and reducing interface-negotiation efforts between collaborating parties. Additionally, it leverages existing technology: instead of replacing legacy systems it introduces a new layer. It is placed on top of (existing or newly developed) applications encapsulating independent modules and providing a set of standards for interfaces. The goal is to get more value out of existing assets [2].
Although service orientation, related syntactic interfaces, and exchange standards provide significant means to achieve loose coupling, semantic standards for vertical industries have yet to be established. These standards would provide a common understanding to enable integration of new modules, with minimal negotiation effort. Semantic standards need to not only cover data and services being exchanged, but also the protocols, terms, and conditions under which business is being conducted.
Figure 3 structures aspects of module integration as an Integration Impedance Stack. The bottom layers have already been tackled by standardization of transport protocols (such as TCP/IP and HTTP), document formats (XML), security (WS-Security) and transaction protocols (BPEL, WS-Transactions). From a business perspective, issues such as business entity management and business process management arise. Hence further research is needed to identify general functions and arrange them by business-functional affiliation (similar to Figure 1) or processes. In this way, companies could generate a capability or module map4 that provides a logical structure and an initial approximation of the resulting business application environment. Using and exchanging such a map facilitates collaborating parties gaining a common understanding about banking modules. Beyond that, business protocols and policies must be established regarding the setup, execution, monitoring, and change of processes in order to facilitate cross-enterprise collaboration. Once all layers of the Integration Impedance Stack are implemented, the financial services industry will be better able to reap the full benefits of service orientation.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment