Saturday, February 14, 2015

How do you Measure Application Reuse

IT leaders can set the right policy, effective governance discipline and the comprehensive time and cost estimation in managing application reusability successfully.

Application reusability is a common industry practice, like many other things, it has both upsides and downsides. Although in most cases the upside of reuse out-weights the penalties. But just give a thought to the negatives as well as the positives, in order to measure application reusability via the lenses of efficiency, effectiveness and agility. How do you even try to qualify the ROI for something like reuse (in terms of, faster time to market, faster development times, standardized applications consistent UI etc.)


Governance and technical maturity: Reuse code have multiple aspects: pure code (sub-routines), formal code libraries (generic utilities), web services (standardized business processes), data (master, reference), etc. There are different dynamics at work in each area, and therefore different paths to success. The business value of application reuse is easiest to communicate after educating the business on the different stages of technical maturity, the advantages and costs of each stage. The sooner in the organization's maturity reuse is leveraged, the sooner the organization will be able to be both global and locally flexibly. If you need to increase reuse of application components, that means you have to spend resources in ensuring 1) clearly define the frameworks 2) allow developers to easily search for existing components (to see if they can be reused) and put in some governance to track if it is happening or not. To justify spending resources doing all the above, management would obviously like to see some quantifiable benefits of doing this verses other project with higher ROI.


All fair reasons you want to reuse: While looking to reuse you obviously have to ensure that you don't increasing your collateral in old technologies or business processes that you want to get rid of. Here are the fair reasons you want to reuse:
1). Must be on the technologies that are going to be around for the next few years.
2). Should require limited customization.
3.) User experience should not be sacrificed too much.
4). Decrease the development and/or support costs (as opposed to a new custom solution).
5). Decrease your time to market
6). Standardizes some user experience
7). Leverages common maintenance and standard features


The Cons of Reuse: Reuse is not necessarily good, it carries several penalties that in some cases outweigh the benefits. Reuse happens at many levels, just keep remember that everything has downsides and they should be considered along with the benefits. What are the negatives of reuse?
1) Reuse costs extra. It is very rare that a reusable component is built as cheaply as a bespoke one-off design would be. It will typically have extra flexibility and configuration options included. Every doubling of the number of users  increases complexity by about 30-50%. Increased complexity increases cost of development, testing, configuration and maintenance.
2) Reuse slows things down. Because changes to reusable components have to be acceptable to a wider body of customers, you need some way to get consensus to any change. You need to test the change against all parties requirements to ensure you don't break anything, but that extends the time required. In addition the extra complexity mentioned increases the time to analyze changes and fixes. Reuse tends to be slower. Bespoke code can be highly tuned for performance. Code that must serve the needs of many is harder to tune because what is fast in one context might be slower in another. The reusable component must be acceptable to all.
3) A developer’s arrogance or fear: A factor that can increase the perceived cost of reuse is "developer arrogance"; the belief that custom is better and/or that "I" can do it better. I have been successful in channeling this energy into: "then help us develop a better library, web service, master data entity, etc.". Another factor is the developer's fear of the unknown: if you have never followed a reusable approach it seems inherently risky. In some cases, the developer is incapable of generalizing, most just need to have the way illuminated and they catch on fairly or quickly.


Reuse or not is situational, but through the pros and cons of application reuse analytics, IT leaders can set the right policy, effective governance discipline and the comprehensive time and cost estimation in managing project portfolio successfully.  

0 comments:

Post a Comment