Case Study: Model-Driven Integration in Financial Services
This case study presents how metamodeling was applied in the area of enterprise application integration in a large bank.
Metada modeling tools have been used to define models of banking integration, parts of business logic, and Internet banking
The goal was to provide uniform XML interface to diverse backends. Integration services were to be used by information
systems supporting client interaction center, internet banking, and a branch application. The solution had to support
message routing, mapping, and translation to and from various message formats.
Integration project smoothly integrated all required services within planned timeframe.
From the start, modeling of the integration layer allowed full separation of integration model from the program code
that was fully generated from it into Java and C++. Integration analysts that analyzed and modeled the frontend-to-backend
comunication never had to be programmers. The approach allowed zero coding time, because when the analysts completed the integration
model the software was ready to deploy. Repeatable automated integration tests were introduced right in the first phase of
the development to allow models to be thoroughly tested.
The Role of Metada
- developed web-based modeling repository where integration analysts maintain different versions of their integration
- developed 100% code generation from models to Java and C++ code
- developed autotesting framework
- trained integration modelers
# Integration services
# Backends integrated
This case study takes place at one of the largest banks in Central Europe. The bank offers a wide range of financial
products and services such as retail and corporate banking, mortgages, consumer loans, insurance, investment banking, asset
management, pension funds, and leasing. Its largest groups of clients include households, small and mid-sized enterprises,
large corporations, and municipalities.
With the quickly spreading information and communication technologies, banks are faced with growing need for offering services
via distribution channels other than branches. People want to place transactions on call centers over the phone, use mobile
banking on their mobile phones, or Internet banking over the web. All services need to be offered through various technologies
and channels. Our customer, as most of other banks, has different services supported by different software systems (backends).
For providing similar or identical services over various channels, there has to be a uniform access to them. This situation
forces banks to introduce a software layer that integrates functionalities offered by different backends.
In the beginning of 2001, the bank started a project to build the multi-channel infrastructure (MCI). MCI was initially
designed to integrate several banking backends and offer their services over the client interaction center. More channels
were to be added later and enable also Internet banking and GSM banking.
The MCI architecture was formed from several subsystems: the integration layer, business processes layer, and front-end services
layer. It was recognized that these layers were to be connected by messaging interfaces and were to share a common objects.
The integration layer was expected to communicate with backends and translate their requests and responses to their respective
The bank looked for an integration solution that would meet all the following requirements:
Routing messages to different backends based on conditions.
Support for structured data messages with complex structures.
Support for collections (lists of items).
Mapping data among different data structures.
Translation to/from various message formats.
Need for fast communication and large throughput.
Ease of integration.
It was still a time when the boom of integration solutions was yet to start and for that reason, there was no ready solution
that could satisfy the requirements. The only conventional solution left was to hand-code the integration layer in C++.
Metada as one of the suppliers on the project with experience implementing a software system based on modeling and metamodeling
offered a viable solution to the integration problem. The proposed solution was accepted by the project management even though
it was very unconventional and unproven.
An integration modeling repository was built with a goal of implementation technology independent modeling of the integration
services and to allow for an automatic generation of integration layer program code and documentation. Metamodel was designed
in Metada metamodeling language that captured the required functionality of the system to be modeled and generated.
The modeling tool designed allowed modeling of the following entities:
Messaging Logic Objects (Services)
Value Mapping Tables and Mapping Functions
Backend communication adapters
The first step in the implementation was introduction of a naming convention. All banking products, subsystems, operations,
etc. obtained their codes and all messages and services were named based on these codes. This enabled the teams to talk about
the banking problems in one language and allowed for models to be consistently created in the repository. Good naming convention
also helped with navigation through large amounts of different model elements of different types.
Implementation proceeded in the following streams of development:
Modeling repository development
By means of Metada metamodeling environment, the whole modeling repository was automatically generated from the designed
metamodels. Initial metamodels were thus used to create the first version of the repository. During the project there were
some changes and adjustments made to the metamodel and the affected parts of the repository were always regenerated.
Execution framework development
Overall system architecture was designed and it was carefully measured what functionalities will be modeled and what are
the general functionalities that may become part of the framework. Anything that is used by the application in context of
all models should become part of the execution framework (i.e. authentication, network communication, format drivers, backend
adapters, mapping functions).
Preparation of code generators
Metamodels define what should be modeled about the system. Based on metamodels the modeling repository allows developers
to create the corresponding models. The repository then allows the models to be retrieved in structured way and use generation
facilities to generate program code or documentation from models. Code generators were designed (via XSLT transformations)
so that the code generated would fit into the execution framework being prepared.
Modeling repository allowed the domain experts to model the problem of banking transactions and integration of the different
backend services into one compound layer of services offered to the various channels (call center applications, Internet banking,
etc.). All the above streams of development proceeded simultaneously on the project. It was possible to start modeling the
system functionalities way before the execution framework or the code generators were ready. The only part that had to be
ready relatively early was the modeling repository. That means that metamodeling of the system and weighing what should be
modeled and what should become part of the execution framework is essential part of a development project that is based on
There were two major advantages of the metamodeling approach apparent already during the development of the project:
Requirements may be elaborated almost until the end of the project
The project had encountered big problems with negotiating the interfaces to the individual backends. Each backend system
was maintained by different department with different people and the process of defining what data will be exchanged in what
form was very lengthy and difficult. In fact all the negotiations extended during the whole project. On a regular project,
after defining the backend interfaces, implementation of the integration layer services would have been started, but on this
project a finished design (and thus model) meant also finished implementation, because the implementation program code was
instantly generated from the fresh hot models.
Code generation saved great amounts of development time
The MCI metamodel contains means for modeling of the banking object model. This model is used to generate program code for
the banking objects (several hundred). Almost at the end of the project if was figured out, that some utility methods need
to be added to each implementation of an object (i.e. serialization method for logging purposed; equals method respecting
inheritance and associations; etc.). If all of the objects would be hand-coded, then the late requirement for new methods
would take weeks to realize, nevertheless because all objects were modeled and then generated, it was possible to extend the
code generators to include these methods during code generation. It thus took only few minutes to add the new methods specifically
to all objects.
Technologies used: XML, XSLT, Java, C++
The whole project was short compared to the scope of functionalities it covered. The metamodeling and system architecture
design started in mid-2001, application modeling and framework development including code generators lasted until the
end of 2001. Then the system went into thorough testing phase and resulted in migration to banking production in early 2002.
Application of Metada metamodeling approaches enabled metamodels of banking enterprise application integration to be
defined and resulted in comprehensive modeling repository, which has been used since to model required functionalities of
the banking integration layer, business services layer, and parts of related application front-ends (i.e. internet banking
or call center support applications).
Modeling the multi-channel infrastructure enabled abstraction from technologies and allowed the banking functions to be more
apparent and explicitly expressed in models as opposed to being encoded in specific program code. Furthermore, implementation
technology independence of models enables model to be transformed into program code in different languages or technologies.
This feature has been found useful when optimizing some parts of the system, where one technology was smoothly replaced by
another without need to touch the functionality that the code realized.
It has been also shown that the same models may be used to generate code into different technologies simultaneously. This
has been demonstrated on generation of banking objects, messages, and their serialization/deserialization facilities both
to Java and C++, and later on to XQuery. Not using code generation would lead to extensive and error prone reprogramming of
the same functionalities into another language.
This case has shown how metamodeling may be applied on a real world and large scale information system development project.
The modeling repository driven by the banking metamodel presented has been now six years in operation without major changes,
whereas the banking models have changed extensively since then.