Naked Objects
By Richard Pawson and Robert Matthews

Case study: Government benefits processing

In 1999 we had the opportunity to design a set of behaviourally-complete objects that modelled the business of a large organization, and to create a system that met users' requirements simply by exposing these business objects directly to the user.

The Department of Social and Family Affairs (DSFA) is the Irish social security administration. Prior to 1998 it was known as the Department of Social Welfare. The Department depends heavily upon information technology to fulfil its tasks. It has some 2000 PCs, but its core transaction processing programs (both on-line and batch) are all mainframe-based, and accessed via some 4000 green-screen dumb terminals. These systems are technologically out-of-date and increasingly expensive to maintain. For example, they require manual re-programming every time the government changes the benefit rates or rules. Currently, there is a separate system for each major type of benefit - Child Benefit, Disability, Unemployment and so on. Although there is a Central Records System (a customer database, effectively), there is much less sharing of both information and functionality than there could be. For example, many systems have their own separate mechanisms for generating payments. Word processing, email and calendar facilities are provided through the mainframe-based All-in-One suite, and there is no integration between this and the transactional systems.

Demand for greater organizational agility within the Department has been growing for some years, and this translates into demand for greater agility within the information systems. Technological developments such as the Internet and smartcards offer significant potential benefits both to the DSFA and its customers, including ease of access, richness of information, and cost savings. The government has also been pressing for more agility, both in the ability to introduce new forms of benefits, and in improving service to the customer. There are various e-government initiatives in Ireland, of which the most significant is the REACH programme, which will provide a common 'e-broker' for accessing information about the services offered by multiple government agencies, a central means of identification and authentication, and a personal data vault that gives the customers greater control over their own privacy.

In response to these various demands, in 1999 the DSFA conceived a new Service Delivery Model (SDM) that emphasizes electronic commerce, agility and customer-responsiveness. The SDM highlighted the need for a complete new architecture for the core systems. It would not only support the specific needs of the SDM, but would also be more adaptable to future, as yet unforeseen, business changes. Early on it was decided that new architecture should be multi-tiered, and object-oriented. The DSFA's IS department had experimented with object-oriented techniques some three or four years previously, focussing on the idea that object-orientation could improve development productivity through re-use, but had produced little in the way of tangible output or results. In retrospect, the IS management felt that the previous initiative had been focussed much too inwardly on the IS department itself. This time, the motivation for thinking about objects would be to improve business agility.

Early experimentation

Early in 1999 the IS management became aware of the emerging set of ideas that would eventually become embodied in Naked Objects. They were attracted to the concept for several reasons. First, it advocated a very pure version of object-orientation, based on the idea of behavioural completeness, and the motivation for this was clearly to facilitate business agility, rather than to promote re-use. Although the management did not necessarily accept the full argument at that stage, it was clear that the objectives were well aligned with what they wanted to achieve. Secondly, the IS management were attracted to the visual concreteness of the approach. They felt that this would make it easier to get non-IT managers more involved with crucial design decisions.

Early in 1999, the IS department initiated some educational workshops on object-oriented concepts for some of its senior managers, both IT and business, with the help of one of the authors (Richard Pawson). Given that the Naked Objects framework did not exist at this point, and there were no known examples of transactional business systems having been built this way, The Incredible Machine was used as a metaphor throughout the workshop. In The Incredible Machine, the user is presented with a series of physical challenges, and must construct a simulation of a complex, improbable-looking, machine (in the style of the artists Heath Robinson or Rube Goldberg) to solve them. As well as clearly demonstrating the notion of a problem-solving system, The Incredible Machine is also very clearly object-oriented from the perspective of the user: the elements that the user drags from a parts catalogue into the workspace are not just visual representations, but bring with them the complete simulated physical behaviours of that part.

One of the workshops (a one-day exercise involving six managers) attempted to identify the core business objects that could potentially model the DSFA's business. The participants were invited to suggest object categories directly: no attempt was made to capture requirements or to specify use-cases up front. By the end of the morning a list of approximately twenty candidates had been produced. During the afternoon this list was reduced by identifying candidates that were duplicates, declaring certain candidates as sub-classes of others, and eliminating candidates that, with further discussion, turned out not to be core business objects, because they could be better represented as simple attributes or as methods of other objects. The result was a list of seven core classes: Customer, Case, Scheme (meaning a Benefit Scheme), Payment, Service (a non-monetary benefit such as a bus pass), Community, and Officer.

The group was next asked to imagine how users would interact with each object, by asking such questions as: What will this object look like on the screen? Where might a user want to drag it? and What actions will a user want to be able to invoke by right-clicking on this object? The result was a list of 'know-what' and 'know-how' responsibilities, with emphasis on the latter to avoid thinking of the objects merely as complex data sets. The result was a very crude definition of a set of behaviourally-rich objects.

These draft object responsibility definitions were translated into a crude visual mock-up of a system that might be used by a 'deciding officer'. The mock-up was actually a series of hand-drawn screenshots held as Powerpoint slides, but a well-rehearsed demo managed to create quite a realistic effect, with the impression of icons being dragged around the screen and menus popping up in response to a right mouse-click.

This mock-up of the DSFA system was created in Powerpoint in full-screen mode. Using a carefully scripted demo, the mock-up created the illusion of mouse-clicks, pop-up menus and new windows appearing.

