[YZF]

In an existing system some combination of these attributes:

- High quality (e.g. low number of issues hit by customers, resilient to failures, efficient, secure etc.)

- Easy to maintain (well organized, broken down in a sensible way into components or layers)

- Easy to extend/adapt to future requirements (i.e. the designer was able to anticipate the likely direction of the system and account for that in the design)

Automated testing feels a bit orthogonal to me but a system that is easy to test is likely one with a better architecture. It's not strictly part of what I'd call architecture.

Less different technologies - YES!

Runs on fewer machines is a sign of an efficient/performant design. Less well designed systems exhibit bloat that is often made up for by running on more machines.

[jeffreygoesto]

We sometimes point to ISO25010 [0] if management or not so experienced devs are asking. It contains a good deal of the relevant "qualities" you keep an eye on for quality.

[0] https://iso25000.com/index.php/en/iso-25000-standards/iso-25...

[sunrunner]

That looks like a whole lot of dimensions to measure without providing any clear way of actually doing so. Which I guess is the point? But what do management or less experienced devs actually do with the information in the standard after they’ve read it?

[jeffreygoesto]

You put all as cards on the table and have management pick their top three or five and their order. Can be extended to a full day workshop with your stakeholders, if useful. It gives you a relatively complete taxonomy and you can speak about it with the same vocabulary which is a benefit on its own also.

[bluefirebrand]

Hopefully, they ask more experienced devs "what do we do to accomplish this" and hopefully the devs on their team actually are experienced enough to have good answers