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.
Wednesday, May 31, 2006
Thursday, May 18, 2006
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.
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.
Tuesday, May 16, 2006
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.
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.
Thursday, May 11, 2006
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.
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.
Tuesday, May 09, 2006
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.
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.
Subscribe to:
Posts (Atom)
