In-Depth

Eyes on the Web commerce prize

Web commerce is becoming both useful and efficient, according to industry studies. As a result, there is a growing demand for the development of Internet, intranet and extranet business-to-business transaction capabilities.

Bill Clifford, president and CEO of the Stamford, Conn.-based Gartner Group, predicts that by the year 2004 more than 50% of all enterprises will use the Internet for more than 80% of their external procurement activities. Meanwhile, almost every company offering products and/ or services has developed or is developing Web sites ranging from information-only sites, known in the industry as "brochureware," to sophisticated Web commerce sites where customers can select and purchase products ranging from music CDs to automobiles.

That is the good news. The bad news is that IT departments are suffering sticker shock when it comes to developing Web-commerce applications. "Most companies are grossly underestimating Web application and development costs, sometimes by as much as 20 times," noted Clifford in his key- note address at the recent ITxpo 99/Dataquest Predicts 99 conference held in San Diego.

Chris Staszak, CTO at Evergreen Internet Inc., a Chandler, Ariz.-based provider of Web-commerce software and consulting services for companies such as The Sharper Image, Robert Redford's Sundance Catalog and the San Diego Padres, puts it even more bluntly. "I've had the fortune of being involved with a lot of high-profile commerce sites," said Staszak, "and I've never seen one [come in] on time."

In scenarios painfully familiar to all Dilbert fans, sales and marketing departments often propose Web-commerce applications and set the deadline back to yesterday. Then, as Staszak and other experienced developers will testify, development is often interrupted as marketing executives find new features they want to add to the site. This results in the dreaded "scope creep," which may be responsible for missed launch dates and cost overruns.

But real-world issues also play a factor, especially in the business-to-business arena. For example, major companies are now demanding that vendors have electronic invoicing as a condition of doing business. This is the kind of demand that gets the attention of CEOs and CFOs.

How can these demands be met? Can a traditional IT department quickly develop the skills needed to build a Web-commerce site suited to its company's needs? Or is it better to buy a turnkey Web-commerce product and hire consultants to handle its implementation?

In discussing build vs. buy at Spring Internet World 99, Jeetu Patel observed: "The technology is still immature. It's a confused market with lots of vendors and no clear leader."

Patel is vice president of research/CTO at Doculabs Inc., a Chicago-based industry analyst organization. The firm's recent study of major turnkey and tool vendors, including IBM and Microsoft, found no clear Internet technology leader. According to Patel, on a one-to-four scale, the best that most vendors achieved was a score of two-and-a-half.

Based on Doculabs' research, Patel offers the closest thing to a rule of thumb for IT departments planning Web-commerce sites. In the Internet version of the build vs. buy debate, he suggests that smaller companies can get on the Web with a turnkey solution as long as they are willing to mold their Web-commerce business to fit the technology a vendor offers. The disadvantage is that companies may have to wait for vendors to provide upgrades before they can get the features they want. For larger corporations with specialized Web-commerce needs, Patel suggests custom development as the only option that ensures an application will fully meet a firm's needs.

Scope creep happens

Once the decision to build has been made, Carl Salnoski, general manager of IBM's Net Commerce Group, suggests that Web-commerce development is not unlike any other build project.

"It all gets down to the project management of an IT project," Salnoski said. "It's making sure that you have the right project scope defined, the right skills, the right level of user involvement and commitment, and that you do a good job of managing the change control process.

"One of the temptations, particularly on the Web where everything is so public, is that marketing people have a tendency to change their minds frequently," he continued. "If you haven't done a good job up front of nailing down the requirements, establishing the basic scope of a project and then putting a good change control process in place, it's relatively easy to go in and make changes to the user interface and [so on]. You can very quickly end up with lots of scope creep."

Organizations that are unsure about their Web commerce plans face the worst nightmare, added Evergreen Internet's Staszak. "One of the most destructive patterns of behavior in these engagements is a customer who comes on board with a foggy notion and says, 'My boss said we needed to get on the Internet.' We [then] outline a six- to 10-week deployment cycle for a fairly significant commerce site," he said. "[But] I've seen, more times than not, where we are 25%, 50% or even 75% or 80% of the way through that cycle, and the customer says, 'Well, I just saw this neat thing and I want to do this instead.'"

Because requirements are basically a moving target in this type of situation, the result is a Web site pushed out of scope and over budget. The way to stop this kind of scope creep, suggests Staszak, is to first document the business rules for the application and get the requirements set.

"Typically, that's the longest phase of the project," he said. "It's the most difficult part because many times the bigger the company, the bigger the mess."

Gordon Steever is vice president of business development at ManTech Advanced Systems International, an Elk- ridge, Md.-based systems integrator doing Web commerce development. He agrees with Staszak that nailing down requirements is crucial to keep a project from getting out of hand.

