Most sourcing projects (IT-based) that I have worked with can be classified under two categories: professional services and enterprise or organizational solutions -- based on their contractual agreements for delivering results. While presenting the principles, I would like to distinguish the activities that are different for each type of sourcing.

The discussion recently came up about the role of an architect and whether or not they should write code as part of a project team. This became a somewhat heated discussion with a lot of strong opinions, but I think it ultimately comes down to the typical consultant's answer: "It depends." It depends on what you mean by an "architect" and what you expect the architect to accomplish.

We are constantly amazed at the number of our clients who are strongly focused on cutting IT costs. Just this week, a large financial services organization asked us for assistance in cutting its IT budget. Yet this same organization continues to grow and to demand more IT services.

The IT industry today bears little resemblance to the industry of more than four decades ago when I started out in software development. In those early days, the concept of computers actually "communicating" with each other didn't exist. My definition of a "personal computer" was when I was the only user operating a mainframe at night, debugging my program (which was written on punched cards -- oh yes, "don't drop the card deck!").

A question I seem to be asked with increasing frequency by readers and other people I meet at meetings and conferences concerns whether I think that open source BI is catching on with companies. My answer is that open source BI is definitely catching on.

"The map is not the territory."

-- Marshall McMullen

One of the basic assumptions of agile development is that design and -- to a certain extent -- architecture evolve over time. The key difference between a piece of completely entangled software that has been maintained to death and software that has grown in an agile manner is refactoring, the art of improving the design of an existing system without changing its functionality.

"There is not the slightest indication that nuclear energy will ever be obtainable. It would mean that the atom would have to be shattered at will."

"With over 50 foreign cars already on sale here, the Japanese auto industry isn't likely to carve out a big slice of the US market."

"We can close the books on infectious diseases."

The three above predictions were made respectively by Albert Einstein in 1932, in a Business Week article in 1968, and by the US Surgeon General William H. Stewart in 1969.

In Nicholas Carr's famous 2003 piece in Harvard Business Review with the provocative title: "IT Doesn't Matter," [1] Carr asserts that technology's strategic impact has run its course, and the technology playing field is now level.

Last month, I discussed the concepts underlying Web 2.0 and Enterprise 2.0 (see "Enterprise 2.0: Hip or Hype?" 25 October 2006). Basically, I said that Web 2.0 involves the use of second-generation Web technologies (e.g., blogs, wikis, social networks, instant messaging, RSS, video conferencing, pod casting) in an open manner to allow consumers to communicate with each other, to form groups or communities consisting of members with similar interests, and to share ideas and collaborate on content.

collaboration = innovation

One of the strongest community-building tools available to the coach is the retrospective. Retrospectives happen at different times during agile projects. The reflection (a short retrospective) happens at the end of each iteration. Typically taking about an hour, the reflection is time for the community to process the iteration. The retrospective, a bit more formal and longer lasting, typically covers more time -- possibly weeks or months. In each case, the following are discussed:

In February, I discussed the convergence of the "two BPMs": business PROCESS management (BPM) and business PERFORMANCE management (see "Merging the Two BPMs: Opportunities Abound," 21 February 2006).

Last month, I provided an update on text mining and analysis technology (see "Text Mining Update," 24 October 2006). Basically, I said that over the past year or so, I've noticed increasing attention directed at the use of text mining for automating the analysis, categorization, indexing, summarization, and association of high volumes of text-based (i.e., unstructured and semi-structured) information for business applications.

Recently, my local state highway department put off a US $150-million project because, during a site mapping study, the state engineers discovered a layer of shale under a significant portion of the planned route. Now, building a stable roadway over a large segment of unstable shale is a very expensive and difficult process, so the highway department quietly postponed the project for a couple of years until a better route could be found or more extensive engineering studies could be completed. This was not a popular decision, but it was good engineering.

Even after five years and many papers, the Agile Manifesto principle of "Working software over comprehensive documentation" is misunderstood. What any organization strives for is understanding, not documentation, and that understanding comes from a transfer of knowledge. Furthermore, knowledge transfer occurs within a context; a context that is often complex.

What would it take to shut down your project intentionally? What state of nature would be required to actually drive you to formally terminate it? The unfortunate thing is that most project managers don't have an answer for that question, and the organizations that support them don't have the information either. All too often, we don't have a clear definition of an approach, terms, and process to shut down projects, which puts the organization at risk for continuing projects that are no longer profitable or that no longer serve their original intent.

What would it take to shut down your project intentionally? What state of nature would be required to actually drive you to formally terminate it? The unfortunate thing is that most project managers don't have an answer for that question, and the organizations that support them don't have the information either. All too often, we don't have a clear definition of an approach, terms, and process to shut down projects, which puts the organization at risk for continuing projects that are no longer profitable or that no longer serve their original intent.

A service-oriented approach helps in comparing and evaluating alternative implementations of the same service and choosing the best one. The organization is decoupled from vendor lock-in. This leads to much better control of the provider relationship, with consequent business benefits. These benefits often center on cost reduction.

In my last Advisor (see "OASIS SOA Reference Model," 1 November 2006), I described the OASIS Reference Model for SOA as a set of fundamental concepts about services and service orientation. The Reference Model document talks about these concepts being the basis for a "reference architecture." To add fuel to the fire, Accenture recently announced the Accenture SOA Reference Architecture and other consulting organizations are expected to follow suit.

A friend of mine was recently hired as a CIO by an association representing trade union members in the northeastern US. One of the most astonishing discoveries he made in becoming acquainted with the organization was the certainly obscene amounts of money paid to consultants for all sorts of menial tasks. He soon figured out why this situation existed and it reminds us what is the right and wrong culture in which to cultivate and manage a disciplined IT organization.

While wrapping up the semester's work, one of my executive MBA students challenged me: "Sure, all of this technology stuff is good -- and powerful -- and might even contribute to the business, but when all's said and done, politics determines what gets funded and what gets killed, what the company does and what it doesn't do. Good arguments are nice, but they usually fall on deaf ears.... I'd rather play golf with the boss than work my tail off writing the 'perfect' business case."

Does politics explain what happens -- and what doesn't?

You'll notice that I've shamelessly put the term "SOA" right at the beginning of the title of this Advisor. I'm as eager to attract attention as the next guy, and these days SOA is a near-irresistible little acronym. Any conference, organization, Web site, or product line that promises help in getting up to speed on "service-oriented architecture" is guaranteed an avid audience.

In our survey covering the use of open source software for data warehousing and BI, conducted last April, I noted that 14% of end-user organizations surveyed indicated that at that time they were using open-source databases for (target) data warehousing and data mart databases. Another 7% said they planned to do so within the next 6-12 months.