Much is made of the supposed complexity of software development for parallelism. It has been my experience, however, that the influence of traditional application development thinking and training is the main contributing factor to this myth. Ordinary human beings have no problem developing highly efficient implementations of parallel algorithms which suffer not from the prescriptions of Amdahl's Law, although admitedly do encounter scalability constraints associated with other factors, like managerial span of control and the limits of reliable communications using voice only.

Most, if not all, software that is available for the support of parallel applications is hopelessly tied to the intrinsic limits of computer hardware available in the marketplace over the past 40 odd years. As long as the problem of parallelism is viewed in such a context, the complexity of solutions will only increase.

My suggestion is that application developpers spend a few weeks in a day care for pre-schoolers and watch how they solve such problems as getting toys from a toy bin. Applying the lessons learned to a parallelism problem can result in rather amazing enhancements to applications.

Much as I like the idea of SOA, I can't help but feel nervous when I read that everything will be "SOA enabled as a default". To me, SOA implies potentially high latency and a need for controls (ie overheads) to cope with the fact that you aren't quite sure who'll be using your service and what for.

OK, there are real benefits from SOA for a lot of people - but for others (as Martin implies), in some applications, a nice tightly-coupled efficient point-to-point solution may actually make business sense - in the future as well as now!