Chapter 14: Working with Multiple Quality Attributes

Welcome to Last Minute Lecture.

This free chapter overview is designed to help students review and understand key concepts.

These summaries supplement not replaced the original textbook and may not be redistributed or resold.

For complete coverage, always consult the official text.

Welcome back to The Deep Dive.

We're here to help you get informed, get prepared.

And I want to start us off today with a quote, one that really gets to the heart of architecture.

Quality is not what happens when what you do matches your intentions.

It is what happens when what you do matches your customers' expectations.

That really sets the stage perfectly, doesn't it?

Because, you know, every architect learns the standard quality attributes, performance, security, availability, the usual suspects.

Right, the A -list, as we sometimes call them.

Exactly.

But what really marks out a great architect, I think, is dealing with the unexpected, the stuff that isn't on the standard list.

So today we're diving into everything else, those custom requirements, the X abilities, and figuring out, well, how do you actually handle them when there's no ready -made playbook?

That's the core mission, absolutely.

For those common QAs, we have processes, right?

Define it, specify it with scenarios, use known tactics.

But when something new crops up, something really specific to your project or customer, you need a solid engineering approach.

So our goal today is to show you, the listener, how to build that same robust portfolio, you know, definition, specification, design for any quality attribute, no matter how unique it seems at first.

And the material we're digging into today seems set up nicely for that.

First, we'll sort of classify this bigger universe of QAs, and then we'll walk through the actual steps, the playbook, for designing for these new ones.

Okay, so let's get grounded first.

Those traditional A -list QAs, they usually fall into, what, two main buckets.

You've got things you measure when the system's running, like performance or security.

Right, the operational qualities.

And then you have qualities that measure the development project itself, like modifiability or testability.

Exactly.

But what's really fascinating now are these emerging categories.

They measure the architecture itself, or even the wider business context around it.

It's not just about the code anymore, or even just the running system.

Interesting.

So architects now have to think about how the design interacts with the real world in new ways.

Precisely.

These are qualities of the architecture itself.

Okay, what's in this new bucket then, these quality attributes of the architecture?

Well, there are three key examples discussed.

First up is buildability.

Buildability.

Okay, what's that?

It's basically a measure of how efficiently you can turn that architecture blueprint into an actual working product.

Think cost, think time required, just to realize the design.

So you're evaluating the architecture before anyone's even written the line of code.

That's the idea.

But hang on, if it's about cost and time, isn't that just, you know, project management, standard metrics?

Where's the architectural part?

Ah, good question.

It is architectural because the structure itself matters.

A really complex or maybe poorly defined architecture,

it's just inherently going to cost more and take longer to build, right, no matter how good your programmers are.

The blueprint itself dictates effort.

Got it.

Okay, that makes sense.

What's next?

Second, we have conceptual integrity.

This is all about the internal consistency of the design.

Right, the idea that you should do the same thing in the same way everywhere.

Exactly, like standardizing how you handle errors or how components talk to each other.

Less variation is generally more here.

Keeps things simpler, reduces surprises,

and probably bugs.

Absolutely.

Standardization lowers the cognitive load.

And the third one, which I find particularly interesting, is marketability.

Marketability in architecture.

Yes, it acknowledges a sometimes uncomfortable reality.

The perception of your architecture, totally separate from its technical merits, can actually drive adoption or sales.

Okay, the buzzword bingo effect.

So if like microservices are hot right now or a specific cloud provider.

Bingo.

Organizations might feel pressure to adopt that style of architecture, even if technically something else might be a better fit, just because it's perceived as modern or desirable.

It's marketable.

Wow, that's a tough constraint for an architect to deal with.

It is, and it's critical for the business side sometimes.

Okay, moving on.

Another category is qualities measured by the development project, but with a specific twist.

Development distributability.

Development distributability.

Okay, give us the plain English translation for that one.

Okay, this is basically about designing your software so that teams spread all over the globe can actually work on it effectively.

Think overcoming geographical barriers, painful time zone differences.

Right.

Less need for everyone to be on a call at 3 a .m.

Exactly.

Architecturally, it means designing your subsystems, your components, to have really low coupling.

Not just in the code, but in the data models too.

Why low coupling specifically?

Because that minimizes how much those distributed teams need to constantly coordinate.

If team A in Austin can work on their piece without constantly needing input from team B in Bangalore, things move faster.

The key is aligning the architectural structure with the social or business structure of the project.

That's a perfect example of a modern QA.

You wouldn't find that on a list from 20 years ago, but it's vital now.

Absolutely vital for many companies.

