Out of ten bullets on software architecture, this is the second: the realization that no software architecture is good or bad – at best, it is appropriate (or not).

This is going to be fun: So many people believe there is “good” and “bad” software architecture. I’d like to lead you to think: “there is appropriate architecture”.

An example:

Some time ago, friends of mine got the job to write a piece of software for the following scenario: For the synchronous world-wide launch of a new revision of an immensely popular piece of consumer electronics, a minimal web shop was needed. Top priority: Don’t loose any sales. None at all. No browser, no operating system, no language, no platform should be excluded. That shop should work, come hell or high water – or literally millions of customers in the first hours of its existence. It doesn’t have to be sexy. It just has to work. For a few weeks.

And after said few weeks, it would be thrown away never to be seen again and replaced with a spiffy standard webshop engine.

What does that tell us? – the usual considerations about “maintainability”, “supportability”, “extensibility” and all these other nice “-ilities” go straight out the window. Go back to basic transaction management: No deadlocks, none. Squeeze every bit out of your SQL-statements. Hardwire the database. More than that: hardwire everything you want. No JavaScript, very careful use of CSS. And so on, and so on. (It also requires a lot of other know-how, e.g. on load testing, but that is of no concern here)

Everything is turned upside-down.

Sometimes I wonder whether today’s CS students could even do something like that or whether they themselves have these “-ilities” hardwired so thoroughly in their wetware that they don’t know how to write “bad code” like that anymore.

A shot at a conclusion

Admittedly, this is an extreme example. It does illustrate a couple of things:

• Today’s “best practices” hardwire a ton of “-ilities” into your projects. Most of the time, that’s a good thing. Best practices and the components incorprating them hide a significant chunk of complexity and let you focus on what you really want to do.
• Sometimes, these “best practices” get in the way. Even if the price you pay is negligible most of the time, it may be too high under extreme circumstances.
• Most importantly, you loose awareness for what really counts: that the system you build is 360° appropriate to the task at hand (because so many hygiene factors are already silently covered)

For example, some time ago I had the opportunity to build a software suite that was designed to be a medical product. As the satisfaction with the predecessor system was, at best, mixed, I examined it thoroughly, mostly for its “-ilities”, and found a solution similar to the web shop above: most importantly, the resource drains implied by the requirements of medical product regulations were not considered. I re-drew the whole thing bottom up and, surprise, ended up with a slightly unusual approach but much more appropriate foundation that served us well throughout my tenure and beyond, as far as I can tell to this day.

Later, I found that there’s even a name for this kind of thinking: “non-presumptive architectures“:

A presumptive architecture is a software architecture (or a family of architectures) that is dominant in a particular domain. Rather than justifying their choice to use it, developers in that domain may have to justify a choice that differs from the presumptive architecture.

Warning

Every problem is, of course, unique. Most of the time, that doesn’t mean that your software system has to have a unique architecture, too.

Conclusion

Most of the time, standard solutions are appropriate because most of the problems we are to encountering are “standard problems”, one way or another. This creates the illusion that architecture may be “good” or “bad” where in fact it is only “appropriate to a standard problem”. Or not.

P.S.:

To all architects out there: reflect on your past projects. What did you enjoy more: “standard problems” or “non-standard problems”? How will this reflection influence your future choice of projects?