OIG Ltd Capturing Business in Software OIG Ltd Capturing Business in Software OIG Ltd Capturing Business in Software

+44 1249 815081

 

Business Modelling

Adopting a Process

 

more@oig.co.uk

Business Builder

Component Development

Home

 

Full Life Cycle

Delivering on the J2EE

 

OIG was established in 1993 to run the Object Interest Group, formed in 1990 to help large scale users migrate to object technology (OT). OIG has since developed and implemented reusable processes, frameworks and components facilitating the rapid development of flexible and maintainable systems. This means we now have considerable experience of helping companies with all aspects of the development life cycle, including technology selection, choosing methodologies, tailoring software development processes, business modelling, requirements gathering, tool selection and tailoring. Recent technologies we have helped companies adopt include Use Cases, UML, RUP, Agile methods, J2EE and component-based development.

Would you like to know more about what we do ?

The following page describes the work the Object Interest Group did on getting initial OT projects started within their companies. Although their work took place some time ago now, many of the issues they addressed remain relevant to anybody embarking on their first OT project.

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

Go to top of page

 

The Object Interest Group
 
History of the Object Interest Group
An Assessment of OO
Choosing a method
Managing Reuse
Feasibility of CBOs
Components and BPR
The Object Interest Group Home Page
Go to OIG Ltd Home Page
© The Object Interest Group

Any comments on these pages to: more@oig.co.uk

© OIG Ltd 2002-2003

Legal