Archive for the ‘Process Improvement’ Category

Reverse Engineering

Tuesday, July 10th, 2012

I support several units outside of the Enterprise Data Warehouse to retrieve, process, and export information. Most of this work is done using straight PL/SQL (Oracle’s transactional SQL language). However there are quite a few processes on a platform that we no longer want to support. These processes have a minimum (and I do mean minimum) amount of architectural documentation. This leaves me with the unenviable position of having to reverse engineer these processes and draw up a plan to convert them to a new platform.

Reverse Engineering – The process of discovering the technological principles of a device, object, or system through analysis of its structure, function, and operation.

Just to be clear: The only reason this is necessary is that the original architectural documentation was a) lost, or b) never completed. If the person who originally created the process or someone who understands the process was available to write the architectural documentation, reverse engineering would not be necessary. This, however, is not the case I found myself in.

So…How do you reverse engineer something? Here are the steps I’m using:

  • Get access to the current system.
  • Use current system to create a sandbox area.
    • If a sandbox already exists, ensure that the sandbox has the most up-to-date source code from the production environment.
  • Familiarize yourself with the existing platform: You need just enough knowledge to navigate the environment and read the processes. You don’t need to program it.
  • Start at a very high level and work your way down to the details. Each level that is delved into gives insight and clarity to the next. During this iterative process create the following documents:
    • Diagram of the major items. (These items will get smaller and more detailed the further down the iterative path you get.)
    • Description of the major items.
    • Listing of item’s code elements and locations.
    • Listing of major business rules.
    • Any other information that clarifies the system.
  • Analyze documentation and look for areas for efficiency gains and process streamlining. Modify documentation where appropriate.

Yeah…This is boring and tedious and VERY TIME CONSUMING. Example: My current documentation for the DMExpress jobs I’ve targeted for conversion is just north of 140 pages! Think of it…how much is it costing the company when this type of thing happens?

What it is not is a waste of time. Once completed I can sit down with a group of developers and break down this documentation into Agile stories ready for development. And this is exactly what I plan on doing.

I will return to my regular subjects shortly.

Battlespace Management

Monday, July 9th, 2012

We’ve all been there: A project that has gone south and needs to be put back on track quickly. Resources get thrown into the breach to bolster customer and management confidence. When this situation occurs the manager dealing with the issue can get myopic pretty quickly. How can he do anything but focus like a laser on the one thing that everyone is looking at?

But focus comes at a cost. Other issues can quickly rise out of the turmoil and out flank a manager’s ability to effectively see and deal with it. Some of the available resources do not get fully utilized. There is dead space in the feedback loop. This is where Battlespace Management comes into play:

Battlespace Management (BM) – The adaptive means and measures that enable the dynamic synchronization of activities and resources to provide the desired outcome. BM has always been important but the nature of modern operations requires ever lower levels of command to plan and execute increasingly complex BM.

Yes, it is a military definition but can easily translate to business. In fact many consulting firms use military comparisons regularly. Whole books are written on the subject.

Battlespace Management has four main principles:

  • Universal Application – BM is applied at all levels, the only difference being the means and measures. All applied activities require coordination, synchronization and prioritization.
    • Strategic Management – Focuses on resources acquisition and management.
    • Tactical Management – Focuses on resource assignment and task measurement.
  • Interaction – Resources interact; therefore activities will (eventually) impact each other.
  • Coordination and Control – As resources interact, control must be asserted to maximize benefit and minimize interruptions.
  • Collaboration – Seldom can activities remain compartmentalized. Collaboration occurs both up and down the command chain, as well as across environmental boundaries.

So how could this understanding benefit an IT unit?

  • Standard Operating Procedures: Clear cut procedures that exist in a process improvement environment that allows any member of a team to easily initiate required work.
  • Task Integration vs. Responsibility Silos: Each member of a team should be familiar (but maybe not an expert) with all aspects of a unit’s area or responsibility.
  • Liaisons: Have members of the team assigned to interact with support units. These liaisons are used to reduce the ‘friction’ that can naturally occur when coordinating tasks and resources w/o the need for supervisorial involvement.
  • Training and Preparation: Each member should be competent in all platforms the unit operates in and a training regime should exist to support this.

If a unit followed these ideas it would be a lot harder to be surprised (flanked) by new developments within their area of responsibility. Has anybody seen a related case-study in one of their MBA classes?

“Technical skill is mastery of complexity, while creativity is mastery of simplicity” – Erik Christopher Zeeman

Tuesday, July 3rd, 2012

In the past I’ve been called technical…Usually in the phrase, “Look, I don’t want you to get to technical in this meeting.” Heck, if I didn’t know any better I would think that was an insult.

But I don’t think I’m that technical. There are many more people a lot more technical than I. I think of myself as procedural….as in, “A standard procedure could remove the complexity of what we are trying to do and make it simpler…and more efficient!”

To wit the situation I’ve seen with turns in the Enterprise Data Warehouse: They are complex…very complex with many rules and exceptions. At least that is how it appears. And, in general, appearance (perception) is reality. This is further complicated by having each developer do their own turn requests, which in turn is complicated by the turnover, especially with the contracted/offshored resources.

So what is the cost of all this complexity?

  • Miscommunications
  • Delays
  • Defects
  • Rework/Resubmissions

It’s like throwing sand in a transfer case! So what is the answer? My proposed solution would be twofold:

  1. Create a living document that consolidates all the turn request processes/knowledge/lessons learned into a single, cohesive standard operating procedure.
    1. Create a logic-branched procedure so that someone could literally ‘walk through’ the process…step by step.
    2. Cover all aspects of a turn: Sign-offs, security requests, document transfers, code file staging, job templates, etc.
    3. Create examples for the most common cases.
  2. Have a turn Subject Matter Expert (and a backup) who is responsible for all turns within a unit.
    1. They would serve as the liaison between the DBA group and the unit doing the work.
    2. They would advise/facilitate all turns.
    3. They would provide quality control and feedback for the procedure outlined above.
    4. They would automate what pieces of the process that can be automated.

And the best part? This is not theory. This is how my old unit operates day in and day out; regular turn or emergency turn. It works, it works well, and has allowed the unit to split out some of their resources to work on other projects (like Mobile Computing!). Gotta love simplicity!