Life Sciences Manufacturing

Promise of Service Oriented Architecture

Daniel R Matlis,  President, Axendia, USA.

Service oriented architecture promises to revolutionise the way companies share information internally, as well as with partners, customers and regulators.

For more than three decades, life sciences manufacturers have been implementing shop floor data acquisition systems to automate their manufacturing processes and systems with the goal of increasing quality and lowering costs.

As part of automation projects such as Computer Integrated Manufacturing (CIM), Supervisory Control and Data Acquisition (SCADA) and Statistical Process Control (SPC), life sciences companies began to rollout computer workstations on the shop floor. The data storage capabilities afforded by personal workstations on the floor often lead to an unforeseen side effect; the creation of “Data Islands”.

“Data Islands” are created when manufacturing equipment is connected to a computer and begins collecting historical information and process data. Although computers have made it to the shop floor, the bridges required to connect them—including networks and integration technology—will take some time to catch up. Until recently, data islands were connected by “island-hoppers” (Figure 1). The process involves getting data into a system by walking it over to the next data island in the process and manually entering it.

Ever since the earliest SCADA system implementation, pharmaceutical manufacturers have attempted to make this production information, processes and resources more transparent with varying levels of success. Further, companies have always looked for better ways to integrate operational data to allow stakeholders to make timely and informed decisions. The phrase often used is getting to the “Single Version of the Truth”.

Can you handle the truth?

There is an iconic scene in the movie “A Few Good Men”. Lt. Daniel Kaffee (played by Tom Cruise) questions Col. Nathan R. Jessep (played by Jack Nicholson).
Jessep : You want answers?
Kaffee : I think I’m entitled to them.
Jessep : You want answers?
Kaffee : I want the truth!
Jessep : You can’t handle the truth!

The fact is that in some cases life sciences companies may not be ready to handle the truth. This is not due to an unwillingness to get to the truth, but because in some cases facts can turn an accepted practice on its head.

The enlightenment of truth requires organisations to surrender to the process of discovery and analysis. Tools such as Multivariate Analysis and Manufacturing Intelligence allow manufacturers to sift through the terabytes of historical data accumulated over the last thirty plus years to transform it into information, knowledge, wisdom and ultimately truth.

Only after life sciences firms have assessed the facts regarding the current and desired states of their manufacturing processes, can they embark on the next step of the journey, selecting the best technology to enable the change.

Want to buy a “Bridge”

Today, software manufacturers are moving away from proprietary systems and interfaces and are working together to develop open standards and interoperability schemas. Known as Service-Oriented Architecture (SOA), this functional design provides a bridge that allows for the connection of data islands in an efficient and effective manner.

Harmonisation

In traditional system architectures, software systems are stacked to meet a particular department's need. By contrast, SOA is composed of clearly defined business functions or services, which are loosely coupled and highly interoperable. The interaction of these services is independent of their operational platform and programming language. The interface standards hide vendor proprietary and technology-specific implementation (such as Java and .NET) allowing for smooth and reusable services.

Functionally, SOA transforms stand-alone systems and their data islands into "services" that can be accessed with a common connector or bridge, regardless of the location or technical makeup of the system. The functionality and capabilities of these connectors ranges from simple data passing to complete orchestration of multiple services and escalation capabilities based on the rule anthologies required to meet a particular business activity.

SOA implementation is a process, not a project

For SOA implementations to be effective in allowing the business to reach new heights, functions must be well defined, self-contained and must be aware of the context and state of other services. Today, web services use SOAs to achieve the loosely coupled yet robust connections (Figure 2).

Service-Oriented Architecture(SOA) Web ServicesThe use of SOA has led to development of standards such as Business Process Execution Language (BPEL), which takes the service concept one step farther by providing a method of defining and supporting workflow and business processes.

The journey to successful SOA implementations begins with specific and clearly defined business requirements and process maps. Business needs—not technology—must drive this process. The journey requires IT departments to undergo a significant shift from their mantra to “align IT with the business” to the reality that IT must “support the needs of the business”.

Another key step in the process is to evaluate the current IT portfolio. This step seeks to identify and eliminate applications developed as stop-gap measures to address a business need that was not provided by commercial off-the-shelf software. Historically, “pop-up” applications have been critical to running the business and releasing quality products to the market. How many organisations still rely on spreadsheets and home grown Access databases to perform final product release? One key drawback to “pop-up” applications is the increase in IT support and operational costs due to their adhoc and uncoordinated nature.

To enable the implementation of SOA, software companies have developed open standards and are moving their products away from proprietary interfaces that resulted in difficult-to-support applications. While the pharmaceutical companies have tolerated proprietary systems in the past, to meet the industry’s changing needs, leading software providers must be able to interface with—and acquire data from—other systems in real time. They must also have the ability to share and analyse raw data and transform it into actionable business information. As pharmaceutical companies become more global the need for integrated environments compels the next generation IT solutions to be designed and built to be part of a SOA.

Bridging to the future

Today, IT organisations play an intricate role in technology decisions at all levels within a pharmaceutical company. This is evident by the consolidation of historically separate R&D, Finance and Automation IT groups into a single Corporate IT organisation spanning all disciplines. This has lead to a more efficient use of IT resources. To take full advantage of this “organisational integration architecture”, companies must implement SOA infrastructure to eliminate redundant systems and data. Finally, to facilitate regulatory requirements compliance, pharmaceutical manufacturers define and identify authoritative sources of data across the organisation to minimise compliance risks by controlling and providing visibility into relevant processes.

The SOA in automation and manufacturing applications requires the development of an integration and intelligence infrastructure that eliminates the traditional application stack model, where point solutions are piled on each other to increase functionality, and transforms it into a collaborative interoperable one based on industry standards. The use of SOA increases situational awareness in today’s ever shifting global and outsourced operations. The implementation of SOA allows license holders to communicate with contract manufacturers, raw materials suppliers and supply chain and logistics managers instantaneously and cost effectively by building bridges between systems of record. This eliminates the need to build custom interfaces with every system and, thereby minimising system compliance and validation costs.

Although SOA promises to revolutionise the way companies share information internally, as well as with partners, customers and regulators, technology can only enable change not drive it. For change to be effective and accepted, it must be rooted on the drive to provide better products that enhance patient health, on sound business practices, and in compliance with applicable regulatory requirements.

Author Bio

Daniel R Matlis
TOP