Brief thoughts on the future of scientific UIs

 Architecture, ELN Design, Industry  No Responses »
Dec 222009
 

I’m not a great fan of the term “ELN” despite the name of this blog, only because it means too many different things to many different people. As such it confuses things rather than aids communication.

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…

 Posted by Simon Coles at 8:33 pm

“Networked Laboratory Information”

 ELN Design, Industry  No Responses »
Oct 012009
 

Over on Depth-First Rich Apodaca picks up on the problems with the “ELN” word and as a thought experiment makes a proposal for “Networked Laboratory Information” as being a starting point for thinking about Lab Informatics (as opposed to starting from something centred around the Lab Notebook):

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?

 Posted by Simon Coles at 4:09 pm

Responding to RFPs

 Amphora, Industry  1 Response »
Sep 042009
 

There are few things I find more painful than responding to RFPs.

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.

 Posted by Simon Coles at 3:23 pm

Economists, the Credit Crunch, and ELNs

 Industry, Project Management  No Responses »
Jul 262009
 

In today’s Sunday papers there is a story about a bunch of Economists writing to The Queen to explain why they missed the Credit Crunch. Here’s a shorter article by the Huffington Post which might appeal to US readers.

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.

 Posted by Simon Coles at 10:17 pm

Use of Open Source in Commercial ELN products

 Amphora, Industry  3 Responses »
Jul 172009
 

On the (rather hard to get into) LinkedIn ELN group, there was a question about the use of Open Source components in commercial ELN products.

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.

 Posted by Simon Coles at 11:59 am
 Older Entries  Newer Entries
© 2011 elnblog.com Suffusion theme by Sayontan Sinha