Avoiding the Point of No Reuse

The advantages of component-based development seem so damn obvious that it's a wonder everyone isn't doing it. But CIOs who've been there say reaping the benefits of software reuse hinges on overcoming a bevy of cultural barriersAfter simmering away quietly for the past decade, object-oriented technology has finally shed the shackles of the pilot project, and is making a splash in mission-critical business environments. According to converts, what has clogged its evolution and mainstream appeal was not only the lack of supporting infrastructure technology, but the issues of complexity and cost. But with heavyweight vendors like Microsoft now bombarding the market with object-oriented products, the technology is about to have its day in the sun.

Companies such as Macquarie Bank, Kodak and Bankers Trust swear by its ability to deliver cost and labour efficiencies.

For developers, the compelling reason for component-based software development are the economies of reusing code as well as avoiding the many risks associated with the traditional big bang approach of rolling out bespoke applications.

While for business users, the pace at which software applications can be turned around and subsequently adapted to change in business process is the winning characteristic. Still, there is a pervasive caveat. For those organisations bracing themselves to take the object oriented plunge, indications are that underpinning successful projects is a tight integration between business and IT departments.

In Australia, the drivers of object oriented development are found predominantly in the financial and telecommunications sectors - where the client/server and mainframe applications popular in the market today have simply proved too sluggish. After four years on the object oriented learning curve, Bankers Trust has successfully pushed an entire suite of mission-critical, object oriented applications through both its business and technology departments.

"The biggest issue is that it takes several years to change culture for using object oriented technology effectively," says Greg Baster, head of technology for Bankers Trust's investment banking group. "Having business ownership integrated with the technology is a very critical factor and if it wasn't in place at Bankers Trust we wouldn't have been able to achieve what we have to date.

"We actually structure our technical teams around the business structure, and my job is to coordinate activities to achieve reuse and cooperation."Baster says that Bankers Trust takes both a bottom up and top down approach to technology. "The top down approach is that we have top management support for decision-making in technology which is mainly comprised of business managers.

The bottom up approach means empowering team members to make decisions throughout development." Macquarie Bank, with over a dozen mission-critical, object oriented projects now under its belt, has taken the bold step of moving all in-house development to object oriented. Macquarie's development team - like Bankers Trust - attributes its mastery of the technology to the close links between business and IT that have always been a part of its corporate culture.

According to Gayle Burke, head of information services at Macquarie Bank, projects are literally funded by the business side of the organisation. "So if we are about to embark on a major project, we have to sell the architecture and costs and benefits to business, [the same] as an outside consultant. If they don't have any ownership or control over costs then you won't have an effective partnership. And if you charge them without consulting them you will possibly have an acrimonious relationship with them," she says.

But the freedom to develop software in tune with the flow of the business is more critical to some business areas than others, according to Baster. "The derivatives busi- ness is one of the most dynamic in the financial services industry. Changing products, risk management, trading team structures, rapid time to market, and marketing strategies are all sensitive to change. But you need the business buy in because their knowledge is so specialised it is difficult for technologists to grasp it in detail. Even our senior business managers now talk about object development with an understanding of its place in business systems," he says.

Darrell Martins, an application development project leader at Macquarie Bank, says that developers should not underestimate the repercussions of implementations on the business users. "As you change systems, you're changing the way people work. If you do it in a big bang fashion it's a big strain. With object oriented development, we can change gradually or quickly depending on the business demand." However, Trevor West, software development manager for Kodak Australia, faces quite a different scenario. Rather than developing in-house systems, the company has actually put its faith into object oriented technology for developing commercial business systems.

Where in-house development relies on business user feedback, the Kodak developers place heavy emphasis on development methodologies. "We started off very much as an integration shop - oriented towards project management. We developed our own internal project management method, which needed to comply with the ISO 9000 standard. It still serves us well but it left a lot to be desired as a systems engineering methodology, so in mid 1996 we adopted the Process Mentor methodology from Object Oriented," says West.

Yet, despite the different approaches, efficiency and flexibility is the name of the game, and Philip Louw, one of the object oriented project leaders at Macquarie Bank believes the current corporate trend towards massive software roll outs is transient.

"Companies can't afford to do those big monolithic projects any more," says Louw. "They run for too long and risks are too high, because after a year of development the business has inevitably moved on. You want to be able to deliver stuff in smaller chunks, so you're getting results and credibility from the first phase of the roll out, before you move on to the next stage.

"However, it's a trap to try to quantify benefits. The real advantage of the technology is in its design. The benefits will come further down the track because historically the majority of the costs of bespoke applications are the lifecycle costs," Louw says.

