Comment by YZF
18 hours ago
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.
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...
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?
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.
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