Mashups are seductive, thanks to their whizzy interfaces and lightweight development requirements. To creative developers, they constitute an open invitation to mix and match data and services in unexpected ways. But if you don’t think them through from an enterprise perspective, “mashups are no more than Happy Meal toys,” says Edmund Vazquez, manager of Web services integration and SOA implementation at Sprint Nextel.

Mashups hold strong appeal at Sprint as a way of bringing together services and data sources in ways for which they were not planned, using simple, familiar technologies. “They let you redirect existing resources rather than design a new application up front, providing a cheap way to get add-on value for your existing services,” Vazquez says.

Sprint’s control over mashups came naturally as part of a larger initiative. With its overall SOA plan, the company has defined a Web services platform and policies for using services as well as data within Web services, including mashups. “That gives us a leg up for the consumption of the services we deliver,” Vazquez says. “But it took us a year to develop the policies and platform.”

Without such effort, Vazquez sees mashups creating risk, delivering services that can’t be well supported, tarnishing hard-earned brand reputations, and disappointing business partners and customers. “If you use someone’s mashup service, they become your trusted business partner, whether you meant them to or not,” he says.

That’s why Sprint decided not to use any of the free map sources for dealer-location mashups. “They had no enterprise support model, they couldn’t guarantee reliability, and they had no product manager,” Vazquez recalls. Small businesses may be able to risk service outages and surprises such as unexpected ads in mashup content, because their transaction volume is low and mashups give them a cheap way to add peripheral features, Vazquez says, but enterprises must be more careful in how their brands, reputations, and service levels are affected.

Even for mashups designed to be used wholly within the enterprise, Vazquez argues for the same rigorous approval process applied to any other types of applications, no matter who develops them. “At some point, these mashups are going to interact with IT’s software and data,” he says. “They simply become an extension of your composite applications.”

Then the task for IT -- often in coordination with legal, finance, brand management, and other business groups --- boils down to everyday policy management questions such as who is authorized to develop mashups; which services and data sources may be used; how to handle policy violations; and so on. Fortunately for most companies with an organized approach to SOA, that approach fits nicely into the governance framework they’re already creating.