First Impressions
Pentaho’s tag line is “Open Source Business Intelligence”, and while I was tempted to evaluate the community edition of the product, I decided I didn’t want to invest the normal amount of time required for open source software.  Therefore I elected the Enterprise edition.  Pentaho is a web deployed application utilizing Tomcat. The installation was simple, however it did take awhile due to the amount of different applications and dependent software that was installed.

Overall, my first impressions of this product were not very good. There are a lot of different applications that combine to perform all of the functionality of Pentaho.  The necessity to move through these multiple applications in order to configure initial configurations and the amount of work required before simple data extraction could occur was significant.  Lastly, Pentaho has a minimum RAM requirement of 2GB, however I really believe more resources are required.  During prototyping I dealt with instability and inconsistent responses that I believe are related to lack of resources by the server.

Positives
Pentaho strives to be a full service Business Intelligence platform.  I believe that the application covers that via it’s offerings of canned reports, schema creation, and a built in ETL tool.  The installer is platform independent due to the JVM and the use of Tomcat, and the end client is accessible via all modern browsers.  For me, this earns high marks because the application can fit into any existing infrastructure.

The end user interface is very clean and easy to navigate from a user’s perspective.  Each user interface request is predictable and sometimes I would forget that I was operating within a browser.  While this may be because I was spending so much time using the other desktop application portions of the Pentaho suite, I still take this as a positive.

Negatives
The Enterprise Version installs with a surprisingly small number of database drivers.  My prototyping database is a SQL Server Database, and I had to research how to install the necessary driver files in order for the application to connect to my selected database.  By not supporting a high cross section of industry standard databases, Pentaho literally requires technical assistance directly after installation.  In the days of shared services, and Project Managers performing initial application evaluations, this is an unfortunate oversight.

As previously mentioned, there are a lot of applications that combine to create the Pentaho suite.  I found this to be confusing and uncomfortable.  After providing the SQL Server drivers for one application, I found that I couldn’t deploy to the server without updating the server drivers.  Or in another instance, I was able to create my report in the Report Designer, however the included JDBC driver for Report Designer was not included in the server installation and was not the same JDBC driver that I had previously installed.  This meant that I had to dig through the Java trace file to determine the driver anticipated by the compiled report in order to install the necessary driver for the published report.

Another drawback was that each application did not have the same look and feel.  I believe this is primarily due to the open source base of the product, however all integral portions of an Enterprise application should have a consistent presentation to the end user.

Lastly, I was confused by the lack of a “Refresh” button for the Analyzer Reports.  Frequently I would change data within my prototyping database and question my schema, only to find that Pentaho was still operating with the cached data.  This would require me to clear the cache and then re-launch the report.  This seems like a frequent use-case and should be automated.

Ad-Hoc Reporting Capability
I spent a significant portion of my time prototyping the Schema Workbench.  This schema allowed for a true Ad-Hoc interaction with the data through the creation of an Analyzer Report.  While the Schema Workbench required ramp-up time prior to producing a valuable schema, I felt there were enough options to address all of the different cubes, dimensions, and measures that were required to map my application data.  I do believe that with enough time spent, I could completely map my application data to present a full ad-hoc data model for the application users.

LIMS Implementation Conclusions
I hesitate to consider Pentaho for a LIMS Implementation.  The application feels a bit fragile, and with the open-source base, I’m convinced that it will required significant IT support to maintain adequate up-time.  I do feel that Pentaho is moving in the correct direction for becoming an Enterprise Business Intelligence tool, however I do not believe that it has reached the necessary maturity to be deployed in a regulated environment alongside a validated LIMS system.

First Impressions
Of all of the tools that I have prototyped over the last few months, none of them is easier to use or has better graphics then Tableau. The installation of the product was very simple and free from any confusing choices.  There was very little setup once the connection to the data source had been created and I found that I could be reviewing data in Tableau within fifteen minutes of starting the installation.  Tableau simply digested the data and presented me options for viewing and manipulate the underlying data sets.  The simple layout of the desktop application allowed for the simple creation of workbooks which could then be published to the server.  Overall I was extremely comfortable with the application in a quick period of time and felt the choices for data display were more then adequate to graphically view the necessary data.

