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

CIO's Organizational Challenges Changing Portal Strategy to Widget/Gadget?

Few years back companies have started implementing Portal solution using Portal products. These Portal products were mainly from leading vendors like IBM, Oracle, BEA etc. Sales people from these companies have done extraordinary job by convincing CIO’s the benefits of implementing Portal products, never the less they applied shopping mall analogy to it. Also they have associated enterprise vision with this product because of licensing price, feature set and need of high back end horse power.

Some how this enterprise vision is not linked with company readiness, governance and existing IT investment of companies. Probably this is the reason these important criteria’s were given high importance during SOA implementations, which came in subsequent IT wave. Now a day, you may see these as being Portal and SOA service offerings for IT services companies.

Some of the objectives that CIO’s set for going with Portal products are –

1) Consolidation of web sites
2) Improvement in staff productivity by way of self service and reducing information glut
Off the shelf available features
3) Collaboration capabilities

But because of some organizational dynamics enterprise portals are not able to scale up to real enterprise level hence reducing ROI in the process -

1. Most of the above objectives are linked with softer benefits except for first which translates in real hard benefit. This makes difficult to sell portals to business user. Hence internal users see portal implementation as IT initiative rather than business initiative, except in situations where it is external facing.

2. CIO’s of big and medium organization have different priorities to these objectives.
But I would see these objectives are mostly pain areas of bigger company CIO’s than medium organization. This is because typically bigger companies have grown, build lot of disparate web sites/application and made IT investments in content mgmt, search, security, user directory store etc. So these companies are left with two options,

1. Use portal off the shelf features
2. Integrate with existing products/solutions
First option challenges portal capability Vs explicit technology products. Portal being generic product does not match feature set of specific products. But main problem while evaluating portal products is evaluators do not compare feature set that are needed for their need rather they try to compare best available feature by specific products. Eventually these companies do not use content mgmt, search, security etc features of portal but integrate with existing technology stack thus increasing total cost of ownership and reducing ROI.

3. One can say that it is governance issue which CIO’s/Portal leader have to address/decide. But as per management discipline CIO needs to handle these initiatives in democratic way, which means CIO needs to take application owners with them. While application owners are not very sure how Portal is going to impact their current status and job profile. In this process, they make sure to convince the management by saying that they would like to see first version of portal release and take a decision.

Also second argument that I have seen is about timelines and who will pay for migrating to portal, Would it be application owner or portal leader? Since Portal implementation is phase wise implementation with 1st phase typically takes some where 12 to 18 months of rollout (considering infrastructure setup, integration, SDLC etc). This typically means that during this process application owner’s budget for 2 years is spent on enhancing existing app or creating apps away from portal than migrating to portal. In this long process efforts that are spent on portal initiatives are diluted.

4. End users ask for Yahoo or Google like portal capabilities for usage within the enterprise

Apart from above strategic issues that CIO’s faced, Portal implementation also comes with technical challenges as below –

· Portlet specification in lasy few years is matured from vendor specific API’s to JSR 168 to JSR 268 which resulted CIO’s spending on migration activities
· Limited real estate available on Portal pages for portlets
· Portal pages can not be bookmarked using browser feature of “Favorite”, This is the way end users are accustom rather than forcing them to use Portlet for book marking.
· Rigid Personalization/Customization requirements leads to increasing horse power at back end , which eventually results in buying more portal licenses
Etc.

Over a period of time above issues resulted in more down to earth and realistic Portal scenarios

· End users able to see summary information/data in small window while they can go to individual application for more details. This is more realistic approach rather than trying to consolidate “N” no of application within Portal framework
· Quick time for implementation
· Substantially reducing horse power requirement at server side which means reducing server cost as well as licensing cost
· Limiting Personalization/customization requirement rather than asking for Yahoo or Google like capabilities/scalabilities from Portal products

These scenarios have resulted in widget/gadget alternative as best option. Although widget/gadget was present much before portlet specification, ad banners etc are widgets only. However, now there is a considerable interest in using these within the enterprises for more sophisticated portal like applications.
You will see implementation of this approach at places like e.g. http://www.netvibes.com/, http://www.igoogle.com etc.

Even lot of portal vendors are providing widget/gadget capability within Portal, some of them are providing direct integration with Google portal as well. Surely it means that Portal vendors have realized the benefits and are incorporating these feature set under Portal umbrella quickly, although those have now tagged under web2.0 bucket.

There are few open source frameworks available which can get you up to the speed quickly to build light weight portals. These light weight portals addresses pain areas typically faced with Portal products -

· Provides “inbox” type of functionality on portal, while users can go to respective application to see more details
· Quick and low cost solution
· Does not need high horse power at back end
· Personalization/Customization needs are addressed using client side persistence mechanisms which is resulting in reducing server side load hence hardware requirements

Apart from above, it has added advantage in terms of supporting Web 2.0 capabilities like -

· Mashing up at client side using light weight technologies based on Web Oriented Architecture (WOA) like REST, RSS etc.
· This light weight technologies gives flexibility in integrating with different languages and platforms
· Client side integration between Widgets

So IT community is left with one argument that Widget/Gadget is not backed with any industry standard while Portlet specification is backed with industry standard like JSR 268. But in last few years, I have seen customer’s spending lot of efforts in migrating from one portal version to another, one portlet specification to another etc. This may be because Portals products are not very matured but this is not a convincing answer to business users.

Look forward for my next article on different capabilities available in widget/gadget frameworks.