The Four Stages of Enterprise Architecture

An exclusive MIT survey maps the evolution of IT architecture and explains why you can't skip any steps.

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.

1 2 Page 1
Page 1 of 2
7 secrets of successful remote IT teams