- Formal Resume....
- Further details by company.............
- Roles and Skills......
Neil's Resume: Walker Interactive (1984-2005)
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:
- General Ledger
- Accounts Payable
- Purchase Order
- Inventory Management
(although in the beginnning, IM wasn't strong enough to be sold as a stand-alone product)
One of Walker's uniques was the breadth of Operating Systems, TP Monitors and Databases it supported:
- IMS DB/DC
- DB2 (in 1987)
- IDMS DB/DC
- Adabas & Complete
- Shadow II
- IOSYS, their own home-grown
database file system
- MVS, VSE, and VM/CMS
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:
- Screenbuilder, a screen painter
- Reportbuilder, a report writer
- Transaction Definitions held in a file, which provided a separation of program and screen,
plus allowed new transactions to be build from combinations of other transactions
- A scripting language for building simple transactions
- And various other system building aids
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:
- Product quality was weak (we once shipped blank tapes to meet a deadline)
- All technical decision making was routed through two people, creating a bottleneck and stifling innovation
- The balance sheet was unable to sustain on-going operations
- Products and features that had only been spec'd out were being sold as completed products
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:
- 1969: Company founded
- 1976: First release of Accounts Payable and Purchase Order products
- 1981: First release of the General Ledger product
- 1987: First DB2 customer
- 1990: First Client/Server GUI released
- 1997: First web browser interface released
- 1999: First release with Java functionality
- 2002: Name change to Elevon
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:
- Completing high level design for a Commerce One XML interface to Walker
- Installing mainframe software, including DBA and Systems Programming tasks
- Migrating customers to new releases, including forward fitting customizations in Cobol, Assembler, SQL,
and Walker tools, and including support for production cut-over
- A memorable project was interfacing an energy company's Walker system
with a Trading Consortium's trading system
- Customizing and extending the Walker system using Walker tools and coding in Cobol, Assembler, and SQL
- Teaching various classes:
- Using and customizing the Walker system
- Setting up a web front-end to the Walker system, including teaching basic HTML
- Setting up mainframe services for use by Web based clients
(Using Walker's SOA - Services Oriented Architecture)
- Providing pre-sales support
(building demo systems to a prospectís requirements and acting as a technical resource on sales calls)
- Providing technical support for a Cobol to Java conversion using PerCobol
- Installing, tuning, and benchmarking the Walker system at IBM in Poughkeepsie,
achieving 183 transactions per second on a G4 processor
- Onsite support for Essbase based (multi-dimensional database) financial applications
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:
- Started the group and pioneered methodologies that enabled a 6 month software
development life cycle, compared to the 18 month life cycle of the full Walker product line
- Brought seven products and features to market
- Represented Walker at User Group meetings
- Pioneered the use and distribution of 3rd Party Software as a VAR
- Was a hands-on manager whose roles included Project Manager, Business Analyst,
Technical Coder, Technical Writer, QA, and Instructor.
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 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:
- Tracking spending against a fund
- Reserving money when an item is either requisitioned or ordered
- Detecting an Insufficient Funds condition at the earliest possible opportunity
- Reporting the current status of a fund, including any outstanding Requisitions or Purchase Orders
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 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 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:
- Building hierarchies based on the General Ledger structure
(for example, a reporting structure or a product line-up
- Extracting data from the GL
- Formatting the final reports
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
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:
- The technical challenges of getting it to work seamlessly within the Walker product line
- 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 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:
- OS: MVS; VSE; VM/CMS
- DB: VSAM; IDMS; Adabas; IMS/DB
- TP: CICS; Shadow II; IMS/DC; IDMS/DC; Complete
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.
In my brief tenure with the Systems Software Division, I:
- Was the technical lead on a project that installed and customized RD/Share as
Walker's Change Management System
- Performed a complete audit of Walker's System Building Tools and produced a document
detailing what the tools actually did (as opposed to what management said they did)
- Completed a product called Transport/R, a tightly integrated micro-mainframe link that
allowed data transfer between a PC and the Walker databases
I was let go when the office was closed, but was soon called back to service to fill in the gaps
in customer support.