|
Walker Informatics GmbH Im Suderfelde 22 D – 21385 Amelinghausen Germany |
jim.walker@walkerinformatics.de www.walkerinformatics.de |
Mobile: +49 / 176 / 45 50 14 01 |
Contract work – under the ægis of my Einmann-GmbH – performing consulting, analysis, design, implementation, installation, maintenance and support on software projects and systems dealing with business data and communications (preferably Banking/DBMS/EC).
| M B A | Imperial College of Science, Technology and Medicine (University of London), Management School, 1992 – 1993. Master of Business Administration and Diploma of the Imperial College, 1994. |
| B Sc (Hons) | University of Pennsylvania, Moore School of Electrical Engineering, 1979 – 1983. Bachelor of Science in Engineering, Computer Science and Engineering, Magna Cum Laude, 1984. |
| 1994 – Present | Walker Informatics GmbH, Amelinghausen, Consultant / Contractor (and Geschäftsführer). | |
| Own Company, Walker Informatics GmbH, Python Developer, with Docker | • | In the most recent half year, I've been working on a major overhaul of my company's AI-like own project (see entry for 2020/1 below). This time I've packed each program into it's own Docker container so that multiple instances of each can run in parallel, as needed. Im using Docker Desktop within WSL as the VM. Major topics are Python type-hints for type checking by PyCharm, and using JSON files for holding scenarios and calculation results. Components used: Python 3.13 with ‘C‘ modules bound in, PyCharm, Git, GitLab-Server, Tortoise-Git, Ubuntu WSL, Docker with Dockerfiles, Python DevPI with pip, Python Flask-Server (REST) and Python-Cement-Framework. |
| kein Projekt | • | In 2023/4 I neither sought nor had customer projects. In mid-2023 we (private) had bought a house. Its previous owner, due to frailty of age, had done little or no maintainance on the house or garden for years. I had to relieve the stacked-up and waiting work. |
| Python- and Shell-Developer, Front Arena | • | In 2022/3 I worked remotely for the German branch of a large, international bank in Düsseldorf, in a group focussed on Front Arena, having many interfaces to other systems. Due to Brexit, the bank was restructuring its European organisational chart and the interfaces needed to reflect the changes. My task was to change several existing programmes generating regulatory data (EMIR, MiFIR, SFTR, ESTR) so that they would switch from one day to the next, on the "branchification" date, to use the new data filtering and programme logic automatically, without having to carry out a programme change on day. This was achieved using a couple of new python modules, which read out a system-global environment variable containing the switch-day. The before- and after-behaviour of all of the involved programmes was tested extensively, which uncovered many other unrelated errors, that also had to be corrected. In particular, the stability and data integrity of the EMIR and MiFIR programmes, which ran as AMB-clients in real time, were found to be unsatisfactory and were incrementally improved, as time would allow. In addition to my main task, I was assigned the implementation of several new interfaces, which ran daily and delivered data to several various parts of the bank, for example, reports to the trading office (ESTR), and custom risk-management data to south Asia. Components used: Front Arena, Prime, AMBA, AMB, ASQL, Python, PyCharm, AEL/ACM, Windows, Linux, bash/ksh-scripting, Jira, ServiceNow, Confluence, Git, Perforce, Zoom, Citrix Workspace. |
| Shell Developer, Production Assurance, Git Introduction | • | In 2021/2, after the Corona break, I worked remotely for a branch of a major Italian bank in Hamburg in a group that maintains a data warehouse and pipeline containing performance and controlling data. The system has a monthly running cycle; nominally, my role was to accompany and monitor the system, sounding the alarm if something goes wrong. On the side I coded changes in ETL steps and wrote tools, in bash or PL/SQL, to support change testing. I analysed the current technical situation and gave a presentation on how Git could be advantageously embraced more thoroughly, after which I brought the existing codebase into Git in a basic constellation. Components used: RedHat Enterprise Linux 7, Windows 10, host mainframe, OPC, JCL, Oracle, PL/SQL, sqlplus, SQL Developer, Bash, Git, PuTTY, MS Office, MS Teams. |
| Own Company, Walker Informatics GmbH, Python Developer, Infrastructure | • | In Corona year 2020/1 I worked on my own project to a) modernise a self-developed, tactical trading programme for DAX derivatives and b) gain experience with various current development and infrastructure components. I originally developed the programme in 2004 and used it profitably for two years. I have now updated, optimised and modernised the source code. Components used: Git, GitLab server and Tortoise-Git; Python 3 with embedded C; Oracle VM VirtualBox; Ubuntu Linux; Docker and Kubernetes; Python DevPI with pip; Python Flask and Bottle servers with HTML, REST and Cement framework; MySQL, SQLite and Oracle; JetBrains PyCharm; Make, Setuptools, Distutils and Dockerfiles. |
| JIRA-Developer, Python, Groovy, REST-API | • | In 2019 I worked for a large exchange organisation and market infrastructure provider in Eschborn as developer in a small project team that was responsible for the JIRA-based security issues system. My work centered around importing data from other systems into JIRA, making adjustments to the user interface, tweaking workflows, as well as designing and implementing the necessary programme elements in the background to support the visible changes. Components used: Jira, with ScriptRunner; Groovy, with Java; JavaScript and Ajax; Python 3 and PythonJira; Cement-Framework in Python; JIRA-REST-API-Clients in Python; REST-Endpoints in Groovy / ScriptRunner; JetBrains PyCharm; JetBrains IntelliJ IDEA for Groovy and Java. |
| Regulatory Reporting, EMIR, MiFIR, Perl, Sybase, XML, Linux | • | From 2017 to mid-2019 I worked for a large cooperative bank in Frankfurt as developer and analyst in a project team responsible for the EMIR and MiFIR reporting for the bank and its partners. The EMIR system was taken through a major release and multiple smaller upgrades. The MiFIR system was brought into existence and was steadly improved thereafter. My emphasis fell to EMIR, in particular analysing the reported errors, determining why they arose and repairing them in the programmes and the data held at the registry. The problem complexity was high, due to data interrelationships and quality issues, as well as legacy errors and shortcomings in the available documentation. Nevertheless, we achieved an accepted message rate of better than 99%. Components used: Perl 5, Sybase, XML, Tortoise for Mercurial, Linux, ServiceNow, Jenkins. |
| Regulatory Reporting, Liabilities / Issuances Data, Word, Excel, Access, Sybase, Oracle | • | In 2015 and 2016 I worked as an analyst and documents author in a project team writing specifications for liabilities dataflows within a large (G-SIB) bank in Frankfurt to support the FSB, Bail-In and Basel III reporting requirements. My responsibility was the bank's issuances dataset, although I also assisted with the handling of wholesale funding data. The relevant data elements and structures had to be identified and obtained from the Treasury to the Finance databases, which required expansion of the data models in the intermediate and target systems. The primary results of my work were Business Requirements Dokuments (BRD) and Functional Specifications Dokuments (FSD) for the various steps in multiple ETL-pipelines. The nature of the work was a mixture of technical and business analysis and much communication, including explaining, describing, convincing, negotiating and compromise, in a culturally diverse and geographically distributed environment. Components used: MS Word/Excel/Access/Visio/Powerpoint, Oracle SQL Developer, Toad for Oracle and Sybase, Jira, Collabnet, Python 2, CSV. |
| Testing, Perl, XML, Linux, Excel, CSV | • | In 2015 I performed a short project for a major bank in Frankfurt to convert the control programmes in a regression-testing toolkit, and their control data, from an Excel- and CSV-representation of the data to an XML-representation of the same data, in preparation for a wider deployment of the tool to support a planned major upgrade. Components used: Perl 5, Excel, CSV, XML, Linux. |
| System Monitoring, Front Arena, Python/ACM/AEL, ITRS Geneos | • | In 2013 and 2014 I did project work for a large bank in Frankfurt involving 1) supporting the integration into Front Arena of a recently acquired certificate business and 2) establishing an infrastructure, based on ITRS Geneos, to monitor the availabilty and performance of a calculation and quoting pipeline for those and previously-existing certificates. In task 1, I concentrated on performance analysis and optimisation of the reporting and interface programmes, as well as developing ad-hoc tools to support the daily doings of the middle office. My task 2 involved the implementation of samplers for ITRS Geneos and binding them into Geneos, including rules and other configuation entities. To this end I designed and implemented a flexible framework and class-hierarchy, based on Python, that works equally on Windows and Linux/Unix. The samplers draw their data from many different sources, including Front Arena, Reuters RFA, Bloomberg BLPAPI, KDB/Q-databases and FIX- or XML-logfiles, correlate and summarise the data and send the monitoring outputs to Geneos. "Samplers" for administrative tasks were also implemented within the framework. I assembled several releases, which were passed to production and, of course, documented everything. Also, I assisted in the assembly of dashboards and in the administration of the Geneos infrastructure (gateways, web-servers, net-probes). Finally, I was often in contact with the software provider, ITRS. Components used: Front Arena 2012.1, Python/ACM/AEL, ITRS Geneos, Excel, Windows, Linux. |
| Algo (TLM) Collateral Management, Perl | • | In 2013 I worked for a large bank in Munich on a project introducing the Algo (TLM) Collateral Management System for the bank's office in Italy, where they had been using Murex's MLC. Because Algo was already being used in the German office, it was mostly just a matter of cloning the existing system and adapting it to the Italians' specific needs, although making the existing single code base usable by two distinct installations was tricky at times. My role was mostly technical, although there were some business aspects to reconciliations I implemented and in additional system enhancements for the German customer. Components used: Algo Sentry CM, Perl, MS Access, Windows and Oracle. |
| Front Arena, Python/ACM/AEL | • | In 2012 I worked for a large bank in Stuttgart performing system modifications, mostly small to medium change requests, to an established Front Arena installation. Most had to do with business reports, including generating simulation values, and reconciliation interfaces. My work also involved automating and performing regression testing of hundreds of existing reports in support of a large system upgrade. I also wrote a tool for the automatic registry configuration of all of the various Front Arena components running on Windows, including AMASes, price feeds, exchange interfaces and XMBA interfaces. Finally I provided technical support for minor upgrades of a few interfaces. Components used: Front Arena, Python/ACM/AEL, SVN, Jira, Solaris, Sybase, SQL Server. |
| Bloomberg BPipe & DataLicense, Front Arena | • | From the second half of 2010 through 2011, I worked for a large, resurrected bank in Munich. I supported, enhanced, monitored and documented interfaces to two Bloomberg market-data applications, BPipe and DataLicense. The main foci were improving the performance of the BPipe interface programme and stabilising the real-time price-delivery mechanism between BPipe and Front Arena. I was also in the support team for two Front Arena installations, one Windows-based and one Unix/Solaris-based. Typical tasks involved handling special data or reporting requests, including programming customised solutions, as well as tracking down problems and performing routine maintenance. Components used: Python, Java, Powershell, Windows Server, Front Arena, Solaris, Sybase, SQL Server. |
| Front Arena, Migration, SwapsWire | • | Until April 2010, worked on two projects for a major bank in Munich. The primary project was the migration of a legacy Front Arena system to Murex, although my work involved only the Front Arena side. My task was the development of a suite of data-extraction programmes which make the full set of data related to live trades in Front Arena available to the Murex team on an ongoing basis as well as on the cutover weekend. Additionally I performed analysis and documentation work for existing interfaces and queries in Front Arena, with an eye towards providing specifications from which the Murex team can work. The secondary project was the design and implementation of a query/interface in Front Arena for the backloading of legacy IRS and OIS swaps from Front Arena to SwapsWire, in accordance with the SwapsWire Backload Cookbook. Components used: Front Arena, Solaris, AEL/Python, AMBA, SwapsWire Backload and Client programmes. |
| Front Arena, AEL/Python, wxPython | • | In 2009, worked as a programmer/analyst on a Front Arena system for a state development bank in Dusseldorf. My work was concentrated on re-working and enhancing two processes, the mark-to-market programme and the market conformance process. The first involved optimisations and bank-specific customisations to the standard MtM-product of the system. The second involved a back-end programme which captured and evaluated trades with respect to market conditions in real-time, and a front-end GUI programme integrated into Prime which the risk managers use to identify, check and sign off on any trades which are not immediately accepted by the configurable tolerance rules. This work involved reverse-engineering of the existing processes, analysis, interfacing with the risk managers, implementation, testing and documentation. Components used: Front Arena, FA Prime, Solaris, Sybase, AEL/Python, wxPython, ATS, AMBA. |
| Front Arena, System Management | • | In the second half of 2007 and all of 2008, worked as the sole technical and functional system manager and maintainer for the entire Front Arena installation (which I helped introduce in 2002 and 2003) for a major bank in Munich. My work included testing and performing numerous upgrades as dictated by the exchanges, maintaining system stability and compactness despite continually increasing data volumes, setting up and caring for the various users, diagnosing and repairing any problems and keeping the interfaces and data clean as conditions changed. The wide range of my activities required that I know all parts of the Front Arena system inside out and front to back, and navigate within the bank's system landscape and change management procedures. Components used: Front Arena, FA Prime, Solaris, Sybase, Windows Server/Cluster, MS SQL Server, AEL/Python, AMAS, ATS, XMBA, AMBA, ASG-IMPACT ITIL Tool. |
| Front Arena, Project Management | • | In winter 2006-2007, worked as the project manager for the introduction and initial integration of a new Front Arena 2.2 platform for a new equity derivatives trading group at a large German bank in Zurich. Coordinated all aspects of the FA subproject, from the hard- and software installation and configuration, and interfaces to other systems, to accommodating the demands of the traders, middle office, compliance, business and the vendor. Met the ambitious 'Go-Live' target date of eight weeks after my arrival in the project. Normalised the data flows and operational procedures, including hands-on training of the middle office, and stabilised the system, in order to make it operable in the long term. Components used: Front Arena, FA Prime, Solaris, Sybase, Windows Server/Cluster, AEL/Python, AMAS, ATS, AMBA, ADFL. |
| Front Arena, Win32Com | • | In early 2006, performed design, implementation and documentation of a control programme to serve as a scaffold on which new and existing elements of the P&L process for Front Arena are to be integrated and automated, for a major bank in Frankfurt. Interesting here was the diversity of the elements to be bound together, including a generalised GUI using Python's Tkinter, data extraction from Front Arena using Atlas Extract/ASQL and ACM/Portfolio Sheets, an intermediate Database using Access, reporting using Excel, VBA callouts using Python's Win32Com and mailing of results using Lotus Notes Mail. Components used: Front Arena, AEL/ACM/Python, Tkinter, Win32Com, ASQL, ADFL, cygwin, cvs, Access, Excel, Lotus Notes Mail. |
| Front Arena, Python | • | In 2005, performed general implementation, maintenance and troubleshooting in support of an installation of the Front Arena financial information system for a major public bank in Munich. A strong focus was data maintenance, aggregation, archiving and deletion. Other work involved the interfaces between Front Arena and a wide range of other systems. Components used: Front Arena, Sybase, OOP, AEL/Python, SQL, sh, cvs, SUN Solaris, Excel. |
| Front Arena, Tkinter | • | In 2004, performed design, implementation and documentation of two data import/export interfaces to the Front Arena financial information system for a major bank in Frankfurt. These involved a price/volatility interface for the mark-to-market process and a trade interface for reverse convertibles. Interesting here was the integration of Python's Tkinter with AEL, enabling custom GUIs to be developed and then served from within Front Arena Prime. Also, I created object classes and a wrapper for the easy development of further AEL hooks. Components used: Front Arena, Sybase, OOP, AEL/Python, Tkinter, SQL, sh, cvs, ClearCase, SUN Solaris, Excel. |
| Front Arena, Perl | • | In 2002 and 2003, performed analysis, implementation, integration and documentation work to support the introduction of the Front Arena financial information system for a major bank in Munich. My main tasks had to do with interfaces to/from other bank-internal systems, batch processes and data integrity. This work involved perl, python, tk/tcl, various shells, cvs, SQL and the Sybase DB in a Solaris (Unix) environment. Additional tasks include performance and throughput testing and improvement, and the introduction of a project-wide source-code (cvs) control system. |
| Solaris, Informix | • | In 2003, for a cable infrastructure company in Munich, configured the RAID file systems on a Sun development machine, introduced the cvs source code control system, imported the sources for several existing applications into cvs and implemented a subsystem to perform asynchronous distributed updates to standing data tables, including automatic foreign key adjustment. This work involved perl, triggers, stored procedures, SQL and the Informix DB in a Solaris (Unix) environment as well as Cygwin and XFree86 on W2K PCs. |
| CRM, MS Access | • | From 2000 to 2003, for Cirrus Logic, a DSP-chip maker, specified a web-based database application to support the sales and forecasting functions in Europe, after interviewing staff members about their requirements. Also maintained and upgraded Cirrus' old Access/NT-based sales application, which was replicated and distributed over three European sites. This involved plenty of Access and VBA design and programming. |
| Kondor+, C | • | In 2001, performed upgrade work on an interface for foreign exchange and money-market instrument data between the front-office Reuters Kondor+ trading system and the back-office internal treasury system of a major bank in Munich. This work involved C, various scripting languages, cvs, SQL and the Sybase DB in a Solaris (Unix) environment. |
| EDI, MS Access | • | In 1999, for Epcos, designed and developed an Access-based application for stock control of a consignment depot, integrating incoming EDI data from the customer. Also, developed basis documents to specify the conversion of several EDIFACT versions to the Siemens-internal subset; based on these, wrote the additional customer-specific specifications for 64 customer-to-Siemens mappings. Using Awk, generated test data files for several outgoing links and checked the results of their translations. |
| EDI, BS-2000 | • | In 1997 to 1999, for Siemens Business Services, EDI Service, External Suppliers, performed connection of new partners to Siemens-internal BS-2000 system and EDI-support of existing partners. Narrowed the Siemens EDIFACT-subset for use with external partners. Developed BS-2000 and Windows tools, based on my company's product, to streamline recurring processes. Developed an Access DB, with Awk front-end, to track the 100 partners and 600 individual connections between the various Siemens-customers and external suppliers. |
| EDI, Awk | • | In 1996, for Bass Brewers, developed a testing tool, based on my company's product, to generate outgoing EDI messages. |
| Visual C++, DLL | • | From 1994 to 1996, for own company, developed a specialised Windows EDI product for small customers of large distributors. This involved Windows driver and DLL programming using Visual C++. Unhappily, I failed to sell the product to targeted distributors, and nearly exhausted my company's initial capital. It was a worthwhile attempt, nevertheless. |
| 1992 – 1993 | Student, Imperial College, London (see Education above). | |
| 1992 | Independent Information Technology Consultant, Munich and Frankfurt. | |
| Sybase, Informix | • | Worked on project for Siemens-Nixdorf and Dresdner Bank to emulate a subset of the Sybase DBMS programming interface on top of the Informix DBMS interface. |
| 1990 – 1992 | Infosoft Datenverarbeitung GmbH, Munich, Computer Systems Analyst / Database Technology Specialist. | |
| Unix/C, Sybase | • | Participated in design and implementation of specialised application interface layer over the Sybase DBMS C-language interface layer. Developed tools to automate Sybase database creation and loading and other administrative functions. Installed and administered Sybase DBMS on networked Unix PCs. Wrote paper evaluating Unix DBMS packages. Developed data-conversion programmes and other tools. |
| 1985 – 1989 | Federal Judicial Center of the United States Courts, Washington, D.C., Research Computer Scientist. | |
| Unix, DBMS | • | Designed, developed, implemented, tested, and installed Unix-based application for electronic filing and review of court case documents. Worked as part of team developing and implementing court and case management database application for federal courts using the Unify DBMS and Unix. Worked with all parts of the application, including database design, data conversion, performance optimisation, application security, system software, transaction data-entry, reporting, new-site startup and releases. Delivered technical presentations for several subsystems. |
| 1984 – 1985 | Planning Research Corporation, Patent & Trademark Office Project, Fairfax, Virginia, Programmer / Analyst. | |
| Cobol | • | Participated in analysis and design of project's Data Capture Subsystem. Participated in evaluation of vendor workstation hardware and integrated software packages. |
| 1979 – 1983 | Student, University of Pennsylvania, Philadelphia (see Education above). |
Resident of Germany since 1989. German citizen since 2009. Speak German fluently. Awarded Zertifikat Deutsch als Fremdsprache, Goethe Institut, Munich, 1989. Several German courses at the Munich Volkshochschule followed.
Date of Birth: 3 October 1961; Citizenship: German; Marital Status: Single.
Last Update: 2025–04–07