So at this time the data portability situation in the ELN world is pretty awful. Which is a shame, and at some point people are going to start noticing – and perhaps the next round of ELN purchases will have open file formats as a purchasing consideration.

I came across the Data Portability project in this article on Tech Crunch which seems to be a really nice way of at least making the Data Portability issues obvious to consumers. They are starting off in the online web app area but clearly it is very relevant to any IT system, either cloud-based or on premises.

For the record, Amphora’s systems are completely open – our view is that it is your data and you should be able to take it where you want, when you want, without even having to involve us.

In addition, our focus on IP means we need to be able to reassure our customers that they can take a record out of our ELN and defend their IP long after their relationship with Amphora has come to a close – with a 50 or 100 year retention timescale, requiring the vendor to be around just isn’t acceptable (which is a big concern with services that claim to outsource IP protection, something I’ll blog on in due course).

We take this a step further in our Hosted/SaaS offerings, where customers can take a copy of their data (via rsync or similar) onto another server controlled by them every night. We also work with those customers to make sure they can spin up their own server as needed. This means that even where we’re Hosting them, they can tell us our services aren’t required and still have complete access to their data without any cooperation for us.

We believe that open data, neutral file formats, powerful APIs and above all a respectful policy to our customer’s IP are the cornerstone of any ELN vendor’s offering.

Our next web site refresh will contain our Data Portability policy. In the meantime I can only hope that as various advocacy groups get more vocal about the need for Facebook, Twitter and others to unlock your data, that will cause Data Portability to be given the consideration it deserves in the ELN world.

We’ve always had a very straightforward model; because our Electronic Lab Notebook needs to know about every user to do its job (every user needs to be uniquely to sign and witness their entries), it is easy to just charge for the number of users which are enabled on the system. Fairly straightforward.

We do have a slight complexity in that we split PatentSafe functionality into modules, so you can have cheaper licenses for people who just want to read, or people who just want to submit and sign stuff, etc. We have assigned “points” values to these functions, and customers buy a certain number for their system which gives them a lot of flexibility.

Sometimes we’re asked about concurrent pricing but that request generally comes from an IT dept who are (quite reasonably) looking for ease of administration and don’t realise every user is going to be setup (automatically or otherwise) with a PatentSafe account anyway. Concurrent licensing wouldn’t help anyone in our use case.

We do have a mix of perpetual and rental options in our licensing structure; this accommodates customers who have capital and want the reassurance of owning something (generally larger more established customers) as well as making enterprise-grade solutions attainable to companies who might either be short of capital (being VC funded and at the end of a round) or unsure of their growth curve.

We don’t do anything silly in terms of copy protection; it just adds to pain for the users, and ultimately support pain for us! We don’t even lock a system to a particular number of users – PatentSafe just points out how many users you have and we trust our customers to have that many licenses. We also don’t charge for test servers, although we do make a small additional support charge if you want production-level support for an additional server.

I guess we are unusual in that we’re a records system which is intended to go into court at some point, so we can trust our users to do the right thing in terms of having the right number of licenses. This level of trust makes everything easier, and interestingly means users are more trustworthy back – in all the years I don’t think I’ve ever heard of a reason to be worried that a customer may be exceeding their entitlement.

I know some software companies view having a complex licensing structure as a sales tool but I’ve never found it all that attractive. We’re providing and supporting a tool which will benefit a customer’s organisation, and the question is how to fairly measure the value we provide and hence should be compensated for. We’ve found the easiest and most reliable way to do that is count up how many scientists we’ve freed from the drudgery of the Bound Paper Lab Notebook, so that’s how we price the system. Simple, transparent, predictable – and fair.

Interestingly treating our customers like adults means they act like adults; and the relief expressed in the sales cycle when the realise we’re straightforward to deal with is quite gratifying! I continue to remain befuddled as to why more companies can’t have understandable pricing schemes – I can’t see how complexity helps the vendors or the customers.

In a move that I take as more of a sign of weakness, Adobe have placed an advert in the press basically saying they love Apple, but Apple are being unreasonable.

I can’t improve on TechCrunch’s thoughts this whole thing. Adobe have painted themselves into a corner and I suspect Flash is a dead end technology. They’d do better to admit that and move on, rather than flailing around like so many other failing businesses – the Flash franchise wasn’t as strong as they tried to make out (being dependant on a plugin being installed), they overplayed their hand, and Steve Jobs called their bluff.

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.

