He knows nothing -- Nicolas Carr is back

From time to time I watch Jim Cramer's Mad Money show. Despite the histrionics, there is often a lot of very good investing information. I especially like that fact that Jim is not afraid to take on the experts. One of his favorite phrases is "He knows nothing!!!" when he is taking on some supposed industry expert.

That's sort of how I feel about Nicolas Carr. Carr has taken a series of extreme positions, which, unfortunately, don't help anyone in IT management. Carr's original judgment was that for most organization IT is a commodity. Now Carr has a new book that says that large IT organizations will all be moving to a utility model. It is all about economics, Carr argues. Information is just like electricity or telephone service and history has shown that utilities, now international utilities, are much better equipped to operate worldwide networks than individual in-house IT organizations.

At this point, I'm tempted to invoke the spirit of Jim Cramer, "he knows nothing." If IT were such a commodity, why is it that so few organizations have been able to replace their aging legacy systems and keep up with technological change? Why have the big winners in the Internet age been folks like Google and Amazon who have not only continued to focus on running their own computer applications, but running their own computer centers and networks and even developeding their own operating systems?

My day job often involves my analyzing the Enterprise Architecture of large organizations, and what I can tell you is that most of these organizations have such complex environments that it is laughable to imagine that some large organization will be able to take over and treat it as a utility activity. Many of these organizations don't even know what they have. Moving the whole operation to a group that is more interested in making money on change orders than it is in corporate success is not going to improve the situation. As IT becomes more and more critical, if I were a CEO there are a few things that I would be totally unwilling to let out of my control and IT would be right at the top of my list.

What gets lost in the discussion of IT and economics is the fact that the is a huge knowledge gap between what a good outsourcer knows about an organization's systems and data and what a good internal IT organizations knows. This is going to come to a head over the next decade when a great many of the people who built all those old systems a generation ago retire.

Unfortunately, as misguided as Carr's ideas are, they are sure to gain currency--it just what large outsourcing organizations want their customers to hear. As a result, don't be surprised to see quotes from Carr's latest book crop up in the next marketing presentation that you see.

Doing SOA wrong

I don't usually excited by articles I read in the trade press. There are lots of people writing that all have their own, often slanted perspective. However, I like BP Trends and the people who write for them are usually informed and articulate. Anyway, this morning one article caught my attention-- "Is Your SOA a Disaster Waiting to Happen?" by Keith Harrison-Broninski
( http://www.bptrends.com/publicationfiles/1-08-COL-HumanProcesses-Harrison-Broninski-rev-12-12-cap-final.pdf )

In this article, Harrison-Broninski had a very provocative quotes:

"I recently heard a BPM Suite vendor speak proudly of a BPMN process they had implemented that contained 250,000 steps. This represents a vastly complicated piece of business software, so I asked how they had tested it. He replied that testing was unnecessary since their tools did not require the user to write lines of code (just to draw diagrams), and anyway their products contained simulation features if you really wanted to prove that an application worked as expected. He then went on to say how this approach must be OK, since other organizations are using their suite to build safety-critical applications."

Now, I don't know which vendor this was, but if the article is true, SOA and our industry is in for some very hard times. The approach suggested in this quote is not just questionable, it represents "malprogramming". The first thing to note is that compexity doesn't scale. If you have that many components, you have to have a way to test them independent of all the rest and test groups independently. You have to pay attention to time dependencies and data dependencies. Otherwise, it is truly a house of cards.

More on this subject later...