For British American Tobacco (BAT), SOA success came early. The challenge now lies in determining how quickly SOA should be scaled across the enterprise, and for which functions.
The company's SOA journey began with a pilot project to build a Web services-based dashboard that could extract real-time metrics information from legacy systems. The success of that pilot convinced those involved that SOA could be the catalyst to move BAT's IT away from siloed implementations to an agile, supply-and-demand organization, says Gavin Targonski, global systems architect at BAT.
For a company like BAT, however, with more than 300 products in 180 markets and 90,000 employees worldwide, such a transformation would be a tough challenge. For one thing, BAT had more than 1,000 IBM Lotus Domino applications, and many of its developers were more versed in Domino than Web services, .Net, or J2EE.
"We needed a way to make our existing development teams productive in SOA from the word go, allowing them to develop and consume Web services as, and when, they needed to," Targonski says.
The right toolset came in the form of Skyway Software's Integrated Service Management platform -- now known as Skyway SOA Platform. Its Builder module provided developers with a model-driven, codeless development environment that could automatically generate standard J2EE Web services.
"Skyway embeds an SOA approach in the core of their tools," Targonski says. "The ways in which objects are exposed and externalized to the runtime are already SOA-enabled, so developers can build SOA apps without having to think about all those issues, such as what SOA means and how to do it. It makes SOA a no-brainer."
Skyway's product also provides SOA governance and service management tools. Rounding out BAT's SOA infrastructure are an application router from Cast Iron Systems, which provides the standards-based back-end integration platform, and Network Director switches and servers from Blue Titan, which provide Web service routing, mediation, and management.
Early successes have demonstrated the value of SOA to BAT's business. Now SOA's proponents within the company are in the process of getting the news out to the development teams and business units, including providing a reference implementation to make SOA development an accepted practice in the organization. According to Targonski, that can't happen fast enough.
"We need to get better at getting the good news out more quickly. It's easy to forget the value we're adding because of the speed in which we're developing applications, providing prototypes, and approaching new business requirements with a different perspective," Targonski says.
Targonski also points out that with such quick development cycles it's important to get a handle on how far SOA should go -- and how quickly. "Do we charge on or make sure the operational aspects are in line first? We decided we have to be certain that what we create is supportable and maintainable and that we can manage services from birth to death. It's easy to forget the guys who have to support this stuff and make the datacenter work," he says.
One side effect of scaling SOA has been that BAT's IT organization has had to start reinventing itself. "All of a sudden, you don't have a database guy, a network guy, and a mainframe guy all working on their own," Targonski says. "All their skill sets have to be pulled together because a Web service has so many different touch points to make it work. You really need the right human resources and skills deployed."
For all these reasons, BAT has been developing additional services carefully, targeting key projects to drive SOA and forcing developers to deliver on ROI statements. Some of these initiatives have included transitioning BAT's global messaging backbone from IBM MQSeries to SOA messaging standards and building a new finance application with a Web services-based UI.
Targonski says that it has also been important to make sure BAT's SOA approach is moving in step with that of its largest technology suppliers, such as SAP, and vice versa. "You've got to be cognizant that if you leave existing implementations behind, you're not necessarily delivering real value," he advises. "Evolution, not revolution."