Most if not all that I read on architecture, design, etc. is oriented at programming teams. How might your approach to software architecture apply to the lone developer, or (in my case) the developer whose product(s) is almost a standalone component? In my case, I'm responsible for several thin client apps to a large, complex, legacy server backend. There are thick clients--Windows, Mac, and XWindows--and me, the web stuff (yes, we all have some input on the server, but change there comes slowly).
The thick clients are pretty tightly wound, but when folks think web, they think dynamic, flexible, customized, integrate with my pages, etc. The discussions I read and many tools/APIs start with the assumption of a team the divides up front-end, back-end, CSS, mobile, etc. All this makes for a lot of layers for one person to code and navigate. What does this book offer for someone in such a situation?
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we are is hell, And where hell is, there must we ever be" --Christopher Marlowe, Doctor Faustus (v, 121-24)
I think being a single developer is no excuse to ignore architecture. You can have fewer layers and take up multiple roles at one.
When you do grow and decide to have multiple devs, it might be difficult to refactor architecture. So it's still good idea to have proper architecture.
The book is essentially about how to introduce a minimal set of lightweight software architecture practices; including "just enough" up front design, communicating the architecture using a collection of simple sketches and ensuring that any important risks are catered for. In my view, these practices should be undertaken for software projects of every shape and size, including those with a single developer. Of course, you are a single developer today, this might change next month.
The trick, particularly if you're a single developer, is to ensure that any software architecture practices you do follow add real value. The same is true of how you decompose your codebase - there are no correct answers here, except that you need to identify the trade-offs that you're making. Lots of layers potentially provides you with some nice flexibility and agility, but the cost is added complexity. A simpler solution may work well now, but potentially at the expense of future extensibility.
In terms of some concrete advice, it sounds like you work in a large organisation. If this is the case, and these systems are mission-critical, what would happen if you left the organisation? Is there enough supplementary documentation for somebody else to pick up where you left off? Would somebody else be able to understand the structure of the code? Is the architecture that you have now "working"? Perhaps starting to map out the architecture of your system(s) using some simple diagrams (e.g. my C4 approach) will give you a starting point for answering questions about layering, etc. I hope that helps, but feel free to reply if it doesn't!