You've heard it before: work fast, save money, build better software. But, as with everything it touches, the Internet has escalated that mandate. Is CBD the e-business silver bullet?
A decade ago, US-based project manager Igal Nagar decided software should operate more like the human body. After all, he reasoned, software can be one of our most expensive constructs: frequently costlier than building a car, sometimes dearer than sending a rocket into space. Yet software, like the human body, is born, evolves, dies. If we can extend the life of the human body by plugging in organ transplants, then why shouldn't we be able to extend software's life by plugging in new components?
Then Nagar joined TNT Post Group, which also had a vision: to write software once and deploy it in any language and any currency worldwide - from Internet through mainframe to Unix and PCs.
Both visions finally started to be realised on 14 December 1998 when TNT Post introduced to the Internet the first software product ever developed using components - a customer service environment. Within days, TNT Post's fiercest rivals, UPS and FedEx, had announced they too were moving to component-based development (CBD).
Nothing has served to highlight the deficiencies of other application delivery techniques more than the push to e-commerce and e-business. Organisations need to Web-enable their applications as quickly and effectively as possible; however, many organisations are finding just-implemented applications already starting to act like legacy systems. At the same time, there's more uncertainty about the future than ever before as business models constantly evolve. Software has to move fast to help companies keep their feet on the ever-shifting sands.
That's why some vendors and software developers are describing CBD as the e-business silver bullet - because components, unlike any other delivery mechanism, do allow businesses to plug and play. "Actually, no one thing is a silver bullet, but components are an absolutely essential building block or stepping stone [to the Internet]," says Object Oriented chief architect Brett McDowall. "If you're not creating components and reusing them properly, then you're not really going to make any progress," Of course, no technology can ever pose as a silver bullet unless backed by the strictest of discipline. That's where supporters claim CBD has such an edge over other development technologies: whole-scale adoption of CBD enforces a disciplined approach to application development.
Today, many more people are doing CBD than realise it, notes Jim Sykes, a senior lecturer at the School of IT, Swinburne University of Technology.
"A lot of people are doing CBD in the sense that they're using certain Microsoft products, but in many cases they would not be aware that what they're doing is called CBD," Sykes says. "It is not a chosen path for them, it's one that's almost come about by accident, because that's the way Microsoft develops and offers its products now." Indeed, both Microsoft and Sun have been gradually introducing component-based platforms over the last nine years. Both Windows 2000 and the Java EJB platform are specifically component-based platforms.
CBD is the child of object-oriented programming (OOP) techniques and tools, now into their second decade. However, while objects were a means to structure applications into highly modular and concrete parts, components go several steps further. Software components can drive mainstream business applications as well as power spreadsheets, word processors, Web browsers, or almost any other application.
Currently receiving the most focus is component technology's potential to be the technical foundation for plugging business applications into the Internet. "I think inherently if a CIO isn't looking down this track already under one guise or another then he isn't doing his job," says Dialog information technology director Bob Tisdall.
Dialog recently bought a 50 per cent share in ICE Media, one of Australia's leading multimedia design houses. Tisdall says the company is achieving high rates of component reuse in Web-based technologies and plug-ins. ICE and Dialog now work together as "one" and in particular are focusing on the e-business market - ICE's front-end strength and Dialog's back-end strength.
"The component reuse rate in ICE Media is high because they're right at the front there with Web-based technologies and plug-ins and all those sorts of things. So they almost as a matter of course build or reuse components because that's the way that they operate. And that business is a successful business within its own right," says Tisdall.
Dialog has also found reuse a good way to rejuvenate systems, particularly in the records management area. The company has used components here to update a "competent" system through both Web and Windows developments. Tisdall says the approach probably halved development time on the project.
Measure of Maturity
Component-based development focuses on building large software systems by integrating already developed software components. Underlying the approach is the tenet that certain parts of large software systems reappear so regularly that they should be written once then reused rather than be rewritten many times. Common systems should be assembled through reuse of such components, rather than rewritten again and again.
Consider it according to the school of economics that says maturity in sectors like manufacturing and engineering can be measured, at least to an extent, by the amount of components the typical organisation buys from others compared to the amount it builds internally. By this measure the automotive industry is considered highly mature because a huge amount of the components used in the final product have been purchased from others. Components promise to finally deliver this level of maturity to IT.
That's why the influential Butler Group characterises CBD as, in reality, the industrialisation of software delivery. CBD, it says, brings discipline, predictability and commercial reality to what has been, to date, an unpredictable and under-performing function in most enterprises.
"Unlike previous technology trends or waves, such as client/server, CASE or data warehousing, CBD is not just a technology," Butler Group says. "CBD is a set of concepts, which are, in principle, extremely simple. The principles can and are implemented in various technologies, but at the heart of CBD is the notion that, if business services are designed as components, they are inherently reusable, as opposed to being designed for obsolescence."
Increasingly, components can be purchased as commercial-off-the-shelf (COTS) products.
"We're now starting to buy components because we're finding modern products are much more advanced than the stuff we've written ourselves," says Australian Stock Exchange (ASX) project manager Nicholas Rugg. "For us to upgrade what we've been using for the last eight to 10 years is very, very expensive, and we're no longer in the game of wanting to maintain such a piece of core technology if we can buy it off the shelf. [CBD] is expensive but it does some very neat things."
Rugg says ASX's Internet developers are buying "lots of bits and pieces off the shelf".
The Near-Perfect Model?
There's clear evidence that IS shops that institute component-based software development reduce failure, enhance the efficiency and maintenance of systems and augment the bottom line. GartnerGroup says organisations that are mature in CBD methods using a model-based or a pattern-based application development framework can potentially become between five and 10 times more productive and responsive than those using other models.
And Butler Group characterises the emergence of CBD as one of the most important events in the evolution of information technology. "Components and CBD offer the promise of a software marketplace where components may be built, bought or sold in a similar manner to components in other industries.
"Certified components will be acquired and implemented alongside existing applications without disruption to the existing operational systems - the equivalent of application plug and play. Applications constructed in this manner would no longer become out of date, or be unable to adapt to changing business circumstances or new technologies. New components can be implemented which extend the functionality of the existing application in a controlled manner. Applications can, therefore, evolve rather than require periodical, very costly replacement."
Before joining the mainstream, CBD needs to prove itself easier to adopt than OOP. Despite the hype, it's been clear for some time that object-oriented development is nothing like a silver bullet. "Even those organisations that saw the advantages of using objects and object-oriented development techniques often came up against the realities of time-consuming and costly training efforts that promised to take a significant bite out of development schedules and budgets," IDC analyst Steve Garone says.
"The benefits of objects, measured in reuse, productivity, and quality gains, were often not achieved, due to either technological inexperience or the lack of commitment of resources to support these benefits. The mainstreaming of new technologies often depends on visible, real-world success cases exhibiting measurable, quantifiable benefits. The lack of such cases was an obvious hindrance to lowering the perceived risk seen by new adopters."
Garone says CBD as the next significant wave in software development promises to extend the concept of objects to a more standards-based approach that mainstream developers can use to solve real business problems.
It's Not Time
It has taken components a long time to find their place, says CSIRO R&D manager Ian Gorton, and it will probably take some time yet. Gorton says that's not only because there needs to be a gradual evolution in the quality of components, but also because many of the problems they are trying to tackle are incredibly complex.
"So first of all, quality is a problem. And second, there is just a continual evolution of components as they try to solve new business problems and work with new technologies. So it's an ongoing thing." Nonetheless, Gorton has worked happily with components for years, first at IBM when he developed distributed information systems and transaction processing systems using components.
At CSIRO for the last two years he's led a group heavily focused on the use of component technologies in large information systems. "We actually do real evaluations of component technologies, so we get the technologies in our lab, and we build applications and we stress them and we see how they really perform, and what you can really do with them," Gorton says.
Components, he says, let him do things that were simply not feasible three years ago. For instance, off-the-shelf component technologies known as wrappers or adapters let organisations solve software integration problems without having to handcraft particular wrappers for their own database or legacy systems.
"You can also do a lot of things like distributed transaction processing, which in the past was something that was fairly scary. Now, with component technologies and object transaction monitors and application servers, a lot of this is just out-of-the-box functionality for you to exploit," Gorton says.
But as Australian users and developers are finding out, while CBD does promise some useful remedies to the problems of developing applications quickly to cope with a rapidly evolving world, it's equally important to recognise its limitations.
One of these is that it can take a long time for developers to complete the learning curve and thus start delivering true productivity. Experts say it can actually take longer to develop projects when the organisation first starts using CBD. Only later does the company start to achieve payback.
"Your initial development as you assemble the components . . . is liable to mean that in the first part of the cycle your costs are liable to be higher for the output that you get," Tisdall says. "You're going to be investing intellectual energy into designing components for reuse rather than just immediate one-off use.
"It's all about doing things with a view to reusing code. And almost by definition you don't get the benefit until you reuse that code or component for the second or third time, or else you manage to buy it off the shelf. So to a certain extent, this process is front end-loaded for costs but pretty quickly gives you a positive return on investment."
Analysts also say CBD shifts the emphasis towards planning and careful design and architectural standards. That's an investment the organisation must make if it is to succeed.
IDC points out that CBD requires significant realignment of IT organisational thinking to a more strategic, planned approach to applications. "However, this change should not mean a return to multi-year projects or analysis by paralysis'. An appropriate CBD strategy has the potential to reduce lead times and costs by taking a planned reuse and acquisition approach," IDC says.
There is also a cautionary warning to be made about vendors who fold or otherwise withdraw support for the components they sell. Rugg has been caught this way on several occasions and now only deals with leading suppliers. Even so, "Sun has already let me down," says Rugg.
Tisdall agrees that there is a problem with the long-term viability of some components, particularly since the component industry has been driven to a certain extent at the lower level by one- and two-man bands selling components for $29.99 on the Internet.
"That's why, if you're going to buy a component like that, you're better off getting the source code so you're protected if they go out of business," he advises. The emergence of object request broker architectures is increasingly freeing people from being locked into a single vendor, he adds.
It's also absolutely essential the organisation understands what it wants to achieve before going into components in a big way.
"The great difficulty that end-user organisations have when they adopt a component strategy is the complexity of the component technology that's available to them, and also the range of competition," Gorton says.
"There are many component technologies that claim to be able to do the same thing, all equally wonderfully and all equally bug-free. But in reality, this just isn't true. They all have different characteristics, different performance parameters and different costs of development."
And CBD can also be very seductive, Tisdall warns. As software development becomes cheaper and easier, CIOs have more need to put on a lid on scope.
"I think what we're going to find is that we will develop more complex systems because we can, and therefore the systems will still be expensive to develop. If we came out with a system that compared functionality with functionality, [CBD] would be a cheaper way to do it. But what happens is that because you can, you do a whole lot more," he says.
While massive levels of reuse have been a goal of many software development organisations over the years, most have found that goal difficult to achieve.
CBD facilitates reuse of existing applications, components, acquired functionality, models, fragments, designs and frameworks. When tried and tested components can be reused, applications can be delivered faster and cheaper and with higher quality.
Better yet for the e-business world, the reuse of components improves the consistency of executing business processes and business rules across the organisation. For example, it can allow an organisation to apply discounts uniformly to a single customer across all product lines.
And making components easily accessible and available for reuse makes information more accessible and, hence, more consistently applied across the organisation. For example, the knowledge that a customer is dealing with one part of the organisation becomes more readily visible to all other parts of the organisation.
In a bid to encourage reuse of all sorts of deliverables, many organisations have introduced reuse programs that address not only technical design but cultural, motivational and reward issues. However, the results have generally delivered less reuse than planned, often at significant cost.
So from being a popular concept a few years ago, the notion of reuse went out of fashion for a while because it just wasn't working, says Object Oriented's head Brett McDowall. But that's not to say reuse isn't achievable. "Too often, people treat components as these final artefacts and then wonder why they don't really get the benefits out of them. It's usually because [the components] were never capable of being reused."
McDowall says reuse should be considered an essential part of a wider component-based strategy which plays a critical part in reducing the time and cost to deliver new applications and improve their quality. "Reuse happens on a lot of levels, and by combining architecture and process and then moving that down to the actual components you're using and how you put them together, you really can get high levels of reuse," he says.
It's important to make the entire concept of reuse a factor in the very processes you use, from your business strategy, through the way you determine what software you want, to the way that software is deployed, and even how you hire your developers. "You have to consider what the components are and how they will be used, how they're defined, and also the architecture. You have to own your own architecture and understand what components are."
Too many people also get the granularity wrong, McDowall says, by failing to understand what a solid architectural component is. It's the difference between considering a brick a real component of a building, or recognising it's just a building material. The best component provides much larger granularity up to the business object level.
"There's a tendency - especially in the Microsoft world, I think - to almost equate objects with components," McDowall says, "but that doesn't really give you any leverage: you need to have components that are much bigger than that."
"To actually make them so they can be reused across a number of projects requires a considerable amount of architectural insight, which a lot of people either don't have or don't want to have, because they just want to get in and build it."