ThesisPDF Available

Naked Objects

Authors:

Abstract and Figures

The original concept of object-oriented software development was that the objects would be ‘behaviouslly-complete’ representations of the domain entities that they model. Although object-oriented technologies now pervade the realm of business systems development, business applications typically fall far short of this ideal of behaviourally-complete objects. Instead, business system designs continue to separate data and procedure, even if both constructs are implemented using object technology. This separation increases the effort involved in modifying the system to accommodate subsequent changes in requirements. This thesis argues that the continued separation of procedure and data is encouraged by established architectural approaches. In the generic four-layer architecture, for example, there is almost always an explicit ‘task’ or ‘application’ layer that is procedural in nature. In the Model-View-Controller (MVC) pattern, the Controller objects are often implemented as ‘use-case controllers’ even though that was not their original intent. A new approach is needed that offers the flexibility brought by those established architectural patterns, but without encouraging the separation of procedure and data. The proposed new approach is called ‘naked objects’: behaviourally-complete entity objects that are exposed directly and automatically to the user - such that all user tasks are fulfilled explicitly by invoking methods of those entity objects. Using a suitable software framework (two of which are described in the thesis) the naked objects approach delivers four principal benefits. Two relate to the developed product: improved agility (meaning the ease with which unforeseen changes to business requirements can be accommodated) and a more empowering style of user interface. The other two principal benefits relate to the development process: a faster development cycle and a common language between developers and users during requirements analysis.
Content may be subject to copyright.
Naked objects
A thesis submitted to the
University of Dublin, Trinity College
for the degree of
Doctor of Philosophy
Richard Pawson,
Department of Computer Science,
Trinity College,
Dublin
October 2003
1
Declaration
I, the undersigned, declare that this work has not been previously submitted as an
exercise for a degree at this or any other University, and that, unless otherwise stated, it
is entirely my own work.
___________________
Richard Pawson
October 2003
2
Permission to lend or copy
I, the undersigned, agree that Trinity College Library may lend or copy this thesis upon
request.
___________________
Richard Pawson
October 2003
3
Abstract
The original concept of object-oriented software development was that the objects would
be ‘behaviouslly-complete’ representations of the domain entities that they model.
Although object-oriented technologies now pervade the realm of business systems
development, business applications typically fall far short of this ideal of behaviourally-
complete objects. Instead, business system designs continue to separate data and
procedure, even if both constructs are implemented using object technology. This
separation increases the effort involved in modifying the system to accommodate
subsequent changes in requirements.
This thesis argues that the continued separation of procedure and data is encouraged by
established architectural approaches. In the generic four-layer architecture, for example,
there is almost always an explicit ‘task’ or ‘application’ layer that is procedural in nature.
In the Model-View-Controller (MVC) pattern, the Controller objects are often
implemented as ‘use-case controllers’ even though that was not their original intent. A
new approach is needed that offers the flexibility brought by those established
architectural patterns, but without encouraging the separation of procedure and data.
The proposed new approach is called ‘naked objects’: behaviourally-complete entity
objects that are exposed directly and automatically to the user - such that all user tasks
are fulfilled explicitly by invoking methods of those entity objects. Using a suitable
software framework (two of which are described in the thesis) the naked objects
approach delivers four principal benefits. Two relate to the developed product:
improved agility (meaning the ease with which unforeseen changes to business
requirements can be accommodated) and a more empowering style of user interface. The
other two principal benefits relate to the development process: a faster development
cycle and a common language between developers and users during requirements
analysis.
4
Acknowledgements
The author would like to thank the following for their help in connection with this thesis:
The management team at the Department of Social and Family Affairs, for their
willingness to be the first organisation to attempt to build a real business system using
the naked objects approach, and for providing unlimited access to evaluate the results.
The Java Services team at Safeway, again for their willingness to experiment with a new
approach, and for providing invaluable feedback that resulted in refinements to the
approach
Robert Matthews, who as the developer of the Naked Objects framework, provided an
opportunity to explore many detailed implications of the naked objects concept using a
purpose-designed tool.
Dan Haywood for undertaking all the programming associated with the CarServ case
study.
My thesis supervisor, Vincent Wade, and Simon Dobson for his additional input.
My family for their encouragement and support throughout this project.
5
CHAPTER 1INTRODUCTION....................................................................................... 9
1.1Motivation....................................................................................................................... 9
1.2Objectives......................................................................................................................10
1.3Contribution.................................................................................................................. 11
1.4Technical approach....................................................................................................... 12
CHAPTER 2THE EVOLUTION OF OBJECT-ORIENTED DESIGN.....................16
CHAPTER 3INTRODUCING NAKED OBJECTS..................................................... 26
3.1Frameworks to support naked objects.......................................................................... 27
3.2Some immediate issues................................................................................................. 29
3.3Proposed benefits for naked objects............................................................................. 37
CHAPTER 4DEVELOPMENT OF A NEW BENEFITS PROCESSING SYSTEM
FOR THE IRISH GOVERNMENT...............................................................................39
4.1Background to case study............................................................................................. 39
4.2Early experimentation ................................................................................................40
4.3Applying the concept to Child Benefit Administration .............................................44
4.4Technology demonstrators .........................................................................................44
4.5Phase I implementation .............................................................................................. 46
4.6Phase II..........................................................................................................................49
4.7Evaluation..................................................................................................................... 50
4.8Conclusions from this case study..................................................................................60
CHAPTER 5GUIDELINES FOR DESIGNING NAKED OBJECT SYSTEMS...... 62
5.1Look for projects with characteristics that will benefit most from using naked objects..
64
5.2The pre-requisites for starting a naked objects project are: good OO modelling skills,
a suitable software framework, and a common understanding of the intent..................... 67
5.3Structure the project in two distinct phases: exploration and delivery........................ 68
5.4During exploration, identify objects and their responsibilities directly, not from use-
cases................................................................................................................................... 69
5.5During exploration, capture the object definitions directly into working code............71
5.6Develop the production system one scenario at a time.................................................78
5.7During the delivery phase capture each scenario as executable user acceptance tests....
79
CHAPTER 6TESTING THE APPLICATION OF THE GUIDELINES AT
SAFEWAY........................................................................................................................83
6
6.1Background................................................................................................................... 83
6.2Opportunity................................................................................................................... 84
6.3Exploration phase..........................................................................................................85
6.4The second project........................................................................................................ 87
6.5Evaluation..................................................................................................................... 88
CHAPTER 7CARSERV - A COMPARATIVE IMPLEMENTATION....................94
7.1Description of CarServ1............................................................................................... 94
7.2Defining a comparative implementation.......................................................................96
7.3Description of CarServ2............................................................................................... 97
7.4Evaluating the development effort for the two implementations................................. 98
7.5Some caveats...............................................................................................................100
7.6Testing for agility........................................................................................................101
7.7Conclusions from this case study................................................................................102
CHAPTER 8RELATED WORK..................................................................................103
8.1Object-oriented user interfaces...................................................................................103
8.2Existing techniques for exposing domain objects to the user.....................................106
8.3Empowering user interfaces........................................................................................108
8.4Agile methodologies................................................................................................... 112
CHAPTER 9 CONCLUSIONS.....................................................................................121
9.1Review against the original objectives ...................................................................... 121
9.2Contribution................................................................................................................ 126
9.3Further research.......................................................................................................... 128
CHAPTER 10BIBLIOGRAPHY................................................................................. 131
10.1A componentised software infrastructure that supports distributed software
components, with object-style interfaces based on published standards. .......................142
10.2A strong commitment to the concept of object orientation...................................... 142
10.3Defining principles for the Naked Object Architecture ...........................................143
10.4Customer Object....................................................................................................... 146
10.5Scheme Object.......................................................................................................... 148
10.6Communication Object............................................................................................. 150
10.7Officer Object........................................................................................................... 151
10.8Payment Object......................................................................................................... 152
10.9Case Object .............................................................................................................. 154
10.10Description.............................................................................................................. 155
7
10.11Questionnaire ........................................................................................................ 156
10.12Summary of responses............................................................................................ 158
10.13Charts and commentary.......................................................................................... 159
10.14Description.............................................................................................................. 169
10.15Questionnaire.......................................................................................................... 170
10.16Summary of responses............................................................................................ 171
10.17Charts...................................................................................................................... 171
10.18Description.............................................................................................................. 177
10.19Questionnaire.......................................................................................................... 178
10.20Summary of responses............................................................................................ 180
10.21Charts and commentary.......................................................................................... 181
10.22Description.............................................................................................................. 209
10.23Questionnaire.......................................................................................................... 210
10.24Summary of responses............................................................................................ 212
10.25Charts and commentary.......................................................................................... 213
10.26The Scenarios..........................................................................................................231
10.27Changes Required................................................................................................... 232
10.28Metrics.................................................................................................................... 236
10.29Timings................................................................................................................... 237
10.30Observations............................................................................................................238
8
CHAPTER 1 INTRODUCTION
1.1 Motivation
In February 2002 the Association of Computing Machinery (ACM) presented its annual
A.M. Turing award to Ole-Johan Dahl and Kristen Nygaard of Norway
‘for their role in the invention of object-oriented programming, the most widely
used programming model today. Their work has led to a fundamental change in
how software systems are designed and programmed, resulting in reusable,
reliable, scalable applications that have streamlined the process of writing
software code and facilitated software programming.’ [4]
The inventors of object-oriented programming conceived ‘objects’ as representations of
the entities that model a chosen domain, with each object encapsulating the state of that
entity (i.e. its attributes, including any relationships to other objects) together with the
behaviours associated with that entity [29]. In other words, objects were originally
conceived as being ‘behaviourally-complete’. That term is not meant to imply that an
object provides every conceivable behaviour that could be required of it in any context.
Rather, the term simply implies that within the context of a given application, all the
functionality associated with a given entity is encapsulated in that entity, rather than
being provided in the form of external functional procedures that act upon the entities.
Today, however, most object-oriented designs, and especially object-oriented designs for
business systems, do not match this ideal of behavioural-completeness. Whether by
deliberate design or not, the objects representing the business entities (such as Customer,
Product, and Order) are often behaviourally-weak [96]. They typically have methods for
updating the object’s attributes and relationships to other objects; possibly they have
methods for implementing constraints on those attributes or relationships; and perhaps
they have methods for implementing a few simple processing functions on the object.
However, much of the business functionality required for the application is typically
implemented in procedures or ‘controllers’ that sit on top of these entity objects.
Firesmith describes this pattern as:
‘dumb entity objects controlled by a number of controller objects’ [39].
It can be seen in most custom-built object-oriented business applications, as well as in
publicly-available business object frameworks such as IBM’s San Francisco framework
[13].
9
The controllers or procedures may be written in a conventional programming language,
or in a high-level scripting language that supports workflow or business process
modelling, or in an object-oriented programming language. The procedures may even be
first-class objects in their own right (i.e. it is possible to hold a reference to one in a
variable). But this does not disguise the fact that in essence the data has been separated
from the behaviour.
Firesmith suggests that this separation of procedure and data in object-oriented designs
results in
‘excessive coupling, and an inadequate distribution of the intelligence
of the application between the classes’ [39].
Excessive coupling tends to hamper the ‘agility of a system - that is, the ease with
which the system can be modified to accommodate unforeseen future changes to the
requirements. This assertion is difficult to validate empirically because there is seldom a
chance to develop the same business system using more than one approach. However,
two documented attempts at such controlled experiments ([103] and [32]) both indicate
that where the core business entities are more behaviourally-complete there is less
coupling between the objects, and in consequence the systems are easier to extend or
modify.
The question then arises: if there are known benefits to aiming for behavioural-
completeness in object designs, why is it not widely practiced? Are there other factors
that tend to encourage the separation of procedure data at the design stage, and, if so,
could they be overcome? These questions led to the research described in this thesis.
1.2 Objectives
The objectives for this research were set as follows:
1. To identify factors that cause, or reinforce, the tendency to separate procedure
and data in the design of systems, even where those systems are intended to use
object-oriented approaches.
2. To identify and specify an approach to the design of object-oriented business
systems that would help overcome those factors.
10
3. To evaluate the use of this approach for the design of real business systems, and
thereby to test its effectiveness in achieving the goal of behaviourally-complete
objects.
4. To test whether the use of this approach does ultimately lead to more agile
systems, and whether there are any other advantages to be gained from it, as well
as any disadvantages or limitations.
5. To identify types of business system, or types of project, that would potentially
benefit most from applying this approach.
1.3 Contribution
The contribution of this research is the development of the ‘naked objects’ approach to
designing business systems, and the demonstration that the adoption of this approach
yields significant benefits both to the developed system and to the development process.
Using the naked objects approach to designing a business system, the domain objects
(such as Customer, Product and Order) are exposed explicitly, and automatically, to the
user, such that all user actions consist of viewing objects, and invoking behaviours that
are encapsulated in those objects. It has been demonstrated that this approach yields four
benefits:
The resulting systems are more agile, meaning that they can more easily be
modified to accommodate unforeseen future business requirements. This is
primarily because the naked objects are forced to be behaviourally-complete.
The resulting systems provide the user with a more empowering style of
interaction.
The development cycle is significantly shortened, because the presentation layer
is generated automatically from the domain object definitions, and because the
overall design is simplified.
The naked objects provide a common language between application developers
and users, which facilitates the early stages of requirements gathering and
domain modelling.
This work has led directly to the creation of two independent frameworks to support the
naked objects approach: the proprietary Naked Object Architecture (commissioned by a
department of the Irish government) and the open-source Naked Objects framework.
11
Controlled experiments and real business case studies have shown that with the aid of
such a framework, all of the benefits listed above can be realised. The emergence of a
substantial development community around the Naked Objects framework is further
evidence of the genericity of the approach.
1.4 Technical approach
The research comprised six main phases:
Researching the factors that tend to encourage the separation of procedure and
data even in object-oriented designs.
Designing a new approach to overcome this tendency.
Testing the approach through controlled experiments and real business case
studies, evaluating the results of each.
Identifying the potential benefits and/or limitations of this approach.
Performing a comparative analysis with other approaches that may have
overlapping objectives or characteristics.
Drawing conclusions.
1.4.1 Researching the factors that tend to encourage the separation of
procedure and data even in object-oriented designs
This was primarily achieved by searching and analysing the existing literature on object-
oriented techniques, their advantages and problems. Particular attention was paid to the
origins of the object-oriented concept, how the thinking evolved over time, and how the
idea was combined with other areas of work.
This research, which is presented in 2, suggests that one of the major factors tending to
encourage the separation of data and procedure is the ‘use-case controller’ [41], which is
effectively a functional procedure. The use-case controller is inherent in the ‘4-layer
architecture’ which has become the dominant design for contemporary business systems
development, and is directly encouraged by many object methodologies including the
Unified Process [57]. There is also evidence (e.g. [98]) to suggest that the use-case
controller pattern is often an accidental by-product of the widely adopted Model-View-
12
Controller (MVC) pattern [66] - even though that was not the intent behind the
invention of MVC [92].
1.4.2 Designing a new approach to overcome this tendency
The new approach, described in 3, is to specify an application solely in terms of the
Model (i.e. the domain entity) objects. These Model objects are then rendered directly
visible to the user by means of a generic presentation layer, which embodies the View
and Controller roles from MVC. The user undertakes all tasks by directly invoking
methods on those Model (entity) objects. This approach has been dubbed ‘naked
objects’, because as far as the user is concerned he or she is viewing and manipulating
the ‘naked’ business domain objects.
This new approach is intended to facilitate the design of behaviourally-complete objects
(and thereby gaining the benefit of improved agility). In addition, three other benefits
accruing from the use of naked objects are predicted.
Improved usability - because the system automatically has a truly object-
oriented user interface.
A faster development cycle - because the developers do not have to write their
own Views, Controllers or anything to do with the presentation layer.
Improved communication between developers and users during requirements
analysis, because the naked objects provide a common language.
1.4.3 Testing the approach through controlled experiments and real
business case studies, evaluating the results of each
A timely opportunity arose to test the application of naked objects at the Irish
Department of Social and Familiar Affairs (DSFA). At the start of 1999, the DSFA was
beginning to think about the design of a new business architecture that would eventually
replace all of its current core systems, and was attracted to the claims (at that stage
hypothetical) made for naked objects. 4 tells the story of the early exploratory work,
leading to the development of a brand new Naked Object Architecture. The first
application to be built on top of this architecture - a replacement for the existing Child
Benefit Administration system - went live in November 2002, and work is under way
for a second and larger application to handle the administration of state pensions.
Evaluation of the case study, which included formal interviews with IT managers,
13
business managers and user, was conducted in February 2003. The results of the
evaluation provide strong evidence for two of the four benefits predicted in 3, and some
support for a third.
7 describes a controlled experiment to implement a simple business application using
two different approaches: one was a conventional 4-layer approach, the other used naked
objects. Formal metrics were used to compare the two resulting systems. The metrics
show that the system built using naked objects required significantly less development
effort, and had a simpler design. The two implementations were then subjected to a
series of business change scenarios. The amount of effort required to modify each
system was recorded, and the results validate the prediction that naked objects would
improve the agility of the resulting system.
1.4.4 Identifying the potential benefits and/or limitations of this approach
Having confirmed, through the experiments and case studies, that the benefits proposed
for naked objects could be realized in practice, the next task was to identify its possible
liabilities or limitations. The combination of benefits and liabilities was used to generate
further guidelines on where and how best to deploy the naked objects approach. The
findings from this exercise are presented in 5.
6 describes two short projects undertaken at Safeway Stores (the fourth largest
supermarket chain in the UK), where these guidelines were explicitly applied. The
evaluation shows that that both developers and users involved in these two projects felt
that adopting naked objects together with the guidelines for their use provided an
effective and appealing approach to developing business systems. The evaluation also
confirms the predicted benefits concerning speed of development and communication
between developers and users.
1.4.5 Performing a comparative analysis with other approaches that may
have overlapping objectives or characteristics
8 discusses related work including object-oriented user interfaces, other techniques for
surfacing objects to the user automatically, approaches to designing empowering user
interfaces, and agile development methodologies (or approaches).
14
1.4.6 Drawing conclusions
In 9 the research is reviewed against the original objectives (as set out above). This is
followed by an analysis of the contribution of the research, including its genericity. The
chapter concludes with a statement of possible directions for further research in this area.
15
CHAPTER 2 THE EVOLUTION OF OBJECT-ORIENTED
DESIGN
The first research objective was to identify the principal reasons why the design of
modern business systems continues to separate data and procedure even where there is an
intent to use object-oriented principles and techniques. The approach taken was
essentially historical: examining the evolution of object-oriented design concepts and
their application to business systems design. That evolution, presented in this chapter,
reveals a number of key developments, which, it is argued, have tended to reinforce the
continued practice of separating data and procedure.
Simula and the birth of object-orientation
The idea of object-oriented software originated in Norway in the mid 1960s with Simula,
an extension to the Algol programming language. Simula was designed to make it easier
to write programs that simulated real-world phenomena such as industrial processes,
engineering problems, and disease epidemics [29].
Prior programming languages and techniques explicitly separated software into
procedure and data. The assumption underlying this separation was that a computer
system repeatedly applies the same procedure to different data. Simulation software
challenges that assumption. Sometimes the data is fixed and the programmer manipulates
the functional characteristics of the system until the output meets the required criteria.
For example, the data might represent the roughness of a typical road and the
programmer might alter the design of a simulated truck suspension system until the
desired quality of ride is achieved. Sometimes it is difficult to tell data and functionality
apart. When another axle is added to a simulated truck, for example, does that constitute
changing the data (the number of wheels) or the functionality (the way in which the truck
translates road bumps into ride quality)?
The inventors of Simula had the idea of building systems out of ‘objects’. Each software
object not only knows the properties or attributes of the real-world entity that it
represents, but also knows how to model the behaviour of that entity. Thus each Wheel
object not only knows the dimensions and mass of a wheel, but also knows how to turn,
to bounce, to model friction, and to pass forces on to the Axle object. These behaviours
may operate continuously, or they may be specifically invoked when needed by sending a
message to the object.
16
In the original work, each object was seen as being self-contained [29] - the attributes
of an object were encapsulated with all the necessary behaviours. Another way of
phrasing this is that objects should be ‘behaviourally-complete’. This phrase is not meant
to imply that the object provides every behaviour that might possibly be needed for all
current and future applications. It simply means that all the behaviours associated with an
object that are necessary to the application being developed are encapsulated in that
object and not implemented somewhere else in the system.
The value of behavioural-completeness is that any required changes to the application
map simply onto changes in the program code. For example, adding a valve between two
pipes in a Simula model of an oil refinery simply involves creating a new instance of the
Valve class, setting its operating parameters, then linking it to the appropriate Pipe
objects. The new Valve object brings with it the ability to be opened and closed, altering
the flow of oil appropriately, as well as to model the impact on construction costs. If the
same refinery were modelled using a conventional ‘procedural’ programming, the
behaviours impacted by the new valve would likely be distributed around the program
and therefore harder to find and change.
Smalltalk and the object-oriented user interface
Although the Norwegian work continued (and the ‘Scandinavian school’ of OO is still
sometimes distinguished [71]), by the early 1970s a new stream of object-oriented
thinking was emerging from Xerox’s new Palo Alto Research Center (Parc). Alan Kay,
who led the Learning Research Group at Parc, was attracted to object-orientation for
several reasons.
The first had to do with scalability. At that time, discussions about software scalability
were usually concerned with scaling up by one or two orders of complexity. But in 1965,
Gordon Moore, who later co-founded Intel, stated that the number of transistors on an
integrated circuit would continue to double every year for at least 10 years [75]. The
actual trend has been closer to doubling every two years, but it has continued unabated to
the present day. Kay was one of the few researchers to take the implications of the
newly-coined ‘Moore’s Law’ seriously. He was interested in how software complexity
could scale up, not by one or two orders of magnitude, but by a factor of a billion or
more, to take advantage of an equivalent scaling up of hardware. Kay’s conception of the
future of computing - notebook-sized computers with wireless connections into a gigantic
network of information - looked like science fiction in the early 1970s.
17
Drawing an analogy from microbiology, Kay argued that software could only scale up in
complexity by a factor of a billion if it was self-similar at all scales: if the most
elementary software building blocks were, in effect, complete virtual machines [63] - in
other words, ‘objects’.
Kay also saw that the concept of objects had potential as a cognitive tool: they
correspond well to the way people think about the world [62]. He noted that a verb can
be thought of as a property of a noun: in the phrases ‘the boy runs’, ‘the dog runs’, ‘the
water runs’, and ‘the trains run’, the meaning of ‘run’ is derived from the noun in the
phrase. This gave rise to the object-oriented principle known as ‘polymorphism’: the
same command (verb) can be issued to different objects, but it is up to the object to apply
meaning to that verb and behave accordingly.
One product of this way of thinking was Smalltalk [63], which, as well as providing a
pure object-oriented programming language, was also very innovative in its support for
the user interface. (Simula had not by that stage provided any significant support for an
interactive user-interface - output was usually to a line printer.) Graphical user
interfaces (GUIs) were not a new idea: Ivan Sutherland had demonstrated many of the
key ideas in both graphical output and direct-manipulation input with his Sketchpad
system in 1963 [113] but his ideas were not easy to generalize into other applications,
and also relied on specialized (vector graphic) hardware for the displays. By the early
1970s the falling cost of processing power made it possible to create similar effects in
software using bit-mapped displays. Smalltalk married these capabilities with an object-
oriented programming language, to powerful effect, and eventually established most of
the elements of what is now the ‘dominant design’ [117] in interactive GUIs:
overlapping windows, icons, and a desktop metaphor.
A defining principle of the early versions of Smalltalk (that is, up to and including
Smalltalk-76) was that
‘all objects are active, ready to perform in full capacity at any time. Nothing of
this liveness should be lost at the interface to the human user . . . all the
components of the system should be able to present themselves to the user in an
effective way’. [53]
In other words, objects were able to represent themselves directly to the user.
Although the Simula and Smalltalk languages had many differences, one thing they had
in common was that in most cases the user was also the programmer. The user of a
simulation written in Simula was likely to be the engineer who wrote it. In the early days
18
of Smalltalk the intended user/programmers were children [53]. Indeed, the idea that all
users should be programmers has continued to be axiomatic for Kay and subsequently
led to the development of the Squeak language [54], an attempt by Kay and several of
his ex-Parc colleagues to get back to that original vision.
However, by the late 1970s Smalltalk was becoming a general-purpose programming
language with potential applicability to business as well as education and science. This
had two far-reaching implications. The first was that the users would not typically be
programmers. The second was that there would need to be a way for individual business
objects to be viewed in multiple ways, either as different visual representations (such as a
graph or a table), or in different business contexts, requiring different attributes to be
shown or hidden.
The emergence of the Model-View-Controller pattern
This line of thinking lead to the invention of the Model-View-Controller (MVC) pattern
by Trygve Reenskaug in the late 1970s (the earliest source available is [92] but MVC
was not publicly documented until 1988 [66]). The motivation for this change is
summarized by Reenskaug:
‘One of the great inventions of the Smalltalk group at Xerox Palo Alto Research
Center (PARC) in the seventies was the idea that objects can be made visible on
the computer screen so that the user can see and manipulate them directly. This
makes the abstract computer data appear concrete and the underlying object
model visible. The user can easily adjust his mental model to this computer
model and operate on it with confidence. The well-designed direct manipulation
object interface is intuitively obvious and therefore easy to learn for the
uninitiated. This strength of the direct manipulation object model is also its
main weakness. Each object can only appear once on the screen and must
always be presented in the same way to preserve the illusion of concreteness.
This is insufficient for large and complex models where we need to view objects
in different ways.’ [93]
Under the MVC pattern, object classes are characterized into three distinct archetypes
(see figure 2.1):
Model objects model the entities of the application domain including both their
state and behaviour.
19
View objects create a user representation of Model objects, and handle all the
interfacing with the display device. Each View represents a single Model object,
but one Model can have multiple Views.
Controller objects handle user input on a given View. They interface with the
input device, and update the associated Model and View objects as needed.
Figure 2.1: The Model-View-Controller pattern (reproduced from [66])
The principal intent of the MVC pattern is the separation of concerns. If the business
demands a new view of a particular (Model) object, or if the whole application needs to
be ported to a new user platform, this requires changes only to the View and Controller
objects - the Model object need not be touched.
MVC is now characterized as an architectural pattern [19], meaning that it informs the
whole approach to the design of the system, not just some particular feature. Moreover,
this pattern, or some variant of it, has now become pervasive in new business systems
that involve user interaction, to the point that it is rarely criticized or questioned.
Shortcomings of MVC
But MVC does have some known shortcomings and problems. From the outset there was
a tension between the advantages of MVC and the advantages of the previous paradigm
where objects were exposed directly. Reenskaug wrote many years later that:
‘The Model-View-Controller paradigm extends the power of the user interface
at the expense of increased demands on the user’s mental model.’[93]
20
In the Portland Pattern Repository he is quoted1 as saying that:
‘MVC was an outgrowth of the original direct-manipulation metaphor
popularized in early OO practice (see Brenda Laurel’s Computers As Theatre
[69]), where you want the objects on the screen to be the objects in the
program. MVC actually works against that metaphor but evolved as a
necessary evil. Why? Because the user object maintains multiple simultaneous
views of the model at once; the factoring into user, model, view, and controller
allows one to support that.’ [94]
Alan Kay has recently further suggested that:
‘One of the original motivations for the models, views and controller idea (that,
in my opinion, never got well done) was to be able to automatically produce a
default graphical interface for any object (and Steve Putz at PARC actually did
a version of this but it didn’t stick).' [64]
It has also subsequently been suggested that MVC challenges the principle of
encapsulation (i.e. ‘behavioural-completeness’). Holub, for example, states that:
‘MVC is okay for implementing little things like buttons, but it fails as an
application-level architecture. This extract-data-then-shove-it-elsewhere
approach requires you to know too much about how the model-level objects are
implemented. A system based on that approach cannot be called object-
oriented: there’s too much data flowing around for the system to be
maintainable.’ [49]
Buschmann et al suggest that this in turn leads to:
‘close coupling of views and controllers to a model. Both view and controller
components make direct calls to the model. This implies that changes to the
model’s interface are likely to break the code for both view and controller.
This problem is magnified if the system uses a multitude of views and
controllers.’ [19]
MVC thus encourages the extraction of certain behaviours of an entity object (i.e. those
concerned with representing itself to the user) and placing them in separate structures.
This is deliberate, and is based on the argument that the advantages outweigh the
disadvantages. But in subtle ways, the MVC pattern encourages the extraction of other
1 The (unknown) contributor to the repository is reporting an informal conversation with Reenskaug the
quotation should not be taken as completely reliable.
21
behaviours from the entity (Model) objects. It is very tempting to build small amounts of
business logic into the Views, for example to calculate the running total of an invoice
being built up on screen.
The Use-Case controller pattern
This can be even more pronounced in the case of the Controllers. Controllers were
originally defined (see above) as being concerned solely with managing input. However,
this definition has been progressively distorted over the years so that the term Controller
is now commonly defined as ‘governing the flow of control associated with a complete
user task’ [1]. For example, Rumbaugh (writing in 1994 about the use of MVC) stated
that:
‘the state diagram of a controller defines the allowable sequences of
interactions inherent in a use case ... Start by assuming one controller per use
case...’ [98].
Fowler defines the ‘use-case controller’ as an explicit pattern. He positions it closer to
the ‘Transaction Script’ pattern used in a conventional procedural programming
environment, than to the ‘Domain Model’ pattern (which is more compatible with the
goal of behavioural-completeness) [41].
The use-case controller pattern is effectively adopted by the Unified Process (UP),
wherein business objects are designed according to three archetypes: Entity, Boundary
and Control - the ‘EBC’ pattern [57]. Although EBC superficially resembles MVC
there is an important distinction. In EBC, the Boundary objects are responsible for all
aspects of interfacing (i.e. both input and output), to the user and to other systems; they
therefore combine the View and Controller roles from MVC. In EBC, Control objects sit
in between the Boundary and Entity objects and control the flow of events. They are
often
‘used to encapsulate control related to a specific use-case.’ [57]
In recent years new technologies have appeared specifically to support the
implementation of such controllers. These include workflow engines and business
process modelling languages2. It has been argued that in addition to the benefits
described above, these new technologies also make the resulting systems more agile,
because the business process or task representations are directly editable [109].
However, this claim assumes that the principal requirement of agility is the ability to
2 See, for example, www.bpmi.org
22
change the order in which tasks are fulfilled, or the flow of work between individuals.
Arguably this is only one of many forms of change that business systems may be required
to support. Sheth et al argue that:
‘the ability to respond effectively to changes is a critical challenge for workflow
management systems. . . today’s workflow management systems have problems
dealing with various kinds of change, ranging from ad hoc modification for an
individual customer to evolutionary changes as a result of Business Process Re-
engineering efforts …. and are too rigid to handle [these] dynamics.’ [104]
The four-layer generic architecture
Although not all new business systems designs explicitly adopt the MVC and use-case
controller patterns, most of them do so implicitly in the form of the generic four-layer
architectural pattern shown in Figure 2.2. This 4-layer pattern was first recorded by
Brown in 1995 [17] although he indicates that it had clearly been practiced for some
time before that. In the diagram the four layers are labelled presentation, controller,
domain object, and data management. In a given implementation the names of the layers
may differ, and the four principal layers may be subdivided into further layers, but the
basic concept has become the dominant design for client-server business systems.
23
Figure 2.2: The architectural pattern adopted by most business systems
is based on four generic layers.
In this four-layer pattern, a single business concept (such as a Customer) will usually be
represented in all four layers, in different forms. Moreover, as the diagram indicates, the
relationships between the elements in those four layers often require a complex, many-to-
many mapping. Although this generic architectural pattern has evolved over the years to
meet certain needs, and although each of the layers may be object-oriented in some
sense, this is a far cry from the original principle of behaviourally-complete objects.
Conclusion
The conclusion is that the biggest single factor promoting the continued separation of
procedure and data in object-oriented business systems design is the use-case controller
pattern. Moreover the use of the use-case controller pattern seems to be almost
inevitable where the MVC pattern has been adopted - even though the latter was
conceived for quite different reasons.
Prior to the proposal of the MVC pattern, objects were seen as having the responsibility
to display themselves. This simpler architectural model did not encourage the separation
of data and procedure. However, it had limitations in terms of the flexibility of the user
24
interface, and there is no evidence that this earlier approach was ever tried in the context
of designing core transactional business systems.
The challenge that this research presents is to find a technique that will combine the
simplicity of the original objects-display-themselves approach with the flexibility offered
by MVC, but in such a way that is does not encourage the insertion of use-case
controllers between the domain model and the user interface.
25
CHAPTER 3 INTRODUCING NAKED OBJECTS
The solution to the dilemma posed at the end of the previous chapter is to make the View
and Controller roles (as originally defined in MVC) completely generic. In such an
approach a business application is written solely in terms of the domain entity (i.e.
Model) objects. The presentation layer, which permits the user to view those objects and
to invoke behaviours on them, would be provided automatically. The author has dubbed
this concept ‘naked objects’, because as far as the user is concerned he or she is viewing
and manipulating the ‘naked’ business domain objects.
These business objects actually reside in a domain object layer of the architecture, which
is often implemented on a shared server platform. Thus the user does not strictly view
and interact with the business objects, but rather with Views and/or Controllers that
correspond to those objects and reside in a presentation layer. However, the concept of
naked objects implies an enforced correspondence between the two layers, so the illusion
of manipulating the business objects is total. See Figure 3-3.1.
Figure 3-3.1 With naked objects the domain objects are rendered visible to the user by means of a
completely generic presentation layer or ‘viewing mechanism’. All required business functionality
must therefore be encapsulated on the domain objects.
26
The idea of auto-generating a user interface from an underlying business model
definition is not new [90]. Established examples include several fourth-generation
languages; emerging examples include the W3C Xforms standards for the web-services
architecture [35] and the idea of a device-independent User Interface Mark-up Language
[88]. However, all these technologies are strongly data-oriented rather than object-
oriented, and their motivation has principally to do with reducing the effort associated
with developing and maintaining the user interface rather than with improving the object
modelling.
With naked objects, the resulting user interface is strongly object-oriented. The idea of
object-oriented user interfaces (OOUIs) is well established and the relationship of naked
objects to existing work on OOUIs will be addressed in 8. However, in none of the
existing work on OOUIs is there a suggestion that the objects seen and manipulated by
the user must correspond exactly to the domain objects in the underlying system.
How do naked objects encourage the design of behaviourally-complete entity objects? In
a system designed using naked objects, the only way that the user can initiate action is by
invoking a behaviour on a business object. A simple way to envisage this is to have the
objects represented to the user as icons, and the behaviours made available as options on
a pop-up menu for that icon. (This is by no means the only possible means of
implementing the concept - others will be described later). It follows that the system
designer must encapsulate all behaviours required of the application with the entity
objects.
In other words, the first way that naked objects encourage behavioural-completeness is
essentially negative: there is nowhere to put behaviour except on the entity objects.
There is also a positive way in which naked objects encourage behavioural-
completeness: envisioning domain objects as being manipulated directly by users should
make it easier to identify the behaviours each one needs.
3.1 Frameworks to support naked objects
Building systems using naked objects implies some sort of software framework.
(‘Framework’ is used here in the sense defined by Deutsch i.e. a set of classes that forms
a skeleton around which an application is constructed [33]). In this case the framework
must provide, at minimum, two capabilities. The first capability is an implementation of
the generic presentation layer (i.e. a set of classes that fulfil the roles of View and
Controller in an MVC architecture). The second is some mechanism whereby that
27
generic presentation layer identifies the domain objects and their behaviours, in order to
render them available to the user.
Two examples of such frameworks have emerged during the course of this research, the
Naked Object Architecture and the Naked Objects framework, both explicitly designed to
support the concept of naked objects. Both were inspired directly by the author’s work,
and in both cases the author played a key advisory role in their design, though not in their
implementation. The author has used both frameworks to conduct experiments, and to
design and implement real business systems, some of which are described in subsequent
chapters.
The Naked Object Architecture
The Naked Object Architecture was commissioned by the Department of Social and
Family Affairs (DSFA) in Ireland. (The Naked Object Architecture was previously
known as the Expressive Object Architecture, reflecting the author’s own terminology
[84] prior to 2001 when the term ‘naked objects’ was coined. The DSFA officially
renamed its architecture in June 2003.) The background to the creation of this
architecture, and the experience of building the new Child Benefit Administration system
on top of it, are described in 4.
The Naked Objects framework
The Naked Objects framework is an open source project started by Robert Matthews3 It
was written in Java, and uses Java’s reflection capability (known in some languages as
‘introspection’) to allow the generic viewing mechanism to identify the behaviours of
any object.
Naked Objects is a set of Java classes that can be instantiated or sub-classed by an
application. It is not a development environment. It can be used with any development
environment that supports Java - ranging from a minimal text-editor and Java compiler,
through to a sophisticated Integrated Development Environment (IDE) that supports
graphical modelling, code analysis and support for design patterns. The systems
described in 6 and 7 were creating using the Naked Objects framework: the former using
the IBM VisualAge IDE and the latter with the Togethersoft Control Center IDE.
In addition to using reflection to generate the user presentation, the Naked Objects
framework also uses reflection to render the objects persistent through one of several
3 The framework is hosted on www.nakedobjects.org (which was co-founded by Matthews with the author).
28
possible ‘object stores’, including a relational database. However, this capability is not
definitional to the concept of naked objects, and is not present in the DSFA’s Naked
Object Architecture.
Naked Objects has subsequently been ported onto Microsoft technology, allowing the
business objects to be written in the C# or VB.Net programming languages if so desired
(though all the examples described in this thesis were written in Java).
A brief description of the framework is provided in 10.21.22. For a more complete
description see [86]4.
The framework was featured in the ‘Intriguing Technologies’ track of OOPSLA 2001
[85] 5, in IEEE Software magazine [82] and many online forums. The screenshots shown
in the remainder of this chapter are all from systems built using the Naked Objects
framework.
3.2 Some immediate issues
Even before attempting to apply and evaluate the concept of naked objects, some
immediate issues arise:
How can the user create a new object instance, or perform other operations that
cannot naturally be associated with a single object instance?
How does the concept of a generic presentation layer permit alternative visual
representations of an object?
How is the concept of a generic presentation layer compatible with the
requirement to support multiple forms of user platform?
With no use-case controllers permitted, how can naked objects support the idea
of business process?
If core objects are exposed directly to the user, how is it possible to restrict the
attributes and behaviours that are available to a particular user, or in a particular
context?
How is it possible to invoke multiple parameter methods from the user interface?
4 This book can also be read online www.nakedobjects.org/contents.html
5 This paper is reproduced in
29
These are now addressed in turn.
How can the user create a new object, or perform other operations that cannot
naturally be associated with a single object?
Certain required user actions are not obviously associated with any particular object
instance. Examples include: creating a new instance, finding an existing instance, and
creating a list of instances that match some criteria. However, all of these actions can be
thought of as equivalent to class methods in object-oriented programming (known as
‘static’ methods in Java). Therefore, in addition to exposing individual object instances,
a naked object system should provide the user with a direct representation of the business
object classes, and through that representation also provide the user with access to
appropriate class methods. In Figure 3-3.2, the icons in the leftmost window represent
naked object classes (‘Bookings’ etc), while the other windows and the icons embedded
in them represent individual naked object instances. The pop-up menu for one of the
class icons (‘Cities’) reveals class methods to create a new City, find existing Cities and
so forth.
Figure 3-3.2 Class icons and instance icons
Similarly, it is possible to treat any collection of domain objects as an object in its own
right and therefore viewable and manipulable by the user (in the same way that
collections are treated in object-oriented programming languages.) In Figure 3.2 the icon
consisting of four red blobs represents a collection - in this case a collection of five City
objects.
30
How does the concept of a generic presentation layer permit alternative visual
representations of an object?
One of the motivations behind the Model View Controller pattern was to allow
alternative visual representations of the same object such as a table or a graph [66]. The
prevailing view is that this is a common need, though this view has occasionally been
challenged, for example, by Holub:
‘How often in your work has this problem actually come up? In talking about
object-oriented architectures for the user interface to many hundreds, if not
thousands, of programmers, only two or three have ever raised their hands
when I asked that question. If I need a generic presentation program that has
no notion of what the data means, I’ll buy a copy of Excel or Quattro Pro. I
won’t write a program. The fact is that data has meaning -- it’s not just an
arbitrary collection of numbers. For a given set of data, I would argue that
that there is only one "best" way to represent it for a specific problem domain.
If there’s no "best" way, then just settle on one "good" way. This degree of
flexibility is rarely required.’ [49]
It must, however, be accepted that there are circumstances in which the ability to
generate alternative visual representations is a real requirement. In these cases, how is it
possible to make alternative generic visual representations available to the user without
requiring either a programming intervention in the viewing mechanism or the
incorporation of user-interface-specific code into the domain model?
The solution is to make use of programming ‘interfaces’. For example, in the Java
programming language a class can only inherit functionality from one super class, but it
can implement any number of interfaces. Implementing an interface means that the
object can then be used in any context where that interface is specified, irrespective of
which super class the object inherits from.
Thus it is possible to define a specialized visual representation based on a particular
object interface. Any object that implements that defined interface is capable of being
rendered into that particular visual form, and the option to do so is automatically be
provided to the user.
31
Figure 3-3.3 Generic map view, from an energy trading application.
The screenshot shown in Figure 3-3.3 is taken from the energy trading application
(described more fully in [86]) in which the trading ‘positions’ are shown laid out as icons
on a map of Europe. Each icon represents an object and is fully functional - it can be
right-clicked to reveal a pop-up menu offering its behaviours, including the ability to
open up a separate view showing that object’s attributes and associations. To achieve
this a ‘Spatial’ interface was defined such that any collection of objects that each
implement the Spatial interface (which merely requires the object to provide getLattidude
() and getLongitude() methods) can optionally be displayed in their correct positions
against the background of a map.
Similarly, any collection of numerical value objects could optionally be displayed as a
graph, with that representation still providing full access to the functionality of each
object. Or any collection of objects that implements a ‘date’ and/or ‘periodOfTime’
interface could have the option to be displayed in a calendar representation.
32
How is the concept of a generic presentation layer compatible with the requirement
to support multiple forms of user platform?
Another motivation for the Model View Controller pattern was to facilitate the porting of
systems to different client platforms. Using MVC, such a port involves changing the
View and Controller objects, but not the Model objects.
The initial implementations of both the Naked Object Architecture and the Naked
Objects framework both assumed that the system was being accessed from a PC with a
high-resolution graphical display, and a mouse (or equivalent pointing device).
Moreover, in both cases the generic presentation layer or ‘viewing mechanism’ was
written in Java (though quite differently) and needed to be downloaded to the PC either
as a standalone application, or as a substantial ‘applet’ running within a browser.
Many organizations have adopted a policy that all new business applications should be
‘thin client’, which in most cases means that it must run within a browser and in some
cases means that it must run within native HTML, thereby ruling out even the use of Java
applets. Such a policy, it is argued, eliminates the need to maintain software on the
client side, and also facilitates operation over a wide area network. (The logic of these
arguments is not being defended here).
A further complication is that there is a growing desire to make business applications
accessible from a broad range of user platforms and devices, including Personal Digital
Assistants (PDAs), and third generation mobile phones.
In fact, naked objects makes it easier to address this problem, not harder. Given the idea
of a generic viewing mechanism that automatically reflects the underlying domain object
model, it is quite possible to envisage alternative generic viewing mechanisms, each
tailored to the capabilities of a particular viewing platform. Some of these platforms may
offer a much lower bandwidth of communication between the device and the user than
(say) a PC, both for output and for input. Drag-and-drop may not be feasible - for
example, on a hand-held device. However, to be consistent with naked objects, the user
interface does not need to make use of icons and direct manipulation. The user interface
need only preserves the notion that the user is dealing directly with the domain objects
and explicitly invoking behaviours on those objects. In other words, the style of
interaction is ‘object-action’ (or ‘noun-verb’) [91]. It is quite possible, for example, to
envisage each object as a web-page and with each behaviour as a hot button on that page.
33
With no use-case controllers permitted, how can a naked object system support the
idea of business process?
The definition of naked objects requires that all business functionality must be
encapsulated within entity objects rather than within use-case controllers (or other
broadly equivalent structures) that sit on top of those entities. It will be argued later on
that this approach provides the user with a more ‘expressive’ (or empowering) user
interface.
Nevertheless, there are situations where there is a real need for some kind of sequencing:
for example, to enforce adherence to a regulated business process (‘A customer must be
given a full written quotation two weeks before a contract becomes binding’) or a
fundamental piece of business logic (‘A booking cannot be confirmed until availability
has been checked’).
This is achieved using naked objects by distinguishing two broad categories or
stereotypes of entity object: ‘purposeful’ and ‘non-purposeful’. Some examples of non-
purposeful objects are Product, Customer, Employee, and Location. With non-purposeful
objects the state of the object is defined implicitly by the agglomeration of its various
attributes and associations. The state of these non-purposeful objects will change over
time, and that state will be made persistent, but the changes do not advance in any
particular direction. They can be thought of as random.
By contrast, the state of a purposeful object is usually defined explicitly, and is often
represented by a single field that can take one of a finite set of pre-determined values.
Moreover, this state generally changes in a pre-ordained direction; and this is typically
defined using state-transition diagrams, which specify the conditions under which the
object will move from one of those pre-determined states to another. Thus, an Order may
go from the state of an Enquiry, to Committed, to Shipped, to Invoiced. The status may
occasionally backtrack, or the Order may be terminated prematurely; but there is a clear
intended direction.
This concept of purposeful objects is broadly similar to the ‘moment-interval’ archetype
identified by Coad [22], (the non-purposeful objects corresponding usually to the
‘people, place or thing’ archetype) which could be used as an alternative, as could the
stereotypes defined by Wirfs-Brock [119].
It might be suggested that a purposeful object is just a use-case controller by another
name. There is, however, an important difference. In a naked objects system, both non-
purposeful and purposeful objects are entity objects. They are rendered explicitly to the
34
user as an object (for example as an icon). They are made persistent (at least by default).
They continue to exist as objects even when they have reached their intended end-state.
In most approaches to object modelling, once a transaction, process or use-case is
completed, there is no way of referring to it explicitly. In a naked object system, these
activities show up as objects in their own right: they can be viewed and inspected, and it
is possible to invoke any of their behaviours that remain valid given their status. Thus,
even after a (bank) Transfer has been made, the user could examine it, decide to reverse
it, charge a fee for it, or notify the customer of its successful completion - all methods
that can naturally be encapsulated in that Transfer object.
Any business activity where the verb describing the activity can easily be mutated into a
noun is a prime candidate for a purposeful object. Thus the users might have a
requirement to ‘adjust’ (verb) the prices. But they will also talk readily about ‘making
price adjustments’. This phraseology should be a cue for thinking about
PriceAdjustment as an instantiable entity object, rendered visible to the user (e.g. as an
icon).
The idea of treating a bank transfer as a persistent entity object rather than a transient
controller is not original (Riel, for example, makes the case for treating Transfers,
Withdrawals and Deposits in this manner [96]) but naked objects make the advantage of
this way of thinking clearer.
If core objects are exposed directly to the user, how is it possible to restrict the
attributes and behaviours that are available to a particular user, or in a particular
context?
Using naked objects, domain objects and their capabilities are exposed directly to the
user. But there are many circumstances where it is not desirable for all the attributes or
capabilities of an object to be available to the user. For example:
- A particular user’s role may not qualify them to view all data or invoke all actions on
an object.
- If an object is used in many contexts (for example a Customer object) it may acquire
a great many attributes and behaviours. Displaying them all would result in
unnecessary screen clutter, database accesses, or network transmission.
- Specific attributes or behaviours should be unavailable when the object is in certain
states. For example, it should not be possible to attempt to check the availability of a
booking until sufficient information has been provided. (This applies mostly to
35
‘purposeful’ objects as described in the previous point.) This requirement might be
summarized as the need for selective viewing of an object’s capabilities.
If the user interface is auto-generated from the definitions of the business objects, and no
programming intervention is permitted, it seems impossible to provide selective viewing
of an object’s capabilities. The solution is to provide some capability on the domain
object itself for controlling availability: of that whole class of objects, of specific
instances of that class, and of individual methods on that class. (Note that, assuming the
normal object-oriented practice is observed of keeping all variables private - accessible
only through ‘accessor’ and ‘mutator’ methods such as ‘get’ and ‘set’ - then control
over the availability of methods gives control over the access to attributes and
associations as well as to richer behaviours.)
In the Naked Objects framework this was achieved by permitting any method to have a
corresponding ‘about’ method. Thus the method actionConfirm() on a Booking object
could have a corresponding aboutActionConfirm() method which controls its availability.
This aboutActionConfirm() method might control availability based upon the state of the
Booking object, or it might delegate the decision to an authorization server that looks up
the authorization for the user. In one version of the viewing mechanism, unavailability is
signalled to the user by greying-out a menu action, rendering a particular field (attribute)
uneditable, or excluding it from the view. The ‘about’ method can also return a reason
for the lack of availability, which the viewing mechanism can render as ‘balloon’ help or
similar.
How is it possible to invoke multiple parameter methods from the user interface?
Any zero-parameter methods on a business object can automatically be rendered
accessible to the user as options on a pop-up menu. Single parameter methods can be
rendered accessible using drag-and-drop gestures - dropping object A onto object B
would invoke the method on B that has an object of type A as its parameter. (If there is
more than one such method, then the user interface could generate a pop-up menu from
which the user can choose). But what about multiple-parameter methods? The two
frameworks introduced in section 3.1 differ in the way that they address this issue.
The DSFA's Naked Object Architecture renders multiple-parameter methods
automatically into dialog boxes. The user selects the method from a pop-up menu, which
then returns a dialog box with labelled fields corresponding to the various parameters
and into which the user can type values or drop other business objects as appropriate.
The method is then executed via the 'OK' button.
36
The Naked Objects framework does not (at the time of writing) make use of dialog
boxes, and as such does not provide any means for the user to invoke a multi-parameter
method on a business object. Interestingly, experience of deploying the framework
across a variety applications suggests that this is less of a limitation than it might seem at
first.
Consider the example of a banking system where Account is a class of business object,
with methods for depositing, withdrawing, generating statements and applying charges,
amongst others. How should the system handle a transfer of funds between accounts? A
comventional design might implement transfer as a use-case controller sitting on top of
the objects, but this is contrary to the naked objects approach. However, implementing
transfer as a method (on the Account that the money is being transferred from) would
require two paramaters at minimum: the amount to transfer and the Account to transfer it
to. This is not possible with the Naked Objects framework.
The solution is to implement Transfer as a (purposeful) object in its own right . Its
attributes are the two accounts, the amount to transfer, and the date/time. The Account
object then has a method called 'Create New Transfer', which creates a new instance of
Transfer, ready populated with the 'from' account. Alternatively, the user could shortcut
this by dragging one account onto the other, which returns a new Transfer object with
both the 'from' and 'to' fields populated. After specifying the amount to transfer, the user
then invokes the 'Execute' or 'Make it so' method on the Transfer object.
3.3 Proposed benefits for naked objects
Four possible benefits from designing with naked objects can be inferred from the
preceding discussion:
Behaviourally-complete objects, leading to more agile systems
A faster development cycle
A common language between developers and users
A more empowering user interface
These are briefly defined below.
Behaviourally-complete objects, leading to more agile systems. The initial motivation
behind the idea of naked objects is to encourage the design of behaviourally-complete
objects, and thereby to deliver systems that are more agile - meaning that they can be
37
adapted more easily to accommodate unforeseen future changes to business
requirements.
A faster development cycle. If an appropriate framework is used, naked objects will
speed the development cycle. This is principally because it is no longer necessary to
develop a presentation layer, which often accounts for a high proportion of the total
development effort expended on a business system.
A common language between developers and users. Naked objects will provide a
genuinely common language between the developers and users during the business-
analysis and requirements-gathering phase of a project. Traditionally, the bulk of the
effort in this phase of development is concerned with translating the language of the user
presentation into that of the systems modelling domain. Using naked objects the two
representations are the same. This, in combination with the previous benefit, should
make it possible to prototype in real time in front of users - and to prototype not just the
screen presentations and user actions, but also the underlying object model at the same
time. Moreover, this common language of objects, classes, associations and methods,
should mean that the business user representatives can easily relate to the object model,
and perhaps gain further benefits from thinking about their business using object-oriented
patterns.
A more empowering user interface. The user interface resulting from the use of naked
objects will clearly be an object-oriented user interface (OOUI) [24]. The naked objects
approach does not improve upon the best work on OOUIs to date (which will be
discussed in more detail in 8), but whereas OOUIs are traditionally considered to be quite
difficult to implement, naked objects (or strictly speaking, the framework that supports
them) makes them trivial to implement. It is not suggested that OOUIs are universally
better than other forms of user interface. But the most significant advantage is that they
empower the user - they treat the user more like a problem-solver and less like a simple
process-follower [83].
These four benefits are potentially synergistic - each one strengthening the others and/or
making them easier to realize.
38
CHAPTER 4 DEVELOPMENT OF A NEW BENEFITS
PROCESSING SYSTEM FOR THE IRISH
GOVERNMENT
In order to test the viability of the naked objects approach, and to validate the benefits
predicted in the previous chapter, the author sought appropriate opportunities to design
and implement business systems from naked objects. The first such opportunity arose at
the Irish Department of Social and Family Affairs early in 1999.
4.1 Background to case study
The Department of Social and Family Affairs (DSFA) is the department of the Irish
government responsible for administration of social benefit schemes. 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 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 smart cards 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
39
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, one that would not only support the specific needs of the SDM, but would
also be more adaptable to future, as yet unforeseen, business changes.
4.2 Early experimentation
Early in 1999 the IS management became aware of the author’s research on building
business systems from behaviourally-complete objects, and the emerging concept of
naked objects. Although the management did not necessarily accept all the theoretical
arguments for naked objects at that stage, the hypothesized benefits meshed well with the
Department’s own goals for its proposed new architecture. The IS management was also
attracted to the visual concreteness of naked objects (i.e. the fact that core business
objects were also user constructs), and 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 thinking for some of its senior managers, both IT and business, with the help of
the author. Given that there was no framework to support naked objects at that point,
and there were no known examples of transactional business systems having been built
this way, a piece of consumer software called The Incredible Machine was used as a
metaphor throughout the workshop. (This is a good example of using a single metaphor
to guide the high-level design of a business system, as advocated in the discipline of
Extreme Programming [9]). In The Incredible Machine (see Figure 4-4.1), 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 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.
40
Figure 4-4.1 The Incredible Machine was used as the system metaphor
during the early stages of the design project.
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
specify use-cases up front. By the end of the morning a list of approximately twenty
candidate object classes had been produced. During the afternoon this list was reduced
by looking for duplicates or synonyms, by recognizing that certain candidates were
natural sub-classes of others, and by 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. (Of these original seven,
all but one have survived in roughly the form that they were defined on the first day.
Community was dropped due to a subsequent minor redefinition of the Department’s
responsibilities. It had briefly been the Department of Social, Community and Family
Affairs.)
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?
41
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-to’ responsibilities [120], with
emphasis on the latter to avoid thinking of the objects merely as complex data sets. The
result was a very rough 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 an officer who makes decisions relating to a claim
(there are many hundred such officers within the Department). The mock-up was
actually a series of hand-drawn screenshots held as PowerPoint slides (see Figure 4-4.2),
but a well-rehearsed demo created a realistic simulation of a working system, with the
impression of icons being dragged around the screen and menus apparently popping up in
response to a right mouse-click. This simulation demonstrated a small set of specific
use-cases. However it is important to understand that these use-cases were used only to
illustrate the potential functionality of a system built from a small set of behaviourally-
complete objects. The use cases were not used to analyse the requirements or identify
objects; indeed, they were written only after the objects and their high-level
responsibilities had been specified. (This theme is picked up again in 5).
Figure 4-4.2 Original PowerPoint mock-up of the user interface
for a system designed using naked objects
42
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, that 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 barriers between internal divisions, 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 increasing electronic access (via the web, smart cards, and
telephone), plus a more integrated approach to the systems themselves, means
that much of the routine 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 that had been proposed by some vendors, which
emphasized 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 other words, although the initial
motivation for exploring the naked objects approach was its potential to improve
the agility of the systems, after the first mock-up demonstration the managers
also became interested in the potential benefit to be gained from the more
empowering style of user interface that naked objects would bring about.
In addition to this positive reaction from the user representatives, the IS management
were also impressed with the productivity of this exercise compared to previous attempts
at department-wide modelling (whether as objects, data, or processes). Although the
43
DSFA was by no means ready to commit to using naked objects for a full-scale
implementation at that stage, all agreed that the concept should be explored in more
depth.
4.3 Applying the concept to Child Benefit Administration
At the beginning of 2000 the business case for action became more urgent. The existing
Child Benefit Administration (CBA) system needed to be replaced with some urgency.
The Government had indicated possible future changes to Child Benefit that the existing
system simply could not be modified to address (specifically, the possibility of the rate of
benefit being dependent upon the age of the child). Child Benefit is one of the simpler
schemes that the DSFA administers and is relatively small in scale: the existing system
had around 80 users. Yet the activities involved in processing a claim had much in
common with other schemes. It seemed an ideal opportunity to test 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. 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 operational business scenarios. Additionally, the model was
tested (on paper) against a variety of scenarios of how the DSFA’s business might
change in future. The business object model was captured in the form of textual
descriptions, which are reproduced in 10.3.
During these workshops, the DSFA made use of a very early prototype of the Java-based
framework being developed by Robert Matthews, which was eventually to become
Naked Objects. Although this was not the technology that the DSFA eventually used for
implementation, using the framework helped to build the participants’ understanding of
the concept of naked objects. The ability to capture the object model in the form of a
usable system (rather than just as diagrams) was a significant factor in persuading
managers to participate in the modelling process.
4.4 Technology demonstrators
Meanwhile, another group of IT managers within the DSFA worked on defining the
principles of the Naked Object Architecture that would fully support the concept of
44
naked objects and at the same time meet the DSFA’s other specific needs in an
architecture for core business systems. The principles are reproduced in Appendix I, but
the following excepts demonstrate the commitment to naked objects:
‘Exposure. Naked objects are exposed directly to the user - in a form that
makes it obvious to the user that they are dealing with an object. This includes
the use of an icon to represent the object. Most importantly, though, it includes
the exposure of the object’s potential behaviours to the user who typically
selects an object and then invokes a behaviour upon it. This implements a
‘noun-verb’ style of user interaction, rather than the more common verb-noun
style. In this way, the Naked Object Architecture presents the user with a set of
tools with which to operate and allows a business system to be designed that
does not dictate the users sequence of actions. This allows the user to be a
problem solver rather than simply a process follower.
Class methods. As well as exposing object instances, the [Naked Object
Architecture] provides the user with an explicit representation of the classes of
Naked objects. Using these class representations, the user can initiate a set of
class methods, including for instance methods for creating a new instance of
that class, for retrieving a particular instance of that class from storage using a
unique identifier and for finding instances that match specified criteria.
Single point of definition. Naked objects are ideally defined in a single place.
The representation and role of the Naked object in multiple tiers of the
architecture are all derived from that single definition - including the definition
of persistent storage in a database.
Auto-generated user interface. The default user interface is also ideally
automatically created from the central definitions of the Naked objects. The
Business Object defines for each of its methods the business-related
information the Presentation Layer needs to display and to capture from the
user. This information is subject to security filtering, to ensure that each user is
only shown the information he/she is authorised to see.’
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 the principles of the Naked Object Architecture
including all the services required of a scaleable enterprise architecture (e.g. message
broking, transaction monitoring, and persistence using a relational database). The
45
Department commissioned three such demonstrators from three different vendors, each
using different object technologies:
Sun’s Enterprise Java Beans (EJB)
Microsoft’s COM+
A proprietary object-oriented package.
4.5 Phase I implementation
Having evaluated the demonstrators, the DSFA put out a new RFT for the development
and implementation of a full-scale Naked Object Architecture plus a specified set of
domain object classes needed to provide a complete new application that would replace
the existing Child Benefit Administration system. The RFT did not provide a full
functional specification, but it did provide the description of the high-level
responsibilities required of the core business objects (Appendix II). The contract was
awarded in February 2001 to DMR Consulting (since renamed ‘Fujitsu Consulting’) -
with the original intent that the new system would go live in March 2002. (The author
continued to act as an advisor to the DSFA on an ad hoc basis throughout the
implementation - but had no direct connection to the contractor). The project was
subject to delays - some from over-runs of effort, some from technical difficulties, and
some from industrial action. However, the system eventually went live in November
2002, completely replacing the old system by the end of that month.
Figure 4-4.3 shows the physical architecture of the system. The client machines (shown
on the left) run a generic viewing mechanism written as a Java applet running within a
browser. The business objects run on the ‘COM+ servers shown to the right of the
client machines. Microsoft SQL Server is the primary persistence mechanism. However,
several of the object classes obtain some or all of their data from existing databases
running on Oracle or OpenVMS storage platform (because that data is shared with other
applications).
46
Figure 4-4.3 Physical architecture of the DSFA’s Child Benefit Administration system
Figure 4-4.4 shows the logical architecture. All business logic is contained in the entity
object classes (labelled ‘Business Objects’ in this diagram). Each business object has a
corresponding Data Access Object, which manages the mapping of the object’s attributes
onto a persistent storage mechanism. Part of the reason for this split in responsibilities is
that some of the business objects share their persistent representation with other systems,
in particular through the Central Records System (CRS). A product called Attunity
Connect manages the interchange of data with all existing databases. The business
objects and the data access objects were written in Visual Basic 6.0.6
6 In June 2003 the DSFA issued a new RFT to migrate these objects onto VB.Net. As well as moving from
the COM+ to the .Net service architecture, this migration will also allow them to take advantage of the more
object-oriented nature of the VB.Net language, which, unlike VB 6.0, supports inheritance.
47
Wind ows 20 00
Wind ows 20 00
Wind ows 20 00
Open VMS
Java Apple t
Java Applica tion
IIS
5.0 Bu siness Objects Data Access
Object s
CRS
SQL Server
2000
Attun ity
Con nect
Dispa tch er
Secu rity Refres h Secu rity Filter
PKI Be anString Parser
XML Conve rter
Req uest Ex tractor
RTF Bu ilderLoo kups
Error Han dler
Batch Suppo rt Publis h &
Subs cribe
Figure 4-4.4 Logical architecture of the Naked Object Architecture
The communication between the business objects and the generic viewing mechanism,
which passes through several layers of middleware, takes the form of XML messages.
Thus, a business object in the domain layer will send an XML message that instructs the
viewing mechanism to present an object on the screen, by default as an icon. The XML
message also specifies which attributes can be viewed and/or edited if the user chooses to
open a view of that object; associations to other objects (which will show up as icons in
their own right), and a list of methods that will be offered in a pop-up menu if the user
right-clicks on that object. A similar mechanism generates the class icons with their pop-
up menus of class methods. Figure 4-4.5 shows a screenshot from the application.
48
Figure 4-4.5 Screenshot from the new Child Benefit Administration system showing the naked
objects
The user can move objects around, expand or contract views, explore pop-up menus and
edit allowable fields without any communication passing back to the middle tier. When
the user is ready to save the state of a modified object, or wants to create a new
association between object instances, or to invoke a business method from a pop-up
menu, then the viewing mechanism will generate and send a concise XML message to
the appropriate object in the business model layer, specifying the action and any
necessary parameters.
4.6 Phase II
At the time of writing, the DSFA has indicated its intention to proceed with rolling out
the Naked Object Architecture into other benefit areas, starting with the state pension
administrations systems. The outline object model has already been extended to cover
this area. An RFT was issued for this in the Autumn of 2002, but was subsequently
withdrawn due to government-level budget constraints. Phase II has been rescheduled to
commence late 2003.
49
4.7 Evaluation
In February 2003 the author conducted an evaluation of the implemented system, by
interviewing 25 individuals connected in some way with the project:
7 IT managers who had some responsibility for the specification and/or
implementation of the Naked Object Architecture
3 business managers who were involved in the business object modelling for the
first business application (Child Benefit Administration) using the new
architecture.
15 users of the implemented Child Benefit Administration system all located in
the DSFA office in Letterkenny, Donegal.
Details of the interview method, the questionnaires used, summaries of responses, and
additional commentary on these three sets of interviews are provided in 10.9, 10.13.16,
and 10.17.10 respectively.
The following is a list of general messages derived from the analysis of those interviews
and the author’s evaluation of the system itself.
4.7.1 User reaction to the system has been very positive
Figure 4-4.6 shows that almost all of the users recognize and value the flexibility that the
new system provides them in terms of their way of working.
0
2
4
6
8
10
12
Agree
strongly Agree
somewhat Neither agree
nor disagree Disagree
somewhat Disagree
strongly
Figure 4-4.6 Response of 15 users to the proposition:
‘I value the flexibility that the system provides in choosing how to undertake a task’
50
Early in the project some managers had expressed concern that users might be unhappy
with the unscripted style of the naked object user interface and might prefer that system
guide them through the steps of the tasks they wanted to undertake. As shown in Figure
4-4.7 that turned out not to be the case.
0
1
2
3
4
5
6
7
Agree
strongly Agree
somewhat Neither agree
nor disagree Disagree
somewhat Disagree
strongly
Figure 4-4.7 Response of 15 users to the proposition:
‘I would prefer the system to guide me through the steps of a task’
Figure 4-4.8 shows that, at least in the user’s minds, the system’s operational flexibility
translates into better customer service.
0
1
2
3
4
5
6
7
8
9
Agree
strongly A gree
somewhat Neither agree
nor disagree Disagree
somewhat Disagree
strongly
Figure 4-4.8 Response of 15 users to the proposition:
‘The new system permits me to better deal with the needs of individual customers’
Figure 4-4.9 shows that 9 out of 15 felt empowered by the new system. Given the other
results shown in this section it is perhaps surprising that the percentage is not higher still.
The six who responded ‘Neither agree nor disagree’ all seemed genuinely puzzled by the
question, suggesting that there was a terminological issue. Several of them asked the
interviewer for clarification. However, it was felt that on this particular question, any
51
such clarification would probably lead the respondent toward endorsing the proposition,
so none was offered.
0
1
2
3
4
5
6
7
Agr ee st rongl y Agr ee somewh at Neit her agree nor
disagr ee
Disagre e
somewhat
Disagr ee st rongly
Figure 4-4.9 Response of 15 users to the proposition:
‘The system makes me feel more empowered as an individual.’
In any event, the responses to the final question, shown in Figure 4-4.10 are the most
conclusive. 15 out of 15 interviewees agreed with the statement that ‘The new system
contributes positively to my job satisfaction’, ten of them strongly. Such a reaction in
relation to a core transactional business system is probably quite rare.
0
2
4
6
8
10
12
Ag ree strongly Ag ree
somewhat Neither agree
nor disagree Disagree
somewhat Disagree
strongly
Figure 4-4.10 Response of 15 users to the proposition:
‘The new system contributes positively to my job satisfaction’
4.7.2 The system is efficient from a business viewpoint
The business goals for the new system focused heavily on improved agility. Increased
throughput was never an explicit goal. Indeed, the management recognized that adopting
naked objects might mean that the new system might be slightly slower for
52
straightforward tasks than a more conventional system based on scripted interactions (as
the older system had been). However, as Figure 4-4.11 shows, now that the system is
implemented the perception of users is that it is faster for most tasks.
0
2
4
6
8
10
12
Agr ee st rongl y Agr ee somewh at Nei ther ag ree
nor disagr ee
Disagr ee
somewhat
Disagre e
str ongl y
Figure 4-4.11 Response of 15 users to the proposition:
‘The new system allows me to process most claims and enquiries faster than before.’
At the time when the new system went live (November 2002) the Child Benefit
department had a backlog of more than 20,000 claims awaiting processing, such that a
new claim was taking up to 6 weeks to be processed. By the end of February 2003, this
backlog had been virtually eliminated, and the department was approaching its goal of
turning round most applications within a week. Clearing the backlog required a massive
short-term use of overtime labour - it cannot simply be attributed to the efficiency of the
new system. Nevertheless, the management believes that even though the new system
was still ‘bedding down’ in January and February, it was still a very positive factor in
helping to clear the backlog.
4.7.3 It is too early to assess the strategic agility of the resulting systems
properly, though initial signs are positive
Strategic agility - one of the DSFA’s explicit goals for the new system - is defined as
the ability to modify the system easily to accommodate future and unforeseen business
change. This capability is not going to be fully tested until the system has been through
several cycles of business change, which will take several years. As shown in Figure 4-
4.12 and Figure 4-4.13, most IT managers remain convinced that this agility will be
demonstrated in future, and two of the three business managers said that they could
envisage how possible future business changes could be realized through the business
object model.
53
0
1
2
3
4
5
6
7
Ag ree stro ngly Ag ree
somewhat
Neither agree
nor di sagree
Disagree
somewhat
Disagree
stro ngly
Figure 4-4.12 Response of 7 IT managers to the proposition:
‘To the extent that either of these forms of agility have not yet been demonstrated,
our expectation that they will yet be demonstrated remains
as strong as at the start of the project
0
1
2
3
Ag ree strong ly Ag ree
somewhat
Neither agree
nor disag ree
Disagree
somewhat
Disagree
str ongly
Figure 4-4.13 Response of 3 business managers to the proposition:
‘I can envisage how a range of possible future business changes
might be realized through the object model’
However, as shown in Figure 4-4.14, four of the IT managers believe that the system has
already demonstrated the ability to support this strategic business agility.
54
0
1
2
3
4
5
6
7
Agr ee st rongl y A gree somewhat Neit her agre e
nor disagr ee
Disagre e
somewhat
Disagr ee
str ongly
Figure 4-4.14 Response of 7 IT managers to the proposition:
‘The system has already demonstrated the ability to support strategic business agility’
Based on comments from those and other managers and on direct observation, there are
three pieces of evidence to support that view.
The first is that the business requirements changed during the development of the CB
system. This is likely to happen on any substantial business system project, but several
managers stated that it proved somewhat easier to accommodate these changing
requirements, even quite late in the project, than they would traditionally have expected.
As one put it: ‘On several occasions, the business sponsors asked if it would be possible
to accommodate a certain new requirement, fully expecting that the answer would be
“no”. They were surprised when the answer was “yes”.’
Second, when the new system was introduced in November 2002, the opportunity was
taken to introduce some broad organizational changes, of a scale and nature that could
justifiably be called business reengineering [45]. Previously, each claim was handled by
three separate people. One registered the incoming claim, entering the data from the
paper claim form into the system. Another officer ‘decided’ the eligibility of the
claimant and the amount of benefit (entitlement) that should be paid. A third officer put
the claim into payment. The motivation for this arrangement was the specialization of
labour, and reducing the risk of internal fraud. The deciding officers were further
specialized according to the type of the claim or action required, with officers
specializing, for example, in handling ‘16+ extensions’ (when a child stays in education
above age 16).
The new organization introduced the concept of ‘once-and-done’. Now most claims are
processed, from acceptance to payment, by a single officer in a single session. This has
been hugely popular with the staff (there are many positive references to it in the user
55
survey responses shown in 10.17.10). It is also worth pointing out that this was only
introduced because th