Naked Objects
By Richard Pawson and Robert Matthews

Case study: Government benefits processing

The DSFA's Business Object Model

The DSFA's Business Object Model identifies six primary object classes: Customer, Case, Officer, Communication, Scheme and Payment. The primary object classes in turn make use of several other objects, which can be considered secondary in role, but which are nonetheless still capable of being manipulated as objects by the user. In other words, the secondary objects are usually 'aggregated' into the primary objects. Objects are defined in terms of a set of responsibilities that they fulfil. The 'know-what' responsibilities indicate the attributes and associations with other objects that a user might expect to see and/or edit when that object is viewed on the screen. The 'know-how-to' responsibilities summarize the behaviour of the object. These 'know-how-to' responsibilities will typically translate into methods on the object, though not necessarily one-for-one.

We have listed the know-what and the know-how-to responsibilities for each of the six primary business object classes below. We are grateful to the DSFA for allowing this to be reproduced.

The responsibilities of the secondary objects were defined in similar manner, but are not included here for space reasons. We have also edited out certain details that are not important to understanding the object model.

Some of these responsibilities are not slated for implementation until Phase II of the project, which was going out for tender as this book went to press.

We have included this model as a good example of how to go about designing a system in terms of a small set of behaviourally-complete business objects. There is no implication that this particular model is suitable for use outside of the DSFA, although there are certainly patterns within the model that could have broader application.

Customer object

A customer is anyone who has dealings with the State and has been assigned a Personal Public Service Number (PPSN). The intent of the Customer object is to provide a single point of access to any and all customer-related information that might be of value in more than one context (e.g. for more than one scheme). Where information is clearly specific to one scheme, such as the recording of a mouth-map for Dental Benefit, then this information may be held in the scheme itself - but the guiding principle is to favour the Customer as the repository. The Customer is also the point through which any action that pertains directly to the customer (e.g. authenticate and communicate) is initiated .

The bulk of the data underlying the Customer object, and of some of the new secondary objects such as Contribution History, is held on the Department's existing Central Records database (CRS) . However, with the advent of the REACH initiative (the framework for E-government in Ireland) the Customer object should also be seen as the interface to the 'public service broker' that forms a major facet of REACH. Several of the responsibilities listed below are being explicitly planned for the public service broker.

This underlines the importance of specifying the responsibilities of the Customer object, and hence the interface to other objects, primarily in terms of 'know-how-to' responsibilities, rather than 'know-what'. Over time, several of these know-how-to responsibilities will be delegated to the public service broker, or to other systems, and the intent of the design is to make this transfer invisible to the rest of the system that is interfacing with the Customer objects. In the long run, it may be that the only responsibilities of Customer objects fulfilled within the DSFA's own systems are the knowledge of other DSFA-specific objects (see below). In the short to medium term, the Customer object will have to fulfil most of these responsibilities directly.

Know-what responsibilities
  • Cases in which the customer is cited.
  • Relationships to other Customers, including 'mother of', 'spouse of', 'nominee for', 'legal guardian of'.
  • Communications to and from the customer (that are not held within a specific Case e.g. advice of change of address).
  • Payment Methods - methods through which payments can be made to the customer e.g. bank account, Post Office details.
  • Addresses for communication.
  • Schemes in which the Customer is cited.
  • Overpayment recovery objects pertaining to the Customer.
  • Whether the Customer is an employee of the DSFA or other civil servant - in which case the object may only be accessed by a special unit of officers.
  • Contribution History - summary yearly details of the Customers social insurance contributions.
  • Means Assessments.
Know-how-to responsibilities
  • Find and Retrieve. This method allows the user to find an existing customer instance using any variety of search criteria available. It is implemented by wrapping an OpenVMS based specialised search facility and making it available through the Customer Object.
  • Communicate. The Customer object provides the ability to Communicate with the customer, using any of the specified media and addresses (currently surface mail, e-mail and telephone). This method creates a new Communication object which looks after the transmission and filing of that Communication. Communication can be in Irish if the Customer desires, so the Customer object knows the preferred language of the customer.
  • Authenticate. This means the responsibility to ascertain that the customer you are dealing with (for example by phone, face to face, on the web, or by mail) is the person who they say they are. This facility may use direct input from the customer in the form of a password, PIN, PKI, smart card, digitized written signature, or biometrics. At some point in the future it could evolve full facilities for the issue and maintenance of Public Services Cards. Authentication is likely to be implemented in conjunction with the REACH initiative.
  • Create a statement. The customer should be able to list all Payments (including overpayments) made in a specified period.
  • Update. An officer should be able to request, through the Customer object, that the customer checks their held information and updates it as appropriate (subject to the rules for verifying individual fields). This will usually produce an electronic or paper communication to the customer and may, in future, initiate and process data from other applications.
  • Register life event. There should be specific methods for dealing with the major life events such as birth, marriage, retirement, or death.
  • Respond to life event e.g. notify the Customer of the need to claim entitlements three months before their 66th birthday.

