Decision Analytics > LawsonGuru > LawsonGuru Letter > 2003

October 2003

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 http://www.danalytics.com. For subscription information, see the bottom of this message.

The LawsonGuru Letter is not affiliated with Lawson Software.

In this issue:
1. Guest Spot: Why Software Architecture Matters
2. Lawson's India Flap
3. Understanding Lawson Object IDs
4. Can Isabel teach us about Preparedness?
5. Reader feedback
6. Worthwhile Reading
7. Lawson tips & tricks

This month in addition to the normal LawsonGuru Letter fare, I'm honored to provide you with a guest article by Luke Hohmann. Luke is an independent consultant focusing on product management, software development and organizational effectiveness. His latest book is "Beyond Software Architecture: Creating and Sustaining Winning Solutions" (ISBN 0-201-77594-8). It's easy to read and understand, provides some rare insights on a wide variety of relevant development issues, and is a "must-read" for every software professional.

As a reminder, I invite articles from anyone--whether a Lawson employee, client or partner--with an opinion or topic of interest. Simply send me an email at to get started.

1. Guest Spot: Why Software Architecture Matters
By Luke Hohmann; Visit Luke at http://www.lukehohmann.com.

Software architecture matters because a good one is a key element of your long-term success. Here are some of the ways that architecture influences success. Not all of them are equally important, but all are related to your architecture.

Longevity

Most architectures live far longer than the teams who created them. Estimates of system or architectural longevity range from 12 to 30 or more years, whereas developer longevity (the time a developer is actively working on the same system) ranges from 2 to 4 years.

Stability

Many benefits accrue from the longevity of a well-designed architecture. One of the biggest is stability. Architectural stability helps ensure a minimum of fundamental rework as the system's functionality is extended over multiple release cycles, thus reducing total implementation costs. It provides an important foundation for the development team. Instead of working on something that is constantly changing, the team can concentrate on making changes that provide the greatest value.

Degree and Nature of Change

Architecture determines the nature of change within the system. Some changes are perceived as easy; others are perceived as hard. When easy correlates strongly with the desired set of changes that improve customer satisfaction or allow us to add features that attract new customers, we usually refer to the architecture as "good."

In one application I worked on, the development team had created a plug-in architecture that would extend the analytic tools that manipulated various data managed by the system. Adding a new tool was relatively easy, which was a good thing because it was a major goal of product management to add as many tools as possible.

Profitability

A good architecture is a profitable one. By "profitable," I mean that the company that created the architecture can sustain it with an acceptable cost structure. If the costs of sustaining the architecture become too great, it will be abandoned.

This does not mean that a profitable architecture must be considered elegant or beautiful. One of the most profitable architectures of all time is the Microsoft Windows family of operating systems-even though many people have decried it as inelegant.

It is important to recognize that the profitability of a given technical architecture often has little to do with the architecture itself. Take Microsoft, which has enjoyed tremendous advantages over its competitors in marketing, distribution, branding, and so forth. All of these things have contributed to Windows' extraordinary profitability.

This is not an argument for poorly created, inelegant architectures that cost more money than necessary to create and sustain! Over the long run, simple and elegant architectures tend to be the foundation of profitable solutions.

Social Structure

A good architecture works for the team that created it. It leverages their strengths and can, at times, minimize their weaknesses. For example, many development teams are simply not skilled enough to properly use C or C++. The most common mistake is mismanaging memory, resulting in applications that fail for no apparent reason. For teams that do not require the unique capabilities of C or C++, a better choice would be a safer language such as Java, Visual Basic, Perl, or C#, which manage memory on the developer's behalf.

Once created, the architecture in turn exhibits a strong influence on the team. No matter what language you've chosen, you have to mold the development team around it because it affects such as things as your hiring and training policies. Because architectures outlast their teams, these effects can last for decades (consider the incredible spike in demand in 1997-1999 for COBOL programmers as the industry retrofitted COBOL applications to handle the Y2K crisis).

