Everything has been said and written about the role of pressure in software development; there's no need to reiterate that all over again. At least, that's what I thought until recently, when an executive called me in for one of those "let's talk frankly" chats. She had hired me to help her deal with the organization's disastrous bug rate, which had started to threaten its market position.

The software-as-a-service (SaaS) model really began to shake up the corporate computing world in 2006.

In the entire history of the buying and selling of consumers' personal information, I can't think of one scenario in which the consumer regularly took part in the transaction and thereby profited by it. In this billion-dollar marketplace, the consumer has been treated as an externality; an obstacle to overcome in the category-four-rapids flow of money between buyer and seller. Perhaps until now.

When I talk to people about agile project management and development, one of the things I hear consistently about is the lack of good release planning. Teams seem caught up in iteration-at-a-time plus backlog building and not planning for an entire release or project.

Last week, a couple of enterprise reputation risks items that I have previously written about hit the news once again.

I've had the opportunity to work with architects in a fair number of companies in diverse industries. Whether we were architecting individual applications or grappling with the complexities of an enterprise, the goal has always been to tease out the salient aspects of a problem and organize them in a way that speaks to a robust and flexible solution.

I have been involved with the IT industry for more than 20 years. I cut my teeth in the US Air Force programming big iron, using punch cards and an occasional turn at the green CRT. Over the years, I have seen many innovations in hardware and software -- from advanced programming languages and development environments to larger and larger amounts of memory fitting in smaller and smaller spaces.

In last week's Advisor (see "Even in a Flat World, Quality and Schedule Matter," 25 July 2007), we looked at The World Is Flat author Thomas Friedman's description of how a "connected" world has made it possible to do al

IT has been a critical part of the production of running a business since the early days of the IBM 360. IT supports every aspect of the business from human resources to operations -- yet it has primarily been perceived to be a part of the backstage crew.

In enterprise architecture, we're constantly challenged to overcome perceptions that we're in an "ivory tower" or being impractical or even irrelevant. In response, we should be looking for opportunities to provide value within the enterprise. Luckily, we're well suited with skills and well positioned organizationally to do so if we search out the right opportunities.

A reader asked me to name the major goals and benefits that organizations should seek to obtain by implementing business performance management initiatives. I've recorded my thoughts in this Advisor.

In my last Advisor (see "Summer Reading: Blink, Mirror Neurons, Antonio Damasio, David Gelernter, and Real Intelligence," 5 July 2007), I talked about Malcolm Gladwell's book Blink and how it got me thinking about how experts often know something is wrong in an instant, like when a big project is probably

In this Advisor, I'll tell you about integrity as a key to partnering. You can read about exchange and expansion in previous Advisors.

In the first part of this Advisor (see "A Stake on the Grill? Part 1: A Look at Drawing Information Out of the Right Stakeholders in the Risk Process," 19 July 2007), I traced the evolution of the stakeholder and stakeholder management. Stakeholder management is a critical component of risk management.

If you're heard of UML, then you've probably heard comments that it is big, unruly, and complicated, and that things are even worse with UML 2.0. Although I don't necessarily agree with the sentiment, I can understand where it's coming from. UML is a general-purpose modeling language, directed at IT systems. Well, IT systems are a big topic area.

We have been working with clients on establishing the project management office (PMO) function and pointing the PMO in the right direction. We have also been making presentations at conferences and at companies on this subject. Two questions often are asked: is the PMO important to achieving business value with projects, and what exactly is the charter for the PMO? Our answers are simple: the PMO is on the front lines of business value, and it plays a critical role in its achievement.

In The World Is Flat , author Thomas Friedman describes how a "connected" world has made it possible to do almost anything collaboratively with people around the planet.

I recently spent an afternoon and evening in a hospital waiting room while my wife was having minor surgery. I observed a few things that applied to supervising people and providing services -- two topics that interest most IT managers.

Service-oriented architecture (SOA) has been the hottest topic in software for the past two or three years, and it looks as though it will continue to enjoy that status for some time to come. Like Java, XML, and Web services, it has attained buzzword superstardom -- membership in that select clique of terms that seem fated to be continuously analyzed and debated by analysts, bloggers, and the media.

The latest acquisition to affect the data warehousing/BI market is IBM's announcement that it is buying real-time data integration specialist DataMirror Corporation for approximately US $161 million.

No sooner have CIOs and IT departments come to terms with the demands of SOA and BPM than they find themselves confronted with a new challenge: Web 2.0. Enthusiasm for this new phenomenon is sweeping the world. It began in the ranks of bloggers, but quickly spread to the technorati, journalists, industry analysts, and would-be trendsetters.

I work with a lot of database and data warehouse practitioners who have a hard time seeing how agile software development practices can be adapted to the complexities of data-centric systems integration and development. Large data volumes, integration of commercial software, disparate systems integration, and so on, make this adaptation a challenging one.

Stakeholder management is a critical component of risk management. If we know the things that our stakeholders value, we have a much clearer sense of what's at risk. However, for many of us, the challenge is identifying the right players and then identifying their true passions associated with our project(s).

If it hasn't happened already, eventually your organization is likely going to be faced with the question: should we use advertising-supported business software?

collaboration = innovation