Sprint rationalizes its infrastructure with SOA

As far back as four years ago, Sprint’s IT staff was already headed toward SOA (service-oriented architecture). They just didn’t know it yet.

When developers first began exposing Sprint’s back-end systems as reusable components, the concept of Web services was still largely unproven. Previously, they had connected the company’s departments, customers, and partners to its mainframe systems through a series of stand-alone Web sites and b-to-b interfaces. For one of the U.S.’s largest telecom providers, with a customer base of more than 10,000 companies, such a one-off approach wouldn’t be sustainable for long, however.

Four years ago, the local phone-service business unit began developing Java applications for such basic functions as log-in and password reset, as well as customer tasks such as service ordering and account updates. Seeing the wisdom in this modular approach, other business units quickly followed suit. Unfortunately, multiple, parallel Web-services development efforts resulted. Sprint developers were creating the same modules over and over again, often without knowing it, wasting development time and dollars.

“We had lots of different platforms and technologies as each design progressed for its line of business and customer requirements,” recalls Edmund Vazquez, Web services program manager for the enterprise-focused Sprint Business Services (SBS) unit. “Often, core functionality was projectized. There was no incentive for reuse of core infrastructure assets or components.”

To rationalize its Web services deployments, SBS decided to create a common architecture to provide a framework for identifying, developing, and managing its services. A solid SOA underpinning would let SBS break services down to reusable components that would reduce overall development efforts, although it would also requires a clear understanding of business needs and the services required to meet them.

Click for larger view.

To manage the SOA and the services developed on it, SBS created two distinct IT groups. One focuses on the overall architecture and strategy, while the other concerns itself with service development and integration. This ensures that the architecture is maintained and applied consistently while still allowing development teams to focus on their specific business-logic areas.

Of course, the transition didn’t happen overnight. According to Vazquez, it didn’t have to. “One of the nice things about SOA adoption is that adoption, implementation, and deployments can be incremental as long as you keep your eye on the bigger picture,” he says.

Building for manageability

Architecturally, SBS defines three kinds of services: atomic, aggregate, and composite. Atomic services might expose a single API and are usually transactional in nature. Aggregate services may involve calling sequences of atomic services, much like one Java class calling other classes. Composite services, on the other hand, require orchestration or choreography.