And then finally, there's the category of system quality attributes.

This is where software architecture impacts physical systems.

You mean like cars or smart thermostats or medical devices?

Precisely.

Think about it.

If your software is really inefficient, maybe it needs way more processing power.

That could force the product team to use a faster but maybe hotter or heavier processor.

Or maybe it drains the battery faster.

So suddenly, the software architect's decisions are affecting the physical weight, power consumption, maybe even the physical size of the device.

That feels far removed from just coding.

It is, but the influence is absolutely there and unavoidable.

The source uses a great analogy.

You can't run the latest super demanding software on, say, grandpa's laptop, right?

No matter how clever your code is, the hardware puts a fundamental limit on performance.

Okay, makes sense.

Or think about security.

Sometimes for a physical device, locking the room it's in physical security is actually more effective than any software protection you could add.

The point is the software architect needs to understand and contribute positively to the quality attributes of the whole system, physical parts included.

Okay, so this universe of qualities is clearly huge and complex.

You'd think logically there must be some kind of master list, right?

Something we can all just refer to.

And the source material mentions one, the ISO IEC 25010 standard square, they call it.

System and software quality models.

Yeah, square.

And it is incredibly comprehensive.

The product quality model part lists these big categories, functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability.

That sounds pretty exhaustive.

It is.

And under each of those, they drill down into dozens of sub -characteristics,

like non -repudiation is listed as a sub -characteristic of security.

On the surface, it looks like the ultimate guide.

But, I sense a but coming.

While these lists look definitive, they have some pretty significant drawbacks that architects really need to be aware of.

Exactly.

The first big problem is simply incompleteness.

No list, however long or detailed, can ever capture every possible quality attribute that might matter in a specific context.

Brontex is everything.

Absolutely.

The source gives this great little anecdote about IO ability.

IO ability?

What on earth is that?

It was a real QA for a specific project.

They needed to design the architecture in a way that would help them attract and keep talented developers in Iowa.

That was a critical business goal, directly impacting architectural choices.

But you will never find IO ability on an ISO standard list.

Customer expectations are just too context specific.

That's a brilliant example.

Yeah.

Okay, so incompleteness is one issue.

What else?

The second drawback is the almost inevitable controversy and terminology wars these lists generate.

People start arguing.

Is modularity really a quality or is it a strategy to achieve other qualities?

Is availability just part of reliability or is it separate?

Ah, the academic debates.

Precisely.

And honestly, arguing about those definitions often wastes precious time that you could be spending actually designing the system to meet the real needs.

Good point.

Focus on the problem, not the label.

Right.

And BIRD, these standards often try to create these neat boxes, these squishy taxonomies where each QA fits perfectly into one category.

But reality is messy.

How so?

Think about a denial of service attack.

Does it impact security?

Yes.

Does it impact availability?

Absolutely.

Performance?

Usually.

Usability?

Definitely, if the system's down.

So trying to force it into just one box is kind of pointless and doesn't reflect reality.

QAs are interconnected.

Okay, so if these big checklists are incomplete, cause arguments and have fuzzy categories, what's the main takeaway for architects?

Should we just ignore them?

Not ignore them entirely, but understand their limitations.

The core lesson is this.

QA names by themselves are basically useless.

They're just starting points, invitations to have a deeper conversation.

It's the scenarios that matter.

Exactly.

Scenarios give you the precision, the measurability, the testability you need.

Use lists like ISO 25010 as helpful reminders.

Oh, yeah, did we think about portability?

But don't get bogged down in their specific terminology or think they replace the hard work of context specific analysis.

Okay, that makes a lot of sense.

Names are invitations.

Scenarios are the actual substance.

So let's get practical.

If I'm faced with a totally new requirement, something unprecedented, like say manageability in a specific way or that development distributability you mentioned, how do I start building that portfolio?

What's the playbook for the X ability?

Okay.

There's a clear, pretty straightforward, three -step engineering process outlined.

Step one, capture scenarios for the new quality attribute.

Right.

Back to scenarios.

How do you capture them for something brand new?

It starts with talking to people, interviewing stakeholders.

You need to build what the source calls attribute characterizations.

Understand what they mean by say manageability.

Then you need to refine that potentially vague QA into clearer, hopefully measurable sub attributes.

Like you did with development distributability,

breaking it down.

Exactly.

You broke it down into software segmentation, composition, team coordination.

Once you have those sub attributes, then you can craft specific scenarios for each, define the stimulus, what happens, the response, what should the system do, and crucially the measure.

How do we quantify success?

