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.

With all the discussions of "levels of abstraction" in the systems modeling literature, there has not been enough discussion of what kind of abstraction those of us involved in enterprise architecture (EA) should be doing.

In the Web 2.0 consumer world, social networks are very hot. In the enterprise, people are still struggling with tracking down expertise and getting it applied to projects. However, there are some new tools in the project manager's arsenal.

We're hearing increasingly about the use of Web 2.0 techniques -- including mashups, social networks, wikis, blogs, maps, and search -- with BI. There have also been several interesting developments recently regarding Web 2.0 and BI.

Customer collaboration is a cornerstone of agile development, but it is also one of the more difficult aspects of implementing agile. Of course, lack of customer involvement isn't unique to agile development -- software developers have had problems in this area ever since software entered organizational life.

Business and art are two -- or some would argue, the -- primary sites where innovation happens in our societies. They are, however, also structurally ordered into a dichotomy that often has business on the "useful" side and art on the "amusement" side.

"Many project managers [PMs] still find the complexity of planning and delivering projects in a constantly changing environment often requires competencies that their formal training has not equipped them with," notes Guest Editor Rob Thomsett, in the May 2008 Cutter IT Journal issue's call for papers.

While often the "Green Revolution" in IT consists of well-intentioned projects to minimize damage to the environment, a darkening trend in the data center could transform fluffy and fuzzy corporate environmental attitudes into a more focused, bottom-line disposition where energy strategy becomes a key component of disciplined IT management.

Last month, we wrote an Advisor titled "Is Our IT Superior to the Competition's? No???" It was triggered by the just-published Cutter Benchmark Review article (see "Linking IT Budgeting, Governance, and Value," Vol. 8, No. 7), in which we report that only 27% of managers of large companies believe their IT is superior to that of their competition.

As enterprise architects, we often face tasks aligning business and IT. One approach to this alignment is characterized by the Parker-Benson Square Wheel. It tells us that there are two sides to this equation. IT aligns technology with the business by responding to changes in business strategy and operations. This is the traditional role of IT.

When I'm away on vacation, one of my favorite activities is to rummage through old record albums at the flea market, looking for some long, lost treasure from my youth. On one such expedition last summer, I ran across Steve Martin's comedy album Let's Get Small. Pleased by my rare find, I gladly paid my 50 cents, brought the record home, and then completely forgot about it until it surfaced as I was looking for another album last week.

There have been a number of developments over the past few months involving open source data integration platforms. One of the most interesting of these is Talend's open source data quality suite. Another is the version 2.0 release of Jitterbit's open source data integration toolset.

When I've been involved with clients trying to establish an EA function, they usually fall into one of two categories: either they basically have no architecture occurring at the enterprise level, or they have a fairly new practice in place with a handful of people having some amount of experience and/or knowledge of architecture.

In most organizations adopting agile methods, the techniques used for program and portfolio management are still predictive and "waterfall": yearly budgeting cycles and capacity planning, and heavily matrixed resource management. It's no surprise then that despite adopting agile methods for their projects, many organizations have yet to exploit their full benefits at the portfolio level.

The odds of that? That's like being struck by lightning.

Is it? Is it really?

The English language is rife with metaphors. We do comparisons and analogies on a ritual basis. However, when the topic arises, I'm reminded of a college mate of mine, Jack Shepherd, who used to challenge similes on a regular basis.

Some years ago, I was working on a data warehousing project for a large bank in the US state of Texas, where one of my roles was reviewing the data model that the users and consultants were coming up with. I was charging a fairly high rate, for that time anyway, and the user manager became a little concerned that he was being billed for my work but hadn't seen me around much.

During a recent Cutter Business Technology Council meeting, we hashed over the "Moat" opinion for nearly two hours. I went into the meeting thinking the matter was a slam dunk: yes, there's a culture clash, and no, management shouldn't hunker down and enforce the old outdated rules. To my surprise, there was almost instantly a lot of heat in the room, with Council members differing markedly on how management should respond. I came away feeling that there were no good choices in this complicated matter, only bad and less bad ones.

While it can be very personally rewarding to learn about other cultures and interact with people from different places, from a project management perspective, these factors must be thought of as risks that should be actively mitigated and monitored. The business impact leads to, as a general rule, increased costs and schedule or product delivery delays.

Traditionally, the main purpose in building a business case for an IT project is to obtain approval for the financial spend. However, in addition to obtaining funding for the investment, the preparation of comprehensive and robust business cases provides organizations with other important advantages.

Last month, I discussed cloud computing -- what it is and key issues that end-user organizations should carefully consider when evaluating its use, including reliability/availability, security, and data integration and integrity (see "Cloud Computing Cranks it Up, But Issues Remain," 23 July 2008).

During a recent Cutter Business Technology Council meeting, we hashed over the "Moat" opinion for nearly two hours. I went into the meeting thinking the matter was a slam dunk: yes, there's a culture clash, and no, management shouldn't hunker down and enforce the old outdated rules. To my surprise, there was almost instantly a lot of heat in the room, with Council members differing markedly on how management should respond. I came away feeling that there were no good choices in this complicated matter, only bad and less bad ones.

The number of data warehousing appliances on the market -- prepackaged hardware/software offerings that combine database, data storage, compute servers, and operating systems preconfigured and pretuned to support data warehousing -- continues to grow. The latest vendor to introduce a data-warehousing appliance is Sybase, Inc.

Beyond all doubt, the trend to outsource functions developed inside an enterprise or a government agency is at its peak. This phenomenon is not limited to IT; it's under consideration in several areas of an organization. Although outsourcing is a very appealing concept, it is essential for a company to be properly prepared for this kind of change.

Before there was the principle of open source to manage innovation, there was the open market to achieve the same innovation and agility objectives. Open source innovation attracts the bulk of the attention today, which is why open market innovation deserves another look. The IT organization should join in because of the role it can play in enabling this approach to innovation.

This is a continuation of previous Advisors on quality, specifically ones on intrinsic quality (see "Investigating Agile: Inside and Out," 19 June 2008 and "Intrinsic Quality?" 3 July 2008).