One of the problems with the IT field is that, absent something like the model year for cars popularized by Alfred Sloan in the 1920s, IT companies have to keep coming up with new terms for old ideas. Recently, I've found myself in meetings with consultants and IT managers in which the term "metadata" has been used to allow a group of clueless participants seem with it.

In Part II of this series (see "Centers of Leadership: The Marriage of COEs and Servant-Leadership as an Effective Way to Lead IT, Part II," 3 September 2008), I talked about the need for IT servant-leaders to "get small" in their approach to building community and wielding authority. In this segment, I'll touch on a somewhat-related approach: getting lean.

Last week, Oracle announced two new products targeted at high-performance data warehousing applications: the HP Oracle Database Machine and the Oracle Exadata Storage Server. These products package hardware from HP with database accelerator software from Oracle to form what is essentially a high-performance data warehousing appliance.

The best way to minimize risk is to nip conflict in the bud and to turn it to an organization's advantage.

One of the prime drivers for many organizations moving to agile development is to improve schedule performance. Unfortunately, many facets to schedule performance are often overlooked. Often when I ask, "In what way is your schedule performance lacking today," the answers are very fuzzy. Many managers just have some vague notion that they would like better performance.

How far can you go before you cross the line between ethical behavior and high-risk behavior? It's a question I've been asking quite a few project managers of late, and I find their responses compelling. The question is a seemingly simple one:

If there is to be a true discipline of software engineering, then those of us "doing software engineering" should look closely at how those people in other disciplines who call themselves "engineers" or "architects" actually go about "doing engineering"

Software-as-a-Service (SaaS) is more than simply an application-hosting model. It is an integrated service that involves implementation, hosting, and ongoing maintenance services. In addition, the technical architecture of the SaaS model constrains clients' options for customizing the application at the core level of the application (e.g., changes in data schema). Customers also have less control over the changes that are made to the application by the vendor throughout its lifecycle.

The IT shop aside, most firms find it difficult to truly become customercentric. Many firms have paid dearly for all kinds of studies on their customers, including research under the banner of voice-of-customer (VOC), customer experience, customer-relationship management (CRM) strategy, customer loyalty and retention, and good old-fashioned market research.

Many end-user organizations have multiple enterprise content management (ECM) products in use due to specific application requirements and as the result of mergers and acquisitions. To date, however, integrating these different platforms has often required custom coding or use of specific adapters.

For years, employees who have used Internet search engines such as Google and Yahoo! to find information on the Web frequently ask why searching for and accessing the information they really need to perform their jobs at their own organizations is so difficult.

Data warehouse vendor Infobright Inc. has introduced an open source version of its Infobright enterprise data warehouse product. Infobright Community Edition (ICE), as the new open source offering is called, is similar to the company's main commercial data warehousing package: Infobright Data Warehouse Enterprise Edition.

With an almost evangelical fervor surrounding it, the steady flow of rhetoric concerning alignment of IT with the business side of the organization assumes that if the IT organization pushes for it, business units will enthusiastically embrace it. Often, this is not true, and IT managers must prepare for those occasions when the technology organization is truly ready to transform how it interacts with business units when everyone else isn't.

In this Advisor, I'll offer a few suggestions to firms contemplating how open inflows and outflows might fit into their own innovation strategies.

Recently, the CIO of a non-IT company approached me to help him transform his organization to agile. "We have this tool that provides a real competitive advantage to our domain experts and our clients, but now success haunts us.

Recently, I had a conversation with a senior VP of software engineering who said that certain "macroeconomic trends" were going to influence the direction of his software development strategy. Reading between the lines: the CFO was going to cut budgets in the face of the current economic downturn.

We have covered a lot of material since the first Advisor in this series was published. Now it's time for a review.

In the first part of this series (see "Collaboration: What Does It Mean? Part I," 3 September 2008), we discussed the opportunities provided by new technologies in creating business value with collaboration.

Service-oriented architecture (SOA) looks and sounds very technical. The word "architecture" certainly makes it sound technical, and the fact that it is "service-oriented" makes it sound even more mysterious. So, it is no wonder that SOA is viewed as an IT-driven initiative.

Last week, I discussed how I saw Web 2.0 and search affecting BI (see "Web 2.0, Search, and the Future of Business Intelligence," 9 September 2008). Basically, I said that one of the most important technologies that will have a major influence on BI is search; specifically, the blending of BI and enterprise search technologies.

It is the norm today for the IT shop to be, or have the potential to be, a boundary-spanning function. Organizational theory has long recognized that within the firm there are areas whose focus is mostly internal (e.g., manufacturing and operations) and others whose role is to connect the organization to its outside environment, exchanging information and resources (e.g., R&D, marketing).

The subtitle of Extreme Programming Explained, Kent Beck's groundbreaking book, is "Embrace Change." The full range of behaviors that this seemingly simple phrase can be affect are in fact very far-reaching.

Alice laughed. 'There's no use trying,' she said. 'One CAN'T believe impossible things.'

'I daresay you haven't had much practice,' said the Queen. 'When I was your age, I always did it for half-an-hour a day. Why, sometimes I've believed as many as six impossible things before breakfast.'

In the current edition of Communications of the Association of Computing Machinery (CACM), there is an extremely important article for everyone involved in mission-critical software. The article is titled "Software Engineering and Formal Methods" and is written by a number of illustrious software scientists.

Compared to home-location development teams that may be colocated with domain experts and business champions, software developers at the (offshore) work location are not likely to be familiar with your business. They are learning the details of the business as they code up the application. Even with well-written requirements documentation, don't assume that the team will understand what should be built. Furthermore, intricate business rules and relationships among data elements can be particularly hard to convey.