Web 2.0 technologies -- such as wikis, blogs, RSS filters, mashups, podcasts, folksonomies, crowdsourcing, social networks, and virtual worlds -- are very hot. Everyone is excited about deploying them, especially because they're fast and cheap. But what do they really deliver?

I have previously suggested six dimensions of impact:

Knowledge management (KM)

Last week, Microsoft shed some light on three BI and data warehousing projects it's working on: Gemini, Kilimanjaro, and Madison.

As with all enterprise search systems, the usefulness of a BI search tool depends primarily on the relevancy of the search results returned to the user when conducting searches and the ease with which users can carry out their searches successfully.

In a recent Advisor (see "To Attract Agile Change, Embrace Uncertainty," 11 September 2008), I discussed the need for managers and teams to embrace uncertainty in development efforts and, furthermore, that this is very difficult to do.

There was an interesting story a few weeks ago in the Wall Street Journal about the electronic retailer Best Buy's internal prediction market [1]. Company executives use the prediction market, called TagTrade, to see how successful Best Buy employees think a particular project, idea, or initiative will be.

We like to think that knowledge is cumulative -- what mathematicians refer to as monotonically increasing. Unfortunately, that is not the case. For example, we no longer know how to build pyramids as the Egyptians did, make violins and cellos the way 18th-century Italians did, or, surprisingly, how to build the rockets that got the first man to the moon.

We need to rethink dispute resolution. It has matured in concept and approach so that it becomes not just a useful tool in managing conflict by problem solving but a vehicle for creative collaboration. We might want to start by renaming it, because what we call it influences our perceptions of its uses.

Strategic orientation toward customers and innovation needs to be grounded, understood, and directed in response to the business strategic plan. Businesses that develop a comprehensive strategic plan will have the insight to know which strategic-orientation mode will best help them reach their goals.

Most applications, enterprises, or products will have unique architectures designed to meet their specific goals and requirements, though many of them will be very similar. For example, the architecture for a portal application at one company will probably resemble a portal application at another company of like size and business function.

There is a lot of interest at the present time in the role that Enterprise 2.0 Web applications can play in enhancing business performance. In a survey recently conducted by Trampoline Systems, a London-based provider of social networking software, 94% of UK and 82% of US businesses believe the new technologies will be beneficial to use at work. Other recent research shows similar results.

Last week, I was briefed by the folks from Success Metrics, which has just introduced a new on-demand BI offering: Birst. I say "new," but the product actually has been in use for several years now by a number of customers in various one-off applications.

Recently, I had a conversation with a senior VP of software engineering who said that certain "macroeconomic trends" were going to influence the direction of his software development strategy. Reading between the lines: the CFO was going to cut budgets in the face of the current economic downturn.

Ambiguity: source of headaches, grinding teeth, and any number of other managerial complaints for which big pharma has yet to offer us a pill.

Ambiguity: source of excitement, the thrill of the chase; the product of change, and the lair of innovation.

For some time, my favorite topic has been agile enablement, and, surprisingly, I have found a lack of decent information about the more subtle aspects of transitioning an organization that follows more traditional software engineering practices to more of an agile approach.

One of the ugly truths behind the desire for powerful enterprise software is that the business people expert in the processes the software will oversee don't know how to program and the programmers who build the software know nothing of the business processes around which the software will be built. Into this void have come a number of project methodologies in which programmers and business experts collaborate to deliver a product that sometimes in the end takes too long to build, is rife with bugs, and which everyone dislikes.

We have worked extensively with clients this year on their IT strategic plans. One way we characterize the best approach is to distinguish between the "supply" and the "demand" components of the plan. This month, we'll focus on the "supply" side and next month on the "demand" side. (Incidentally, doing an effective "demand" side of IT strategic planning is by far the more critical and least understood.

One of the problems with the IT field is that, absent something like the model year for cars popularized by Alfred Sloan in the 1920s, IT companies have to keep coming up with new terms for old ideas. Recently, I've found myself in meetings with consultants and IT managers in which the term "metadata" has been used to allow a group of clueless participants seem with it.

In Part II of this series (see "Centers of Leadership: The Marriage of COEs and Servant-Leadership as an Effective Way to Lead IT, Part II," 3 September 2008), I talked about the need for IT servant-leaders to "get small" in their approach to building community and wielding authority. In this segment, I'll touch on a somewhat-related approach: getting lean.

Last week, Oracle announced two new products targeted at high-performance data warehousing applications: the HP Oracle Database Machine and the Oracle Exadata Storage Server. These products package hardware from HP with database accelerator software from Oracle to form what is essentially a high-performance data warehousing appliance.

The best way to minimize risk is to nip conflict in the bud and to turn it to an organization's advantage.

One of the prime drivers for many organizations moving to agile development is to improve schedule performance. Unfortunately, many facets to schedule performance are often overlooked. Often when I ask, "In what way is your schedule performance lacking today," the answers are very fuzzy. Many managers just have some vague notion that they would like better performance.

How far can you go before you cross the line between ethical behavior and high-risk behavior? It's a question I've been asking quite a few project managers of late, and I find their responses compelling. The question is a seemingly simple one:

If there is to be a true discipline of software engineering, then those of us "doing software engineering" should look closely at how those people in other disciplines who call themselves "engineers" or "architects" actually go about "doing engineering"

Software-as-a-Service (SaaS) is more than simply an application-hosting model. It is an integrated service that involves implementation, hosting, and ongoing maintenance services. In addition, the technical architecture of the SaaS model constrains clients' options for customizing the application at the core level of the application (e.g., changes in data schema). Customers also have less control over the changes that are made to the application by the vendor throughout its lifecycle.

The IT shop aside, most firms find it difficult to truly become customercentric. Many firms have paid dearly for all kinds of studies on their customers, including research under the banner of voice-of-customer (VOC), customer experience, customer-relationship management (CRM) strategy, customer loyalty and retention, and good old-fashioned market research.