Kraft General Foods

At Kraft General Foods, I was brought on board for a project to create a new system for determining optimal food formulations and production schedules using updated database, network, and user interface technologies. The business operations team had chosen an Oracle back-end with an X/Motif user interface, and I had been hired primarily for my Unix and X/Motif expertise, but despite my limited experience with Oracle, one look at the proposed system architecture convinced me that it would not work. As I explained to the team, there was no separation between the user interface and the database. Too much data would flow unnecessarily between client and server, and then on to the computational optimization engine. I proposed a different network and database architecture, and the team adopted my redesign.

Before I came on board, management had also chosen to use a third-party IDE and database client known as JAM, rather than Oracle’s own native GUI and IDE. The team, unfortunately, encountered serious problems with the stability and efficiency of JAM's proprietary JPL language. Given the firm's commitment to JAM, we could not avoid JPL entirely. We could, however, reduce our dependency on its built-in SQL dialect, which was at the heart of the problems. I showed the team that most of the critical database logic could be shifted out of JPL and into native Oracle PL/SQL procedures. The team agreed, and we successfully circumvented the worst of the JAM problems.

As the project proceeded, I wrote major pieces of the user interface and database code. I helped the team overcome challenges resulting from nuances between the different dialects of SQL that we were using, tutored them in X/Motif programming techniques, and helped resolve additional problems in the JAM-Motif interface. When the ops team encountered a problem in the formula it was using to re-adjust ingredient proportions. I figured out that they had failed to compensate for changes in quantity resulting from the adjustments. Using my math background, I tweaked the algorithm so that it correctly normalized the adjusted quantity, and the problem vanished.

Another major design hurdle involved the large system of linear equations that lay at the mathematical core of the system. The IBM team that Kraft had hired to create this computational engine had opted to use the patented “Karmarkar” algorithm to solve this linear system. Unfortunately, however, they had never encountered a system of this size and complexity, and in their effort to implement Karmarkar, ran into roadblocks due to network bandwidth and memory limits.

I had never heard of the Karmarkar algorithm, and I, too, had never worked with such a large linear system. Like other problems that had come my way in this project, this one was in no way related to my original job description. Nevertheless, I was asked to take a look, and again my mathematical background came in handy. Using advanced linear algebra, I figured out how to recondition the input data into a workable memory management scheme that also satisfied the sparse matrix format required by the algorithm. My conditioning method enabled the IBM team to complete their implementation, and the project continued on to a successful conclusion.

Advent Software and Geneva

On the strength of both my mathematical background and my prior experience working on an accounting system for a pension fund manager, I was asked to join the team at Advent Software (now SS&C/Advent) that had just started developing a multi-tiered, object-oriented, portfolio accounting system called Geneva. Assigned to build out the financial analytics engine, I developed the virtual inheritance model that enabled Geneva to handle variable-rate, stepped, and fixed-rate accruals for all commonly traded fixed-income securities, and created Geneva's amortization features. I developed a workaround for the 3rd-party library limitation that until then had prevented Geneva from handling dates later than the year 2037. I conducted the initial port of Geneva from Solaris to Linux, which is now the standard Geneva platform. Working along with Geneva’s earliest customers, I became familiar with the ins and outs of Geneva’s object-relational database (Advent Global Area, a.k.a. AGA); accounting engine (Bookkeeping Information Space, or BIS); Report Specification Language (RSL); Accounting Treatment Language (ATL); Interface Definition Language (IDL), etc.

After leaving Advent, I began consulting at a division of Goldman Sachs, which, as co-development partner of Geneva, was entitled to full use of the system's source code. I corrected problems in two internal components of Geneva with which I had not previously worked, the "Query By Example" (QBE) engine and the loader’s transaction traversal mechanism, thereby making a huge improvement in Goldman’s bulk transaction input speed. I also wrote advanced reports, onboarded new security types, and trained and supervised other developers.

I went on to do Geneva implementations and projects at two additional divisions of Goldman, at Citigroup/Smith-Barney (now part of Morgan Stanley), at HSBC (Bank of Bermuda), and at Pine River Capital, where I managed the Geneva development team (click here for details). I also worked on several non-Geneva projects, including in-house accounting systems at Citadel Investments, Morgan Stanley, Millennium Management, and RBS Greenwich Capital.

Having worked in both Geneva and non-Geneva accounting environments, I know that Geneva presents special challenges when integrated into the typical business environment. Business users often assume incorrectly that Geneva has the same failings as other accounting systems with which they have worked. Accountants, for example, sometimes think that because other systems have difficulties in resolving prices, Geneva will, too, when in fact Geneva’s pricing mechanism, if configured correctly, is quite robust. DBAs and developers accustomed to Sql Server and other RDBMS assume that accruals, current face, and other accounting-related values are stored as static values somewhere in the Geneva AGA, when actually, under Geneva’s dynamic accounting model, these values are not persisted anywhere; they only exist, and can only be extracted, in the course of a dynamic accounting run.

