Monday, May 11, 2009

Key aspects for successful implementation of Reusability in IT organization

CEO’s of most of the IT companies and CIO’s of other industries have identified software reusability and knowledge management as one of the prime and important initiative to achieve operational excellence. This is because CEO/CIO's are aware of substantial benefit to bottom line in addition to other benefits like quality, time and standardization.
Although some companies are struggling from last few years to reap the benefits while some have successfully implemented it and matured. I would discuss following few areas which may be helpful in achieving software reusability at organizational level.

1) Resource Rotation
2) Organizational Structure
3) Reusability areas
4) Governance

1. Resource Rotation

Few years back, I was discussing Software Reusability issue with one of my friend from manufacturing industry. He has given me hint by way of saying that in manufacturing industry they use same resources (assembly line, machines, tools etc) for variation of products. I equated manufacturing resource with IT resources i.e. human resources and tried it.

So companies can achieve fair amount of reusability by just rotating the resources (reuse the brains :)) between different projects. Please note that these resources should essentially be knowledge resources e.g. Architects, Business Analyst etc rather than developer resources. Please note that measuring this type of reusability would be challenging unless very good measurement mechanism in place. This concern can be addressed by implementing point (2) below to a larger extent.

2. Organizational Structure

This plays important and vital role. I have seen many companies either during the initiation of reusability initiative or because not able to show any progress for several years create a separate team/department. This may be short term solution hence I do not recommend it.

My recommendation is to identify knowledge community (not operational) within your company in functional, technical and process domain. And bring them under one virtual/physical group/team at organizational or line of business level e.g. Architect, Testing, Technical/Functional domain expert. The resources from this team must be working on different projects at different point in time or working on multiple projects at same point in time. This team should manage reusability in respective area. Additionally, you may want to add reusability and knowledge management as key results area in appraisal process.

3. Reusability Areas

Many laggard companies have given too much stress on code reusability and failed to achieve fair amount of reusability. I am not saying that you can not achieve code reusability but most of the code reusability benefits go to developer who uses that time for long tea breaks and personal emails….ha ha ha.

Also now a day’s developer has internet and outside collaboration to help with it. Don’t try to snatch it, you will basically fail.


Therefore the areas that you should target are –

  1. Standardization in various areas as much as possible e.g. Reference Architecture, Business domain processes and solutions etc.
  2. Focus on identifying reusability in requirements, architecture and design so subsequent artifacts i.e. code would automatically be reusable. Target at higher level not at code level.
  3. Domain Level Reusability. You may refer to http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.103.934

You may want to refer to Reusable Asset Specification for various elements and sections of reusable assets. http://www.omg.org/technology/documents/formal/ras.htm


4. Governance

Last, but not the least. I have seen some cases where reusable framework gets developed, deployed in 8-10 applications, appreciated by customer because of the speed of deployment and cost factor but after some time problem in framework comes to surface. Eventually you have to fix all the applications where framework was deployed. The cost of fixing might be higher compared to the benefits that you have passed to your customer. You might curse yourself that why I have given this value addition to my customer? :) . Hence it is essential that every reusable artifact or knowledge document should be authorized and approved by competent person within organization. Please do not try to substitute person with guidelines and checklist, you may be driving towards failure.

In above sections, I have discussed the areas which help in reusability initiative.

At the same time, I would like to caution couple of predominant areas which result in disappointment in software reusability initiative -


· Many companies’ experiments at one level i.e. process only. But it is like having process without heart and intelligence and end result would be struggle. So good/excellent people are important ingredient.
· Too much importance in having repository and is considered at pre-requisite. Hence lot of initial time and money is spent on it. Repository is important but surly not pre-requisite. You can live without it for some time.

So It is essential that CEO/CIO’s sould look at implementing reusability initiative considering –

  1. Holistic approach rather than addressing above different areas in phased or partial manner and
  2. Not giving too much importance to process that does not have heart and intelligence

2 comments:

  1. Nice write up. A few thoughts to ponder -

    Reusability, IMO is usually of the underlying 'Working Code' because it represents functionality and is 'high value' output. I can see your point of developers taking tea breaks ;-). But No code is better than writing buggy code. Note that 'Working Code' brings with it the quality of having passed tests (hopefully it was tested).


    Reuse of specifications, requirements, architecture, domain, business processes have their own drawbacks - a) It requires that the problem statement is the same b) The analyst/architect needs to be the same, because at the end of the day everyone has their own style and c)IPR issues. d) Finally, they don't save much time as they cannot ensure defect free software.

    IMO, if you spot reusable specs, you should package them as reusable component


    On the point of sharing architecture / design strategy across projects, it is always safe to do Copy-Paste reuse so that you can change it at will for the one project where the defect is identified. Of course, you should flag it as a 'potential future defect' for other projects where the same architecture has been used. However I will defer the fix until the customer or the QA finds it.

    Last but not the least - Reuse comes from heart and not from brain. An architect / designer / lead or for that matter even a developer can reuse by simply asking the right questions at the right time.

    ReplyDelete
  2. Good post!!

    I would like to emphasize the need for establishing a culture of sharing in the organization for successful reuse. Large consulting organizations bring substantial value by providing a few consultants at the site, but huge network of people with varied experience backing those at customer's location. I am yet to see that culture in Indian IT organizations. It looks like availability of technology is further damaging this culture of camaraderie as people are more comfortable with software based repositories than phone calls and meetings.

    ReplyDelete