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
technlogy 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 ...
