SmithKline Beecham Integrates Applications with MQSeries
Global Messaging System Makes it Possible for Leading Pharmaceutical Manufacturer to Place Orders Anytime from AnywhereWith operations in over 160 countries and annual sales in excess of $13 billion, SmithKline Beecham ranks as one of the world's leading healthcare companies. Makers of a vast array of pharmaceuticals, vaccines, over-the-counter medicines, and health-related consumer products-from Aquafresh toothpaste to the popular Nicoderm CQ smoking cessation aide-it falls in the category of not only a major business and manufacturing enterprise, but one that is subject to strict regulatory controls as well. If a product is recalled, for example, the company must be able to provide a detailed accounting of where and when the item was manufactured, where it was shipped to and on what date, its batch number, and its current location in the supply chain. Accurate and reliable information access is especially important for this type of request, but it is also important in tracking inventory levels, forecasting market demand, and processing orders. With an eye on handling these and other information requests more efficiently, SmithKline Beecham recently implemented a standardized global messaging system, based on IBM's MQSeries messaging middleware.
"MQSeries allows us to have a single infrastructure worldwide, with a standard set of messages that everybody can use. It doesn't matter where the message is coming from, or where it's going to-the process is now going to be the same for everybody," explains Chris Jones, Director of Global Messaging.
Jones' group is part of SmithKline's Global Information Resources organization, which is responsible for overseeing the company's implementation of enterprise-wide applications and systems, and for providing the expertise and resources needed to create, deliver, and support systems which require a high degree of integration across applications. These range from accounting and ERP (Enterprise Resource Planning) systems, to forecasting and financial transfers between sites.
SmithKline Beecham currently uses SSA's BPCS application software for manufacturing, JD Edwards software for financial accounting and commercial order purchasing, and a locally available Windows-based application for financial forecasting. These applications are supported across a wide range of hardware platforms including approximately 100 IBM AS/400 systems, 100 Windows NT systems, and about 30 DEC VAX/VMS servers.
Until recently, these applications and systems were integrated only to a limited extent. In some cases, local interfaces were built to handle specific kinds of requests, or a custom interface or network connection was sometimes developed if a sales operation and a factory had a significant amount of activity between them. Otherwise, information throughout the company was typically exchanged through faxes and e-mails.
In early 1997, however, in the midst of efforts to make its legacy systems Y2K-compliant, Jones thought, "Why not take this opportunity to establish an integrated, standardized transaction processing system, worldwide?" and the work on a centralized ordering and processing system began.
As a result of these efforts, the company has since integrated a number of its applications. Its first project involved linking DEC Alpha systems running quality assurance (QA) systems for testing raw materials and products to an IBM AS/400 system running BPCS manufacturing software. "This integration was critical in ensuring efficient factory operations," says Jones. "For example, when raw material is delivered to a factory, it must be tested. However, the factory operations might be waiting for that material, which can't be used until it is released from the BPCS inventory control system. Using global messaging in the factories ensures that the message is passed to BPCS as soon as the results are complete," explains Jones. The material is then released for processing, minimizing unnecessary delays.
To accomplish this, Jones group added code to the VAX system (Beckman LIMS) so that it generates a message and posts it to the message routing hub as soon as the data is available. The hub then passes the message to the AS/400 running BPCS and additional code instructs it to pick up the message and enter the data into BPCS. Usually this occurs at the local site, however, some sites are supported by remote BPCS systems. "This demonstrates another key benefit of the infrastructure that we have built," explains Jones. "We can move any of the systems from one site to another, or consolidate them into a data center without having to make any changes to the systems that they link with. All that is required is that the message routing information is kept up to date," says Jones.
Why Messaging?
"When we first started, we had a business reengineering initiative to improve and integrate our supply chains," explains Jones. At the same time, the team was working against year 2000 timing constraints, which meant it had less than 15 months to update systems that had grown up slowly over the past 15 years. "Clearly, it wasn't going to be possible to rebuild all of those point to point interfaces-we simply didn't have the time-so we looked for tools that would support a generalized approach and that would enable us to develop standardized processes from a business reengineering side," offers Jones.
When they began investigating the technology available that would support an integrated cross-application, cross-platform solution, they considered both traditional EDI (Electronic Data Interchange) techniques and messaging. Traditional EDI was discarded because it didn't provide real-time information flow or the range of transactions the company needed. Messaging-with its support for asynchronous data flow (the ability to release data in a time-independent manner), platform independence, and flexibility in handling both standard and custom applications-offered a foundation for solving the problem within a single infrastructure.
Why MQSeries?
Once the team decided to use a messaging approach, they looked at several alternatives. In addition to MQSeries, they also considered DEC MessageQ, and object brokering technology. "DEC MessageQ basically would have required us to use MQSeries to bridge across the DEC platforms to get to the AS/400s, so we figured if we had to use MQSeries anyway, we might as well use it globally," explains Jones. "The object brokering technology was interesting, but it wasn't proven-there weren't any case histories that we could go to for reference, and again, with the short timeframe and the regulatory requirements, we wanted to make sure that we had something that was fairly robust," he adds.
"In the end, MQ Series was really the only viable solution for us, but we're happy with the choice, because it had a good reputation then, and still does-and moreover, all the testing we've done has proven that it can handle our needs very well," says Jones.
Implementation
During the early stages of development, Jones' group was aided by Logica, an IBM BESTeam partner that had extensive experience with MQSeries implementations. "Logica helped us to jumpstart the project," explains Jones. "They brought strong project management skills and technical expertise to the effort, and we defined the business requirements," says Jones. At the peak of the project, there were approximately 30 people involved-but nearly half that number were responsible for testing and validation because of the regulatory requirements imposed by the pharmaceutical industry. That left approximately 15 people on the development side, and they were essentially divided into two groups. One group was responsible for the message handling development, and a second group worked to engineer system management tools into the hub so that the entire implementation could be run directly from the data center in Philadelphia.
When a message comes in from MQSeries, the hub checks the message, determines which channel to send it off on, and then sends it off-and as part of that process it does all the integrity checking and all of the backup to make sure the message doesn't get lost along the way. MQ Series has proven to be especially reliable in this regard. "We just processed our millionth production message," says Jones, "and we haven't lost a message yet!"
Technically, MQSeries resides on the hub, and every application platform addresses all outgoing messages to its designated hub (usually that would be either a regional hub for a small site or a local hub on the local LAN for a large site), explains Jones. MQSeries then passes the message on to Century Analysis Inc.'s (CAI) TDM software, which examines the message, references the routing tables to determine the route for that address and then posts the message on through the appropriate MQSeries queue for that destination.
The message routing works in a hierarchical way, so if the hub has the destination connected to it then it posts the message directly onto the queue for that destination. If the message is for another destination, then the hub passes the message up one level. "For example," explains Jones, "if the message were for another system on the same site, the local hub would know and would pass the message straight to that system-otherwise the message would be passed up to the regional hub. If the destination is located on another site supported by the regional hub, then the message is sent back down to that site. If the destination site is not supported by that particular regional hub, then it is passed up to the global hub and from there is sent back down to the appropriate regional hub. If the message cannot be delivered, it ends up in a special queue on the global hub and the operations staff resolves the issue.
At this stage, the implementation for processing orders involves some fairly simple transactions. "There are essentially three major transactions-one is a requirements or purchase order transaction, (so that no matter where you are, if you need to place an order to the factory, there are standardized purchase orders available); there's a confirmation that comes back from the factory to the market agreeing to that order; and then there's a shipping note," explains Jones.
Overall, the objective on this project was to establish uniform procedures for placing orders, moving product around the globe, forecasting, and handling regulatory registration. With the MQSeries infrastructure now in place, the real challenge is taking advantage of it for other information processing requirements as well, according to Jones. "The overwhelming imperative to do it on a global basis was the whole ordering cycle," explains Jones. "But once the infrastructure is there, you discover that there are a million other things that you can do with it," he adds.
"From an MQSeries technology point of view, the software has done everything that we hoped it would do, and more," says Jones. "Admittedly, there's lots of examples where others may be handling more messages than we are, but we haven't met anybody who has actually gone out and deployed this type of technology across such a large geographic region," says Jones. "We had roughly 200 systems in more than 100 locations around the world to integrate," explains Jones. "And, although not all of these sites are functioning at full operational loads, we have tested the basic MQSeries components across all 200 systems," explains Jones. By this time next year, says Jones, the company expects the system to be operating at 100 percent operational load.