The State of Enterprise Architecture in 2001

Not so long ago, enterprise architecture was the loser at any business mixer: big, unwieldy, unyielding and nearly always out-of-date. Heck, architecture wasn’t even invited to the three-year rave party hosted by Y2K, Nasdaq and the letter e. But when the nightclub door finally opened and corporate America staggered out, wincing in the daylight and fresh out of cash, there was architecture, looking better than it had in years.

While the tech party is over for now, CIOs are re-embracing the corporate standardized platforms and applications that compose enterprise architecture as a way to contain costs and ensure business alignment. But this time around, the focus is on flexibility. As companies struggle to regain control but retain enough vision to accommodate the next big thing, some are building an architecture that’s rock steady on the bottom with quite a bit of play on top. Think of a well-built skyscraper with upper floors that intentionally sway in the wind.

That design may give some CIOs vertigo, but not David Watson, a longtime IT executive who has served as corporate vice president of technology at several Fortune 500 companies. Though Watson puts his foot down?hard?when it comes to choosing IP protocols, networking operating systems and cabling, he’s willing to give ground at the database/hardware/OS level and, at the top, is perfectly happy to support a fairly wide range of business applications?provided, of course, they return strategic value.

“We are quite rigid at the bottom of the hierarchy, and that actually improves our ability to flex in the upper tiers,” says Watson, now CIO at Enfrastructure, an Aliso Viejo, Calif., startup offering outsourced infrastructure and facilities to other companies. “You have to have an architecture, and it has to be flexible, but some parts should be less flexible than others.”

Keeping a Loose Hold

If enterprise architecture developed a bad reputation in the past couple of years among business users, it was well deserved at least some of the time, according to Peter Weill, director of the MIT Center for Information Systems Research in Cambridge, Mass. “Architecture was presented as a standards issue at a very technical level. [CIOs] took a one-size-fits-all approach that was driven by best practices in IT, which was the worst approach,” Weill says. Architecture should indeed be driven by best practices, he notes?but in business, not technology.

For Watson, that means focusing attention and spending resources on the task-specific, sometimes customized applications that drive particular business units, including best-of-business front ends, Web enablement and custom XML development. “The application decision should always be predicated on business requirements,” Watson says, “but if someone’s proposing a solution that requires a different level of support, you should have the ability to do it.”

Underneath that level, Watson feels it makes sense to try to standardize the basic communications tools to be used throughout the enterprise?e-mail, voice mail, group communications software, office productivity packages, OSs and browsers. At the very bottom, the company’s infrastructure should be set in something pretty close to stone. “This is where you want to drive the bulk of your efficiencies. This is where it pays to be consistent across the enterprise,” Watson says.

Andrew Winer, CIO at Myers Industries, a rubber and plastics manufacturer in Akron, Ohio, agrees that it makes sense to lavish attention on high-end applications and be willing to give and take in that arena. “We’re much more concerned about applications than the lower-level architecture,” he says. Overall, Winer characterizes Myers Industries’ list of approved products as perhaps looser than a traditional standardized list. “We try to pick and choose things where we already have some level of expertise, but our list is broad. The nature of open architecture allows you to be somewhat flexible.”

Good Timing

Perhaps the concept of a flexible architecture had to wait for the technology to catch up to it. Thanks to new standards and off-the-shelf programs that at least try to coexist with the competition, CIOs can give business units much more latitude than in the past when it comes to choosing networking and operating systems, applications, and communications tools.

Where previously every rogue database or niche e-mail system threatened to create another stovepipe, now most programs work together with some fine-tuning (provided, of course, the underlying infrastructure is solid). “Our hottest area of interest right now is application-to-application integration,” says Bill Rosser, a vice president and research director at Stamford, Conn.-based analyst group Gartner. “We have whole conferences on that topic alone.”

A higher degree of interoperability means companies don’t have to dismantle otherwise acceptable legacy systems to achieve application cohesion. “We have a little bit of everything and there are good reasons we have it, and it all works together,” says Roy Swackhamer, CIO at CNF, a holding company headquartered in Palo Alto, Calif. “In today’s open, heterogeneous environment, the danger of backing yourself into a corner is minimized.”

The emergence of the Web interface in corporate America lets companies tie applications together at the top rather than having to hard-wire them in underlying layers. For example, Myers Industries has standardized on the Computer Associates’ CA Unicenter enterprise-management system and uses that company’s Bizworks tool to achieve interoperability at the Web level. “We try to develop as much as possible at that corporate level,” says Winer. “The Web allows us to put a layer on top of all our applications and communicate to underlying applications from there.”

What Sways, What Stays?

