Risk and Compliance

By Howard Baldwin

In the early days of middleware and enterprise application integration, I used to joke that a chief information officer (CIO) could spend months integrating all the systems in a company that needed to exchange data. The day the job was finished, the CIO could proudly lean back with a sigh of achievement. And at that moment, the chief executive would walk in with news of a new acquisition whose systems needed to be integrated.

These days, there's a new challenge with the same punch line: compliance. The day you achieve compliance for Basel II in the European Union or for the Financial Instruments and Exchange Law in Japan is not the end. The chief financial officer, the chief operating officer, or even your chief compliance officer is bound to bring you news that there's a new government regulation or industry guideline or customer service-level agreement with which you need to comply.

"Enterprises have multiple compliance initiatives that they have to manage," says Alonzo Ellis, a principal with Capgemini's financial services practice, "whether it's for external reasons, such as Sarbanes-Oxley, or internal reasons, such as ISO [International Organization for Standards] or Six Sigma programs. They're all trying to figure out the right way to build an architecture that allows them to maintain compliance with rules that seem to come as frequently as every six months." Put another way: It's a never-ending task.

How do you accommodate changes on an ongoing basis? It's not an easy task, because compliance has two sides. First, you have to comply; then, you have to prove your compliance through auditing and reporting. Technology can help, but it's not a panacea. Experts agree that to start building an architecture that's flexible, you need to think about how to:

• Accommodate both companywide compliance (horizontal) and industry-specific (vertical) requirements
• Check periodically for—and eliminate or consolidate—outdated or duplicative hardware and software
• Incorporate open architecture standards, such as federated systems, referential databases, and service-oriented architecture (SOA)

Think Differently About Compliance

Consultants stress that when it comes to designing a compliance-friendly architecture, it helps to think about compliance differently. "Everyone acts like compliance came with Sarbanes-Oxley," says Phil Bloodworth, an IT effectiveness leader at PricewaterhouseCoopers (PWC). "It should be an integral part of how you manage your business." After all, if a customer places an order and you promise to deliver it within 48 hours, you need a way to determine whether you complied with that promise.

David Ritter concurs. Ritter, a vice-president and director at the Boston Computer Group, says that forward-thinking companies are thinking about compliance as a way to achieve agility (not unlike using Y2K as an opportunity to deploy new hardware). Where companies go wrong is in thinking of compliance directives as a static set of requirements. But frequently, he admits, companies don't have the time to rethink their architecture toward building an ideal that will meet the requirements of today's directive and tomorrow's as well. His recommendation: start by thinking about reducing complexity.

Reducing complexity is important because compliance requirements come in so many varieties. They may span your organization horizontally (such as the business-process requirements at the heart of Sarbanes-Oxley) or represent a vertical, industry-specific application, such as the automotive industry's Transportation Recall Enhancement, Accountability, and Documentation Act. In any case, there are only four fundamental elements to compliance. Put simply, you must:

• Capture data about events
• Manage rules about workflows, whether preventive or investigative
• Have a reporting capability, through messaging or Web services
• Retain data for auditing purposes

The key, according to many consultants, is to avoid point solutions—which solve only one problem—and think instead about solutions that are extensible, reusable, and adaptable for tomorrow's compliance requirements.

Deal with Legacy Issues

How do you create an architecture that promotes flexibility? Unfortunately, almost no one can start from scratch, so you have to do two things: look at the architecture you have now, and think about how it should change.

To look at your current architecture, Boston Consulting Group's Ritter recommends a two-phased approach. Start with the part of the architecture that IT controls directly. How many combinations of hardware and software do you currently support? How many different messaging or network systems do you have? Consolidate them.

For instance, at the 2006 Shared Insight's Enterprise Architecture conference, Eric Karsten, senior manager for enterprise engineering at Ford Motor Company, told how Ford didn't have an enterprise architecture until 2001. Before that, individual development teams could deploy technology without applying standard architecture principles. The result was a significant increase in company complexity. Ford eventually pared its architecture down to a half-dozen archetypes. "By reducing complexity," Ritter says, "you achieve flexibility because you have an infrastructure that's more predictable, more scalable, and less fragile."

The second phase is to standardize information with what's known in IT as "master data management." It's a perennial challenge—and one whose advantages can be hard to explain to the business side—but there are some famous examples. Aircraft manufacturer Boeing once offered airlines their choice of 107 shades of white. Consumer packaged goods manufacturer Procter & Gamble once discovered it had 42 different formulas to create the color blue. It eventually reduced that to four formulas and, by doing so, reduced its time-to-market on some products from nine months to three. Because IT manages all that information, it's incumbent on CIOs to show the business the benefit of simplification.

Is Service-Oriented Architecture the Answer?

The last step is to think about the architecture you'd like to have in the future, remembering that compliance is a journey, not a destination. It's not necessary to retrofit everything you have, insists PWC's Bloodworth. But if you eliminate applications and streamline business processes based on an established design philosophy, you'll be heading in the right direction. Bloodworth also recommends that you avoid hard coding of data and that you move to referential databases so that information can be changed more easily. "You're changing one piece of data that's referenced many times," he says. It's similar to the way an airline's yield management system changes seat prices based on a number of external factors.

Keep in mind that while most consultants believe that Web services and the related service-oriented architecture are important, they are not a panacea. "SOA is just the latest generation of the discussion that's been going on since fourth-generation languages were going to allow business analysts who didn't know programming to script logic on top of the existing IT infrastructure," Ritter says with a chuckle. Even though SOA is better than deploying point solutions, he says, relying on SOA to give you agility in and of itself is "dangerous."

Still, it does have a key role in the transition of your architecture from past to future. Dan Carroll, managing director of IT strategy and planning for the consulting firm Keane, recommends exposing the functions you've already invested in—in those legacy systems—as using the Web Services Description Language. "Figure out what services you want to expose and begin to build hooks" between the old capabilities and the SOA you're beginning to build.

The Road to Greater Flexibility

One of the reasons consultants warn about overreliance on SOA is that it's simply an approach to something bigger. Carroll insists, "It's a key foundation to the more important concept of business process management. To do that well, you need the SOA underpinnings."

Why? Because at its most fundamental, compliance is nothing more than a business process: Did you do what you said you were going to? Can you prove it? Did you ship the package? Did you process the financial transaction?

The ability to rapidly respond to compliance is the same as the ability to rapidly respond to new business pressures. In the past, the corporate response would be to build a new application. "That's time-consuming," says Carroll. "CIOs need to solve the problem through configuration, rather than by creating new software." If you have Web services components that can replicate that application, only in more flexible ways, and fulfill the four key activities—capture, management, reporting, and retention—you're on your way to an architecture that can accommodate almost any kind of change.