The regular vendor-supported LIMS lifecycle is to look at requirements, assess whether core functionality exists, and if it doesn't write something new.
That means that sooner or later the vendor will come along and scoop those customizations up for inclusion in their core product as configurable functionality. When they do this they are essentially implementing a type of code harvesting pattern (a similar one will soon appear on LIMSExpert.com).
For some (particularly developers) this process can be pretty upsetting. Vendors rarely cite the source for new functionality in their products in order to give the appearance of being proficient and reactive to client needs. But it is important to remember that this is essentially what the client wants. Customers typically only write customizations when the core product does not provide some functionality. This includes whole new modules. They are, after all, just customizations.
Some view this as the customer supplementing the vendor's development and giving away free functionality. But in many cases the customer does receive a financial benefit. In the future releases of the software the configurable module will fall under the vendor's support. This means that the client will no longer have to pay to separately support the modular customization. They can rely upon the vendor's support instead.
DIY LIMS Support Solutions
A DIY solution would not have central vendor support but, being openly described and documented, allows for a pool of independent and/or in-house specialists to get up to speed fairly quickly.
In this case independent specialists and consulting firms simply need a central place to look for enhancements and the latest state of the module. They can implement it as-is and configure it or they can apply their own enhancements.
Here is where patterns becomes a powerful and useful tool for working separately but collaboratively. When a consulting firm or professional finds that a DIY LIMS module lacks necessary functionality they should author a pattern and submit it to the central collaborative repository. Other professionals that are looking for related patterns will become notified and can make a note to update their own in-house testing/demonstration systems. They can also then notify their businesses or clients.
In time the DIY versions of various parts of LIMS functionality should exceed the capabilities of vendor-supported software due to the increased number of users and respondents. At most a vendor can handle a few customizations like this per release cycle but whole groups of users working collaboratively can produce and test far more changes.
So this means that it should be possible to produce a non-configurable solution and submit it to a central repository as an organizational pattern. In doing this the authors are saying, 'here -- this worked for us...we do not claim it will work for anybody else...' Then the next user of the pattern can pick that up, try to implement it, and say, 'no, no...these two parts are nonsense...it should do THIS...' They submit a new pattern that references the original pattern but specifies what should be executed under conditions that arise in their business. This process goes on an on until successive versions of the module become increasingly configurable.
At first the module/functionality will be a bit of a mess. There will be code forks throughout which will say, 'IF X go this way, ELSEIF y go this other way' but typically patterns will emerge that will facilitate producing a singular module that accommodates the various needs.
When that consolidation happens it is mainly an engineering task. It consists of rewriting the solution in a manner that is clean and efficient for execution, maintenance, and reuse. When modules are rewritten in this fashion they are implementations of a generalized pattern that aggregates organizational patterns.
You will see the terms 'Normalized Organizational Pattern' (or NOP) and 'Normalized Generalized Pattern' (or NGP) more often when reading articles on LIMSExpert.com in the near future. The 'Normalized' part will make sense only after patterns that describe the flow from raw idea to organizational use are described as well as patterns for conversion from organizational to generalized patterns are spelled out. All this is forthcoming here at LIMSExpert.com.Go Back
Citation: On Configurability. (2014). Retrieved Sun Apr 30 05:00:51 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1394659687