InformationWeek

Applications: Architecture Without Texture

HP advocates 'just enough' architecture--but how much is enough?

By John Tibbetts and Barbara Bernstein
Issue column appeared: Sept. 11, 1995

Five years ago, every self-respecting systems vendor was pushing its own architecture, a structured software framework designed to lead customers into a future of open, interchangeable components.

Each featured stacks of blocks representing open standards, generic components, available products, and, frequently, pieces of "futureware" that would magically interface the pieces that didn't quite yet interoperate. Jockeying for pos ition were IBM's Systems Application Architecture, Digital Equipment's Network Application Support, Microsoft's Windows Open Services Architecture, and Hewlett-Packard's New Wave Architecture, among others.

Today, we have to add an extension to most of these terms--R.I.P. The conclusions from the autopsies have much in common. Too early. Too proprietary. Impossibly high vapor-to-content ratio. Set in stone while the computing world was in flux.

Perhaps the most morbid factor is that the notion of architecture makes no sense to the people who have driven our industry in the past several years: users of PCs and small networks.

To organizations using simple, isolated applications or single-vendor solutions, elaborate frameworks for interoperability standards seemed too academic.

Just Enough Architecture?
Since then, isolated applications and vendor dependence have shown their limits. As medium-size and even small organizations join larger enterprises in looking for ways to integrate te chnologies and legacy systems, some vendors have rediscovered architecture as a marketing tool.

IBM recovered from the SAA fiasco with Open Blueprint, a model based on open standards. Microsoft has weighed in with an architecture built around its Object Linking and Embedding technology. HP, meanwhile, has taken a service approach aimed at providing users with "just enough architecture" for their particular needs.

On the face of it, HP's approach sounds the most intriguing. "We don't draw boxes," says an HP executive, adding that block diagrams tend to saddle customers with more architecture than they want or need. HP says it discusses architecture as a springboard to customer solutions, but it has learned that "no one size fits all." Who could argue?

But does just enough architecture do the job? One purpose of an architecture is to provide for future, unforeseen uses of applications components built today. We now live with a generation of intractable legacy applications that were architected "jus t enough" to get the immediate job done. The architectural excess that HP seeks to avoid helps make software adaptable and durable.

Ironically, HP's own products--SoftBench, Distributed Smalltalk, and OpenView--are extremely well architected, both for the present and future. HP may not be drawing boxes for its customers, but someone is drawing them inside the company, and HP's product architecture is stronger for it. The company clearly believes in the value of architecture but prefers not to talk much about it.

HP has seen vendor initiatives come and go, including a few of its own. It may realize that the market has grown impatient with architectural frameworks and that block diagrams give critics a handy checklist of what the vendor hasn't completed. The risks are great and the rewards uncertain, so it seems HP has decided to keep a low profile in this area.

It's a pragmatic approach, if not an inspirational one. In this area, where lofty ambitions have gotten some of the biggest names in the i ndustry into trouble, a low profile has its attractions.

Comments on this story?

InformationWeek http://techweb.cmp.com/iwk