Software Architect Category: Software Architect - Page 47 of 51

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.

'Coz sharing is caring

97 Things Every Software Architect Should Know – 8/97

We often hear software engineering compared to building skyscrapers, dams, or roads. It’s true in some important aspects.

The hardest part of civil engineering isn’t designing a building that will stand up once it is finished, but figuring out the construction process. The construction process has to go from a bare site to a finished building. In the interim, every worker must be able to apply his trade, and the unfinished structure has to stand up the whole time. We can take a lesson from that when it comes to deploying large integrated systems. (“Integrated” includes virtually every enterprise and web application!) Traditional “big bang” deployments are like stacking up a pile of beams and girders, throwing them into the air, and expecting them to stick together in the shape of a building.

Instead, we should plan to deploy one component at a time. Whether this is a replacement or a greenfield project, this has two large benefits.

First, when we deploy software, we are exposing ourselves to the accumulated technical risk embodied in the code. By deploying one component at a time, we spread technical risk out over a longer period of time. Every component has its own chance to fail in production, letting us harden each one independently.

The second large benefit is that it forces us to create well-defined interfaces between components. Deploying a single component of a new system often means reverse-integrating it with the old system. Therefore, by the time deployment is complete, each component has worked with two different systems: the original and the replacement. Nothing is reusable until it has been reused, so piecewise deployment automatically means greater reusability. In practice, it also leads to better coherence and looser coupling.

Conversely, there are some important ways that civil engineering analogies mislead us. In particular, the concreteness of the real world pushes us toward a waterfall process. After all, nobody starts building a skyscraper without knowing where it’s going or how tall it should be. Adding additional floors to an existing building is costly, disruptive and risky, so we strive to avoid it. Once designed, the skyscraper isn’t supposed to change its location or height. Skyscrapers aren’t scalable.

We cannot easily add lanes to roads, but we’ve learned how to easily add features to software. This isn’t a defect of our software processes, but a virtue of the medium in which we work. It’s OK to release an application that only does a few things, as long as users value those things enough to pay for them. In fact, the earlier you release your application, the greater the net present value of the whole thing will be.

“Early release” may appear to compete with “incremental deployment”, but they can actually work together quite well. Early release of individual components means that each one can iterate independently. In fact, it will force you to work out thorny issues like continuous availability during deployments and protocol versioning.

It’s rare to find a technique that simultaneously provides higher commercial value and better architectural qualities, but early deployment of individual components offers both.

'Coz sharing is caring