Software architecture, to me, isn't a discipline separate from Salesforce - it's the layer of decision-making above it. The question isn't "how do I implement this," it's "what system does this business need two years from now, given what we know today."

That means deciding boundaries: what stays inside the platform, what becomes an external service, where coupling is acceptable and where it becomes a permanent maintenance problem. None of these decisions are free - they all trade velocity for rigidity, or flexibility for complexity, and the architect's job is to make that trade explicit, not hide it behind a market pattern applied without question.

I prefer architecture that the people implementing it can explain back to me - if a decision only makes sense to the person who designed it, it's probably more sophisticated than the actual problem requires. That comes directly from having gone through administration, development, and consulting before reaching architecture: I know the cost of inheriting a decision that looked elegant on a whiteboard.

As an independent consultant, I apply this outside the Salesforce ecosystem too - making technical decisions traceable and reviewable isn't specific to one platform.