When introducing an agile approach to IT development into an environment that has known only a structured, start-to-finish, planned approach, you will likely encounter resistance. Thus, you will find yourself needing to compromise and adapt your methodological approach, to institute control points we call "traffic cops," and to learn to depict what you are delivering in a way that proponents of the previous "waterfall" methodology will not just understand but also accept.

Many companies are decentralized these days, though the number that are reverting to centralization is increasing. The essence of the centralization/decentralization dance spins around the value of shared services. But it's also about discipline and governance.

The recent downward economic spiral has predictably put IT in the spotlight as a target for cost reduction. As I've noted in past years,1 the fact that IT has historically been viewed as an expense while at the same bearing the expectation of delivering strategic value has caused a long-lasting macro-headache that still plagues corporate IT across all industries.

The thing about a crisis -- and crisis doesn't seem too strong a word for the economic mess right now -- is that it creates a sense of urgency. Actions that once appeared optional suddenly seem essential. Moves that might have been made at a leisurely pace are desired instantly.

-- Gerald F. Seib1

The IT organization gets a triple dose of challenges during a company acquisition:

IT must support the existing technology of the acquired company after the acquisition is completed.

IT must manage the technology transition projects to assimilate part or all of the technology of the target company to the acquiring company.

One important concept about modeling is that models are based on a well-defined set of abstractions, relationships, and constraints. This is true whether the model is of a business process, a software component, or a data structure. However, the underlying concepts are all different, and so we use specialized modeling languages (or notations) to express them.

This is the Cutter Information Technology E-Mail Advisor (that is obvious, but stay with me here). It may not sound right for someone to advise against the use of IT in this forum, but that is what I am going to do.

In the light of the hype over Web 2.0 this past year, I want to stress that organizations are making use of the techniques to improve the collaboration capabilities of their BI and business performance management initiatives.

Agility is the ability to act quickly and with economy of effort in accurate response to change and also to initiate change for business advantage.

Strategic agility as a science, especially the analysis of IT strategic agility, is emerging as we speak and will be moving into the mainstream within a few years. The Internet has dramatically altered how capabilities and firms are knitted together. The technology is more pliable today than just a few decades ago.

There exists an agile scaling myth that goes something like this: "Agile development works well for smaller projects, but doesn't scale to larger ones." Whether because of initially reported agile projects that were small or the XP focus (in early years) on smaller projects, the myth has stuck, as project teams of 50, 100, and 500 have been successful.

Dr. Geary A. Rummler passed away on 29 October 2008. Geary Rummler was the real thing. There were not many people like Geary in business process management. In a world increasingly dominated by radical management ideas and radical technological innovation, Geary was a researcher, writer, and consultant who focused on organizational change, management control, and motivation.

Working on relations between business and IT, we often forget about the most essential problems in this area. Simply by working on models, we lose the real view and the context. It is beneficial to remind ourselves of the essential reasons problems between these two areas exist.

I've been covering business rules management systems (BRMS) for years now. However, I occasionally get the feeling that some still consider BRMS to be some sort of far-out technology. That's "far out" in the way of being too advanced or too out of reach for more mainstream end-user organizations to employ.

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.