Neil's Resume: Walker Interactive (1984-2005)

Company Overview:

Walker Ineractive was an ERP Software company founded by Jeff Walker. When I joined the company it was called Walker Interactive Products, but it changed that to Walker Interactive Systems in 1987. In 2002 it changed name to Elevon, it was bought by SSA in 2005, and then SSA was acquired by Infor in 2007 (?).

When I joined the company, there were four main products:

One of Walker's uniques was the breadth of Operating Systems, TP Monitors and Databases it supported: The Walker solution to multiple OS/TP/DB support was to write application code to a common interface, with an environment specific software layer to translate to the underlying systems software. The environment specific code was written in Assembler and was called The Bridge. While many have espoused such an approach, Walker actually did it and had the interfaces for all the popular database and TP Monitor combinations.

Along with The Bridge, there was also a layer of common application support routines and various system building tools. These tools included:

Ups and Downs

Walker had its ups and downs during the 21 years I worked there. When I joined, the company appeared to be in good health but that was illusory. There were a number of fundamental challenges: These challenges set the stage for the down-sizing and management shake-up in 1985, when Jeff Walker was ousted from day to day control and Bruce Chapman was brought in to turn the company around. There were actually two RIFs (Reduction In Force) in 1985 - the first one was mainly political, but the second one in September or so saw the company pared to the bone, the strategy being to (a) stabilize the product line and (b) focus on customer retention. The Atlanta office I worked out of was closed, as were many other offices. The sales force was reduced to one person (Hi Bob).

Out of the ashes of the old company, a new one arose. David Brownlea from the UK was made president (Dave was at Altergo before joining Walker in the UK). The product was stabilized, customers were appreciated, and an interface was written to DB2. This brought in an era of cautious expansion and we rode the DB2 wave, being one of the few ERP software vendors with a DB2 interface (our first DB2 customer was in 1987). The first few iterations of the DB2 interface were a learning experience, but soon we had a viable and robust offering.

The rise of Client Server, PCs, and the web caused us a bit of grief as the industry went into a period of uncertainty. We responded with an initiative called Redwood, that was a major and fundamental redesign. The idea was to port the applications to a three tiered ASCII based system, but we bit off more than we could chew. Whether the intiative was too large, or it was just badly managed, is a story for another time. The result, though, was a change in management and a change in priorities.

Some major milestones in Walker hstory:

Senior Technical Consultant (1999-2005):

I provided consulting services to Fortune 500 sized companies throughout the US, Canada, Europe, and Asia, billing out at around $160 per hour. My main strength, outside of a deep understanding of the Walker software, was my ability to perform a wide variety of roles. Projects included: Customers included: New Centuries Energy (NCE); Canadian Forest Products; Liberty Mutual; Memphis City Schools; Shopko; Johns Manville; Orange & Rockland; UCLA; SAKS; RHB Bank (in Malaysia); Food Lion; APL; Milliken.

Software Development Manager (1989-1999):

My group was a development SWAT team, responsive to Sales and Marketing. I: Our products were primarily mainframe but they also included middleware based on EDA/SQL and financial reporting tools based on Essbase. My people were primarily employees but I also managed contractors and off-shore resources.

Early adopters of our products included Western Resources, Canadian Forest Products, Central Illinois Public Service, The Smithsonian, Memphis City Schools, Tennessee Valley Authority, and the US Postal Service.

Starting the group

The group's charter was to be responsive to marketing and develop products and features quickly. At the time Walker was bringing out new releases every 18 months, so I developed techniques and methodologies that allowed us to release products outside of the normal release cycle.

Since we were releasing products outside the normal release cycle, we minimised source code changes to the standard applications because that made installation trickier and impacted customer support's ability to test fixes.

Products Brought to Market

The following products were brought to market:

Encumbrance Accounting

Encumbrance Accounting was the first product built by my group and was based on analysis work I did as a consultant for the Smithsonian. Since we didn't know that much about the Encumbrance Accounting requirements, we invited a number of our customers to help us with that. This advisory panel included representatives of the Smithsonian, Tennessee Valley Authority, the US Postal Service, and a couple of others. We quickly found out that when it came to the details, everyone had a different view of the requirements. In the end, Encumbrance Accounting came down to the following: The final solution required interfacing to the Purchase Order, Accounts Payable, and General Ledger systems.

Early adopters of the system included the Smithsonian, Tennessee Valley Authority, and Memphis City Schools.

Expense Reporting

