As a general rule Apple MacOS X, Linux are second class citizens in the ELN world and it is all the salesperson can do to stifle a laugh when you mention those “other platforms”. The iPad and Android equivalents don’t even get a look in!

I’ve felt this situation is increasingly unsustainable – not only is Apple’s Macintosh experiencing a resurgence, but we’re quite possibly on the cusp of a tablet-drive revolution.

An interesting blog post from the CTO at the UK’s Department for Work and Pensions wonders if their current Windows desktop refresh might not be their last.

Personally, I think it likely this is the last version of Windows anyone ever widely deploys, though.

The reason? I think they’ll be fewer workloads that actually require a heavy deskop stack. Today, of course, we have all this legacy that’s coupled to the desktop, but in a decade, I really doubt that will be the case. Most stuff will arrive via the browser.

Talking with our larger Enterprise customers, it appears their Windows Desktop infrastructure is increasingly cumbersome and it is very hard to innovate in such a complex environment. In the smaller Biotechs there’s a real push to avoid cumbersome IT generally and there’s ready adoption of web and Cloud technologies, as well as additional platforms such as Macs and iPads.

The article makes a good long term point which ELN project teams should urgently consider:

From a strategic point of view, if you’re designing the future technology estate of a large organisation, that last thing it makes sense to do in this kind of context is build stuff that depends on a desktop stack. Furthermore, decoupling legacy from the desktop stack also has to be on the agenda, because you just can’t count on that stack being relevent in 10 years time.

Most ELN products on the market are tightly linked into the Windows ecosystem, even to the extent that one vendor just trumpeted the re-launch of their ELN which is now completely based on SharePoint!

My feeling is that organisations looking for an ELN which is going to last for more than 2 years should consider a situation where there are more than just Windows Desktop PCs in their IT infrastructure – not an unreasonable consideration, but one that needs thinking about up front rather than purchasing a product that locks you in to a dying ecosystem. The Windows PC isn’t going to be replaced but it won’t be the only way you’ll want to access your ELN, and whatever you select needs to be able to work with whatever you might adopt. That such lightweight “thin” solutions are easier to deploy than a thick client just icing on the cake.

(update: this story has been picked up in The Register)

A good Electronic Lab Notebook takes careful design; the foundation of this is what does, and more importantly what it doesn’t do. This is really hard, as evidenced by the complexity that can creep in to products as you add feature after feature. Apple’s success is built upon design and the fact that better-resourced competitors can’t keep up shows just how difficult it is to get design into your corporate DNA.

I’ve always felt that ELNs are particularly susceptible to “Kitchen-sink” tendencies; the term is so badly defined, and the potential use cases so broad that you can easily find yourself needing to add more and more functions until you end up with an unholy mess which then:

• Requires a lot of consulting to customise the application to fit the needs of any group of scientists
• Is complex to master, requiring quite extensive training time

In PatentSafe we’ve taken a different approach – less is more. Our aim is to allow our users to use any application as part of the ELN experience, and we’ve come up with a handful of basic concepts which can be mastered in lass than 15 minutes and allow the user to use all their existing applications and work processes unchanged.

I’d to claim this is as a result of an amazing design philosophy but in truth it is a product of where we started. Most ELN companies started either in big Pharma (or were swiftly pointed in that direction by their VCs). Amphora in contrast started out working with Kodak and then into companies such as DuPont, PPG and J&J – doing really very large deployments (100′s to 1,000′s of users). When you’re rolling out that many seats especially into the very diverse research environments of chemical companies, you have to keep things ruthlessly streamlined and build on what’s there, because it is just physically impossible to customise the ELN for each group.

When we started to work with Biotechs this experience really paid off:

• Biotechs don’t have the resources to pay for a long consulting engagement and lots of software
• Biotechs will often change their entire business over a period of years; if their ELN was overly customised it would be hard to prevent it becoming a business-threatening impediment to change

It is interesting that Biotechs really have a lot more in common with diverse Chemical companies when looked at this way; most people seem to think Biotech is just little Pharma, but nothing could be further from the case when you are deploying IT.

Less-is-more is also helping us as we move into additional devices such as the iPad. PatentSafe is device-, application-, and discipline-agnostic, so the iPad just fits right in.

When we first started out I was always worried that we would need to add a lot more functionality to the core product to meet market demand. It turns out that resisting this was one of the best decisions we made as a company – we now have a product that can be dropped in almost anywhere and used immediately, which is dramatically different from the alternatives (so much so that people often think we’re lying when we say no consulting and 15 minute training time!).