Then you generalize those specific cases into a general scenario for the attribute.

So you ground the abstract idea in concrete testable examples.

Okay.

Step one, capture scenarios.

What's step two?

Step two, model the quality attribute.

Now model might sound intimidating, like complex math.

Yeah.

My eyes glazed over slightly there.

No, it doesn't have to be super complex.

The goal of the model here is simply to understand what factors the quality attribute is sensitive to, what are the parameters that influence it, and then what architectural characteristics affect those parameters.

Can you give an example?

Sure.

Think about modifiability.

A simple model would say it's a function of basically how many different places in the code you need to touch to make a change and how interconnected or coupled those places are.

Fewer places, lower coupling means higher modifiability.

That's the model.

Okay.

That's manageable.

What about something more quantifiable, like performance?

For performance, the source introduces a really powerful concept, the generic queuing model.

You don't need to be a queuing theory expert, but verbally you can picture it, right?

Requests arrive at a system.

They might have to wait in a line, a queue.

Okay.

And then they get processed or serviced by some resource, like a server or a database.

Right.

That basic flow happens everywhere in computer systems.

It does.

And the real power of thinking in terms of this model isn't the math itself.

It's that it helps identify a bounded set of parameters that affect the key outcome, which is usually latency or throughput.

A bounded set, meaning there aren't infinite things to worry about.

Exactly.

For performance, based on this model, there are essentially seven key parameters architects need to focus on.

These become your design lovers.

Okay.

What are they?

The seven knobs.

They are arrival rate, how fast requests come in, queuing discipline, like first and first out,

scheduling algorithm, how work is assigned,

service time, how long processing takes,

topology, how resources are connected, network bandwidth, and the routing algorithm, how requests find resources.

So the model tells us these are the seven things that matter for performance.

If I want to improve performance, I need to make architectural decisions that positively affect one or more of these seven parameters.

That's precisely it.

It makes the design problem tractable.

For example, choosing a specific load balancing strategy directly impacts the routing algorithm parameter.

Deciding to add more servers dynamically during peak load changes the topology.

Got it.

Scenarios first, then model to find the sensitive parameters.

Which leads naturally to step three, assemble design approaches for the new quality attribute.

Now that you know the parameters that matter from step two, you need to figure out the specific architectural mechanisms, the tactics, the patterns that you can use to influence them.

So for each of those seven performance parameters, for instance, you'd list ways to tackle it You got it.

You systematically go through each parameter identified by your model and enumerate the design decisions, the tactics, the patterns that affect it.

Where do you find these mechanisms or tactics, especially for a new QA?

There are a few ways.

You can revisit familiar tactics you already know and ask, hmm, how might this affect my new IO ability parameter?

You can search the literature or blogs using terms related to your QA sub attributes, see how others have successfully solved similar problems, and of course, talk to experts if you can find them.

And the big benefit here, the payoff for this three step process.

The crucial benefit is that it makes the potentially overwhelming problem of designing for some new fuzzy X ability tractable.

Instead of staring into the void, you now have a finite, reasonably small list of parameters to worry about and a process for finding concrete architectural decisions you need to make to achieve the quality.

You've turned a vague requirement into a manageable engineering task.

Hashtags, tags, tags, outro.

So wrapping this all up, I think the core insight we really want you to take away is this defining and achieving quality isn't some rigid academic exercise where you just tick boxes on a standard checklist.

It really is a collaborative context driven process.

Right.

It starts with the customer's needs, not a generic list.

Exactly.

We have to move beyond just the names of qualities.

We need precise scenarios.

We need to understand the underlying sensitivity through modeling.

And then we need to identify targeted design mechanisms, the tactics and patterns to actually control and achieve any required X ability that the real world throws at us.

And thinking about that methodology, especially the modeling and tactics part, it really brings up a fundamental tension in architecture that the sources touch on, doesn't it?

We know that tactics that help during development,

like separating things for better modifiability.

Separative concerns, yeah.

Often in direct conflict with tactics that boost runtime performance, which often involve putting related things together, maybe co -locating them.

That's a classic trade -off, modifiability versus performance.

So the provocative thought to leave you with today is, must it always be such a direct conflict?

Is there a more principled, maybe even quantifiable way to manage these fundamental architectural trade -offs?

Or is it always going to feel a bit like a zero -sum game where improving one inevitably hurts the other?

Something to perhaps mull over on your next project.

Thank you so much for joining us for this deep dive into working with those custom, sometimes tricky, quality attributes.

We hope you feel better equipped now to tackle any X abilities that come your way.