Banking Integration Factory


Mike Walker

Microsoft Corporation

November 2006

Applies to:
   Banking Integration Factory

Summary: This white paper describes the Banking Integration Factory. The Banking Integration Factory combines various software factories and builds on them to provide solutions for integration. This factory also introduces the Microsoft vision for composite banking applications. (9 printed pages)


Overview of the Technical Architecture
Banking Integration Factory Details
Value Propositions
Additional Resources


The goal of the Banking Integration Factory is to make it easier for Microsoft partners and customers to integrate banking applications and establish consistency in the ways that integration can occur. Integration between applications can be accomplished in several different ways. The first and most mature method of integration is by focusing on the integration of data; however, this approach leaves much to be desired, because the behavior that goes with it is lost. A second, much more useful method of integration combines service orientation and XML-based standards. With this method of integration, applications can be integrated while preserving behaviors and data to bring together disparate business logic. However, because there are many ways to provide a service that exposes application functionality, in addition to many ways to implement the XML standards used, lack of consistency can make integration at the service level cumbersome.

Thus, the initial goal of the Banking Integration Factory is to establish a set of guidance and tools to provide a level of consistency for service implementations. The factory does not develop new message standards for the banking industry; instead, it establishes commonality between vendors and the services they expose. This includes consistency in the interfaces they expose, compliance with WS-I profiles for increased interoperability, and crosscutting aspects such as configuration, exceptions, logging, security, confidentiality (encryption), service availability, and guaranteed delivery that will make high-quality service integration easier to achieve.

One goal of this guidance is to help establish agreement about the coarseness of the service interfaces to follow message-based interfaces instead of traditional RPC interfaces. Another goal is to provide consistency in the security of the exposed services, and guidance on exceptions and logging to assist in resolving integration problems more quickly.

The Banking Integration Factory also introduces the Microsoft vision for a third type of integration between banking applications that is becoming more popular. This integration is known as UI composition; with it, customers can achieve application integration in their user interfaces using one of many composite application frameworks. Customers can choose the type of composite application they want to build&#151including; smart client, Web client, mobile client, and Office client&#151using; the software factories from Microsoft to write their custom applications. This approach allows for consistently developed composite UI "parts" to be quickly combined into new applications without having to rewrite user interfaces for each business service that is consumed. Using the software factories, partners can create standard UI parts for these composite frameworks that work with their business services. Customers can then integrate a partner's functionality into their custom composite applications.

The Banking Integration Factory provides a set of proven and integrated practices that are exposed through patterns, how-to topics, reference implementations, a Visual Studio Guidance Automation Toolkit package, and architecture documentation. The factory contains deep industry technical guidance and tested source code that is based on real-world experience.

Importantly, the Banking Integration Factory uses both industry standards for Web services and industry standards for specific processes within banking to provide an open, interoperable architecture. One benefit of this is that existing assets can be reused while introducing new capabilities to the business.

Overview of the Technical Architecture

The Banking Integration Factory architecture builds on cross-channel initiatives (such as CRM and service delivery) that most banks have been acting upon for the last several years. Using service-oriented principles, banks can encapsulate their legacy systems and provide newer applications that support services "out of the box." This work is not complete, but its relative maturity provides a great approach to address the pain of cross-channel integration that the industry has been feeling for years. This infrastructure also provides a complementary environment in which customers can build composite solutions to sell and service a wide array of products in a single, channel-optimized user interface: Web client, smart client, mobile client, and Office client.

The Banking Integration Factory will use standard principles of system architecture and the latest technical advances to address the industry's major requirements for delivering a scalable, secure, manageable, and cost-effective banking infrastructure.

Introduction to Generic Application Architecture

Typically, enterprise architecture is described in layers and tiers, where a layer indicates software boundaries (or separation of concerns) and a tier represents a physical boundary, such as the boundary between a client computer and a server. A tier can host multiple layers of an application's architecture (such as a mainframe) or a layer can be deployed to a single tier (such as an application server).

The architecture illustrated in Figure 1 is divided into three discrete layers and additional resources, each of which can also be decomposed to have sub-layers. The Banking Integration Factory does not provide guidance and resources for all the layers in the architecture, but it is important that each layer be defined.


Figure 1. High-level architecture layers

The following defines some of the layers:

  • Data sources and services. These represent the application data and modular functionality that the service requires. An example of a data source is a relational database, and an example of a service is an external credit-scoring service.
  • Resource access layer. This layer contains the logic necessary to access data. The layer also contains service agents, which isolate the calling of diverse services from your application and can provide additional services, such as basic mapping between the format of the data exposed by the service and the format your application requires.
  • Business layer. This layer incorporates components that implement the business logic of the application. Simple services often require only a very simple business action, but services with more complex requirements may implement a Controller pattern or business rules for implementing service behavior. The business layer also includes business entities that are used to represent objects specific to a business domain. These entities can incorporate both state and behavior. Business-process automation and human workflow can also orchestrate these components to perform more complex business operations, such as account opening and relationship pricing.

