American businessman Warren Buffet once said that, "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently."

Thirty years ago, businesses were organized functionally. The organization chart became the way to describe how the business works. In the mid-1980s, scholars like Michael Porter and consultants like Deming and Hammer led the way to refocus work on process and quality control. Making sure you had a robust process was the key to efficiency, productivity, and quality.

It is critical to have an individual accountable for the success of each contract. This person often carries the title of contract manager, but other terms such as contract officer, contract superintendent, and contract supervisor are also common. The contract manager (or equivalent) is the hub of the contract management network for the contracts under his or her control.

In my last Advisor (see "EAD: The Architecture of the Customer Experience, Part 4," 2 April 2008), I discussed the interviewing approach we use to break down and cluster into a set of experiences the many interactions customers have with companies.

Recently, cloud computing and the rush to solve the problem of writing programs to exploit parallel computers have begun to push software-oriented architecture (SOA) out of the technical headlines.

Despite the immense impact that the user interface (UI) design has on how IT applications are used, perceived, and judged, the discipline of UI design remains a stepchild within the software development process as practiced by most large companies. Typically, UI design is shoehorned between the requirements and design phases. Under great time pressure, a UI designer creates screen mock-ups and perhaps an interface specification that are meant to drive application design and coding.

More than half of end-user organizations undertaking business performance management initiatives are required to make changes to existing business processes in order to support implementing their performance management solutions. This finding comes from a Cutter Consortium survey conducted in January 2008 of 101 end-user organizations (based worldwide).

My objective in this article is to look at the discussion of BI with or without DW from a business rather than a technical or operational perspective.

Imagine, for a moment, that you have an integrated team that is to build some software product. This team includes all the necessary stakeholders to define, assess, and refine the product; it contains the people who understand the need and have all the required skill sets and tools to accomplish the task. Call this the A Team. The A Team might be creative and highly innovative. Or not. What makes the difference? Whether the team uses an agile or a waterfall process? Whether the team uses Java or C#? No.

One of the interesting dilemmas facing current IT development managers is what to do with the applications that were written in what used to be referred to as 4GLs (fourth-generation languages). In the 1980s and 1990s, a number of such languages were developed that were designed first to handle management reporting tasks and then to develop basic PC and client-server applications.

An old boyfriend of mine, while a young adult, once spent a Saturday with his best friend taking apart and reassembling his car's engine. The intent wasn't to make improvements. They were simply curious about the engine's assembly and about their own ability to do something that was more ambitious than other such experiments they had tried.

As technology continues to improve and advance, businesses are using software applications, components, and other technology tools once reserved for IT use in ways that IT departments sometimes have no control or even knowledge of. This ubiquitous adoption of technology at many levels within a company -- as well as the increasing complexity of internal systems, external partnerships, and shorter application-development cycles -- has left IT executives scrambling to find a solution to manage the enterprise technology roadmap.

We have been working with public sector and commercial clients in upgrading their IT investment prioritization processes. While doing so, we have found it helpful to apply a prioritization maturity model to establish the company's goals and outcomes. Clients of Cutter's Business-IT Strategies Advisory Service are no doubt very familiar with the concept of maturity models in software development.

I've been talking for some time now about why Business Rules Management Systems (BRMS) should be considered an important part of an organization's service-oriented architecture (SOA) initiative.1

Data integration tools vendor Informatica Corporation is buying Identity Systems, Inc. (ISI), a provider of identity search, matching, and resolution software, for approximately US $85 million.

Business process management (BPM), also called business process modeling, is a hot topic these days: as a standalone solution; as the impetus for the customer relationship management (CRM) and supply chain management (SCM) categories; and perhaps most importantly, as a critical enabling technology for the orchestration function in service-oriented architecture (SOA).

In working with a number of software companies over the years, I've come to find a single metric that is very effective in determining how "agile" these organizations are: the length of the tail. The tail is the time period from "code slush" (true code freezes are rare) or "feature freeze" to RTM (release to manufacturing).

It seems as if every time you turn on the television there's an advertisement regarding identity theft or a newscast about how someone lost their laptop containing the personal records of hundreds of thousands of people.

I noted that Joseph Weizenbaum died last month. Weizenbaum was an early computer scientist, most famous perhaps for the creation of Eliza, a very early artificial intelligence (AI) program fashioned around a simple pattern recognition (stimulus-response) model that mimicked the approach used by psychologists and psychiatrists in talking to patients.

Example:

I frequently read articles about outsourcing, benefits, risks, business value, challenges, best practices, concerns, and so on. I wonder whether this information, most of it around success stories, refers to a reality exclusive to American companies, or whether we have the same environment in Latin America.

I'm a strong proponent that everything we do in an IT organization should be driven by business needs and issues. One reason many IT managers are out of sync with their business client is that they haven't really established what the business needs and issues are.

Awhile back, Cutter Senior Consultant Mike Rosen and I wrote an Executive Report (see "Enterprise Architecture: It's Not Just for IT Anymore," Vol. 9, No.

Disasters happen, and projects do go wrong. Very often this sets off a chain of events that causes more hardship down the line and incurs costs that someone will be looking to recoup. However, all too often, the distress of the situation blinds the people involved from the opportunities that remain to break new technological ground, introduce new products or capabilities to the market, and solve problems that could not be solved before.

Like other metrics, key performance indicators (KPIs) require modification to remain accurate. Reasons for modifying KPIs can range from the implementation of new business processes and corporate objectives and strategies to responses to changing market conditions or business environments.

I've been working with many companies lately whose IT systems are dominated by enterprise resource planning (ERP). This is not surprising, since an ERP system is an essential part of most IT portfolios today. In many organizations, the ERP system contributes as much as 70% of the total IT capability.