Needs-based architectures

Enterprises must provide different levels of service to different users according to need and assign the right resources dynamically

Say goodbye to one-size-fits-all architectures -- the old days of just giving users their apportioned slice of “the system” are long gone. As financial pressures force IT departments to act more like internal service businesses, architectures are by necessity becoming more responsive to the fast-changing needs and service-level requirements of multiple segments of users.

“It’s the idea of IT as a service company and needs-based, service-level management that needs to get built into the architecture,” explains Gartner Vice President Jeff Schulman. “We’re saying, think about what’s really driving the need for architecture in your organization right now. What are the business needs?”

The übertrend in application design, SOA, has made serving disparate sets of needs easier in some senses because application functionality can be accessed using standard protocols, rather than having to be built from scratch. On the other hand, it’s very difficult to spec out an SOA with the current and future needs of all stakeholder in mind.

CareGroup and Harvard Medical School CIO John Halamka echoes this advice, citing numerous examples where his company’s IT architecture was designed to support varying service levels based on internal customer needs.

“We were one of the earliest adopters of information lifecycle management,” Halamka says, noting that the company’s 85-plus terabytes of data are stored on a tiered storage architecture based on the data object’s point in the lifecycle and value to end-users.

Halamka also points out that CareGroup’s wireless infrastructure was designed to support four very different classes of users. Physicians get the highest speed and most secure service for clinical results and ordering. Patients use the same network but with a different security model. And the network supports two other applications: VoIP over wireless and RFID for geolocation of people and assets, each with their own distinct service levels.

“What I’ve done is looked at the needs and then architected those systems to serve those differing levels of needs,” Halamka says. “You’ve got to take a hierarchical view; you can’t deliver the absolute highest level of service and quality across the board because our capital budgets are limited.”

Taking this approach to the extreme, some enterprises have designed systems that allow them to fine-tune service levels to highly specific segments of internal users or external customers. Charles Schwab, for example, has developed an architecture that allows it to provide segmented levels of service to its online customers, according to Willy Chiu, vice president of high-performance on-demand solutions at IBM.

“You do get a better page response the more money you have in your account,” Chiu says. “Before the market opens, for example, they cache the top 500 users.” Such segmentation is typically policy-driven and can be done dynamically. “This is differentiation of service, class of service; what the business side has been talking about all this time,” Chiu notes. “But in the old days, the IT guys said, ‘We have no way of doing this.’ ”

For internal users, such segmentation is often role-based and requires an architecture that can support policy-setting and rules engines, as well as usage monitoring and charge backs, according to Chiu. On the back end, such systems require flexibility -- the ability to expand or contract based on demand or to shift loads dynamically to provide the right service levels to the right users as seamlessly as possible.

Where will this all lead? Gartner’s Schulman predicts the ascendancy of what he calls “good-enough” architectures -- architectures that are constantly changing to meet the shifting needs of internal and external customers, in contrast to the old days of monolithic moon-launch style architectural planning.

“We’re saying don’t go there. … Architectures must be built to change, not to last,” Schulman advises. “Understand what’s driving it, build out enough that you can understand it and then modify it. Get something on the board, build out an ROI, and then come back.”