Blogger Upgrade

Blogger, home of this blog is going to get an upgrade. I have used Blogger for the last couple of years as it suits my text mostly blogging style. So far my only complaint has been about Google's segregated indexing (and a spell checker that seems to work against both Blogger and Google). Many others have been less patient.

The bad news is that the new Blogger will be integrated with Google Accounts. Recently, I wrote about how I had been forced to give up my identity to Yahoo. Now, it looks like Larry and Sergey are going to get a bit of my identity as well. Barry Diller has a piece of me and Rupert has all my kids nailed down in their own little spaces. Whatever happened to freedom?

A Short Post

Everyone including the media is talking about the idea of the long tail. To me it seems like last years idea. On the other hand, this is the silly season so maybe that is all they have to write about.

Moore's Law Logic

We all know Moore's law, but very few seem to understand the inevitable logic that it implies. Moore's law states that the number of transistors on a silicon chip doubles every 12 to 18 months. In practice chips are all pretty much the same cost (within an order of magnitude or so), thus we get double the capability every 18 months. The long term consequence of this is that everything becomes digital and every digital device is eventually a single chip.

I will not waste your time you with a comprehensive history. It is sufficient to highlight a couple of trends. The first trend is to digital media, starting with music in the CD and then MP3, then video and books, and now we are on the verge of digital broadcast TV and radio. A second trend is towards the single chip implementation of all electronic devices, starting with watches and calculators in the 70's then consumer electronics like CD players, stereos, radios and TV's. Currently we have just achieved the single chip cell-phone. The trend to digital media helps with the movement to single chip implementations because it is much easier to do an all digital device than one that has both analog and digital circuits.

One device that has so far avoided becoming a single chip implementation is the personal computer. A typical motherboard has about 6 to 8 processing chips, a bunch of memory chips and some driver chips that do nothing more than pass on a strengthened signal from a processing chip. One day all these chips except for the driver chips will coalesce into a single chip, because there will be nothing else better to do with all the available transistors.

So, last week when AMD announced that they were buying ATI, I knew what it was about. AMD has the single chip personal computer on their long term road map, and they need the display drivers and other peripherals that ATI has to complete their vision. AMD has already moved the memory controller onto the processor chip. Next I expect them to announce a low end chip with all the rest of the peripherals integrated. Over time the single chip processor implementation will move up to the mid range and high end. Sometime thereafter, the single chip computer with integrated memory will become first possible and then inevitable.

The Yahoo Business Model

In the back of my mind I had always understood the Yahoo! Business Model. Yahoo! gets you to sign up for the compelling online services that they provide and in return they sell advertising targeted at you. This was confirmed at the July meeting of the SDForum Business Intelligence SIG where Madhu Vudali, Director of Pricing & Yield Management at Yahoo! Spoke on "Pricing & Yield Management at Yahoo!"

For years, I instinctively resisted signing up for any online services and deliberately avoided using any services like driving directions that would reveal part of my identity, while still making liberal use of anything that did not reveal anything about me except for perhaps a few stocks that I was anonymously interested in. Recently I have been required to sign up for a couple of Yahoo! services so they have my identity, as they do for the half billion other people who are also signed up. As I said before their services are compelling.

Madhu explained the other side of the coin where Yahoo! sells advertising. This is not the auctioned search advertising that Google has become known for, although Yahoo! also does this. This advertising is the banner ads that you see when you use all those compelling services. The ads can be very specifically targeted such as a movie ad that is shown for a few hours on a Thursday and Friday afternoon to a specific demographic.

As Madhu explained, Yahoo! uses the yield management techniques that were pioneered by the airline industry in the 70's. The airlines use yield management to get the most revenue out of every available airplane seat while keeping the airplane full. Yahoo! has a similar problem but on a much larger scale. They have a huge inventory of page views and several dimensions such as age, location and interests on which to segment the viewers and interest the advertisers.

The problem is to extract the maximum revenue out of this mix. Compared to aircraft yield management the inventory is much larger and more squishy and the number of potential products numbers in the multi-millions rather than in the tens of thousands that an airline has.

