Re-engineering the way we work

"What if the business is apprehensive to re-engineer the current system? Are there other opportunities for pursuing a re-engineering initiative?"

This is how my conversation with the Development Area Manager started today.

From the initial discussion we had on re-engineering a few weeks back, he went to our business partners and pitch the idea to them. The initial reaction we received was a bit lukewarm. Without the support of the business partners, we are looking for other ways to push the re-engineering agenda.


Innovate how we operate.

Rather than focusing on the client system, we can use the same re-engineering principles on how we work. The approaches used in systems re-engineering can be applied in innovations for application delivery and maintenance.

To do this, we will need to review the processes involved in application development and maintenance. By revisiting each phase on the software development life cycle, we identify the tasks we can re-engineer. To help us in our analysis, I have identified the following categories that we can focus on.

Recurring, repetitive and manual intensive tasks. From experience, most proposals will fall in this category. Not only are these are easy to identify, most developers will be drowning you with proposals as these are tasks we hate doing. It is good to work on these category first (especially since we are just starting to build the skills of our team) as the re-engineering activities required are simpler.

The re-engineering approach for these type of tasks requires a combination of standardisation and automation. First we need to establish the series of steps required to accomplish the task. From these steps we can determine which of them (if not all) we can automate through mainframe facilities like ISPF Edit Macros and ISPF Services.

Tasks with wait times or requires monitoring. Monitoring activities (like those by Production Support staff) are essential to ensure that exceptions are addressed promptly. Although important, the time spent waiting are opportunities better spent on activities that adds more value. With this, it is important that we find other ways of monitoring aside from
having somebody continuously looking at a computer screen until an event happens.

For monitoring non-critical activities, we can avoid manually monitoring them through the use of automated notification - the simplest of which is the email notification through the SMTP (Simple Mail Transfer Protocol) service. We can consider modifying a non-critical job to send the error details to the appropriate group if exceptions are encountered.

SMTP can also be used for automated report distribution. Rather than have someone kick off a process to create and email a report, we can replace this with a mainframe job to be triggered when the input file is created to process the file for us.

Tasks where human decisions are made. I am not suggesting that we replace all of the intelligent decision making activities with an automated process as this is not possible. In situations where the decision making is complex, we can help the decision maker by ensuring that all the information he needs are easily accessible. The benefit with this is that we don't change the way people work, we just eliminate the administrative part and let them focus on the parts of their job that adds value.

Tasks requiring system downtime. The activities that fall in this category overlaps with the other previous categories. We need to further categorised them into this type because of their impact to the business. System downtime (whether the downtime is for software migration or data/error recovery during production support) means there are no business activities in our system. Business opportunities are lost on periods when our system is inaccessible. With this, we must give special attention to activities falling in this category.


Pushing re-engineering forward.

There is a good incentive to devote the time it takes to re-engineer our development processes. If done right, these re-engineering successes will be the best marketing tool in selling the re-engineering agenda to our business partners. The tangible results are more powerful than any PowerPoint presentation we can muster. This will open up a wider horizon of opportunities for us in the future.

Succeeding through incremental re-engineering

If it ain't broke, don't fix it!

It is the most common argument against a re-engineering agenda. It is argued that although the current system maybe slow and inefficient, people were so dependent on them for so long that migrating to an untested system is unthinkable.

Today, I heard this again and then some more.

I was invited by our Development Area Manager to have coffee with him. This gave us the chance to discuss how we can pursue an effective re-engineering initiative. I was asked based on the recommendation of his colleague (another Development Area Manger for another business) who worked with me in the past in pursuing a re-engineering agenda together.

In this conversation, the primary concern raised was on the area of risk. Previous experience shows that re-engineering has a high degree of failure and probability of introducing errors to the system. The larger the system the higher the degree of risk one has to take.

There was also the concern of the perceived high costs related to re-engineering. Most re-engineering pursuits in the past had been expensive - driven by much hyped tools and processes. There is additional associated costs on supporting the new system until it stabilises (which can take longer that what management are willing to accept).

I understand these concerns as I have witnessed these issues manifesting while pursuing re-engineering in the past. But these concerns are driven by one factor - size. With this in mind, these concerns can be managed by implementing re-engineering initiatives in smaller chunks.

The incremental re-engineering framework, also known as evolutionary re-engineering, is the process we have followed in the past. Through incremental opportunistic approach, both the risk and cost concerns can be addressed.

Focusing on a smaller part of the system provides better error recovery. Given the smaller size, errors are easier to investigate and fix. If a major issue is found, the re-engineered component can be backed out with less disruption to the system.

Given the size of some re-engineering projects, development costs can sometimes be absorbed by current projects. We have demonstrated this through the new batch setup utility we created last July. We used the the first week allotted to the branch setup if done manually to create this utility. Not only did we complete the setup before the two week deadline, we now have a utility that drastically cut turnaround time for every new branch we setup.

For managers, incremental re-engineering offers other advantages. The incremental approach provides increased flexibility to address changing priorities and strategy. Fewer resources are committed to re-engineering projects in shorter period of time. This allows managers to re-align resources quickly if required.

There is also a high degree of user acceptance. For some of these re-engineering initiatives, the changes are least disruptive, if not transparent to the user. In other instances, these focused projects provides immediate and tangible benefits (improved response time, simplified process, less errors) that are quickly noticed by users.

With these advantages, incremental re-engineering projects provides a better chance of success. These advantages together with the successful project implementations will make it easier to justify incremental re-engineering projects to management.