Scheme object

A Scheme object is responsible for the administration of a particular benefit or set of Benefits. Scheme is an interface. Each benefit scheme that the DSFA administers will be represented by a Scheme object that implements this interface.

There are, broadly, two different forms of Scheme: composite Schemes and component Schemes. Component Schemes model individual benefits. Composite Schemes are containers that hold one or more component Schemes. Thus, an instance of a Component Scheme can only exist in the context of a Composite Scheme. Individual Schemes will vary in the kind of support that they provide to the Officer handling the claim. At the simplest level, the Scheme instance merely provides a convenient place for recording the facts and decisions taken. At a more sophisticated level, the Scheme could implement some form of rules engine and/or a spreadsheet-like calculator. However, the underlying philosophy of the design is that the system provides a workbench to leverage the skills, and increase the productivity of the Officer - not to attempt to automate a process that necessarily involves judgement.

A composite Scheme will always exist inside a Case, creating a new one if necessary, in order to be processed by an Officer. However, once the Scheme is 'In Payment', then the Case will usually not play an active role. The batch system will interact directly with the Schemes. Certain Schemes will need the ability to bring themselves up for review after a certain period, or upon certain events - via the Case mechanism.

Any Scheme (composite or component) must implement the following generic responsibilities, plus any additional responsibilities specific to their own needs:

Know-what responsibilities
  • The Customer who is claiming the benefit and any other Customers cited in the claim. (Component Schemes do not need the former since they can get it from the composite Scheme they can belong to, but they may need the latter e.g. the Customer object representing the Child or the Qualified Adult.)
  • The Payment Method that the Customer wishes to be paid by, including nominee payments. (Component Schemes will default to the Payment Method specified in their parent Composite Scheme, but this can be over-ridden if, for example, the customer wishes different components to be paid to different parties or different accounts. Note that for the Free Schemes, the Payment Method specifies the Service Provider and knows how to deal with that Service Provider.)
  • Component Schemes held within this Scheme (if it is composite).
  • Start and End dates.
  • Status.
  • Any other information specific to this Scheme (or shared by its component Schemes) that cannot be obtained from the relevant Customer object.
  • The Case within which the Scheme is currently held.
  • All Payments made against this Scheme.
  • Certificates for various decisions made by the officer, including eligibility and review date.
