One of the most fundamental problem of software engineering
is the construction of suitable abstractions. Another is the adequate
communication of functionality between all parties involved in the construction
and implementation of IT solutions, from end-users, through business managers,
to software developers. The approach described here uses the notion of business
activity (or business process) as a form of abstraction which can be used in a
variety of ways to develop specifications and designs for software systems. The
method avoids complex notations, at least at the specification stage. The
origins of the ideas began with a multi-national company which had a very
diverse set of software solutions implemented in similar businesses world-wide.
The ideas have been refined and adapted in the functional specification of a
system to support elderly care planning in the European Community, and some
aspects of that project are reported in brief in this paper.
The business activity perspective has a number of potential
uses. At a strategic level it is a good framework for comparing total IT
solutions in similar business environments, and consequently can be used as a
support for strategic planning of systems. In the procurement process, it
provides a good framework for scoping and defining functionality of a required
system, and for comparing proposed solutions. In the business reengineering
phase, it can be used as the basis for the terminology in describing actual
processes and quantifying aspects of changes to business operations. In the
software specification and design process it can be used in an object modelling
process as a framework for driving the dynamic modelling in a way similar to the
event-trace methods of OMT.
The author has used the techniques briefly described here in
a variety of consultancy projects. The common characteristic of these projects
have been:
Although no panacea, the business activity approach has
proved to be very effective in communication, obtaining consensus, and
co-ordinating group activities. By removing temporal and information flow
considerations, which are often a source of confusion and disagreement, it
enables a comprehensive map of a business to be constructed; it can be used
later to introduce information flow and time dependencies for the purposes of
deeper analysis and design.
The approach described here has been pragmatic and driven by
the needs of applications. However, a common theme is emerging, and hopefully
through the broader application of the techniques they can be related to and/or
integrated with established methodologies. The use of the approach in PLANEC has
begun to open up the integration into object modelling in a way which appears
consistent with and complementary to established approaches.
The PLANEC application
The PLANEC consortium has undertaken the ambitious task of
producing a demonstrator computer system which can be used in all member states
of the EC; it will support the strategic planning of elderly
care provision by a broad range of organisations from municipalities to
hospitals and other service providers. The consortium is led by the Stakes
Research Institute in Finland, and has partners in Holland, Spain, Germany and
the UK, and consists of research social scientists and practitioners in the
field of elderly care; a software house has been contracted to construct the
demonstrator system, but the responsibility for specifying functionality rests
with the social scientists. The author has been facilitating the specification
process, firstly by teaching the rudiments of object modelling, and then by
introducing and developing the notion of activity modelling.
Although the basic needs of the elderly may be similar in
each locality, the provision of services to meet those needs varies widely in
type and organisational structure. Each country has different legislation,
different infrastructure, and different policies. The greatest challenge, from a
software design perspective, has been to devise a suitable abstract description
of the problem in a way that can be understood by the social scientists who are
steering the development, the software house which will be producing the
demonstrator, the potential users of the system, and other interested
third-parties.
Object modelling was chosen as a design method for the
following reasons:
The project found early-on that the greatest challenge was
providing a common framework within which to describe the differing approaches
to elderly-care provision. The solution adopted was to introduce ideas from
Business Process Re-engineering, using an activity (or process) model. This
model was then mapped back into the object-modelling. This method is a novel
extension of object modelling, and serves as a useful contribution to computer
science in its own right.
A Three-Level Business Activity Model
A business activity is a logical grouping of events which
can be agreed as a fundamental element of a business. Although some implicit
ordering may emerge, the intention is to describe a whole business as a set of
about 200 to 300 activities without concern about the order or the interactions
of the individual activities. These activities are grouped on three levels. The
top level should be no more than about ten activities. For a manufacturing
company, these activities may be:
It can be seen that at the abstract level these are very
gross divisions of the company behaviour, which may be considered too obvious
and simplistic. However, experience shows that it is easy to obtain broad
agreement on these. Using a group of experienced researches and practitioners in
the field of elderly care, a workshop produced the following breakdown of
elderly care provision into:
Agreement on these took less than a morning, and the
breakdown has survived six months of scrutiny.
The activity model is intended to hide organisational
structure, and simply to describe the functionality of the organisation.
Activities may be implemented in many different ways, sometimes even within the
same company; for example there may be many types of manufacturing plant within
a company, producing different goods, or producing the same goods in different
ways. Having obtained the common abstraction it is possible then to map it back
onto organisational structure.
The importance of the omission of information flow and
temporal considerations cannot be over-emphasised. There is rarely any
disagreement on what an organisation does, but there is always disagreement on
how it does it. Flows can be added later, once functionality has been agreed.
The second level breaks down into finer detail each of the
first level activities. Again, this is a logical grouping, and any temporal or
informational links are implicit and/or coincidental. A second level breakdown
for the SELL activity of a manufacturing business might be:
In practice there are likely to be at least double these
activities for a particular business type. A second level breakdown for the PLAN
activity for elderly care provision was derived in a workshop as:
Again, this took about two hours to agree and has survived
six months of scrutiny.
Finally, the second level activities can be broken down into
third-level groupings. For the elderly care planning system, this was only done
for the PLAN and MONITOR/EVALUATE activities, as these are the principal focus
of the system being developed. A third level grouping for the INVOICE activity
in a manufacturing business might be:
Again, this is a little simplistic, and it is likely to
involve at least twice as many activities in a given business. The third level
activity for Analyse Information in PLAN was:
This was extended towards the end of the project from a much
shorter list. The lesson to be learnt is that the third level is more open to
changes. Practical experience of trying to break down to four levels shows that
it is very difficult to gain agreement, and becomes much more related to how a
business operates rather than what it does.
Having obtained agreement on the third level of activity, it
is possible to describe each activity in some detail. This has not yet been done
for the PLANEC application. For a manufacturing company, such a description can
take up many hundreds of pages. However, the principle value of the activity
modelling approach is its conciseness and brevity. Detailed descriptions are at
times either too vague or too prescriptive. However, for some purposes, such as
software tendering, it is vital to elaborate on activities for a third party to
understand.
The initial value of constructing a business activity
model
It can be seen that the above breakdown is in some sense
simplistic, and it leaves out a lot of detail. However, experience shows that
there is considerable value in the process of constructing such a model. The
following benefits have emerged:
Strategic uses of a business activity model
Perhaps the greatest value of an activity model at this
level is its ability to provide a concise, easily explained terminology,
organised in a simple framework, which uses the phraseology of the domain. Some
of the uses to which they have been applied successfully are listed below.
Mapping current IT solutions
Using the activity model as a checklist, it is possible to
identify all IT systems in use within a business. This is a gross level map; for
example a manufacturing business may have different types of manufacturing plant
using different software systems. It may be desirable to produce a number of
maps for the business, depending on organisational structure, say one for each
production stream.
The result of doing this for one organisation highlighted
the radical difference in IT support between similar organisations in different
countries, from one using over a hundred systems to one using thirty to achieve
the same purpose in similar markets. The experience of using this framework was
very positive, as it was possible to identify possible changes in IT usage
within different businesses, and to relate them to possible business process
changes.
Scoping of a package
It is possible to rate a package against each activity. The
author has worked with various numeric ratings. The most effective scheme,
however, has been to rate the package against each third-level activity
according to the scheme:
In the process of rating the package, the partial support
ratings should be accompanied by a description of the deficiencies of the
package.
Comparison of packages
Using a rating scheme as above, it is possible to provide a
very descriptive and concise overview of the similarities and differences of two
or more packages.
Request for tender
The activity model can be used as a checklist for a package
supplier or systems developer. By highlighting the activities which need IT
support, the supplier can be asked to address the needs of the business. This
requires a full description of the activities.
Identifying strengths and weaknesses of IT provision
This was done by the PLANEC group, to establish market needs
for the proposed PLANEC system. The activity model was used to construct a
questionnaire to identify strengths and weakness of the IT provision in
different organisations which need to support the planning of elderly care
provision. By collecting information in this form, it is possible to relate the
current market to the planned functionality of PLANEC.
Identifying actors
By cross-referencing interested parties with activities, it
is possible to gain an understanding of how a system may be used. This was done
by the PLANEC partners in their own countries, and it opened up a number of
organisational differences between the countries. In each case, there are
different actors operating elderly care provision.
Analytical uses of a business activity model
So far, temporal and information flow aspects have been
omitted from the model. The reason for this is that at the functional level
similar businesses rarely differ. However, at the operational level they do. By
introducing temporal and information flows, analysis of different aspects of a
business can be incorporated. Two simplified examples drawn from actual projects
are given below. They use activities defined in the activity model to indicate
information flows, and the effect of delays on information flows.
A problem of invoice errors
Chinese whispers within a group of companies indicated that
one company had cut its invoice error rate from 5% of all invoices having an
error, to almost zero, by changing from one computer package. This was being
used as an argument for a wider utilisation of the given package. To
substantiate the claim, an analysis was done of the business process before and
after the package installation. Prior to the installation, the information flow
relating to orders was:
Changes to standing orders were taken by the salesman
visiting the customer. These were taken on paper, and by the time the salesman
had returned to the office, and the changes recorded on the computer system, an
average of ten days elapsed. The consequence was that a high number of
deliveries, approximately 5%, were not as the customer now wanted them.
Therefore there were returns which the depot recorded on paper, and sometimes
extra emergency deliveries. Returns took five days to record on the computer
system. However, the practice was to issue invoices the day after delivery, and
the standing orders were used. The customer would then query the invoice,
usually at the end of the 30 day payment period; then they would pay the
re-issued and correct invoice at the end of a further 30 days payment period.
The net effect of 5% of invoices being paid 30 days late is
that the company needs approximately half a percent of its annual turnover
needlessly tied up in cash, which for a multi-million pound turnover is a
substantial cost to the business. The system looked ridiculously inefficient,
but it had been set up fifteen years earlier in a more stable marketplace with
fewer products, and when batch processing was the most cost-effective means of
providing IT support.
A new system was introduced which allowed telephone
ordering, and for the depot to record directly onto the computer system any
returns. A burden was taken off the sales force, who could then concentrate more
on selling to new customers rather than servicing existing ones. Customers were
sold the new process on the basis that they could adjust their stock levels more
easily, and therefore reduce their own working capital demands. The result was
that hardly any deliveries did not match customers expectations. There were some
added benefits of increased customer satisfaction and reduction in extra
deliveries to meet needs of customers. The change in the flow of information was
as follows.
Explained in this way, it was clear that the new software
package was not of a higher quality, thereby reducing invoice errors, but that
it facilitated a change in business operation which allowed the errors to be
removed. The decision to adopt a change in IT to tackle similar problems could
then be taken in a more informed way; arguably changes could have been made to
existing systems to achieve the same effect.
Stock reduction
Another Chinese whisper about a computer system in another
business area was that it reduced stocks in the warehouse and reduced the number
of stock-outs. Again, analysis of the process using information flows between
activities indicated the full reason for the improvement in stock management.
The flows before the new system were:
Customers would typically order about 15 days in advance of
delivery, to fit in with their own production schedules. Orders were taken,
irrespective of stock levels in the warehouse. Production would then schedule
its activities to maintain stock levels in the warehouse. The new system added
an information flow that allowed the production activity to see the orders. This
meant that production could respond to changes in order levels rather than
changes in stock levels. The result was that stocks could be reduced.
Discussion
The above examples could have been described in many ways.
The use of the activities from the business activity model meant that the
problem could be explained in terminology which could be understood by different
businesses. The use of information flows, with delays, proved very effective at
describing the benefits of changes in IT to business managers in ways that could
be quantified.
Object Modelling with Activity Models
Activities are logically arranged groups of events. Dynamic
modelling, through event traces, is one way of linking events to objects,
thereby defining object behaviour and identifying new objects. Activities can be
used in a similar way to identify operations on objects. This can be done by
simply producing a matrix; a simplified example from the PLANEC application is
illustrated below. This is for the ARRANGE RESOURCES activity. PROVIDER, FUNDER
and RESOURCE are three of the candidate objects for the PLANEC system.
A similar cross-referencing process can be used to identify
attributes.
This process has proved remarkably productive and effective
in defining functionality. Over a two day workshop involving the representatives
of the consortium, approximately 250 operations and attributes were identified
and agreed. The list for one of the objects is given in appendix 2.
The high level specification ended up with nine core objects
in the specification:
The objects are related according to the following diagram
The PLAN object interacts with all other objects, and so has
been drawn as above for clarity.
These objects are really large groupings which will need
further refinement with specialisations and component objects to be devised in
the design phase. The objective of the functional specification has been to
obtain a logical and complete grouping of all the data and functionality
requirements for the first prototype.
The activity model was used extensively to drive the process of defining these objects and their relationships. The process of cross-referencing objects with activities clarified a number of issues an reduced the set of candidate objects considerably.
The relationship of activity modelling to object
modelling techniques
An object model, consisting of objects, their attributes,
their operations, and their relationships, can be viewed as a computable
representation of the real world. Dynamic modelling, through event traces and
state diagrams, and functional modelling, through data flow diagrams, can be
viewed as a means of refining the object model. Activity models, as used above,
can be thought of in the same light. Thus they extend the repertoire of
available tools to analyse a business environment.
The difference between activity models and event traces (or
use-cases), is their omission of temporal considerations. In this sense they are
weaker than dynamic models. On the other hand, they prove easier to deal with in
the earlier stages of analysis. In particular, the lack of temporal and
information flow considerations allows specification of system functionality
without overly constraining implementation.
Planned research
The above methods and techniques have emerged initially as
ad hoc approaches to solving high-level analysis and design problems, and
communicating IT issues to senior management and to non-IT researchers. They
have not, therefore, been related to the literature. Two avenues of research are
opening up. One is to extend existing methods, using the activity modelling
approach. Another is to investigate the use of activity models as a bridge
between business process re-engineering and software engineering.
Conclusion
Activity models are proving a useful means of reasoning
about systems at an abstract level. By omitting temporal and information flow
considerations, they allow high level reasoning about systems and the
environment in which the systems operate. They are largely independent of
organisational considerations. They can be used as a framework for strategic
planning and analysis, as a basis for a common terminology in BPR, and as an
entry point for specification and initial design of systems in an object
modelling approach. They offer a possible, useful extension to existing methods,
and a possible bridge between BPR and software engineering. They have been
proven in a number of practical projects where the characteristics of the
projects have involved differing organisations which provide similar products or
services.
References
To be advised.
The complete activity model for elderly care provision,
devised by the PLANEC consortium, is defined below. It is only developed to two
levels in the areas where PLANEC has no direct use, and to three levels where
PLANEC has a significant contribution to make.
POLICY - second level
Identify / articulate issues
Investigate issues
Construct scenarios
Co-ordinate with other policies
Goalsetting
Set priorities
State policy
Consult / liase
Approve policy
Disseminate
PLANNING - second and third levels
Order to start planning
Collect information
Analyse information
Set up strategic goals
Set operational goals
Arrange Resources
Negotiate with actors
Make proposal
Consult / liase
Approve plan
Implement plan
MONITOR / EVALUATE - second and third levels
Collect information
Analyse information
Report
Make changes to plan
Operationalise evaluation criteria / choose measures
Evaluate performance
PROVIDE / CONSUME - second level
Assess need
Allocate care
Deliver care
Charge
Develop provision
Staffing
Maintenance
The attributes and operations of the Resource object for the
PLANEC system are defined below. This is one of nine high-level objects. It
represents more concrete objects such as residential homes and hospitals. In the
design, the basic functionality will be organised by specialisations of this
object and aggregations of other objects. The intention in the specification has
been to capture comprehensively all data and functionality areas to be
considered in the final design.
RESOURCE OBJECT
IDENTIFIED ATTRIBUTES
Data on quality of professional/client relationship
Data on management effectiveness
Budgets (health, social, housing)
Budgets for EC by sector
Data on technology available
No personnel by personnel group
No personnel by education/qualification
No personnel by age
Standards to resource quality
Buildings- size type and age
Total no. places by service unit by long/short term
Data on opportunity for client participation
Data on co-operation
No. of volunteers
No. of family carers
Data for Wenger index
No. absent days
No. of working days
Data on regime
Data on staff motivation & moral attitudes
IDENTIFIED OPERATIONS
Enter resource detail
Read resource detail
Edit resource detail
Allocate Capital Investments
Authorise and Allocate Recurrent Expenditure
Collect information on
resources:
staff
buildings
equipment
consumables
money
non-material
availability
quality
Collect comparative information on the level of service provided on
staff
buildings
equipment
consumables
money
non-material
availability
quality
Allocate current personnel
Calculate need for additional personnel
Calculate quality of professional/ client relationship
Calculate management effectiveness
Calculate budget proportions
Calculate technology index
Calculate no personnel/places by total pop
Calculate ratio trainees/qualifies staff
Calculate comparison of actual resources with standards for quality
Calculate no long term places
calculate co-operation Indexes
Calculate family care- actual v potential
Calculate Wenger index
Calculate absenteeism
Calculate regime index
Calculate staff- motivation moral attitudes index
Calculate technology productivity
Calculate labour productivity
Calculate equity of resource allocation
Investigate the current and potential resources
Allocate the current resources and
Develop a regroupment plan
Allocate the capital investments
Authorise and allocate the recurrent expenditure
Availability of social networks/familial
care, assess actual population statistics