Q. What advice do you have for drug makers in meeting the regulatory requirements?

'Be ahead of the curve' is the best advice we could give the industry. If possible, work with regulatory bodies to understand key regulatory initiatives that are in progress and the potential impact of these regulations on the real world. Attempt to influence the regulations by positive collaborative efforts across the industry. Undertake research and development efforts to implement (or simulate), in a small laboratory environment, regulatory compliance before regulations are enacted.

Technology

Standards adoption is the most challenging aspect of integration projects. If two technologies adopt open standards, integration becomes a nonissue. On the other hand, if two proprietary standards-based technologies need to be integrated, the result is expensive and complex integration. Oracle is doing its part to enable low-cost integration by basing its integration platform (Oracle Fusion Middleware) on open standards. Similarly, our application integration architecture (AIA), an open, standards-based platform for business process management across Oracle, third-party and custom applications make it easy to integrate our products with others.

Q. What integration issues do you see up and coming in all type of industries, and any specific challenges in the pharmaceutical industry?

The traditional point-to-point integration model has outlived its utility. In most industries, chief information officers are asking us for a hub-based integration framework that can incorporate an enterprise-wide common object model. Such an architecture makes it easy to plug and play applications over time, without undertaking massive integration projects. Pharmaceutical companies are beginning to adopt this model as well and are trying to understand the impact of regulatory constraints on the adoption of such models.

Q. What are the top three applications that are typically interfaced with your products? And what are the challenges in interfacing with applications with different languages (character sets)?

1. Factory-level shop floor (such as process control and process scheduling applications)

2. Statistical packages for highly advanced and specific data analysis

3. Third-party (legacy) business intelligence products. As long as all these applications accept unicode characters, integration with these applications should not be an issue. However, some applications are less "internationally robust" than others, and unique character sets, such as the Japanese character set, can pose a problem.

Q. Some companies face challenges in integrating MES (Manufacturing Execution Systems) to Enterprise Resource Planning (ERP) applications. What is your company doing to help ease this integration?

Oracle is adopting the S95 standard aggressively and using this standard to guide our AIA strategy and approach, where appropriate.

Q. Do you have any thoughts on virtualization (e.g., virtual servers) and the impact of this to your business and to the pharmaceutical industry?

[A few years ago, Oracle introduced] real application clusters, which support the deployment of a single database across a cluster of servers—providing strong fault tolerance, performance, and scalability. We aggressively promote the virtualization of an application environment through the implementation of machine clusters. This drastically lowers the cost of ownership, as a group of several smaller machines is often a small fraction of the cost of a much larger machine, and the risk of failure of a cluster is infinitesimal, as well. The adoption of this approach by the industry has been a strong validation of our commitment to lower total cost of ownership for our customers.

Q. Do you outsource application development outside the US? Do you have any comments on the trend toward outsourcing?

Oracle has software development teams in several countries around the world. We have aggressively embraced globalization as a key option for attracting the required talent to fuel our research and development engine. However, we do not typically call this outsourcing, as software development is undertaken by Oracle employees in these countries who are trained on our methodologies and standards and are subject to extremely stringent hiring criteria. So, we leverage a global pool of talent without having to outsource a key business function.