April '09 - present

Tools Development

In dealing with the recession, IBM conducted a "resource action" to reduce the headcount of the support organization. Part and parcel with this decision came the need to reconsider how they did business to develop new efficiencies to maintain the same level of quality user support expected from IBM. Support identified ten initiatives that they needed to undertake to achieve this. Number 1 was to improve their tooling.

Support use a "green screen" application as the core for tracking customer incidents. Of course, very few support engineers actually use the green screen application. Most use various frontend applications built around it. And, since the back end application really only supports punch-card style 72 character wide narrative text fields, there are a plethora of tools needed to deal with bitmaps, log files, and all the modern trappings of support.

The tool that has been used the most was something that looked like it was developed with VB to be cutting edge for Windows 95. It includes lots of plain text and lots of windows. It is very cryptic, with few linkages to the halo of applications. It is as quirky as you might expect 10 year old software to be. Writing a new front end would require a system that was good at on-the-glass compositing of diverse applications together into one, unified, working environment. This was a job for Lotus Notes Composite Applications.

When I took my BPTE job, I also ended up transferring into the Support organization. When support looked to build the tool they needed, they decided to use the people they had in their own department they could spare. However, not being a development organization they only had a handful of people with coding skills. After six weeks of trying they determined that these people would not be enough. They spread their net wider and decided to move me from technical enablement to work on this critical priority tool.

This assignment allowed me to combine my history of tools development with my expertise of Notes composite applications. Within two weeks I had a build process, a deployment strategy, and was able to roll out a prototype made up of the pieces that they had already managed to produce or convert. This gave management the assurance that the team was on track, but was just the start of the work.

Over the next several months I laid down an architecture and framework that gave us a consistent look and feel to present the feature set we were developing. Usability is important for many reasons. First of all the extreme lack of usability in the preceding tool hampered productivity. Focusing on usability gave a quick way of making rapid gains in productivity. The traditionally high turnover of staff also made having a tool that was quick to learn beneficial. And, since the development team was small, a high usability factor reduced the need for documentation and training materials.

Although targeted specifically for support engineers, there is a whole ecosystem that revolves around the support process. Since composite applications are built of configurable components, it is possible — if those components are developed right — to project those components in different configurations targeted at different roles. So part of the architectural design was around making the infrastructure flexible and extendable, so that different feature sets could be deployed, and unanticipated functions extended without need to redevelop or redesign. For virtually no more cost a tool was developed that would not only aid support engineers in doing their job, but also developers that have to consult on incidents, customer account managers who have to deal with collections of incidents, and many other roles.