[Excerpted from an article in the March 1995 issue of Cutter IT Journal . Used here with permission from the ITABHI Corp.]

Commonsense decision making separates the great companies from the merely good. True common sense, however, is not innate but acquired.

The great companies have learned -- most often after suffering painful failures -- that commonsense decision making requires:

Sometimes I wish that I worked for a large organization; one with lots of fancy, expensive technology. I have a small organization and we have a very limited budget for gadgets and new toys. I sometimes feel a little deprived. But recently, while visiting a client, it occurred to me that working for a small organization in this day and age is a distinct advantage.

I've been concerned for some time with how one can simplify and accelerate the development of large-scale business processes. I've begun to use the term second-generation BP to describe business process frameworks like the Supply Chain Council's SCOR and the TeleManagement Forum's eTOM/NGOSS architecture.

Model-Driven Architecture (MDA) is a broad church covering several approaches to model-driven development. People often think of models as blueprints that are filled in with code. Model-driven development automates the transformations among these several models. That is, MDA is commonly viewed as supporting "heavyweight," process-heavy modeling techniques.

Whatever happened to all the arguments about component standards? A few years ago, it was popular to talk of DCOM/.NET and EJB/J2EE and compare their relative chances of success. Some comparisons would even include the Object Management Group's (OMG) CORBA Component standard.

Here's another interesting finding based on the results of a Cutter survey conducted last September that asked 127 end-user organizations of various sizes located worldwide questions designed to measure the adoption and use of enterprise information portals (EIPs) in conjunction with other information technologies and business strategies.

In the first Bulletin in this two-part series (" Best Practices for Combatting Malicious Software, Part 1," 4 March 2004), I began an examination of the components that must be considered when developing an information security program. In this article, I conclude that discussion.

Recently, one of my clients and I were discussing a project that his team had deployed some time ago. It was a real success story in risk management. The team had skillfully managed the deadline and the scope, using project simulations of where things were heading, and delivered within two weeks of their 90% probability date.