Does Unique Selling Point have any meaning in for Open Source professional services firms?

On my way home back from a gig in Kiev last week, I read a truly enlightening, fun and excellent white paper from the smart folk of Wellesley Hills Group, posted at QuickArrow. The paper - or rather, collection of articles - entitled "Truth and Lies in Professional Services Marketing", argues that the dynamics of services business are different from those of a product business: consequently, the rules and mantra's of marketing need to be tweaked (or thrown out) when applied to professional services businesses.

I was particularly interested in because, in the last year, I have studied a Diploma in Business Development at the Irish Management Institute; I graduate next week (with distinction: hurrah!). The Dip Bus. Dev. is a great program, particularly for myself as a person of technical origin. Regularly I would meet with my assigned business mentor, who would administer a ritual and deserved mental beating as she questioned everything I had ever held dear. One of the most difficult things for me on this course was to let go of my need for scientific, clear reasoning, and embrace fuzzier, more intuitive business concepts.

But back to that paper! Let's say you're running a professional services firm that specializes in open source. What can you say is your Unique Selling Point? Hmmm. That you know the source? Everyone knows the source dude, that's the whole point! That you have committers on your team? Better... however, anyone with smarts can become a committer in an open an vibrant community, so if this is your USP and your open source projects are successful, then your competitors will quickly become committers: there goes your USP, gently flying out the window. The open nature of open source means that the barriers to entry are low; sure, becoming an expert on an open-source project takes time, but anyone with smarts and the willingness to invest the time can eventually break into your space. Back to the USP: you could talk about experience, customer-focus, reliability, ... but then, so will all your competitors, so they're not good unique selling point candidates either.

So: forget about "uniqueness" for now. The nature of open source services is that, if your project is successful, then your firm will become one of many others - an ecosystem, if you will - offering similar services around the code. Being a PS firm in open source is very much like being a law firm, or a chartered accountancy firm, or a doctor: all rely on an open body of knowledge at which they have become experts, and they sell that expertise for a price. It's not about "uniqueness": when you want a lawyer, accountant or doctor you do not care if they're unique or different: you care that you can trust these guys to solve your problem and make things right. A strong reputation, with credible proof of their expertise, is more important than a unique selling point.

Successfully marketing your services, then, is not about USPs; it's about having a genuine, credible, reputation. So how can you build this? By taking part in the community. By contributing fixes, patches, and documentation. By helping newbie users into the community. By speaking, writing and blogging about the knowledge for which you are expert, at community events (with your peers) and at industry events. By being clear about how you your services can help others, who don't have your level of experience or expertise. By being reliably, trustworthy, and professional with your customers - so that they're happy to endorse you.

Perhaps, it can be argued, this "reputation" becomes your unique selling point. However, it's a reputation built on real evidence, not on slick marketing material or finely-tuned elevator pitches.

Give that paper a read - it's well worth it!

Explicitly creating dead letter queues in ActiveMQ using individualDeadLetterStrategy

There are lots of great features in ActiveMQ that are documented only in the code, which is a shame, as it means that it sometimes means developers are "six degrees of google searchin'" away from finding out how to enable the feature.

I came across this one while working for a customer: they're happy with the concept of the default dead letter queue in ActiveMQ, but need to know how configure an individual DLQ for each of their queues. The answer is to configure an 'individualDeadLetterStrategy', and I've updated the ActiveMQ wiki pages to show how to configure this. This change should make it's way through to the Apache ActiveMQ web site overnight.

JMS/JCA Flows in ServiceMix: the wrong level of abstraction for distributed ESB

The ongoing argument over REST versus RPC has created useful debate around programming abstractions, particularly with respect to the use of abstractions in distributed computing. Abstractions are useful in that they remove underlying complexities and allow us to focus on the task at hand. However astractions fail if they hide away important detail that could influence design or implementation decisions. For example, the problem with RPC, some RESTful folks would argue, is that in making remote invocations look like local invocations, RPC facilitates poor design decisions that neglect caching, error handling, or optimization of network traffic. And, they may have a good point here; however, in this blog entry I don't wish to go down the well-beaten REST/RPC track, instead though I want to discuss the use of a particular abstraction in implementing integration solutions with FUSE ESB (Enterprise Apache ServiceMix). I've found that while this abstraction - the JMS/JCA flows - offers exciting possibilities, it is the wrong abstraction, and should be avoided.

