For the past few years, I've covered the use of business rules management systems (BRMS) due to their ability to add automated decision-making capabilities to applications in domains such as personalization, marketing, compliance, fraud, and business process management (BPM), to name a few.

An effective plan provides guidance and direction to the people who will implement the plan. Regardless of the type of initiative that is being planned (business, investment, marketing, project, etc.), the plan describes not only the business problem and proposed solution, but also the strategies and tactics to be followed during implementation.

Aligning IT execution with IT strategy means knowing the value projects bring to the table. This value has to be measured in some way meaningful to those providing the funding or consuming the benefits. The units of measure for both the cost and benefits is usually in dollars or some percentage of dollars. The physical prioritization of suggested projects starts with a "paired comparison" analysis rather than a linear ranking. The linear approach falsely sorts the projects by failing to distinguish between real need and perceived need.

For me, the most telling and important statistic in Cutter's recent survey on the state of BI is the percentage of employees that use BI tools: 57% of respondents indicate 0%-9.99% and 70% indicate 0%-14.99% (see Cutter Benchmark Report, "Successful Business Intelligence: Moving Beyond the Obvious," Vol. 7, No. 9).

Two weeks ago, I was practically bombarded with e-mail from readers asking if I knew anything about the possibility of Business Objects being acquired. Like many, I'd heard the rumors, but I couldn't really say anything definite because they had been circulating for at least a year. Turns out that all the increased "chatter" was right after all.

This Advisor suggests you take a hard look at your strategic technology alliances. How many do you have? Are they productive? How do you decide which ones to pursue -- and which ones to terminate? Some of the alliances you may have include:

Channel alliances to sell your hardware, software, or services

My 2 August 2007 Advisor discussed the need for, and lack of in many instances, good release planning (see "Release (Project) Planning"). In the rush to deliver in short iterations (weeks), teams often suboptimize their pursuit of business value.

Last Wednesday was like any other Wednesday. I was busy working on some reports when at 0819 I received an e-mail from a person named Alex stating that he was changing jobs in a few weeks, and that he would like to receive the US Department of Homeland Security (DHS) daily reports at his new e-mail address.

As a kid growing up in a musical family, I was trained as a classical violinist. My favorite musical settings were ensembles; whether playing chamber music with my mom, dad, and brother, or playing the great symphonic works in youth orchestra.

Last week, an article titled, "Big Spenders Reveal they know little about the value of IT Assets," appeared in the Financial Times (1 October 2007). The article reported on research conducted by MicroFocus, UK provider of enterprise application management systems. The essence of the findings (covering 250 firms, half in the US and half in Europe):

Most CIOs (and half of CFOs) do not quantify the impact of IT investments on the company

To multisource or not to multisource? This is a question that will grow in importance as the size of sourcing and the varieties of processes sourced marches upward. In true, two-handed fashion -- on the one hand, on the other hand -- let's consider multisourcing's value first, then some of its risks.

Of all the areas in which technologists can make strong contributions, business intelligence (BI) is at the top of my list. After all, BI solutions touch people who make decisions. They are a primary means, a sensory organ, by which the firm comes to know its environments, both internal and external. The visual presentation layer of the tool interacts with human thought.

An agile requirements strategy is one where there is no wasted effort. All the effort you spend on requirements (meeting, interviewing, modeling, reviewing, prototyping, documenting, testing -- everything) brings you closer to being able to meet your project's goals. But not all projects have the same potential for agility.

The majority of organizations using -- or planning to use -- on-demand BI and data warehousing solutions require that the application/service be customized to support their data analysis and data management needs.

Recently, Nokia purchased an American company named NavTeq for US $8 billion and some change. Like most technology acquisitions, the people on the business channel had a little trouble explaining what all the money was about and why one of the stock market's darlings, Garmin, had suddenly taken a hit.

Last month (see "The Roots of Agile, Part 1," 6 September 2007), we broadened the concept of agile software development by considering the underlying factors that make any development process more agile, whether it is a software development process that can take advantage of certain special characteristics of the software medium or the development of a non-software product for which conventional agile software techniques would not apply.

In my last Advisor, "ITSM and SOA Part 1: Coincidence?" (26 September 2007), I discussed ITSM and its service management processes. Now let's look to see how or if they really apply to SOA. To do this, we'll start by examining the service lifecycle and some of the challenges that face successful SOA adoption.

There is new interest in an old standard to improve IT management performance. The Information Technology Infrastructure Library (ITIL) is well known in name, if not as much in usage. While we hoist our glasses in recognition of the noble intentions of organizations that seek an internal transformation through ITIL, bountiful good means bountiful change. Some organizations might lose the institutional endurance to see through a multi-year ITIL implementation effort when they comprehend the implications of this fact.

There are some very basic things that systems engineers should be taught. These things are both fundamental and classic. They are fundamental because we can reuse them in a very wide variety of software engineering (SE) situations. They are classic in the sense that they have a very long usefulness half-life. They are probably useful for at least a career lifetime. When I was in my 20s, I decided to collect, to learn, and to develop these SE basics. Now, in my 60s, I am more than ever convinced that these fundamentals should be shared with students.

The latest Web 2.0-related developments to move into the corporate world are mashups.

For some time now, Oracle has offered what it calls "Information Appliance Foundations," which are reference configurations that specify a recommended database, server, and storage mix for a customer's data warehousing requirements. These specifications, however, do not actually bundle the various software and hardware. Thus, they are not a data-warehousing appliance, per se.

China is a vast country with abundant human resources. Today, China is undergoing a rapid amount of change as its people build a modern, high-performance economy. Given continued rapid economic growth along with population concentration, China is moving into an age unprecedented in human history, the age of the Megalopolis.

The Agile Manifesto principle of "working software over comprehensive documentation" has often been misunderstood as either "no documentation" or an excuse for "ad hoc" development. In the principle statement, the word "over" implies that working software is more important than documentation, but not that the documentation isn't important or useful.

A few tenets of faith on risk management:

Risk management is a comprehensive evaluation of what may or may not go right within an organization, and a series of actions related to that evaluation.

Risk management is the challenge of establishing a common vision of when and how an organization should react and respond.

I'm not sure where the expression "Parts is parts" came from. I think it had something to do with fast-food chicken, but it implies that not all parts are the same, which certainly fits when we talk about services. After all, what someone means by "service" varies widely based on the context, even when we limit the scope to IT.