The following defines layers that are addressed by the Banking Integration Factory:

  • Service interface layer. This layer defines the operations of a service, the messages required to interact with each operation, and the patterns by which these messages interact; these patterns are referred to as message-exchange patterns. The service interface layer contains a service contract, which describes the behavior of a service and the messages required as the basis for interaction. The service interface layer also contains a service adapter, which is used to implement the service contract and to expose this functionality on a certain endpoint. The service layer does not specify a particular message standard; instead, it specifies the standards in which the message is built and described (such as XML, XSD, or WSDL). The service interface layer is a good place to implement services that are based on open standards (such as W3C and WS-*) to provide interoperability.
  • Presentation layer. This layer describes the different ways end users can visualize and interact with application data. Using the presentation layer, the architecture can optimize the user experience for the device and human target ((Customer or Employee) + channel device). This layer presents the user interface (UI) and allows for data analysis, input, and simple validation. The business rules are centralized in the business layer, so that they can be reused across channels.
  • Components to address crosscutting concerns. These components address functionality that is common to multiple layers of the architecture. Examples of common functionality are exception management, authentication, and instrumentation.

In this generic architecture, the presentation layer and service layer communicate with one another through simple action-oriented interfaces that pass messages between the service and the consumer for functionality. Note that it is not only the presentation layer communicating with a service; it is also communicating with service agents in the resource layer, thus service to the consumer interaction can be either service-to-service or service-to-presentation. These services should allow any transport to be used along with standards-based messages; that way, each layer can be implemented in a technology-agnostic way and still maintain interoperability.

Messages between layers should support existing standards for functionality (this includes industry-specific standards and WS-* standards). This does not preclude the use of other transport types and message types from being used inside a service, but it does preclude encapsulation at the service fa&#231de;.

Fa&#231ades; are not monolithic interfaces; instead, they are a set of interfaces at the surface that is typically partitioned by domain type (such as account or customer). Because of this, each layer can and will have multiple service interfaces to support the business. These service fa&#231ades; should provide a coarsely grained interface that allows for a single message to complete an entire business function (such as UpdateCustomer or UpdateAccount) and multimessage&#150based; services with correlation (such as workflow).

Banking Integration Factory Details

Following the generic architecture described earlier, Microsoft partners in this initiative can deliver additional value to customers by exposing consistent business services and, optionally, presentation parts. Customers can use these to build composite applications. This architecture does not alter existing partner applications; instead, it complements them by adding consistency and composition capabilities. For example, a partner can deliver a service interface for a discreet business function along with a corresponding presentation part for a user to interact.

In Figure 2, the relationship between the UI part and the service interface can take on one-to-many relationships from the UI part to the service interface and many-to-one relationships to support multiple channels (such as Web client, smart client, mobile client, and so on); these combinations are referred to as partner factory bundles. Bundles can then be composed by customers along with their own UI parts (and, potentially, other partner bundles) into channel solutions that will deliver the best user experience addressing requirements of the channel and user.


Figure 2. Simple partner factory bundle

In Figure 3, the partner components delivered using the factory are pointed out in the generic architecture; note that the existing application from the partner remains unchanged. Partners can choose the business functions to expose and the types of UI parts (if any) to provide (such as SmartParts, Web parts, mobile client parts, and Office client parts, perhaps bundling them into different pricing tiers). Additionally, they can provide new non-composite solutions for their offerings, such as mobile or Office, using the factory. Microsoft will provide the platform infrastructure, guidance, and interoperability standards in the Banking Integration Factory for consistency of implementation across the partners. Partners will use the factory to build their bundles that can be tied to or sold separately from their existing applications.

Click here for larger image

Figure 3. Partner in the architecture (Click on the picture for a larger image)

In Figure 4, the Banking Integration Factory uses the generic application architecture and standard "off-the-shelf" software factories provided by the Microsoft patterns & practices team as a base to build on. Using the generic architecture and the software factories provides consistency in development, and capabilities between partners and customers.

Click here for larger image

Figure 4. Microsoft-provided parts in the architecture (Click on the picture for a larger image)

Additionally, the Banking Integration Factory provides a standard set of guidance for implementation by partners, including service interfaces, exceptions, and so on. The Banking Integration Factory is being developed collaboratively with Microsoft partners, so that specific integration and composite scenarios can be addressed. Future functionality may include:

  • An XML vocabulary normalization service.
  • SWIFT integration service.
  • Addition of modeling capabilities using the DSL toolkit.
  • Guidance packages for configuring partner modules using the Guidance Automation Toolkit (GAT).
  • Web site for publishing updates to interfaces and specific integration details between partners.

Initially, the Banking Integration Factory's focus will be to provide consistency in service implementations and crosscutting capabilities, such as service exceptions, configuration, security, confidentiality (encryption), service availability, and guaranteed delivery. For the presentation layers, customers and partners can use the factory to create new application UIs without focusing on composition capabilities (such as mobile clients or Office clients). As the factory matures and more composite assets are developed, composition may become the focus. However, the initial composition scenarios will probably focus on customer-built composite applications integrating with a single partner-provided bundle.

The current software factories from the Microsoft patterns & practices team are used "as is." The Banking Integration Factory will simply build on the existing assets, to provide additional guidance and tools for partner bundles to be built and used by customers with the standard software factories delivered by Microsoft.

