IT shops generate oodles and oodles of metrics. IT hardware and software can spit out hundreds of operational metrics, mostly to monitor system performance and diagnose system errors. On the hardware side, routers, switches, and data devices produce metrics that let operators infer the volume and kind of use patterns at work.

Despite often-touted alternatives and real drawbacks, the enterprise data warehouse remains a very popular architecture for providing the data integration and management foundation for end-user organizations' BI environments. Moreover, my research indicates that use of enterprise data warehouses will continue to grow for the foreseeable future.

Making business decisions is never easy. It becomes progressively more complicated as those around us offer their "two cents' worth" on how we should act or what practices we should adopt. And the sheer number of those around us sometimes means that we receive input from a host of different parties, all with different perspectives.

Times of crisis provide the opportunity to ask whether any innovation and agility is still possible. The answer is not simple. One way to treat a crisis is by cutting costs. This is not a bad solution, and it is often very justified, but one must be aware that it may create extra danger for the future.

Many software development organizations have a growing realization that they need a more formal process than "seat of the pants." They are aware that many development methods are overly bureaucratic and unhelpful, particularly for small and medium-sized enterprises. They hear that agile processes may help, but how do they make the transition to a modern-day process? How do they determine how much agility the agile processes on offer today really possess? How do they determine how much agility they need, anyway?

If cloud computing wasn't the number-one IT buzzword in 2008, it had to be pretty close. In all likelihood, it will probably hold this place in 2009. But let's face it, cloud computing is still in its infancy. This becomes vividly apparent when you consider the almost complete lack of (open) standards pertaining to almost everything associated with using cloud architectures.

Organizational skepticism about the virtues of a new technology idea are likely to run, at least in part, in direct proportion to the economic climate in which the company finds itself. When times are tough, it is essential that managers follow the basic rules of winning buy-in from key constituencies for their IT investment ideas. Here's how.

First, remember what buy-in means. It is not acquiescence or compliance but enthusiastic, active support for an investment proposal from relevant employee populations in the organization.

Are you ready for a fresh perspective on agility, architecture, and SOA? Then check out Building the Agile Enterprise with SOA, BPM and MBM, a book by Fred Cummins (Morgan Kaufmann, 2008). Don't let the title scare you away.

Many are engaging with Web 2.0 technology in their personal lives, and increasingly at work. Even if you don't think there's much new in Web 2.0 technologies, that it's merely a renaming of extant things, you can't ignore the power of them as presented now, and as widely adopted. It is perhaps the level of adoption of these technologies, combined with the potentialities for social interaction of different kinds, that make Web 2.0 so interesting from an ethical perspective.

Our research indicates a gradual but certain increase in the use of real-time data warehousing techniques -- such as trickle-feeding data from production sources or using technologies that capture changed data -- by end-user organizations to enable real-time updating of their data warehouses.

In my experience, firms that take on agile transformation initiatives have two very different types of leaders involved in the process. The first is an executive sponsor who has the resources and patience to stay the course while others around that individual get used to what it takes to be agile.

There are four critical areas in managing large projects: people, product, plans, and tools.

There's a compelling phenomenon that happens with the commonplace aspects of our lives. The boredom that is frequently associated with the average concerns in our day-to-day existence evolves into a willing ignorance that those concerns even exist. In our cars, we sometimes become oblivious to the fact that speeding inherently carries with it a higher level of risk.

It is just over a week since US President Barack Obama's inauguration, and people are wondering what to talk about next. There are a number of obviously significant issues (war, global warming, the economy, etc.). All are of momentous concerns, and how Obama handles them will affect many of us.

A center of excellence (COE) is not a new concept in business management. Even in offshoring, the creation of IT development centers to more effectively coordinate the application development work of distant service providers is a well-established type of COE. Yet the COE concept in offshoring has matured from its development center roots, taking on a more strategic aspect. The features of the evolved offshoring COE that offer value to managers are worth exploring for what they say about the evolution of offshoring as a management discipline.

A good friend of ours who is very active in business strategic thinking in many industries has mentioned to us that only 20% (or less) of business strategies and goals actually are worked on. This squares with our own experience in working with more than 100 companies worldwide. How can we plan IT to support business strategies if 80% of those strategies do not in fact drive business activities? On the other hand, we know that business managers undertake many initiatives that are not, strictly speaking, connected to the business strategy statements.

A recent blog post from the Burton Group on the alleged "Death of SOA" has been causing quite a stir.1 The contention is that the bad economic situation has finally finished the "SOAsaurus" off and that we must now concentrate on services, along with mashups, cloud computing, and software as a service (SaaS) -- and not service-oriented architecture (SOA).

The cloud hype continues to spread into just about any IT category, whether it's computing infrastructures (IAAS), platforms (PAAS), storage (scaling on-demand), applications (software as a service [SaaS]/cloud software), and even newer categories, such as integration on the cloud (IAAS). The list goes on.

Cloud models are now presenting CIOs with new ways of dealing with the shrinking IT budgets by allowing them basically to move nondiscretionary activities to discretionary.

I think that many end-user organizations are going to have serious reservations about deploying their data warehouses permanently to the cloud, certainly at least initially. This is quite understandable, given that most companies tend to view their data -- especially customer data -- as a strategic asset.

The production systems environment in its basic role should serve production and commercial purposes. If left unaddressed, the cloud of changes delivered by various software development initiatives would be implemented in the production environment independently, with each introducing some sort of risk and disruption to production systems work.

I think that many end-user organizations are going to have serious reservations about deploying their data warehouses permanently to the cloud, certainly at least initially. This is quite understandable, given that most companies tend to view their data -- especially customer data -- as a strategic asset.

To make something new, you have to decide when it's done. If it's really new, it's unique, and you don't have anything to base a decision on but the thing itself. So you're in exactly the same position as an artist deciding on closure.

There are four critical areas in managing large projects: people, product, plans, and tools.

While I am normally not one for tilting at windmills, I do have to take on the October 2008 Cutter Council opinion against the "cheaper, better, faster" (CBF) philosophy. In their 7-0 opinion (see "The Cheaper and Faster Tailspin," Vol. 9, No.

There are four critical areas in managing large projects: people, product, plans, and tools. In a previous Advisor, I discussed the collaboration aspect of people in teams (see "Help Agile Scale by Fine-Tuning Collaboration," 11 December 2008), and in another I covered organization and management style (see "Scaling Agile: People and Organization," 24 December 2008).