GuardIEn at Ford Credit Europe
Ford Credit Europe - Company Profile
Ford Credit Europe (FCE) recently launched Release 5 of the Loan Processing System (LPS). It was the smoothest launch of a major system that had ever been experienced by the company, and it was managed using the GuardIEn configuration management system from IET.
LPS is a major long-term program to replace all of the core business systems of FCE. It is being rolled out in phases, and Release 5 is the biggest so far in terms of effort and functionality.
To give some idea of its size, LPS comprises 352 on-line transactions, 121 batch transactions, 8.3 million lines of code and 557 DB2 tables. Release 5 was launched on time in July 1996, having taken 18 elapsed months and 45,000 man-hours in development and support effort. As well as meeting the timing, the system testing defect count averaged only one per delivered transaction, which represents a 300% improvement over previous releases.
So how did the team manage to achieve such outstanding results? According to FCE, it comes down to three main elements: strong project management, learning from previous implementations and automation of the model management and configuration management tasks.
"Before we started using GuardIEn, we spent a lot of time implementing changes to our integration test, acceptance test and production environments" says Nick Smith of FCE. "We handled change requests using a standalone spreadsheet application and manually performed the impact analysis to decide what objects required migration, generation and testing. Whilst we managed to complete the implementations on time, it took a lot of effort to check all of the changes for consistency and decide what needed to be done and problems inevitably occurred because it was a manual process. We had more production problems, for example timestamp errors and missed changes, than we would have wished."
Initially LPS implemented one major release a year, so this approach was feasible. With Release 5 though, the team decided that they needed to implement minor enhancement releases on a more frequent basis, and therefore needed to reduce the time and effort required to implement each release.
They decided to investigate ways of automating the model management and system implementation processes, and selected GuardIEn as the tool that was most tightly integrated with the Gen encyclopaedia.
The implementation of GuardIEn commenced in early 1995. This was a significant undertaking, since the project contained over 70 separate models, with a team of more than 50 people. The implementation started with Release 4 and was conducted in parallel with the existing procedures. The initial life-cycles used to control the objects were refined and simplified over the course of this release.
From the experience gained with the product, the LPS team proposed some enhancements that would simplify and streamline the use of the product in their environment, which were quickly delivered by IET. These included the automatic update of the status of action blocks when the parent procedure step was updated and enhancements to improve the way dynamically linked action blocks were managed. "We were very impressed with the speed with which IET delivered the enhancements we requested" commented Nick Smith.
The LPS team have also made use of the GuardIEn production update exit to create their own processing steps for their integration test and production updates. They have some unique requirements for DB2 binds and the GuardIEn exit enables them to integrate their own logic with the main GuardIEn procedures.
The figure below illustrates the LPS model architecture. The main features are:
- Multiple Business Models: Each major business system is developed in its own model. These models are kept separate throughout the life-cycle rather than merging the models into a large integration or production model. The GuardIEn production updating system therefore needs to be able to implement a single production update with code that originates from many models.
- Common Objects Model: Common objects that are used in more than one business system are maintained in a separate common objects model.
- Stub Action Blocks: To reduce the need to migrate data objects to every business model, ‘stub’ or interface versions of the common action blocks are used to implement the ‘call’ to common action blocks.
- Parallel Development: Releases 5.1 and 5.2 are developed in parallel. GuardIEn keeps track of changes to objects in both releases and by comparing the timestamps to a baseline stored in GuardIEn, it is able to automate the promotion of fixes applied to R5.1 to the R5.2 models.
"When we originally started introducing GuardIEn, we met some reluctance to learn a new tool during a tough part of our project life-cycle. Today the whole team of Managers, Users and Developers use GuardIEn daily to track and implement changes within our project, and consider it one of the key factors contributing to the quality of our work" concluded Nick Smith.
This article is based solely on Ford Credit Europes (FCE) own experience of working with IET. For the avoidance of any doubt, this article should not be regarded as constituting any form of representation by FCE in respect of IET and prospective customers should make their own enquiries.
