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 Centre 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.