The Four Stages of Enterprise Architecture

It was 1999, and addressing any potential Y2K flaws in all of State Street’s computer systems consumed the giant financial services provider’s IT attention. But despite the tremendous focus on making sure that “00” would be interpreted as Y2000 rather than Y1900, David Saul, then systems software manager and Y2K remediation lead at State Street, realized something else. All the remediation projects were connected, and to ensure that any Y2K-related change in application A would not cause problems for application B, the project team needed to understand the relationships among applications and all of their inputs and outputs.

For example, State Street’s applications use reference data to process security transactions (the currency, the exchange on which the trade is made and so on). Because this data is used across all applications, it made sense to Saul’s team to handle it independently from the specific financial applications that drew upon it. At the time, most applications handled their own reference data, rather than relying on a separate, common service. Recognizing the value of common services, State Street formed an Office of Architecture (which Saul has headed ever since) to create the architectural environment for them. “It was a natural progression from there to delivering reference data as a service to today’s service-oriented architectures,” he says.

The SOA approach aligns software and data services directly with business processes so that specific services can be reused and mixed and matched as needed. That lowers technology development costs and improves the company’s ability to offer new or improved services to customers and supply chain partners.

And that’s all good. But even if an SOA is what your enterprise needs, you may not be ready to deploy one. That’s one conclusion from a pair of recent MIT Sloan Center for Information Systems Research (CISR) studies, “IT Architecture as Strategy” and “IT-Driven Strategic Choices,” both based on a series of research projects involving 456 enterprises between 1995 and 2006. The CISR research identified four distinct architectural stages—silos, standardized IT, standardized business processes, and business modularity—that both the business units and IT must pass through before SOA’s benefits can be fully realized. And no one gets to skip any stages. At best, you can speed up the process. For the CISR researchers, this conclusion was unexpected, says Jeanne W. Ross, the studies’ principal research scientist. “But when we tell people that, they say, ’Oh, that’s why it’s not going that well.’”

And because the vast majority of enterprises are in the first or second stage (and, again, they don’t get to skip), it will be years, perhaps decades, before SOA is widely adopted in an effective way, Ross says.

CISR’s research provides a road map for both the business and IT to follow so that they can avoid fruitless diversions, not get discouraged during the long haul and understand what success should look like when it’s finally achieved. Happily, Ross notes that each stage comes with its own benefits, so there are short-term returns on the long-term architectural investment.

Each stage takes about five years to get through, says Ross, though that period could shorten as more companies go through the process and learn what missteps to avoid. “Seven years ago, there were no architectural practices at the research firms,” notes State Street’s Saul. Today’s enterprises, he says, don’t have to feel their way as much.

The good news, according to Ross, is that your competitors are likely to be at or near the same architectural maturity level as you are, and they can’t leapfrog any stages either. Those that try to could waste time and effort deploying business processes and IT infrastructure that they’re not ready to use.

Rather than attempting great leaps forward, Ross suggests that CIOs should partner with the rest of the business to move their enterprise forward incrementally, gaining expertise, building buy-in and reaping the ROI that will sustain long-term maturity. Having the architectural maturity framework in mind during that evolution gives CIOs and their business peers a way to evaluate if they’re really progressing, she says.

The SOA Buzz

CIOs can’t avoid SOA today. Research firms and the business press trumpet its ability to make companies agile and efficient. Vendors apply the label, often speciously, to help sell their products. No matter where CIOs turn, they hear the same message: You must deploy an SOA—quickly—or be at a competitive disadvantage.

Indeed, there are advantages to adopting the SOA approach even if you’re not at the stage at which CISR says enterprises can reap its full benefits. “If you deploy SOA-based technology before your organization is ready, you might still get a more efficient integration system in IT,” says Ron Schmelzer, a senior analyst at SOA consultancy ZapThink. Implementing SOA concepts, even in a limited fashion like creating Web services, also “helps create a common vocabulary so the business and IT groups start moving in the same direction,” notes Judith Hurwitz, CEO of the consultancy Hurwitz & Associates.

