Is your IT organization entitled to be the supplier of information services for your company? Do they deserve to be? Why? Are they the best, most competitive supplier of quality services? Do they even think they have competition? They should -- because every company needs to have accurate, timely, available information when and where they need it and be able to get it from the best supplier around.

It seems like architecture as an IT profession has finally hit the big time, judging by conferences if nothing else. Last week I presented at Dr. Dobb's Architecture and Design World 2006 in Chicago, Illinois, USA. This is not the first time I've presented at an architecture conference, but it is the first time I remember being impressed by how many people were present.

We all seem to have a morbid curiosity about how we compare to others -- how we compare to others in our industry or peer group in terms of spending on IT, or MIPS per employee, or whatever.

Although central architecture is generally effective in managing the IT infrastructure, enterprise IT architecture efforts often fail to extend their influence beyond that. A recent enterprise IT architecture (EITA) effort by a global leader in the marketing, travel, and hospitality industries spent US $12 million on service-oriented architecture (SOA) before the project was halted for lack of business ROI. This case is typical of EITA failures, which often progress as follows: The EITA effort is driven by IT management through a central IT architecture group, as discussed above.

I was talking recently with a colleague who is involved in a business performance management initiative. The subject quickly turned to one of the most important challenges associated with such an effort: identifying key performance indicators (KPIs). This Advisor summarizes what we discussed.

Basically, there are a number of techniques useful for identifying KPIs for business performance management efforts. But the reality is that, more than likely, organizations are going to have to utilize multiple techniques.

I was talking recently with a colleague who is involved in a business performance management initiative. The subject quickly turned to one of the most important challenges associated with such an effort: identifying key performance indicators (KPIs). This Advisor summarizes what we discussed.

Basically, there are a number of techniques useful for identifying KPIs for business performance management efforts. But the reality is that, more than likely, organizations are going to have to utilize multiple techniques.

We often encounter CIOs with a common complaint: business executives demand more business impact and less cost from IT. When we explore the issues with these CIOs, we discover that the problem is more fundamental: the IT organization has been incapable of communicating IT's business impact to business executives. That is, other than IT's cost (the cost of IT borne by the business units), the IT organization has not (credibly) communicated the impact and value of what they do to the business executives who pay the bills.

Countless self help groups meet each day throughout the world, and all start with the same premise, adapted from the original AA (Alcoholics Anonymous) Twelve-Step program: "First, admit you have a problem."

In this, the last installment of my three-part series on LoTech -- HiFi (for parts one and two, see "Part 1: The Evolution of Story Cards and User Stories," 23 March 2006, and "Part 2: The Cost of Tracking Tools," 11 May 2006), we will look at ways to take metrics beyond "how fast" or "how much."

As the classic "dog days" of summer approach in the Northern Hemisphere, there is a temptation to take a break -- to draw a deep breath and forget about one's individual and organizational worries for a little while. To paraphrase Thomas Jefferson, the price of organizational freedom is eternal vigilance.

Corporations that perform well over long periods of time have typically learned how to maximize the performance of their people. They recognize that it is people who make good or bad decisions or who may even avoid making decisions. They strive to create a business environment where employees feel valued and are supported by effective direction -- policies, procedures, standards of performance, guidelines, and tools -- for performing their work.

A friend of mine recently returned from a software development conference where he picked up an introductory copy of a business rules management system (BRMS) development tool. I asked him what he planned to do with it, and he said he had no plans, really, because he "didn't want to learn some new development language." Basically, he said he couldn't see writing rules to create applications he could more easily develop just by writing code.

In his recent E-mail Advisor, titled "Software as a Service," Mike Rosen, the Director of Cutter Consortium's Enterprise Architecture Practice, does a great job of identifying some of the technological advancements which are making "SaaS" a viable solution for a variety of application requirements.

Although everyone's known that it's been in the works for some time now, Microsoft last week finally revealed its plans for its upcoming on-demand CRM offering: "Microsoft Dynamics CRM Live."

One important fact to keep in mind when considering Microsoft's planned entry into the CRM software as a service (SaaS) market, is that it will not become generally available until sometime in mid-2007 for North America, with other locales to follow.

We think that this is a great time to focus on IT innovation because, as George Westerman, a research scientist with Massachusetts Institute of Technology's Center for Information Systems Research (CISR) points out in the May 2006 issue of Cutter Benchmark Review (CBR), innovation is alive and well in IT shops around the world, after years of tightening budgets and requests for keeping the lights on utilizing fewer and fewer resources.

An IT management idea that has not outlived its usefulness suggests how improved might be the performance of the IT organization were its members to undergo communications skills training. Put a router in a computer jock's hands and he's happy. Put him in front of a capital planning committee to justify the IT shop's 20% budget increase request and the result might be an audience recommendation to stick with routers.

I always enjoy the annual Cutter Summit conference. At this wonderful event, I have a chance to talk to a lot of old friends and Cutter clients and, most important, I always meet and learn from people who I haven't heard from before. This year was no exception: there were great talks about wikis, open source, and technology roadmapping planning. However, there was also something I find distressing: there was still an inordinate amount of discussion about code and coding.

Given how besieged organizations must feel today by both the growth in the incidence of information security breaches and the types of information security breach techniques that result in those breaches, the knee-jerk reaction is to throw money at perceived problems -- or at breaches that have already occurred -- in the hopes that this will constitute effective risk management. A more level-headed approach is to balance information security spending against actual risk.

In an earlier Advisor (see " Management's Performance Levers," 29 June 2006), I discussed the fact that, over the last four to five years, I've worked with a significant number of product companies in implementing agile development and project management practices.

Shared services and business process offshoring have in common some basic principles around the focus on value and accountability, so is the existence of a shared services (SS) model the optimal condition for organizational readiness in business process offshoring?

As enterprise architecture becomes more commonplace, many organizations realize that they don't have the appropriate level of skills in-house to staff the positions. An obvious approach is to look to a training program. In discussions about training, I'm often asked about certification programs for enterprise architects. Given that EA is a relatively new field, there aren't a lot of options for certification as yet, and just as important, there aren't any specific certifications that are generally recognized within the industry.

Last year, I submitted to you three perspectives for aligning business and IT in delivering business value: setting the right ground rules to begin the initiatives ("Setting the Ground Rules," 20 July 2005) and developing effective IT strategies to get business organizations engaged from the early stages of alignment initiatives ("Developing Effective IT Strategies," 3 August 2005), and recognizing the complexitie

A recent discussion on the NewGrange list server [1] began with the question, "Is there really anything that a project manager does that is more important than risk management?" As the discussion unfolded, there was a general consensus that a risk-centered perspective would definitely stand any project management in good stead. With that in mind, I would like to suggest a few risk-centered activities that are in keeping with an agile risk management.

For some time now, I've been saying that compliance applications have become a major driver for companies to apply business rules management systems (BRMS) (see, for example, "Rule-Based Systems for Customer Privacy Compliance," 10 May 2005).

I am working on a large project with a group of people on the opposite coast. I visit them once or twice a month for face-to-face discussions. On a recent visit, I learned a lot about improving productivity from some unexpected places.