The architectural focus of Comcast’s SOA effort has helped the concept be applied more widely than if viewed merely as a technology issue, Adler believes. For example, because Comcast didn’t start with the view that SOA means the use of Web services, the company has applied the SOA concept to all its efforts, not just those that are obviously Web-enabled. “A Web service is just one way to expose a service – it’s just an implementation detail,” he says. One result is that much of the initial internal SOA efforts were in fact directed at the legacy applications, reducing the integration points both within and outside the company (such as with billing vendors), a major pain point for the business.

Developers use a variety of tools and programming languages, for example, as best fit their knowledge and the application they are creating. By standardizing processes and policies instead of specific tools and technical methods, Adler says developers can better adhere to the architecture’s intent rather than trying to shoehorn each effort into the limitations or assumptions of a specific tool or technology. There’s also a practical reason to allow technological heterogeneity under the common architecture, he notes: In a 90,000-person company, it would be unrealistic to get everyone on the same methodology.”

A company of that scale must also adjust to changing business needs and technology opportunities, Adler says. It’s important to revisit the reference architecture periodically so that it doesn’t become a straitjacket or a document that everyone ignores; either way, you would lose the benefits of SOA. Adler revisits the architecture each month, though it is changed less often than that.

Leapfrog keeps its SOA options open with open source
It’s the classic problem faced by IT developers everywhere: Applications developed during the year by different groups just don’t work well together when brought into a common system such as a Web portal. The dilemma hit home for Leapfrog Enterprises in early 2007 when the toy company wanted to deliver its various applications in a consistent way to suppliers and customers alike, wanting to take better advantage of Internet-based commerce and transactions. In March, it decided it needed a new way to develop applications, so it began an SOA effort whose first efforts are now bearing fruit, says Eugene Ciurana, the director of systems infrastructure. “We wanted to lay the foundation for Web infrastructure and systems, so we stated with a clean slate,” he says.

Leapfrog had many of the same goals that typify a typical SOA initiative: greater reuse of code, faster development time, and easier integration. But the company did not want to approach SOA as simply a changing of the guard for development tools and integration platforms. Instead, it wanted to free its developers from conforming to a platform’s idea of best practices so that they could focus on the applications’ functionality and use a wide range of development technologies as best for each job. (Leapfrog’s developers use a mélange of Java 5 and 6, Microsoft’s C#, and Web services with various third-party libraries.)

For example, Ciurana did not want to force developers to all use the same transport. “The transport doesn’t matter,” he says. He chose to use the open source Mule ESB as a messaging backbone, relying on it to deal with transport interfaces. That way, “developers could focus as little as possible on the implementation of services,” he explains. Instead, their focus is on the functionality they are trying to achieve. The result is that developers tend to use HTTP as their transport mechanism, but some use REST (Representational State Transfer) and SOAP -- “whatever works best or they’re most comfortable in,” he says. With the Mule ESB’s approach, “they don’t need to worry about what’s in a specific SOAP stack or what IDE they’re using.” Ciurana had previously used Mule at Walmart.com, so he was convinced it was the right basis for Leapfrog’s “clean slate” efforts.