CIO Dashboard » 13 Barriers to Reuse

13 Barriers to Reuse

post by Chris Curran on June 22, 2010

MIT Center for Information Systems Research held its 2010 summer session last week. Wednesday’s session covered innovation and agility - as part of the agility discussion CISR shared some great research on reuse. Peter Weill, the Center’s chairman led an interactive discussion to uncover the reasons that companies don’t reuse. For the purposes of this discussion, reuse was defined as using something that already exists - to include code reuse, processes, data, designs, whatever.

Interestingly, few if any of the barriers discussed were technology related. Rather, they were about the behaviors, politics and corporate cultures.

See if this list rings true for you and add any thoughts or ones I missed by leaving me a comment!

Barriers to Design, Process and Code Reuse

No one will pay for the initial development of a shared component
The component was not initially designed to be reused - no broad requirements consideration, poor interfaces, lack of documentation
Lack of recognition for the original builders
No one willing to support it for other users
Unclear how to find, use, customize, extend the reusable code
Unwilling to accept less that 100% functional fit
Belief that a new thing is always better
Belief that my job is to create things and that reusing code reduces my value
Reuse reduces my ability to be innovative
Unwilling to give up total control of the component’s design, building and operation
Lack of incentives to create or use reusable code, designs, etc.
Organizational structures don’t motivate employees to talk, share and innovate outside of their business areas
An SOA program does not drive reuse itself

MIT’s research found that firms with higher levels of reuse of their digital assets grow faster and have lower costs. Faster growth makes sense to me. However, lower costs from reuse is a tricky one. In research Diamond did on SOA adoption (also with CISR interestingly), companies reported little if any cost savings from their SOA investments. Instead, they reported the most benefits in bringing new and enhanced business capabilities to market faster.

cc licensed flickr photo shared by timtak

http://www.obviousideas.com Sainath Nagarajan

Very interesting post. Reuse requires a fundamental long-term orientation and a comfort level with going rummaging through the attic to find pieces that can fit together.

From a human angle, I am curious whether an innate creationist attitude and birthing excitement comes in the way. From an organization design and incentive perspective, some of the tactical time-keeping methods might also be a barrier to reuse. After all, ‘x’ hours is more easily measurable and justifiable for net-new development, rather than for reuse.

Given that the economics seem to indicate a longer-term payoff, with an initial learning curve, reuse should be on a long-term agenda … and not measured through IT cost reduction metrics that get rewarded/reprimanded on a quarterly scorecard.

Interestingly, the moment attention shifts towards the business, the benefits and metrics are all in favor of reuse. Should we have a call for action for CIO organizations to fundamentally re-examine their own organizational design? Possibly, have a couple of CIO’s lead the charge … and let other comparable CIOs reuse the same. Neat, eh?

Best,
Sainath
- Richard
  
  …its also a path of least resitance. Its always easier to play music you’ve written yourself rather than learning someone elses. (Though this could just be the other side of ‘Lack or incentives’ ).
http://www.obviousideas.com Sainath Nagarajan

Very interesting post. Reuse requires a fundamental long-term orientation and a comfort level with going rummaging through the attic to find pieces that can fit together.

From a human angle, I am curious whether an innate creationist attitude and birthing excitement comes in the way. From an organization design and incentive perspective, some of the tactical time-keeping methods might also be a barrier to reuse. After all, ‘x’ hours is more easily measurable and justifiable for net-new development, rather than for reuse.

Given that the economics seem to indicate a longer-term payoff, with an initial learning curve, reuse should be on a long-term agenda … and not measured through IT cost reduction metrics that get rewarded/reprimanded on a quarterly scorecard.

Interestingly, the moment attention shifts towards the business, the benefits and metrics are all in favor of reuse. Should we have a call for action for CIO organizations to fundamentally re-examine their own organizational design? Possibly, have a couple of CIO’s lead the charge … and let other comparable CIOs reuse the same. Neat, eh?

Best,
Sainath
- Richard
  
  …its also a path of least resitance. Its always easier to play music you’ve written yourself rather than learning someone elses. (Though this could just be the other side of ‘Lack or incentives’ ).
Mark Brady

First, if there’s not a highly enlightened upper management already in place, it takes highly confident and gutsy front-line managers to defend schedules that leave room to develop components to a format conducive to reuse. SOA/Object Oriented are both concepts to promote reuseability but as pointed out already, they don’t ensure that happens. They are, in fact, more expensive initially to build. You have to defend that, and push others to reuse the elements you’ve built to be reusable.
Mark Brady

First, if there’s not a highly enlightened upper management already in place, it takes highly confident and gutsy front-line managers to defend schedules that leave room to develop components to a format conducive to reuse. SOA/Object Oriented are both concepts to promote reuseability but as pointed out already, they don’t ensure that happens. They are, in fact, more expensive initially to build. You have to defend that, and push others to reuse the elements you’ve built to be reusable.