Human progress happens at 4% per year, averaged across many fields, ranging from 2% to 7%

How interesting! I wonder what the state of play is for ELNs…. I suspect we’d like to think it’s something like 10% or 20%, but I fear that if we took a good look at what’s really going on, it would be somewhat lower! One of the problems we currently face as an industry is there’s too much marketing spin in our communications and not enough real understanding of what’s going on.

I’d like to think at Amphora we’re on the realistic side – replacing the Paper Lab Notebook is a hard problem and we’re only going to get better if we pay attention to the whole problem and are clear-eyed about what’s really happening. Geeks at heart, we run a lot of stats about the performance of the business and customer experience and it produces really thought-provoking insights.

It isn’t just about the product, there’s lots more involved to the customer experience – from the sales process, pilot & training, commercial packaging, infrastructure requirements etc. all have a significant impact. Interestingly from a product perspective it is often more about what functions you leave out rather than making a complex mess, which does take a lot of discipline. For example we were recently eliminated from an RFP because we didn’t meet a “mandatory” requirement but we’d prefer to lose a deal than bend PatentSafe in weird ways which would lead to a more complex product which was harder for everyone to use. Purity of design is a good thing (yes, we’re Apple fans!).

With regard to “bed behaviour” particularly by Sales & Marketing personnel, I’m afraid I’m one of those naive people that believe open conversation spurs creativity, and if people act badly they’ll just look like idiots to the very people they are trying to “impress”. As long as there’s transparency it tends to self-correct.

However, I realise that only a few of us are willing or indeed able to Blog, so forums such as LinkedIn groups definitely have a role. There are a couple of ELN groups on LinkedIn, one’s pretty quiet and the other is somewhat stifled by rather outmoded policies.

So I’m delighted that a more open ELN group has been setup on LinkedIn – you can join it here and I would strongly recommend you do.

Here’s the group description:

This group was set up to provide a place where all can discuss content free from restrictions.

By joining this group you are agreeing to allow other group members to make comment on your discussions free from any risk of litigation or lawsuit. This means other members are free to make reference to trademarks and express their opinion positive or negative. The only recourse is to answer their discussion. Abusive replies will be removed.

Content from this discussion should not be referenced elsewhere.

Innovation requires uncensored discussion.
So feel free to discuss anything related to this topic in here.

I really like this approach, the only quibble I might have is “Content from this discussion should not be referenced elsewhere” which is going to be really tricky in practice – good ideas and discussion spread, that’s the whole point. But I’m sure we’ll have a discussion about it .

FYI the group was setup by Andrew Lemon who runs The Edge, producers of BioRails which is on my list of “interesting things to look at when I have time”. So guess he’s a fellow supplier although I’m not sure we compete that much – we briefly met at a conference once, but apart from that I have no relationship with him. I’m just pleased that someone is doing something to enhance the quality of conversation in the industry because we urgently need to something to improve the success rate and ROI of ELN implementations.

• Business drivers
• Comparing the different sectors and disciplines
• Build or buy?
• An overview of the solution space
• Patterns of success

There’s a few concepts in here which deserve their own posts (presentations are so useful for stimulating the creative juices!) which hopefully I can do over the coming weeks.

Anyway, you have to give a 10 minute presentation talking about wider industry issues and I thought it was appropriate to draw people’s attention to what’s happening in the consumer space and how it might bring us towards the original vision of an ELN.

I’ll blog more on this tomorrow (after the Apple announcement today!) but for the moment here’s the presentation….

Having said that, whilst I believe we’ve done a really good job in PatentSafe replacing the corporate aspects (record keeping, long term records etc.) of the Lab Notebook, scientists still need a place to work. Sometimes that’s a discipline-centric product (sometimes badged as an “ELN”, sometimes something else), sometimes Microsoft Office and other general Knowledge Worker tools.

Looking forward I can’t help but think that tools like Google Wave and WordPress (especially with 2.9′s nifty features) are the long term future. A lot of vendors have “Web based” ELNs which are nothing more than their thick-client products wrapped in a browser – which I’ve always felt is cheating.

But when you look at what people are doing with web-native UIs these days…surely the next generation of Scientific collaboration products are going to come from the blogging or Web 2.0 space, with a little chemistry added to the mix. They’re cheaper, easier to use, easier to deploy, and often more powerful than a typical thick-client “Enterprise” app – and I suspect they’re more capable of dealing with large-scale use than any of the commercial products on offer at the moment (the lack of scalability being the dirty little secret of most ELN deployments right now).

