Category: Software Architect

97 Things Every Software Architect Should Know – 10/97

“Fast” is not a requirement. Neither is “responsive”. Nor “extensible”. The worst reason why not is that you have no objective way to tell if they’re met. But still users want them. The architect’s role is largely to help the system have these qualities. And to balance the inevitable conflicts and inconsistencies between them. Without objective criteria architects are at the mercy of capricious users (“no, I won’t accept it, still not fast enough”) and of obsessive programmers (“no, I won’t release it, still not fast enough”).

As with all requirements we seek to write down these desires. Too often then the vague adjectives come out: “flexible”, “maintainable” and the rest. It turns out that in every case (yes even “usable”, with effort) these phenomena can be quantified and thresholds set. If this is not done then there is no basis for acceptance of the system by its users, valuable guidance is stolen from its builders as they work, and the vision is blurred for those architecting it.

Some simple questions to ask: How many? In what period? How often? How soon? Increasing or decreasing? At what rate? If these questions cannot be answered then the need is not understood. The answers should be in the business case for the system and if they are not, then some hard thinking needs to be done. If you work as an architect and the business hasn’t (or won’t) tell you these numbers ask yourself why not. Then go get them. The next time someone tells you that a system needs to be “scalable” ask them where new users are going to come from and why. Ask how many and by when? Reject “Lots” and “soon” as answers.

Uncertain quantitative criteria must be given as a range: the least , the nominal, and the most. If this range cannot be given, then the required behavior is not understood. As an architecture unfolds it can be checked against these criteria to see if it is (still) in tolerance. As the performance against some criteria drifts over time, valuable feedback is obtained. Finding these ranges and checking against them is a time-consuming and expensive business. If no one cares enough about the system being “performant” (neither a requirement nor a word) to pay for performance trials, then more than likely performance doesn’t matter. You are then free to focus your architectural efforts on aspects of the system that are worth paying for.

“Must respond to user input in no more than 1500 milliseconds. Under normal load (defined as…) the average response time must be between 750 and 1250 milliseconds. Response times less than 500 milliseconds can’t be distinguished by the user, so we won’t pay to go below that.” Now that’s a requirement.

97 Things Every Software Architect Should Know – 9/97

We’ve all been hit with budgetecture. That’s when sound technology choices go out the window in favor of cost-cutting. The conversation goes something like this.

“Do we really need X?” asks the project sponsor.

For “X”, you can substitute nearly anything that’s vitally necessary to make the system run: software licenses, redundant servers, offsite backups, or power supplies. It’s always asked with a sort of paternalistic tone, as though the grown-up has caught us blowing all our pocket money on comic books and bubble gum, whilst the serious adults are trying to get on with buying more buckets to carry their profits around in.

The correct way to answer this is “Yes. We do.” That’s almost never the response.

After all, we’re trained as engineers, and engineering is all about making trade-offs. We know good and well that you don’t really need extravagances like power supplies, so long as there’s a sufficient supply of hamster wheels and cheap interns in the data center. So instead of saying, “Yes. We do,” we say something like, “Well, you could do without a second server, provided you’re willing to accept downtime for routine maintenance and whenever a parity bit flips, causing a crash, but if we get error-checking parity memory then we get around that, so we just have to worry about the operating system crashing, which it does about every three-point-nine days, so we’ll have to do nightly restart. The interns can do that whenever they get a break from the power-generating hamster wheels.”

All of which might be completely true, but is utterly the wrong thing to say. The sponsor stopped listening right after the word “well.”

The problem is that you see your part as an engineering role, while your sponsor clearly understands he’s engaged in a negotiation. We’re looking for a collaborative solution-finding exercise; they’re looking for a win-lose tactical maneuver. And in a negotiation, the last thing you want to do is make concessions on the first demand. In fact, the right response to the “do we really need” question is something like this:

“Without a second server, the whole system will come crashing down at least three times daily, particularly when it’s under heaviest load or when you are doing a demo for the Board of Directors. In fact, we really need four servers so we can take one HA pair down independently at any time while still maintaining 100% of our capacity, even in case one of the remaining pair crashes unexpectedly.”

Of course, we both know you don’t really need the third and fourth servers. This is a counter-negotiating gambit to get the sponsor to change the subject to something else. You’re upping the ante and showing that you’re already running at the bare, dangerous, nearly-irresponsible minimum tolerable configuration. And besides, if you do actually get the extra servers, you can certainly use one to make your QA environment match production, and the other will make a great build box.