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).

As it was two millennia ago, today a decimation of sorts remains a distressing part of our cultural experience.

As 2009 brings dramatic change to the economy, politics, and IT, some consistency might be in order. So, as I have in the past, I've devoted my first Advisor of the year to suggestions for New Year's resolutions.

It's 2:12 am. The cell phone is ringing. What now? It's Amy, a data center technician. She wouldn't be calling me unless something is wrong. Very wrong. She tries to explain that the primary storage network is failing. And the path to the backup is failing, too. She can't tell what it is. Everything is coming down.

BI and data warehousing appliances -- prepackaged offerings bundling software and hardware designed to support specific data warehousing and BI applications -- continue to garner strong usage. This trend is expected to continue through 2009 as end-user organizations look for ways to cost-effectively advance their data management and analytic needs.

Challenges abound in every enterprise, but the success of most major initiatives requires that all relevant parties understand the breadth and depth of the problem, the current environment in which the problem exists, and the impacts and implications of potential solutions.

How much architecture does an agile team need up front? Most agile methods are surprisingly silent when it comes to this question. Scrum regards architecture as an issue the team has to deal with on its own discretion -- and thus does not include any advice.

The beginning of 2008 started off with the French bank Société Générale reporting that a low-level employee, Jérôme Kerviel, had executed a series of "elaborate, fictitious transactions" that cost the bank more than €4.9 billion, the largest loss ever recorded in the financial industry by a single trader.

Among other things, 2008 was the year that models died on Wall Street. After decades, the "quants" were just as surprised as everybody when the market started down and, instead of pulling out, just kept on going south. For years, the idea of "program trading" has gained a bigger and bigger foothold in the world of high finance.

The beginning of 2008 started off with the French bank Société Générale reporting that a low-level employee, Jérôme Kerviel, had executed a series of "elaborate, fictitious transactions" that cost the bank more than €4.9 billion, the largest loss ever recorded in the financial industry by a single trader. However, Kerviel's escapade pales in comparison with those of investment advisor Bernie Madoff, who admitted in early December to defrauding his clients of upward of US $50 billion in a "giant Ponzi scheme" for years.

This Advisor looks at debriefing the unsuccessful bidders after a competitive bidding process has closed. This is often treated as an optional process -- and is usually one to be avoided. However, if done well, with the right intent, it is a valuable exercise for all, and can also create support for your future bidding opportunities.

This Advisor looks at debriefing the unsuccessful bidders after a competitive bidding process has closed. This is often treated as an optional process -- and is usually one to be avoided. However, if done well, with the right intent, it is a valuable exercise for all, and can also create support for your future bidding opportunities.

Mergers and acquisitions (M&As) -- and even divestitures -- represent opportunities to reengineer technology acquisition, deployment, and support. Like other major corporate events (such as missing earnings estimates five quarters in a row), M&As can be exploited to make decisions that somehow get endlessly tabled in the routine ebb and flow of many companies.

Mergers and acquisitions (M&As) -- and even divestitures -- represent opportunities to reengineer technology acquisition, deployment, and support. Like other major corporate events (such as missing earnings estimates five quarters in a row), M&As can be exploited to make decisions that somehow get endlessly tabled in the routine ebb and flow of many companies.

Despite the reality of service-oriented business -- as evidenced by partnering, collaboration, outsourcing, core competency focus, and the like -- many software solution projects aimed at solving business problems do not yet use service-oriented architecture (SOA) as a key enabler. I hear a variety of reasons from project managers for this, including the following:

Cloud computing is a prominent concept in the IT technology world. Cloud computing and software as a service (SaaS) promise fast return on investment, agility, improved scalability, availability, and more.

Grid computing did not generate as much attention in 2008 as it did in 2007. However, our research indicates that use of grid architectures to support data warehousing and BI by end-user organizations has grown considerably. Yet despite this development, use of grids in such a capacity still remains fairly limited.