From The Editor I am offering a new service for recruiters, brokers, and consulting firms wanting to advertise Lawson-related job openings.  With 2300+ registered users on LawsonGuru.com and 4100+ LawsonGuru Letter subscribers, your job openings will be highly-visible to your ideal target audience.  Please email me at letter-editor@lawsonguru.com for further details and pricing information.  Lawson clients may continue to post their open positions on LawsonGuru.com free of charge.

The LawsonGuru Letter is a free periodic newsletter providing provocative commentary on issues important to the Lawson Software community.  The LawsonGuru Letter is published by—and is solely the opinion of—John Henley of Decision Analytics.  Visit Decision Analytics at https://www.danalytics.com. For subscription information, see the bottom of this message.  Lawson® is a registered trademark of Lawson Software, Inc.  The LawsonGuru Letter is neither affiliated with nor sponsored by Lawson Software, Inc.  Lawson Software, Inc. is not responsible for the content of this information.

Last summer’s reading included a significant and highly-relevant book, “The Change Function: Why Some Technologies Take Off and Others Crash and Burn” (see http://www.amazon.com/Change-Function-Technologies-Others-Crash/dp/B000NA6U2O ) by Pip Coburn.  As I was reading, I naturally started to draw some parallels to some Lawson initiatives.   The gist of the Change Function is expressed by Coburn’s functional notation:

The Change Function
f (perceived crisis vs. total perceived pain of adoption)

To state this as a narrative:

Users will change their habits when the pain of their current situation is greater than their perceived pain of adopting a possible solution—this is the crux of The Change Function.

To put this in terms of Lawson, the onus is on the supplier (Lawson) to convince the buyer (you, Lawson’s client) to adopt a new product because the pain associated with implementation of the new product is less than the pain of your current crisis (i.e. maintaining the status quo).  Pretty interesting so far, isn’t it?  Let’s look at this as it applies to two keys to Lawson’s future, Landmark and LSF9.

Crisis? What Crisis?

First, let’s examine Landmark.  Now, Lawson hasn’t yet announced Landmark replacements yet for their legacy S3 product suites.  But that time will come, and Lawson will do its best to convince you to switch.  Their pitch thus far has been that you will want to switch because the technology is so cool, how could you not?  But, to the non-technologist, Lawson’s current applications really aren't a huge problem.  Sure, some folks may consider them archaic and it may require reams of paper if you wanted to print out the source code.  But, end users couldn't care less whether the apps are written in Landmark-generated Java, in COBOL, or in Sanskrit.  As long as they work--and they do work pretty well for the most part—why switch?

Think about it this way.  If I’m the CIO or the CFO and we have an HR application that works just fine for my organization, why would I even consider swapping it out for the Landmark HR?  Even if the upgrade is free?  I don’t get any tangible, measurable, benefits from the upgrade.  If I don’t upgrade, my costs don’t change.  Why bother?

Now if you talk to Lawson about it, they really don't portray it as a switch per se, but claim that—by maintaining backward compatibility (in other words, keeping current by upgrading to LSF9)—you will be able plug in new Landmark apps at will and not miss a beat.  But let’s not kid ourselves.  As Coburn points out, if the vast bulk of the conversation is from and about the purveyors of the new technology, watch out: “sometimes technologists forget just how vast the chasm is between them and ‘real people’".

Is the Change Incremental?

Coburn differentiates incremental changes from total change:

Disruptive technologies are much more likely to be adopted if they offer incremental adjustments to new users and not complete deviations from life, as we know it.

So, is Landmark an incremental change, or is it a complete deviation?   No matter what Lawson comes out with as an upgrade path, to truly take advantage of a Landmark application you would want to re-implement—not just upgrade—an application.  As an analogy, you wouldn’t just translate your procedural COBOL code into procedural Java.  You would re-architect it to take advantage of unique features in Java that aren’t available in COBOL.  Same holds for implementing a new version of an application. 

To simply upgrade with the same setup and business processes is only half the upgrade equation.  The second (and much more difficult and costly) task is to figure out why, where, and how to use all the new functionality.  And, that’s where the pain is.  Landmark also requires a shift in mindset for your IT staff.  They do have to endure a significant change—in their training, toolsets, etc.  In other words, more pain.

To sum it up, consider the Machiavelli quote that Coburn uses to introduce Chapter One:

“Nothing is more difficult than to introduce a new order.”

Now, before I leave the subject of Landmark, let me make myself clear.  I’m not condemning Landmark as a product/technology.  Time will tell if Landmark successful or not. What I’m saying is this: Lawson will have a tough sell getting clients to “upgrade” to Landmark applications.  Unless they force decommission of the pre-Landmark offering.

To be fair, Lawson has been forthright in saying that the transition to Landmark applications will be a long process, “a journey” to quote Dean Hager.  But this does provide us with a perfect illustration of Coburn’s Change Function.

Does LSF9 Suffer from the Change Function?

Enough about Landmark; let us examine LSF9.  So, how great is your current crisis?  Are you enduring enough pain to warrant an LSF9 upgrade?  Consider a typical client's need for the LSF9 upgrade.  There are certainly some very compelling arguments for upgrading to LSF9: greater stability via Websphere, the new Lawson Security model, and more robust add-ons, like ProcessFlow Integrator, which require LSF9. 

But for a fair percentage of Lawson clients, there just isn't compelling reason to upgrade.  If you’re just running the core apps, don’t have RMI issues, and aren't enticed by (or don't have the resources to implement) Lawson Security, the only driver for the upgrade is to beat the decommission date.  In other words, clients are asking "what's in it for me?” And, this is where the Change Function applies.   As Coburn succinctly points out, crisis must precede change because change is so difficult.

Now if you’ll excuse me, I need to go change.

A few months back, Alex Wolff shared an article (see https://www.danalytics.com/guru/letter/archive/2007-06.htm)) outlining a technique for combining a Java program with the LSF9 ‘loadusers’ utility.  I wanted to add to that idea, and show you another alternative, which I recently used to migrate users from Lawson Environment 8 to LSF9. 

I won’t reiterate Alex’s article or the loadusers XML format, except to say that for each user, you need to populate a handful of fields, such as their name, ID for Portal (SSOP ID), OS ID, Product Line, etc.  If you already have that info in your Environment 8 LOGAN data, you can use this type of technique to migrate it to LSF9.  In this particular instance, a full-blown v8->LSF9 migration wasn’t necessary, since the client was setting up new security classes, wasn’t migrating jobs and reports, didn’t have existing ProcessFlows, etc.  The only thing that needed to be migrated was the user setup.

Alex and I arrived at different, yet equally valid, solutions for creating the loadusers file. The difference is that instead of using a Java program, I used the Query Wizard from the Lawson Microsoft Add-Ins to extract the user data, and IBM WebSphere DataStage (nee Ascential nee Mercator) to reformat it into the XML format required by loadusers.

Querying the Users

The first step was to create a CSV file of the users.  To do that, I used the Excel Query Wizard to extract the data from the v8 LOGAN data.  As the source table, I used LOGAN/SIRDIDHDR, and its related table, WEBUSER:

In this particular instance, I created two sets of DME queries and CSV files, to match the users who were grouped into two categories:

• Employee Self-Service users; these users would be loaded into Lawson Security and mapped to the appropriate COMPANY and EMPLOYEE values; they would share a common OS identity.  To select these users I selected the WEBUSER.TYPE = ‘EM’.

 

• Portal / LID Users; these users would also be loaded into Lawson Security and mapped to the appropriate COMPANY and EMPLOYEE values (since in addition to being “real” users they are still employees!).  In order for them to use LID and run batch jobs, they needed be mapped to their specific OS identities. To select these users I selected the WEBUSER.TYPE = ‘EC’.

Once I ran these queries, I had two CSV files, each formatted like this:

 

Mapping with Mercator

The next step was to create the Mercator TypeTrees and Map files.   Mercator was purchased by Ascential a few years back, and Ascential was subsequently purchased by IBM and the Mercator tools were re-branded under the WebSphere suite of products.  Lawson bundles them with Lawson’s ProcessFlow Integrator or Business Component Integrator.  Call me stubborn, but I still refer to the product set as Mercator most of the time.  

The primary Mercator tools are the Type Designer and the Mapping Designer.  Mercator TypeTrees describe input/output file formats, and Mapping(s) transform the input data into output data.  If you’re a “visual” developer, you’ll love Mercator.  Mercator comes with some handy import tools that you can use to create TypeTrees from common formats.  For instance, Mercator can create a TypeTree from a COBOL FD.  Mercator can also create a TypeTree for an XML document based an XML Schema (XSD).  So, all I needed to do was come up with an XSD that matched the loadusers XML format.  Thankfully, Microsoft Visual Studio has a great tool for creating XSDs, which I used to create the XSD for the loadusers format:  

I then used Mercator’s XSD import tool to create the TypeTree:

 

I then created some simple TypeTrees for the CSV files, and used the Mapping Designer to hook everything together:

 

Without going into too much detail, one of the ways you control the data/execution of a Mercator Map is with what Mercator calls a “Functional Map”.  Think of it as a function/subroutine and you’ll get the idea.  The primary map operates on the CSV input file(s) to create the XML output file(s); a “Functional Map” can be executed for each record (or even individual fields) in the CSV file to populate the appropriate XML nodes:

 

Once I was done with the mapping, I could generate the two XML files, in the loadusers format, which could I transfer to the server and use as input for the loadusers utility:

That Pesky LawLocal Group

If you run Lawson in the Windows Environment, one task that’s part of user creation is to add each LID/Portal (batch job) user to the local Lawson user group (often referred to as the “LawLocal” group).    Since I was reading through all the users anyway, I decided to add that step to the Mercator mapping process, so that it also generated a command script:

net localgroup LawLocal domain\train01 /add
net localgroup LawLocal domain\train02 /add
net localgroup LawLocal domain\train03 /add
net localgroup LawLocal domain\train04 /add
net localgroup LawLocal domain\train05 /add
net localgroup LawLocal domain\train06 /add

From a DOS prompt, this script could then be executed to add the users to the LawLocal Windows user group.

Sharing the OS Identity for ESS Users

For the ESS-only users, you generally share a common OS identity; in this case, DOMAIN\essuser.  After creating the DOMAIN\essuser on the server itself, adding it to the LawLocal Windows User group, granting it LAUA security and creating it’s identity in Lawson Security, I used the Lawson Security “Mass Assignment” tool to assign the employee resources/ users to the identity:

Last but not Least

The last step for migrating LID / Portal (Batch) Users is that you have to put them into a LAUA user group and assign them to a Security Class.  There are no Lawson-provided mass-load utilities that do that.  In the interest of keeping Lawson from chastising me, that’s all I’ll say on the matter.  Except to remind you that, now that GEN is in a SQL database, you can probably make that part a lot easier.

The Long View

Companies are trying to shift investors' focus from short-term results to long-term goals.
CFO Magazine, May 2007
http://www.cfo.com/article.cfm/9057969/c_9064230

I.T.-Business Alignment: 10 Best Practices

At too many companies, technology managers aren't on the same wavelength
with the top business executives.  Here are 10 ideas for improving that dynamic.
Baseline Magazine, August 2007
http://www.baselinemag.com/article2/0,1540,2164145,00.asp

Manage Change with Oracle Database 11g

New features speed innovations and transform the enterprise.
Oracle Magazine, September/October 2007
http://www.oracle.com/technology/oramag/oracle/07-sep/o5711g.html

Infor: The $2B Company No One Has Ever Heard Of

Infor's CEO outlines potential IPO plans and an SOA strategy to kick start the company's marketplace visibility.
eWeek, September 11, 2007
http://www.eweek.com/article2/0,1759,2181784,00.asp

Chances are, you've probably run across this scenario before. You've had to spend an annoying amount of time trying to figure out how an error was occurring in a program (i.e. which library code is populating CRT-ERROR-XXX). You've built a COBOL shell via bldsh and looked through the program to see which values it was moving to CRT-ERROR-CAT and then looked them all up in msgmnt.

You've probably even used a tip I published some time ago, which showed you how to userngdbdump against the CRTERRMAP GEN table:

$ rngdbdump -c gen crterrmap | grep "Your exact Error message" | lashow

Now, with LSF9 there's an even easier way!  View the rest of this tip on LawsonGuru.com (site registration required).