Reach1to1 Technologies - scalable business tracking solutions for field and channel sales, order processing and customer support - Part 3
  • About

    Reach1to1 Technologies is a provider of business solutions using the latest web technologies. With a complete range of standard products that can be customized and setup in a matter of a few days, Reach1to1 can help your business integrate your entire workforce including employees, suppliers, channel partners and customers with web based applications.

Making LIMS Work

What is LIMS?

Laboratory Information Management Systems are specialized applications for laboratory automation that offer significant benefits:

  • Optimal utilization of laboratory resources
  • Reduction in manual operations and errors due to repeated data entry
  • Adherence to regulatory requirements
  • Standardization of procedures and enforcement during actual operation
  • Collaboration and sharing of laboratory information with other departments and customers
  • Automatic collation of test results into standard reports
  • Instant identification of anamolies and exceptions

Challenges in LIMS implementation

Several laboratories realize the need for installation of LIMS to automate the processes in the laboratory, but LIMS installations are not cheap, and certainly not easy. The main hurdles in LIMS implementations are:

  1. Wide vareity of testing equipment – Laboratories use a wide vareity of testing equipment such as pH meters, balances, spectrophometers, autoanalyzers, and chromatography data systems. In addition, specialized laboratories have testing equipment specific to the type of samples that are tested. Though most standard LIMS packages have built-in facilities for integration with most standard equipment, there is significant effort required to integrate LIMS with non-standard or non-computerized equipment.

    Based on our experience of studying LIMS requirements and solutions, we have a different view on handling this issue in LIMS installations. We have found that laboratory technicians, especially in smaller laboratories, are not overly bothered by having to record test results manually. In fact, we would venture to guess, that if a LIMS solution were to merely provide a mechanism to manually export data from computerized data loggers that are anyway used with most modern testing equipment, it would more than suffice the requirements of small and medium sized laboratories. As for those equipments that do not have any computerized data loggers, test readings anyway need to be recorded manually – in which case, the technicians can directly enter the data in the LIMS forms.

  2. Different operating procedures – each laboratory has its own operating procedure, based on the industry and nature of operations or tests carried out in the laboratory. The sequence of processes, data formats used to record test results, sources of information, formats of reports generated, everything changes from one laboratory to another. Standard LIMS packages do have facilities for customization or configuration to a certain extent. However, there is almost always a need to write custom code.

    As Colin Thurston, Senior LIMS Product Manager at Thermo Electron Corporation, in Altrincham, UK reports in Scientific Computing World – LIMS: WORKFLOWS

    In a typical LIMS, the sequence of work is broadly fixed, with no logic built into the sample lifecycle. Limited modifications are normally possible at each individual step, usually actioned by the system administrator. For example, changes in status of a sample such as ‘login’, ‘testing complete’, or ‘authorised’, would lead to different options being available to the user. Changing the sequence of events, or adding further logical branches (e.g. if . . . then . . . else nodes) to the sequence, usually requires the development of custom code, generally in the programming language of the LIMS. This can often be a proprietary language unique to that LIMS. Such customisation is not only complex and expensive, but it can lead to problems for the customer when upgrading or validating their LIMS. The consequence can be significant delays in going live. R&D and contract research laboratories handle many different types of analyses, so they need to be able to add or amend workflows quickly.

    One approach that is used by some LIMS providers such as Thermo Electron Corporation is to use workflow management technology to handle this burden of customization by providing graphical editors that can be used by the laboratory technicians themselves to customize the process at any time during the life cycle of LIMS.

    This is certainly a step in the right direction. As consultants for workflow management solutions, we completely identify with their vision in using workflow management to alleviate customization requirements. However, merely giving a graphical tool to edit process descriptions has its limitations.

    We have found that any workflow management solution that is purportedly easy to customize by using graphical process modelling requires significant skill enhancement of users. There is no doubt that simple process modifications are easy to handle in a graphical modelling tool. However, it is far easier to write a procedure in a programming language than using a graphical process representation, if a programmer is available when required, and if modifications to the process logic can be made on-the-fly.

    It is these two attributes :

    1. Availability of a programmer when required and
    2. Ability to modify workflow logic on-the-fly

    that makes a workflow solution successful. This is precisely the reason why we insist on LIMS, or any other workflow implementation as a software service and not a one-time product installation.

  3. Customization requirements during change in procedures or software upgrades – If a laboratory implements a standard LIMS package, but with significant amount of customization, the customized version may become incompatible with new upgrades of the LIMS package. As Thurston reports

    Upgrading will be complicated if there has been significant customisation. Is the code compatible with the new version of the LIMS? Do you have access to the people responsible for the code – contractors or in-house? If not, implementation services may need to be purchased, again, to re-implement the customisation. All this adds unwelcome complications to the upgrade process. And, of course, once re-implemented, the system needs to be revalidated.

    Having a LIMS customised this way also presents problems should there be changes to laboratory procedures. When changes to the mapped workflow are required, the client may have to re-program the LIMS. This may then entail revalidation of the affected subsystem.

    Again, this problem only occurs if LIMS is installed as a one-time package, and not when LIMS is treated as a software service.

  4. Integration with existing systems – Laboratories may already have some software systems and LIMS needs to be integrated with those systems. This integration is also case-specific, requiring additional efforts and cost.

    As Jason Simpson reports in Integration Of LIMS Offers Compelling Advantages For The Production Environment,

    Under increasing pressure to harmonize their business processes, science-based organizations are taking measures to standardize on computing applications such as Laboratory Information Management Systems (LIMS) and also to integrate these with enterprise platforms and systems. Often different locations within the same organization will employ information management systems from a variety of vendors for the same purpose. Industry mergers and acquisitions have only added to this diversity. For these reasons, it is no surprise that the standardization and integration of systems typically represents around 30% of IT budgets.

    Most standard LIMS packages have built-in facilities for integration with external systems using APIs (Application Programmers Interface). However, some LIMS packages like Thermo Electron Corporation’s SampleManager LIMS are beginning to use XML-based standard integration facilities, or Web Services to allow easier integration of LIMS with disparate systems.

    Our LIMS solution, offered as a completely Web based system, uses XML not only as a way to integrate data with external systems, but as a native object database technology.

