Name: Tony Owen
Position: Director of marketing, software and informatics business, Life Sciences Solutions, Agilent Technologies, 2008 to present
Background: Marketing manager, liquid phase separations products, Life Sciences Solutions, Agilent Technologies, 2004 to 2008; lab-on-a-chip marketing manager, Pharmaceutical Solutions, Agilent, 2001 to 2004; PhD, chemistry, University of Manchester Institute of Science and Technology, 1976
At Pittcon held last week in Chicago, Agilent Technologies' Tony Owen held an invitation-only meeting to talk about forming an industry-wide group aimed at developing open standards for chromatography instrument control software.
The meeting, attended by about 30 people from various companies with businesses in liquid and gas chromatography, was held to try to address growing customer frustration being heard by vendors about the limited connectivity between instruments and software.
Historically, instruments and software have been packaged together where the software controlled the instruments. But as customers are now buying different instruments from different manufacturers — such as an LC from one vendor and a mass spec from another — they are demanding control of the instruments, Owen said at the meeting.
As a way to remedy this, some software makers have begun making drivers for third-party instruments, but the time to deliver the drivers is too long, Owens said. Additionally, drivers for some instruments remain unavailable.
A number of ideas were discussed last week on how to develop the standards, including different models a prospective group could use, but nothing has yet been decided. Among these options is for the members to form their own self-funded association, join an existing association as a sub-group, or create a loose association with no funding model.
In the months ahead, Owen and others who have taken the lead on the effort will be forming a steering committee to decide how to proceed with the initiative. Those interested in learning more about or who want to participate in the initiative can contact Owen at [email protected]
ProteoMonitor discussed the effort to create the group and standards with Owen. Below is an edited version of a conversation.
Tell me about the initiative. What are you trying to do and why?
We are trying to set this up as an independent initiative, independent of Agilent specifically. We want it to be cross-industry. Obviously, the initiative comes out of the needs and requirements that we are seeing as a company, but we don't want this to be just an Agilent-driven activity, because … having had discussions with other companies, we see this as something which many companies are interested in.
Somebody had to start it, if you like, so that was a reason we thought Pittcon was a good opportunity just to get companies together.
I've been in the business a long time. I've been on the instrument side [for] quite a long time. I've been on the software side recently. I've also been involved [in] talking with partners, either with direct partners or with competitors when it comes to instrument controls in the software environment.
There are two reasons for looking at some kind of standardization between instruments and software in a multi-vendor environment. And one is customers are looking more and more for multi-vendor control. They are tending to settle on one software platform for a laboratory, and want to use that one software platform to control different vendors' instruments.
And that need, that requirement is increasing. We're seeing increasing requirements from our customers, either for our software to control other people's instruments or our instruments to be controlled by other people's software.
This is a trend from a customer's point of view, and customers want to see good solutions.
If you look at it from a manufacturer's point of view, the way we do it today is inefficient for us and is not delivering good solutions to the customers. The reason it's inefficient for us is traditionally the way it's been done … we talk to other suppliers on a bilateral level type of relationship and typically share or exchange codes for the instruments.
[ pagebreak ]
That means the software manufacturer then has to sit down and write a piece of software to control the instrument based upon the control codes supplied.
For, let's say, a common liquid chromatograph like ours, we will write a driver for our own software, then company A will write another driver, company B will write another driver, company C [will write] another driver, and suddenly we've got five drivers written by different companies, and each one of them is a little bit different, but each one does basically does the same thing.
We're effectively reinventing the wheel over and over again. And it takes time, and money, and resources. In the end, the customer is the one who suffers because of delays in availability of the drivers, and then the customer is paying the cost for the same driver to be written multiple times.
It seemed to me that it would be advisable for everybody in the industry … to see if we could come to a way to find some standard for communicating between instruments and software …The idea as we're proposing, is the instrument manufacturer writes a driver and then through the standards, the driver plugs into other people's software in a fairly straightforward way.
So the driver gets written once, and the customer gets that driver quickly and with the same functionality independent of the software environment that they're using the instrument in.
Why not just leave it to market forces? If there is customer frustration over this, won't companies like Agilent at some point say, 'We need to address this,' and develop these standards and interoperability on their own without an association spearheading the effort?
Obviously, we are developing standards on our own … internally. We have multiple software packages. We have a mass spectroscopy package, and historically we've written separate drivers for each of those softwares. That's not efficient for us, so we're moving to a standard internally.
But in the end, we have a standard, Waters has a standard, Dionex has a standard, and the standards are not compatible with each other, so we're moving to internal efficiencies but we're not achieving the real multi-vendor efficiencies that we need.
And one option is to take one of these standards and let the market forces decide which one of them is going to be the industry standard, but that could take a long time, and there'll be a lot of walls along the way.
And we thought that maybe there's an opportunity at the moment to accelerate things by forming an association.
I'm not guaranteeing that this is going to work. I feel that the conditions are right. Before the meeting last week at Pittcon, I had talked with other companies to find out if there was general interest in doing this because there would have been no point in calling this meeting if I'd already talked to half a dozen companies and they all said, 'No.'
And all companies are basically seeing the same things. It isn't efficient for us as Agilent to be writing drivers for Waters' instruments or Dionex's instruments, for Shimadzu, and everybody else's. We would rather be using these resources on developing our software and differentiating our software, rather than writing another driver for another third-party instrument.
But we know our customers want that control. It's a paradox, and it seems like an association could be the best way to solve that, rather than staying with the kind of bilateral agreements that we have today, which … work, but there is a lot of work involved to keep all of these bilateral agreements up to date and going.
So the companies have told you they're interested? It wasn't clear to me that the people who were at the meeting were there representing themselves or their firms.
I haven't talked to all the companies that were there, but I've had communications with a few companies and yes, the companies are supporting it. The individuals that were there were expressing the opinions of their companies.
[ pagebreak ]
One of the things I'm trying to do this week is just to get all of the names [sorted], I collected about 30 business cards … I need to put together a way to communicate to those people without transferring all of their personal information around.
As I mentioned at the meeting, there are two or three different options how we could go forward. One, we can actually form a new association, or we can use an existing organization, maybe ASTM, or … there's an organization, OPC [open connectivity via open standards] that's already on something similar for the process-control industry. Maybe they could take it on.
I just heard today there's a group, a customer group [that] has been looking at standardization for automation.
So I think there are various options on the table. The outcome of the meeting last week was to form a steering committee of about eight people from large and small companies. We will get together and then sort through the different options and make a recommendation.
What is OPC?
OPC is a foundation that was formed by companies in the process-control industry … because I believe they had the problem that they were all making measurement devices for process control — pressure, temperature, and so on.
The way they were communicating that information was different, so to put together a complete process control system was obviously difficult. … and they faced this problem 10 years ago that I'm describing now for our world, and the companies decided they should find a solution to it, so they formed the foundation, and they agreed upon some standards.
That means somebody who's putting together a process-control system can take instruments from different suppliers and plug them in and they all talk the same language.
You say this is the right time because customers are asking for this. Is this also the right time because adoption of chromatography technology has reached critical mass? I'm thinking specifically of HPLC in proteomics, which is increasingly supplanting gel-based techniques in protein-separation work.
Yes. … I think technology is moving on, so you're seeing more and more adoption of HPLC and actually electrophoresis, by the way. The things that we talked about for chromatography can easily be applied to electrophoresis instruments.
Plus the software technology is moving on, so there are standards, like the .NET standards, or .NET technology from Microsoft, which many of the instrument manufacturers are adopting as a basis for their communications standards.
So, in a sense, because there are technology developments, the instrument companies are individually moving toward standards, which are actually closer together maybe than we were in the past. If we're moving anywhere closer together, maybe we can take that extra step and agree on a standard.
When you say standards, what kind of standards are you hoping to set?
I'm not a software person, but the way that a driver talks to software, they have to communicate certain parameters in the same language, and to some extent, with the same units.
For example … let's take flow rates, some people will communicate in milliliters per minute. Other companies will communicate flow rates in microliters per minute. Now obviously, if you have a driver that communicates in microliters per minute [and] you plug it into software that communicates in milliliters per minute, your flow rates are all over the place because one says it's 2,000 microliters per minute, the other takes a number and thinks it's in milliliters per minute.
[ pagebreak ]
It can be actually fairly trivial things that we agree on, the ways of communicating, for example, flow rates, and the unit which is involved so the software can understand what is actually being communicated. It's not just a number.
There's obviously, on the technical level, more on the way the numbers get moved around. There's XML technology today [that] allows you to have a core set of numbers but we are able to extend that with a dictionary of other elements.
There's a dictionary of words [that] describes things you communicate like flow rates, wave lengths, and so on. And if we're all using a different dictionary, then we can't talk to each other.
It's those kinds of things we're coming to an agreement on — the dictionary of how particular things are described … at least a dictionary of ways to translate from one dictionary to another.
Are vendors going to have to change the way they design or build their instruments as a way of these standards?
I don't think they would have to change or rebuild the instruments themselves. There might be changes to the way they make their firmware, but it's more the software.
We're moving to the point where we have a piece of software that talks to the instrument in the instrument's own language … but then that driver talks to the outside world in a common language.
The drivers will have to change, so our driver talks to an Agilent software in our own language, a Waters driver talks to Waters' software in its own language, and it's that language that we have to standardize, so that an Agilent driver can talk to Waters software in the same language.
What kind of relationship would your association have with vendors?
That has to be decided. I think most associations of this type have a membership and a membership fee … there are other associations where you have a membership fee, and once you've paid the membership fee, then you have access to the standard, and that standard is copyrighted or protected, so there's a membership-based access to the standard.
During the meeting, a lot of people volunteered to be on this steering committee that you're trying to put together. Where does that stand now?
That's in progress. I think I've got nine companies who wanted to participate and I have to follow up with them. I would like to keep it down to a smaller number of people. …But if people volunteered, it's hard to turn them away.
We also wanted to be very clear that we are not trying to form, if you like, a cartel. I think that's one of the things that we have to be careful about. It could be that the big companies come together and decide to do this and it could easily then become a barrier for small companies.
We definitely do not want to do that, which was one of the primary reasons for having an open forum at Pittcon.
What are going to be some immediate tasks for this steering committee once it's been formed?
I think there are two things. First of all, have we contacted enough companies in the industry? There were some who were missing from the meeting. For example, Varian was not present, Thermo Fisher Scientific was not present: Was there a specific reason for that? Did they not want to support it, or were they not able to attend?
A part of what we will talk about is [whether] we need to initiate some more activities to make sure that everybody in the industry is informed and has the opportunity to participate.
The second major thing is to try to come to some agreement of how we move forward, and what specific way do we recommend to move this initiative forward — the fastest and most effective way.
And the third thing is that whatever way we move forward, that it is fair and open to all participants, large and small.
How would you like this association to look like?
One thing I'm trying to avoid is that I am the one who has to make it all happen. I really would like it to be a shared activity, to have a number of people, a number of companies drive this along, rather than one company.
My ideal is to have an existing organization take this over and drive it forward, but if that doesn't work out, then we would have to set something up ourselves.