One of many shibboleths in our business is "work closely with the business." Ways this can happen is to participate with business in its planning meetings, engage it in business-based conversations about requirements, get traction on what the business strategies really are, and so on.

In my last Business & Enterprise Architecture Advisor ("

This must be a question that tugs on CEOs, CIOs, VPs, and PMO directors at every company across the nation and around the world whenever they consider PM staffing. Wouldn't it be? PMP certification -- the most well-known and widely regarded certification in the project management world -- is a great default requirement, right? Require certification of all your incoming project managers -- and require that your current ones get certified in the next year -- and you're set, right? If you've required the industry standard, how can you go wrong?

Is Web 3.0 just hype, or are people actually working with these technologies? Do people even understand what Web 3.0 is?

It is quite a common occurrence in my practice: I step into an engagement that involves hundreds of developers, testers, product managers, project managers, architects, user design specialists, and quite a few other disciplines, from all over the globe. The time zone difference between some of their most important sites is 10, 11, or 12 hours. The expectations of whatever agile software method I bring to bear is that it will improve quality, productivity, and time to market.

I call this series of Advisors "Reflections on Innovation." There's plenty of writing on innovation that tells you what it is, how you must do it, and even suggests ways to predict the outcome of your process. That's an industrial approach, and I'm unsympathetic to its aims and methods.

It is quite a common occurrence in my practice: I step into an engagement that involves hundreds of developers, testers, product managers, project managers, architects, user design specialists, and quite a few other disciplines, from all over the globe. The time zone difference between some of their most important sites is 10, 11, or 12 hours.

In my last Advisor ("Principles of Design: Part I" 14 September 2011), I introduced

[From the Editor: This week's Advisor is from Robert Scott's introduction to the September 2011 issue of Cutter IT Journal "21st-Century IT Personnel: Tooling Up or Tooling Down?" (Vol. 24, No. 9).

I've been researching new, innovative applications of BI and analytics.

With the debt crisis, the spending crisis, the unemployment crisis, and a hundred other crises du jour, there is constant talk about the fact that we are leveraging our future. I couldn't agree more! I would suggest, however, that it is not only a loss scenario.

Experience has shown that agile data warehousing (ADW) can be a double-edged sword when viewed from the program level or the perspective of a data warehousing/business intelligence (DW/BI) director.

The risks associated with personally owned devices in the enterprise are significant, warrant serious consideration, and are poorly understood. So why are we still having the teenage-esque debate over them when we should be engaging in meaningful dialogue aimed at making decisions in the best interest of the enterprise? Is it that we truly do not understand how to frame the discussion? Is it that we do not have the courage to engage? Anecdotally, it is both (with a little bit of the "rock star CEO intimidates nerdy IT security analyst" sprinkled on top).

Nearly a year ago, I reported that advancements in virtualization technology have made virtual desktop environments much more practical and that this will facilitate broader mainstream adoption of desktop virtualization by end-use

Dear Colleague,

I was reminded of this quote by Gerry Adams, president of Sinn Fein, when I came across a couple of articles in the New York Times and the Wall Street Journal over the course of the past week.

At first glance, you might think that the best way to deliver good software quickly is to have teams of people who have deep skills in required areas. There are several reasons why this is not the most effective approach to developing software when you have changing requirements and need to be agile, including:

During the last decade, vendors, standards bodies, user organizations, and consulting houses have all attempted to capture the promise of business service management (BSM) -- with notable success.

I happened across a really interesting exhibit on industrial design at the San Francisco MOMA last week.

A recent survey conducted by Cutter Consortium helps shine some light on corporate spending trends for text mining and analysis as well as organizations' overall attitudes toward the importance of having the capability to analyze unstructured data.

Maybe I am getting old. Lately I have been reflecting on the debates regarding methodologies that this industry seems to have all the time, no matter the decade. Every generation of IT people seems to spontaneously generate a new, great methodology that will transform and replace all that came before. Oh yes!

One of the saddest patterns I've seen several times in my career is that of an agile island. The story usually goes along this route: a highly motivated middle manager finds herself in some difficult situation and decides that agile is the right way out of her turmoil.

For some time now, I've been looking for a word or a phrase or some way to distinguish among classes of architects.

The person who cuts my hair has a formal license on the mirror. The guy who fixes the pipes in my old house has a license, as does my doctor, my lawyer, and the guy who flies me around the country. Heck, even the kid next door has a driver's license. But the person who developed the architecture, wrote the code, and manages my IT operation is not only unlicensed, he or she has no formal proof whatsoever of competence beyond a college degree and some experience.