One of the first aspects of getting a risk management practice into place is to find out what you actually do and don't know to sensitize yourself to any unjustified overconfidence. The initial step to understanding what we know and don't know is to discover what's controllable; i.e., what are the boundaries of the action, situation, or event that might be posing risk.

One of the first aspects of getting a risk management practice into place is to find out what you actually do and don't know to sensitize yourself to any unjustified overconfidence. The initial step to understanding what we know and don't know is to discover what's controllable; i.e., what are the boundaries of the action, situation, or event that might be posing risk.

I suggested in a recent Advisor (" Relational and Object-Oriented Database Design in the 21st Century, Part 1," 27 January 2005) that there was a battle brewing -- a battle between the database community (and the enterprise architecture community) and the development community.

I suggested in a recent Advisor (" Relational and Object-Oriented Database Design in the 21st Century, Part 1," 27 January 2005) that there was a battle brewing -- a battle between the database community (and the enterprise architecture community) and the development community.

Part of my consulting practice is to perform assessments. Sometimes, those assessments discover misalignments between IT and the business. Misalignments show up as "problem" projects, "inadequate" testing, and other typical problems in IT. It turns out, though, that many IT misalignment problems can be solved by small changes in IT work processes.

It's been almost five years since Web services were first introduced, and it's probably a good time to check in on how they're doing and where they're going.

Today, we have new knowledge about software measurement. Because it's an emerging discipline, we know more about it today than ever before. The emergence of the Internet and Web-based development has had significant impact. During the Y2K transition, additional patterns arose. A major economic downturn, agile methods, and application development and management outsourcing brought other dynamics. Today, software measurement operates in a new context, and its purposes should be reframed accordingly. Times have changed; so should measurement.