Even the best laid plans need to accommodate exceptions, particularly exceptions that might one day become the new norm, or the bedrock of a new architecture. “If the marketing department says, ’I need a website in 12 weeks,’” says Gartner’s Rosser, “IT needs to be able to respond to that.” He goes so far as to advise IT managers to think of architecture as two different sets of guidelines for two different situations. “There’s the systematic back-end stuff and the opportunistic stuff. You need a different set of rules for the opportunities.” An opportunistic architecture, for example, may have different quality-assurance strictures or less formal configuration-management requirements. “And when the ad hoc systems succeed,” Rosser says, “you’ll need to be able to plug them back into your systems.”

How companies decide just which projects will be the exceptions is determined by the organization’s corporate culture, budget, degree of technological investment and how centralized or decentralized IT is.

On the cautious end of the scale are companies such as Denver-based Johns Manville International, where CIO Chan Pollock spends significant resources developing and maintaining the company’s architecture. Two dedicated employees maintain and update the various standards, which are reviewed and approved by business development executives, then publicized for all to see via the company’s intranet. In return for that level of attention, Pollock and his staff expect that exceptions will be kept to the barest minimum.

“We’re not a company that has a lot of high-tech aspirations,” Pollock says of the building-materials company. “We’re a process manufacturer. So we’re pretty dictatorial about what we’re going to deploy and why. We have a strong preference for buying over building, and just about everything out there supports our needs. Occasionally something comes along that’s outside the ballpark, but if it fits into our business requirements we’ll figure out a way to accommodate it.”

CNF’s Swackhamer focuses his architecture efforts on gaining cost efficiencies and leaves functionality decisions up to the CIOs of each division. If a business unit in one of the four companies wants software outside of its architecture, managers must make a business case for why they want the alternate product, and their CIO needs to approve the petition and bring it forward to the CEO.

Enfrastructure’s Watson adopts a stance halfway between tenderness and tough love. On the one hand, he’s the first to acknowledge that the pace of technological change can require some pretty sharp deviations from the master plan, however well crafted that may be. “The Internet’s a great example of that,” he points out. On the other hand, Watson, like Swackhamer, insists that would-be deviators do the math and show their work before they get a pass to play hooky from the stated architecture plan. “I advise them of the other ways they can get what they want using the existing architecture,” he says. “If they still want to go on, they have to use a standard five-year discounted cash-flow model to make their case.”

Socrates and Business Value

Watson and Swackhamer aren’t alone in turning to the calculator when times get tight. Indeed, business users and IT executives alike will need to sharpen their accounting skills as they negotiate upcoming technology investments. “In the next year at least, we’re going to see architecture based strictly on numbers,” says Barry Lovalvo, CTO at Armeta Financial, a Dallas startup that provides enterprise software solutions for open finance. “The [finance] people are sitting down with a hangover right now. They’re doing a Sunday morning ’Oh my gosh, what have we done here?’ routine.”

The point behind discounted cash flow and other economic exercises isn’t to wield ironfisted control over unruly users. It’s to ensure that off-list projects are on target with corporate goals. CIOs are unanimous in saying that, this time around, business alignment is the primary litmus test for IT expenditures.

“I start by asking, ’What does the business case need that the current architecture can’t deliver?’” Watson says. “If someone asks for Internet sales rather than brick-and- mortar, we don’t say, ’How do we stop this.’ We say, ’That’s an interesting business discussion; we may have to adapt and see where it goes.’”

That type of dialogue isn’t an adjunct to architecture: It should be the architecture, says Richard Buchanan, vice president of enterprise architecture strategies at Meta Group, a research company in Stamford, Conn. “Architecture isn’t a thing; it’s a process. The architecture team is the steward of the logic that describes the value of any investment in business strategic terms.”

In practical terms, Buchanan says, CIOs should require business units to enunciate a typical cost-benefit analysis for any new technology investment. On the benefit side, that means determining how an application will help a company gain market share from its competitors, for example. On the cost side, that means factoring in not just purchase and maintenance price, but the price of added complexity or the cost of not being able to adapt as rapidly, says Buchanan.

“When someone says, ’I need this application or this infrastructure capability,’ you need to force them through a Socratic dialogue,” Buchanan says. “They need to tell the whole story: ’I need this application because I need this information because I need to support this business strategy because otherwise our business goal won’t be achievable.’”

If engaging would-be architecture anarchists in a Socratic dialogue sounds like a far cry from presiding over dusty three-ring binders filled with outdated product lists, that’s the way it should be, Buchanan says. “Enterprise architecture has no value in and of itself,” he points out. “All of the work that’s done has to be linked to business strategic goals. That’s the job of the CIO.”