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.’"