Positives
Tableau immediately engages the user with an incredible graphical display.  Every element of the report is beautiful to look at and elegantly designed.  The “Show Me!” button is a tremendous treat to evaluate how the requested data can be displayed in different formats.

Data consumption and classification is also handled with ease by Tableau.  Either in connecting to database tables, consuming spreadsheets, or digesting text files, the application is able to determine which elements are suitable for measures, and which are appropriate for dimensions.

The drag and drop functions for displaying the data makes working with Tableau extremely user friendly.  The ability to quickly drag elements between being rows and columns allows for quick restructuring of the data until the display captures the intended communication purpose.

The ability to design the data interaction in a desktop environment and then publish the designed workbook out to a server application allows for a cross platform deployment which users can further customize for their own purposes.

Negatives
In order to be useful for LIMS reporting, a significant amount of work is needed to stage the LIMS data correctly to be consumed by Tableau as LIMS data models are optimized for the application and not for reporting.  The hierarchy of the LIMS data will need to be flattened and prepared in the form of database views prior to consumption and display by Tableau.  The simplistic work flow of Tableau is a delight to use, however detailed planning and design would be necessary to provide this rich and easy to use experience to the end user.

Ad-Hoc Reporting Capability
The server portion of the Tableau installation does allow for automatic updating of the data available to the user.  This does increase the usefulness of the data as it can be implemented against a live database, however I do not believe that Tableau could be considered a true “ad-hoc” business intelligence tool.  Tableau aggregates the data and presents it to the user in the relationships pre-determined by the application.  I can find no manner to present to the user a data structure that has been supplemented with meta-data to indicate data relationships and therefore allow the user to operate within these definitions. Although I do believe that a complete view based definition of the data could be designed and implemented that will closely match an ad-hoc approach, it will still be based on pre-designed pathways through the data that the users are forced to use.

LIMS Implementation Conclusions
It is very hard to ignore the wonderful user experience available by Tableau.  I would love to work with this project more as a part of a LIMS reporting implementation to truly test the ability to satisfy end user requirements.  I am concerned that the incredible graphics will begin to wane if there are issues with presenting data in a consistently usable manner for every day lab operations.  I am convinced that the ease of deployment to a web server will require strictly documented SOPs due to the regulated data, and I also believe that the lack of true ad-hoc modeling will not completely eliminate the need for report system maintenance.  While I don’t believe that this product deserves and immediate implementation nod, I believe that a small scale pilot program would be worth the effort to deduce the necessary steps to provide the rich reporting environment that is Tableau.

In my experience, business reports have usually taken one of the following development approaches:

• Rebuild – Rebuild what the business already has in the current LIMS system without asking any questions.
• Standards – Deliver a set of “standard” reports based on an evaluation of the current reports to see which are actually being used by the business and where multiple reports could be combined.
• Business Process Gaps – Identify requirements in the Business Process that cannot be met by a function in the system and deliver a report that fills this requirement.
• Iterative Development – Schedule a working session with representatives from the business and collaborate on the reporting requirements.  Continually refine these requirements through iterative development and test cycles with the end users until the budget is exhausted, or until the Business loses patience and “accepts” the reports.
• End User’s Problem – Deliver “starter” reports designed to show the general LIMS data model and allow for the end users to further customize these reports to fulfill their own purposes.

I believe that each of these approaches can be a valid path based on the approach to implementing the LIMS system.  The scale of the deployment will heavily impact the success of the chosen approach as the number of end users to satisfy will often determine the amount of compromise that is required.

However, possibly the paradigm of LIMS report delivery should actually be challenged. Regardless of the approach used above, they all share the same common fault.  All of these approaches rely on the business use of the LIMS system to remain static, and for data model translations between the business data and the LIMS data schema to remain unchanged.  These approaches make it more and more difficult for value added changes to the LIMS application to be implemented over time as the system becomes locked-in to the data organization expected by the reports.

I believe that a Business Intelligence (BI) approach to the LIMS data would solve this issue. Possibly not every report required by the business users would be able to be replaced by a BI report, however I believe the vast majority could be delivered through the selection of the right tool.  Additionally with a complete data model mapping provided to power business users, the requirement to retain staff for the sole purpose of maintaining business reports could be eliminated.  An appropriate investment into Business Intelligence with the deployment of a new LIMS system could drastically increase the ROI of the project over the long term investment.

