In February, I wrote about service component architecture (SCA) and service data objects (SDO) (see "Service Component Architecture," 1 February 2006, and "Service Data Objects," 15 February 2006), which are emerging specifications for how services can be written and assembled in an industry-standard way. At that time, eight companies had joined together to create and support these specifications. Let's see how this effort is progressing.

This Advisor is about my adventure in getting to a creative solution for a tough problem. My recent work has been to architect, design, and code in Java an extremely fast, very high-speed data structure to represent complex networks. There have been many different designs and data structures for software implementations over the years and trying to beat the state of the art can seem unattainable.

The recently published Association for Project Management Body of Knowledge (5th edition) features 52 topics required for the successful management of projects. The last of these topics describes the area of "professionalism and ethics." The inclusion leads to an obvious question: namely, should we as project managers care about being professional?

When you came to work today, did you encounter a big surprise? A reall-lly BIG surprise with a major program initiative? If not today, did it happen yesterday, or last week, or last month? Is it one that may cost significant time, effort, and money to resolve? Anyone who has worked on major IT programs for any length of time in their career has experienced, or will encounter, that inevitable day when their best-laid plans have gone awry!

I've been hearing more and more about companies establishing "BI centers of excellence" (COEs; also sometimes referred to as "BI competency centers") in order to provide advice and experience with implementing BI techniques, applications, and products throughout their organizations. Several issues are fueling this trend, including corporate BI tools standardization initiatives as well as the move to distribute analytic capabilities across the organization to different classes of end users.

Each time IT explores a new domain or business area, it is inevitable that we have to develop a new set of tools to support that methodology. For example, relational database development spurred the development of entity-relational diagrams (ERDs) and object-oriented design spurred the development of object-class diagrams. Each of these environments required the development of new tools appropriate to the job at hand. But while new domains ultimately require new tools, our first instinct is to reuse existing tools and adapt them for the new domain.

In my last Advisor ("Collaborative Leadership Basics, Part 3: Get in the Same Boat Together," 31 August 2006), I suggested that "outcome interdependence," or the feeling of being in the same boat together, is the number-one predictor of successful collaboration and teamwork.

In retrospectives on corporate failures, not surprisingly, strategic failure typically outranks operational failure as the primary cause -- often by a factor of two to one. Business history is littered with corporate carcasses marking a company's inability to deal with changes in its markets. As enlightening as corporate strategic failures are -- as engineering professor Henry Petroski notes, we learn to succeed by understanding our failures -- corporate strategic successes are also sources of useful lessons learned. Here is a short story of one of them.

So, you want to avoid the offshoring lay off axe? Then become the person who manages all the offshoring initiatives in your organization.

So, you want to avoid the offshoring lay off axe? Then become the person who manages all the offshoring initiatives in your organization.

In May, I wrote an Advisor titled "The Convergence of BPM and SOA Continues" (3 May 2006). Little did I know that it was only the beginning. The pace of consolidation has increased significantly in recent months in the SOA, BPM, and combined markets. Let's take a look at some of the highlights.

A client recently asked how to assess the effectiveness of their IT organization. We immediately responded: does the IT organization add value to the business? Of course that's the right question -- but exactly how does one go about getting the answer?

American football teams spend many hours reviewing films of their own games, as well as those of their opponents. They analyze what worked and what didn't, who made mistakes and who performed well. They incorporate that analysis into their preparation for the coming game.

The other morning, over coffee, I was talking with several folks about the predicament that the big US automotive manufacturers General Motors and Ford now find themselves in. Simply put, GM and Ford are in trouble because sales of their SUVs, pickups, and other large vehicles have declined considerably. Some defined it as a forecasting problem. Others said it was faulty data analysis, and asked me why Ford and GM's BI folks failed to predict the shift in consumer sentiment to smaller, more gas economical cars.

Back in 2003, I wrote about the use of intelligent video systems for adding automated, real-time threat detection, identification and alarming capabilities to closed circuit television cameras for security applications (See "Intelligent Video Surveillance for Security Applications," 30 September 2003). Since then, there have been a number of new developments regarding intelligent video systems.

Business process management (BPM) is a category of software application sweating from the heat generated by the spotlight of attention. No surprise when you consider the importance of managing, refining, and reengineering the very business processes that multimillion-dollar enterprise software automates. As BPM software evolves, the best of this class of application is likely to blossom into multiple points of functionality. Stay focused on the following functional modules as the bare minimum needed to constitute BPM software that offers any real value:

"Time after time" goes the song by Cyndi Lauper. Scheduled time has been a pervasive theme in software development projects and, in fact, for all projects. But what time are we really talking about? What defines late? Is time the most important control measure? This Advisor will explore three distinctly different "time" perspectives: planned versus actual, elapsed, and schedule performance. Each of these places a different perspective on "time." So our song might be "time after time after time."

As I wrote several weeks ago (see "Losing Your Reputation," 27 July 2006), Airbus announced a second major delay in its delivery of the Airbus A380 super jumbo. This past week, Airbus announced yet another delay, which, to say the least, hasn't pleased its customers. Instead of delivering 25 Airbus A380s in 2007, Airbus may be lucky to deliver just 4.

When you came to work today, did you encounter a big surprise? A reall-lly BIG surprise with a major program initiative? If not today, did it happen yesterday, or last week, or last month? Is it one that may cost significant time, effort, and money to resolve? Anyone who has worked on major IT programs for any length of time in their career has experienced, or will encounter, that inevitable day when their best-laid plans have gone awry!

Back in 2002, when I wrote the Executive Report "Transitioning Business Application Components to Web Services" for Cutter Consortium's Enterprise Architecture advisory service, I described service-oriented architecture (SOA) as a next big thing.

This is the first in what will be a series of Advisors on elements of working together that we can think about systematically and productively. I'm indebted to other members of the new Cutter Innovation Practice: Rob Austin, Shannon O'Donnell, and Erin Sullivan for all sorts of help.

Several years ago, a company whose software was used by other companies in the semiconductor industry to design complex integrated circuits scheduled its annual strategic business planning offsite retreat. The company was one of two dominate players in the industry and, by itself, accounted for more than one-third of integrated circuit design software sales. Its main competitor had a slightly larger share of the market, with the remainder of industry sales being shared by a host of smaller, niche market competitors.

Over the past year, I've seen a lot in business technology discipline (or not). I spent a day at a large enterprise where they explained how they had implemented 11 ERP systems and multiple instances of them. When I got up off the floor and promised them huge savings by reducing the variation in their back-office environment, they told me that they really weren't interested in the savings because they would require too many meetings, too many arguments, and -- well -- just too much discipline.

The other morning, over coffee, I was talking with several folks about the predicament that the big US automotive manufacturers General Motors and Ford now find themselves in. Simply put, GM and Ford are in trouble because sales of their SUVs, pickups, and other large vehicles have declined considerably. Some defined it as a forecasting problem. Others said it was faulty data analysis, and asked me why Ford and GM's BI folks failed to predict the shift in consumer sentiment to smaller, more gas economical cars.

In my last couple of Advisors (see "Working Around the Delete Key, Part 1," 24 August 2006 and "Working Around the Delete Key, Part 2: What Are Our Users Really Doing?," 7 September 2006), I've commented on how inventive human beings become when working around perceived problems with their systems.