Boundaries Defined

During the architectural design process the team makes numerous decisions about what is "in" or "out of" the system. These boundaries, and the manner in which they are created and managed, are vital to the architecture's ultimate success. Boundary questions are innumerable: Should the team write its own database access layer or license one? Should the team use an open-source Web server or license one? Which subteam should be responsible for the user interface? Winning solutions create technical boundaries that support the specific needs of the business. This doesn't always happen, especially in emerging markets where there is often little support for what the team wants to accomplish and it has to create much of the architecture from scratch; poor choices often lead the development team down "rat holes" from which it will never recover.

Sustainable, Unfair Advantage

This point, which summarizes the previous points, is clearly the most important. A great architecture provides a technically sophisticated, hard to duplicate, sustainable competitive advantage. If the technical aspects of your architecture are easy to duplicate, you'll have to find other ways to compete (better service, superior distribution, and so forth). Architecture still has an important role: A good architecture may still help you gain an advantage in such things as usability or performance.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Change Is Hard
CIOs, asked to name their single biggest fear concerning Oracle's proposed
takeover of PeopleSoft, cited rising prices more than switching costs or
support services:
46% Prices soaring due to lack of competition
25% Having to switch application systems
16% Not concerned about the proposed acquisition
9% Oracle not supporting current PeopleSoft service agreements
4% Other
Total number of responses: 181
Source: CIO Best Practice Exchange online survey of CIOs from companies
with more than $250 million in revenue, July 2003
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2. Lawson's India Flap
By far, the biggest news this month on the Lawson front may be its most controversial. In conjunction with an announcement of some development layoffs, Lawson announced that, over the next 2 years, it plans to move some development jobs offshore to an as-yet-unnamed organization in India (see http://news.mpr.org/features/2003/09/22_horwichj_lawson/).
This news was a bombshell to many in the Lawson community, and most clients and users were disturbed, to say the least. It wasn't the layoffs necessarily, but the shift to using offshore resources that has the users disgruntled. The Topica and Yahoo message boards were quickly ablaze with anti-American sentiments about Lawson, proclaiming them as sellouts.
The India offshore news leaked just a couple days prior to the quarterly Lawson Mid-Atlantic Users group meeting, which included a surprise visit by Dean Hager, Lawson Executive Vice President for Emerging Markets. Hager was quickly put on the defensive about the layoffs and offshore development. He explained that, thanks to some realignments and acquisitions, there were some job redundancies that could be safely eliminated.
I questioned him about the layoffs, and in particular, asked why Lawson-that often touts itself as an employee-friendly company-was not able to redeploy more of these employees to other positions rather than lay them off. He assured us that more than half of the employees who were initially targeted for layoffs were actually redeployed, and that the others were closely evaluated, and, in some cases, were let go for performance and other reasons. So, this sounds more like a periodic housecleaning, and not necessarily a sign of bad times at Lawson.
He also touted the strengths of the Indian offshore developers in structured methodologies, particularly their levels of CMM compliance, as one of the primary reason to start moving some development offshore.
The move to offshore resources certainly didn't surprise me. It's purely a cost issue. For years now, other software developers have been moving in this direction: Oracle, Microsoft, IBM, etc. In fact, one of the reasons I shifted from software development into consulting is that I simply didn't want to compete with the cheap offshore labor pool. You simply get more bang for the buck. Or do you?
One of the statistics I've seen is that there's a 1:5 to 1:10 cost ratio for using offshore resources. In real dollars, this means that for every $100 spent in the US, the same work can be down for $20 or even $10. But, beware the hidden costs of offshore work.
The truth is, no one really saves 80 percent by shipping IT work to India or any other country. Few can say they save even half that. As just one example, United Technologies, an acknowledged leader in developing offshore best practices, is saving just over 20 percent by outsourcing to India (see http://www.cio.com/archive/090103/money.html).

There are other hidden costs as well, particularly understanding the cultural differences, and managing people who are halfway around the world (i.e. not just a few time zones away).
You also have to deal with the "Anti-American" issue. While it's a shame that we have to ship jobs offshore, at least they haven't moved the headquarters there. That's when I'd be really worried!
Will this work for Lawson? Well, I can't predict that. A lot of companies are making it work. We'd all like to see it work, and for Lawson to become a stronger company offering ever more robust solutions. So, we'll see. I know a whole lot of people who will be watching.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- QUOTE OF THE ISSUE -

"Success is the ability to go from one failure to another with no loss of enthusiasm."
- Winston Churchill
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3. Understanding Lawson Object IDs

One of the fundamental concepts in Lawson applications is that of the "Object ID". I'm periodically asked by clients to explain Object IDs, and how they are used in Lawson. This document outlines the concept of an Object ID, and explores some of the methods for querying them and updating them.

To download an enhanced copy of this article, including sample code and diagrams, please visit http://www.LawsonGuru.com (web site registration required).

What is an Object ID?

Don't let the name "Object ID" intimidate you-it's really not all that complicated. An Object ID is simply a name for a data value that Lawson uses to uniquely identify a particular entity or transaction object. In other words, think of it as an identifier.

In the database parlance, it might be called an IDENTITY; in the Microsoft Windows world, you may be familiar with the GUID (or Globally Unique Identifier); for an employee, think of it as you would a Social Security Number (SSN).

Object IDs are used to identify various entity or transaction objects throughout the Lawson applications:

Object Type

Lawson Object IDs uniquely identify

ACCNT

General Ledger Account

ACCTU

General Ledger Accounting Unit

ACTVY

Activity

ACTRN

Activity Management Transaction

ASSET

Asset Management Asset

ASITM

Asset Management Asset Item

GLTRN

General Ledger Transaction

HRHST

HR History (HRHISTORY) Record

PRPEG

Garnishment

PRPRD

Payroll Distribution (PRDISTRIB) Record

PRPYD

Payroll Deduction History (PAYDEDUCTN) Record

How Lawson Uses Object IDs

The primary purpose for Object IDs is to facilitate the linking of records (or "objects" to stretch the idea) between the various Lawson subsystems. This is what makes the Lawson DrillAround features so powerful. As this diagram shows, Object IDs are used to manage a 3-way link between APDISTRIB transaction objects, GLTRANS transaction objects and ACTRANS transaction objects:

Where are Object IDs Defined?

An Object ID, when combined with an "Object Type" uniquely identifies an entity or a transaction. Object IDs are 12-digit integers, and are defined in two tables for each object type. The base value (the last-used object ID) for each object type is defined in the OBJID table on Unix/NT; and in the DBIFOBI table on the iSeries/AS400.

Then, in each table where an Object ID is used/assigned (i.e. in the context of the entity or transaction), there will be an OBJ-ID column. In cases where a record points to other records that support Object IDs, there may be more than one OBJ-ID column, usually prefixed by the table prefix for the target table (e.g. ATN-GLT-OBJ-ID is the Object ID in ACTRANS that relates to the Object ID in GLTRANS).

For example, ACTRANS has it's own unique OBJ-ID, as well as a GLT-OBJ-ID value, which relates the ACTRANS to a GLTRANS record. If you're familiar with database schemas, think of the OBJ-ID in ACTRANS as a primary key, and the GLT-OBJ-ID as a foreign key to the GLTRANS table. Now, to confuse you just a little more, although you can think of an OBJ-ID as a primary key identifier, Lawson does not use them as primary keys-that would be too problematic if the Object IDs were to get corrupted.

Querying on Object IDs

Here are a few SQL queries that can be used to understand how Object IDs are assigned to individual entities:

SELECT COMPANY, ACCT_UNIT, DESCRIPTION, OBJ_ID FROM GLNAMES
ORDER BY COMPANY, ACCT_UNIT

SELECT ACTIVITY_GRP, ACTIVITY, DESCRIPTION, OBJ_ID
FROM ACACTIVITY
ORDER BY ACTIVITY_GRP, ACTIVITY

SELECT
APDISTRIB.GLT_OBJ_ID,
APDISTRIB.ATN_OBJ_ID,
GLTRANS.OBJ_ID AS GLTRANS_OBJ_ID,
ACTRANS.OBJ_ID AS ACTRANS_OBJ_ID
FROM
APDISTRIB
LEFT OUTER JOIN
GLTRANS ON APDISTRIB.GLT_OBJ_ID = GLTRANS.OBJ_ID
LEFT OUTER JOIN
ACTRANS ON APDISTRIB.ATN_OBJ_ID = ACTRANS.OBJ_ID
WHERE (APDISTRIB.REC_STATUS = 9)

What's the last Object ID used?

You can easily use a SQL query to determine the last Object ID used for each object type:

SELECT OBJ_TYPE, LAST_OBJ_ID
FROM OBJID
ORDER BY OBJ_TYPE;

Resetting an Object ID

Chances are that if you've never run into any problems with Lawson processing, you may never have to fix an Object ID problem. In some cases, particularly where you're merging product lines, you may need to reset the "last Object ID used" for a particular object type.

The easiest way to do this is to use the IFOB form (it's in the IF system code). The "reset" option is used to reset the last Object ID explicitly to the value you specify; otherwise the last Object ID is incremented by the value that you specify:

Some Final Words of Caution

Always use care when manipulating Object ID data, particularly when you are affecting transactional data, such as GLTRANS or ACTRANS. If you find yourself in that situation, or are perhaps merging multiple product lines (and therefore, the Object IDs), it's highly recommended that you consult an expert. And, make sure you have a good backup!

4. Can Isabel teach us about Preparedness?

Each autumn in the DC area, it seems we face a crisis. First 9/11, then the sniper, and this year, it was Hurricane Isabel. Thankfully, this was least by far the easiest of the three.
How prepared can you be for a looming crisis? I know I'm not the world's most prepared person. I've always chuckled to myself upon I hearing my neighbor's generator start up during a power outage. It even lights up his doorbell button (since he's an electrician, I guess that's to be expected!). And I have to admit I was skeptical and sat on the sidelines watching the Homeland Security panic, with the frenzied buying of duct tape and plastic sheeting.
But this was no ordinary storm. It had been predicted for weeks (in fact, we had been hearing all year that this would be a wicked hurricane season, which has indeed been the case thus far). So, I was determined that I should be somewhat prepared.
Beyond the obvious concern for my family and our collective well-being, my primary worry is over my sump pump. Without it, we might as well be living underwater. Naturally, following our last major hurricane, and after ever major storm, I promise myself that I'll get some sort of backup power-be it a battery or a generator-to carry me through a power outage. Needless to say, I still hadn't gotten one. And, during the week leading up to the storm, I couldn't find one anywhere.
I did get a couple of small rechargeable marine batteries and a power inverter, but to no avail. Not enough juice to start up the pump! So, on to plan B-a battery-powered drill with a small pump attachment. Hey, at least I had a plan B! And I could use my batteries and power inverter to keep the drill charged up, at least until the batteries ran dry. At which point I guess I'd be knocking on my neighbor's door begging to rent some time on his generator. Well, the good news is that we really didn't get that much rain. And luckily, our power was back on in about 24 hours. No damage whatsoever. Another bullet dodged.
On the morning after, we went for a walk to survey the neighborhood for damage. A lot of downed trees, but mostly only minimal property damage. I was truly amazed at how many trees had come down between houses, and next to cars, but without hitting anything.
The fine folks at our local Starbucks had flung open their doors and hooked up a generator to their drip coffee maker. They were handing out free coffee, one cup to a person. With most of households in our area still blacked out, I thought this was a wonderful gesture of community goodwill. You can picture my chagrin at the audacity of some of the "patrons" (remember we're talking "free coffee" here!) who actually complained when they couldn't get their specialized lattes!
And, it's plainly obvious that our electrical infrastructure needs an upgrade. This was the second major storm in a month in our area, and some houses had been without power for a week each time. Why are we still stringing power lines on ugly poles anyway? Is it really that "cost-prohibitive" to bury the lines, given the expense of constantly patching things back up? In our urban areas and denser suburbs, doesn't it make sense, over 10 or 20 years, to do that? How this gets done, and how it gets paid for is another matter.
I honestly think that the storms and other crises we face help to remind us of our own mortality. They send a strong message that it's time to stop and take a break. Well, it's all over now, and things are nearly back to normal. I'm off to go buy that generator!

5. Reader Feedback
Send your comments to .
In the last issue (http://www.danalytics.com/guru/letter/archive/2003-09.htm), I asked if you're ready and willing LID. I loved this response:

- "to paraphrase...they can have my green screen 'when they pry it from my cold dead fingers'. I dislike losing what little control we have and would protest loudly if I lost LID. Then again, I'm not a fan of color TV."

6. Worthwhile Reading

15 Great Excel Tips
Use these little-known functions to make your formulas
more useful than ever.
PC Magazine, September 16, 2003, pp. 60-61
http://www.pcmag.com/article2/0,4149,1229633,00.asp

Big Ambitions
Small and midsize companies have the same technology needs, and the same goals, as large ones.
Information Week, August 25, 2003
http://www.informationweek.com/story/showArticle.jhtml?articleID=13100930

Barely Working: The 2003 Working Capital Survey
Companies squeezed more cash from their businesses this year -- but not much. Was it the economy, or too much focus on Sarbanes-Oxley compliance?
CFO Magazine, September, 2003
http://www.cfo.com/article/1,5309,10533||M|667,00.html

Special Guide To Business Orchestration
From Tightly Bound to Loosely Coupled
Software Development, September 2002
http://www.sdmagazine.com/documents/s=8860/sdm0309b/sdm0309b.html

Make a Smooth Move to Windows Server 2003
A successful Windows Server 2003 migration calls for evaluating your organization's needs and creating a migration plan that matches them.
.NET Magazine, September 2003
http://www.ftponline.com/dotnetmag/2003_09/magazine/features/nruest/

Configure Disks for High Availability
Configure SQL Server properly to ensure high availability and optimal performance.
.NET Magazine, August 2003
http://www.ftponline.com/dotnetmag/2003_08/magazine/columns/sqlconnection/

7. Lawson Tips & Tricks
Share your tips. Send them to .
Understanding security peculiarities on reports created by INVOKEd programs.
Lawson uses a subroutine technique in some modules that INVOKEs a form within code. The theory behind this technique is that a form contains "business logic", and as such, is a self-contained module. Another program can then INVOKE that form module--programmatically--just like a user entering data in that form. This technique is heavily used in the v8.x Procurement suite. For example, the code to print delivery tickets is not in PO30 or PO130, but rather in an INVOKEd form POIE.
What's interesting about the INVOKEd forms is the security. A user does not have to have laua program access to an INVOKEd form, as long as they have access to the base form that INVOKEs it. In other words, a user can have access to PO30, and not POIE, and PO30 will still INVOKE POIE to print a delivery ticket.
However, the user MUST have access to the INVOKEd form in order to view reports created by the INVOKEd form. In this example, the user can use PO30 to print delivery tickets (and perhaps have them routed automatically to a printer). However, in Print Manager, the user will not be able to see the print files created by POIE unless they explicitly have laua security access to POIE in the product line in which the print file is created.

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 http://www.danalytics.com.
To subscribe, send an email to:

To be removed from the subscription list, send to:

Decision Analytics is an independent consultancy, focusing on Lawson technical projects, and specializing in customization/modification, data conversion, and integration/interfaces. Please visit http://www.danalytics.com for more information.

Decision Analytics. Integrating Lawson with the Real World.