Dirk Riehle, Erica Dubach
UBS AG, Ubilab
P.O. Box, CH-8098 Zurich
Dirk.Riehle@ubs.com, Erica.Dubach@ubs.com
A modern bank needs several attributes for successfully surviving in the market place. Two key attributes are that it flexibly reacts to change, and is capable of innovation. Much of a modern banks processes and organizational structures are reflected in software. Therefore, a banks IT is a key player in guaranteeing these attributes. In this position paper, I discuss how maintaining these attributes influences the definition and introduction of new banking products, and how I believe that IT can improve its support through the use of dynamic object models.
From an IT (information technology) point of view, the typical process of developing and introducing a new product by a bank division looks like this: Some gifted bankers or a committee has an idea, plans it, and eventually assigns a development task to one of its software development/maintenance units. The IT unit then either designs and implements new software or adapts existing systems so that they support the new or refined product.
The development of a new product varies significantly between division and between product types. It might take from a few weeks to several months until a new application release is available. Different divisions use different tools, for example 4GL systems, case tools and procedural languages, or object orientation and frameworks.
Common to all these approaches is that
This approach leads to a noticeable delay between the definition of an idea and the ability of the bank to introduce the product into the marketplace. The consequences are that
Dynamic object models seek to overcome these problems by drastically reducing time-to-market, by giving immediate feedback on what a new application looks like and how it works, and by allowing bankers to experiment with new product types.
It is not yet well defined what a dynamic object model is. My take at a first definition is the following:
An object model is an abstract representation of a particular domain, using objects as the description mechanism. A dynamic object model is an object model whose object representation is interpreted at runtime and can be changed with immediate (but controlled) effect on the system interpreting it.
Obviously, a dynamic object model cannot be thought of without a system interpreting the model. The dynamic object model is embedded in a system, and effects its execution. Thus, dynamic object models require adequate software support. The software must provide the following functionality:
Let us examine the consequences of using dynamic object models.
The primary property of using dynamic object models and its supporting software is that changes to an object model can be effective immediately. The model engine may immediately execute the new model, which means, for example, that a new product type is in place with a minimal delay.
The positive consequences of this minimal turn-around time are:
The negative consequence of this approach is:
Product-specific tools typically do a better job in supporting the handling of a new product than generic tools do. But then, if product-specific tools are needed (which may not be the case for short-lived products), they can always be implemented later, after one has learned from using the generic tools what the requirements for these product-specific tools are.
As the UIUC workshop on "metadata and dynamic object models" showed, several systems of this type already exist and are in use in industries like insurance and telecommunications billing.
In addition, personal communication with other researchers suggests that similar efforts are going on in the R&D departments of large enterprise software solution providers like SAP and BAAN.
All systems we have seen use a metamodel based on object concepts. Existing approaches like knowledge-based systems, constraint systems, or procedurally implemented systems, tend to be too far away from providing the proper modeling elements for modeling "the real world."
Object orientation provides a significant advantage, because it has always been aimed at modeling domains, for example, business domains. Other technologies can be used as a support of object orientation. For example, constraint systems aid in implementing business rules. Thus, an object-oriented metamodel may serve as a core, as the common integration platform, but probably needs to be extended with further modeling concepts.
Systems with a dynamic object model are inherently reflective systems. As reflective systems are becoming more common, and the involved concepts become more widely understood, we may eventually help free reflective systems from their obscurity and give them a (non-technical) business justification.
Model driven systems have been built previously, probably precisely for reasons given above. The difference to these approaches is that today, we have an improved understanding of the modeling issues involved. In particular, we can use object orientation as a common basis, and we now better see the business justification.
I conclude that for a bank it is critical to build up know-how in this area. Whether this know-how is built up by buying and analyzing systems, or by developing its own systems is merely a tactical issue. What is important, is that these kinds of systems will play a significant role in the future. They are a key to achieving flexible reaction to change and maintaining being innovative.
Many issues surrounding dynamic object models are unclear at this point of time. As far as I know, they have not yet been addressed by openly accessible research. Questions, which I suggest for the workshop to address, comprise, but are not limited to:
I hope that these questions will contribute to a workshop at which we will have lots of fun and think deeply about these kinds of systems and what they can do for us.
Copyright 1998 Dirk Riehle, UBS AG, Ubilab. All rights reserved.