Know-how-to responsibilities
  • Request needed information. In line with the Service Delivery Model, this capability could generate a personalized form (paper or electronic) on which the customer could confirm relevant existing details and supply any missing ones. For some schemes, this request could be going to other agencies (e.g. a school/college or doctor). The request would usually generate a standardized Communication object, filling in the fields as appropriate. Where the missing information should be held within the Customer object, then the responsibility to request the needed information is delegated to the Customer object.
  • Record the eligibility decision. This is equivalent to ruling the customer's eligibility for the Scheme. It involves creating a Certificate which represents the legal decision of the Deciding Officer. The claim cannot proceed until this stage has been passed. If the claim is disallowed, then the Scheme object continues to exist, but the Case that contains it may be closed. Deciding the claim may automatically generate an advice note, using the Customer's communicate capability.(Note: it will usually be necessary for the Officer to formally decide the eligibility for the composite Scheme and for each of the component Schemes that it contains.)
  • Calculate entitlement for any specified period. This responsibility is carried out by reference to the particular Scheme being processed. It implies that the Scheme must know the rates and rules for previous years, not just the current year. It must also know the payment frequencies which apply to the particular scheme. As new rates and rules come into force, these will be added to the Scheme definition. If the new rules and rates follow the same structure as the previous ones, then this can be thought of as just adding a row to a table. If they introduce new structures then the modifications will be more complex. Note, however, that all changes to scheme rates and rules are contained within the particular Scheme - they do not spill over into the Customer or Payment objects. The calculate entitlement responsibility is used as a prelude to generating a payment for that period, but may also be used just to advise the Customer of how much they are due.
  • Calculate claim start date. Where there has been a delay in submitting a claim, some backdating of entitlement is permitted. A set of rules exists to calculate the backdated start date.
  • Generate new payment for a given period. Depending on the Payment Method selected, this capability will typically be invoked by an external batch process running at a range of frequencies e.g. weekly, fortnightly or monthly. Application of taxation rules (with reference to the Customer's taxation status) may be an embedded part of this responsibility.
  • Generate a schedule of payments. This method will be used when the preferred method of payment is a book (i.e. it is necessary to generate payment vouchers at regular intervals - say, every 6 months or every year - or one-off payments such as a Christmas Bonus. The frequency of voucher generation and the number of vouchers in a book will vary from scheme to scheme). It may also be used during transition, for compatibility with existing systems.
  • Generate difference payment for a given period. This method will invoke the Generate New Payment, but will then net the amount against any existing payments for that Scheme for the same period. This will be used when, for example, the customer's circumstances change after a schedule of forward payments has been generated (e.g. new child born during the year). This responsibility can also produce a negative Payment (i.e. an overpayment to be recovered). Note: This is only for making corrections to future payments, and within a single scheme. In general, overpayment recovery is handled by a dedicated Overpayment Recovery Scheme.
  • Split payments in accordance with individualization or other legal requirements. This could be achieved by generating separate payments based upon a percentage split agreed with the Customers involved.
  • Correct an overlap. This means generating an Overlap object that will, effectively, transfer surplus payments made under this Scheme onto another Scheme.
  • Guide the user. This means permitting the user to look up the relevant legislation, or more likely staff guidance notes, relevant to processing the claim. This may be implemented as context-specific business help.

The following responsibilities apply only to composite Schemes:

  • Add component Schemes. This includes enforcing rules as to which such component Schemes can be added
  • Manage interdependencies between component Schemes. A simple example of this is that the CB Scheme needs to assign an 'eligibility order' to each of the (component) Child Claim objects - since they cannot calculate this for themselves.
  • Cascade methods on to the component Schemes. The most common one of these is the regular Generate Payment method.
  • Aggregate Payments generated by component Schemes. Most of this responsibility is delegated to the Payment objects themselves. However, the composite Scheme will need to enforce certain rules about which Payments can and can't be aggregated (e.g. because they are legally paid on different days of the week).
  • Bring itself up for review based upon certain events or the passage of time.

Communication object

The Communication object models a single communication, for example between an Officer and a Customer, or between two Officers. The role of the Communication object is not just to allow such communications to be created, but also to allow them to be filed.

Communications may be incoming or outgoing. In addition, the Communication Object is used to record remarks.

The transmission mechanism for a Communication is achieved through the Address object. The same user interface is used regardless of the transmission channel chosen.

A Remark is a Communication that has no recipient. It is typically made within a Scheme, Case or Customer object.

Know-what responsibilities
  • Recipient's Address (obtained from the list of Addresses contained by the recipient object i.e. a Customer, Officer or any other object that is communicable). The user may choose the particular address, but it will default to the first entry in the list.
  • Sender's Address (obtained from the sending object). This will default to the first entry in the sender's address list that is the same type as the recipient's address (although all written communications will list various ways of replying).
  • Subject. If the Communication was generated inside a Case, then that object will be recorded as the subject. This will not only allow the Communication to be filed in the right place, but will also potentially allow any reply to be matched up. This field could also hold other context objects.
  • Date
  • Status: draft, sent, received, returned, standard letter (read-only) etc.
  • Content. Text will be held in some generalised mark-up language (e.g. HTML).
  • Certificate (i.e. digital signature) if required.
  • Attachments. In a wide variety of formats (e.g. Word, Acrobat) that are themselves capable of being transformed into various forms such as paper and electronic image. Additionally, the content can include pointers to any expressive objects in the system, though these will only be of use to recipients who are on the system (i.e. internal mail). Attachments could also include digitized voice recordings.
  • Language of content. (English or Irish, initially).
Know-how-to responsibilities
  • Transmit. Execution of this responsibility is fulfilled through the Address object.
  • Edit. Allows text contents to be created and edited.
  • Reply.
  • Forward. This is done by creating a new communication that has the current one as the Subject.
  • Retrieve (class responsibility). Previous communications will be retrieved from lists held in the Customer, Officer or Case objects.
  • Attach a file such as a scanned image to a Communication.
  • Confirm successful delivery (also fulfilled in collaboration with Address).
  • Sign. Create a Certificate digital signature of the sender. This responsibility may append a digitised image of a physical signature, if desired.
  • Copy. This copies a whole Communication.
  • Lock. This turns a Communication into a standard read-only communication that can be copied.
  • Append. Used to create a letter from standard paragraphs.

Officer object

The Officer object is the single point of contact for information and functionality associated with an individual (an employee of the Department or an associate) who may use the information system. There is one instance for each such individual.

Users of the system have their own Officer object readily accessible, as this is the means for logging on and off, and for storing their personal desktop view. In addition the Officer object provides access to their current workload.

An Officer object may be 'virtual', that is, it may represent roles and/or departmental sections (e.g. the Claims Registration Section).

Know-what responsibilities
  • Relationships to other Officers. This includes supervisors, supervised, and peers.
  • Cases. This means cases that are currently assigned to the officer.
  • Communications to or from the Officer.
  • Addresses for communication.
  • Roles fulfilled.
Know-how-to responsibilities
  • Find and Retrieve. These responsibilities are broadly similar to those specified for Customer.
  • Log-on and off.
  • Capture and recall the user's desktop.
  • Present caseload. This responsibility can show all cases currently assigned to the Officer broken down by various categories including current status.
  • Manage in and out boxes.
  • Manage authorization levels. Authorization (to perform a specific method on a specific object) will be done by a system-wide authentication and authorization server. However, the Officer object will be a principal user interface onto this server (i.e. the means through which the authorization levels for specific roles and/or individuals are specified).
  • Communicate. This works in the same way as the Communicate responsibility of the Customer object.
  • Create a Certificate to record the basis of the Officer's decision.

Payment object

A Payment object represents a single payment from a payer (by default, the Department) to the payee (usually a Customer). A Payment is in many ways analogous to a Communication and shares some of its structure. Thus, the role of the Address in a Communication is replaced by a Payment Method, where that may represent a cheque, electronic funds transfer, electronic information transfer or a voucher (the latter usually forming part of a payment book).

The amount of the payment will have been determined by whatever created the Payment object (e.g. a Scheme, or, in rare cases, an authorised Officer), along with the date due. Payment can represent negative amounts for the purposes of recovering an overpayment

Payments are generally created at the lowest level possible to enable them to be posted accurately into the financial accounting system. Thus, a claim may give rise to the creation of several Payment objects representing different component Schemes such as Retirement Pension, Contributory Pension, Qualified Adult Allowance or Child Dependent Allowance. Payments that have been created but not yet executed and which have the same payee and date may be combined or merged with other Payments within the same payment period to form a single net transfer.

Know-what responsibilities
  • Scheme that caused the Payment to be created.
  • Payee's Payment Method. The descriptive label of the Payment Method includes the name of the Payee, and can provide direct access to the object representing the payee (e.g. a Customer or Agency).
  • Payment identification. For example, cheque number or voucher number.
  • Component Payments. This means that any composite payment knows what other payments it has been made up from.
  • Amount (expressed in a currency).
  • Status (issued, paid, stopped, reconciled).
  • Stop Reason, if status indicates that the payment has been stopped.
  • Payment Type. This indicates if the payment is a regular payment, a replacement payment, grant payment etc. This is a free-form field whose contents are typically determined by the Scheme that creates the Payment.
  • Payment period that it relates to.
  • Date due. (It may be that this is a function of the payment period e.g. first Tuesday in the period).
Know-how-to responsibilities
  • Merge with another payment (subject to rules). Typically, Payment instances are created at the level of Scheme elements (e.g. child dependent, fuel allowance) and then merged to form a single payment which is transferred to the Customer.
  • Post into the financial accounting systems.
  • Authorize. Most payments will be generated within Schemes, which will look after their own levels of authorization. However, it may be appropriate to put some additional generic concepts of authorization into the Payment object itself (e.g. for payments over 5,000 Euros).
  • Stop the individual payment or the entire book of payment vouchers.
  • Issue in the manner appropriate to the Payment Method.
  • Deduct tax, if appropriate, by reference to the taxable status of the payee and/or the reason for payment. (This can be thought of as splitting the payment between the payee and the taxation authority).
  • Advise. Generate an advice or payment to the payee, by generating an appropriate Communication object or by generating an advice note for inclusion in the PPO Book.

Case object

The Case Object is currently used to hold Scheme instances and is the mechanism whereby a Scheme instance can be linked to an Officer. Case can act as a holder for any supporting communications (including Remarks) and could in future hold scanned images of other documents associated with Schemes being processed, but which may not be explicitly held within the Scheme. However, the work contained in a Case does not have to be related to a Scheme. Instead it can be any type of Departmental work from correspondence to investigations.

Case provides certain workflow-like characteristics, including the ability to forward the case on to another officer.

Know-what responsibilities
  • The Officer currently responsible for the case.
  • The Officer to whom the Case was previously assigned (if any).
  • Schemes that form part of the case (which in turn know the Customers).
  • Communications relating to the case.
  • Other relevant documents (including, potentially, scanned images) and notes.
  • Current status. For example: Pending - customer; Pending - other; In payment; Closed.
  • Review Date - the date when the case is to be brought to attention for review. This date will usually be determined by the Officer.
Know-how-to responsibilities
  • Refer to another Officer. This referral may be temporary (e.g. for authorization to proceed) or a permanent handoff. The nature of the referral will make that clear. The referral may be initiated merely by dragging the Case object onto the appropriate Officer object. As well as changing the Officer assigned, the referral will generate a standardized Communication to appear in the in-tray of the recipient.
  • Alert. Publish and subscribe is a generic capability of the Expressive Object Architecture. Case is expected to be a significant user of this capability - using a specified event on an object within a Case that may change the status of the case itself.
  • Maintain history. All objects maintain a full history of both accesses and changes for audit purposes. However, for the Case object, the history of changes needs to be maintained in a form that is easily accessible by an officer - for example whilst dealing with a customer on the phone.