You are currently on IBM Systems Media’s archival website. Click here to view our new website.

Bookmark and Share

Recent Posts

IT Change and Rework

May 14, 2018

In this post, I concentrate on the times when rework is needed. It could be to fix something that was not done correctly or to make a modification to an existing solution to enhance its usefulness. As you know, rework is not always so black and white, fix or enhancement. In the first post in this series, I asked, “Is there a model that will help us analyze and begin to address difficult obstacles regarding needed change, expansion of method or complexity?” The model I proposed involved three Rs: renew, refresh and rework. Previously, I discussed IT change and renew and a focus on refresh. Rework has a cost and project managers have strategies to avoid it. Rework that adds new functionality is often labeled as a programming enhancement or simply new features, but it inevitability results in rework of business functions.
The Cost of Rework
Many of us have experienced the need for rework in our professional work lives. I remember a project where the application developers decided to secure the data by encrypting every data stream that went to and from the display (page in a web browser). This was easy to do so they did it as compared to securing specific functions or data elements.  
The problem with this approach was that when the transaction volume increased, the encryption/decryption process took a lot of processing cycles and the performance of the application degraded. We discovered the security bottleneck during stress testing where we employed automated testing tools and systematically bumped up the transaction rates. 
Fortunately, the solution we chose involved offloading the encryption/decryption process to hardware-based security cards and the problems literally went away. Of course, we had to buy the hardware and pay to have them installed and configured and the re-running of the stress tests. I wrote about hardware-based security called CryptoCards recently in one of my posts.
Project Management and Rework
There is a lot that is written and discussed about tactics to avoid rework in IT projects. If you are an IT practitioner and you are interested in a quick read, “Minimize Rework as Part of Your Quality Management Process”  is a good example. If you have the interest in a more comprehensive view of the topic, please look at “Strategies to Reduce Rework in Software Development on an Organisation in Mauritius as it’s unusually detailed in its listing and discussion of alternatives to deal with the challenge of rework. 
Rework as a Programming Enhancement
Another way to examine rework is to look at in in the context of a programming enhancement. This rework is not the result of a quality problem but rather a technology change. Consider user interface modernization. 

The user interface has changed from monochrome, non-programmable displays to web interfaces and now to mobile devices. Many techniques have been developed to use long-standing outputs in new ways. An example of interface modernization software involving outputs originally targeted for 3270 devices is the CICS 3270 Bridge, a tool used to web-enable a web-unaware legacy IBM CICS application. This is a smart and supported way to get 3270 applications on the web.
Also consider IBM Rational Host Access Transformation Services, which makes it possible to display outputs from CICS applications on a smartphone with no changes required to the existing application. This is a low-risk approach that increases user productivity and satisfaction while enabling the re-use of proven business logic in new mobile applications.
Rework Reconsidered   
Rework is a term in IT that implies that there is a problem with the quality system. This is true in construction and manufacturing as well. Rework can also be used in a different context—reworking the application or its interface or its data repository to perform differently by embracing newer approaches and technology. 

Posted May 14, 2018| Permalink