A good friend of mine, who was quite active in the AI community in the late 1980s and early 1990s, asked me an interesting question the other day: "When did rule-based systems go from being 'expert systems' to 'business rules management systems'?"

Microsoft's announcement that it is developing a new, comprehensive business performance management application called Office PerformancePoint Server 2007 was received like a 500-pound firecracker detonating at a fireworks show. Everyone has been expecting something from Microsoft in the way of a major BI announcement, because of the way it has been aggressively assembling all the necessary pieces for a more comprehensive BI product strategy (either through product development or acquisitions) over the past few years.

A couple of weeks ago, I wrote a Trends Advisor entitled, "Why You Might Not Want to Sell Your Google Stock Just Yet" (4 May). In that column, I pointed out that Google had made an acquisition of one of the more interesting 3D tools that I'd seen in recent years: SketchUp. Because it is so easy to model things, especially buildings, I speculated that Google had pulled off a coup.

Corporate scandals leave a long, bitter aftertaste. While last month's convictions of Enron's Ken Lay and Jeff Skilling may signal the end of the most notorious corporate scandal of recent times, it has not signaled the end of the problems associated with poor corporate governance.

I was recently asked to give a talk to a group of Irish software companies about software process improvement (SPI). As I thought about the topic, I realized that to most people, SPI conveys expectations such as deterministic, comprehensive early planning; a detailed process focus; waterfall (serial) lifecycle (planning, requirements, design, etc.); extensive documentation deliverables to show progress; and internal metrics.

Knowledge transfer represents a critical stage in the transition phase of a business process offshoring (BPO) project. Often, the offshore service provider (OSP) staff, although skilled, might lack specific expertise unique to the specific business processes they will oversee. It is vital that the offshoring organization establish a structured, disciplined knowledge transfer program to ensure that OSP personnel are adequately prepared to assume daily business process management when that day arrives.

Projects sometimes happen to deliver a product that meets every requirement specified but ultimately appears not to address important needs of the stakeholders. Certainly there are many possible causes for that. In this Advisor, I focus on one cause that I believe is not always properly understood -- partly because of the flawed notion of quality of IS systems. The problem I will address is that of requirements quality and responsibility for requirement analysis in the context of IS procurement.

The great rush to decentralize heirarchical decisionmaking in American corporations has been accompanied by a well-intentioned but hopelessly misguided faith in the power of teams to reach optimal decisions. In the realm of IT decisionmaking and governance, teamthink is as often a value killer as creator. Consider the ways this is so, first.

Effective coordination of the innovative minds, both within the company and externally, is necessary to tap the creative juices of the best contributors. This is a difficult problem, since we have created organizational silos that don't necessary welcome external inputs. An innovative culture has to be rebuilt and reconnected for effective communication and collaboration.

Oracle announced last week that it will acquire Demantra Inc., a vendor of demand-driven planning applications that use BI analytics to help manufacturers and retailers predict demand for their products based on seasonality, long- and short-term trends, and promotions and pricing changes. Oracle is expected to finalize the deal later this month; however, financial details were not disclosed.

I bumped into an old friend at the Cutter Summit last month whom I hadn't seen for several years. He told me he was now a member of the nefarious three-time losers club as a CIO. When I asked what had happened, he described a consistent story of joining fast-growing, venture-capital-funded, small- to medium-sized firms, and having a wild ride for a couple of years. Inevitably, entrepreneurs in the firm would give way to professional management, and soon thereafter, so would he (my words, not his).

A friend of mine evocatively condemns many development organizations as "team ghettos." Designing a team ghetto is easy: organize developers into teams and organize management into silos over the teams, then watch the predictable inversion layer form between the two environments so that nothing ever gets across whole and unscathed -- not information, not people, and certainly not trust, honesty, and the truth about operations, competition, customers, progress, and results.

In the business world, one man's risk is another man's opportunity. So, too, risks that are insignificant for one type of business may be of major concern to another. The risks faced by an IT project are in themselves not unique. Any risk that can be postulated for an IT project can be identified in the risk environment of projects in other technical areas. What is different and generically characteristic of IT is its typical project risk profile. By their very nature, IT projects tend to exacerbate certain kinds of risk.

There's a clever saying that goes: "In theory, there's no difference between theory and practice, but in practice there is." This difference was driven home to me on a recent engagement where I spent time with two different groups at the same multinational corporation. In the morning, I discussed SOA with the architecture steering committee (name changed to protect the innocent), where we discussed the issues of SOA and what was needed to realize that potential at the enterprise level.

In the first half of this Advisor ("The Bane of the Automatic Stay in Bankruptcy," 10 May 2006), we took a look at careful contract wording as one way customers can protect their rights in the event that a software development vendor files bankruptcy.

We have recently encountered troubled CIOs and IT organizations with common symptoms. These symptoms characterize the uneasy relationship between IT and the rest of the business. As one CIO put it: "my business users do not understand what we do, and worse, do not value what we accomplish for them." As a result, the business users complain loudly about IT in general and about the high costs of IT in particular -- and this is never good.

IT organizations in trouble have the following symptoms in common:

Whenever we head into uncharted territory, whether it is a trip across the country or a lunch with a friend at a new restaurant, we always try to identify where we are or where we are headed by using commonly known reference points. The greater our common familiarity, the more detailed and precise our reference points can be.

Informatica Corporation is the latest software vendor to enter the software as a service (SaaS) market with a number of new announcements. First, Informatica detailed a bold new on-demand strategy. Second, it just introduced connectors for its PowerCenter data integration platform specifically tailored for Salesforce.com customers.

The art of risk management is the art of clairvoyance. Risk management is the ability to both foretell the future and to do something about it. Risk management has long been analyzed in the context of business financials, organizational behavior, project breakdowns, and individual perspectives and attitudes. In each instance, it has largely been focused on the risks of a given point in time and a given set of circumstances based solely on today's knowledge.

Web 2.0 has become kind of a metatag to describe a number of evolving features and capabilities of the protean Internet. One of the most pronounced advancements is the software-as-services trend demonstrated most vividly by Google. What near-term implications does this trend bode for the enterprise?

The US National Oceanic & Atmospheric Administration (NOAA -- www.noaa.gov) released its 2006 hurricane forecast this week.

This Advisor on alignment is the fifth in a series on agile integration (see "Agile Integration -- Organizational Processes," 4 May 2006; "Agile Integration -- Assembling a Team," 13 April 2006; "Agile Integration -- Making Agile Work in Organizations," 2 March 2006; and "Agil

There is no shortage of reasons for an organization to offshore business processes and services. Often organizations enthused about the perceived cost reductions and efficiencies from offshoring are blinded to the possibility that at least in the near term, offshoring is a bad idea. What reasons could emerge that tell the company this? There are a lot, in fact.

Last November, I covered the merging of business process management (BPMS) and business rules management systems (BRMS) (see "The Merging of Business Process Management and Business Rules Management Systems," 16 November 2005). I also discussed differences between how the two technologies utilize business rules as well as how they are complementary.