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
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

"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, go to http://www.danalytics.com/solutions/ (web site registration required), and select the "Understanding Lawson Object IDs" article).

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:

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 mailto:letter-comments@lawsonguru.com.

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/