If you ask the average citizen on the street for a definition of "open source," you'll probably get a blank look. Ask a programmer, though, and you'll not only get a precise definition, but several examples and an emotional argument for why it's good or bad.

In my last Advisor ( 2 August 2000), I talked about the importance of practicing risk management for effective business-IT alignment. I described risk management as a cyclical process, comprised of five main stages: identification, qualitative assessment, quantitative assessment, development of risk responses, and monitoring of implemented responses.

There are five important conferences coming up this fall. Since they are spread out over three different continents, few people will be able to attend all of them. Moreover, they are are specialized in different ways. Still, I thought I'd point them all out, since at least four are annual meetings and will recur next year, elsewhere.

We all have come to understand how important communication is to a project. Balancing the need to keep everyone informed while avoiding management by democracy is a skill that every project manager must master. I recently came across a project that emphasized an important lesson about testing the effectiveness of a communications plan.

When I was a young boy, I remember my father telling me to beware of discussions and debates in which "reaction words" were used to evoke an emotional response that had little or nothing to do with the substance of the conversation. I have no idea why that lesson made such an impact on me, but it's one that we all see during debates about politics and religion.

Among the challenges managers have had to face during the IT "revolution" of recent years, dealing with an increasingly specialized workforce has provoked particular angst. I saw this firsthand when I led a small, elite team of young programmers that supported mission-critical systems in an automaker's assembly plants. These plants are where the rubber hits the road in the auto business (literally).

I'm probably widely considered an enthusiastic supporter of Java and Enterprise JavaBean (EJB) application servers. I think both hold great potential for the development of important enterprise systems.

In today's environment of doing more with less, organizations are finding themselves with staff members that are burning out fast and are unable to deal with the growing work load.

Alert Webster, there's a new word in the English language: Amazoned. The definition: It's what happens to a business that doesn't keep up with the Internet economy.

With the collapse of the dot-com industry, we don't hear much talk these days about the Internet revolutionizing mankind; Nicholas Negroponte's 1995 paean, Being Digital, probably wouldn't sell very well today. Indeed, with the collapse of the high-tech stock market, it's hard to find anyone saying positive things about the benefits of technology.

In a previous Advisor ( 12 July 2000), I discussed how to conduct an identification session that surfaces key impediments to an organizational or divisional objective. Armed with that information, you are ready to begin the second phase of the facilitation.

Time passes quickly. It's hard to imagine that I've been writing Architecture Advisors for three years now. In that time, of course, the world of software development has evolved rapidly, and, as I considered what to write this month, I thought that it might be good to step back and think, very broadly, about the status of software architectures today.

Each year, members of our community present new methods of building and maintaining software. It is our task to be open-minded, learn, and think. We must always look at our people and the product we are building before we decide which process or method to use.

If you are charged with selecting or implementing a customer relationship management (CRM) solution for your organization, it is imperative that you understand the business drivers that propel this application area. The CRM solution space is big and growing.

Software architects at large companies who are focused on the design of enterprise application integration (EAI) systems that can link existing enterprise applications with the latest e-business systems face a horrendous task -- there are so many applications, written in so many different languages, running on such a wide variety of platforms.

Back in the Y2000 days, I got into a little trouble for going against commonly held beliefs. A number of industry pundits claimed that the Y2000 challenge wasn't a technical problem, but simply a project management challenge of considerable magnitude. Classic project management theory says that in the project-constraint triangle, one is bound by work, resources, and time.