But while you might reap some positives from a premature SOA deployment, says Jim McGrane, former CIO (now VP) of paper manufacturer MeadWestvaco, you might harvest some negatives too. “Flopping a Web services interface on a bad process just makes it more visible,” he says.

Understanding why your organization may not be ready for a complete SOA approach will help the CIO figure out what SOA-approach benefits can be gained at his organization’s current maturity level.

From Silos to Business Modularity

Even if they don’t know it, Ross says, most successful enterprises are moving through the maturity stages that CISR’s research has identified. Today, most companies are in Stage 2: standardized technology. Throughout the 1990s, it became clear that Stage 1—business silos with IT efforts focused on specific departmental needs—created a mountain of overhead and support requirements. That level of complexity, which came to characterize the early days of IT, could never support enterprise growth (not to mention the fact that it cost lots of money). This led most enterprises to adopt standard platform technologies wherever possible, using just one or two PC configurations, a standard database technology for all departments or the same type of hardware and OS for all servers.

The third stage, standardized business processes, is where many advanced enterprises are today. Here, the business is viewed holistically, and IT and business leaders see themselves as partners.

The fourth stage, which very few enterprises have entered to date, is business modularity. Here, business processes and their supporting technologies become modules that can be reused for efficiency and recombined for agility—the quintessential promise of SOA. Organizations know which processes should be local to specific business units and which should be standard across the enterprise—and the architecture supports the mix.

“Going from Stage 1 to 2 is not rocket science,” says McGrane. Although it requires real effort, the tactics and strategies for successful platform standardization are now well-known by vendors, consultants and IT staff. But “going from Stage 2 to 3 requires organizational change and business accountability,” McGrane says, “and that’s a lot harder.” And the move to Stage 4 is even more difficult. “It requires a redefinition of what you’re doing as a company,” he says.

Getting from Stage 1 to Stage 2 is mainly a job for the IT department, with the promised ROI of cost reduction. Moving to Stages 3 and 4, however, requires a fundamental shift in focus—from how IT can fulfill immediate and defined business unit needs to developing business processes that can be delivered through flexible, modular IT services, with the promised ROI of enterprise agility.

“The point is not just to manage costs but to shift the enterprise. If the CEO and CFO don’t understand this, you’re dead,” McGrane says.

Platform Sanity

In Stage 1, the pressure to move from silos to standardized platforms is easy for the CIO to identify. The business complains about escalating IT costs and longer delivery schedules as IT wrestles with the ever-increasing complexity of all the pieces it must manage and integrate. But standardizing an enterprise’s platform is not as simple as it may sound. The first step is deciding what exactly should be standardized.

“It makes sense to standardize at the network level, but it doesn’t make sense for a specific business area,” says State Street’s Saul. For example, a common storage network and e-mail system both reduce cost and improve information sharing. But traders working with stocks may need different application functions than traders working with derivatives, even if many of the underlying functions, such as client management and reporting, are the same. “Today, our enterprise architecture exists in layers, starting from things like the network, hardware and operating systems, and continuing up through middleware and databases until it reaches the applications. The differences across businesses may be quite slight and restricted to the application layer. The idea is to standardize on functions wherever possible but not to force-fit them at the business level. That way designers can concentrate on business services that give us an advantage while reusing core components,” Saul says.

The next issue is figuring out how to handle the change from the existing systems to the new standards. Not only must you actually transition your technology, you also must transition your users. And, Saul notes, you’re bound to come across noncompliant technologies that are doing an important job and doing it well. State Street started an architectural committee early in its standardization effort to address these issues. When resolving standardization priorities, the committee started with the business objectives, ensuring that IT didn’t inadvertently standardize away a business-critical technology. The committee approach planted the seeds for business-IT cooperation that would be needed in Stage 3 a few years later.

