I second this and would also recommend the Software Architecture Book Club podcast where the authors cover a chapter each episode (Head First Software Architecture and then Fundamentals of Software Architecture).

I would also recommend the InfoQ architecture RSS feed to stay current.

This is a bit beyond architecture, but being competent to build a mathematically bug-free API is probably something that few programmers would even bother trying to compete-against..

https://leanpub.com/algebra-driven-design

I think there is a fundamental mis-framing, throughout the entire software/development understanding..

I think that the architecture needs to be simultaneously agilely-devloped, but into an executable-model, a kind of toy-implimentation, so it is easy to change the architecture, low-cost, BEFORE one converts it into load-bearing, & therefore unchangeable architecture ( architecture’s the hardest thing to change, as it’s most-fundamental )

So, I think that the proper way is to do it in 2 stages:

This is part of an idea from years ago: I read in a Wiley GAAP book that I happened to be glancing into, that it’s a violation of GAAP to prototype any project in any language other than the final-implimentation-language, & expense that prototype.

Which is totally insane!

Prototype in the highest-level-language you can, to get the domain+architecture right, then reimpliment what you have to in the most production-efficient/effective language for that project.

GAAP ( of that year ) is categorically wrong: it penalizes optimal-prototyping.

It was years-later before I discovered that an English mathematician ( roundish ginger, worked in Glasgow, no idea what his name was, sorry ) had studied the difference between complex projects which worked vs ones which died, & it was the visual-spacial-representation-of-the-model, & the complete-coverage executable-model which made the successes win.

So, I just put those ideas together.

_ /\ _