Software Checker

In an enterprise, it is common to have hetergenous environments like 'IVE', 'OnTheGo', each employee could have different version of browser, different java or Flash plugins. In such environment, it is difficult to ensure that the application(starting 5.8.5 Flash is used) or content that is created by different vendors runs properly.

From 5.8.5, LMS introduces a nice feature called "Software Checker" to address this. This checks for the browser and plugin compatibility and alerts the user about it and also helps them in downloading the required version of software.


By default, the software checker does not check for users' version of Flash Player. You can turn on Flash Player checking by updating the PS_SUPPORTED_SOFTWARE table. Customers should change the ACTIVE flag to Y where SOFTWARE_NAME = Flash. This causes the software checker to check for browsers' versions of Flash Player.

You can also turn the checker completely off for users and administrators in Talent Management Administrator. Go to: System Admin > Configuration > Global Variables > Enable Software Check for [admin/user].

Data Migration and Mastery Score

Here is the problem that one of the clients faced. The client had 2 different LMS versions running and wanted to merge the 5.8.3 data to the one in 5.8.5.

The data migration scripts were written by a Migration Expert and the data migrated. During the Customer testing of the content, the content was getting launched and they could complete the Course but it was not being removed from the Learning Plan and cannot be seen in the Learning History.

After debugging, I found out that the Mastery Score was null. This value was not being migrated from the 5.8.3 system based on the data requirements provided by the LMS Admin. When this value was set and the Course taken again then the Course moved to the Learning History. The 5.8.5 LMS application does not warn or throw an error mentioning that this field is null. Neither is this a mandatory field.

Here are some best practices while doing the LMS data migration. You will save precious time of everyone and thousands of dollars if these are followed.

• Data is the king. Data was entered for some purpose. So, without second guessing migrate the data as it is. The LMS Admins may not know why some field is required.
• Use the Copy Entity Tool to do this. This is easy to configure and it does not increase the time or cost to copy all the columns in a given table.
• Avoid writing SQL scripts to do data migration where Copy Entity Tool can serve the same purpose. 
• Get the data migration strategy reviewed by the Plateau LMS Consultant. 

Re applying a DB Patch

If for some reason, you are not satisfied with the DB Patch and want to apply it again, you cannot do it out of the box. Here is what needs to be done.

• Query PS_PATCH_INFO table and delete the records that have the Patch# that you want to re apply.
• Now run the installer again. This will install those patches again.

Applying DB Patch

Since SP4, the applicaton of DB Patches has improved. Following are some features

• The PatchInstaller(dry run mode) checks if any configuraton files that are beng delivered in the Patch are modified by the Customer or not. 
• If so, it lets the Customer merge the changes and update the DB (merge run mode)   

Note: Please verify if the files have been uploaded correctly. Check the timestamp in the DB. I know of one instance when the DBA applied the Patch, the Patch number has been updated correctly but the Report libraries were not updated. It is always a good practice to ensure that the files have been uploaded correctly. If not, these problems only appear during the testing or usage when it would turn to be very costly. The Application Patch version which is stored in PS_PATCH_INFO table showed all the patches applied correctly.

Many Customers are of the view that the upgrade can be done only by the Vendor. This can also be done by a Plateau Consultant or by a DBA with guidance from LMS Consultant as the DB scripts are very straightforward to apply the Patch. Once it is done in house then the costs of further upgrades that are required in different environments can be done as and when required. This saves a lot of time, cost and helps in  planning the project better.  

Budget and Quality - Managing the LMS Implementation effectively

Companies that approach me for the LMS solution come up with the following experience they had with the previous vendors

• The implementation cost has overshot the budget by at least twice the budget
• The quality of the implementation

I found the following common problems in the above implementations

• The Vendor over charged for the LMS implementation and delivered a poor quality implementation.
• Waterfall Approach followed in the execution of the projects. This approach conceals the problems in requirements, implementation, skills, budget till the end where there is  little room to make any corrections as the budget had already been overshot. 
• The source code for the integration is not available to the Customers and as a result they are tied up with the costly solution provided by the Vendor.

Here is how I propose the above to be solved. Of course, this has to be discussed with the Customer and they have to be comfortable with it.

• Get the fixed cost bids from a few vendors and compare them
• Follow the Agile methodology. This ensures the integration is done in multiple iterations. This will help flush out the requirements, continously tests the quality of the implementation, helps in prioritizing what needs to be done, helps in controlling the budget. This is a change in the mindset for which the Customer and Vendor need to be ready to work with.
• Ensure that the Vendor provides the source code of the Connector as this will reduce the cost in upgrading to new versions and in customizing the solution.

There are other problems that I have observed which the Companies should be aware of

• This is a technical problem and needs strong technical folks with Plateau LMS SME knowledge to head this effort. Do not rely on the non technical managers who may be the SME in this.
• Get the Content right. Prioritize this for the beginning and ensure that different types of Content(AICC, SCORM) can be launched and the run time communication works well.
• Ensure that you get the setup of Domains right and automated.
• Ensure that any data transformation is externalized.     

Deployment

The desired deployment scenario is as follows

1. Web Server - This is the gateway to the LMS. The static files(images, styles,etc) are deployed here. All requests are from here. This could be Apache HTTP Server.
2. Application Server - The LMS application is deployed at an Application Server(Weblogic, JBoss, Websphere).
3. Content Server - All content (AICC, SCORM) is deployed here. This could be a Tomcat Server.

Branding Styles

The Branding Styles are usually modified by an external vendor. The changed files are usually in styles and images. The deployment of these files is as follows

1. If the static files are deployed at the Web Server then these files just need to be copied over. This is the recommended approach.
2. If the static files are not deployed then they need to be copied in plateau.war which exists within plateau.ear and the ear needs to be redeployed.

Multiple branding styles can be created and they can be applied at Organization or Domain.