Summary

LIMS can make a huge difference to the productivity of an R & D Laboratory. However, a standard LIMS package may not be the most suitable solution, due to the amount of ongoing customization required as is typical in an evolving enterprise – of which a Laboratory is a prime example.

However, if a LIMS solution is built and delivered as a software service by utilizing workflow modules as building blocks, with a scripting language that can be used for on-the-fly customization, evolution of the code can match changing requirements of the laboratory.

Also, creating LIMS as a web-based service, with a native object database to store and retrieve data, integration with other disparate software systems can be done with a minimal overhead and cost.

Posted in Laboratory Information Management, Workflow Management | Leave a comment

Why Open Source?

What role does open source play in bringing affordable technology to evolving enterprises? We would like to cut through the hype of free software and get down to the bottom of why open source makes sense, when, and for whom.

The most celebrated success of open source is without doubt, the Linux operating system. But how many people are really using Linux? And how can / does it benefit us? We like the way Time O’Reilly asks in Open Source Paradigm Shift:

“How many of you use Linux?” I ask. Depending on the venue, 20-80% of the audience might raise its hands. “How many of you use Google?” Every hand in the room goes up. And the light begins to dawn. Every one of them uses Google’s massive complex of 100,000 Linux servers, but they were blinded to the answer by a mindset in which “the software you use” is defined as the software running on the computer in front of you. Most of the “killer apps” of the Internet, applications used by hundreds of millions of people, run on Linux or FreeBSD. But the operating system, as formerly defined, is to these applications only a component of a larger system. Their true platform is the Internet.

