There has been a love-hate relationship between IT and performance measurement ever since IT emerged from the freight elevator, stumbled into the express elevator, emerged on the executive floor, and became a reluctant member of the business's management team. Accountability became the word of the day, along with budgets, controls, standards, and, eventually, key performance indicators (KPIs) and performance reporting.

Practically no area of corporate computing remains untouched by the open source Linux movement. Consequently, a big question on a lot of data warehousing and BI practitioners' minds has been: to what extent are companies actually adopting open source Linux for their data warehousing platforms?

A recent survey we conducted in April 2006 that asked 106 end-user organizations (of various sizes based worldwide) about their plans to use open source BI and data warehousing tools helps provide some insight on this issue.

In recent years, a number of seminal books have helped to define the software security field [1, 2, 5]. The approach to "building security in" introduced in these books has been enhanced and expanded by practitioners and published in various technical articles, including the "Building Security In" series in IEEE Security & Privacy.

Everyone has been complaining about Sarbanes-Oxley and other government-induced compliance formulae for several years now (everybody, of course, except the auditors and the consultants who make their money on compliance and related activities). Technology has become part of the compliance process in some very important ways. Let's talk about the role that IT governance plays in compliance and the frameworks out there to help us all stay legal.

For one of my manufacturing clients, "lean" is in. This client analyzes ergonomics, steps taken, rework, and refit to an excruciating level of detail. In watching this, it has saved hundreds of resource hours on the shop floor and has rendered its organization more responsive and worker-friendly. Its environment makes more sense today from a work perspective than it did just six months earlier.

Ten to fifteen years ago, a lot was being written about the concept of coopetition. This was just at the beginning of the huge growth in technology -- capabilities, products, companies, and, of course, stock value. Well, things have cooled off a bit since then; however, the concept is just as relevant today, if not more so. We just don't hear much about it because most companies have learned how to better manage their relationships with vendor partners.

Experimentation is essential to the growth of all organizations. It fuels the discovery and creation of knowledge and leads to the development and improvement of products, processes, and business models. Without experimentation, we might still use rocks as tools and live in caves. With breakthrough technologies, it is now possible to perform a greater number of experiments in an economically viable way to accelerate the drive toward innovation.

You may know the authors from their Web site, zapthink, which provides analysis on XML, Web services, and service orientation, and which is where I first became aware of the book Service Orient or Be Doomed, by Jason Bloomberg and Ron Schmeltzer.

I was intrigued by the book's catchy title and thought I should give it a look.

A good friend of mine, who was quite active in the AI community in the late 1980s and early 1990s, asked me an interesting question the other day: "When did rule-based systems go from being 'expert systems' to 'business rules management systems'?"

Microsoft's announcement that it is developing a new, comprehensive business performance management application called Office PerformancePoint Server 2007 was received like a 500-pound firecracker detonating at a fireworks show. Everyone has been expecting something from Microsoft in the way of a major BI announcement, because of the way it has been aggressively assembling all the necessary pieces for a more comprehensive BI product strategy (either through product development or acquisitions) over the past few years.

A couple of weeks ago, I wrote a Trends Advisor entitled, "Why You Might Not Want to Sell Your Google Stock Just Yet" (4 May). In that column, I pointed out that Google had made an acquisition of one of the more interesting 3D tools that I'd seen in recent years: SketchUp. Because it is so easy to model things, especially buildings, I speculated that Google had pulled off a coup.

Corporate scandals leave a long, bitter aftertaste. While last month's convictions of Enron's Ken Lay and Jeff Skilling may signal the end of the most notorious corporate scandal of recent times, it has not signaled the end of the problems associated with poor corporate governance.

I was recently asked to give a talk to a group of Irish software companies about software process improvement (SPI). As I thought about the topic, I realized that to most people, SPI conveys expectations such as deterministic, comprehensive early planning; a detailed process focus; waterfall (serial) lifecycle (planning, requirements, design, etc.); extensive documentation deliverables to show progress; and internal metrics.

Knowledge transfer represents a critical stage in the transition phase of a business process offshoring (BPO) project. Often, the offshore service provider (OSP) staff, although skilled, might lack specific expertise unique to the specific business processes they will oversee. It is vital that the offshoring organization establish a structured, disciplined knowledge transfer program to ensure that OSP personnel are adequately prepared to assume daily business process management when that day arrives.

Projects sometimes happen to deliver a product that meets every requirement specified but ultimately appears not to address important needs of the stakeholders. Certainly there are many possible causes for that. In this Advisor, I focus on one cause that I believe is not always properly understood -- partly because of the flawed notion of quality of IS systems. The problem I will address is that of requirements quality and responsibility for requirement analysis in the context of IS procurement.

The great rush to decentralize heirarchical decisionmaking in American corporations has been accompanied by a well-intentioned but hopelessly misguided faith in the power of teams to reach optimal decisions. In the realm of IT decisionmaking and governance, teamthink is as often a value killer as creator. Consider the ways this is so, first.

Effective coordination of the innovative minds, both within the company and externally, is necessary to tap the creative juices of the best contributors. This is a difficult problem, since we have created organizational silos that don't necessary welcome external inputs. An innovative culture has to be rebuilt and reconnected for effective communication and collaboration.

Oracle announced last week that it will acquire Demantra Inc., a vendor of demand-driven planning applications that use BI analytics to help manufacturers and retailers predict demand for their products based on seasonality, long- and short-term trends, and promotions and pricing changes. Oracle is expected to finalize the deal later this month; however, financial details were not disclosed.

I bumped into an old friend at the Cutter Summit last month whom I hadn't seen for several years. He told me he was now a member of the nefarious three-time losers club as a CIO. When I asked what had happened, he described a consistent story of joining fast-growing, venture-capital-funded, small- to medium-sized firms, and having a wild ride for a couple of years. Inevitably, entrepreneurs in the firm would give way to professional management, and soon thereafter, so would he (my words, not his).

A friend of mine evocatively condemns many development organizations as "team ghettos." Designing a team ghetto is easy: organize developers into teams and organize management into silos over the teams, then watch the predictable inversion layer form between the two environments so that nothing ever gets across whole and unscathed -- not information, not people, and certainly not trust, honesty, and the truth about operations, competition, customers, progress, and results.

In the business world, one man's risk is another man's opportunity. So, too, risks that are insignificant for one type of business may be of major concern to another. The risks faced by an IT project are in themselves not unique. Any risk that can be postulated for an IT project can be identified in the risk environment of projects in other technical areas. What is different and generically characteristic of IT is its typical project risk profile. By their very nature, IT projects tend to exacerbate certain kinds of risk.

There's a clever saying that goes: "In theory, there's no difference between theory and practice, but in practice there is." This difference was driven home to me on a recent engagement where I spent time with two different groups at the same multinational corporation. In the morning, I discussed SOA with the architecture steering committee (name changed to protect the innocent), where we discussed the issues of SOA and what was needed to realize that potential at the enterprise level.

In the first half of this Advisor ("The Bane of the Automatic Stay in Bankruptcy," 10 May 2006), we took a look at careful contract wording as one way customers can protect their rights in the event that a software development vendor files bankruptcy.