Microsoft's Vision for Composite Banking Applications

Approaching banking applications using a composite strategy provides a method for combining the right building blocks together to create compelling solutions that deliver real value to the business. Composite applications are an especially good fit for service interaction. These applications build on service orientation and provide loosely coupled UI components that can be independently versioned and maintained; UI complexity (device and platform) factored away from business logic; and the ability to bring together disparate back-end systems into a single, cohesive client interface that is correctly targeted at both the device and the end user.

Composite applications can be built using a number of Microsoft technologies (such as the Composite UI Application Block, Customer Care Framework, Office Business Applications, and SharePoint/ASP.NET), but they all share a set of common characteristics. Most importantly, composite applications consist of loosely coupled, autonomous UI components that communicate by way of messages and take advantage of services that are provided by their container (also referred to as a composite application "shell"). This approach provides the ability to have organizationally or geographically dispersed development teams independently create modules that can later be composed into a unified application. This ability to version and deploy independently these autonomous UI components&#151in; addition to the ability to compose them into unique combinations, according to business need&#151provides; a great deal of technical flexibility, which ultimately contributes to business agility.

These composite parts can vary in their degree of capability, from a complete business process contained in a series of parts to finely grained parts that provide simple reusable functionality. Because banks and vendors can develop these parts against the same composite shells, it provides a unique ecosystem for these types of applications where customers can build their own UI parts for internal systems and use third-party parts to build integrated systems quickly without worrying about the required infrastructure.

Composite applications are especially important when creating applications that span lines of business or channels that have traditionally been segregated within the bank. This concept can also transcend enterprise boundaries by allowing you to create composite applications that interact with your business partners' systems. For example, a customer-service application in a call center can greatly benefit by integrating disparate internal systems, such as credit-card systems, deposit-account inquiry, and consumer-loan origination into a single, unified interface; with this integration, agents can easily provide quality service across a broad range of products that had previously been serviced by disintegrated, stand-alone applications. Extending this concept, the bank may employ the idea of "open architecture" to offer partner products, such as insurance, annuities, or other investment products. A composite application would allow your sales representatives to use a single, integrated application to sell your "organic" in-house offerings alongside open architecture products.

Because the UI components of a composite application are loosely coupled, they can be brought together in unique combinations, depending on the needs of the user and the business. For example, while using the same composite application shell, a teller, personal banker, and call-center representative would each use a different set of application modules, which could vary both by the users' roles and the product lines the user services or sells.

Composite applications have a clear set of benefits, but they entail some degree of complexity, especially for developers who are new to this architectural style. The goal of the Banking Integration Factory is to help reduce the "learning curve," manage the complexity, and provide consistency for integrated applications using composition.

Value Propositions

This section describes the benefits of using the Banking Integration Factory for customers and partners.


Initially, banking customers will benefit from a "time-to-market" advantage for consistent and richer integration into partner offerings. This integration will be "richer" by commonality across partner services for security, reliability, configuration, and implementation. By using the factory, Microsoft partners can agree on consistent aspects of enterprise-solution architecture.

Additionally, following the prescriptive architecture of the factory, businesses can see new, innovative channel experiences that cross products (and lines of business); for example, they can see and service a customer's personal and small-business accounts, credit or debit card, mortgage, investments, risk, fraud, and so on&#151all; in the same application. UI parts either built internally or acquired from vendors can simply be added to the standard Microsoft software factories, and they will "just work."


Partners using the factory will provide consistency in service implementations across the partner ecosystem. With this consistency, customers can more quickly integrate their systems when they need to. Additionally, by potentially introducing composite UI parts in their factory bundles, partners can deliver more options and value to customers who are developing composite applications using Microsoft software factories without extensive testing. Because of this, partners can focus on the business functionality of the services and user-experience components, instead of on the infrastructure required to support them.

System integrators will also benefit by using the factory to jump-start their banking projects and build IP on top for value-added services.


Reducing overall technology costs while increasing agility is a key deciding factor when organizations are looking to add new functionality to their application portfolio.

In an effort to reduce integration costs and improve interoperability, enterprises expect vendors to adopt open standards and service-enable their applications rapidly. Where possible, IT departments are looking to service orientation and composite-application strategies to reduce custom coding through improved configuration and personalization tools. The short-term goal of the Banking Integration Factory is to include more flexibility to use the best services, composite applications, and highly specialized legacy systems. Long-term objectives include varying levels of functional analysis and business end user self-sufficiency.

The Banking Integration Factory contains deep technical guidance and tested source code that is based on real-world experience. The technical guidance is created, reviewed, and approved by Microsoft architects, product teams, consultants, product-support engineers, and Microsoft partners and customers. The result is a thoroughly engineered and tested set of recommendations that can be followed with confidence when building, integrating, or purchasing applications from key vendors. Most importantly, the Banking Integration Factory is a sustainable model led by Microsoft, its partners, and banking customers that is developed iteratively for continuous improvement that enables agile banking solutions.

Additional Resources

For more information about Microsoft software factories, see the following resources in the MSDN Library: