Smartly "repurposing" the technology - Innovation or misuse?
Lately I have had multiple conversations and discussions on the topic of product selection. In such conversations, again and again I have seen the emphasis on why a product should be used for a given intent because that is what the product vendors have built the product for. Interestingly in one such conversation that I recall, the chief architect wanted to use a product that was meant for complex event processing to actually implement a process management capability. At the same time, there are products actually that do the process flow management that could be used. However, given the requirement of the software capability, both the products can do what is needed to be done. So now question is, in such situation, how appropriate or inappropriate is to use a software (if that meets your requirements) that is not intended to do what you want it to do from product vendor’s perspective.
Straight forward answer just could have been “Don’t misuse the product capability, stick to what the products are designed for”….but is it really that way? How do we approach this situation and make a decision that is not going to lend itself to disaster? That’s when the “repurposing” ideas started taking shape in my mind. In simple terms, repurposing is defining new purpose/usage of the object. In our case, we are talking about inventing/discovering new ‘utility’ of the software. Now, such new utility becomes innovation or misuse will possibly depend on number of factors that we will shortly come to.
Talking about repurposing, history has it that countless number of technology inventions that were originally designed for different purpose and then subsequently they were successfully adopted for a totally different purpose. This is a interesting topic, let me talk about a few of such inventions.
Microwave – apparently the original devices was meant to produce radio signals for radar usage. However it was discovered that such microwaves have capacity to heat certain types of material and thus it was repurposed to bring something that is so common in our life: the microwave oven.
Washing machine - This is the most interesting of all. I discovered it few years ago that a particular business community has adopted washing machines (after little customization) to produce a particular health drink using the sturring capabilities of the machine. Same machine is also adopted to separate out the butter from the cream of milk. Did you ever imagine that?
SMS text messages – these were designed to notify the users of mobile as test from network operators. However, given the simplicity and usefulness of the capability, they were launched as features for mobile services and now they are also being repurposed to operate certain electrical appliances/machinery using the sms capabilities. Amazing!
In the area of information technology itself we have so many variety of examples. Emails being used as draft documentation tools, Microsoft XLS being used as interactive application development tool, iPOD/MP3 players being used as storage disk, computer games (customized of course) are being used to train the business users. And the latest, as I write, tremendous repurposing effort is going on for the social network technologies to be deployed for alternative collaboration capabilities for the businesses.
That was fun side. Let me now take two key example from recent technology areas – BPM and CEP.
From my own experience, there are so many cases I have seen across fortune 2000 global companies where they have actually used the BPM software as a tool to develop applications. Now a purist will take offense (rightfully as one should) on this approach arguing the architectural contamination that such approach brings. And I too will agree on that if the organization actually uses BPM software tool for application development while thinking that they are doing BPM. But it doesn’t end here. I know organizations who have ‘deliberately’, in control of all their sense, to some extent I would say smartly decided to use the BPM tool as the application development platform. Why not? They figured out that BPM software with what it costs, there is far more utility in it to develop custom applications (with of course BPM embedded in that solution) than just using it to create process wireframes. In some of such cases, it took much lesser time for them to develop the apps, was easy to integrate with rest of the ecosystem and has required much lesser technology knowledge (well, it does depend on the product though). So from ROI perspective, such organizations believed that with the sunk cost of licenses (which is significant cost actually), they are able to derive much better value from the product. I think in my mind such approach has a merit if carefully and strategically driven. Another reason also why I’m in favor of such repurposing is that many times product vendors build the product with very narrow purpose to gain the niche market space and mindshare while software actually has capability to do lot more. So it is more of a business marketing from product vendors than the real product fitment issue.
Let me come to next technology product – Complex Event Processing or CEP. There are many products in the market that allows us to model the event, correlate the events, model the event policies etc. Now there is a newly emerging paradigm of ‘management of unstructured and adhoc processes’. These are the processes that are not well-defined and categorically structured, rather, they are dynamic and get defined based on patterns of the events. Sounds similar to CEP? It does a lot in my mind and hence, CEP products are now being experimented to be repurposed as BPM tools to manage the unstructured/adhoc processes given that current BPM suites don’t offer such capabilities largely.
Now coming to important question. What decides if the repurposing is really an innovation or rather a dangerous misuse. In my view 4 key factors that iinfluence this decision will be:
- Interoperability and compatibility of the product (with rest of the eco-system) in the changed environment (due to repurposing) - if the repurposed capability doesn't really fit into the overall eco-system, it doesn't really make the case.
- Future roadmap of the product (sustainability of the utility of the repurposed software based on the changes being made in the product) - it ensures that repurposing is not a short sighted decision that create a disaster in making for future. To large extent its not entirely predicable or reliable since its difficult to figure out the future moves of the product companies. But the its a risk and hence best judgement should be used considering the expected shelf-life of the solution and trends/anticipated changes of the market.
- Cost effectiveness of the product with the repurposed scenario - quite obvious unless someone has to do it for the sake of other milages (read as policitical etc.)
- Unintended consequences of the repurposing - this is interesting. While we could have unintended use of the software but at the same time it calls for due diligence of any unintended consequence that the repurposing could lead to. Such unintended consequence could be TCO impacts in long run, legal consequences of software usage from angle of licensing etc etc.
So that’s my 2.5 cents (0.5 cents for the fun examples) for the product selection. I think we need to experiment little more with the portfolio of software capabilities we have in the market and I’m sure we would be able to create innovative repurpose cases to bring new values from the IT investments.
