Although we've initiated some changes this year--including the name of this column--one thing will remain the same: my drive to boost your business-to-business success. In large part, I'll be identifying the problems you'll face and the solutions you'll need to advance your projects. Focusing on applications issues, my emphasis will be on the external. And I'll address your challenges in four categories: management, infrastructure, development and applications--specifically e-commerce.

In 1999, the organizational management focus likely will fall into the categories of partnerships and distributed projects. It's easy to predict this trend because of the sudden social acceptance of outsourcing and the increased pace of ad hoc collaboration as business partners jointly pursue markets. SLAs (service-level agreements) may help you manage suppliers and outsource vendors, but how will you manage a "partner"? Experience shows that the ad hoc nature of virtual teams doesn't guarantee quality.

The most interesting effort in the management of large development has been in Open Source. Although not new--Open Source has proven itself with the development of Apache, Bind and Linux--it has become the battle cry of Netscape Communications' Mozilla source-distribution scheme. With Open Source, the question is not one of product but of process: Every corporate IT manager tries to duplicate the success of programs such as Apache, Bind and Linux. We all strive for flexibility, innovation, reliability and faster development time. However, it's a stretch to apply Open Source processes to corporate IT development, regardless of platform (open or proprietary). But it's an incredibly interesting idea. Can it be done? Is anyone doing it today?

Infrastructure Intuition The network infrastructure market has not ignored the intercompany collaboration trend. Every booth at every network trade show this year had VPN (virtual private network) plastered all over it. Extranets leverage the ubiquity and growing reliability of Internet connections to quickly and securely provision communications between customers and suppliers, and joint ventures. What you exchange and allow access to, and for how long, is contingent on the nature of those ties. Results have included, but are not limited to, an increased need for security-policy management, a call to develop relationship-specific applications, and the need for managed access to production systems and their underlying data.

Last year, you may have implemented a firewall and secured the DMZ and its hosts. But this year, you'll secure the rest of your internal segments and systems, and I'll be here to help. Additionally, I'll advise on applications; you'll need choices beyond punching holes in firewalls.

As your internal applications meet the requirements of these intercompany efforts, chances are that 1999 will be the year your Internet applications reach critical mass. Finally, you'll be obligated to get economies of scale through code reuse. In anticipation of this necessity, the development community has increased its focus on application servers and active content. Back in 1996, in this column, I addressed the need for traditional database engines to support just that. I'll continue to monitor this development and keep you posted.

Also in 1996, I reported on the emergence of the CLEC (competitive local exchange carrier) market and its implications for providing choice, delivering more bandwidth and lowering costs. Now DSL (digital subscriber line) technology has matured. The question is: Will CLECs and other carriers compete over cost or demand, or will the contest always be about bandwidth? We'll see if the combination of competition and technology will help us deliver services at a lower cost or if we'll still be waiting come this time next year.

Predictions and Predilections While I'm fairly comfortable predicting what you'll see in this column during the upcoming year, crystal-ball gazing is a touchy subject for me. I remember (though I've tried to forget) the time in 1989 when I got up in front of an audience and preached about how we should discard SNA. I argued that IPX was a waste of time--the solution was IP. I got religious about it and endeavored to persuade the rest of the corporation to see the light and get rid of their archaic 3745s. OK, so it didn't work.

The point is that despite my zealous belief that all things would be wonderful once the protocols on the wire were standardized, I never--and I mean never--thought that the result would be the canonization of mundane retail applications to the realm of the killer app of the Internet. If I had, I wonder if I would have pursued IP with such vigor.

That brings us to e-commerce. I can't think of another example where the answers to feature-set questions--like "Can I disallow duplicate products in a line item?" "Do you support tax calculation for Lower Saxony?" and "Can a customer change his or her registration data?"--will become the cutting-edge concern of venture capitalists. Come on, 10 years ago if they had wired a cash register to the Internet instead of a Coke machine, we would have called it e-commerce. That's all B2C (business-to-consumer) sites are: glorified cash registers. And what's an Internet-enabled loading dock scale and bar-code reader? It's a B2B (business-to-business) site.

For e-commerce to scale it will need to do more than provide easy-to-set-up stores. It will have to integrate, scale and conform to an identifiable architecture. I'll track the pipeline of features for e-commerce and determine if factors like fraud control, catalog cross population, heuristic identification of visitors, and personalization are requirements for the real world or simply buzzwords.

So that's my plan for the column in 1999. Of course, I'll deny it once a better idea comes to mind.

Brian Walsh is the founder of bwalsh.com, a Portland, Ore., consulting firm specializing in Internet and client/server product strategies, development and testing. Send your comments on this column to him at brian@bwalsh.com.