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.

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."

Thirty years ago, businesses were organized functionally. The organization chart became the way to describe how the business works. In the mid-1980s, scholars like Michael Porter and consultants like Deming and Hammer led the way to refocus work on process and quality control. Making sure you had a robust process was the key to efficiency, productivity, and quality.

It is critical to have an individual accountable for the success of each contract. This person often carries the title of contract manager, but other terms such as contract officer, contract superintendent, and contract supervisor are also common. The contract manager (or equivalent) is the hub of the contract management network for the contracts under his or her control.

In my last Advisor (see "EAD: The Architecture of the Customer Experience, Part 4," 2 April 2008), I discussed the interviewing approach we use to break down and cluster into a set of experiences the many interactions customers have with companies.

Recently, cloud computing and the rush to solve the problem of writing programs to exploit parallel computers have begun to push software-oriented architecture (SOA) out of the technical headlines.

Despite the immense impact that the user interface (UI) design has on how IT applications are used, perceived, and judged, the discipline of UI design remains a stepchild within the software development process as practiced by most large companies. Typically, UI design is shoehorned between the requirements and design phases. Under great time pressure, a UI designer creates screen mock-ups and perhaps an interface specification that are meant to drive application design and coding.

More than half of end-user organizations undertaking business performance management initiatives are required to make changes to existing business processes in order to support implementing their performance management solutions. This finding comes from a Cutter Consortium survey conducted in January 2008 of 101 end-user organizations (based worldwide).

My objective in this article is to look at the discussion of BI with or without DW from a business rather than a technical or operational perspective.

Imagine, for a moment, that you have an integrated team that is to build some software product. This team includes all the necessary stakeholders to define, assess, and refine the product; it contains the people who understand the need and have all the required skill sets and tools to accomplish the task. Call this the A Team. The A Team might be creative and highly innovative. Or not. What makes the difference? Whether the team uses an agile or a waterfall process? Whether the team uses Java or C#? No.