Carlos Leyva

Silicon Stories

Chapter 6: Architecture

Components

« PreviousContentsNext »

Components are software building blocks that are reusable. They plug into, and require, a runtime commercial plumbing infrastructure such as .NET or J2EE. Individual components are compatible with one or the other (i.e. .NET or J2EE) but not both. There are a number of software companies that generate revenue based on providing reusable components and nothing more. There are now third party market makers that facilitate transactions between component buyers and sellers (e.g. Flashline at www.flashline.com). In short, the software component market is maturing, however despite a maturing marketplace, many (perhaps most) IT organizations and plenty of ISV’s (sad to say) are woefully behind the component reusability curve. Why is that? Why does it matter?

Buy versus Build

Like so many other aspects of software development, the reasons that components and reusability have not taken off as dramatically as expected, despite the progress, are largely rooted in historical, organizational, and sociological (biological?) considerations. Developers and other technologists are natural-born tinkerers. They like to build stuff. They like to use the stuff they build. They have an innate proclivity to use their own stuff.

IT management, on the other hand, recognizes the importance of components in the abstract, but becomes totally caught up in the selection process. They become obsessed with finding the best components where, in the majority of cases, damn good ones will do. Either that or they refuse to give up the cold hard cash required to purchase them, the epitome of being penny wise and dollar foolish.

The change to a software component mindset is happening ever so slowly. Most organizations would benefit greatly from purchasing commodity component technology and moving up the abstraction food chain to design issues. The design domain is where significant differentiation is likely to occur going forward.

In the consumer electronics space there is a significant trend toward outsourced manufacturing. Microsoft designed the Xbox but Flextronics manufactures it. Microsoft rightly decided that it was not in the consumer electronics manufacturing business, and did not need to be.

This is not an argument for outsourcing your entire software manufacturing operations; in the near term commercial components provide a happy middle ground. In the longer term, variations on the software manufacturing outsourcing theme will have to be re-visited based on the same economic drivers as consumer electronics (i.e. that differentiation will become completely design centric).

Reducing the DIP

Component based development dramatically reduces outstanding decisions in progress. Once you buy or build a robust set of components you use them with confidence over and over. This strategy can provide up to 60% of any new product pre-built. Using pre-built components has revolutionized a number of industries including retail-housing construction. The exact same idea is now being applied to software development.

It is obvious that starting with a 60% pre-built solution yields significant benefits. But the upside to this strategy is more subtle. Not only do you get the benefit of using proven parts, you also win by not having to revisit these issues from a decision-making perspective. In short, a 60% pre-built solution probably yields more like a 70% reduction in product cycle time.

« PreviousContentsNext »