Supporting Enterprise Architecture Methodologies at KPMG

David vun Kannon, KPMG

For the full presentation, click here.

ABSTRACT

The thrust of KPMG's work for its largest Financial Services clients encompasses the creation of enterprise level architectures. In fact, we attempt to take an architectural approach to most engagements, so that the work we do for our clients can have the broadest relevance and applicability.

On custom development engagements, we have found that it is important to spend significantly more time than usual on the design and requirements gathering phases of a project, to ensure that the project is scoped correctly and that we deliver what is expected. In order to keep this increased focus on the up front phases from lengthening the total project, it is important to leverage the design deliverables during subsequent implementation phases.

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 which is more flexible and open. This technology is an application of XML to the area of object modeling and code generation.

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.

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 XSLT, the transformation language component of 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. Rational Software and other vendors of UML tools are working with the Object Management Group to create an industry standard for representing UML in XML, a specification called 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: Java and Visual Basic source code, SQL table definitions, LDAP object schemas, HTML forms and ASP scripts. These diverse targets can be woven together into applications quickly.

In order to create these stylesheets, it was necessary to create a development environment which supported the rapid development and testing of the stylesheets, target XML documents, and associated DTDs. Since such an environment was not available commercially, we undertook to create one, starting last October. It provides the capability to edit the raw text of the documents as well as manipulate them with an outline view. We have recently added the capability to use several different transformation engines within the same tool, in order to test compatibility of implementations.

Another recent development has been the creation of a set of tools to transition legacy data representations, such as 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.

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.