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.
"When 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.
The steps needed to complete a credit card transaction are well known. But, says Weiner, in the cataloging system, it's impossible to know beforehand factors such as exactly how they'll be priced or displayed in the catalog. For applications like this one, the key is defining and enforcing very rigid rules about how each component is built. "I can write a catalog which handles an infinite number of SKUs, without knowing what is in each [SKU listing]," as long as each component in the catalog system treats each stock-keeping unit field the same way, such as requiring the same number of characters in the field, he says.
Another key is to properly split applications into tiers: often, one tier for the user interface, another for the application logic (business rules) and a third for the data.
Managing the Layers
The e-commerce applications that scale the best are those that have only the proper functions in each tier and require as little interaction as possible among the tiers, says John Steensen, CTO at Intira Corp., a Pleasanton, Calif.-based Web hosting firm. That way, it's relatively easy to add more processing power to the layer that's becoming overloaded as user demands increase.
If much of the business logic is written into the database, for example, "all of a sudden, you have a database which can't handle all the transactions being thrown at it from the application layer," says Steensen. That slows overall application performance and can obscure the real nature of the problem.
"By breaking your business into three layers, you can add hardware against each one" as needed, says Weiner.
Putting much of its business logic in the middle tier helped HSN.com reuse more of those middle-tier components as it scaled from 325,000 unique visitors in January last year to 2.3 million in December, says Mitchell.
For example, the company developed one component to deliver online coupons that "we developed once and used everywhere throughout our site," says Mitchell. "If we hadn't . . . we would have to rewrite [that] code in every page on our site."
Just about every company must link its Web applications to back-end inventory, accounting and billing systems. Often, as in the case of Avis, these systems are mainframe applications that weren't designed with three-tier architectures in mind, much less the Web, but are far too expensive to scrap and rewrite.
The answer, according to several Web architects, is what Weiner calls "wrappering" these older systems in a software layer such as XML that sits between the legacy application and the Web, allowing the two environments to communicate. This surround-and-conquer approach lets Weiner add more Web servers as needed that can cleanly access the existing mainframe application via XML.
Doing this extra planning upfront adds costs that developers and business managers must weigh against the need to get new applications up and running quickly.
"I'm glad . . . we really locked into a data architecture" that supported Avis' eventual move to a data warehouse, but "it was tough," says Kinder. It cost an additional 10% to 15% per application to get information out of the companywide data warehouse than it would have to simply build another single-application stovepipe into a legacy database.
Successful Web architects take a pay-as-you-go approach. Every IT project has to produce a well-defined business benefit, says Kinder, as well as "build towards the target architecture, even in a small way."
Just as IT managers have learned the problems that come with incompatible stovepipe systems, they're also learning that a scalable Web architecture exists for only one reason: to make money. Or, as Mitchell says, "Keep it simple, stupid. Solve the business [problem] and service the customer, rather than feeding the technology monster."
Scheier is a freelance writer in Boylston, Mass. Contact him at RScheier@charter.net.
|