"If you want higher quality, build less stuff." That, in essence, is what Cutter Business Technology Council Fellow Tom DeMarco once said about a daring strategy for quality improvement: reduce quantity. Tom went on to say, "Whatever it is that your organization makes, make less of it. Make less, and choose much more carefully what you make" [1].

The good news is, Tom's advice is something that can be done immediately to reduce defects. Talk about being agile! Quality is inversely proportional to quantity -- simple as that.

As any software customer knows, it is extraordinarily important to spell out all of its rights in the license or development contract. The customer's ability to withhold payment, take possession of source code, or even terminate the contract, among other important terms, are usually spelled out in black and white.

One of the reasons that it is so hard to find enterprise data architects (EDAs) these days is that most of the training on database (or data warehouse design) is focused far too much on technique and far too little on basic concepts. And since most EDAs are taken from the ranks of DBAs, database models, or data warehousing experts, that means that the folks with experience haven't learned the basics.

In a recent Enterprise Architecture E-Mail Advisor ("EA Maturity Models," 15 March 2006), I introduced a variety of different models that are being used to evaluate enterprise architecture programs. Just like many EA programs that unfortunately go down the "EA for EA sake" path, we often take a "maturity for maturity sake" approach, forgetting that the maturity model is there for a purpose.

I'm hearing increasing talk (again) about how organizations need to extend BI capabilities to their rank-and-file employees. To date, however, most companies have found this "BI for the masses" movement difficult to carry out. True, the growing popularity of digital dashboards and scorecards have helped extend -- in somewhat limited fashion -- BI capabilities across the enterprise.

Just when I was beginning to think that the market's view of Google is far too optimistic, the company does something really smart: this time Google bought a company called @Last Software, which makes a product called SketchUp. This is quite a coincidence, since for the past five or six months, I've been telling all my friends that they really need to look at SketchUp because it is one of the slickest products I've seen for a long, long time with one of the most inventive user interfaces I've ever seen.

This Advisor is the fourth in a series on agile integration and the first on process (see Agile Integration -- Assembling a Team, 13 April 2006, Agile Integration -- Making Agile Work in Organizations, 2 March 2006, and Agile Integration -- Organization and Empowered Teams, 6 April 2006).

Many organizations have a policy for fixed assets; however, this policy is driven usually from an accounting perspective, not from the perspective of the operational risks associated with these assets. Controlling the organization's IT assets requires an operational framework that complements the accounting-based, fixed-asset policy.

A Google search of the phrase "achieve an ROI of" returns a sea of URLS from IT vendors promising that an investment in their product means a return on investment. As organizations grew more conscious of the need to fold the language of finance and profit into IT investment assessment, it was predictable that vendors would adopt the language of economic value into their sales and marketing efforts. Are these claims more than rhetoric?

There have been a lot of "studies" on job migration and outsourcing over the past five years that try to position outsourcing as something political: outsourcing creates jobs; outsourcing is the inevitable consequence of globalization; outsourcing will destroy the US labor force. But what's really going on? How do we avoid the spin that proponents and critics of outsourcing present every time the topic comes up?

I've seen a lot of press lately about the relationship between business process management (BPM) and service-oriented architecture (SOA). Products are now claiming to support the "convergence of BPM and SOA technologies." There have been major announcements this year of BPM products being acquired by SOA vendors, such as the purchase of Collaxa by Oracle and the recent purchase of Fuego by BEA. There have also been announcements of new product sets following previous acquisitions.

Over the years, I've had the pleasure of working in a range of IT organizations around the world, and I've often worked with, or at least reviewed, many of the enterprise architecture (EA) teams within those organizations. In all cases, the EA team is staffed with some of the best and brightest within IT, all of whom have the organization's best interests at heart.

The latest announcement by open source reporting tools vendor JasperSoft that it has a new business intelligence (BI) server designed to make it easier for corporate and commercial software developers to build reporting environments got me thinking the other day about the extent to which organizations are actually embracing open source BI tools.

The management of knowledge is not new. Knowledge has been managed in organizations from time immemorial to ascertain that appropriate capabilities are available for people to perform requisite work competently and successfully. As a result, implicit knowledge management (KM) mechanisms were pursued by introducing practices such as master-apprentice traditions, educational programs, and so on.

Former Intel Chairman Andy Grove nicely described the link between strategic and operational risk, and the importance of managing the former by the latter, when he said, "People [employees] formulate strategy with their fingertips. Day in and day out they respond to things by virtue of the products they produce, the price concessions they make, the distribution channels they choose."

Typical database development involves building the data structures, writing some code to access the database, running the code, then writing some queries to verify that the data got into the database. Even the most rigorous database testers generally verify a database by running several queries and visually inspecting the results for validity. The problem with this approach is that as changes are made to the database, we don't generally rerun all the old test queries to revalidate that everything is still fine.

Vendor readiness for a security and privacy regime which meets the offshoring company's needs is a key vendor selection criteria as well as an operational imperative at the time the relationship with an offshore service provider is forged. As part of a comprehensive due diligence process on the cusp of signing a services contract, many organizations require a vendor to submit a security self-assessment.

I was talking recently with a reader who is in the process of selecting a business rules management (BRM) tool for a project at her company. She has checked out various products on the market, and is still unsure as to which one to choose. In particular, she is agonizing over the various user interface paradigms that the different products utilize.

One of our clients regularly provides every business unit management team with a comprehensive portfolio management report and dashboard covering the entire IT spend, every month. This report and dashboard covers several global business units and many subsidiary units. The report and dashboard highlight important areas of concern: IT spend not aligned with strategy, IT spend that performed badly (e.g., service-level and quality), IT spend with significant business and technical risk.

The press regularly echoes the never-ending frustration of business and project managers with large overruns, huge delays, and low-quality delivery of software projects. Software estimation remains a vexing conundrum. If a civil engineer can produce reliable estimates for a new bridge, why can't software engineers produce reliable estimates for software projects?

Every so often, you may come across an article that says something to the effect that "CRM isn't a product or technology but rather an attitude or mind set." Well, I've been thinking a lot about this concept lately and have come to the conclusion that done correctly, CRM is indeed both a particular mindset and a technology. Here's an example that I hope demonstrates why it is both.

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'?"

Recently, my colleagues on the Cutter Business Technology Council got into a very heated exchange on the state-of-the-art in software development. A couple of members of the Council were particularly disturbed by the level of knowledge in fundamental principles that some of their recent computer science graduates were exhibiting.