Without us realizing it, almost everyone is using Linux. You are using Linux right now if you are reading this post online (our servers are running Linux too). Like O’Reilly says, the true platform is the Internet. Software applications are moving out from the desktop and on to the Internet. O’Reilly also elaborates on the 3Cs that drive the move towards open source:

  • Commoditization of software
    Just as computer hardware has become a commodity by the open standards of the PC, been driven by the commoditization of the PC architecture, software growth will be driven by commoditizing the software architecture.

    Software commoditization has been driven by standards, in particular by the rise of communications-oriented systems such as the Internet, which depend on shared protocols, and define the interfaces and datatypes shared between cooperating components rather than the internals of those components. Such systems necessarily consist of replaceable parts. A web server such as Apache or Microsoft’s IIS, or browsers such as Internet Explorer, Netscape Navigator, or Mozilla, are all easily swappable, because in order to function, they must implement the HTTP protocol and the HTML data format. Sendmail can be replaced by Exim or Postfix or Microsoft Exchange because all must support email exchange protocols such as SMTP, POP and IMAP. Microsoft Outlook can easily be replaced by Eudora, or Pine, or Mozilla mail, or a web mail client such as Yahoo! Mail for the same reason.

    This commoditization of software converts the software as a product into software as a service. Users of software no longer need to purchase software licenses. They use the software as a service. O’Reilly quotes Clayton Christensen, the author of The Innovator’s Dilemma and The Innovator’s Solution:

    in this type of market, the drivers of success “become speed to market and the ability responsively and conveniently to give customers exactly what they need, when they need it.”

    There are now emerging leaders who have leveraged this business model of Application Service Providers such as salesforce.com, google.com, amazon.com, and scores of smaller local players, Reach1to1 being one of the emerging ones in India (could not resist that :-) )

  • Collaboration over networks
    Having the Internet as a platform for software provides another major network effect – of collaboration. Open Source projects depend largely on contributions by independant developers working collaboratively to enhance the value of the code. Services like eBay are intrinsically collaborative services (what’s the use of an auction if people cannot bid openly?) Others like Amazon have created a collaborative layer over the traditional product-selling model – by allowing user participation in the form of reviews, recommendations and a resellers program. Another interesting model is the one introduced by Napster for music and data sharing:

    Because Napster set its defaults to automatically share any music that was downloaded, every user automatically helped to build the value of the shared database. This architectural insight may actually be more central to the success of open source than the more frequently cited appeal to volunteerism. The architecture of Linux, the Internet, and the World Wide Web are such that users pursuing their own “selfish” interests build collective value as an automatic byproduct. In other words, these technologies demonstrate some of the same network effect as eBay and Napster, simply through the way that they have been designed.

    We also note from our own experience that the most interest we generate from prospective clients for the software as a service model is where collaboration within a geographically disperse community is required – such as project management, sales force automation, channel integration and supplier integration.

  • Customizability of software
    This is, from our perspective, the largest factor that determines the neccessity of open source. Software is traditionally viewed as a product – something that is built once, and used repeatedly – with a few upgrades thrown in. However, applications in the new paradigm – like Yahoo, Google, Amazon or eBay, customization is an ongoing process of evolution. Similarly, for automating business processes of evolving enterprises, software is not a product that is built only once. Enterprises evolve by constantly fine-tuning their processes, products and services to match market dynamics. Software that empowers such businesses need to be agile and mimic the evolution. As O’Reilly puts it:

    We’re used to thinking of software as an artifact rather than a process. And to be sure, even in the new paradigm, there are software artifacts, programs and commodity components that must be engineered to exacting specifications because they will be used again and again. But it is in the area of software that is not commoditized, the “glue” that ties together components, the scripts for managing data and machines, and all the areas that need frequent change or rapid prototyping, that dynamic languages shine.

    It is this very property that prompted us to adopt Perl as our primary development language. The flexibility of Perl, combined with the plethora of open source modules available on CPAN, where any developer can publish modules that extend Perl, creates an ideal platform for creating agile software that needs to evolve continuously.

    Perl provides a component-based architecture with an ideal glue language, allowing us to write code that can be customized easily and continuously. To extend this flexibility to the data model, we have used Object Databases that allow databases to be customized as and when required.

In conclusion, the open source software paradigm provides an ideal platform for developing business applications for evolving enterprises that involve collaboration and constant customization.

Posted in Affordable Technology, Evolving Enterprises | Leave a comment

Software for Everyone

Maryann Jones Thompson, editor of sandhill.com reports in her article Software for Everyone about a panel discussion held as part of Software 2005 between

  • Iain Morris, senior VP, AMD
  • Nicholas Negroponte, Professor & Chairman, MIT Media Lab
  • Teresa Peters, executive director, Bridges.org
  • and moderated by David Kirkpatrick, technology editor at Fortune

where they discuss the next big revolution in information technology – bringing IT to the poor. They note how companies like AMD are bringing down costs of hardware so that computers can reach a larger part of the 6.4 billion people in the world today than the current penetration of a mere 15%.

However, more interesting are the points they note about what needs to be done to bring software to the poorer parts of the world:

  1. Lower cost and ease of use of software

    “At least 50 percent of the remaining cost [in the $100 laptop] is the ‘fat’ in software,” says Negroponte. He claims today’s software is so difficult to use that it impacts the ability of the developing world to take advantage of it let alone pay for it.

  2. Develop localized content and training

    “The ground-level realities are that people need to be trained,? says Peters. ?There needs to be locally developed content. When you talk about poverty, you need content focused around education, but also healthcare and small business development Going from 50 people to 6 million is a tough jump in terms of training…”

  3. Fund local technology providers

    “The technology solutions come from overseas. Local, small companies cannot get the attention of those with funding.” Peters would like to see the private sector in the U.S. and elsewhere around the world work closely with local providers to help them get the attention of global funders which would increase the effectiveness of local technology solutions.

