Columns

Retooling the software factory

• By Tony Baer
• June 25, 2001

Compare the market valuations of Microsoft and GE, and it is clear that the financial world views the software business as the single largest creator of wealth in the 1990s. The software industry's winning streak has put a premium on developers, whose salary growth continues to outpace the rest of the white-collar world. But it's amazing what adversity has taught manufacturers; however, being "kings of the hill" doesn't make us immune to the lessons that our less-glamorous colleagues have learned.

Let's try a few on for size.

LESSON ONE: Become customer-driven. Leading manufacturers and financial services organizations often attribute their success to their ability to translate customer desires into products and services. It's a switch from the days when choices were limited and suppliers dictated what customers could buy.

In the consumer goods industry, for instance, supply-chain integration has tipped the balance of power to the customer. Retail leaders, such as Wal-Mart, share sales/distribution data with suppliers, who are expected to deliver what the retailer can, or wants, to sell.

In the software field, we still believe that technology limits our choices, and that we know what's best for the user. How often have you heard, or claimed, that the customer was demanding the impossible -- such as querying capabilities that would force us to develop SQL statements joining dozens of tables? Too often, we're convinced that giving the customer what they want will bust budgets or deadlines. Too often, we fail to innovate when customers ask us to jump through hoops. It is a sign of our industry's immaturity that we still joke about Bill Gates designing cars.

LESSON TWO: Stop making quality an afterthought. We remain awfully inefficient at what we make. A few months back, we wrote about the plight of the quality assurance (QA) specialist. While the manufacturing sector learned a decade ago to build quality into the process from day one, in software development we still build and design the software first and then send it back for rework. Can you recall any project in which QA personnel were involved at the design stage?

LESSON THREE: Configure to order. Reuse, hyped as the wave of the future, has been derided in many quarters as a return to the Henry Ford era of mass production. Once again, we could take another cue from manufacturing: Don't stamp out the same product, configure it to order from basic components. The result will be the best of both worlds -- the economies of mass production combined with strong customer responsiveness.

For manufacturers, product configuration tools have made this possible. They allow manufacturer sales representatives to "virtually" assemble a product to customer specifications on their laptops. The configuration tool provides menus of parts, features and extensive rules sets regarding what can be assembled, when products can be made and how much they will cost. The customer gets what they want, and the manufacturer gets return business.

So if you want a blue widget that accelerates to 100 m.p.h in six seconds, has an extended memory option, a 19-inch flat-screen monitor and a sun roof, you can have it -- as long as the rules say that the item can be manufactured and that the combination of parts won't impair the operation of the final product. In this case, you could get almost everything you want. You might have to drop the flat-screen monitor because of federal safety regulations prohibiting car TVs.

Admittedly, no such configuration tools yet exist for component-based software development. But some of the ingredients are beginning to fall into place, such as component interface standards, visual modeling, automated testing, repositories and so on. Nonetheless, the real battle may be cultural, not technological, as we discuss in "The culture of components." In this feature, an I/S executive notes that internal customers were cynical that their unique business needs could be satisfied by anything made of generic parts -- until the development group actually delivered.

LESSON FOUR: Develop a configure-to-order business model. So you've configured the grand outline of a software package. How do you get developers to go against their better nature and stick to assembling the specified components? Money.

Taking another cue from manufacturers, transform your I/S group into "virtual organizations," with each group making or buying software components that are assembled into applications that are then sold to end-user organizations. To keep things honest, end-user organizations may buy from your group or from outside suppliers --after all, it is a free market.

The result might be that your development group becomes a solutions group. But what's wrong with that, especially once you're tallying the profits?