-TE (Quipoz Transformation Engine)

-BSD Business System Documentation

Addressing Operational Efficiency, Risk Management, and Basel II Accord Compliance

January 2003

-BSD

Business System Documentation

Quipoz Pty Limited

Table Of Contents
1 2 3 4 5 Overview ........................................................................................................... 1 System Documentation Defined ......................................................................... 2 Causes Of Poor Business System Documentation................................................ 3 System Documentation Necessity - Risk Profile................................................... 4 Automate The Creation Of Documentation......................................................... 6
5.1 5.2 5.3 Unified Modelling Language (UML) ........................................................................... 7 Deliverables Explained ............................................................................................ 7 Transformed System Documentation....................................................................... 8

About Quipoz A Capability Overview ............................................................... 9

Page ii

Last Saved 30 January, 2003

-BSD

Business System Documentation

Quipoz Pty Limited

1 Overview
It is generally accepted that software for which there is inadequate or inappropriate documentation poses the very real opportunity to impact adversely on the risk profile of the modern enterprise. For those organisations needing Basel II Accord compliance, complete documentation across the enterprise will be a pre-requisite for the development of operational risk management capabilities. These developed capabilities necessitate the collection of information in a systematic, uniform and useable format. Maintaining and developing enterprise applications without maintaining a quality compliant standard of documentation is like maintaining and developing a high-rise building without the aid or use of plans and specifications even at best, unacceptably risky and commercially negligent. The enterprise has a responsibility to its stakeholders to continually monitor operating risk, and therefore, it is a fact that enterprises are failing to reduce that risk if they continue to operate without adequate documentation of their systems. There is now a path to quick, accurate, and comprehensive production of digital documentation of the application regardless of the development language, operating environment, or age. Quick, accurate, and comprehensive because the process is automated, not a manual reverse engineering exercise. (Refer to the process diagram on page 7). The process is the Quipoz Transformation Engine, Q-TE, with the add-on component, the Quipoz Business System Documentation module, Q-BSD.

The process of business rule capture has been practiced on an informal basis for many years. Formalizing this process, and automating portions of it, completes the missing link in the redevelopment chain. Business rule capture and reuse is becoming a feasible endeavour that will profoundly change the way organizations redevelop the vast base of legacy applications. As the pace of redevelopment quickens, organizations will want to have the process and the tools in place in order to meet competitive information challenges of the next millennium. William Ulrich, Tactical Strategy Group, Inc. May 6, 2002

Page 1

Last Saved 30 January, 2003

-BSD

Business System Documentation

Quipoz Pty Limited

2 System Documentation Defined

Software is developed using methodologies related to accepted standards (viz. ISO), which follow a logical construction process. This process begins with the definition of requirements to support corporate strategic objectives; the business model. This is an enterprise model of the business with documentation. The second step in the development process is the definition of the requirements specification, which defines the information needs of users in a business process. From the requirements specification is developed the functional specification, which contains all of the information requirements, described in a set of logical data and process models. The next step in the building block is the development of the technical specification, which progresses the logical models (functional specification) into physical models. Finally comes the design and production of code.
Enterprise model of business (with documentation)

Develop Business M odel

Requirements Specification

Information needs of users of the business process, in English

Functional Specification

Information requirements described in logical data and process models

Technical Specification

Progresses the logical models to the physical

Design & Production of Code

Design, produce and document the code

Page 2

Last Saved 30 January, 2003

-BSD

Business System Documentation

Quipoz Pty Limited

3 Causes Of Poor Business System Documentation

Generally, the rule of documentation of Enterprise Application (Business System) software is that there are no rules. There are, of course, standards, methodologies, and requirements; but even the organisation with the tightest controls, and employing Best Practice methodologies, will usually find considerable gaps in its system documentation. Why? The reasons can be found in a combination of practical circumstance, and human nature. Practical circumstance is led by the fact that, over the life of the application, there will, most likely, have been many individuals maintaining and developing it, all with varying degrees of skill and care, all with a different output, and very few who remain with the business system. The human nature aspect equates to diligence and capability, or attitude and aptitude. As software is generally maintained and developed at the production level (the final step in the development process) the need and opportunity to fully document the process is lost, because there is no immediacy influencing the current task at hand; the maintenance and development. The foregoing is by no means an exhaustive list, but does capture the most frequent causes, and those common to most enterprises.

