What is Architecture?

The main point of this chapter seems to simply drive home the point that when you’re designing a system it’s not all about what technology stack you’ll be using, or how you’re going to split up responsibilities into modules on the client side, but also to make absolutely sure you and your team have a firm grasp on why you’re building something the way you are. Without this information it’s too easy for the architect or the engineers to build something that violates the intended design and solution, and to make checking for this sort of thing simpler, documentation should be made available and be kept up to date.

@Randy: I can’t think of a single concrete example, but I took that section more to mean that the Architect should have a good understanding of which components can be decoupled the easiest. I mean, in a magical world of infinite budgets and staffing you would be able to assign a single person to each of these modules. Or maybe they’re just using a different staffing model where what could (and, you’re right, probably should) be two different jobs are unified under the heading of “Architect”.