“DevCon” is nerdy developer-speak for “Developer’s Conference” so it’s definitely not a conference to attend if you’re merely interested in using the iPad in your lab.

I wanted to point-out that one of the speakers is from a place called “Big Nerd Ranch” and, as someone that does program, I particularly thought that sounded intriguing. 

Just this past week, one of the software vendor’s consultants at my customer was sitting around thinking and suddenly turned to me and said, “You know, I bet there are some great uses for the iPad in a laboratory” to which I immediately replied, “Yes, it’s a great sample tray!,”and then I snickered. I just can’t stop perpetuating that joke. I guess that shows the inane level my sense of humor dives to.

But I might have to stop this silliness. In the LIMS/Laboratory Informatics group in LinkedIn, I just saw the title “The iPad Makes its Way Into the Research Lab” to which I struggled but did hold-off making a post just to point-back to John’s “sample tray” posting ( http://www.linkedin.com/newsArticle?viewDiscussion=&articleID=136348746&gid=36640 ).

And, to make things yet more serious, there’s a real application really using the iPad ( http://blog.biodata.com/2010/06/13/the-ipad-makes-its-way-into-the-research-lab/ ).

Also, to be fair to John, he did also make another posting about the iPad where he did not use the term “sample tray” anywhere (drat!) (http://theintegratedlab.com/2010/05/the-ipad-in-the-laboratory/ ).

And so, as we get new technologies, there is usually eventually someone that discovers a great use for it. And, when that doesn’t happen, the technology doesn’t take off and disappears from our horizon, regardless how “cool” we might have thought it was when it came out.

The course presented at SmartLabs Exchange outlined a systemic approach to automation, tracing its evolution from the days when quantitative chromatography was based on cutting out peaks and weighing them, to current requirements for integrating disparate laboratory instruments, systems and robotics into a unified laboratory ‘solution’. Considerable emphasis was placed on process and workflow understanding, the choice of technology infrastructure and the role that systems such as LIMS and ELNs can play in facilitating integration. From a manager’s perspective, the introduction of laboratory automation is equivalent to introducing a small scale ‘scientific manufacturing’ operation and therefore warrants appropriate policies and practices. Good planning plays a critical role in the deployment of laboratory automation, based on well-defined goals and business justification.

The course provided an excellent overview of strategic approach to laboratory automation. Full details of the public course schedule offered by the Institute for Laboratory Automation can be found here.

With regard to the technical content of the meeting, one of the underlying themes was the continuing debate about the overlap between LIMS and the growing number of ‘Q/A ELNs’. Presentations from LabWare, Velquest, LabVantage and Waters tackled this issue head-on. It is interesting to note that after staying away from the ELN market for some years, a number of LIMS vendors are now adding ELN functionality to their products to move into this market space. The underlying strategy seems to be one of offering existing (LIMS) customers the ability to extend their implementations by adding ELN functionality, rather than purchasing a separate ELN system and facing the subsequent interfacing issue. This approach has its strengths and weaknesses which I’ll look into in another post.

For the first time in one of these meetings I sat through a workshop on Software as a Service(SaaS). SaaS is currently in the hype cycle when it comes to laboratory systems. But with an increasing number of commercial offerings and some potentially significant benefits to customers, it is becoming increasingly important to get some clarity around the benefits and limitations.

Laboratory automation, as an ‘engineering’ function, got a good exposure, and I’ll put together a separate post or two on this topic. The concern is that there is very little formal education that specifically addresses this topic, despite the fact that it represents a significant challenge for most laboratories.

My participation included a workshop on the subject of ‘Managing User Resistance’; here’s my slides.

Overall this was a good and enjoyable meeting and a refreshing change from the more passive style of conference that serves the laboratory integration market.

He and I agreed that the terms are fairly meaningless, right now – that our industry needs to either redefine the terms to reflect the new products or to abandon them, entirely.

With this being a time when many labs are getting ready to start their Fall work, and a new round of product selections, we hear many people complain that this is just too confusing.

Here’s my usual tip, and these are the same tips I give all of those who want to do this, themselves, regardless whether we’ve been in such transition or not:

1. Don’t get hung-up on the terms. They don’t mean much.
2. Focus on functionality.
3. Plan to spend lots of time on this. By the time you’re done, you’ll be an expert, too.

My own opinion on this is that our current terms reflect old ways of doing business that we’re replacing. As we’re making our transition away from old processes, let’s stop using terms that reflect those old processes to define our new path.

This seems like a digression from the main topic, but it’s just a way to lead you to it. The simple answer is this: this is time-consuming and hard. Period. Read lots of articles to get yourself started and spend a lot of time on it.   –or-  Hire someone to do it.

Hey, I said “simple” not “easy”!

Solid state drives are now available in terabyte sizes, but are more expensive than their more traditional counterparts. However, a couple things might offset that higher cost:

1.                Solid state drives use much less power. The fellow that I spoke with said that the power consumption of a solid state drive was 90% less. I went to the Internet to verify this but did not find an exact verification. I found many charts to showed overall power consumption savings, but nothing that addressed this exact number. So, this might be the case but I cannot independently verify it.

2.                In areas where the per-square-footage building costs are high, floor-space is at a premium. Solid state devices take up much less room. In areas such as Cambridge, Massachusetts, USA, where the per-square-footage costs are extremely high and companies struggle to squeeze into smaller rooms and buildings than in other areas, space is a premium and footage costs can be significant savings costs.

Also, from looking around, it seems that the read times of these devices are much higher than that of the traditional drives, as well.

So, will solid state devices take over for Cambridge, MA, USA data warehouses and other large database applications where reads are quite high, and where both power and floor space costs are high? Or, can they be costed-out to make sense for less costly physical areas and for applications where writes are heavy, as well?

It reminded me of a paper written by Ray Dessy, published in 1993, entitled ‘The analytical laboratory as factory: A metaphor for our times’ (Anal. Chem., 1993, 65 (18), pp 802A–809A). The factory metaphor was based on ‘samples in’, ‘results and reports out’, and Ray Dessy’s argument was that automation alone would not drive efficiency; workflow, scheduling, capacity planning would all contribute towards improved performance. 15 years or so later, are we starting to catch on? I suspect that ‘lean science’ and the introduction of Six-Sigma in the laboratory may feel like a major culture change, and how many undergraduates embark on courses in science expecting to eventually be employed as a ‘factory’ worker? But there is another dimension to this, one that Mark Gibson, the author of the Schering-Plough article, emphasises in the last paragraph: ‘the feeling of success created when a group of hardworking individuals, each gifted and talented in his or her own scientific field, unites to accomplish a challenging goal together’.

The reality is that a lot of laboratory work has been heading for black box efficiency for some time. The introduction of Six-Sigma, where the drive is for process efficiency,  teamwork and the elimination of waste will take Ray Dessy’s prophesy a significant step further.  I don’t disagree with Mark Gibson’s point about the success of the project team’s achievement and the benefits being delivered, but there’s that nagging concern that, as the science gets increasingly absorbed into the process and the process becomes increasingly regimental, how many laboratory workers will continue to understand the science, and just how exciting will it be to be a lab worker?

For me, the worrying thing is how we get the inertia to make us want to change.  So much laboratory work is heads-down and keep the wheel turning, that taking time to stand back and evaluate what we could be doing better isn’t as high on the priority list as we would like.  You can argue that it is the manager’s job to do this, but like a lot of other things in life, unless it’s completely broken you’re often willing to let things keep running to avoid the disruption of fixing it.  Of course, there are other factors that get in the way; legacy technologies that are lacking in application and data interchange standards certainly don’t help.  We’ve also got to deal with the IT department and depending on the size of your organisation, this can sometimes mean that it’s the tail trying to wag the dog.  And do we have the necessary skills and knowledge immediately to hand in the laboratory to understand the problem and to define the solution?

Nevertheless, Joe’s proposals for moving forward make a great deal of sense, and give us a choice.  So perhaps the most telling comment is in the last sentence of the article: One method will always have us looking to fix past problems, the other will improve the effectiveness of lab operations.

As we continue to talk about why we have project overruns, it continues to befuddle customers that they could purchase a COTS (Commercial Off-The-Shelf) system that merely requires some configuration, and end up with an expensive project full of programmers writing code for them. This is due to the fact that what some (i.e., the customer) might conclude would be configuration is not the same as what another (i.e., the person selling the services to the customer) might consider it to be.

What Do They Really Mean?

I claim that “configuration” is when you press a few buttons to change the behavior of a feature. I don’t agree that you could write “just a few” lines of code and still call it configuration. I say that having seen what some people would call “a few lines.”

I also claim that “customization” is when you write code to change any behavior in your system, not just that of the core of the system. I have been on too many projects where a module is “configured” to work in a customer’s situation by writing thousands of lines of code. Once again, leaving the customer to wonder why the project is taking so long and costing so much.

Finally

With all that said, I realize some of the terminology we use is used in a way to mollify some of the regulatory agencies. But are they being mollified or are we just misleading them? I can’t quite figure that out.

But I will make everyone a deal: if you all just stop using these words in a confusing manner, I will stop my constant whining and writing about this topic. I promise to move onto another worthy topic, such as then getting rid of confusing and misleading terms like “COTS.”