Expense Reporting was an addition to the Accounts Payable system. Each employee would be represented as a vendor in the system, and the Expense Report was basically an invoice with additional data items and additional validation. Enhanced capabilities included processing for mileage, advances, and third party invoices (for example, a company credit card).

Support for the Prompt Payment Act

The Prompt Payment Act was an act of Congress with the objective of making government contracts more appealing to contractors by ensuring they would get paid in a reasonable period of time. There were two objectives to the act. One was that vendors should get paid per the terms of the contract and receive interest in the event of a late payment. The other was that agencies were to report on how successfull they were at paying their bills on time.

When I started this project, we already had most of the Functional Specs built. Even still, I spent many hours reading and re-reading the parts of the Federal Register where the details of how the act should work were published.

The product was primarily an enhancement to the Accounts Payable system. It had to track a lot of different dates, especially when there was a dispute with a vendor. The cheque creation process was heavily modified to accomodate the requirements.

Early adopters of the system included Tennessee Valley Authority and the US Postal Service.

Responsibility Reporting

Responsibility Reporting was a hierarchically based financial reporting solution, initially developed to allow Energy companies to build their FERC (Federal Energy Regulatory Commission) reports. The idea was to develop a reporting system that allowed a specific report to be run automatically against different levels of an organization - for example, run this P&L report for each business unit, or maybe for each product and product line.

There were three parts to the project:

From a performance point of view, we chose to go old school - extract, sort, and print. That is, we made one pass through the General Ledger database to extract data. That file was then sorted. The print process made one pass through the sorted data to produce as many reports as were required.


WC/DSS (Walker Client/Decision Support System) was originally titled WIN (Walker Interactive Networking). The core functionality was provided by Essbase, at the time a dominant force in the emerging OLAP marketplace. It was used to summarize financial data from the General Ledger. The functionality allowed a financial analyst to slice and dice their financial data, drilling down from summary to detail data to explore their company's financial information.

The full solution used InfoPump to extract data from the General Ledger, and Essbase to summarize the data and present it to the businesss users. Our value added was to provide templates that could be used to extract, summarize, and present Walker specific information.

Early adopters of the technology included Western Resources (in Topeka, Kansas).


InfoView was middleware based on the EDA/SQL product from Information Builders. EDA/SQL sat on top of a corporation's databases and provided relation access, as if all the databases and file structures were relational databases. It allowed a customer to join together a VSAM file, a flat file, an IMS database, and a DB2 database as if they were all one relational database.

From Walker's point of view, there were two parts to this product:

  1. The technical challenges of getting it to work seamlessly within the Walker product line
  2. Building the catalog information with details of every file in the Walker system
The latter was our main task, which involved writing programs to create EDA's Master File Definitions based on the copybooks available for each record layout. The system had to have the flexibility to handle customer customizations and to handle new releases of the Walker system.

Analysis Cubes

Analysis Cubes was a mainframe DB2 based decision support system that summarized the raw financial data held in the General Ledger, giving business users the ability to slice and dice that information at various summary or detail levels, including the ability to drill down to the supporting details (an invoice, purchase order, or other source document). It was a feature of the General Ledger and there was both a green screen and a web based front-end.

The core concept of Analysis Cubes was to pre-summarize the data, thus simplifying the process of navigating through the information. The summarization was performed by DB2 for performance reasons, using only three dynamically built SQL statements to summarize each cube.

When we received the go-ahead for the project, there was a prototype solution being delivered by Walker's UK consulting group which required assembler and SQL coding for each cube to be built. We took the basic concept and rebuilt the product from the ground up. Most of the coding was done in-house, but towards the end we used some off-shore resources to add additional functionality.

Senior Technical Consultant (1987-1989):

Customers were a variety of Fortune 500 sized companies throughout the US and Canada. Projects included: Software Installation; Teaching; Designing and coding product enhancements; Migrating customers to new releases.

Customer Support Analyst (1985-1987):

I was brought back and relocated to San Francisco after being laid off when the Atlanta office was closed. My job was to support the Bridge, which was the assembler interfaces to the Databases, TP Monitors, and Operating Systems. I supported the following interfaces:

Product Manager (1984-1985):

Walker had built a number of tools to help it build better on-line systems. Since Walker had used those tools to build it's own applications, the thought was that maybe other companies could use them for their own systems. That thought gave rise to a new division, the Systems Software Division, based in Atlanta. It was tasked with packaging Walker's System Building tools and marketing them as a stand-alone product. I joined the company to become the technical SME (Subject Matter Expert) for the new division.

Shining Moments

In my brief tenure with the Systems Software Division, I: I was let go when the office was closed, but was soon called back to service to fill in the gaps in customer support.