April 06, 2001, 5:56 PM — How do you eat an elephant? One bite at a time. You create a scalable Web architecture in the same way: by dividing your Web systems into well-thought-out components so you can add capacity where needed without bringing down the entire structure, say users and analysts.
"Design big and build small," says Larry Kinder, senior vice president and CIO at Cendant Corp., a financial and travel services company in New York. That means "functionally isolating" the databases, business rules and interfaces where applications meet, so components can be modified or scaled up as needed, he says.
For example, Kinder says, "we literally built a wall around our mainframe applications, our old legacy stuff, and as we build new applications, we can turn off old functionality on the mainframe" and transfer those functions to more easily scalable, smaller servers.
Scott Mitchell, chief technology officer at HSN.com, the online subsidiary of Home Shopping Network Inc. in St. Petersburg, Fla., wanted to be able to "scale out but not scale up," he says. "Rather than having to swap out a server and buy a more expensive server, I just wanted to be able to add a server to my [existing] cluster."
In the past year, Mitchell's server farm has grown from four to 10 dual-processor Web servers accessing two four-way database servers running Microsoft Corp.'s SQL Server 2000. Since 10 servers is about the limit on which he can comfortably perform load-balancing and data replication, Mitchell says that as traffic increases, he'll create new farms at new locations, which will give him "an infinite amount of scalability."
Some IT managers are addressing these scalability issues by dividing key systems into components, determining what those components should look like based on the needs of the business, and building the architecture out of those components on a "pay-as-you-go" basis.
The Component Mind-set
A component is simply a chunk of software that performs work or provides information within a wider application. A component could be the user interface on an order entry system, the rules for how and when to increase a customer's credit limit, or a data warehouse detailing every customer transaction conducted during the past five years.
According to several IT managers and analysts, to build a scalable Web architecture, managers should think of components not in terms of the software on which they're based but in terms of the services they provide.
During his tenure at Garden City, N.Y.-based Avis Group Holdings Inc., which Cendent acquired last month, Kinder says, "we needed to find a way to give our clients access to their data and to their accounts online," without having to connect the Web server to 50 legacy databases.
In this case, the core component was a data warehouse holding the crucial data and business rules that had been replicated from legacy databases. Whenever more users or applications needed the data and the business rules, Kinder could expand the data warehouse without having to significantly change the mainframe databases from which the warehouse drew its data.
EBlast Ventures LLC, a Chicago-based venture capital and professional services firm, created a reusable component in the form of a catalog engine. The catalog lists different types of children's soap with different toys inside each bar, says CTO Bruce Weiner.
"WWhen I sell that on the Web, parents are going to want to select from a variety of different soaps and a variety of different toys," he says. "I don't know what combinations parents are going to want." But using San Jose-based BEA Systems Inc.'s WebLogic tools, says Weiner, "I can write a cataloging engine which lets me list all the pieces of soap and all the toys and the rules for putting them together and let the customer tell me how to put them together."
Creating these application components once and having them available for reuse in future applications is far less expensive than rebuilding the capabilities on every new e-commerce platform a business adopts and every legacy system a Web application must access.
But designing components correctly requires that they contain enough of the right business-critical details to be useful while being generic enough to be reused across applications.
Some components, like those that handle credit card payments, can be defined in extreme detail, says Weiner. For example, for the transaction required to complete a credit card payment over the Web, he says, his developers used WebLogic "to define the rules on how to use that specific component" across multiple applications.
