4th International Conference on Principles and Practices ... - MADOC

Provided Services
Glue Code
Start Macro
Market Data
Payment Dates
Product-specific Parameters
Figure 1: An Excel-based pricing sheet for defaultable zero coupon bonds (ZCB) and credit default swaps
(CDS). The sheet’s embedded buttons trigger VBA code execution.
3.2 Prototypes as final products
The pressure of short release cycles hand in hand with
monetary constraints favour the acceptance of prototypes
instead of mature implementations. What first started as a
prototype often becomes an everyday solution 4 . Prototypeinherent
problems continue to exist for the whole life cycle.
Inflexibility reduces productivity – Prototypes are almost
always inflexible, hard-wired implementations of
the underlying mathematical description and models.
Missing the benefits of modern software technology,
even small variations in the financial products portfolio
induce huge reimplementation efforts. Instead of
concentrating on the creative aspects of contract design
and supporting trading & sales, financial engineers
have to struggle with hard-to-modify implementations
that decrease overall productivity.
Maintainability, extensions and debugging – Because
of high cohesion and strong coupling caused by interwoven
layers, the maintenance effort is huge. Local
modifications trigger changes in the sheet, the glue
code and in the underlying DLLs. Proprietary APIs
and complex architectures cause time consuming debugging
cycles.
Archaic Design – In the past, spreadsheet solutions were
tied to plain C/C++ DLL functions. Besides design issues,
a large amount of time was spent on low level programming
aspects like pointers, arrays, and garbage
collection. While the underlying C++ code may obey
the concepts of object-orientation, most implementations
stayed close to an inflexible procedural design
because of limitations in the wrapper code. Even today,
design patterns (see e.g. [8]), modular design, and
component-orientation are still uncommon.
Captured in proprietary solutions – Even without using
COM or .NET, typical spreadsheet solutions are intrinsically
tied to the Excel application platform. Migration
or cross platform usage is at least limited and
often illusory. Although many financial institutions
are using the Windows platform, there is a tendency
4 Exceptions of this rule exist, e.g. [7].
towards open systems like Linux in combination with
OpenOffice. The importance of cross platform solutions
will grow in the future, making a closed-source
ecosystem more and more uninviting.
4. COMDECO
Decreasing time to market cycles and the permanent demand
for all new products increases the pressure on financial
engineers. To assure a company’s market position, design
and valuation of derivative contracts have to be carried
out as optimal as possible. A newcomer’s market share is
enlarged when using improved workflows and already established
market players are able to strengthen their share of
the market. In fact, financial engineers have to face similar
problems as their colleagues in the software development
domain.
ComDeCo [9] aims at providing techniques and concepts
which offer a high degree of scalability, so the increasing
complexity of contract design and valuation can be tackled
efficiently. Albeit not being a silver bullet for all kinds of
problems in this domain, component-orientation is able to
provide the foundation for optimised design and valuation
frameworks. A derivative contract is modeled as an Active
Document which is manipulable by using visual composition
gestures, e.g. drag and drop. The domain-specific
framework of ComDeCo provides end-user compatible composition
facilities tailored to the demands of financial engineering
and an adaptable valuation architecture that is able
to price almost arbitrary contracts. In ComDeCo’s context,
the term “active” 5 refers to
• the ability to check and enforce consistency constraints
for derivative contracts, i.e. avoid meaningless design
attempts.
• the ability to automatically perform context-specific
adaptations, e.g. selection of the best-fitting valuation
algorithm and model.
The possibility to describe derivative contracts using functional
programming languages [10] is a hint indicating the
5 However, in the context of the generic general-purpose Active
Document framework Omnia, dynamicity is discussed
in a more abstract way based on the component and composition
model.
155