N-tier at your own risk - multi-level architecture for component-based development - includes table of products and related article on ActiveX and components - Technology Information

Software Magazine, Dec, 1996 by Colleen Frye

The blueprint is designed to help Andersen Consulting clients who are "making choices at early stages," says Moldauer. "The approach provides a standard way of building systems so choices can evolve over time. We're using a standard approach for how to break down the structure for building components. If a tool changes, the worst thing that happens is people need to learn a new syntax.

KPMG's Lord also emphasizes a flexible infrastructure to clients. "People are approaching the distributed object world out of necessity. We're suggesting they adopt the most flexible infrastructure environment to build and deploy their solutions, so the architecture will support components when they are available. The reality is components aren't commercially available."

Both Lord and Moldauer stress that the upfront work of building this flexible environment is time-consuming. Andersen's Eagle team both built and used components in its architecture during its three-year development effort. "There certainly is upfront work," says Moldauer. "We invested '91 to '94 to build libraries of reusable assets." However, he adds, now that the investment in the architecture has been made, "the first system was not a big investment because we had already made [the investment]. The development time was at least as good as, if not better than, traditional. At the same time you're creating many more function points, so it's a more rich application getting built."

"You do not build n-tier architectures in a RAD [rapid application development] fashion," adds Lord. "These paradigms take significant time upfront to plan and design. " Organizations moving toward a component-based, n-tier architecture need to balance their long-term development goals with short-term business needs, says Lord. "The problem with physically building an application from the component perspective is you've got to invest more design time upfront to create something that's an abstraction. Some organizations are willing to do that, others are only willing to a certain degree. They have to balance how much they want to invest upfront vs. the return downstream. There are conscious decisions made to compromise. That doesn't mean you don't get the extensibility and reusability; you just don't get it to the ultimate degree. But you get a huge improvement in maintenance and extensibility." Connie Baker, product development manager at May & Speh, a direct marketing firm in Downers Grove, Ill., agrees with this approach. "Most organizations will not finance that upfront time to do component development through and through. You have to develop a hybrid system, and architect it well so you can go back and identify areas where you could utilize a component," she says.

"I don't believe that there are a lot of domains out there where you can create reusable components right off the bat," Baker adds. "The way to get to a higher level of reuse inside your own code is to hire somebody who has an outstanding architecture, develop frameworks, and start plugging in components on top of the framework."