Category: Software Architect

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.

I feel there is a certain irony in trying to impart something about architectural ideals, when the very premise I wish to begin with is that effectively there are no ideals. If this is indeed the case, then surely there is nothing to write, I am a contradiction and by doing this I run the risk of the universe imploding or something like that.

But alas, ceci n’est pas une pipe.

One of the most valuable lessons that I have learned as a software architect is that context is king, and simplicity its humble servant. What this means in practical terms is that context is the only force that trumps simplicity when making architectural decisions.

When I say context, I refer not only to high-level, immediate forces such as key business drivers, but also to elements in the periphery, such as emerging technologies and thought leadership on diverse topics. Indeed, good architects keep track of several fast-moving targets.

What constitutes good architecture? It is the product of decisions made within a context usually tainted with multiple competing priorities. Those competing priorities mean that sometimes the most important decisions are not about what you put in, but rather what you omit. The currency of good architecture is simply astute decision-making (while the products are all only about communicating your intent).

Historically, there have been some fascinating examples of the influence that context can have on architecture. A favorite example involves the database selected to support an ambitious new software system for a modern battlefield tank [1]. (Deciding what database to use is not usually architecturally significant; this example merely serves to illustrate a point).

When it came time to choose the database, the team assessed many. They found that while the tank was moving quickly over undulating terrain while tracking a target, the majority of the databases were capable of supporting this maximal throughput required of the navigation and targeting systems. But they were taken by surprise when they discovered that firing the main gun on the tank caused such a strong electromagnetic pulse that it totally crashed the on-board systems and of course the database along with it! On a modern battlefield, a tank without its software running is quite literally in the dark. In this context, recovery time was the overwhelming factor in the choice of database, and no database did that better at the time than InterBase [2], and that is why it was chosen for the M1 Abrams tank.

So, while newsgroups rage with the flames of technology debates of X vs Y, it is idle amusement. The reason these debates rage is often not because of huge disparities in their technical merits, but rather because there are more subtle differences between them, and what features individuals value more than others when there is no guiding context to act as a trump card.

Your team should be free of ideals, reflect on context in the first instance, and reach for the simplest solutions from there.

Footnotes
[1] – A tank, despite its extremely dubious purpose, is still an engineering marvel.
[2] – Interestingly, InterBase had an architecture that caused disk-writes to leave the database in an always-consistent state. This is one reason that contributes to its ability to recover from hard failures so quickly.