All these tools need – apart from some open mindedness – is a decent record keeping system. Which we would be happy to help with

What an exciting time…

This discussion will start out with identifying the many forms of information we create and use, and the needs of those doing the creating and using. It would then move on to how best to share this information within our organization, and with our customers and partners in a secure manner. Our mental model will be the most well-known computer network – the Internet.

I really quite like this. I think The Internet has a lot to give in terms of sources of inspiration and it’s sad that the Lab Informatics market has been rather knocked off course by an obsession with a paper artefact rather than looking at what’s really going on.

I’ve always felt fortunate that we’re operating in one of the few “Green field” markets for IT systems. I thought my age would condemn me to working on incremental IT projects, as opposed to all the fun my predecessors must have had in the 80′s and 90′s going into manual processes and achieving quite amazing business impact by automating them.

Perhaps what’s happened is our generation have forgotten some of the basic system analysis skills that our Dads used?

Regardless of the cause, I strongly suspect if the Paper Lab Notebook didn’t exist we wouldn’t have come up with the concept of an Electronic one. Which does make you wonder how much more effective we could all be if we focused on the real problems scientists and their companies have?

I’m sure writing them is difficult.

But answering them is deeply frustrating – it’s being forced to have a one-way conversation about something where you really need to have a chat, which is much more my natural style.

I remember once I turned up to a Government research establishment and was told “We can’t tell you what we do, or anything about how we work. In fact, the people in this room can’t tell you anything at all. So just tell us what you do, and show us your stuff”. Which was painful, but at least the audience gave some (non-verbal) feedback.

Guess I’d better get back to it – although I think my car might need washing, and there are some other chores to do. Or I might just poke myself with a sharp stick or something.

