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.

We just completed a Cutter survey on IT budget and costing practices (for more on Cutter's survey, see the Cutter Benchmark Review, August 2007). This is the second year of the study (see also Cutter Benchmark Review, August 2006).

On many offshore projects, there's a high degree of parallelism between the requirements and the build/code/test phase.

As project managers, most of us have experienced problems on projects. Most of us have also received help (that seemed more like interference) from concerned colleagues and superiors. Back-seat driving, nit picking, hindsight memos -- none welcome, none helpful. There is, however, an alternative. Let's start with the usual "help" and move onto something that is helpful.

nit: noun, the egg or young of a parasite insect.

nit picking: verb, inspecting someone closely for the presence of nits and then picking them off.

In the rush of sourcing issues that threaten to pull you under like a riptide, it is worthwhile sometimes to step back and recalibrate your perspective to better understand the current sourcing environment as a necessary step in planning for the future.

Several current sourcing issues loom over managers. Here they are in no order of importance or urgency. All are worth watching closely.

Here's an interesting finding: although on-demand BI and data warehousing solutions are receiving increasing interest from organizations, my research indicates that their use requires that companies modify their business processes.

Every once in a while, someone I respect gets something wrong -- I suppose that it just shows everyone is human. Michael Stonebraker is one of my longtime heroes.

In my last Advisor (see "On Tools in Agile Development, Part 1," 23 August 2007), I talked about tool requirements for agile developers. In this article, I focus on tools for team support, while the next Advisor will discuss tools that help in planning agile projects.

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

Last month, we examined the first of the seven essential questions of planning: "what?" (see "Principles of Planning, Part 2: The Seven Questions," 15 August 2007). In that Advisor, I talked about the importance of clearly defining the business problem for which a solution will be developed or acquired.