Out of ten bullets on software architecture, this is the third: the thought that software architecture is not decided by features, or at least: that features usually only have a minor impact on the whole topic.

Before we begin…

I’d like to remind you that we have already established that there is no good or bad architecture, only appropriate architecture. Now… we may fall into the trap of thinking “that means if only I understand the necessary features well enough, I can make an appropriate architecture.

No.

So far, I haven’t encountered a case where “features” in the classical sense helped shape the architecture. Even worse, they have frequently distracted from the really important things.

Let me tell you a joke:

Punch and Judy go to a pub for a drink. Or two. Or… well, whatever. Sooner or later, Punch is drunk and figures it’s time to go home. Judy, whether she was more careful or more hardened is up to the reader, stays a while longer and then leaves, too. Outside, she meets Punch. “I though you wanted to go home, what happened?” she asks. Punch replies: “I’ve dropped my keys and can’t find them.” – “I’ll help you look for them.”

Together, they look for Punch’s keys for a while, and Judy inquires “Are you sure you lost them here?”

“No, I’ve lost them over there, but the light is better here.”

When designing a software system, people tend to look for the features. Why? – Because that’s what they are excited about. So they love to think about features. But it is not what matters for good architecture.

By means of a little excursion: Sometimes, people are excited about a new piece of technology. That matters even less for a good architecture. (Unless you want to rip off some clueless tech kiddies on kickstarter.) End of excursion.

Let’s take the previous example from the other post: by means of classical feature set, the launch-high-scaleability-webshop and the later standard web shop are not noticeably different. Take order, secure payment, deliver. Roughly.

What obviously distinguishes the two are the “-ilities”: The one has to be unique in scaleability and performance and universality (“all” browsers, “all” OS’s), but basically no maintainability, no supportability, no updates / upgrades and only minimal troubleshooting tools. Even accessibility was not a design goal. At the time, accessibility was at odds with “all browser, all OS’s” and the browser-OS-matrix won temporarily.

The long-term shop needs update / upgrade support, has a middle-of-the-road OS/browser-matrix, needs to be good on performance, accessibility, supportability, maintainability, troubleshooting, but compared to its sibling, scaleability just needed to be good enough, in the upper commercial range.

What do we learn from that? – There is a quazilion of different ways to implement any set of features. Based on your feature wishlist alone you will not be able to sort your implementation options into “good” or “bad”, because there is no “appropriate” way to realize a feature (unless your feature already considers its corresponding “-ilities”). The yardstick is missing, and the yardstick is not in technology space – it is in user space, stakeholder space. But by the time you talk about “-ilities”, implementation options exclude themselves left and right. Examples?

• “I want to have sub-second response time” (-> performance)
• “I do not accept deterioriation of response time until we reach 1,000,000 requests per second” (-> scaleability)
• “I want to the cost of adding another translation without technical overhead” (-> I18N)

As we will see in a later post, it doesn’t make sense to talk about, say, performance, without accurately declaring “performance of what?”. Features and “-ilities” are connected, that’s what the title image symbolizes, but if you want to have an appropriate architecture, don’t fall for Judy’s mistake: ask for where the keys are first. Look for the “-ilities” first – or at least very, very early. Normally, you get a first rough cut at the features as a by-product.

If you need inspiration for your list of “-ilities”, have a look at ISO/IEC 9126 (or, more precisely, it’s Wikipedia page :-)). It may not be an ISO standard anymore, and I don’t think it ever applied to real-world software system anyways. Conversely, every system has its unique characteristics that need to be taken into account that can never ever be meaningfully standardized. ISO 9126 still has an inspiring look “beyond features”. Have a look and get your thoughts flowing in a useful direction.