The analysis of the enterprise business cycles is an important step in EA efforts. However, to find gaps and future directions for an enterprise IT architecture, we introduce another concept, which we call enterprise architecture capabilities. We use them instead of specific information systems functions to point out the relationship of IT logical architecture to business architecture, described as a set of business cycles and business capabilities.

I came across a saying the other day at one of my favorite Web sites, www.despair.com, that is particularly applicable to IT: "You can do anything you set your mind to when you have vision, determination, and an endless supply of expendable labor."

Someone recently asked me to distill my thoughts on strategy down to the bare minimum. I pondered this request for a few moments and then answered:

Strategy is what we use to do more smart stuff and do less stupid stuff.

A few tenets of faith on risk management:

Risk management is a comprehensive evaluation of what may or may not go right within an organization, and a series of actions related to that evaluation.

Risk management is the challenge of establishing a common vision of when and how an organization should react and respond.

A couple weeks ago, I discussed the significance of SAP AG's acquisition of BI vendor Business Objects SA (see "SAP Buys Business Objects, Or Keeping Up with the Jones II," 16 October 2007). Last week, SAP made another acquisition: YASU Technologies.

I have to begin this piece by admitting that I have tremendous admiration for Steve Jobs. Jobs is probably one of the most creative people in electronic product development today. He has proved this creativity multiple times in multiple incarnations. Not only did Jobs put Apple computing on the map in the 1970s and 1980s, he made windows, mice, and object-oriented design popular.

This is the last of a trilogy of Advisors on tools in agile development.

An IT project orientation to risk blindsides organizations to business risks when achieving strategic goals like revenue generation largely depends upon the successful design, execution, and management of technology. Responsible risk analysis cannot end when the technology project supporting strategic goals is completed. Some technology requires persistent business risk analysis. eBay's recent experience is instructive.

CIOs are responsible for managing many different aspects of IT, ranging from providing IT services, to controlling costs, and aligning IT with the business. One of the most powerful tools that a CIO has to help with this is enterprise architecture (EA). Yet, EA is often misunderstood, misapplied, or simply not present in many IT organizations.

IT work is frequently intense knowledge work that requires years of dedicated study and hard work to master. How well IT organizations can build and keep teams of expert IT workers together can make or break the IT organization and, depending on the context, the entire business. One can draw a short line between business strategy and IT skill development.

Many outsourcing arrangements today describe themselves as following a staff augmentation model, as opposed to a transition of IT staff to a supplier organization, which occurred more frequently in the early years of outsourcing.

I believe that there are some very basic things that systems engineers should learn. In the first installment of this Advisor series (see "Undergraduate Basics for Systems Engineering, Part 1: Principles," 3 October 2007), I discussed the first of these fundamental lessons: principles (heuristics, laws).

The business community concluded at some point that the words "employees," "workforce," and "personnel" were inadequate in describing workers' influence in shaping enterprise success. So a phrase was introduced into the lexicon of business and industry that more appropriately acknowledges the newfound importance of labor: "human capital."

The majority of organizations currently using on-demand BI and data warehousing solutions are generally satisfied with the results.

The increasing focus on analytics-based competition has reinvigorated the debate about the potential economic value of data. The debate, however, has narrowly focused on the use of data, rather than on the process of its generation.

While agile practices improve the odds of success in many situations, neither agile practices nor any others are silver bullets. There are situations in which projects will fail, regardless of methodology. For example, one of the Agile Manifesto principles is that people are more important than process.

For the past few years, I've covered the use of business rules management systems (BRMS) due to their ability to add automated decision-making capabilities to applications in domains such as personalization, marketing, compliance, fraud, and business process management (BPM), to name a few.

An effective plan provides guidance and direction to the people who will implement the plan. Regardless of the type of initiative that is being planned (business, investment, marketing, project, etc.), the plan describes not only the business problem and proposed solution, but also the strategies and tactics to be followed during implementation.

Aligning IT execution with IT strategy means knowing the value projects bring to the table. This value has to be measured in some way meaningful to those providing the funding or consuming the benefits. The units of measure for both the cost and benefits is usually in dollars or some percentage of dollars. The physical prioritization of suggested projects starts with a "paired comparison" analysis rather than a linear ranking. The linear approach falsely sorts the projects by failing to distinguish between real need and perceived need.

For me, the most telling and important statistic in Cutter's recent survey on the state of BI is the percentage of employees that use BI tools: 57% of respondents indicate 0%-9.99% and 70% indicate 0%-14.99% (see Cutter Benchmark Report, "Successful Business Intelligence: Moving Beyond the Obvious," Vol. 7, No. 9).

Two weeks ago, I was practically bombarded with e-mail from readers asking if I knew anything about the possibility of Business Objects being acquired. Like many, I'd heard the rumors, but I couldn't really say anything definite because they had been circulating for at least a year. Turns out that all the increased "chatter" was right after all.

This Advisor suggests you take a hard look at your strategic technology alliances. How many do you have? Are they productive? How do you decide which ones to pursue -- and which ones to terminate? Some of the alliances you may have include:

Channel alliances to sell your hardware, software, or services

My 2 August 2007 Advisor discussed the need for, and lack of in many instances, good release planning (see "Release (Project) Planning"). In the rush to deliver in short iterations (weeks), teams often suboptimize their pursuit of business value.

Last Wednesday was like any other Wednesday. I was busy working on some reports when at 0819 I received an e-mail from a person named Alex stating that he was changing jobs in a few weeks, and that he would like to receive the US Department of Homeland Security (DHS) daily reports at his new e-mail address.

As a kid growing up in a musical family, I was trained as a classical violinist. My favorite musical settings were ensembles; whether playing chamber music with my mom, dad, and brother, or playing the great symphonic works in youth orchestra.