"One of the things you have to do is to make sure you have hard requirements defined up front," said Steever. "We typically will go in [to a company] and come up with a business process reengineering [plan], which is a study that defines the requirements and the scope of the job. You build from that and your cost is driven by that."

Brad Goldberg, Visual C++ lead product manager at Microsoft, sees the growth in sales and marketing expectations for Web commerce as a natural evolution. "Originally, we just wanted to get a site up that described our products. But actually what we need is more of a fully integrated site that is going to be more com-
plicated and more full featured," said Goldberg. He asserts that scope creep happens "because e-commerce has grown in importance from the original planning phase when the project was spec'd."

ManTech's Steever argues that one way to prevent scope creep is to buy as much off-the-shelf software as possible and then hire a consultant to come in and take responsibility for doing the implementation within budget and on time.

"I've noticed that when companies turn to IT departments to do certain developments in-house, as opposed to going to an outside contractor, many times IT may lose some leverage," Steever said. "You can get a fixed-price bid out of a systems integrator to do development, and their risk is bound by that agreement. You don't typically have that kind of leverage when you are dealing with your own in-house IT resources."

Reality check

In the build vs. buy debate over Web-commerce development, most vendors, developers and consultants suggest that the situation is fuzzier than it might suggest. The best bet is to buy what suits your needs -- a commerce server, for example -- and build what you must have to meet the unique requirements of your organization.

However, a clear buy signal comes from Oracle co-founder Bruce Scott, who is now president and CEO of PointBase Inc. (formerly DataBahn), San Mateo, Calif. PointBase recently released a 100% Pure Java object-relational embedded database that is being used by companies like Evergreen Internet in Web commerce sites.

"I think we're emerging from the complete build paradigm, because that was what was available," said Scott. "Now we are going to have a build/buy where you buy some of the components and have to build the rest. I think that [situation] will evolve to complete buy solutions. If not this year, then by the end of 2000, you'll see total drop-in solutions."

But for those developers who are in the midst of building and enhancing Web commerce sites, the build vs. buy debate is not so clear-cut.

"Obviously, there are large infrastructure pieces that are required that we have no interest, experience, time or money to build," said Evergreen Internet's Staszak, who is a PointBase user. "When we look at implementing e-commerce presence, there are some core technologies that are pretty much must-haves."

Among the must-haves Staszak lists are middleware and a database that almost all organizations have, which can be used to provide pricing information and other e-commerce data. Evergreen, for example, has purchased CORBA-based middleware for its product. "That is something we would never attempt to build on our own," said Staszak. "There are people far smarter than us who do that very well."

In summarizing his take on build vs. buy, Staszak said, "We want to use off-the-shelf pieces that are proven and that are not in our core expertise and core competency."

Barry Walsh, director of university information systems at the University of Indiana in Bloomington, bases his skepticism on his experience building sites for college recruiting and online college bookstore sales.

"We're sort of going through what I would call the second incarnation of the build vs. buy exercise," he said. "Five or six years ago, like many organizations, we started to say, 'Well, we're going to buy everything; there's no need to build this stuff anymore.' That has turned out not to be as true as we would have liked it to be. The bottom line is that we want to differentiate ourselves from our competitors. It's very hard to differentiate yourself with commodity software. So we're feeling the need to augment and create value-added services on top of the standard products we're buying."

While building for customization, Walsh said there are some products and services it makes business sense to buy.
For example, all of the university's Web commerce applications are required to buy the services of an independent credit card payment processor.

"We are creating a plug-and-play facility we can hook into any merchant's Web site that will enable three-way processing," he explained. "We want to make it attractive for the merchant to be able to offer that ability to customers so they don't have to send in a check or call in a credit card over the phone lines.

"But we also want to make it incredibly secure from the payer's, customer's and university's perspective," added Walsh. "We're not interested in holding peoples' credit card numbers on our servers -- that's a liability nobody wants."

If an IT department opts to build all or part of a Web commerce application, Microsoft's Goldberg suggests working with tools the IT department already uses.

"Looking at the skills and capabilities you have in-house and finding the right way to leverage those skills, or using VARs or solution providers to supplement and add to what you have in-house, is probably a great way to go if you are focused on cost and a timeline," he said.

When asked about the confusion surrounding Web-commerce development, most vendors, analysts and developers seem to agree the big factor is that it is a brave new world in business computing.

"I put it down to nothing more than our inexperience," said the University of Indiana's Walsh. "None of us have been at this very long, and we're doing an awful lot of discovery along the way."

Vernon Tirey, president of Boston-based DiaLogos Inc., which provides consulting services for e-commerce development, agrees that inexperience is a key reason behind Web commerce deployment delays and failures.

"You have lots of different people working together on these projects, and everybody is going with their intuition," he asserted. "This on-the-job training is a gigantic reason for failure."

But Tirey suggests companies can buy expertise to build what they need. "All of your team can't be doing this for the first time; either hire somebody or go find consultants who have not just done it, but done it successfully."

Most   Popular