Model Driven Architecture in the Financial Services

Supporting Enterprise Architecture Methodologies at KPMG with the Use of Extensible Markup Language (XML) Tools and Technologies.

1. Introduction

The frequent use of the word architecture in the world of information technology presupposes an appreciation of the need to plan large projects, and not begin haphazardly wherever chance allows. This same appreciation used to be represented by the use of the word engineer. The earlier errors can be caught, the easier and cheaper it is to fix them.

Just as architects communicate their vision of a building through a set of blueprints, information architects have adopted a visual language, Unified Modeling Language (UML), the Unified Modeling Language, to communicate a system model in a visual way. The graphic nature of UML is a strength when the language is used to communicate ideas to humans. Our sense of sight is our strongest sense, after all.

Unfortunately, computer systems do not share our strong visual sense. This has impeded the use of UML models is directly specifying technical deliverables such as source code or other deliverables meant for consumption directly by a system or application. The Object Management Group (OMG), the Object Management Group, which controls UML, has created a standard XML representation of UML to address this problem.

The business benefit of this UML in XML, called XML Metadata Interchange (XMI), is that it allows resources to be shifted from later, costlier stages in the software development cycle into the earlier, cheaper modeling stages. Previously, there was not a reliable, non-proprietary link between modeling and later stages of development. This often meant that models quickly became irrelevant to the actual process of software development.

2. Motivation

One way to accomplish this leveraging is to use modeling tools such as Rational Rose to capture as complete a set of requirements as possible, and to shadow the implementation process, keeping the design documents up to date. Rose includes tools that allow code generation automatically from models. This automatic code generation is very important to leveraging the design documentation and keeping it relevant.

Unfortunately, Rose's internal code generation is "one size fits all." It is a "black box" solution that cannot be customised or tailored. Further, it does not take advantage of all the information available in a well-kept model. It also does not guarantee a consistency of implementation across different tiers of an application.

To address these and other issues with the bundled code generation capabilities of Rose, we have developed our own code generation technology that is more flexible and open. This technology is an application of XML to the area of object modeling and code generation.

3. Methodology

The key idea of our work is that code generation is essentially a transformation from one representation of an object model to another. A typical three-tier business application is made up of a User Interface layer, a Business Logic layer, and a Persistent Storage layer. The User Interface is the appearance of the application, collecting user demands and relaying results from the layers that perform the work. The Business Logic operates on data as directed by the user. The Persistent Storage layer maintains the memory, or state, of the system over time.

In each of these layers, there are representations of the objects in the underlying model. User interface forms, for example, capture the attributes of object instances. Data structures in the programs of the Business Logic receive the information captured by the interface, and tables in a Persistent Storage database store that same information for later use. So the object model shows up in each layer.

In addition, the shuttling of data between each representation in each layer has its own representation of the objects, a transmission representation. There is also a certain amount of programming that just moves data out of one representation into another representation, without actually performing "useful work" in the sense of pushing forward the business goal of the application.

All of these representations and transformations are tied directly back to the object model of the application, which in turn should relate directly to the object model of the business.

4. Analysis

To accomplish these transformations of representations, it is important to choose a tool that is appropriate. The tool (Visual Basic scripting) that Rose offers is inappropriate. The most appropriate tool available today is Extensible Stylesheet Language Transformations (XSLT), the transformation language component of Extensible Stylesheet Language (XSL), the eXtensible Stylesheet Language.

To make use of this XSLT technology, it is first necessary to bring the UML model into an XML representation, such as the OMGs XMI. Our work at KPMG uses a representation similar to XMI, and we can transition to XMI when it becomes available in tools.

Once an object model has been brought into XML, it is possible to apply transformations to it. We have created stylesheets that create the following different kinds of representations automatically: XML Schema and Document Type Definition (DTD)s for transfer syntax, Java and Visual Basic source code, Structured Query Language (SQL) table definitions, Lightweight Directory Access Protocol (LDAP) object schemas, HyperText Markup Language (HTML) forms and Active Server Pages (ASP) scripts. These diverse targets can be woven together into applications quickly.

Another recent development has been the creation of a set of tools to transition legacy data representations, such as COmmon Business Oriented Language (COBOL) copybooks, into the UML object model representation. The further refinement of this capability will vastly improve the documentation of legacy applications and improve the coordination of new development with current systems. This is the start of the "round trip engineering" part of code generation, the backing out of an object model from pre-existing source code. The next phases of our work will focus on round tripping, and ways to bring metadata from existing sources into the object model so that it can be leveraged in as many other ways as possible.

5. Further Work

There are many areas still to be explored, and we expect that the use of our tools and technologies on working engagements will reveal others. We are actively pursuing the use of UML statecharts, use case diagrams and sequence diagrams to create detailed user interface components. We are attempting to leverage sequence diagrams in source code generation. We also look forward to building application instrumentation via LDAP. Any one of these would be a significant advance over the state of the art in what is possible to create automatically from the object model. Together, they form a qualitatively different way to approach application development.

6. Application to Financial Services

KPMG has applied this methodology to important projects within the financial services industry. In each case, the key technical deliverable was the transfer syntax definition, whether DTD or XML Schema.

The first project was the design of a message architecture for the Global Straight Through Processing Association (Global Straight Through Processing Association (GSTPA), ). This consortium addresses the needs of cross border securities trading and settlement. After the execution of a securities trade, numerous instructions pass back and forth between the parties detailing the process of exchange of monies and securities. In a cross border environment this process is complicated by concerns over multiple languages, currencies and legal jurisdictions.

The next project was the design of the eXtensible Business Reporting Language (XBRL) specification. XBRL is the eXtensible Business Reporting Language, a language designed to enhance business and financial reporting. All forms of accounting and financial data can be represented using XBRL. The goal of the consortium sponsoring XBRL was a language that could represent financial facts for any business around the world, operating under any set of accounting principles.

Most recently, KPMG worked with the Research Interchange Markup Language (RIXML) consortium to create the RIXML specification. This language covers the area of investment research, documents written to provide an investment opinion or outlook on specific instruments (stocks, bonds, etc.), companies, governments, industrial sectors, geographic regions or markets and economies in general. A huge amount of research of an amazing variety is produced every day, and it must be routed, filtered and consumed by those companies which invest money in the financial markets. The first version of the RIXML specification deals primarily with the metadata attached to investment research documents. Subsequent versions may introduce markup to the text of the documents directly, perhaps by leveraging other markup languages such as News Markup Language (NewsML) for the text, and XBRL for the data.

Design and Development by deepX Ltd.