Burke agrees. "The promise of object oriented technology is that maintenance and support costs - the real costs - are going to be lower over time. The rewards are not so much cost savings as capability enhancement, while being able to maintain appropriate rigour and control," she says.

But according to Baster, Bankers Trust is starting to see solid financial returns from using the technology today. "While reuse of code is a difficult thing to achieve, the cost saving is very leveraged. Every time you reuse a component, you save not only the time it takes to develop a component, but also in the cost of maintenance.

"It is a difficult thing to quantify, but there is a rule of thumb that about 30 per cent of cost of a typical development project goes into initial development, and the remaining 70 per cent in support in maintenance," says Baster. "Over the long-term and short-term you can reap great returns provided there is a culture to adopt those reusable components throughout the organisation.

"Bankers Trust does have a strong culture of cooperation and reuse, and because we began strategically using object oriented technology three years ago, our components are being targeted for reuse in our trading businesses in the areas of fixed interest, cash and equity derivatives, and risk management," he says.

However, at Macquarie Bank, reuse is confined more to the backoffice than for business processes. Martins says: "Reuse depends very much on the culture of organisation. You would find it in organisations that are very tightly coupled, while for looser structures reuse of system components wouldn't be as great.

Meanwhile West believes that few users have met with the same success that Bankers Trust lays claim to. "I don't think reuse has taken off yet - many developers design their software for that [reuse] but it just doesn't happen.

"It's very hard to design something that will stand you in good stead for a series of different projects," he says. On top of the reuse issue, are other pitfalls for the unwary. For one, all users agree that it's very difficult to find good developers. Macquarie Bank has worked around this issue through graduate recruitment and retraining of its own mainframe developers, but acknowledges the problem is unlikely to ease in the short term.

And neither are some of the supporting technologies for object oriented development as stable as they could be. According to Pascale Mani, a development project leader at Macquarie Bank, there are still some weighty technological hurdles to cross. "We have found a lot of immaturity in some of the supporting infrastructure that you need for building mission-critical object oriented applications. Middleware is still on the edge of maturity where other things such as relational databases are far more developed. On our projects, we take a gentle, go slow attitude to bringing these things on board," she says.

Louw agrees. "There's a learning curve - it's a whole new way of doing things.

And we had to learn lessons - such as you just don't get too ambitious with this stuff. But now we're pretty comfortable with the technology," he says.

However, development project managers working in high-risk banking areas take more of a pioneering approach. "Trading rooms have probably been that little bit more aggressive with the technology because there is a pressing need for a fast turnaround and the culture is all about taking calculated risks," says Macquarie's Martins. "It's much more of a Darwinian environment, so if something survives then we keep it - if not then we move on the next bet. But you can look at what is going on in the US and take a punt on the trends happening there," he says.

Another cornerstone to success or failure hinges on the user's choice of object oriented development language. The issue is a heated one: as some tools are suited to high turnover and flexibility, while others can encompass complex mathematical equations but are less easy to manipulate. According to Martins, he has seen some "heavy duty tribal wars" between advocates of the C++ and SmallTalk languages. "It's pretty much a cultural thing, but the end results of this conflict can be bad for all concerned. At Macquarie Bank, we try to blend the strengths and weaknesses of each tool," he says.

Macquarie has also begun to use PowerBuilder for object oriented development.

Bankers Trust, on the other hand, began with SmallTalk, and is now migrating all future development over to C++ as the basis for its object component strategy.

"Until the last few years it was difficult to create object components because it was restricted to being a single-language environment - but the rise of commercial 'glue-type' technologies such as COM/OLE, CORBA and Open Doc has sped the process," says Baster.

"We have also taken a pragmatic approach to very standardised tools across the investment bank with the Microsoft toolset, using a combination of Visual C++ and Visual Basic," he adds.

According to Kodak's West, Microsoft is one of the main players shaping the object oriented horizon today. "When their products are released, they have a lot of impact on object oriented development. We've traditionally sneered at Visual Basic, but you can certainly use it for object oriented design. And while it's still got a long way to go, it is becoming more and more capable.

C++ on the other hand is well supported with a lot of third party tools and is an incredibly cheap package. The availability of good tools seems to have driven the acceptance of the technology - and made it available to everyone," he explains.

To add to the languages quandary, the Internet and Java are hovering just around the corner, and while most of the industry is waiting to see where it will lead, Bankers Trust is already dipping its toe in the water. "We believe that Java will probably be the dominant object oriented technology for commercial systems within a few years time and we already have some Java pilots going on. The results are very encouraging," says Baster.