Page 3

Last Saved 30 January, 2003

-BSD

Business System Documentation

Quipoz Pty Limited

4 System Documentation Necessity - Risk Profile

Poorly documented business systems have the potential to impact on the enterprise risk profile by posing an escalating hazard to project, corporate, and market risk. That potential to impact is highlighted by the very definition of a business rule as a combination of conditional and imperative logic that changes the state of an object or data element. The risk factor is widely recognised by business, and has led to the development of an audit requirement, whereby the auditor is obliged to ensure that the enterprise has system documentation sufficient to guarantee no risk can go un-recognized. The following scenarios are the most probable consequences of inadequate or unavailable documentation: Reporting Risk (Regulatory, Compliance and Basel II) The underpinning tenet of regulatory and compliance reporting is accuracy, along with the associated requirements of relevance and timeliness. Without adequate system documentation, reporting requirement development and maintenance cannot be accurately tested, and therefore poses a considerable corporate and market risk. There are implications from Basel II that business systems that are not fully and adequately documented are not compliant with the Accord. With all three levels of reporting, internal accuracy is a paramount pre-requisite to ensure the market perceives corporate integrity and competence and that operating licenses and approvals are not jeopardised. System Maintenance Risk The most common and often reported practice in enterprises where there is no specific enforced and audited procedure for creating and upgrading documentation during system maintenance, is that there is no documentation produced. Without an understanding of the effect on the system as a whole, undocumented alterations to the underlying code, or to the technical specification, can have an unpredicted outcome on the efficient and effective conduct of the system. System Development Risk The risk identified with the non-documentation of system maintenance, so the development of the system under the same conditions poses an even greater risk profile. The most often quoted justification is that the developer(s) are still on staff, and that all the necessary knowledge is safe. The reality is that neither the knowledge, nor the system is safe. The knowledge may depart at any time, for any reason. And is the system really safe if undocumented alterations have been made to a system without beginning adequate documentation? System Testing Risk In order that the integrity of the system is maintained during and after maintenance and development, the system must be tested before, during, and after implementation. For that testing process and procedure to be accurate, test cases must be developed from existing business rules. If those business rules either do not exist, or are incomplete or inadequate, then the system is at risk, because the testing process is flawed. Flawed because it is only by use of the architectural specification that the components of the software and the relationship between them can be mapped. The testing process generally has two major components to be satisfied; validation and verification. Is the software doing the right job, validation and is the software doing the job right, verification. Verification is the checking or testing of items for conformance and consistency against a specification. Validation is the process of checking that what has been specified is what the user actually wanted. Validation and verification activities cannot be meaningful unless there is adequate specification of the requirements.

Page 4

Last Saved 30 January, 2003

-BSD

Business System Documentation

Quipoz Pty Limited

Gap Analysis Risk In the circumstances where there is a necessity to conduct a gap analysis, (that is, examine the gap between the current system capabilities and the present business performance requirements) there is very obviously a major impediment if the current system is either not documented, or not documented adequately.

Page 5

Last Saved 30 January, 2003

-BSD

Business System Documentation

Quipoz Pty Limited

5 Automate The Creation Of Documentation

Quipoz automates, using the Quipoz Transformation Engine (Q-TE), the transformation of business systems from the current language and operating environment into a modern object-oriented architecture (Java/J2EE); relational database enabled; and platform independent. This automated process delivers, using the Quipoz Business System Documentation engine (Q-BSD) as an add-on to Q-TE, a full and comprehensive digital set of system documentation. The source of this set of documentation is a full, comprehensive and auditable, 100% accurate and 100% complete set of business rules (business object model) delivered in a browser format, in plain English. Producing the rules associated with each and every line of code, and displaying them side-by-side, establishes an audit trail. (See examples below)

Page 6

Last Saved 30 January, 2003

-BSD

Business System Documentation

Quipoz Pty Limited

This document can be viewed, also using the browser, in an hierarchical structure (a la Windows Explorer) by a variety of views: by program; by business function; or by business object.

5.1

Unified Modelling Language (UML)

In the Business System Transformation process developed by Quipoz, the production of documentation as an early process output can be achieved in UML structure, and the development of the Business Object Model is already Basel II compliant.

5.2

Deliverables Explained

The following table describes, to some extent, the relationship between what the Q-BSD process will deliver, and what is generally accepted as the documentation deliverable. Deliverable Design of Code Completeness (as delivered by Q-TE) 100% Comment The application program structure (before and after transformation) is used to display the extracted business rules. See above. The Quipoz process utilises various tree structures to summarise and display business rules. See above. Quipoz produces a high-level business object model as a starting point for our clients.

Technical Specification Functional Specification

100% > 70%

Requirements Specification Business Model

> 20% > 15%

Page 7

Last Saved 30 January, 2003

-BSD

Business System Documentation

Quipoz Pty Limited

5.3

Transformed System Documentation

The diagram below illustrates the stage in the business system transformation at which documentation is produced.

Consistency Review Confirm Consistency

Identify Business Object

Coding & Client Standards

Post Processing

Test Cases

Source

Load Repository

Parse the Source

Apply Standards

Generate Code / Screens / DB

Application Tuning

Q-BSD
Test Cases And Results Business Rules

Grouped By Program Business Process Business Object Business Rules

Q-BSD
Object Models Test Results

Generated from the current system

Risk Reduction Basel II

Generated from the transformed system

Basel II

Gap Analysis Decision Making Test Case Development

Reporting Maintenance Development

Figure 1: Q-TE Process This documentation, it should be remembered, is documentation of the current system only. However, the earlier description of corporate value embedded in the documentation (risk reduction, regulatory and compliance reporting, Basel compliance, gap analysis and system testing capabilities) is as relevant whether the current system is to be retained in its current operating environment, or a full transformation is to be undertaken. When a business system is transformed, a new set of digital documentation is produced which is a complete map of the new, transformed, application.

Page 8

Last Saved 30 January, 2003

-BSD

Business System Documentation

Quipoz Pty Limited

6 About Quipoz A Capability Overview

Quipoz has developed an engine that automates the process of business system language transformation. The Quipoz Transformation Engine (Q-TE) takes business system applications and reproduces them in Internet-enabled languages and architectures such as Java/J2EE. As an early output in the process, a full set of digital documentation is produced, allowing among many other things, the recognition of intellectual property and competitive advantage captured in the code. Most companies and government agencies that were early adopters of information and transaction process automation have been accumulating information and business rules since before the 1980s within their legacy Information Technology (IT) systems. And now, more than 5 years into the business revolution that is the Internet, many are still struggling with the actions required to transport them from the cost and inflexibility of those applications, written in now obsolete code. The Basel II Accord goes further than the normal competitive and operational issues that would drive transformation. The Accord indicates that business systems or components thereof (such as hardware platforms and operating environment) that are not, or will not be, supported by the manufacturer; are not, or cannot be, XML enabled; and do not have full system documentation are not compliant. Converting legacy applications that contain customer details, histories and business process rules into modern languages such as Java has, until now, been an arduous task. The only choice has been a manual rewrite of the application. The alternatives have been to buy a new application, build a new application or even build a modern front end while retaining the old application. In terms of cost, time and risk, the absolute winner is the automated transformation of the existing application. It is quick, less costly, no risk and yet retains all of the business rules and processes that most enterprises believe contains their competitive advantage. Quipoz was formed by a group of people with a history dominated by pioneering application and data migration. They were also involved in the preparation and execution of Y2K legacy code remedial work. With the input of almost 100 man-years of development, Quipoz has brought together this experience to develop our unique capability in the transformation of legacy applications: - greater than 95% AUTOMATION! This capability is set to revolutionise the ability to unlock corporate value. The ability to reduce applications maintenance cost by up to 50%, and dropping that, say, $5 to $50 million to the bottom line where a company is valued at a price earnings multiple of 15. Suddenly that has added $75 to $750 million to shareholder value. On a more functional level, there are substantial benefits across the total business. Information Technology (IT) operations are now able to reduce maintenance costs and risks associated with older systems. They are now able to present to the business units more flexible systems, browser based, with a much quicker time-to-market for new products. In the financial services market, for example, the creation of straight through processing capability reduces costs and presents a competitive advantage over rivals who are still constrained with legacy systems.

Page 9

Last Saved 30 January, 2003