cuse: “The system is [going to be] too large to take the time to model its behavior. We just need to start building it.” If the chore of modeling is considered too onerous, then it will probably be very challenging to achieve predictable performance, scalability, and other desirable technical attributes. Some development projects have a strong focus on unit tests, but in my experience it is rare to find a corresponding focus on testing the system architecture as a whole.

modeling a Sample component

Describing the modeling of a sample component may provide additional insight into the approach I am advocating. Suppose a new system calls for receiving some stream of data items (for example, stock quotes), enriching the data and publishing it to end users. An architect may suggest that some type of publisher component be built to perform this core requirement. How can this component be modeled before investing money in building a system around it? Data throughput and latency are probably primary concerns. Ideally, we have some target requirements for these. Scalability and availability are also issues that can be addressed with later iterations of the model but before proceeding with the functional development.

Based on this simple example, the model should contain at least two building blocks distinct from the publisher component. The incoming data feed needs to be simulated. A driver should be built to pump data into the publisher. Additionally, some type of client sink is necessary to validate the flow of messages and enable the measuring of throughput and latency. Figure 1 shows a simplified drawing with drivers and sinks for the proposed publisher.

The publisher model component
should be built using the proposed tar-
get language. It should use any frame-
works, libraries, among others, that
may affect the model outcome, though
it may not be obvious which of these
could have an effect. In that case you
should take a risk management ap-
proach to include those that are core
to the operation of the component. Any
new technology where the behavior is
not already fully understood should be
included as well. Any nonsuspect infra-
structure can be added in later itera-
tions. It is important not to get mired
in trying to build the functionality too
early. As much as possible should be
stubbed out.