For Macquarie Bank's development team, Java represents no threat either. Louw claims that because of the nature of object oriented technology, existing components can be replaced in measured stages. "It requires minimal cost and you don't have to change it all in one go," he says.

So while some companies may prefer to wait for the cloudy skies to clear before they decide to join the object revolution, Baster believes there are compelling grounds for embracing it now. "The technology is gradually being built into every tool being introduced to market - so sooner or later developers are going to have to learn to manage it," he says.

According to the Macquarie Bank development team, the best way out of the dark is simply to begin a project, and accept that the mistakes incurred will help to build a better infrastructure for the following project.

Burke says: "You could argue that the best way to get started is to do all the set-up work first and then start. But it's not the Macquarie Bank way. We started before the infrastructure had been built up - but I don't think it was a bad thing. You're better off just making a start rather than putting in a year of planning and investing up front.

"You do need to experiment on a project that is meaningful and useful.

Development can be done in a piecemeal way allowing you to sell your success to the business in order to fund later developments," she says.

* Louisa Bryan is the news editor of ComputerWorld AustraliaComponent speakBy Miryam WilliamsonTo help a CIO make a case for component-based development (CBD) to an audience devoid of glassy stares, some sorting of technical terms is in order.

Explaining the lingo will assist in persuading other executives of the benefits of software reuse API Application programming interface.

A specification within a program or component that allows other programs or components to activate its functions.

APPLET: A small application; a module. An applet can be a component by itself or can be combined with other applets to form a component. APPLICATION A component or collection of components that performs some useful task.

APPLICATION ARCHITECTURE The structure of components in a system. An application's architecture is made up of its components and their relationships. (Not to be confused with an enterprise's architecture, which consists of its hardware and software components.)BUSINESS OBJECT: An item of interest to a company; for example, a letter, a customer or an order.

CBD: Component-based development.

CERTIFICATION: a process by which a software component is tested to ensure it can be trusted; a precondition for inclusion in a component repository.

CLIENT: A component or application that issues a request for service. The component or application that responds to the request is called a server. (Both terms are also used in relation to hardware.) COMPONENT A software module designed to be used repeatedly in developing applications, either with or without modification. (See module.)CONSTRAINT: A condition or statement that must be maintained as true; a requirement.

CORBA: Common Object Request Broker Architecture. A messaging standard that enables object-oriented systems to interoperate.

ENCAPSULATION: The isolation of a component's attributes and behaviours from surrounding structures. The technique protects components from outside interference and protects other components from relying on information that may change over time. Components are often encapsulated.

EVENT-DRIVEN PROGRAMMING: The technique of creating applications in which the order of actions is determined by the end user or an external event as opposed to the programmer. The opposite of procedure-oriented programming.

INHERITANCE: The mechanism for sharing behaviours and attributes among objects.

Behaviours and attributes defined at a higher (more abstract) level can be accessed or redefined at a lower (more concrete) level. Some components are capable of inheritance.

ITERATIVE: development An approach to application development in which prototypes are continually refined into increasingly complete and correct systems. (See prototyping.)MODULE: A unit of software code designed for use with other modules; a component. (See applet.)OBJECT: A software module containing a collection of related data and procedures for operating on that data. (See business object.)OBJECT ORIENTATION: An application development and database technology based on defining abstractions of real-world entities known as objects, such as invoices, orders and customers, which contain both data and procedures. Key characteristics of object-oriented systems are encapsulation, inheritance and polymorphism.

POLYMORPHISM: The ability of objects to handle different types of information and different requests for actions. Components are not typically polymorphic.

PROCEDURE-ORIENTATED PROGRAMMING: The traditional approach to application development, in which the sequence of actions is determined by the programmer rather than the end user or another application. The opposite of event-driven programming.

PROTOTYPING: The development of a model that displays the appearance and behaviour (look and feel) of an application to be built. A prototype may only demonstrate the application's appearance. It may also demonstrate navigation and user controls, or it may even accept input data that can be stored in and retrieved from a simulated database. (See also iterative development.)REPOSITORY: A database of information about objects and components. Synonyms include library and encyclopaedia.

REUSABILITY: The characteristic of a component that allows it to be used in more than the application for which it was created, with or without modification.

SPIRAL LIFE CYCLE: Another term used to describe the iterative development process. Opposite of waterfall life cycle.

WATERFALL LIFE CYCLE: The conventional software development process, consisting of a series of steps commonly defined as analysis, design, construction, testing and implementation. The underlying assumption is that each phase does not begin until the preceding phase is complete.

(c) 1997, COMPUTERWORLD