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