But there are a couple of more points we would like to add to the wish list:

  1. Reduce the cost of customization
    One way to do this is to involve local companies in the region. However, to really achieve the benefits of software to grow small businesses, we need to build software that is far easier to customize. Our vision:

    • Component-Based Architecture makes building customized code easier,
    • Object Databases make building customized databases easier, and drastically brings down the impedence mismatch between code and data while customizing software.
    • Agile Development makes the process of customization more manageable.
  2. Pervasive Connectivity and Server-based computing
    There’s no escaping the fact that contemporary and future software solutions will be tightly integrated with (if not completely running off) the Internet. Infrastructural development needs to be accelerated
    and server-based software solutions need to be created that can be easily customized for individual users
Posted in Affordable Technology | Leave a comment

Characteristics of Evolving Enterprises

Nicole Dunlop, Jadwiga Indulska and Kerry Raymond of the School of Computer Science and Electrical Engineering, University of Queensland, Australia have written a paper titled Dynamic Policy Management for Large Evolving Enterprises in which we found an interesting set of characteristcs of evolving enterprises :

  1. Scalability

    Due to the continually varying nature of the market within which enterprise operates, it is imperative that systems be scalable. Scalability refers to the ease with which a system can adapt to and accommodate increasingly complex requirements without the need for substantial changes to system structure or application algorithms.

    Some factors which have a direct impact on the level of scalability within distributed enterprise systems are, increasing user base, evolving and escalating functionality requirements, emerging distributed computing domains and heterogeneity of distributed computing domains.

    Our vision about how to achieve this scalability in systems for evolving enterprises:

    1. Component based architecture – for making code scalable
    2. Object databases – for making the database scalable
    3. Agile Development – for making the process of evolution scalable
  2. Rate of Change

    Evolving enterprises must be able to cope with the extraordinarily high rate of change ubiquitous in such environments. Including, merging distributed computing domains which often results in the introduction of new services and a need for heterogenous applications to co-operate.

    Web services with with a open XML based common language spoken between distributed computing domains is the ideal approach

  3. Trust

    Trust is essential for the efficient operation of large, evolving enterprises. Communities within an enterprise frequently recognise common organisational objectives and the members of those communities must typically exhibit a level of qualification, experience and responsibility in order to be included within the community. It is therefore reasonable that we allow those members to operate with a degree of independence deemed appropriate to their level of qualification and the nature of the actions they are performing in order to ensure efficient interactions within the enterprise.

    This is a pivot for the issue covered by the rest of the paper – how to determine policies in distributed computing environments so as to support dynamic roles, dynamic policies and the subsequent dynamic conflict analysis. Very interesting!

Posted in Evolving Enterprises, Workflow Management | Leave a comment

Evolving Enterprises as Virtual Organisms

Cells, Organisms, Ecosystems

Virtual Cell
We consider our “self” as one single “individual”. But we are actually made of millions of individually self-sufficient units called cells. Similarly, we as individuals form a cell of one or more virtual organisms – such as our family or our business.

Virtual Organism
As compared to biological cells, we as cells of virtual organisms, are far more complex. Physical cells perform a fixed role in our body. The little toe on your left foot cannot suddenly feel like becoming the heart. But as virtual cells of virtual organisms, we are capable of transforming ourselves by playing different “roles” according to the “organism” that we happen to belong to from time to time.

For example, Joe plays the role of “Chief Developer” when he is in office. While going home in a crowded suburban train, he is playing the role of a “commuter” expected to behave in a certain way. Then he plays the role of a “husband and father” when he reaches home. And he’s the perfect “party animal” who cracks great jokes when he’s among his friends.

As children, we ape adults who play their roles, and as we grow up, learn to play our own roles as we begin recognizing the virtual organisms we belong to.

Virtual Ecosystem

And pushing the metaphor further, each such virtual organism is part of an even larger virtual organism such as an industry, state or country. A business organism learns to play a certain role in the industry, based on the particular “market”. The same business organism could play the role of a supplier, customer, investor, advisor, consultant, facilitator etc. based on the requirements of the “market”.

In this heirarchy, each higher level of organism functions as an “ecosystem” to the sub-organisms that it is composed of. For example, the business organism is the ecosystem to the employees functioning as organisms. An Industry is an ecosystem to the individual companies functioning as organisms.