I had been pondering for some time about the use of abstractions within the ServiceMix implementation of the JBI Normalized Message Router (NMR). The NMR is used to send messages from one component to another; in ServiceMix, this is implemented using a number of different "flows". Depending on the kind of message exchange (syncronous or asynchronous), quality of service (reliable, transacted), and whether the target service is clustered, the NMR will choose a "flow" to match.

Four flows are provided in ServiceMix - single-threaded (ST) , SEDA, JMS & JCA. Of these, the latter two have interesting and exotic qualities. First, because they're both based on JMS, they are reliable: messages can be persisted as they travel between components. Second, and again, because they are implemented using ActiveMQ JMS queues, this means that if the ServiceMix container is deployed in a cluster, then messages can transparently be delivered across JVM containers. This gives us a truly "distributed ESB".

Many are drawn to this visionary usage of the NMR; however, I strongly believe that clustering & persistence of the NMR is the wrong level of abstraction. First, you are unwittingly exposing your solution to potentially unacceptable performance hit. With a little knowledge of the NMR's message passing semantics, you'll see that even a simple integration solution (like my File -> Pipeline EIP -> transfomer -> JMS) takes more NMR messages than you think: in this case, seven messages are used. Wow, a simple little integration solution using the JMS-flow takes a total of three persisted JMS queues and four temporary queues! And each of those persistant queues, in ActiveMQ, will need it's own thread! In fact, if you've left the default flow settings enabled in ServiceMix, you'll see that we create two queues (and hence, two threads) for each service on the NMR (one for JMS-flow, and another for JCA-flow!). I was curious about the impact of these flows on ServiceMix threading, so played around with the configuration. I found that by simply disabling the JMS & JCA flows in ServiceMix3, I was able to reduce the number of threads on startup by about 50%. Yup, that's right. I halved the number of threads lurking in the JVM.

So, a deeper look shows that this "flow" abstraction is going to consume resources and impact on your latency & throughput. It gets even hairier though: with a flow like the one I detailed above, it's possible that in a clustered environment your message exchange could start out on the file component of machine A, get pipelined by machine B, get transformed back in machine A, and then get send to the JMS provider on machine B. All that remote network traffic when all I ever wanted was to do a little transformation on a file and drop it into a queue.

I had the good fortune to be in town with Guillaume Nodet, Godfather of Servicemix, last week, and talked to him about this; Guillaume is an intelligent and fun guy and if you get a chance to meet him then take it! It turns out that the JMS/JCA flow feature of ServiceMix was there before the NMR was refactored to become JBI-compliant. So, back when it was invented, it wasn't burdened by the additional NMR traffic mandated by the JBI spec. So, these flows made more sense back then, but really don't make so much sense now. You can get everything you want in terms of reliability by using explicit queues as checkpoints in a transactional SEDA architecture: just use the SEDA flow, and, where transaction propagation is required, set the message exchange to be synchronous.

Rather than engage in feature debridement in ServiceMix3, Guillaume has made the right move in choosing to leave these flows in ServiceMix3 but omit them from ServiceMix4. There is talk about reimplementing the JMS flow for ServiceMix4 for "backwards compatability", but I for one would rather see Guillaume invest his and the community's efforts on other more pressing stuff. A really nice feature of ServiceMix4 is that you will be able to transactional propagation on the SEDA flow with asynchronous as well as synchronous messages, so those who invest in the SEDA appraoch now can avail of better thread-performance at the flick of a switch when they move to ServiceMix4.

Both Guillaume and I were agreed in that if you want to introduce clustering, reliability or transactionality into your integration solution, then do so using explicitly named JMS queues. That way, you have full control over when and where your message exchanges are persisted, transacted or clustered. It's easy, and more importantly, it's the Right Level of Abstraction for integration solutions.