Any IT manager worth his or her salt can give you at least a dozen reasons why waterfall methods are passé. Yet the semicontractual specification that is the usual result of requirements engineering is clearly a waterfall artifact. What flows over the waterfall is the spec.

A client asks about methods to increase the trust between IT and business managers and staff. It seems the relationship is currently broken: business managers don't trust IT, and the feeling is mutual.

I just attended the Architecture and Design World 2008 conference in Chicago, Illinois, USA. It was an exciting collection of 300-plus architects and designers with an array of about 75 talks that provided a good representation of what's of current interest to software architects and designers.

A common business adage these days is that "if you don't move forward, you will fall behind." This is reasonable, in a sense. There is a good chance that in a competitive environment, maintaining the status quo internally will give others an opportunity to make advances and leave you in the dust. In effect, you indeed fall backward.

I have a problem with this, in that it implies that our approach should be to aggressively stay ahead of the competition in order to survive.

Microsoft has announced it is acquiring data warehousing appliance specialist DATAllegro, Inc. Microsoft plans to convert DATAllegro's massively parallel processing (MPP) data warehousing appliances to work with the Microsoft SQL Server database.

In far too many organizations, bureaucracy is an inherent impediment to success.

"How do I know what I think until I see what I say?" -- commonly attributed to novelist E.M. Forster

This is a continuation of a series of recent Advisors on quality (see "Intrinsic Quality?" 3 July 2008 and "Investigating Agile: Inside and Out," 19 June 2008).

In our just-published Cutter Benchmark Review article (see "Linking IT Budgeting, Governance, and Value," Vol., 8, No. 7), we report that only 27% of managers of large companies believe their IT is superior to that of their competition. (By "large," we mean companies with more than US $50 million annual spend.) For all companies, regardless of size, only 39% of managers believe that their company's IT is superior.

Wow.

I once wrote a project plan for a global team with a business challenge of developing a model for the formation and management of worldwide strategic alliances. The seven team members were physically situated in different cities and time zones; we were part of an international executive education program to study key management issues of global enterprise.

Increasingly, we're hearing about cloud computing, with a host of companies -- including Amazon, Google, Hewlett-Packard (HP), IBM, Microsoft, Oracle, SAP AG, and Sun -- all promoting it to varying degrees.

Is the role of your change management specialist really that of a trainer? While training is essential to a successful change management program, it is only one piece of the puzzle. As with any change program, there is considerable change happening with many potential points of failure. So how do you mitigate them all?

Advanced data visualization tools have been around for some time. They first gained a following among scientists and engineers, who used them to build models for fluid-flow analysis, aerodynamic simulation, and other complex applications involving large data sets with many cause-and-effect variables.

On the face of it, we all can agree that how a company does its work matters a great deal. The continual interest in reorganization, the business process reengineering explosion of the 1980s, and the now nearly universal acceptance of the business process and organizational structure as fundamental to good performance give proof to this truth.

Many agile teams do their estimations in abstract measures, such as story points or complexity points, rather than using effort or time. Though the difference is subtle, abstract measures allow a self-adapting estimation process, decrease wish-based planning, and increase realism.

In far too many organizations, bureaucracy is an inherent impediment to success.

I was reading an article today that claimed that parallel computing is the next big thing [1]. I heard a similar refrain in an interview with someone from Intel. The premise behind this idea is that the first age of Moore's Law is ending and the hardware guys are beginning to panic.

Necessity is not only the mother of invention but apparently the father of invention offshore. A gaping need for domestic technical talent is causing US technology-driven organizations to site product development and R&D functions where there exists an abundance of engineers.1 Not surprisingly, this flavor of strategic sourcing has little to do with offshoring's historical allure -- saving money.

How many times have you left your office at the end of the day reflecting, "I spent the entire day in meetings"? And then wondered to yourself, "When do I find time to get some work done?" You also possibly didn't remember to think, "I wonder what's happening elsewhere in the organization." Does this scenario sound familiar?

Practically everyone has started down the path toward software-oriented architecture (SOA). Industry surveys show that 80% or more of enterprises have already adopted, or are in the process of adopting, some kind of SOA. We're told we need to for a variety of reasons, although the ones we use are often not the best reasons for us to consider it.

Second Life [1] and virtual worlds like it are Internet-based platforms for collaboration and socializing, which provide users with a 3D experience and a community. Second Life is a platform on top of which users, called "residents," can create their own world with 3D content and associated software, realize their ideas, and even earn money.

BI and business performance management vendors have offered facilities that give mobile users the ability to view and interact with performance-related information -- managed by their BI tools and analytic applications -- via such wireless devices as smartphones and PDAs for years.

We think of agile methods as a family of approaches aimed at dealing with uncertainty. If there is a high level of uncertainty about what exactly you will end up building, then the agile approaches (all of which call for multiple short iterations with ongoing customer feedback) make enormous sense. With the agile methods, we incrementally steer our way to a useful system.

Last month, I had the privilege of being one of four keynote speakers at the Better Software Conference in Las Vegas. I'm not a gambler, so I didn't partake at the card tables or roulette wheels, but I do watch software project managers gamble all the time, so it seemed to be a fitting place for a technology conference.

Ever since the private sector's recent discovery that meaningful technological innovations didn't necessarily include a price tag, we've had open source innovation. While "free" overstates and misstates the value of open source innovation (OSI), the characterization does not miss by much. So far.