You've seen it -- workshop attendance has been shrinking, as has class length. The likelihood that the participants that showed up at the start will be there when the evaluations are passed out is slim to none. This year, if you're a training manager, you had to cancel an increasing number of classes that are on your schedule.

There has been substantial but patchy take-up of software process improvement (SPI) throughout the last decade.

In early 1999 there was quite a bit of discussion about a new technology called the Simple Object Access Protocol (SOAP). SOAP was developed by a group of people closely associated with Microsoft, and it quickly received Microsoft's blessing. SOAP is not an official part of Microsoft's Distributed Network Architecture (DNA 2000), COM+, or Windows 2000.

After presenting a seminar on software inspections at a client site recently, I asked the development manager about his plans for implementing these practices in his group. He confessed a reluctance to set ambitious expectations for his team.

Electronic business is often innovative, involving significant change in conventional business models that have been slowly established over the last few decades. Such organizations are lean, often cutting out middlemen and selling direct to the end customer, running new paradigms, or adapting old ones to another medium.

Three weeks ago, in the Architecture/e-Business E-Mail Advisor, I considered some of the issues involved in outsourcing IT services. I suggested that a company would probably want to use packaged applications or outsource everything that wasn't strategic to the company as it shifted to e-commerce and the Internet.

Several years ago, while a software development lead, I was introduced to the concept of automated software testing. Just point, click, and record the test cases, the vendor promised. Their tool would, we were told, quickly accumulate a huge collection of automated test cases that would dutifully execute unattended.

When deploying systems with a large business process change component, one of the most critical steps is to implement a process to measure change. It's all well and good to design a knowledge management system, train the users, and use change management techniques to decrease resistance to change. But, in the end, how do you know whether or not you solved the business problem you were attempting to solve?

Last week's Advisor focused on the fact that the US Department of Justice has asked, as part of its settlement of the Microsoft case, that Microsoft middleware products be grouped with the applications company and not with the operating systems company. I said that it would be a good thing, since it would level the playing field between COM+ and Enterprise JavaBeans.

In 1853, Commodore Matthew Perry sailed into Tokyo Harbor with his gun ships. What Perry did (once euphemistically called "the opening of Japan") was controversial both then and now. But Perry did not go to Japan out of the goodness of his (or America's) heart; rather, he and his ships were there on behalf of old-fashioned, bare-knuckle, imperialistic capitalism.

I recently attended an excellent software development conference focusing on a variety of "leading trend" methods. Many of the topics were ones like risk management or knowledge management -- which no one opposed, but on which many companies have not made much progress. Why not?

Ed Roman, CEO of The Middleware Company, (edro@middleware-company.com) and the author of one of the best EJB books, took the trouble to read the government's petition to have Microsoft broken into two separate companies and pointed out something that you probably haven't yet seen in the popular press.

Editor's note: A recent posting on the Cutter Forum by Borys Stokalski contains some interesting predictions we thought would be of interest to Cutter IT Journal subscribers.