This investment, however will not be small.  The challenge with a BI project is to convince the stakeholders that a significant scale BI project will eliminate the slow funding of future static report creation and maintenance. Experienced stakeholders will recognize the value in this approach immediately as they are haunted by the operational cost of LIMS reporting in prior projects.  Others however will need to be convinced of this need due to the intelligent reporting available in many consumer systems available in common web portals.

Over the next series of posts, I’m going to explore a few of the cross platform BI tools that are available on the market and discuss the positives and drawbacks for use with a LIMS deployment.

This is the age old question – and my answer remains as ambiguous as ever!  What may be optimal for one, may not be optimal for another.  It really comes down to the means in which your organization is run, the skill sets that you have on hand (or those that are readily available to you) and the requirements that you have for your systems.

I have heard some recent case studies about companies going to a two-tier LES (basically an ERP and ELN) and eliminating a LIMS altogether.  There are also numerous examples of companies that are deploying a “Thin-LIMS” or “LIMS-LITE” in addition to an ELN and an ERP system.  Other companies are deploying a full throttle LIMS that incorporates an ELN, Lot Management, Instrument Calibration, Sample Chain of Custody, etc.

There may be benefits to minimizing the number of vendors that you deal with and there may also be benefits from cherry picking the best systems for the functions that you want to perform.  The best recommendation that I have is to consistently review your LES portfolio and to look at the strategic means of deploying the best LES possible for your organization.  Think about what you may try and do if you had access to unlimited funds and then how you can get as close to that as possible when you look at things realistically.

Thanks again for the feedback and I would be more than willing to discuss what options and systems may help you and your LES achieve optimality sooner and cheaper!

Selecting a hardware platform for your lab information systems is just as important as selecting the software itself. My advice is to sit with your users and compliance team members to define your hardware requirements carefully; don’t be dazzled by a slick marketing campaign. If you take the time, a detailed set of requirements will allow you to understand your business needs, and also build your basis for cost justification.

Here are just a few of the discussion points to include when interviewing your users:

• When and where will you use the system?
• Will your users be wearing clean room gowns & gloves?
• How will the hardware need to be cleaned? If so, with what solvents/sporacides, etc?
• Will you need printing capabilities for bar code labels?
• Could your manufacturing or lab equipment interfere with the Wireless or RFID?

The good news is that there are vendors dedicated to the manufacture of rugged slate PCs for laboratory and field use. These hardware options have touch screen and stylus based inputs, some even have onboard barcode scanners and RFID capabilities. Best of all – you can drop them, spray them, and since they are sealed and fan-less, you will not create new airflow patterns or introduce particulates in to your environment.  Based on my experience implementing mobile lab information systems, the top two candidates are the Panasonic Toughbook H1-Health and the DRS Technologies Armor X10. While the Armor X-10 has a solid customer base, the H1 has a sleek and easy to clean design as well as on-board bar code scanner and other ease-of-use tools.

There are rugged hardware and software platforms that can take your lab from being 100% paper based to virtually paperless – it is being done in pharmaceutical labs on a global scale. When done correctly it will save you countless work hours that are currently spent completing, tracking, reviewing, correcting and filing paper forms.

The reason for this challenge was simple, most of these managers had been exposed to plenty of lab based projects where the primary IT function was to support the validation team for hardware validation. With validation requirements at the forefront of experience, it was my job to make a convincing case for the software development tools and process required to deliver a quality product to the validation team for successful implementation.

The very first requirement is a source code repository. This tool is critical to the delivery of fully tested code for validation testing because it provides a means of control. Developers must be able to have immediate access to the latest version of the code that is being developed and have confidence that their developed code is secure. Additionally with a properly implemented source code repository there is the ability for multiple authors to contribute to the same source code files and merge the updates once completed. The source code repository must be able to keep all versions of checked in code, and developers must check-in their code on a pre-defined basis. Depending on the testing cycle, this is usually daily or at each functional milestone. While there are expansive source code repositories available for purchase, I recommended investigating CVS and Subversion before making any purchases.

