Naked Objects -

Naked Objects
By Richard Pawson and Robert Matthews

Case study: Arrears and collections

This case study is based upon a short exploratory project undertaken by a large UK-based bank. As for any large bank, 'Arrears and Collections' is a core business activity. At any given time it will have tens of thousands, perhaps hundreds of thousands, of products in arrears, ranging from a current account that has exceeded its agreed overdraft limit, to a mortgage where whole payments have been missed. Many of these situations are not serious: they may have arisen from a simple oversight or misunderstanding on the part of the customer, or possibly a clerical error by the bank itself, and will rectify themselves within a few days. At the other end of the spectrum, the arrears and collections department must deal with serious default, bankruptcies and fraud.

Business background

The sheer volume of the minor infringements dictates that they be handled initially by an automated system. This bank has a sophisticated system for generating a series of automated letters, of rising severity. The wording of these letters is a science: the system constantly tracks the effectiveness of each letter template, and tests new 'contenders' against the 'champion' letter for any given arrears status.

If the letters fail to correct the situation then at a certain point the case will come to the attention of an arrears and collections officer. The threshold for that transfer may be based on fixed criteria such as the amount and duration of arrears, or upon an assessed risk profile for the customer. The officer will then decide what new course of action to initiate. This may involve seeking to negotiate an agreement for the gradual repayment of the arrears, restructuring the debt, repossessing the goods (for a secured loan), or pursuing the debt through the courts. It may even involve the discovery that the borrower is deceased and the initiation of a claim against the estate.

Whilst the generation of automated letters is a model of technical sophistication, IT support for the interventions of an officer is minimal - little more than a speadsheet and word processor. Ideally, an arrears and collections system should seamlessly integrate the automated early stages of a case with the intensely manual later stages. Such integration would make it easier to track a single case from end to end, and to monitor the relationship between early tactics and later ones. It would also allow the officers to intervene earlier in some cases, and place others back into 'auto-pilot' for a period.

Approach

We worked with a small team of business and IT managers to explore a possible design for such a system using Naked Objects. The team had no difficulty identifying certain core business objects that would feature in the system, including Customer, Officer, Account, Transaction, and Case.

At any given time, each arrears case will be subject to a particular 'strategy', though this strategy will change according to how the case progresses. At the start of the exercise, the business managers referred to 'thousands' of such strategies. However, within a couple of weeks the team had abstracted them to just 13 core strategies, each of which has branches and variations:

