 |
||
 |
||
 |
 |
|
|
Case Study: Model-Driven Integration in Financial ServicesThis 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 application. Executive Overview
Project Goal
Results
The Role of Metada In Numbers
The CustomerThis 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. The ChallengeWith 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. The JourneyIn 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 formats. The bank looked for an integration solution that would meet all the following requirements:
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++. The DiscoveryMetada 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. The SolutionAn 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:
The ImplementationThe 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:
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.
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).
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 metamodeling. There were two major advantages of the metamodeling approach apparent already during the development 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.
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. The ResultsApplication 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.
|
|||||||||||||||||||||||||
|
Copyright © 2008 Metada
|