Ecosystem <==> Organism <==> Cell

Virtual cells also differ in one more aspect from biological cells – they not only can change from one functional role to another, they can play these multiple roles simultaneously. Multiple virtual organisms can share the same virtual cells. The same Joe is simultaneously a “Chief Developer” and a “husband and father” – as can be illustrated when Joe gets a call in office from his daughter asking for a new toy. Joe does not stop being a “husband and father” when he is in office. He is always playing the roles that he has learned to play.

Similarly, business organisms simultaneously play the different roles they have learned to play.

Evolution

Evolution

Just as biological organisms evolve, so do virtual organisms. Evolution is a process of continuous adjustment that individual entities make so as to adapt to their surrounding system.

Charles Darwin invented the term “natural selection” – a process by which organisms best suited to their environment become the ones most likely to survive and leave descendants. The outcome of the process is an organism that is well adapted to its environment.

Virtual organisms follow exactly the same process of natural selection. The probability of survival of a business organism through evolution is directly proportional to its ability to adapt to its environment.

Reproduction

Evolution in biological organisms occurs via heredity – a natural outcome of reproduction. Evolution occurs by parent organisms reproducing and passing “winning traits” down to the offspring. “Traits” are codified in “genes”. In sexually reproducing organisms, the genes of both partners combine to form the genes of the offspring.

What is the metaphorical “reproduction” process in virtual organisms?

Let us define reproduction as the combination of “traits” of separate organisms to form new organisms that inherit the traits of the parent organisms.

What are “traits” in a virtual organism – especially a business organism? The closest parallel I can draw is the “skills” of the organization – ie the core strengths.

Then, reproduction in the context of a business organism, as per the above definition, would mean the process whereby two business organisms combine their “skills” to form new business organisms that inherit the traits of the parent organism.

Does reproduction occur in business organisms?

Businesses do collaborate, form joint ventures, form mergers, acquisitions, all of which combine traits of two or more business organisms to form new business organisms. But the frequency of occurrence of this type of reproduction in business ecosystems is far far less than its frequency in biological ecosystems, and is ridden with failures.

A merger or acquisition is an extremely stressful process for those involved: job losses, restructuring, and the imposition of a new corporate culture and identity can create uncertainty, anxiety and resentment among a company’s employees

- Appelbaum, Steven H., Gandell, Joy, Jobin, Francois, Proper, Shay, and Yortis, Harry (2000), “Anatomy of a merger: behavior of organizational factors and processes throughout the pre- during- post-stages”, Management Decision, Vol. 38, Numbers 9 and 10

Virtual Reproduction

Could it be that the reason business reproductions fail isbecause they do not have a well-defined mechanism to reproduce – to really stretch the metaphor – no “reproductive organs”? If reproduction were to become a norm among businesses, would it not make sense to define pre-determined ways in which business organisms can combine traits to form new organisms – virtual reproductive organs, so to say?

An interesting paradigm that seems to successfully spawn such dynamic combination of traits is the open source movement, which relies more on a person-to-person (1to1) trust network that is unstructured, undocumented, flexible and result-oriented.

In addition, with the networking tools available today – email, instant messaging, online forums, networking sites etc. the process of interaction between small virtual organisms for combining traits to form new virtual organisms could be far easier, faster and painless.

So what are we headed towards? Virtual Organisms that get created as and when required to fulfill any requirement or opportunity in the environment (market). These virtual organisms are formed by a reproductive process between small, specialized virtual organizations (traditional companies), or individuals.

Its unlikely that the decomposition of conventional business organizations will be stretched to an extent where only individuals with skills will combine to form virtual organisms whenever any requirement arises. The efficiencies of close, continuous interactions have their benefits, and there will always be a certain optimal size for each business organism within which components have fixed functions.

Conclusion

Evolution of business enterprises and biological systems seem to have many parallels. The most interesting of the parallels is the process of reproduction. Biological organisms have mastered the process with a magnificent result of a biologically diverse ecosystem. This has been facilitated by a highly efficient, and structured process of reproduction. Now, with the increasing collaborative capabilities of the Internet, enterprises are likely to evolve new models for collaborating with each other, similar to how biological organisms have mastered the process of combining genetic traits to form new organisms by reproduction. Paradigms such as the Open Source movement have proven that highly successful products can be created with dynamically structured teams of individuals working together in a loose structure. It will be interesting to see how this phenomenon evolves further to allow larger business units to combine dynamically and create virtual organizations that have the combined strengths of each component business unit.

Posted in Evolving Enterprises | Leave a comment