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 https://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 mailto:letter-editor@lawsonguru.com 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. [Read More...]

- 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". [Read More...]

4. Can Isabel teach us about Preparedness?

Each autumn in the DC area, it seems we face a crisis. [Read More...]

5. Reader Feedback
Send your comments to mailto:letter-comments@lawsonguru.com.
In the last issue (https://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 mailto:letter-tips@lawsonguru.com.
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 https://www.danalytics.com.
To subscribe, send an email to: mailto:letter-subscribe@lawsonguru.com

To be removed from the subscription list, send to: mailto:letter-unsubscribe@lawsonguru.com

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

Decision Analytics. Integrating Lawson with the Real World.