Just when you thought all the innovative sourcing ideas had been exhausted, an entrepreneur figures out a new way to offer potential value to an arable market while raising his nation's total international trade in services. Success here will remind us of important sourcing truths.

Since the term "Web 2.0" started appearing, the key questions that seem to keep coming back are: What does it mean? What is the relevance to the enterprise? Should we fear it?

As I recently helped update my company's knowledge management strategy (our business vitally depends on the effective transfer of knowledge from experts to novices, but then, what business doesn't?), I realized that leveraging Web 2.0 in the enterprise meant relinquishing traditional control mechanisms over the editing and publishing of corporate knowledge.

BI proponents -- including vendors, analysts, and consultants (myself included) -- have pushed the idea of ubiquitous BI, or "BI for the masses," for years. To date, however, most companies have found the widespread dissemination of BI practices to their more rank-and-file workers an elusive goal.

Companies are starting to direct their attention at how they can better facilitate collaboration among their BI users using so-called Web 2.0 technologies such as instant messaging (IM), wikis, and blogs.

Here are 10 rules I'd like to propose we all follow, starting immediately:

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.

The responsibility for establishing and maintaining information security today looks like a Scrabble board. COSO, COBIT, ITIL, ISO, and ASIS1 (apologies if I missed any other tiles) are either standards bodies that evangelize practices or acronyms for the management practices themselves -- all designed to help organizations optimize today's information security strategy and contend with tomorrow's threats. Whatever approach an organization adopts, there is one other standard worth considering first.

"Whatever Web 2.0 is, IT executives and technologists need to pay attention to it, and so do the business-unit managers who look for ways to use IT strategically to improve their revenues and shareholder value."

-- Ed Yourdon, Guest Editor, Cutter IT Journal

The business/IT divide is alive and well. We often cast blame on IT for not "talking to the business in a way they can understand," but it's a two-way street and there is plenty of responsibility to be shared for the situation. Business blames IT for a host of sins. Recently, I heard: "They can't do what we ask ... everything takes too long ...

Ah, the word "politics" sounds ugly. Yet IT managers always talk about the negative role of politics in making IT investment and prioritization decisions. It would seem that "politics" is something to be avoided, that somehow a more rational decision-making approach could avoid politics.

In helping the founder get a local technology professional organization to take flight, I began to think about some broad themes around the business value of IT that would seed discussions in future meetings among the like-minded folk who populate this informal group. Thinking about business value topics made me realize how useful this exercise is in establishing better alignment between IT and business units.

In the next few Advisors, I'll address some complex rights your organization will want to consider in outsourcing contracts, as well as the obligations you may wish to require of a service provider. Each of these entails having a separate schedule in your outsourcing contract in addition to clauses within the contract.

In this series of Advisors, we're examining the use of schedules as an approach to contract design that enables you to modularly construct contracts; you only use the schedules you need in any given circumstance. This approach also allows for third parties that may need to sign the schedules to have only the information they require.

The title of this article sounds like an oxymoron, doesn't it? But it is becoming a reality in some countries in the EU: research, development, and innovation (RDI) standards defined for innovation management systems and innovation projects {1}. The question is: will an RDI certification stimulate and support organizations in achieving systematic and sustained innovation? Or will the routines that they promote be another obstacle to innovation if bureaucratic and "audit-type" controls are introduced?

It is amazing to think that the QWERTY keyboard layout invented by Christopher Latham Sholes to minimize jamming of manual typewriter keys is now almost 140 years old. It is almost as amazing to realize that the familiar mouse-and-windows GUI is nearly 25 years old and that the Mosaic-inspired Web browser interface is roughly 15 years old.

In January, I said that I believed that grid computing represents the future of enterprise computing (see "What About Grid Computing?" 9 January 2007).

Summer time is when my mind seems to require that I take some time off from thinking about close-in problems and take a really long view. You have to understand that being a realistic futurist is hard work.

During several recent interviews with candidates applying for a project manager position in our company, I ran across a gross misconception about agile software development processes that, in my opinion, requires some explanation.

The requirement for really good security -- where that exists, which is by no means everywhere -- hones right in on the Achilles' heel of governance. After all, what is governance? A set of rules, policies, or principles designed to steer employees in the desired direction: toward right behavior and away from wrong behavior.

For 40 years, businesses have asked, "How can we get more from our investment in technology?" Scholars, gurus, experts, and consultants have responded with some form of "You should first create an architecture." A few pioneers who pursued this advice realized the benefits; most did not.

I know that none of you really want to be here, so I'll try to keep this as short as possible. We shouldn't be more than two ... two-and-a-half hours ... getting through this risk stuff, and if we all just push through, it shouldn't be too painful.

BI proponents -- including vendors, analysts, and consultants (myself included) -- have pushed the idea of ubiquitous BI, or "BI for the masses," for years. To date, however, most companies have found the widespread dissemination of BI practices to their more rank-and-file workers an elusive goal.

On 24 April, I attended a meeting in Washington, DC, USA, titled "Engineering Solutions for Specialty Crop Challenges." The meeting had over 100 attendees, mostly from industry. As part of the agenda for the first day, I gave an overview of my work in modeling agricultural risk.

Last month I reviewed opportunities for IT to partner with the business, with suppliers, and with other organizations, and I described the first of my three keys for partnering: Exchange (see "Three Keys to Sustainable Partnering Across Any Boundary," 31 May 2007).

Last week, the company RC2 Corporation of Oak Brook, Illinois, USA, issued a recall notice and notified the US Consumer Products Safety Commission (CPSC) that it was recalling 1.5 million of its Thomas the Tank Engine wooden railroad toy trains and some of its accessories because the Chinese factory that produced them used lead paint.