A more subtle issue in making the shift to Stage 3 is the human factor, says John Petrey, executive VP and CIO of TD Banknorth, a banking and insurance firm. Stage 1 businesses and their employees are focused (understandably) on solving their specific, individual problems. To problem-solvers, standardizing technologies may mean a loss of control and perhaps even a loss of optimal solutions. “It takes time for people to realize that to get the benefits everyone is after, you have to share more things,” Petrey notes.

Realistically, this cultural shift takes place in spurts. “You don’t wake up one day and it’s a different culture,” he says.

Companies also need a measure of resolve to succeed. Often, a crisis makes it clear why change is necessary. Other times, company leaders have the charisma or force of personality to effect the change. At TD Banknorth, Petrey implemented a ruthless approach to standardization for acquired companies. “We do rip and replace,” he says. That way, he says, platform heterogeneity can’t get a toehold in the organization.

Collaboration Time

As an organization gets its platforms standardized, the next logical place to look for efficiencies is business and IT processes. For example, chemical manufacturer Celanese saved about 40 percent of its IT costs through its four-year standardization and consolidation effort, notes CIO Karl Wachs, in which the company rolled seven data centers into one and 13 ERP systems into one. The consolidation began in Stage 2 as a platform effort and was completed in Stage 3, when the company could begin the business-process standardization needed to run the company on one ERP system.

Understanding business processes sufficiently to standardize them is no small feat, says Wachs. It requires intense collaboration between IT and the business. But the effort helps both groups understand that different business units use many of the same core processes. “Our base chemicals unit works differently than our plastics groups, for instance, so they have different sales processes and thus different implementations of CRM,” Wachs says. “But, in reality, they are different flavors of the same functionality, so we could put all the functions in one system and make them configurable for each of the business lines.”

To do the deep analysis required to come to these realizations, you need ongoing metrics, Wachs says. Without them, you can’t assure proper governance of your services, much less of your business processes. ZapThink’s Schmelzer points out that governance in this case means both the policies for specific business and IT processes and the system by which the enterprise decides how it creates and deploys its business and IT systems, such as architectural review requirements and funding priorities.

Moving from the second stage to the third can produce subtle benefits. At TD Banknorth, the business units needed more sophisticated products to compete. That required IT to keep improving its abilities and levels of sophistication. At the same time, cost pressures require the CIO to deliver these more sophisticated tools with the same level of resources. This pressure leads to an optimization approach, bringing the enterprise into the third architecture stage.

It is at this third stage that architecture begins to mean more than IT infrastructure. Data architecture, IT governance, Six Sigma process optimization and business-IT alignment become critical aspects of the enterprise architecture, with the focus of IT shifting from simply managing the technology plumbing efficiently to contributing to the business’s operational excellence. Efficiency remains important, but its goal has changed from saving money for the sake of reducing costs to freeing up resources that can be used to grow the business, says Petrey.

For example, TD Banknorth began paying much more attention to data architecture as it entered Stage 3. “You need to put real resources into evolving and planning it,” says Petrey. That involves ensuring standard definitions of data to make it easier for multiple systems to work with the same data and interpret it correctly, as well as to be able to glean patterns that help better serve customers.

TD Banknorth has designated IT staff who entrench themselves in the lines of business and act as relationship managers with their business colleagues to ensure true IT-business alignment.

Although TD Banknorth has standardized its technology platforms, it didn’t always enforce its architectural standards on the applications it bought or created. “It happened because of the rapid growth—we were most concerned with just getting something in,” recalls Petrey. “We’ve recognized that we committed these sins in the past and that it reduced our service levels and interfered with our ability to move the company forward.” Petrey is now working to make those architecturally deviant systems fit his new IT architecture, so TD Banknorth can continue to mature into Stage 4. And stricter governance is now in place to make sure it doesn’t happen again.

A focus on architecture can also lay the groundwork for future benefit, says Joe Solfaro, executive director of information management at pharmaceutical maker Merck. Much of the company’s IT efforts are focused on standardizing its platforms, but it’s also mapping its business processes and data architecture so it can be more agile once it has a more cost-effective platform on which to operate. The company began two separate data-standardization efforts several years ago but more recently brought in enterprise architects to develop a common data architecture to underlie both. “Even if the systems have tactical differences, they’ll still support the same strategic direction,” he says. That means easier data management that will ultimately support a full-blown, Stage 4 SOA.

Culturally, Stage 3 requires both IT and business staff to let go. “You have to stop being tactical. You need to trust others to manage the details,” Petrey says. Some of that shift occurs in moving from Stage 1 to Stage 2, but in Stage 3 the letting go is more difficult because now very different types of people—IT and business—must depend on and trust each other. And as with the change from Stage 1 to Stage 2, the shift to Stage 3 happens over time as the organization sees the ROI of the new approach and buys into the transformation.

Business Modularity

Very few enterprises are at Stage 4. They account for just 6 percent of the roughly 450 companies CISR surveyed.

Still, CIOs in the latter part of Stage 3 can already see how Stage 4 might look. At Celanese, CIO Wachs says parts of his organization are in Stage 4, focusing on modular processes that can be easily managed within an enterprisewide architecture. “Companies can be agile only if they can turn specific functions on and off,” Wachs asserts, and that requires understanding what the functions are, where they are used and what they affect. That in turn requires having an architecture designed for both flexibility and consistency, he says.

State Street also believes it is in the beginning of Stage 4, says Saul. “We know we’ll have to get the IT people better at understanding business processes and at communication,” he says. “The lines between IT and business are blurring,” he continues, “and it’s clear that someone will have to manage both.” For some companies, that means IT may become part of a shared-services effort. (For more on the role the CIO will play in this type of organizational structure, see “EA Changes Everything.”)

Less clear is what a mature Stage 4 organization will be, what it will look like, says MeadWestvaco’s McGrane. “The understanding of how to use IT for agility and game-changing things versus incremental improvements is just starting,” he notes. And he’s not sure the enabling technologies are really there yet. One thing McGrane is sure of: “You can’t move to Stage 4 until the entire enterprise has achieved Stage 3, because Stage 3 sets up the process orientation necessary to view the enterprise as modules, as Stage 4 requires.”

A Journey, Not a Place

While it’s tempting to think of each stage as a place to arrive at, a truer way to see it is as a transformative process with the enterprise gradually transitioning from one stage to another, CISR’s Ross says. That’s because the volume of change is immense, and more important, people must change along with the technology. (For more on managing change, see “The New Science of Change.”) That’s why CIOs should promote incremental deployments and promise incremental value, both to ease the impact of change and to nurture management’s enthusiasm for the effort, says Celanese’s Wachs.

In fact, because of the legacy of mergers, different levels of business need and buy-in, or external forces such as regulation, companies often find that they’re in different stages simultaneously. For example, at Celanese, the HR system is still in Stage 2 because of payroll requirements, while other parts of the company are entering Stage 4, says Wachs.

No matter the pressure to improve enterprise efficiency and agility—Today! If not sooner!—companies, unlike the X-Men, cannot leap over stages in their evolution, says CISR’s Ross. Each stage lays the technological, procedural, cultural and behavioral foundation for the next. The impossibility of skipping stages holds true even in companies where one entity is ahead of the others. For example, in 2002 McGrane considered Mead to be at Stage 3, but then the company merged with Westvaco, which was at Stage 1. As CIO of the new MeadWestvaco, McGrane had to bring the newly acquired parts of the company through Stage 2 before moving them to Stage 3. Now, the unified organization is moving closer to the same maturity level.

Enterprises should also understand that architecture is never done, says ZapThink analyst Schmelzer. “The idea is to continuously adjust the service—not necessarily the implementation—such as composing two finer-grained services into a more composite one or vice versa,” he says. Typically, CIOs don’t have those skills, so they should have a chief architect or architecture team reporting to them, Schmelzer advises.

However an enterprise manages its architectural evolution, it must remember that the journey is the reward. Says CISR’s Ross, “The end point is much less important than the continuous improvement you gain. You need to get a little better every day. It’s not about how to get to Stage 4.”

Galen Gruman is a frequent contributor to CIO.