 |
Starting with Objects |
The ‘Starting with Objects’ project informed and provided guidance for OIG members on why and when to adopt objects, benefits and costs, barriers and impediments, and was substantiated by supplier and IT user experiences.
A survey by Taligent indicated that in 1992/3 only around 5% of USA companies were using the object
approach and supporting technology. Assuming that a similar figure
applied to the UK, we felt that the issues surrounding ‘starting’
were therefore important. Furthermore, we felt this should be related to all
aspects of the development life cycle and its management, ie analysis, design, project management, methodology, organisational
infrastructure, performance and maintenance etc.
The objective of the project, therefore, was to address the questions :
- For what proven reasons do people start with the object approach and technology ?
- What are the key issues associated with running projects ?
- How are they being handled ?
The solution process consisted of OIG members first sharing their
experiences to identify key concerns. From April ‘93
to December ‘93 experienced practitioners and suppliers were
invited to give presentations to respond to these concerns, and
together with members’ own experiences provided the evidence on which our findings were based.
Members’ key concerns were loosely grouped into the following categories :
- How to persuade management.
- Why start ?
- Where to start.
- How to start.
- Project management.
- Organisational management.
How to persuade management
The first group of concerns we encountered were to do with persuading
IT division management to start to use the object approach in
the first place.
The members and practitioners we spoke to used different approaches
to gain management support. In some cases, the persuasion came
from outside the companies concerned, via messages from key suppliers
to high-level management. Others carefully controlled the process
of persuading management, even targeting the particular level
of management they would involve - typically not too high.
Almost all agreed that it was essential to tell the bad news,
as well as the good, to avoid it being thought of as just hype.
While management were fed with object information and understanding,
their expectations of the technology was also carefully managed.
This included making it very clear that to see the real benefits,
ie productivity and quality gains, it was necessary to invest
in more than one project, ie the first project would not be cheaper
and would not deliver lots of reusable components. But the flexibility
of objects could be demonstrated straight away, providing a basis
to argue for reusability and subsequent reduction in costs.
Why start ?
Hard evidence is essential to the persuasion process and there is inevitably a lot of management scepticism, particularly
since so few of previous industry offerings have met their hype.
Competitive edge in the mid-nineties is about IT supporting the
business wherever it wants to go, in a rapid and responsive manner,
by integrating new and existing functions. The evidence we have gathered suggests that objects are particularly
effective at enabling IT to overcome these business problems.
Therefore, being faced with any of these problems would seem
a compelling enough reason to start.
On the other hand, immediate cost reductions are not a good reason
for starting. Although significant cost reductions have been
seen, these were generally as a result of considerable up-front
investment in training, staff, infrastructure, reuse etc. Furthermore,
since reuse is the main contributor to cost reduction, any significant
benefit is unlikely to be evident until at least the second or
third project.
Objects had moved beyond the hype stage . There were now many
examples from both our own members and practitioners we met as
to their success, particularly where conventional approaches could
not cope, even though overall penetration was still low.
Where to start
Where to start remains a major problem for management. We have
seen that the reaction to small pilot projects can be ‘so
what.’ The alternative is to start with an application where
the object approach has significant advantages over conventional
approaches, though often these applications are enterprise-critical.
Consequently, where people have started varies considerably :
- Car dealerships.
- Airline yield control.
- Financial dealing.
- Underwriting.
- Pension administration.
- Network management.
- Mortgage administration.
- Maintenance planning.
- PEP administration.
How to start
In general, the most effective way is to choose an application which is small,
but important to the business. This allows control to be more easily maintained while everyone is in a learning state, but also avoids the pilot project reaction. However, we did see successful projects of varying sizes, ranging from a few man years to around one hundred. Indeed, some of our members started with very large enterprise-critical applications, either
because conventional approaches could not meet their needs, or
because their competitors were already using the technology.
People’s experiences were mainly favourable, whatever the size of the project, but the larger ones did require more effort, and therefore investment, to control. Most
problems occur when there is no properly thought out and communicated
systems architecture, or support for evolutionary delivery. Similarly,
too much focus and effort on reuse, or methodology and tool selection,
has also resulted in problems. These are all unnecessary diversions
for a first project, and are generally extremely time-consuming.
Project management
A number of concerns relate to project management.
Quality comes from repeatable processes that can be tuned and
gradually improved. Managers had concerns that evolutionary
development did not have sufficient clarity of process to enable
this.
The main differences in project management result
from the different life cycle required for object developments.
Analysis, design, implementation, testing and integration are
still components of the object life cycle, but they form more
of a continuous process rather than discrete stages. As such,
object developments involve more of an evolutionary approach,
a small part of the final system being completed as a result of
each evolution (or iteration). Evidence showed that it was best
to treat each evolution as a formal stage, delivering code. Along
with regular walk-throughs, this allowed the project manager to
maintain control.
Any changes to requirements, that the evolutionary
delivery prompted, needed to be carefully managed. This was particularly
necessary where sub-contractors were involved, because typically
they were only too pleased to make any changes !
Object developments
typically have two deliverables - the application and any reusable
components. Evidence showed that project managers needed to be
aware of this and explicitly manage it, again paying particular attention if sub-contractors were involved.
The definition between analyst and programmer roles also became
blurred, the same developer usually doing the analysis, design
and coding of a given part of an application. The new role was
that of a class manager/librarian which most successful projects
established straight away, even if this was only to manage external,
bought-in classes.
One essential issue seemed to be communication. In the small
teams, this was relatively informal, but where larger teams were
involved and/or the development was geographically distributed,
it was necessary to establish electronic communication links.
Organisational management
Most organisations have already made substantial investments
over the years in IT. Consequently, any necessary response to business changes they want to be able to achieve by building on the IT resources they already have. This in general means being able to integrate previously separate legacy systems and emerging approaches such as client/server, open systems etc
The cost of maintaining legacy systems and supporting the equipment
on which they run, will eventually exceed the cost of developing
replacement systems. The advantage of the object approach is
that it provides a realistic migration path, rather than forcing
complete replacement all in one go. Evidence has shown that objects
will allow us to move forward on the established base, for example
by giving existing systems so-called ‘object-wrappers’,
allowing them to communicate with new developments as they gradually
appear.
Concluding remarks
The most immediate benefits of objects, which can be demonstrated
with the first project are flexibility and their ability to handle
complexity. Increased productivity and quality, and reduced development
costs have been demonstrated, but in general this has been as
a result of subsequent projects.
There were barriers to the take-up of the technology. Some were
related to its maturity, for example poor staff availability - which is gradually improving, while
others are inherent to objects, such as the culture changes required.
But despite these barriers, members and practitioners we spoke
to, considered the benefits outweighed the costs.
Experience will help overcome the barriers. This is why it is
important to start as soon as possible, preferably with a small but high-visibility
project, demonstrating the simple benefits, while exploring the
changes required and gaining knowledge to achieve the more valuable
benefits, but at minimal cost.
Created : 30th April 1996
Updated : 11th August 1996
|