The mock-up was demonstrated to a group of senior managers who had not been involved in the modelling workshop. A few of the responses sum up its impact:

  • 'I can see how everyone in the entire organization, right up to the minister himself, could use the same system'. This did not mean that all users would perform the same operations, or indeed have the same levels of authorization. Rather, everything the organization does could be represented as actions on the handful of key objects. Such a consistent interface could help to break down some of the divisional barriers, as well as making it easier for individuals to move into different areas of responsibility.
  • 'This interface might be sub-optimal for high volume data entry tasks'. There was some debate about this, until someone pointed out that the DSFA's commitment to electronic access (via the web, smartcards and telephone call centre), plus a more integrated approach to the systems themselves, means that most of the data entry work will disappear anyway.
  • 'This system reinforces the message we have been sending to the workforce about changing the style of working'. The DSFA is committed to moving away from a conventional assembly-line approach to claims processing, where each person performs a small step in the process, towards a model where more of its officers can handle a complete claim, and appropriately-trained officers might in future handle all the benefits for one customer. The managers at the demonstration felt that even this simple mock-up could help to convey to users the message that they are problem solvers, not process followers. This was in marked contrast to the approach proposed by some vendors, which emphasised using rules-based technology or 'intelligent software agents' to automate as much decision making as possible. Instead, the object-based mock-up suggested an environment where the users' natural problem skills would be highly leveraged. In this sense, the design of the system could be seen as helping to facilitate a fundamental cultural change.

In addition to this positive reaction from the user representatives, the IS management were also impressed with speed of this exercise compared to previous attempts at department-wide modelling (whether as objects, data, or processes). They were only too familiar with the phrase 'analysis paralysis'. Although the DSFA was by no means ready to commit to this new approach for a full-scale implementation at that stage, all agreed that the concept should be explored in more depth.

The Child Benefit system

At the beginning of 2000 the business case for action became more urgent. The existing Child Benefit Administration system needed to be replaced with some urgency. The Government had indicated possible future changes to Child Benefit that the existing system could not be modified to address. Child Benefit is one of the simpler schemes that the DSFA administers and is relatively small in scale: the existing system had just 50 users. Yet it also has much in common with other schemes. It seemed an ideal opportunity to start the deployment of a new approach.

In a series of workshops involving both senior managers and user representatives, the responsibilities outlined in the original object model (from the one-day workshop) were now fleshed out from the particular perspective of Child Benefit Administration. These ideas were immediately prototyped using a very early version of a prototyping tool designed by the authors.

The prototype of the Child Benefit system was created using a very early version of the framework that would eventually become Naked Objects, though this name was not used at the time. It had no persistence mechanism but had sufficient functionality to simulate some real operational business scenarios.

During the workshops, object responsibilities were refined and new responsibilities identified. New sub-classes and secondary (or 'aggregated') objects were also added. And the whole model was crudely tested against a number of business scenarios. Some screenshots from this prototype and an example use-case for processing a straightforward application for Child Benefit are shown on this page.

Additionally, the model was crudely tested against a variety of scenarios of how the DSFA's business might change in future. What is remarkable is how well the initial model from the one-day workshop stood up to these subsequent demands and tests.

Technology demonstrators

Meanwhile, another group was looking at how to translate these concepts into a working infrastructure that would fit in with the DSFA's technical requirements. As a public sector agency, all procurement is subject to the European Union tendering rules. Accordingly, the DSFA published an RFT (Request For Tender) for 'technology demonstrators' that would implement all the main layers of a scaleable enterprise architecture (including message broking, transaction monitoring, and persistence) using a relational database, whilst at the same time reflecting the design ethos of the prototype. The Department commissioned three such demonstrators, each using different object technologies: EJB, COM+, and a proprietary object-oriented package.

Phase I implementation

Having evaluated the demonstrators, the DSFA put out a new RFT for the design and implementation of a full-scale 'Expressive Object Architecture' and the business functionality necessary to replace the existing Child Benefit Administration system. Interestingly, the RFT did not provide a full functional specification, but it did provide a description of the high-level responsibilities required of the core business objects, which is reproduced in this section. The contractor would be required to undertake a detailed requirements specification at the start of the project, using those object descriptions. This was deemed to be sufficient information for the contractors to place fixed-price bids.

The contract was awarded in February 2001 to DMR Consulting (now known as Fujitsu Consulting) - with the original intent that the new system would go live in March 2002. Following some industrial relations issues to do with the business changes being introduced, the switchover was postponed until the summer of 2002.

The user interface of the implemented Child Benefit system is not identical to that of the prototype shown earlier, but it clearly adheres to the same principles: business objects show directly through to the user interface, both as classes and instances, and all business actions are initiated either via pop-up menus from the objects or via drag-and-drop. Moreover, the entire user interface is auto-generated, dynamically, from the underlying business objects. Screenshots from the implemented system are shown on this page.

This screenshot is taken from the implemented Child Benefit system. On the left side of the screen are the icons representing the core business object classes; elsewhere on the desktop are icons representing individual instances. One of the customer icons has been right-clicked to reveal the pop-up menu of instance methods available to this user.

The opened view of a customer object reveals both simple data attributes and the various associated objects in a navigation pane on the left. The pop-up menu for the associated CB (Child Benefit) Scheme shows that all the relevant behaviours can be invoked in that context without necessarily opening a view of that object.

Moving into Phase II

At the beginning of 2002, when a substantial amount of the Phase I development had been completed but before it went live, the DSFA started to plan Phase II, to replace the current systems for administering the state pension schemes. This will use the Expressive Object Architecture built for Phase I, but is considerably larger in both scale and scope.

At the very beginning of the original project in 1999, Richard Pawson advised the DSFA that re-use should not be treated as an objective. He recommended that the objective should be agility: strategic business agility, operational business agility, and agility in the development process. If these goals were pursued, and the object modelling was done well, then re-use would be a positive side effect. And so it proved. The preliminary object modelling for Phase II, conducted early in 2002, has shown levels of re-use from Phase I that have startled even the most passionate of the object-modellers. The message: re-use is a good result, and a poor objective.