Everyone wants to get a slice of the social networking market. Social networks provide opportunities for large IT enterprises, innovative startups, third-party developers, IT professionals, and venture capitalists. IT businesses now have many new social network-inspired opportunities, some of which are yet to be explored, along different avenues, as follows:

I've run across a writer who has wonderfully smart things to say about art and biology that I think offer a lot of food for thought about innovation.

A client asks about methods to increase the trust between IT and business managers and staff. It seems the relationship is currently broken: business managers don't trust IT, and the feeling is mutual.

About a year ago, I was consulting with a client around the organization's SOA offering and its relationship to enterprise architecture. The client, a software provider, had its chief architect in the meeting, and the architect was trying to convince me of the value of the company's solution.

Collaboration is overrated. Nevertheless, collaboration is the cornerstone of Enterprise 2.0. It is considered a truism that collaboration is good, that teams work better than individuals do, and that the brave new world of Enterprise 2.0 is a brave new world of democracy in the workplace, of institutionalized collaborative decision-making.

The idea that collaboration is the answer to every problem may come as some surprise to anyone who has ever served on a committee.

The most popular Web 2.0 technologies used by organizations to support their business performance management initiatives are wikis and social networks. This finding comes from a January 2008 Cutter Consortium survey of 101 end-user organizations worldwide, which was designed to measure the extent that organizations are implementing business performance management technologies and techniques.

American businessman Warren Buffet once said that "it takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently."

In my last Advisor (see "How to Increase Productive Velocity, Part I," 17 April 2008), I had collected strategies for managers and domain experts to make their agile team run faster. This second article in the series is devoted to measures suitable for the development team.

Discussions surrounding risk management for the last decade have taken on the duality of risk, expressed as threat or opportunity.

With high gasoline prices, an increasing number of organizations are revisiting their travel policies and about employees working from home. The pressures of high fuel costs, increasing travel time, and higher travel costs all argue for more remote (technology-mediated) meetings. The current buzzword for this is "telepresence," but "teleconferencing" is just as appropriate.

What the business intelligence (BI) architecture will look like in the future depends on the business drivers for BI as well as the direction the technology is going to take. Data within an organization are increasing exponentially, and the demand for real-time analytics is greater than ever. The process of standardizing and integrating enterprise data in a single data warehouse (DW) is an ever-increasing challenge given the high data growth and rapidly evolving business processes in organizations.

In my last Advisor (see "Making Planning Predictability One of Your Principles," 14 May 2008), I spoke about the importance of predictability of plans, especially as implementation proceeds.

I've been thinking about the software-plus-service model, where a vendor offers online (hosted) software components that integrate with the vendor's software installed onsite at the end-user organization (i.e., the customer). Microsoft is pushing this approach in response to on-demand offerings from Google and other providers.

The following is what you hear from almost every IT organization when you conduct an IT assessment:

Vertica Systems is offering an on-demand version of its high-performance, columnar analytic database hosted on Amazon's Elastic Compute Cloud (EC2) platform.

Technologists love technology and assume that others share this affinity. Unfortunately, most nontechnology executives and managers feel quite differently about technology. Most of them see it as a means to an end, and we all know what the end looks like. Therefore, we also know that there are key messages in which we should frame our discussions about the business value of technology.

We know that people are our most valuable resource, but we seem to forget this too easily. Recently, I was with an executive team of a high-technology company, and the team was struggling with a string of late-to-market development projects. Finally, the CEO got up and proposed yet another rewiring of the organization chart. I have seen this scenario repeated too many times.

Humans, like other primates, are fundamentally social animals. We congregate at rock concerts, football stadiums, and jazz clubs and through churches, golf clubs, and alumni associations. We've converted broadcast media into meeting places, with reality TV and hosted call-in talk shows.

When I complete a new business plan or project plan, the only thing that I can guarantee anyone is that the plan is wrong. How can that be? Well, from the start of a business initiative until the end, business conditions change.

The question of where logic belongs in an application has been a topic of debate for years and has changed as technology, requirements, and our understanding has evolved over time. The change from client-server computing (two-tier) to the three-tier model represented a movement of logic out of the presentation and into a separate, middle tier.

Consulting occurs in a context of sanity and insanity. We refer to this as "corporate culture," "political context," "the ranch," or some other metaphor that communicates instability and dysfunctionality. Murphy would remind us here that all organizations are pathological: it's just a question of degree.

When most people think of applications involving business rules management systems (BRMS), they tend to think of rules used as a means to represent and simplify complex business logic, with rules expressed as IF-THEN statements using English-like syntax (e.g., IF CUSTOMER_INCOME = $75,000 - $100,000 AND CUSTOMER_HOMEOWNER_CODE = 3 THEN CUSTOMER_LIFETIMEVALUE = 9).

The things you have to be careful about in architecture are those everybody knows but are not true. I was working recently with a friend trying to sketch out a migration plan for an organization whose IT systems were not too great.

Agile development has always included the practice of timeboxing -- setting a fixed time limit to overall development efforts and letting other characteristics, such as scope, vary. However, timeboxing can also be used in another interesting way: timeboxing capabilities and stories rather than projects or iterations.