I can’t help but feel that our market-leading presence is down to what we decide not to do, instead choosing to work with what’s out there. I’d like to think that what we’ve done is technically excellent, and PatentSafe has a number of very powerful features. But it is the features we chose not to implement which make PatentSafe so quick and easy to use, and able to stand the test of time as our customers’ business change.

(this post was inspired by “Simplicity isn’t that Simple” on 52 Weeks of UX blog.

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.

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…

Basically SaaS is not a magic bullet for enterprise apps, the problems associated with large complex software can’t be magicked away just because someone else runs the software for you.

Our hosted products and SaaS products are identical, as is our deployment methodology. I’d like to think we’ve put in the design time to ensure that deploying a replacement for the paper notebook is as painless as possible. That’s the result of experience and careful design, which I hope produces the same results regardless of how it’s deployed – on premises or SaaS. That some of our customers find purchasing our products as a Service is more a matter of convenience and economic preference.

“McAfee’s Hypothesis: Within organizations, collaboration technologies are dictated by the most powerful person involved in the collaboration.”

I’ve become increasingly concerned that what’s said in public forums (e.g. articles, conferences etc.) isn’t a true reflection of what’s really going on. A lot of ELN systems are being introduced based on tools companies already have (Microsoft Office being typical), and those don’t get any publicity (no vendor to push it!), and of course you never hear about the problems, disasters, and near misses!

This systemic fault in how the industry communicates is really serious – and will result in an awful lot of money being wasted, and our credibility damaged – just because people think doing X is the safe way (for any given value of X), but in fact the case study they’ve seen was the only one where X has worked and there are 10 other people who tried X who have hit really serious problems (often fatal).

Given the nature of our business and product we see an awful lot of ELN projects across a wide variety of businesses, disciplines, and vendors. What we’re seeing in terms of best practice is at times completely contrary to what you’d think listening to conference talks, reading magazine articles etc. Of course, there’s no reason to suggest we’re right and everyone else is wrong, but on the other hand there’s a huge gap and that’s a worry.

So my presentation was an attempt to draw attention to this and propose some solutions:

• Be very careful about the use of the “ELN” word, as it’s too ambiguous. Ideally, stop using it entirely. It is especially useful to get vendors to describe their offerings without using the term “ELN” – then you find what their real focus is.
• Keep the ELN project as simple as possible. I mentioned some of the frameworks we use for this – The Triangle, Broad Vs Deep, etc.
• Blog – read blogs, and join in yourselves.

You can download a copy of the presentation here here. I had some interesting chats with people afterwards – I’ll try to expand on some of these points in future posts.

As an aside, I’ve nearly given up on SlideShare – the Keynote conversion process doesn’t seem to be working well.

Update: Rich Apodaca over on Depth-First makes some contributions here.

We didn’t know what the attendees were going to want to cover so I must confess the presentations don’t read as well as they hopefully came across. However, I hope they will provoke some thoughts all the same.

My overall proposition is that Biology is a very different beast from Chemistry and what works in Chemistry – the products, approaches to the projects, rollout strategies, etc. all need to be reviewed in the light of the special challenges of Biology environments.

There were two main presentations I used. The first looked at the ELN story from Chemistry from Biology and some of the differences between the two. You can download it here.

The second presentation looked at the Technology Adoption Lifecycle (TALC), which was first described by Geoffrey Moore in his book “Crossing the Chasm”. The TALC describes how people react to discontinuous/disruptive innovations and how you can help your innovation get adopted as easily and widely as possible. My contention is that Biology userbases are sufficiently complex that you should use Chasm-crossing techniques to both develop and deploy your ELN. You can read the presentation here.

Interestingly there were a number of people in the workshop who had successfully deployed an ELN into Biology and they had used Chasm-crossing techniques to do so – not because they’d heard of the concept (they hadn’t) but because it was the most sensible approach.

I’ve also uploaded the presentations to SlideShare, but the conversion process is taking some time. Once they are up the SlideShare versions should have the transitions and builds etc. which might make for a better reading experience. They should be on my SlideShare page in due course.

There’s lots of other stuff that came up in discussion, which I will try to cover in later blog posts. For example:

• What you see in conferences and publications in terms of case studies etc. isn’t representative of what’s really going on. There’s a lot of in-house development, a lot of use of Microsoft Office and other applications – but because there’s no vendor involved, they don’t get publicity because most publicity needs paying for, e.g. speaking slots, article placements etc. Sadly these are often the most successful deployments of ELN functionality – but it didn’t come from a vendor with “ELN” stamped on the box!
• I don’t believe you can have one ELN for Chemistry and Biology – or even for all of Biology.
• All of this is dependent on your definition of “Chemistry” and “Biology” – and this varies from company to company. In particular big Pharma seem to conduct a restricted set of activities on a very large scale (perhaps because all the really weird stuff is effectively outsourced to Biotechs) – which makes taking lessons from any company very difficult.
• Of course, sales and marketing efforts by various vendors do nothing to clarify this already muddled picture!

Not that I mind that too much

(of course any vendor can claim a SaaS offering, just as any vendor can claim to be web-based by wrapping their thick-client application in IE. Unfortunately there’s a world of difference between a marketing-led “Paper over the cracks” effort and a true solution. Tthe economics of SaaS will mean those vendors will quickly find their customers don’t renew and then it’s game over.)

Sadly we’re all conditioned to this, accepting it as the norm – to the extent that users feel bad because they can’t immediately use the product, and companies require as a matter of course that their vendors provide extensive documentation and training to make a badly designed product usable.

The Electronic Lab Notebook industry is no stranger to these problems, and in fact suffers more than most. Products are designed by Geeks (of the IT or science variety), evaluated by teams concentrating on feature count, and thrown at users who are just required to use them.

I’ve always been concerned with the problems created by the ELN selection process, but even when a product has been selected adoption is hampered by usability issues. Good products shouldn’t need extensive consulting, training, customisation to enable the users to be productive – they should “just work”. Of course there should be APIs and the ability to customise the system (and our products do) but that work shouldn’t be a requirement to get things going.

One of the best early decisions we made was to hire an Information Architect to work on PatentSafe. What I learned is that Usability isn’t just a matter of a nicely designed User Interface, it’s also about the concepts that the software exposes to the user. In fact, consistency and transparency are more important for usability than “prettiness”.

There’s a good article on ComputerWorld on how Bad Software Design Inhibits Use of Enterprise Apps. Some choice quotes from the article (I’d encourage you to read the full thing) with some comments…

“Software manufacturers are generally confident that their products will succeed on the strength of their technology,” Hambrose writes. “But products that don’t appeal to their users can be self-defeating. Whenever software systems create obstacles-technical jargon, ambiguous messages, illogical sequences or visual clutter-the people who use these systems will respond in a variety of ways.” That typically includes undesired behaviors that users (and CIOs and applications managers) know all too well-frustrating and inefficient workarounds, complete disregard for business process, or abandonment of the application altogether.

As a vendor I’m always interested in hearing from users about how we can improve our products, and it’s depressing the number of times something’s not quite right and they just live with it rather than shouting. All the stuff in PatentSafe that makes people go “Wow” has come from conversations which have started from us probing into what a user thinks is a minor issue not worth actually mentioning. This is the major reason we visit our customers face-to-face, and I often come away with half a dozen new feature ideas.

Sadly so many companies buy stuff over and above the real interests of the users – because the user’s don’t have a voice, or because they don’t know what to ask for. Yes, there are user representatives on the purchasing committee but they suffer from what I call the Toaster problem. Again from the article:

“Hambrose: It’s the same problem, different day: dashboards, CRM systems, or whatever is coming down the pike this month. And the dashboard suffers from same problem. The consumers of the technology-the business side of the house-don’t know how to ask for what they need. They ask for what they want. That’s different than understanding the need. The tech group on the other side of the house, they’re ready to buy or build what’s asked for.

Finally, I loved this bit on what happens when they are invited into product demos. (it’s a bit too large to quote in full here).

Some days I feel we’re punished a bit by evaluators because PatentSafe is too straightforward to use. Yes, there’s a lot of power there but we’ve worked hard to make the learning curve shallow and ensure you only need to understand the bits that are relevant to you. It really does take a lot more thought and effort to design a “simple” system rather than an complex one, a lot of watching how people adopt the system, and good communication with customers long after they’ve purchased and deployed the system. Ironically sometimes people evaluate PatentSafe against other products which take a week’s training and customisation, and feel the other solutions are somehow more “powerful”. Of course, they aren’t – they just make the user work harder.

This is why we encourage prospective customers to pilot – use the system in real life, get a feel for it. 90% of the time, they fall in love – even when compared like-for-like with other products and approaches. The other 10% is where we learn a lot about how to make a better product.

By the way, our IA is Karen Roles, she’s an excellent Information Architect and available for contract work – you can see her Portfolio here. We like her to come back every now and then to make sure we haven’t strayed too far from the One True Path

Chuck Norris can fix everything without changing anything

And therein lies some of the problems people are hitting on ELN projects – they think that the old way of doing things will produce, if only they do it properly.

I’d argue that the old, “Big Software Project” way never worked all that well for something as diverse as science, and it certainly doesn’t work today – there just isn’t the money around to throw about hoping it will all turn out OK.

The blog post invites customers to ask: “Are our projects repeatedly late, over-budget, or not meeting planned expectations?”. Um, time for the ELN industry to look in the mirror!

Today we have to have the guts to admit that perhaps “One size fits all” (more accurately “one size will be made to fit all, dammit!”) approach isn’t the best way to approach very complex circumstances – even the best-designed software can’t compensate for the challenges of deploying very intimate software to a wide variety of use cases.

It’s time to tell our boss that we need a series of smaller projects which are more approachable, predictable, and less risky. If you work with the right vendors (and we’d hope we were one!) the total cost will be much less, your users will be a lot happier, and you’ll end up with a more integrated system than perhaps you can buy from someone who promises you can get everything from them.

Time for the quiet heros, delivering on time and under budget. Shame that doesn’t get the same press though.

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.

Standards can not force a vendor to be interoperable. If a vendor wishes deliberately to withhold interoperability from the market, then they will always be able to do so, and, in most cases, devise an excuse using the text of the standard as a scapegoat.

You can’t rely on any representations about a “standard” unless there’s clear evidence of different implementations working together.

This really matters for ELNs, for two reasons:

• Your data is locked up in the ELN unless you know you have proved you can get it out.
• The need for long term (typically 30+) access to proof of experimental activity for Patent purposes means you can’t rely on any of the existing vendors being around, or the software you are currently using being functional.

We recommend that customers reassure themselves before they purchase any ELN product that they can get the data they need out into some suitable format – you have leverage with your supplier before you purchase, after that you’re locked in. I am amazed how many customers are aggressive about price discounts etc. but don’t look carefully at the “open data” situation – which is surely much more important than a 3% cost saving on the license price.

There are a number of ELNs around at the moment which can’t reliably create a PDF of the experiment. To some extent it’s a hard problem, but my concern is the “How do we get our data out” is answered with a wave of the hand and “You can just export to PDF” and everyone takes that at face value. In fact in some cases the PDF export facility is unreliable, doesn’t contain all the data, and can’t be automated! Buyer beware…

In terms of picking good “standards” we prefer published, straightforward, and well-used file formats. In our case that currently means XML and PDF/A, both of which are very open and used extensively by a wide range of software.

…simplify the authoring of chemical information in Word – specifically the inclusion of chemical structures. This project will also demonstrate how semantic information can be captured at authoring time as the way to more accurately represent the chemical content, create high quality depictions, contribute to simpler pre-publication processes and richer information discovery scenarios, as well as to preserve chemical information for archival purposes.

We did a similar thing in Lotus Notes ages and ages ago, and it worked really well. I wonder how much of the “I want a chemistry-centric ELN” question this will end up solving (not all of it but it will have some impact I am sure).

This entry by Simon Phipps explores the benefits of loose coupling in the enterprise:

the source of many costs in IT infrastructures result from different organisational units with no (or distant) shared management being forced to create technical interdependencies in order to co-operate. The less technology we are forced to share in order to co-operate, the less we will have to pay to get started and the less we will need to pay in the future to maintain – or remove – the ability. We need to stay loosely-coupled – connected by the least possible thread of technology.

The safest, cheapest, and most reliable way to joined-up research is loosely-coupled integration between various specialised systems. This is actually pretty easy to achieve (especially with open data formats and APIs) and empowers the customer organisation rather than leaving them at the whim of a vendor.

“Open government meets IT”: “Starting in mid-June, the District of Columbia would begin releasing operational data from a variety of city agencies to the Internet in several XML formats, including RSS and Atom.”

How cool would it be for instruments to make their results available as RSS/Atom feeds…..