Geneva's complexity and inconsistencies - not to mention bugs - are themselves sources of tremendous confusion. The relationship between "prior knowledge date" and "knowledge date" in Geneva's "Closed Period" accounting engine trips up many an accountant and developer. Even the most experienced Geneva technologists are dumbfounded to learn that "Closed Period" accounting when applied to the BIS is different from "ClosedPeriod" accounting applied to Journal Entries. Geneva's Freezepoints seem to be a great concept, until you learn that if a freezepoint is later removed, any transactions that are modified in the interim will have their knowledge-date altered by the removal. A huge number of RSL reports are provided in a standard Geneva installation. Intimidating in their complexity, and often buggy, they lead many Geneva clients to believe that they must spend large amounts of time and money to fix or customize the reports to their liking. But when you look below the hood, you find that every piece of accounting data in Geneva can be extracted in a much smaller number of much simpler reports.

I do not pretend to know everything about Geneva - nobody can, and there's always more to learn. But my experience with it, as well as with non-Geneva accounting systems, enables me to answer questions, solve problems, and complete projects that clients and Geneva professionals may sometimes struggle with.

Pine River Capital Management

At Pine River Capital Management, I assembled and managed the Geneva development team. Working closely with Pine River’s accounting, operations, treasury, and IT staff, our team of three developers and various consultants integrated Geneva with Pine River’s existing systems, including a Paladyne security master, Eze-Castle OMS, and in-house pricing server. To facilitate testing and deployment, we created a production-parallel version of Geneva, into which all production transactions and other activity were loaded and replicated in near real-time. I designed and developed a service that used the Geneva Synchronisation Utility (GSU) to extract all activity and other AGA changes, both static and dynamic, into a Sql Server database.

Before I came on board, Pine River had implemented Geneva World Investor (GWI). One of the particularities of GWI is that transactions that are loaded from GWI into Geneva are permitted to violate the knowledge-time versioning of the AGA. In a typical Geneva installation, if you re-run a report with an earlier knowledge time, your results should exactly match those of the earlier report. At Pine River, however, we sometimes found that due to violating GWI transactions, the results were different. This caused the accounting department a great deal of trouble. To help reduce the impact, I created a custom audit report that showed exactly which objects in the AGA were causing the discrepancies.

At the business's request, we produced two related but independent implementations of Geneva: a general ledger giving a custodial view of data, and a position ledger giving an internal profit-loss view. I created custom reports reflecting the accounting department’s specific requirements for currency exposure, financing risk, and swap resets. I also developed a number of special-purpose Geneva ETL modules to handle requirements not otherwise supported by the traditional Geneva loader and workflow manager.

Advertising Database, Inc.

AdData (Advertising Database, Inc.)^†, a successful web-based provider of advertising information, needed to upgrade all major components of its business: its underlying data store, internal user interface, customer database, accounting system, and customer-facing web GUI. I was brought in to oversee the project, partly for my experience in systems integration, and partly because, as an outsider to both the company and the industry, I could look at issues in a fresh light.

Gaining the trust of external and internal stakeholders, I redesigned aspects of the overall architecture that had not been adequately fleshed out. I coordinated with both IT and web designers to resolve inconsistencies between wireframes and specs. I overhauled the schema provided to the database developer, and designed a mechanism for converting and replicating the database via open-source technologies.

AdData’s internal database, on which the company’s main product and source of revenue depended, had been running on a PC data management program known as Filemaker. Over the years, the data had become duplicative and corrupted. The business, however, was deeply dependent on the Filemaker GUI – which remained among the best available. As part of my duties, I was therefore asked to reconfigure the company’s data, and to perform an upgrade to a more modern version of Filemaker. Using advanced techniques of natural language processing, I cleansed and normalized the Filemaker data, making it suitable not only for the upgrade, but also for daily replication into the fully relational MySQL database that was needed for both the companys Solr textual search engine, and for new business uses that the staff, hamstrung by the problems with the old program and data, had not even realized were within their grasp.

RBS Greenwich Capital

At RBS Greenwich Capital (now NatWest Markets), I worked with the credit derivatives team to add support for swaps and other securities in its in-house (non-Geneva) accounting system. I created accounting modules for Total Return Swaps (TRS), Credit Default Swaps (CDS), and a variety of MarkIt mortgage-backed security derivatives, including interest-only (IO) and principal-only (PO) strips. The MarkIt derivatives, however, were fundamentally different from other asset classes in the existing RBS accounting system. Their pricing and valuation were so closely linked to data available only through MarkIt web services that current reporting tools were inadequate. To provide the middle-office the in-depth reporting they required, I designed a new set of detailed reporting tools that integrated closely with both the MarkIt and accounting data to fill in the gaps.

I also developed facilities for straight-through trade processing and clearing and confirmation, and designed and executed database conversions and migrations. For the Scrittura conversion, I received the RBS “Ovations” award below: