There are individuals afraid to begin the risk conversation in any organization. Why? I hear it from our client personnel time and again. "We're risk averse around here. Management doesn't want to admit there are risks. They tell me to come with solutions, not problems, and then they tell me that I should have warned them about the risks." These are not uncommon complaints and concerns. What's tragic about them is that they stifle the risk conversation in an organization.

This is the third in a series of E-Mail Advisors on agile integration and the second to deal with organizing (see "Agile Integration -- Making Agile Work in Organizations," 2 March 2006, and "Agile Integration -- Organization and Empowered Teams," 6 April 2006). The six organizing guidelines presented previously are:

Historically, managers in large private and public enterprises like to consider (and portray) themselves as hard-headed businesspeople -- no frills, straight to the point. For most of the history of IT, this line of thinking has dominated. However, the Web changed that. Success on the Web has caused many organizations to rethink how they use technology, especially how they can reach people who are not technology-oriented. The emergence of the creative class has given one more reason that organizations need to look at their information systems.

A successful business intelligence (BI) outsourcing strategy requires a clear understanding of the value proposition. A benefits analysis to assess the gains of outsourcing should include the value of coming "online" more quickly with a new BI application; the cost saved by not having to build and maintain inhouse BI expertise; and the value inherent in the vendors' experience and ability to avoid perils and pitfalls.

Information architectures are increasingly misaligned with business architectures while becoming less adaptive to new products, services, markets, and customer requirements. A steady drumbeat of failed projects, some that are publicized and some that are not, has executives rethinking failed policies of the past. Wholesale replacement projects and package deployment initiatives have poor track records while integration tools have created a maze of redundancies wrapped around already convoluted architectures.

In my previous Advisor (see "The Mythical Business Case -- Part 1: The Limits of Rational Decisions," 8 March 2006), I presented the not-so-uncommon phenomenon of tweaking formal business case analysis to fit (rather than prove) the IT investment decisions that have already been made.

Reputation is a major corporate asset that is often valued much more than the tangible assets of the corporation itself. Buying a corporation's reputation is as important a consideration as buying its assets. When Phillip Morris bought Kraft Foods for US $13.1 billion, it wanted Kraft's reputation and was willing to pay four times Kraft's physical assets to get it.

Last week, Microsoft acquired BI analysis and visualization vendor ProClarity Corporation. Financial terms were not revealed. However, this deal is important because it significantly bolsters Microsoft's already considerable BI technology stack with an intuitive and comprehensive analytic, visualization, and reporting platform already tailor-made for the Microsoft product line.

One critical issue that arises in the move to agile methods is organization. Since some of these issues differ between product organizations (such as software ISVs) and IT organizations, I will discuss some general guidelines and then how they apply to each type of organization. This first Advisor on agile organizations will focus on the first guideline (of the six outlined below) of empowered customer-facing teams.

"The man who trades freedom for security does not deserve nor will he ever receive either." This quote from Ben Franklin came to mind as I sat bemused while trying to outwardly show some sympathy to my government colleague as he attempted to log on to his agency's network. Some 30-plus minutes later, he was able to log in. Next came the process of asking the network for permission to start checking for his e-mail. This is always an adventure as well, since this activity might take another 30 minutes to complete.

My last three Trends Advisors in this series (see "Real Enterprise Data Architecture, Parts 1, 2, and 3," 23 February, 9 March, and 30 March 2006) have been about enterprise data architecture.

What is "architecture?" We know what conventional architecture is in the context of the structure of buildings. So, the question is, what is systems architecture in the systems engineering context?

There are many different opinions and many standard definitions.

All around the world, corporations are turning to open source software (OSS) for a number of compelling reasons. In Europe, for instance, financial services companies have been moving to Linux because of its superior price/performance, hardware-neutrality, reliability, and vendor independence. Companies like AtosEuronext, Banco Popolare di Milano, LVM Insurance, and Reuters Group have migrated important server-side operations to Linux with remarkably successful results.

This third and final Advisor in a series of articles on post-project evaluations focuses on the second of the two main components of post-project evaluations: assessing the business impact of an IT investment (see "Post-Project Evaluations, Part 1: Overview," 22 February 2006 and "Post-Project Evaluations, Part 2: Assessing Project Performance," 15 March 2006).

Technology and business conditions are creating an environment that favors rapid response, collaboration, and loosely knit modular organization. This trend can be seen at all levels, from the supply of individual contract labor up to "constellations" of enterprises brought together for a common purpose.

Sadly, I believe that the data management (DM) community has fallen down when it comes to ensuring data quality within the vast majority of organizations. Yes, these people talk the talk, but they don't seem to walk it. They claim that data quality is important, and they're right about that. They also claim that they should be responsible for ensuring data quality, which also seems fair. But, as we can see by the myriad data challenges faced within most organizations, their vision begins to fail.

[This week I address two issues. In the first part, I consider what makes up customer relationship management (CRM). Second, I offer a correction to last week's article that covered the new Oracle BI Suite offerings.]

My last two Trends Advisors in this series (see "Real Enterprise Data Architecture, Parts 1 and 2," 23 February and 9 March 2006) have focused on what I refer to as real enterprise data architecture, which in enterprise architecture terms is equivalent to distinguishing the forests from the trees in the enterprise data space.

Increasingly, governance risk is becoming the "fifth risk" that corporations must include in their enterprise risk management (ERM) portfolio that already includes strategic, operational, financial, and insurable risks. The move to couple risk management and governance can be seen clearly in the COSO Enterprise Risk Management -- Integrated Framework [1].

Shortly after reading Agile Project Management Practice Director Jim Highsmith's recent Advisor about whether iterations must be short to be agile ("Agile Isn't Short Iterations," 23 February 2006), I watched a video with my family called "The Wright Stuff" about the Wright brothers' clearly agile project leadership in development of the flying machine (www.pbs.org/wgbh/nova/wright/).

By now you have most likely heard of or been exposed to the lo-tech agile practice of using 3x5 cards to capture user stories, plan development, and track an agile project. Needless to say, this technique has terrified more than a few development managers and leaders and in many cases the strengths associated with agile development have been thrown out along with the "crazy" idea of using index cards for requirements.

It is sometimes very useful to go out to a customer's office and sit in a cubicle right in the heart of the action. You get a very real perspective on the dynamics of the organization. It is a feeling unlike those you are spoon-fed in meetings. You learn the real problems, and the real problem solvers. I recently undertook an assignment and wound up at a very nice desk, right outside the room with the coffee pot. Fascinating.

Managing core competencies is much more difficult than simply outsourcing those areas that have proved troublesome to manage. Managing core competencies involves taking a very long view of an enterprise's strategic interests, especially its key knowledge areas. Nowhere is that more in play than in the area of IT.

In my last 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.

In our last Advisor, we began a discussion of the benefits of employing properly crafted dashboards to provide transparency into every aspect of IT's business (see "Dashboards Are Critical for IT Management -- A Lot of Dashboards, Part 1," 22 March 2006). "Manage IT like a business" is a recent mantra. Dashboards provide the means.