A new three-letter acronym has hit the customer relationship management (CRM) market in the past few years: CEM (customer experience management) [1].

It was bound to come. After so many years of focusing on internal CRM processes (how the organization is interested in working with the customer), now it's time to improve the customer's experience in his or her interactions with the organization.

There have been a lot of announcements pertaining to open source BI (e.g., query, reporting, OLAP, dashboards) and data warehousing (data integration, data cleansing, etc.) tools over the past few years. But the big question on everyone's minds remains: to what extent are end-user organizations actually adopting open source BI and data warehousing tools?

IT shops generate oodles and oodles of metrics. IT hardware and software can spit out hundreds of operational metrics, mostly to monitor system performance and diagnose system errors. On the hardware side, routers, switches, and data devices produce metrics that let operators infer the volume and kind of usage patterns at work.

In the recent Advisor "Generally, Role Specialization Aids Agile" (26 November 2008), Cutter Fellow Jim Highsmith argued that the idea of generalists in agile projects doesn't scale and that the focus should be more on collaboration than on trying to staff a project from ge

The current economic climate seems to be taking its "risk toll." It's not that organizations are now forced into situations where they have to take risks that they would not otherwise take. In fact, the exact opposite phenomenon seems to be occurring.

I am always surprised to find myself in discussions with people who have architect titles and who have little feeling about the key concepts of architecture. Too many members of the current generation of technical experts have very little comprehension of what differentiates systems from programs or services.

Because nearly every organization has become heavily dependent on technology and many organizations have been dissatisfied with the ROI of their IT operations, they are looking for new ways to acquire and administer their IT systems and business applications.

A business needs outstanding leadership to successfully navigate through today's complex, competitive world. Identifying and understanding the strategic orientation of your business toward customers and innovation is one thing; however, it is quite another to successfully reorient the organization in another direction.

When we think about IT architecture, or talk about it, the desire to draw parallels with building architecture is often irresistible. Since I have just returned from a visit to Italy, I'm drawn to make some observations along these lines.

Consider the "competent performer" who possesses good skills and knowledge. However, good skills and knowledge are not sufficient. In order to deliver acceptable work, the competent performer must have a good attitude, conviction that he or she is doing the right thing, and an understanding of how to support enterprise intents and strategy.

The need to consolidate disparate data warehouses and data marts is a situation that many organizations have been forced to deal with. Based on our latest research, approximately 39% of organizations indicate that they have already conducted, or are involved in carrying out, some type of effort to consolidate data warehousing or data marts. It also appears that this trend has accelerated.

The myth surrounding agile projects goes something like this: a small team of developers who can handle any coding task (database, business logic, user interface, middleware, etc.) works hand-in-hand with the end user who talks with the development team about the details of the work requirements. The small-team-filled-with-generalists model may work for some small projects, but it doesn't scale.

Population Estimates of Three Generations of Workers

Generation

Birth Year

As companies become comfortable using agile methods, larger and larger projects are being undertaken. While the myth, "agile is only good for small projects," is being proved wrong every day, there are still a number of issues that need to be addressed in order to scale agile -- in two dimensions, up and out.

With 2009 looming large, ugly, and just around the corner, it's time for the obligatory prognostications. Boy, is this difficult.... Hmmm. What will next year bring? Any wild guesses?

Rather than focus on the dark clouds, I am going to first look for the silver lining ahead.

"You keep using that word. I do not think it means what you think it means." -- Inigo Montoya, The Princess Bride

In a meeting today with a client, people were talking continually about how the IT organization and business have to improve their collaboration. The business feels a considerable amount of pain about the lack of collaboration with IT, and IT in turn is feeling some pain collaborating with the business during a transition to agile.

I've recently been observing a group of people attempting to develop a local food system for their community. What strikes me is that the principles of enterprise architecture (EA) that I've learned and used over the years are entirely relevant to this endeavor, despite the fact that IT has no role in it whatsoever.

Y2K was great for IT housekeeping. It forced us into answering the question: do we make that application compliant, or can we toss it? Well, we are almost nine years past Y2K, and I am finding that during this period many organizations have been concentrating on adding new functionality, and rarely changing it, let alone replacing it.

Almost one-quarter of end-user organizations indicate that they currently have operational BI applications deployed and in use.

The debate constantly comes up about the role of an architect and whether or not he or she should write code as part of a project team.

Which of the following is a worse problem?

The developers have started using agile practices, but managers are not on board.

A project manager institutes agile practices for his or her project, and only some of the developers and testers go along with it.

It has been a month since I wrote the first part of this Advisor in which I suggested that governments may need to understand the underlying sources of financial risk before they kick off yet another rescue plan (see "Before Moving to Another Rescue Plan, Review Your Risks," 6 November 2008).

Last month, Grafton County, New Hampshire (USA), Treasurer Carol Elliott lost her bid for a fourth term to Vanessa Sievers.

Everyone has a perspective about return on investment (ROI). Lots of calculations, models, and algorithms allegedly precisely measure the impact of alternative technology investments. There is strategic ROI and tactical ROI; there is "soft" ROI and "hard" ROI. There are as many ROIs out there as there are RBIs in the major league. What do we make of the ROI smorgasbord?

In working with a client recently, we made the point that getting and keeping business involvement in any aspect of IT governance is a serious difficulty. We noted that this is true for every client with which we've worked over the last 25 years.

In this case, this understanding allowed us to lead this client to the following "three-phase" approach to successfully gaining management involvement, focusing on portfolio management for applications and infrastructure services as a start.