All in all, it was a very interesting presentation. Unfortunately for anyone who was not there, Madhu's presentation is not available, so this is the best that you are going to do. Sign up for the Business Intelligence SIG mailing list (sdforum_bisig-subscribe@yahoogroups.com) and do not miss another meeting.

Divergence

The conventional wisdom (always suspect) is that portable devices will converge on a single platform. In the future we will each carry a single device that is a phone, clock, radio, camera, media player, media recorder, messenger and provide all the functions of a PDA including calendaring, reminding and note taking. This is called convergence.

Well as the song goes "it ain't necessarily so". I have written about this before, however I got to thinking about this again when I wanted another track on my iPod. I use the iPod Shuffle to listen to podcasts. Sometimes, I would like to have a second music track for when I want to concentrate and need background music to drown out distracting sounds. Time to trade up to a more sophisticated iPod? Well the alternative is just buy another iPod Shuffle, after all they are cheap enough and I can have one Shuffle with podcasts and one Shuffle with a music mix.

The point is, the devices are so cheap that there is no need to have one converged device. In fact you may be better off with several best-of-breed devices rather than one mediocre do-it-all device. Hence divergence. In fact convergence may be the new disintermediation.

Taming Concurrency

Two items this week. AMD again talked about their next generation of 4 core processors. That is, each chip will have 4 processors. On further research, both AMD and Intel have been talking about 4 core processors for sometime. This week I also received the May edition of IEEE Computer, which had as its cover feature "The Problem with Threads".

On the one hand we are moving into a world where applications have to be concurrent to exploit the available hardware. On the other hand there is a growing realization that the current tools are not adequate. All this in the face of hardware that is being designed to make life more difficult for the casual threads user.

The fundamental problem is quite simple. Programming languages offer a set of features to help the programmer and prevent them from making simple programming mistakes. For example, typechecking and sophisticated type extension mechanisms like objects to allow the programmer to easily express their ideas in a safe way. Automatic garbage collection in Java and other languages eliminate a huge collection of bugs, disastrous crashes and storage management code. On top of this are a set of design patterns that help and guide the programmer.

None of these things exist in the threads environment. A threading library is an add-on to a programming language. It provides no protection to the user, in fact it encourages unsafe programming practices. Also, threading libraries provide very little guidance as to how they should be used. On top of this, there is no rich set of design patterns for parallel and concurrent programming. I had difficulty recognizing the set of design patterns that are available and could not find patterns that I regularly use.

All this has the making of a perfect storm. "The Problem with Threads" paper takes the position that we have to integrate threads into existing programming languages because people are not willing to move to a new programming paradigm. I take the opposite view. We will not be able to write safe concurrent programs until we develop and determine to use programming languages that prevent us from making elementary mistakes, just as we have programming languages that prevents us from making elementary mistakes with types and memory allocation.

CDI vs MDM

Anyone who missed the SDForum Business Intelligence SIG meeting tonight missed a great meeting. Paul Friedman, CTO and founder of Purisma gave a talk on "CDI vs MDM: A Basic Primer". CDI is Customer Data Integration and MDM is Master Data Management, two of the most potent new terms in the IT world.

The problem is the same one that IT has been battling for the last 20 years. That is multiple database driven IT systems that all contain different versions of the same data, and the inevitable problem of reconciling that data. For many reasons, reconciling customer data is more difficult than other types of data.

Paul presented a spectrum of possible solutions. At one end of the spectrum is a registry Hub for Customer Data Integration (CDI). This takes data from operational systems and uses it to create a master registry of customers. As it only reads data from other systems it is a relatively inexpensive and light weight solution. On the other hand, the operational systems that source the data do not benefit from it.

At the other end of the spectrum is Centralized Author Control or Master Data Management (MDM). This has a single authority that receives and authorizes all changes to customer data in all operational systems. As you my expect, this is a much more difficult and expensive to implement as it involves changing the operations systems.

Paul's and Purisma's approach is to start by building a registry hub and then perhaps slowly move it to becoming more proactive with managing the data in the operational systems. Big bang MDM is as likely as other big bang IT projects to blow up in your face.

Uncommon SaaS Wisdom

Ken Rudin gave an interesting talk to the newly revived SDForum Software as a Service (SaaS) SIG on "Not-Yet-Common Wisdom in SaaS". I have heard the main points of his talk at previous presentations at the SaaS SIG. The interest was in the little details and real world experience that he bring to the topic.

Ken has been doing SaaS for a long time. He was an early employee at SalesForce.com, running their engineering team. He was on the original board of NetSuite, and created the Siebel CRM OnDemand division at Siebel. Now he has a new startup called LucidEra that is bringing SaaS to Business Intelligence.

Ken spoke for some time on the engineering challenges of SaaS. He explained why Enterprise software suffers from "feature" bloat (something I have complained about before) and SaaS does not. He also discussed the challenge of making software adapt to customer requirements. Enterprise software is usually given some programmatic customizability. With SaaS, allowing the end-user to program the product is a death knell, so the trick with SaaS is to provide the right simple options so that the customer can configure the software themselves by for example clicking check-boxes.

Related to this Ken talked about doing the relative efficiency of silicon versus carbon. By carbon he means people. Silicon is cheap and scalable while carbon is neither. While it is an amusing metaphor, it risks being confused with the other carbon problem.

Ken was also illuminating on the business problem of Enterprise software companies like SAP and Siebel that try to provide a SaaS version of their product. He termed this SoSaaS (Same old Software as a Service). Basically the business drivers are such that the two models cannot co-exist as peers. The most common outcome is that the SaaS offerings is sidelined as the little brother product and does not thrive.

Collaboration SIG Podcasts

I have been listening to podcasts from the SDForum Collaboration SIG, and I have to say that they are very good. It is not like being at the meeting, the visuals and the interactivity are missing, however it keeps mind alive while cleaning out the pool filter or pounding away on the cross trainer at the gym.

If anything is wrong with these podcasts it is that they show that an iPod Shuffle is not really designed around playing 2 hour tracks. I have not figured out how the Shuffle remembers its stopping point in each track, particularly when I switch it off and on again. What I experience is that it always seems to remember the stopping point before the last one so I find myself having to fast forward through many tens of minutes of the podcast. To say this is unwieldy is an understatement.

The Collaboration SIG goes to great pains to make the podcasts work. Most of the audience questions are audible, and the speakers come across very clearly. The only suggestions that I would make are to put on lead in and outro announcing track and perhaps edit out the longer pauses and the inevitable bit where the speaker grapples with getting the projector to work.

The other issue with these podcasts is finding them. The Collaboration SigBlog wiki (???) has 6 feeds from Atom to RSS 0.91, but I could not find a feed for the podcasts. Then I did a search on the iTunes Music Store for "SDForum" and found it immediately. Subscribe now.

Language Influences Architecture?

Peter Seibel started to give an interesting talk on "How Implementation Language Influences Architecture" at the recent SDForum Software Architecture and Modeling SIG. Peter started with three theories. The Sapir-Whorf theory is a long standing theory of natural language. It claims that language determines thought. The current common consensus is on the weak form of this thesis. (I will give you my opinion of Sapir-Whorf on another day.)

The second theory is the Blub paradox. This theory starts from the assumption that everybody has a favorite programming language that controls how they think about programming, which is where it loses me. The theory itself is too complicated and tenuous to sum up in an elevator pitch, so it may as well be forgotten.

The final theory is Turing equivalence. This is the idea that all programming languages are capable of expressing any computation and are therefore equivalent. The Turing tarpit is the idea that while all computationally complete languages are in theory equivalent, in practice some programming languages are just so much better and easier to use that the notion of equivalence is moot.

Unfortunately, after this strong start, Peter degenerated into a less satisfactory discussion of design patterns. The descent continued as Peter showed some particular problems with Java and claimed that they are better solved in Common Lisp. My experience with Lisp is confined to maintaining my emacs configuration file, something I have to do far too often. However, I think that the problems Peter highlighted were the usual problems with static versus dynamic checking. Java has some restrictions because it tries to detect and eliminate problems at compile time. Lisp has little compile time checking so problems are only discovered at run time. As it is better to discover problems sooner than later, compile time checking beats run time checking any day.

My view is that programming languages are tools. Just as I have four different hammers in my garage for different types of hammering tasks, so I use several different programming languages for different types of programming tasks. The issue is not that the language influences the architecture, rather that the software architecture influences the choice of implementation language.