It’s quite nice to have a Queen in such circumstances – she’s above it all (so there’s no finger pointing and has so much respect that when she asks people they jump. So when she asked the obvious question – why no one anticipated the Credit Crunch – a bunch of them sat down to figure out why.

The answer is very relevant. It’s why systems fail, Space Shuttles explode, companies fail, and in my particular interest – how a group of well meaning people in a company can fail in their quest to replace a Paper Lab Notebook with an Electronic Lab Notebook. From the article:

“Everyone seemed to be doing their own job properly on its own merit. And according to standard measures of success, they were often doing it well,” they say. “The failure was to see how collectively this added up to a series of interconnected imbalances over which no single authority had jurisdiction.”

Besley stressed that the experts had not been in “finger-wagging mode” and had agreed that the causes of the credit crunch were extremely complex. “There was a very complicated, interconnected set of issues, rather than one particular person or one particular institution.”

….. snip …..
“In summary, Your Majesty,” they conclude, “the failure to foresee the timing, extent and severity of the crisis and to head it off, while it had many causes, was principally a failure of the collective imagination of many bright people, both in this country and internationally, to understand the risks to the system as a whole.”

Lots of bright people. Complex problem, with interlinked components, dimly understood, with diffuse responsibility. Everyone working diligently on their own bit. It’s no ones fault – they all tried their best, etc.

Sounds very much like a lot of ELN projects . ELNs by their very nature are complex, span multiple areas of expertise, and require different parts of the organization to have conversations they aren’t used to having.

This is why we run “Fire Drills” – to get the customer’s organization to see the whole picture. Works very well. This overall perspective is one of the most valuable things we can bring to our customers, the result of an awful lot of interesting experiences in many different ELN deployments, across a whole variety of industries and company sizes.

Sadly we see a lot of ELN projects which are doomed from the very start, because they fail to appreciate and manage the complexity of what they are trying to undertake. I hesitate to say it, but I am inherently skeptical of any ELN project team, or indeed any consultant, who claims to be fully in control – these projects just aren’t that simple. If you think you know what you are doing, you’re probably just unaware of the problems which are going to seriously ruin your day.

For me, a healthy paranoia is much more encouraging as it shows respect for the challenges ahead. The Credit Crunch has “cost” each of us a mind-boggling amount of money and it would be a shame to lose the lesson.

We use a lot of Open Source components in our products, and I know we’re not alone.

There are vendors who are very committed to a specific platform – Windows (and associated libraries, APIs etc.), Oracle, and so on. Those will almost certainly have some Open Source components in them, but not much.

There are other vendors – Amphora (my company) and Rescentris are two that I know of – who have built on top of an Open Source stack. We do have some proprietary components but where there’s an Open Source alternative we use that.

Why?

• The Open Source stuff just works better (and you can fix it if it isn’t).
• Support is better.
• Licensing issues go away (of course you have to abide by the Open Source license, but that’s not a problem as long as you check everything before the developers start using it).
• It is dramatically cheaper for our customers to deploy. No expensive additional Windows Server or Oracle licenses (unless you want to use those of course – we can support them if you prefer).
• We have much more latitude in deployment options. We can bundle our product in a variety of ways and on different platforms, which we wouldn’t be able to do if we were locked to a specific commercial platform. You can get PatentSafe as everything from SaaS, to an embedded device, to a traditional “Install this on your own server” software product.

A few years ago we got raised eyebrows about our platform choices (“We will only consider applications written in .Net”) but that’s not been an issue for a long time. Everyone assumes that the components we’ve assembled into the solution will work and we’re responsible for the overall performance of that – what bits we’ve chosen seldom get discussed.

From what I can see, Open Source starts at the bottom of the stack – the OS, generally – and is gradually moving up (Database, Application Server, some applications). Every commercial vendor needs to keep an eye on what value they are bringing compared to what’s provided by the community.

As an aside, we don’t consider ourselves to be a “Software Vendor”. We solve a business problem and it just so happens we deliver our expertise as some software which implements a “best in class” process. But we don’t consider we’re charging for “software” – we get paid for our expertise and how we deploy that to help customers solve their problem.

What that means is that as the software environment changes (and quite probably Open Source gets further up the stack) that’s not something that threatens our identity. I know some vendors (particularly those locked to proprietary platforms) aren’t so lucky, and I wonder how they will fare as the Open Source community begins to provide more and more of the “ELN” system.

I think there’s multiple issues here, more than would fit in a comment to the original post, hence this one.

The good news is there are examples of how healthy communities can arise, the bad news is the ELN market isn’t there just yet. There’s still a lot of old-school thinking around about how a market should communicate, especially by vendors (Wolfgang and I are the only ELN implementors actively blogging for example).

My view, formed both as a result of my own experience as a “customer” and by books like The Cluetrain Manifesto, is that markets are conversations. This is especially the case in new markets, where none of us know what we’re doing, and the only distinction between “Vendors” and “Customers” is that the vendors are trying to generate enough marketing fluff to hide from the users that they’re making it up too!

I guess there’s at least three levels of conversation/interaction that need to happen in a market:

1. We need to figure out the problem and how to solve it in general terms. This is market formation stuff.
2. Customers need help getting from “I think I might have a problem” to “This is the kind of solution I am looking for”. This is the start of “Curious Buyer”.
3. Once the prospective customer has some idea what they are looking for they then need to decide which is the “best” vendor.

Each of these deserve a post on their own, but for the sake of brevity some quick thoughts…

The Market Formation Conversation

CENSA was a really good place for the Industry to figure out what the problem was, although it’s usefulness declined once the industry got to a size where the vendors hired marketing people and sent them rather than their CTOs or founders. We still need something like that because we’re still not where we need to be in terms of really understanding the “map” of the space we call “ELN”. There’s too much confusion even in the use of basic terms, and when that’s combined with sales & marketing efforts a lot of projects just start out doomed from the start.

Personally, I’d love to see all the vendors and consultants running their own blogs, blogs written by people who are responsible for actually helping customers, writing about their daily experiences. I know a lot of people are constrained in their messaging, but I don’t think that’s going to work much longer so Sales & Marketing may as well get used to it.

I’d also love to see people with an ELN blog their experiences. Again, this is hard to do but I’d love to see even anonymous blogging (although how do you know it’s not a vendor… this has happened in other industries, sadly). The academics are starting to blog though, and that could well be our salvation – although the needs of Industry and Academia are somewhat different, so the conversation is going to get a little skewed.

Helping the Curious Buyer

In terms of helping a curious buyer, typically that’s a role a consultative-based sales person would do. If done well (and by well I mean ethically) this is often an excellent way for a buyer to quickly understand their problem and how it might get solved. This is why at Amphora we have a very “soft” sales approach, tend to hire people with more of a consulting background than sales, and have a compensation system which focuses on long term customer success not “get the sale in”.

However, not all vendors work in that way – some can’t (because of their company structure) and some just lack the vision. So buyers don’t trust any “Vendor”. Which is why the Industry needs ways of helping Curious Buyers move forward, and sites like The Integrated Lab are a good starting point for this.

Some people view analyst reports as a possible way out for a Curious Buyer – “If I buy this report it will tell me what to do”. Unfortunately this rarely works even in mature industries because of the inherent conflicts such analysts encounter – you’re generally reading something that’s heavily vendor influenced.

I know that our interactions with Analysts hasn’t been good – a “review” of our product appeared based on not actually seeing our product, our market positioning is totally misrepresented, and even the basic analysis is wrong – we weren’t even given the courtesy of being able to respond. Not going there again.

Having said that I do quite like the guys from RedMonk who have an “Open Source” approach to Analysis. Here’s the first couple of paragraphs of their web site:

RedMonk is the first analyst firm built on open source. We’re dedicated to providing high quality research at no cost, and believe that the dialog that follows is beneficial to us, our community and our clients.

William Gibson once said that “the future is already here, it’s just unevenly distributed,” and we concur. RedMonk analysts spend their days learning from the communities that are defining the future of technology, distilling our findings into free research, and working with clients to explain the likely impact.

Bit of a contrast from the traditional “Buy our badly researched and very expensive report, and oh by the way we do consulting so you can CYA even more” analyst!

Right now our solution to this phase is a very soft, consulting-centric sales approach. It is expensive (for us) but it does work. We also do lots of conference talks and articles where we concentrate mainly on industry issues and our experiences, rather than product pitches or “real user case study” type stuff. Our hope is that if you like our approach, find what we say interesting, then you’ll come and talk further.

Picking the right product

Once our Curious Buyer has a good idea of what they want to do, it’s time to pick the vendor. I think this is the easiest bit right now, because the vendors are sufficiently differentiated that once you understand the problem you quickly end up with one or two candidate vendors – so get them in and have a chat with them, and then take up references.

I’m not sure product reviews will help right now. It will be too hard to do an “Apple to Apples” comparison, and without a decent map of the market it will add more confusion than enlightenment for a Curious Buyer.

This is also my concern about case studies right now – rarely are they positioned in a way that allows the audience to understand how their specific needs relate to the needs of the subject of the case study. So you get someone walking out of a case study believing they’ve just heard that it’s perfectly possible to use one ELN throughout your organisation – which is perfectly true but only if you all do the same kind of science!

Summary

I must admit I don’t know the solution to all of this. I know we have a big problem, and I know the first step is to start the conversation – which is why I started this blog.

Using the two models to split the ELN problem up into different areas and data types, project teams can clearly see the different parts of the problem they face and how to tackle each one.

In cases where the demand for an ELN originates from Medicinal Chemists then clearly an ELN from one of the many vendors in this space will service that need, and as this is a relatively mature area of the industry a solution can be purchased in the traditional manner. However, teams should resist the vendor’s encouragement to view all scientists alike as non-chemists are unlikely to be well served by something that is primarily focused on Medicinal Chemists.

For Biology and other areas which don’t draw chemical structures, the demand for an “ELN” is often an expression of frustration by the scientists that they are using computers in their work, but are still forced to use a paper notebook. In that case, their needs may well be met by something that focused on the record keeping functions which are currently being performed by the paper notebook – an aspect rather inelegantly referred to as Patent Evidence Creation & Preservation (PECP). The scientists will rarely require any additional software but if they do it will be focused on particular niches – data management, additional workflow support etc. which will either be very specific or could easily be met with common software they probably already have as part of their standard desktop.

Most R&D organisations would feel a sense of discomfort if the possibility of “Silos” of information were to appear. Fortunately, PECP systems are by definition generally applicable and they can form the central repository of the organisation’s knowledge, available to all. A common PECP usefully reduces legal risk by ensuring common practices across the company, whilst freeing scientists to select their tools of choice without having to compromise as a result of legal considerations.

We need to stop thinking of an ELN as a single product, and more a system of parts integrated together. Some might fear the I (“integration”) word, but with today’s tools and sensible interfaces, it really isn’t a big deal. You can argue that cut & paste, or printing, are perfectly sensible integration mechanisms. I’m no fan of Microsoft, but when everything is on a common platform the only integration pain tends to be vendor pain/stubborness – and in today’s world Cash is King!

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.