Identify cause and try to identify non-arrears situations (e.g. technical errors).
Extend facilities (e.g. extend overdraft, offer new loan product).
Generate automatic letters of increasing severity.
Accept the customer's verbal promise to remedy by a specified date.
Make direct contact with the customer and establish circumstances.
Make and monitor an arrangement to repay (over a period).
Trace a customer who has gone missing.
Recover securities.
Take legal action.
Write off the debt.
Outsource the debt.
Claim against (the deceased's) estate.
Monitor account closely after rehabilitation.

One of the main challenges we faced was that both the IT and business manager involved had a very strongly process-oriented view of the world. They assumed that these strategies would be implemented using a workflow engine or some other form of high-level scripting mechanism, and would draw data, and perhaps even some limited forms of behaviour, from the core business objects. However, since part of the purpose of this exercise was to evaluate the potential of the Naked Objects approach, the team somewhat reluctantly agreed to think of these strategies as objects in their own right. (In fact the 13 strategies would all be sub-classes of a generic Strategy class.) Unlike, say, the Customer object, these Strategy objects have a sense of direction: they would be designed to follow a sequence of known states, even if that sequence might sometimes backtrack. It can be useful in object modelling to draw a simple distinction between 'purposeful' objects and 'non-purposeful' objects: the former can be thought of as vestigial processes, but it is important to understand that they do not 'sit on top of' the other objects in the way that processes are usually conceived. In fact, it is just as valid to envisage them as 'sitting inside' the non-purposeful objects.

Prototyping the system using the Naked Objects framework not only helped the team to envisage this concept, but also to see the benefits of this way of thinking. Now, instead of thinking of the strategies as verbs on a top-level menu, they saw them as nouns - represented as icons. Changing the strategy being applied to a particular arrears case could be envisioned, both metaphorically and literally, as dragging a new Strategy object into the Case object. Moreover, when an officer reviews a case, she can immediately see the history of the case summarized as a list of icons representing the Strategies previously attempted. Double-clicking on any of these icons would permit inspection of how that Strategy actually progressed and was terminated. It is very hard to get this kind of view from a workflow system. Each Strategy object is capable of executing a sequence of actions and responding to events such as new Transaction on the Account that is in arrears. Additionally, each Strategy will have its own exit conditions, which may include simply the passage of sufficient time. Upon exit, a given Strategy may replace itself with a different one or it may bring the Case to the attention of an Officer to make the decision.

In fact, experienced object-oriented programmers will recognise that this is a standard programming design pattern, coincidentally named 'Strategy'[Gamma1995]. Such patterns seldom seem to be known by business analysts, however. This brings out another general point about Naked Objects: they make it easier to apply the rich, expressive power of a language like Java or SmallTalk to solving business problems. Most methodologies insist that the analysis be independent of any programming language. This would be a laudable aim except that the net effect is that resulting designs fail to take advantage of these powerful object patterns.

Evaluation

Two things surprised the team. The first was that it was possible to design a sophisticated system purely in terms of behaviourally rich objects, without ever having to draw a set of process diagrams. The second was that accepting the constraints of the Naked Objects approach quickly yielded some insights into the nature and structure of the arrears and collections activity that no-one had previously seen (specifically, the abstractions that existed within the notion of strategies). Given the very limited amount of time that the business representatives could devote to the exercise, they were very surprised at the amount of useful work that actually got done. One comment was that: "In the time that we would normally have spent just discussing how to get started on gathering the requirements, we had actually built a simple working model of the business domain that yielded some new and useful insights into how our business actually operates."

A brief description of the responsibilities of four of the naked object classes follows.

Class: Account

Sub-classed for different types of account including: mortgage, credit card, unsecured loan, bank account etc. The object acts as a wrapper onto the account management system, which will perform the transactional and management reporting responsibilities. Specific responsibilities include:

Identify if it is in arrears and be able to advise the amount and age of arrears.
When the account first goes into arrears, either create a new Case, or if a Case already exists for that Customer, then add this Account to that Case.
Display a zoomable, visual history of the account for a specified period, showing planned and actual balances.
Calculate the impact of one or more hypothetical transactions upon the account (mostly used when making an arrangement - this ideally should be done like a spreadsheet).
Alert the Case either to a significant change to the arrears situation (in amount or age) or to any transaction.
Report arrears to credit agency if appropriate.
Freeze or make temporary restrictions.

Class: Asset

Most commonly these will exist because they are securities on a loan (e.g. a mortgaged property) or because they form part of the loan contract (e.g. a car). Asset can also be used to model any known physical asset in cases of recovery. The most common assets will be modelled as specialized sub-classes of Asset so that they can record their own specific details. Specific responsibilities include:

Initiate physical recovery.
Realize value (initiate a sale of the asset).
Assess net worth (e.g. apply depreciation).

Class: ArrearsCase

Responsible for managing the workload of the arrears and collections process, and for producing management information. The majority of arrears cases, however, will not involve the intervention of an officer. Specific responsibilities include:

Split, merge, or subsume other Cases.
Be brought back to the attention of an officer.
Be forwarded to another officer.
Choose initial Strategy upon creation.
Alert Strategy to changing events.
Provide management reporting on current status.

Class: Strategy

Some Strategies will operate automatically - others will involve an Officer. Each strategy has a desired outcome, which may be fixed or may be determined by the officer. Strategy is an active object - it is not merely an attribute. Strategy is a means to achieving an outcome, not a sequence of actions. Specific responsibilities include:

Select the version to be used (most Strategies have 'champion' and 'challenger' versions). This is done by the system, not by the user.
Take next action - when and what.
Generate the standard Communications appropriate to that Strategy.
Instruct the Account (e.g. freeze withdrawals).
Respond to events such as a transaction, communication from customer, increase in debt, or the passage of time.
Terminate itself (or be terminated manually by an Officer) and pick the next strategy (including referral to a officer to decide manually).
Benchmark itself - whether it worked or not, including by version.

Copyright (c) 2002 nakedobjects.org You may print this document for your own personal use, or you may copy it in electronic form for access within your organisation, provided this notice is preserved.