The second requirement is a common development environment. Every developer must be working from the same source files and library files and usually with the same IDE. Project priorities and assignments may shift, and the development work must be able to transition between resources without a concern about compatibility of development environments. Prior to the start of development, the optional development environment should be determined and documented so that all developers can configure their workstation according to the requirements.

The third requirement is a specification and defect tracking tool, when possible implemented as part of a team collaboration tool. By tracking each specification, and each associated defect, the time-line of each deliverable is established and measured. This is critical for defending development practices in addition to providing the team with a sense of organization around final product delivery. See my post on the requirements for a collaboration tool for additional information about the benefits of a well implemented collaboration tool.

The final requirement is a delivery procedure. A rock solid delivery procedure ensures that all of the effort that was invested into the final delivered code is not marred by the incorrect version of the code being released to production. The delivery procedure should ensure that the version of code that the developer has marked fully functional, is the same version that the tester has proven meets the listed specifications, and is the same version that the validation resource proves meets the expected functionality when installed into a controlled environment, and is the same version that the installer puts into production to be used by the end users. If any of these transitions are not planned for and implemented according to procedure then the entire team will be questioned due to the lack of quality within the deliverable.

While there are many other necessary requirements for a successful software development project, these four should be a starting point and a cornerstone of your project.

If you have any questions or suggestions for future presentations, please let us know.

The reasons for this situation is usually because the project has not been presented or framed with the expectation that there will be customized development activity. This could be due to terminology by the vendor, the framework of the application, or a lack of understanding the true extent of the gaps that have been determined during the Business Analysis stage of the project. In large organizations this perception is even further clouded when the IT department is organized into “Shared Services”. One group will provide the databases, another group will provide expertise in setting up Tomcat, a third group will provide recommendations and deliver the necessary virtual servers, etc. This will all sound wonderful as is usually is fronted with a Shared Services Delivery manager that will ensure that your project will receive all of the necessary pieces from all of the internal vendors on time according to your project plan.

If you don’t know that you are running a development project, then you likely won’t manage the project correctly, and there most likely will be significant problems. To avoid this, answer the following questions about your project and use the answers as a conversation starter with your team to determine if your project is actually a development project:

1. The project has completed user requirements and the project team is expected to deliver a modified version of the vendor project package to fill any gaps that have been identified.
2. A portion of the deliverables for your project include reporting on data that is contained within an information management system via paper reports or via any mechanism outside of using the provided screens within the application such as a business intelligence solution.
3. A consistent configuration must be applied to the software installation in production. This may need to match a previously tested or validated configuration, or it may mean that there are multiple production environments that are required to be configured identically.
4. The newly installed application will be required to interface with a legacy application or other technology solution.
5. The selected vendor is providing for your team a specific version of the product that your team will be responsible for installing and accountable for future end-user support and break/fix activity.
6. In the documents section of your project plan, there is a task to draft an SLA for your end users or other business functions in your organization.
7. You plan for extensive testing of the product after receiving it from the vendor and prior to officially validating the implementation for use by the end users.

Stay tuned for my next post to learn how to outfit your (possibly newly discovered!) development project team with the tools for a successful delivery.

As we all look at our personal portfolios and readjust as desired – the same must be done with your Laboratory Informatics portfolios.  Decisions need to be made.  Are you throwing good money after bad?  Or conversely– are additional investments required in order to gain more value from your systems?  While it is human nature to formulate opinions and have preconceived notions about your environment, it is important to take an objective analysis of your LES (Laboratory Execution System).  We all have been part of projects that have been loved by some and loathed by others.  A strong leader will embrace these differences of opinions, and when used constructively, these contrarian viewpoints can help drive an optimal outcome.

When you are close to realizing a vision, the decisions are easier.  However, if the vision is blurred, it provides a good opportunity to perform this objective analysis.  I believe that there is no better time than the present to get out there right now and evaluate one’s portfolio.  There are systems that will potentially bring a large ROI and it may take an investment to realize this return.  Don’t throw good money after bad, throw good money after opportunity!

If the last car you bought was a lemon, it doesn’t mean that you never buy another car, right?  Its always good to take a step back, catch your breath and evaluate how your current LES fits into your overall informatics strategy.  And remember – the strategy should be a living strategy as today’s technology may already be dated tomorrow.