Category: Softwares

A system consists of interdependent programs. We call the arrangement of these programs and their relationships “architecture”. When we diagram these systems, we often represent individual programs or servers as simplistic little rectangles, connected by arrows.

One little arrow might mean, “Synchronous request/reply using SOAP-XML over HTTP.” That’s quite a lot of information for one glyph to carry. There’s not usually enough room to write all that, so we label the arrow with either “XML over HTTP”—from an internal perspective—or “SKU Lookup”—for the external perspective.

That arrow bridging programs looks like a direct contact, but it isn’t. The white space between the boxes is filled with hardware and software components. This substrate may contain:

* Network interface cards 
* Network switches 
* Firewalls 
* IDS and IPS 
* Message queues or brokers 
* XML transformation engines 
* FTP servers 
* "Landing zone" tables 
* Metro-area SoNET rings 
* MPLS gateways 
* Trunk lines 
* Oceans 
* Cable-finding fishing trawlers

There will always be four or five computers between program A and B, running their software for packet switching, traffic analysis, routing, threat analysis, and so on. As the architect bridging between those programs, you must consider this substrate.

I saw one arrow labeled “Fulfillment”. One server was inside my client’s company, the other server was in a different one. That arrow, critical to customer satisfaction, unpacked to a chain of events that resembled a game of “Mousetrap” more than a single interface. Messages went to message brokers that dumped to files, which were picked up by a periodic FTP job, and so on. That one “interface” had more than twenty steps.

It’s essential to understand that static and dynamic loads that arrow must carry. Instead of just “SOAP-XML over HTTP”, that one little arrow should also say, “Expect one query per HTTP request and send back one response per HTTP reply. Expect up to 100 requests per second, and deliver responses in less than 250 milliseconds 99.999% of the time.”

There’s more we need to know about that arrow.

* What if the caller hits it too often? Should the receiver drop requests on the floor, refuse politely, or make the best effort possible? 
* What should the caller do when replies take more than 250 milliseconds?
Should it retry the call? Should it wait until later, or assume the receiver has failed and move on without that function? 
* What happens when the caller sends a request with version 1.0 of the protocol and gets back a reply in version 1.1? What if it gets back some HTML instead of XML? Or an MP3 file instead of XML? 
* What happens when one end of the interface disappears for a while?

Answering these questions is the essence of engineering the white spaces.

Imagine a personal vehicle that is roomy, comfortable, fuel efficient, inexpensive to produce, and 98% recyclable. You want one? Sure. Everyone does. Just one problem: Its top speed is 6 miles/hour (10 km/hour). Still want one? This small example demonstrates that performance is just as important as any other criterion.

The reason many designers put performance at the bottom of their lists might be that computers are so much faster at computation than their human counterparts, that they assume that the speed of the system will be acceptable. And if today’s systems aren’t fast enough, Moore’s Law will take care of everything. But hardware speed is only part of the system.

Performance is sometimes thought of as a simple measurement of the time it takes for a system to respond to user input. But system designers must consider many aspects of performance, including performance of the analysts and programmers who implement the design; performance of the human interactions of the system; and performance of the non-interactive components.

Performance of the people building the system is often called productivity, and it is important because it directly affects the cost and schedule of the project. A team that delivers a project late and over budget has a lot of ‘splainin’ to do. Using tools and pre-built components can dramatically affect how quickly the system can be built and start returning value.

Performance of the human interactions is critical to acceptance of the system. Many factors of system design contribute to this aspect of performance, response time being perhaps the most obvious. But response time is not the only factor. Just as important are intuitiveness of the interface and number of gestures required to achieve a goal, both of which directly affect performance.

More than response time per se, a good system specification will measure task time, defined as the time required to complete a domain-specific task, including all human interactions with the system. In addition to system response time, this measurement includes operator think time and operator data entry time, which are not under the control of the system. But including these times gives motivation to the proper design of the human interface. Proper attention to the way information is presented and the number of gestures required to complete the task will result in better human operational performance.

Performance of the non-interactive components is equally important to the success of the system. For example, a “nightly” batch run that takes more than 24 hours to complete will result in an unusable system. Performance of the disaster recovery component is also a critical consideration. In case of total destruction of one part of the system, how quickly can operational status be restored, in order to allow normal business to resume?

When considering the implementation and operation of a successful system, architects and designers should always pay careful attention to performance.