then you can move on to the various functional implementations.

 

modeling an early Windows System My first experience with modeling involved creating both drivers and mock-up components to explore a new technology. I was working for a large financial institution in the late 1980s when Microsoft Windows 2. 1 was released. A group of developers had created a fairly sophisticated suite of Windows applications for telephone-based customer service representatives. The applications provided the ability to retrieve customer information, balances, and so on from several mainframe-based systems (using the now-ancient concept of “screen scraping” the data intended to be displayed on an IBM 3270 dumb terminal) and then present the data in an aggregated view. It also allowed the customer service representatives to place trades on behalf of the customer.

The suite started as a proof of concept, but the prototype demos went so well it was rushed to production. When I joined the team it was already deployed to about 150 representatives. As the programs began to be used all day, problems began to occur frequently. These were manifested in a variety of forms: memory leaks, access violations, spurious error messages, and machine lock-ups (aka freezes).

Our small team was busy adding
functionality to meet the rapidly grow-
ing wish list and at the same time ad-
dressing the stability issues. We navi-
gated through the source, attacking
memory leaks and access violations.
We struggled to track down the grow-
ing list of newly observed error mes-
sage. The most challenging task was
“freeze patrol,” where we expended a
great deal of time hunting down those
machine lock-ups. The problem was
that we did not have a really good un-
derstanding of how Windows worked
behind the scenes.

figure 1. Publisher model component with drivers and sinks.

data Feed driver(s)

data Flood

Publisher

˲ receives mocked-up data feed.

˲ Simulates data enrichment and pumps data to client sinks.

client Sink(s)

modeling a “Slave” System

Not all of my modeling experiences resulted in such a positive outcome. Several exposed fundamental flaws in the architectural design, and with a few the only option was to abandon the system and start over. These messages were not typically well received by project management.

One of the more notable examples occurred in a system intended to be a “slave” receiving updates from several existing systems and applying them to a new database. The database would be used by other new systems to form the basis to replace the older systems. The systems would be built using a new technology platform. The technologies were so different and the functional breadth so wide that the development team had grown to more than 60 people for the slave system alone.

I joined the project after the basic architecture and much of the functionality had already been designed and developed, but it was still months away from production. My team’s assignment was to help get the most out of the infrastructure and optimize how the applications interacted with each other. After just a few weeks we suspected that some bad initial assumptions had impacted the architectural design. (I do not mean to disparage any teams in my examples, but