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 5 hours ago | parent [-]

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 5 hours ago | parent [-]

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 2 hours ago \| parent \| next [-]
		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 4 hours ago \| parent \| prev [-]
		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