The new industrial revolution

Don't look now, but a radical idea is the latest buzz. Instead of organizing for craft production, labor tasks should be specialized to increase productivity. First comes the design-the grand blueprint against which product is built. Developers then generate standard parts adhering to the blueprint, while assemblers piece them together.

Henry Ford, circa 1914, this is not. Instead, this is the brave new world of component-based development software. Rather than writing code, developers should be able to assemble it.

The Visual Basic Control (VBX) marketplace first made the idea popular. For $69, you could buy any assortment of graphical devices to paint the screens of your Windows applications. Need a radio button or drop-down menu to grace your Visual Basic (VB) application? Simply order one out of a vendor's catalog or download it from the Web.

Until now, it was easy to dismiss components as kid's stuff because of VB's limitations, especially when it came to scaleability, platform independence, and database connectivity-none of which VB itself really had. Enter ActiveX, which makes OLE Controls (the successor to VBXes) Webfriendly; Java Beans, which promises to simplify Java programming; and now, SAP's Business API (BAPI), which promises to deconstruct the company's R/3 enterprise resources planning system into-you guessed it-plug-andplay components.

With components, nobody should need to reinvent the wheel, or even the business process software applications to make one. With components, there is now a means for reusing code without having to rewrite the infrastructure. Thanks to standards like ActiveX or Java Beans, physical interfaces between reusable software are defined already. Thanks to Microsoft's distributed component object model (DCOM) and Java's network-friendliness, you can deploy components almost anywhere. Finally, thanks to Microsoft's ODBC and Java's JDBC, components can connect to SQL databases.

With ActiveX and Java Beans defining interfaces, everything should be plug-and-play, right? Let's assume that's true-although there is plenty of client/server experience to prove the contrary. In the case of components, what's to keep two ActiveX or Java Bean components from performing overlapping functions that conflict with each other? But let's assume we've gotten beyond that hurdle.

The real issue is, if components finally allow information technology organizations to piece together, rather than write business applications, what does that do to the application development process? Will you now pay R/3 consultants $250 per hour to connect BAPI icons rather than write arcane ABAP/4 code?

Early experience indicates IT teams are rethinking their roles. Large projects still need designers to analyze how users interact with information and how the application should be designed to handle those interactions. One difference is that they define standard components, not raw functions.

The biggest difference, however, crops up at the developer level. Traditionally, developers were responsible for translating design into code. In the component world, however, their roles are further balkanized. Some groups design components, while others piece them together. In effect, the software world is adopting production techniques that the manufacturing world rejected barely a decade ago: assembly line production.

But there may be hidden costs if the notion is taken too far, as any manufacturer will testify. When the assembly line becomes too specialized, workers lose sight of the end product, regardless of whether it's a four-door sedan or statistical quality management software. The designer views the application as a series of standard parts with little thought as to how those parts might interact, component developers get carried away and design too many components, while assemblers only reach for familiar components without regard for how well the finished application will test or actually run.

Component-based development could reverse recent history. In the 1980s, manufacturers often looked to the software community for expertise on reengineering. In the 1990s, the tables may be turned as IT organizations, bent on componentbased development, look to manufacturers to learn the basics of forming cross-functional software teams.

Author Affiliation: