This interview of SAPs CIO makes interesting reading.

Oliver Bussmann told me that SAP’s chief scientist had done an analysis of computers in business, and where they will be going. In their scientist’s view, the mobile and desktop models are converging. That is, instead of rolling up to a desk every day to power up a machine, and sift through screens of information to arrive at a simple dashboard, users will come to expect a smaller device to focus on the data. This smaller form factor and more task-focused paradigm will allow you to call up information almost instantly, with laser focus on specific processes, rather than one large machine that does a dozen things. It’s an evolution of the species, if you will.

We’re seeing this ourselves, both in our internal use of the iPad and also by our ELN clients. The Tablet form factor and the very task-centric paradigm really does create a compelling additional device from which to interact with your data – and we’re pleased that PatentSafe continues to keep up with the innovations in the tablet space.

A large number of our customers have iPad trials ongoing; there are few who are refusing to entertain the iPad at all on the basis that it is a “toy”. With endorsements like this from SAP I can’t help but think they will be reconsidering!

The resulting lack of competition on top of vendor consolidation has led to Chemistry-focused ELNs tending to lag in terms of ease of use, and openness, whilst of course being pretty expensive. As those vendors seek to expand into other scientific disciplines, they bring with them the same costs which are then unnecessarily imposed onto other areas.

One major reason for this is that the Open Source Cheminformatics world has historically been under-developed. My theory is that’s because Cheminformatics started in earnest before Open Source took off as a concept (in comparison to Bioinformatics) but I have no real evidence for this.

Open Source is an important part of todays’ software ecosystem:

• It provides a set of building blocks, and I would imagine almost every software product (commercial or otherwise) has some Open Source components. By sharing the basic foundations, the cost of entry is reduced and this results in more entrants and lower costs for everyone.
• Open Source drives innovation by allowing people to re-mix things to “scratch their own itch” and produce new approaches as needed. Even if those solutions remain in-house they still inspire others, and perhaps allow the engineers inside the commercial vendors to successfully propose new approaches.
• The threat of “free” competition as well as more players in the market generally keeps vendors on their toes. Without a complete lock on particular functionality, vendors must instead compete on value and functionality.

Amphora are not in the Chemistry ELN market (and have no intention of being in that market), but I look at what’s out there and compare with what I see happening in other areas and it is clear there’s a lot that could be done which would benefit the wider ELN world as well. Frankly what’s going on Chemistry is giving the wider ELN community a bad name – especially as marketers keep positioning their products as the only “proper” approach for any kind of science, chemistry or otherwise. You really don’t need to spend thousands of dollars a seat and days/weeks of implementation time to deploy an ELN!

So I’ve waiting for a decent Open Source approach to Chemistry-based searching because if nothing else it will inject some innovation where it has been sorely lacking.

So I was delighted to read this post on how to Enable Exact Structure Search and Substructure Search for Your Chemical Database. I don’t think there’s a great breakthrough here, but it is a straightforward set of instructions on how you can do it which demystifies Cheminformatics a lot.

This could get pretty interesting in the next few years…

• HTML5 and other web technologies are surely at the stage where we don’t need a “thick client” deployed onto a desktop anymore – can’t we do it all in the browser?
• What about all the tablets (like the iPad), can we make them full clients?
• Can we finally have true cross platform chemistry ELNs?
• Can we easily embed chemistry into a variety of other applications, rather than having to buy a complete implementation of someone else’s idea of an ELN?

Amphora’s focus will remain on our particular slice of the ELN problem, which is providing the secure recordkeeping back end, discipline-neutral collaboration etc. Once you’ve done all that work the lawyers generally want to make sure you get the credit for all that Intellectual Property you’ve created even if they don’t explicitly apply for a Patent – even in Academic environments this is becoming more important as the journals and funding agencies raise their expectations in terms of record keeping etc. Amphora’s job is to help our customers focus on the science, and we’ll look after the Intellectual Property and Records considerations.

Even though we don’t plan to directly participate, I’m really looking forward to this. It is great fun working with our customers’ in-house Bioinformatics solutions, and I’d love to see that level of innovation in Cheminformatics.

As an example, a recent post on battery life makes some interesting points about the impact of battery life on usability. The short post is well worth a read, and he finishes with the following which I think is equally applicable to the Laboratory:

Simply put: if your device doesn’t last for 10 real-world hours of use, your device is no longer competitive in education. I can’t imagine ever going back to using 4-hour devices like laptops on a regular basis.

I can’t shake the feeling that tablets like the iPad are going to completely change the way we use IT in the labs, because they are just so compelling for the kinds of interaction you need to do in that environment. But I also feel that people haven’t really woken up to the implications… which does make it interesting!

It is small-but-crucial things like this which we are exploring in our loose group of people who are interested in the iPad in the Lab. We’re getting lots of really practical insights as well as the inevitable “How do we do this” discussion.

As an aside, any reading of the iPad developer documentation shows how much effort Apple have put into managing the battery life on their mobile devices, and you can really see the results. But that does have software implications – e.g. people who think they must have Flash to have a viable Tablet probably don’t realise they will get a device which will have a greatly reduced battery life as a result!

Comparing a recent ruggedised tablet with an iPad shows why the iPad is so interesting for accessing an ELN from the benchtop.

The latest PC Pro magazine has a review of the Motion Computing J3500 which is a ruggedised PC with a touch screen which I guess would be one of the devices you might consider if you wanted a PC in the lab. At £2,253 (ex VAT) it isn’t cheap, battery life is just over 4 hours, and it is going to take a lot of bench space.

Compare that to an iPad which is £365 (ex VAT), a battery that will last most if not all of the day, much more portable, doesn’t take up nearly as much space on the benchtop and can be placed in a protective plastic bag if desired.

The difference in price, form factor and battery life is stark, and I suspect the iPad will be a lot cheaper to manage from an IT perspective. Given the move to web-based systems I can’t see there’s much the iPad is missing in terms of functionality either.

And that is why we’re excited about the iPad…. and it is too small to be used as a tray which is a concern with Tablet PCs!

I must admit some frustration with the process of Press Releasing new customers. Unlike most suppliers we tend to press release after a successful implementation (e.g. pilot, decision to go forward, roll out – and then we press release), and we also don’t press release everything. So it tends to be a while after we’ve got the project in and successful before we can talk about it, but it does mean when we do go public it is with something that’s solid.

We’ve just issued a press release on 4-Antibody’s use of PatentSafe (story on PRWeb here) and what’s interesting to me is that 4-Antibody, as a growing Biotech, needed to have a solution which allowed them as much flexibility and future-proofing as possible whilst giving them good IP protection.

Here’s the customer quote:

4-Antibody were looking to replace their paper based system but had some definite ideas about how any new electronic system would need to work for them. Marc van Dijk, Chief Technology Officer for 4-Antibody explained “It was very important for us that a new electronic lab notebook should not impose restrictions on us in the way that we work”. 4-Antibody evaluated several possible ELNs (Electronic Lab Notebooks) and chose to implement Amphora’s PatentSafe system, because according to van Dijk “Amphora seemed to offer the most flexible system which allowed us to do what we wanted to do in terms of workflow”.

But of course, you still need to stitch your systems together and keep things straight – always a challenge but particularly important in growing companies:

The system can also be simply integrated with other R&D applications, which was important to 4-Antibody because they plan in the future to implement these types of links. Van Dijk said that 4-Antibody aim to use PatentSafe as “one searchable database connecting all our R&D records, linking to our LIMS system” and he continued, “this will allow scientists and management to quickly see everything that is going on across R&D”.

This was one of the projects I was personally involved in, and it was a real pleasure to work with them – great bunch of people. They have a mix of Apple MacOS X machines as well as Windows PCs which meant the cross platform nature of PatentSafe really helped too.

This project was also my introduction to the Basel Fasnacht. We did think it was a little strange when we found the hotels were booked up, and you can imagine how we felt when we kept tripping over brass bands and people in scary costumes! Next time I’ll take the decent camera.

Aside from all the really interesting philosophy stuff which might give insight into the design decisions Apple have made, my interest in the iPad and ELN is as follows:

• Finally we have a practical device which allows access to “The Cloud” in a magazine form factor.
• They’ve sold 1m in the first 28 days, with supply restricted to the US. There are no credible alternatives announced. This is Apple’s segment to lose at the moment. If you want The Web in your hand, Apple is the place.
• Because it is in consumer space, pricing and volume are almost commodity-like.

It might not currently be positioned as an enterprise device, but the above make it viable to evaluate. Turning to the ELN:

• It has a proper web browser on it – no compromises (except for the lack of Flash – but HTML5 is here). The keyboard is ok ish and you can always use an external one – but it isn’t intended for content creation, really – this is a consumption and annotation device.
• It is relatively cheap so accidents won’t break your heart. But it is sturdy enough for kids… it isn’t an executive toy.
• Apple’s control-freak side mean this can be one of the most secure devices around.
• You can use it in a plastic bag, with gloves etc.
• Which makes me wonder – is this a hint of what we need to take the ELN to the science?

It isn’t perfect, but for my money it has earned a decent evaluation. It doesn’t replace the laptop, the desktop, etc. – but it does fill a gap which opens new possibilities. This is version 1 and I wouldn’t go out and buy them for everyone in my lab just yet, but I’d buy a couple and use those to understand the impact.

My conclusions so far are:

• If you get one and take it home, be prepared to get one for your significant other. It is the only way to maintain harmony. Having said that, I rarely get to use mine when my children are awake, and I don’t know how to solve that yet (I am not getting them their own!).
• This is a content consumption device, with the ability to annotate and make small contributions. It won’t replace your computer as the place you write.
• Applications – web or otherwise – need to be re-visited in the light of the iPads characteristics. Straight ports won’t work.
• The ecosystem is still settling down, you can tell that people have written apps not having seen the UI metaphors everyone else use. I suspect it will take at least 6 months for things to settle out.
• This really is very interesting. I suspect it could be as profound as the the introduction of the Mac.

This post is interesting as an insight into what Apple are probably doing with the iPad. This is more about changing our entire relationship with computers than merely the choices they’ve made for this one device.

If you haven’t seen it, I covered some more about this on the morning before the possible iPad release in my Chairman’s remarks at the SMI ELN Conference (this was just before the iPad announcement – apologies to my dinner companions who had to suffer my addiction to Twitter that evening!).

We’ll also have a couple of iPads with us if people are interested – we think this class of device has great potential in Labs.

The future of our industry now looks totally different than the past. It looks like a sheet of paper, and it’s called the iPad. It’s not about typing or clicking; it’s about touching. It’s not about text, or even animation, it’s about video. It’s not about a local disk, or even a desktop, it’s about the cloud. It’s not about pulling information; it’s about push. It’s not about repurposing old software, it’s about writing everything from scratch (because you want to take advantage of the awesome potential of the new computers and the new cloud—and because you have to reach this pinnacle). Finally, the industry is fun again.

It’ll be interesting to see what the iPad and devices inspired by it do for the world of ELNs. Clearly Marc’s got a very cloud-centric perspective but the success of Salesforce.com (which he launched when Enterprise software was very much a 3-teir world client/server affair) does mean he’s worth listening to.

But perhaps the real issue here is our application-centric view of laboratory systems

Which I very much agree with. So many projects start out not looking at their problem but instead “What ELN should we buy?”. When the terms we use such as “Electronic Laboratory Notebook” and even “Laboratory Information System” cover such a wide spectrum of potential functionality, starting out that way without being clear about what you are trying to achieve is a recipe for failure.

When we meet people for the first time we always ask “Why did you make time to see us?”, and hopefully they tell us the business problem they are trying to solve. If they answer “Because we’re looking for an Electronic Laboratory Notebook and you are an ELN vendor, show us what you do”, we find ourselves asking questions like “Why do you want one?” and “What do you think one will do for you?” which helps us to get to the root of the issue.

You’d be surprised how many people who tell us they want an ELN (and are quite certain about that!) but in fact have a problem that doesn’t need one – they might just need to use their existing software in a different way, or buy something like an SDMS or a LIMS.

I know that the traditional sales school says you should immediately “re-engineer” the prospect’s “vision” to suit the features of your product, but in my experience that rarely leads to a happy outcome even if you do manage to make the initial sale. If the end users didn’t need one, then just because the organization went out and bought one, and the vendor’s salesperson convinced them to buy his (plus the consulting time to aid with the inevitable painful implementation) it doesn’t mean the project is going to be a success in terms of achieving a Return On Investment.

From my perspective (as a technology implementor, not a salesperson), the sales process is where a potential customer and a potential vendor communicate and establish if what the vendor has to sell is going to solve the business problem the potential customer is prepared to spend money to solve. That often involves clarifying what the real problem is, before we get into solutions.

From the vendor side that means being willing to say “That’s not us, why don’t you go talk to these guys”, and from the customer side that means talking to us about the business problem you need solve, not what application you think you want to buy.

Once we understand a business problem, then if appropriate we can show how our ELN might be able to solve it. But not before. This sometimes upsets people who want us to just come in and demo, but surely the idea of the sales meeting is to have a productive outcome, and requires communication? Which is why we like to ask as many questions of prospective customers as they might ask of us, as strange as people find that.

I’d rather have a meeting where after 10 minutes we mutually come to the conclusion that there isn’t a fit, than labor with on each side pretending there at some point might be a happy outcome. If we communicate well at the first meeting, it means if things do go forward there’s a high probability of success all round.

(This approach of finding out people’s business problem and telling them if we aren’t a good fit did cause problems with our sales team until we changed their focus and compensation to be biased towards “happy customers” rather than just “make sales”. A small but important tweak which really helped the quality of the business, but still raises eyebrows when we recruit new salespeople.)

Requirements Gathering – a Broken Process

Project teams have been drawing up lists of requirements since the dawn of time, and since that first list the fate of a project has to a great extent been sealed the moment the requirements have been finalized. As a Civil Engineer my Father was always bemoaning the unrealistic requirements forced upon him by “dreamer” architects, a feeling that I suspect has dominated construction since the pyramids. I recall many a tale of tense ad-hoc negotiation on the construction site, and even the removal of troublesome architects from site entirely!

IT projects share a great many similarities with Construction, although a Civil Engineer has the advantage that she can point out the very obvious real-world difficulties (“You want me to build a roof of glass that large without any supports to spoil the view?”) whereas IT implementors often suffer from the perception that everything is easy. The progress in our field has been so rapid that our customers are used to apparent miracles, and of course there’s always the potential for distrust to arise due to the often large culture gap between the “Geeks” and “Normal people” – and that’s nothing compared to what people often think of Vendors and their dastardly sales people!

It is well known that IT projects can fail to meet expectations, and indeed some of the statistics on IT project success make sobering reading. Plenty of studies have shown the criticality of requirements setting in project success and indeed some practitioners (for example in the “Agile” and “Customer Development” movement) have gone so far as to remove what they perceive to be a very error-prone requirements setting step from their project entirely.

Unfortunately most large companies have purchasing processes which require the business to decide what they need, and then go out to the market to get the “best” solution from what they hope is a selection of competing solutions via a Request for Proposal (RFP) or other formal process. The need to maintain fairness to all concerned means the RFP process if often very rigid and leaves little scope for modification of the requirements in the light of the reality of implementation.

Therefore we are faced with a situation where a potential user’s desire to get the best possible solution forces them into a situation where they have to place almost total reliance on their up-front requirements setting process, an “Aim, and hope” approach which would be abhorred in another sphere of corporate activity. Who would design a process which explicitly prevented feedback from influencing the initial conditions?

And yet, we are here – to paraphrase Winston Churchill, the RFP process and it’s reliance on Requirements Specification maybe the worst way of purchasing systems but in today’s corporate environment is better than anything else available. In the spirit of making the best of the circumstances, this article will take the opportunity to make some suggestions and point out common pitfalls which so many implementation teams fall into.

The problems of requirements and the resulting issues in the RFP process are all the more critical for ELN projects because:

• The ELN replaces an existing paper process, which through the mists of time is often badly understood in itself.
• The term “ELN” can cover such a wide range of functionality and domains that in itself it is a foundation for confusion.
• Most of the current ELN offerings are still only “first generation” solutions which come with their own set of problems.

Thus an issue which bedevils all IT projects is often the founding cause of ELN project failure and requires particular attention.

Apparent “Solutions” which often aren’t

The difficultly in requirements capture/generation are apparent to anyone who has participated in such a project. A common approach is to hire a consultant, and when you get the right one they can single-handedly turn the situation around, although it does require the customer to listen! With apologies to the great consultants out there, the presence of a “consultant” leads to groans in the vendor community because (fairly or not) consultants:

• Are sometimes viewed as having an interest in creating long running complex projects, rather than quick productive wins.
• Despite having lots of industry experience, seldom get a long term view of a project. Often their involvement is restricted to the purchasing process, after which the vendor takes over. This gives them a rather one-sided view of the process.
• Need to get paid and that means making sure the customer is happy. Unfortunately sometimes the customer needs to be told some uncomfortable truths which might lead to them being “fired” as a customer – something a vendor with a large customer base can do, but very hard for a solo consultant to do.

Another approach is to “Stick with who/what you have and know” – for example, if you have an established implementation of SAP or a Document Management package, those solutions might be bent or tailored to meet the new requirements. Unfortunately this doesn’t remove the requirements generation pitfall, and leaves you with an expertise gap as domain-specific solutions ideally come with a vendor who spends their days working on a particular area, who can bring that expertise to bear both in the solution itself and the implementation process.

Some companies will already have an “ELN” deployed in one area, and there is a temptation to view this as being suitable for all kinds of science. This is a sad outcome of the rather generic “Electronic Lab Notebook” term, and is one of the primary reasons why we prefer to avoid the term in day-to-day use; “science” is by definition a very varied activity and you can’t assume that just because two different departments use the same Paper Lab Notebook, that a single ELN will work well in both places. Often all these groups will have in common is they both call themselves “Scientists” and work for the same company – hardly a basis for a common toolset.

It is important to note that these solutions – consultants, re-use of a horizontal tool, and a common ELN across multiple disciplines – aren’t in themselves inherently flawed and can indeed lead to a successful project. There is however a risk of viewing them as the solution to what is at heart a very tricky problem, and project teams who think they’ve somehow reassured themselves of success are often painfully brought back to reality. As the Financial Crisis has taught us, risk doesn’t go away by magic and sometimes the very approaches we take to remove it in fact just increases it, more dangerously so because we’ve stopped being sensitive to it.

Perhaps as Andy Grove says, “only the paranoid survive” and the ultimate key to project success is the recognition that any solution to risk reduction has the potential for problems in itself, often in ways you least expect it.

A Modest, Sadly Unrealistic, Proposal

This article has presented a bleak assessment of how most teams are forced by circumstances to approach their ELN projects, as well as pointing out some common pitfalls that requirements gathering processes fall into. Whilst the problems implicit in these approaches can’t be removed, I hope I have provided at least the opportunity for some reflection. In closing perhaps I might offer some suggestions which I know are unrealistic, but might one day mitigate the issues I’ve described.

One of the problems with an RFP process is the lack of feedback from the implementors; I am sure I am not alone in looking at some requirements and thinking “This project is doomed”. I for one would welcome the opportunity to answer some additional questions, such as:

• “If you could remove 5 of our requirements what would they be and why?”
• “What are the most expensive/troublesome requirements listed above?”
• “Which of these requirements do you think we don’t really need, based on your experience of similar projects?”
• “What are we missing?”
• “If you were us, what are the three things you would be most worried about going forward?”
• “Please rate our chance of success if we go with you, and if we go with another vendor, with reasons”

These questions would afford thoughtful vendors the opportunity to reflect and contribute their experience – after all, for all the conflict of interest that you might perceive in a vendor/customer relationship, a vendor only ultimately succeeds when their customer succeeds. Any vendor team is easily going to see ten times the number of ELN projects that any customer or indeed consultant will see in a year.

Sadly whilst all these questions are interesting I don’t know what project teams would do with this information! In so many cultures project managers are rewarded for following a process and thus any failure is blameless, any reconsideration a failure.

Other Approaches

One very interesting approach we’ve just experienced was where the prospective customer held an RFI (non-binding Request For Information) process which was rather like an RFP but held outside a commercial purchasing process. Crucially the RFI submission and scoring was then followed up with a 1 hour feedback meeting between the customer and the vendor team which allowed for a lot of constructive discussion which no doubt benefited both sides.

We have had good results from projects which have used a Six Sigma methodology with plenty of contributions from all parties – end users, management, IT departments, and outside vendors. This approach tends to be too “heavy” for smaller companies but has delivered great results in larger companies where Six Sigma is part of the culture.

This illustrates the final and most important point: a successful solution is the product of a partnership between everyone involved, and even the largest most process-driven companies reinforce this in their process. Perhaps the greatest danger lies in taking a very formal approach in the purchasing process without counterbalancing that with an up-front listening process – a trap that growing companies often fall into as they formalize their purchasing process without having developed the experience and resources to learn from themselves and the rest of the industry.

Not all of the “Stuff” sloshing around the lab is the same, and distinguishing between them helps tease out the best place to store things. We use a simple Triangle Diagram (originally proposed by John Trigg of PhaseFour which really just tries to point out that stuff is related, but it’s at different levels of abstraction:

It is quite hard to draw definite lines around things, but I think most people can appreciate that a raw data dump from an instrument is somewhat different from a report to management, or that an experimental write up in word is different from some tabular data in a spreadsheet. The differences between the levels come out in:

• The software that’s used to read the file and interpret the content. Some will require very specific software (e.g. from an instrument vendor), but a PDF or text file can be read by many different things.
• Who might be interested in the data. Again, some files are useful to anyone (for example, a report) but some only useful to certain people with specific training.
• How long your company might want to keep the data, and indeed how long you are realistically able to keep the data. Typically the lower you go, the harder it is to keep something, so if you feel it’s business critical you really need to pay attention to the formats used.

This differentiation can really help in ELN System design. Partly it draws your attention to what needs to be stored in the ELN (typically the “Experiment” write up level), and what can be left in systems e.g. a database or a file server, which can be pointed to from the ELN.

Not everything needs to be stored in the ELN, and indeed it would be unrealistic to expect to be able to do so. The important thing is common keys so you can offer the user a link to more information, and the advent of web-based systems has made this level of “integration” so trivial one sometimes feels a bit of fraud describing it as such.

By building on the storage tools you have in place, and focusing an ELN on Experiments, the resulting system is cheap to run, costs little to acquire, and results in little disruption to existing practices.

You can read the final part of this series here.

Most R&D organisations have more than one scientific discipline under their aegis. These groups will have developed their own suites of IT tools to help them do their work, everything from common desktop infrastructure to instruments and specialist tools. Some of these might be common to other groups, some will be very specific (and often unknown to anyone else). Meanwhile, the corporate-centric record keeping functions have remained in the commonly used Paper Lab Notebook.

“Broad” and “Deep” functions

The “ELN” question often arises when companies buy more and more IT to support the science, yet the only record keeping option is the paper notebook – a situation that generally arises because of the patent/legal issues around lab work in Discovery. Broadly, the the more computers you use, the more the paper notebook sucks – and to add insult to injury whilst you can search the entire planet using Google, the paper notebook is very much a “Write only” device!

The challenge for project teams is how to replace the paper notebook, and this is where splitting out what you mean really helps. Unfortunately most vendors have tried to expand the definition of “ELN” as far as possible which turns any project into a high-risk “do it all” venture, with an associated price tag.

By focusing on either the improvement of support for a particular niche or on replacing the paper notebook’s general record keeping process, projects can easily build on what’s already in place and achieve faster, more predictable ROI. Later projects run according to the same framework will by definition build on what’s already in place so there should be little scope for missed opportunities.

Vendor-driven approaches to use a single product for more than one area bring increased risk and often the promised cost savings are overwhelmed by the costs of replacing perfectly serviceable existing tools.

The next post examines what is stored in ELN systems, which is another useful way of looking at the ELN problem.

If the traditional large-ELN model no longer fits, what options are there for organisations who still need to find a better replacement for the Paper Lab Notebook? Fortunately, there are a number of concepts which have grown out of ELN deployments outside of the Life Sciences industry (which never had the money to afford “ERP for R&D”-style approaches) which can allow organisations to tease apart their requirements and clearly identify what they need.

Using these approaches, organisations can often achieve swift return on investment (often in a matter of months) for minimal outlay and vastly reduced risk. The more a project can focus, build on what’s already in place and solve the problems that need solving then it will by definition involve less of everything – less requirements, less code, less consulting, less change, and less money. Smaller, quicker projects are vastly less risky than larger ones, are easier to get approved, and allow the organisation to react easily to changing business circumstances. By building a culture of “quick wins” they lay the foundation for further improvements in tools.

The two models which help tease part the “ELN” functionality are relatively straightforward and indeed most thinkers in this space have their own versions. Their real power comes when they allow project teams to understand what they have and what they need, and develop a road map such that the future is protected even though the initial project may not have the widest possible scope.

We’ll examine each model in a separate post, first looking at ELN functionality and then what gets stored.

On to the next post in this series…

The problem with the term “ELN”

One of the problems that has confronted the “Electronic Lab Notebook” industry for a long time is the ambiguity of the term. Many a consultant and vendor has attempted to hijack the term with their own favored definition, complete with impressive diagrams in outdated and expensive reports.

ELN 1.0 started from the perspective of the suppliers – be they the vendors, or the consultants, or indeed the internal project teams. It was very much a “This is what we think you need” kind of approach, which led to a lot of worthy complexity which looked good but in practice got in the way of delivering the promise.

(For full disclosure, I was very much part of that group, and indeed the very first commercial ELN was written by me and others for Eastman Kodak – it was very functional but very complex. Then I led a Management Buy Out which created Amphora, and we had our own mini credit crunch which forced us to build something people could buy and use, not what we thought would be a good ELN!)

Today’s ELN 2.0 needs to focus on delivering value, and that means laser-like focus on the end user’s problem – which starts out something along the lines of “Since we bought all these computers, this paper notebook doesn’t fit with the way we work”.

ELN 2.0′s “End user first” approach doesn’t mean you end up with something that “isn’t a proper ELN”. What it means is you start focusing on the end user’s problems, prioritising them, and starting with the biggest wins first. Which is exactly what you need to do when there isn’t so much money around and everyone has become very risk averse. If we can do 20% of the work and get 80% of the benefit, doesn’t it make sense to do the 20% first and then look at where we want to spend our money next?

Interestingly this is directly against the interests of those who feel that a large, “fully functional” ELN is the only proper ELN. If we can deliver most of the benefit without the complexity, there’s no motivation to look further. So they have to bundle it all together and make the complex stuff appear necessary to achieve any kind of return. (for those who have attended my workshops, this is the “Toaster Problem”.

Differing needs

Some disciplines clearly benefit from a science-centric working environment which supports their niche requirements for example Medicinal Chemistry, and the considerable number of ELNs targeted at this sector is proof of the value that these solutions bring. The ability to draw structures and reactions, calculate properties, and structure/reaction-based search demonstrably increases the productivity of those scientists. Ironically, these solutions often don’t replace the Paper Notebook which is still required due to the concern that niche science-centric tool cannot provide adequate long term legal protection. However their value is only slightly diminished by the requirement to cut & stick into a Paper Notebook once the experiment has been completed.

For some scientific disciplines a gradual investment in IT tools, starting with a fairly typical desktop computer and then expanding into niche applications has provided them with all the tools they need to do their work. Once you deal with the legal issues, a lot of Discovery research looks a lot like any other kind of knowledge work and there’s a massive number of tools, sometimes already available to people for no additional cost, which can support that work. Indeed, one of the reasons the Paper Notebook is no longer suitable is that they are actually using those IT tools, and as a result a paper-based record keeping process is an unproductive overhead. Microsoft Office might not be blessed by the consultants as an ELN but it surely is the repository of more scientific thought and data than any “fully functional” ELN; that some products claim their similarity to, or integration with Office just reinforces the point! In these cases, project teams need to have a good answer to the CFO’s question “Why are you spending $1,000 a head to make Office harder to use?”

It is interesting to compare the health of the Medicinal Chemistry ELN market with the Biology ELN market, and indeed the discipline-neutral ELNs. Some have postulated that “Biology is next” and the approaches that work for a relatively homogeneous Medicinal Chemistry market will guarantee success in Biology. The implicit assumption is that Biologists have just been waiting for the ELN Gods to come and rescue them which rather implies that there are no biologists able to innovate in the same way as the chemists who developed the first Chemistry ELNs! A more realistic assessment might be that Biology is different – much more heterogeneous – which means the rise of a single Biology ELN is very unlikely. The adoption of the Biology-centric ELNs seems to be proceeding at a departmental level rather than the mass rollout to 100’s of scientists.

One size doesn’t fit all

Historically the ELN industry has been pushing a “One size fits all” approach, perhaps more due to the agendas of IT departments and suppliers. These projects are necessarily large, complex, and of course come with an associated price tag. With increasing size, complexity, and diversity of users also comes increased risk, and the success rate of such heroic endeavors has never been good. Projects of this type, which were always hard to justify anyway, are increasingly out of step with the new commercial realities. We just can’t afford to waste so much money stroking our “big project” egos – in today’s world, spending unnecessary money ultimately means there’s less money to spend on our own salaries.

If we want an ELN industry that’s healthy and can hold it’s head up high, we have to focus on delivering value, in a way that is acceptable in today’s environment. The subject of the next article in this series.

The past year has been “eventful” to say the least. So many long-held truths have shattered in moments, taking with them institutions who were meant to be the model of probity and longevity. Only a fool could pretend that the business of modernising R&D by replacing Paper Lab Notebooks is unaffected by such massive events, and it is perhaps useful to peer into the mist and see what the future might hold. It is clear the Electronic Lab Notebook’s time has come, but perhaps we need to adjust our sights for the new environment.

Warren Buffet said “It’s only when the tide goes out that you learn who’s been swimming naked” and perhaps the hidden blessing in reduced financial circumstances is a renewed focus on value. Successful projects will be more disciplined, surviving suppliers will be more customer-focused, and the products that succeed will be capable of delivering a predicable Return on Investment within a short time period.

It isn’t just a simple matter that there is less money around; for sure, companies which are exposed to the wider economic cycle are clearly hurting badly (the Chemicals industry is perhaps the most obvious); Venture-funded endeavours that planned to go back to the market for additional funding are having to close or sell out. Even for companies which are well-funded for a few years, the general climate of uncertainty is causing significant caution and search for value. Suppliers who had pumped themselves up on cheap speculative money, with the intention of selling large amounts of high-ticket software and associated consulting are being forced to make cutbacks as their sales pipes evaporate, and the resulting revenue loss reducing their ability to service the sometimes onerous commitments they have made to their existing customers.

Despite all this, the problem remains – Paper Lab Notebooks are no longer “fit for purpose” and an ELN can deliver well-documented savings in both time and effectiveness for any R&D-based organisation. The question is, how can we achieve this in a cautious, value-focused climate?

The answer goes right to the core of how we have been currently approaching the problem. Yes, you can tweak around the edges – most suppliers now have rental options which removes some of the financial pain (although the consulting effort required by many “fully functional” products is still onerous), and some have even started offering on-demand SaaS-style (Software as a Service) offerings. However, in an environment of such uncertainty much more needs to be done – how can you expect a management team to support an ELN project which will require 6 months of customisation before it even starts to deliver value, when no one is sure what the business will look like on that timescale or even if they will be in business? The answer goes right to the heart of our assumptions about how to approach the problem of replacing the Paper Notebook.

You can read the next post in this series here.

I’ve been thinking for a while about the impact of the Financial Crises and the ELN industry. I was asked to write an article on it and some of the proof readers suggested I take some time to expand on the various elements on the blog. So I will start a series of posts exploring what I feel the impact of the Credit Crunch has been on the Industry, and how we need to respond – what I think ELN 2.0 needs to look like.

Although the ELN blog world isn’t all that active, I’d be delighted if this sparks some discussion. The issues are important, and I hope my stance is suitably (but respectively!) provocative enough that others feel moved to make their own contributions.

You can read the first post here.

This is my first attempt at using SlideShare… hopefully this makes my stuff more accessible. Enjoy…