There are certain commercial-in-confidence restrictions on what I can include on a public web site like this. In particular, I cannot name the organisations for which I have worked while employed by IBM.
Since joining IBM in February 1995, I have worked on application architecture, business modelling and modelling language design, compiler design and construction, object-oriented framework development, component-based middleware, wireless and pervasive computing solutions, telco portals and data services platforms, and enterprise architecture. My industry experience includes government, banking and financial services, utilities, and transport and telecommunications companies.
Most recently, I have been working in the Finance Sector, as Lead Architect for a IT Change programme for a small bank in the North of England.
In the recent past, I have has been working on enterprise architecture projects in the government sector, as well as the telco and transport industries. I have also worked with pervasive and wireless computing solutions, especially with the integration of mobile solutions into large-scale enterprise systems. In particular, I have worked on wireless and multi-channel portal solutions, and data services platforms for telcos.
My previous experience includes systems and application architecture for large-scale e-Business solutions, using large-scale component models, and integrating multiple legacy backend systems. In particular, I have built large-scale business systems using Enterprise Java Beans (EJBs).
I have also developed business flexibility systems based on extended query languages, intended for large banking and financial services applications.I would like to think that I bring to any project an extensive technical background, both theoretical and practical problem-solving abilities, and a willingness to adopt a high-profile technical leadership role.
Within the limits of professional discretion, here are a few highlights from my time with IBM.
I have spent the last few years working for one of the UK Government's largest Departments. It's been quite an interesting experience working in government. Certainly, the failures are quite spectacular - the last one made the UK national radio and TV new, as well as four column-inches on page two of The Times. It's certainly an interesting experience to be driving along the motorway to work and hear about failures of a certain government computer system, and you realise that a small part of the programme you are leading is a replacement for that system.
For large, risky and expensive programmes, it is vital that the resource and effort estimates, the delivery plans and the solution itself represent exactly the same understanding. To allow this, I have been working on a modelling approach which uses a consistent metamodel for representing the solution, the effort estimates and the planning dependencies in a single environment. I have bene using this approach for large programmes with government customers.
A UML model typically contains multiple "views" or "perspectives" to represent different architectural aspects. Model perspectives include:
Insurance Product Builder was a concept ahead of its time. It allowed a business analyst to enter rules and calculations to describe the behaviour of a complex financial services package (life assurance, for example), and have these rules automatically turned into SQL and C code which ran as part of a CICS transaction against a DB2 database on an IBM mainframe.
Product Builder included a sophisticated compiler, which converted the rules expressed against high-level relational database tables, but compiled to run against the actual physical database structure, which might be quite different. IPB included (under the covers) a declarative programming language (no pointers), and a strongly-typed and deliberately incomplete programming language. This allowed the compiler to infer certain useful behaviour, such as memory management: although the IBP language had automatic memory de-allocation, there was no requirement for a garbage collector, since the compiler was smart enough to plant memory deallocation instructions.
The compiler used a patented technique to decide which of the two output languages (SQL and C) was most appropriate - clearly, neither target language was powerful enough to express this kind of data-oriented rules, as well as extract that data from a relational database.
The simple and declarative nature of the language also meant that it was tractable to perform automatic test generation, wwhere test cases could be inferred from the program logic. Of course, test cases require both program inputs and database data contents; the test generator produced both, as well as database schemas. We also built numerous other tools, including an interactive debugger for the IPB language.
Another key part of the IPB functionality was the Business Rules development environment. This was a shared (multi-person) version-controlled environment. We built this by persisting the "parse trees" directly into the Gemstone database. The generated rules were also version-controlled and time-sliced - that is, the rules in force when a customer bought the insurance would be applied when a claim was made, even though rules for newer versions of the same insurance product would be applied to a policy purchased today.
Product Builder was (briefly) an IBM Software Product, and even made it to version 2.0. Unfortunately, this was at a time when IBM was disinvesting from all application software products, and IPB was discontinued.
The technology used for the IPB system is now more-or-less obsolete, at least for new development; this included OS/2 [note], VisualAge for Smalltalk (including Envy), and the fine-grain object database from Gemstone.
In many ways, IPB foreshadowed the modern developments in Model Driven Architecture, which is all about representing and generating large-scale systems from very-high-level descriptions. And of course, it pre-dated the modern focus on using XML and Java for everything.
Interestingly, my more recent experiences with using MDA approaches suggests that large physical memory machines (at least 2 Gigabytes) are essential, since the entire structure must be in main memory for efficicent operations. Conversely, we made this kind of generation work with (by present-day standards) tiny amounts of memory (4 Megabytes!), by allowing object-level swapping in and out of the Gemstone database. This was the MUSHROOM approach, of course!
As part of the Product Builder development, I was awarded one US patent: 6,286,133, Method and apparatus for strategic compilation of source programs into two or more target languages. This patent was filed in March 1998 and issued in September 2001, and is now of course ascribed to IBM.
OTAAs awarded by IBM.
|© 2006-2016 Trevor Hopkins. All rights reserved.||Webmaster||Last updated 16 February 2016|