Posted by Ron Kersic in the late evening: February 7th, 2007
The origins of lean thinking lie in production and there’s quite a bit of interest in finding parallels between current software development practices and those of manufacturing. The Poppendiecks for instance, frequently quote examples from classic manufacturing companies (Ford, GM, Dell, Toyota) to help understand why agile methods are a very effective approach to software development. Oddly enough they (and many, many others) are hesitant to buy fully into the concept that manufacturing industries and software development have indeed much in common.
Posted by Ron Kersic late at night: January 30th, 2007
I love Lisp. That’s right, ‘inefficient’, ‘hard-to-understand’, very much out of the ‘mainstream’, and ‘parentheses-obsessed’ Lisp. Unashamedly love it to bits.
Lisp is, of course, the most powerful language available. That’s right, what looks like an odd syntax actually is a terse syntax that allows for a great deal of configurability. Where you probably are used to formulating a combination of keywords and punctuation to get your ideas across, in Lisp you directly code in what amounts to other languages’ compiler-generated parse trees. List programs are lists (of lists of lists…) and Lisp’s parse trees are lists too and generating parse trees in code therefore is very easy.
Posted by Ron Kersic in the early morning: January 18th, 2007
Over the past weeks I have been pulled into quite a few debates about SOA and, more specifically, about the “right” way to do it. And the definition of “right” gyrates alarmingly often towards the application of an ESB.
Every new computing trend elicits debate and any sizeable debate provokes vendors to aggressively position their –often already existing– products to take advantage of the customer’s interest in the hot, new trend. Of course, the energy pumped into ever inflating expectations inevitably finds a way out in the guise of confusion and disillusionment. The vendor hype surrounding ESBs has been especially effective to the extent that organizations that want a quick-fix solution (and don’t they all?) are sold on the idea that an ESB is the yellow brick road to “instant SOA”.
Here’s the gentle introduction: an ESB is not an essential part of SOA. Actually, leave any product in their glitzy shrink-wraps for now: SOA is about analysis and design, and not about technology.
Of course, there are a few basic components you’ll probably want to use get kick-started. But an ESB is not one of these “basic components”; in fact – and here comes the shocker to some – you should absolutely not use an ESB when starting with SOA because an ESB does not encourage good SOA. ESBs are integration solutions and integration solutions reinforce application silos while SOA is about tearing down those silos.
An ESB is a useful component in a services infrastructure as it is especially good for bridging to legacy applications. Many ESBs also support reliable messaging, asynchronous messaging, and several message exchange patterns, which are all useful capabilities — just not in the initial stages of a SOA project. To put this in perspective, you might also want an orchestration engine at some stage in a SOA project — but that too isn’t where an organization should start a SOA initiative. All of this you just don’t need when first getting started; an ESB should be a later-stage purchase.
Some parting words for all of the kind folk that tried to convince me of the essential nature of an ESB by drawing hub-and-spoke diagrams: a bus, by definition, is not a hub but a physically distributed set of federated hubs. It may start out centralized, but as the implementation evolves the infrastructure should allow for more physical distribution. You might want (and appreciate) to keep the bus’ configuration and control centralized however.