I’ve been following some of The Man in the Doorway‘s posts recently, and directed him to my earlier post discussing the definition-differentiation model. In the comments, TMITD (who works with JP Rangaswami BTW) made a few interesting points, particularly:

Another interesting area is how this analysis can be used against technology that already been built (possibly using the above model) where the definition/differentiation balance has changed (it really only ever changes in one direction) and from that analysis whether we should start throwing away code and replacing with sourced code or components.

but …

that is rarely possible due to differing APIs between the current bespoke component and a now existing sourced component

This got me to thinking some more on the model, and how it could be put to use.
I have revisited it a few times, and at the moment it looks a little more like this:


Rather than having different thresholds for different ways of providing software applications, I see it now more as a continuum along which a business process moves, generally (as TMITD suggests) in the one direction (hopefully shown by the arrowhead) – as time goes by, the “definition” will become more publicly available, more firms will emulate it, more software will be written to support it – and it will usually be an ever-decreasing advantageous “differentiation”. One day you wake up, and it’s part of Oracle, SAP and the lexicon of “best practice” – a hygeine factor in business.

Maybe you can delay it, but it will happen. So, how do you transition from a bespoke solution to an outsourced one? And what do you do next, if you think that bespoke software is (in the diff:def model’s view) a good thing at the edge?

Let’s take them back to front. If you are working with/for/in a firm that only has one bright idea worth supporting with bespoke software, maybe you made the wrong choice. Try finding firm(s) who have bright people who are always churning out good ideas worthy of your development efforts – they won’t necessarily be easy to find, but fortunately it’s a vocation not tied rigidly to physical space, so look a little wider.

Then (and this is in answer to the first question) develop in a service-based manner – the actual deployment mechanism doesn’t matter so much here, as the fact that there is a clearly-defined interface, and the service can be discontinued/replaced by an outsourced one at a later date. If you’re REALLY good, maybe they’ll buy yours!!

Now, I know this sounds a little idealistic, and it certainly describes a best-case (in my view) scenario. You may not find the perfect firm with a pipeline of great new ideas, and you might find yourself doing the maintenance on your ‘bespoke’ software as it crawls up the slope to being replaced for longer than is desired … but you know what you’re looking for. The point about delivering the software functionality as a service stands though – I see that as an imperative (and if you don’t know what I’m talking about then –

1) you’ve possibly started your tour of the blogosphere at the wrong end, and

2) Wikipedia will almost certainly explain it better than I can.

In thinking more about the model, it occurred to me that it might seem a little absolute from my first description. It is meant to be used as a guide in a particular environment, rather than a prescriptive edict that says that only processes which are completely new and undefined can give you a competitive differentiation. The differentiation is relative to your industry and situational.

For instance, for most firms which produce physical goods, distribution is an important function that needs to be done well – but you don’t need to do it yourself. However for someone like FedEx or P & O, distribution is core, and is worth making the effort to not only do well, but find something beyond the current best practice to give a meaningful difference.

I also don’t mean to imply that what for some firms is outsourced, CAN’T be a source of competitive advantage for another firm in the same industry – for smart people there should be opportunities everywhere.

My point IS, however, that if you did find a point of differentiation to your competitors, your best chance of preserving that advantage for longer is to support it with your own software – and if it is within the domain of an installed package, then it is even more important that it be a loosely-coupled/plug-in software-as-a-service delivery method at the ‘edges’ of your packaged software (because you don’t want to be trying to upgrade a modified package – hands up all you others who have broken their heads on that one too!).

That’s enough for one post – back to you for more comment …

5 thoughts on “Def:Diff revisited

  1. Ah, Dennis – you’ve put your finger on the nub of MY problem! I have the suits and they have the cheques, but they’re not spending it on this stuff, unfortunately.

  2. Yeah – nobody said it would be easy 🙂
    I like the ideao of contributing to an “opensource vendor”. The key to opensourcing your own stuff is that you need to be aggressive in how you do it, how you market it – if you have a partner who will do that on your behalf then so much the better. You can opensource stuff fairly easily but to get it taken up by the community needs a lot of hard work .. better to outsource that as well. Maybe set one up yourslef in partnership with your competitors .. who are likley to use the same tool set as you do.

  3. “Before your differentiation ends” – that could be a difficult point to pick, but apart from that a good thought, Malc.
    As for how/who to outsource – why not contribute the code to an opensource “vendor” with a related package (that you may be using anyway)? This would serve a number of purposes – augments the OSS with working modules, still gives you access, enhances your reputation and makes it more difficult to write proprietary interfaces.

  4. I agree with most of this but I feel one needs to be more aggressive with the commoditisation. So rather than:
    Then (and this is in answer to the first question) develop in a service-based manner – the actual deployment mechanism doesn’t matter so much here, as the fact that there is a clearly-defined interface, and the service can be discontinued/replaced by an outsourced one at a later date. If you’re REALLY good, maybe they’ll buy yours!!
    which makes a deal of sense, but I would say
    agresssively outsource your own layers and code before your differentiation ends and define the market for that service with your own outsourced code and APIs
    Now – I am in no way pretending this is tractable. One would probably have to set up a new company to handle this, staffed and PR’ed up.(Even opensource needs to be “sold”).
    One would also have to understand where you were on the def:diff graph with no environment to benchmark against because you would be creating the environment yourself by being the first after you take the decision to outsource.
    None of the above, of course, should allow any engineer to design and build against shit proprietary APIs. Indeed, the more simple, elegant and “does what it says on the tin” your APIs are the more chance of the opensourcing being a success.

Comments are closed.