The Boundary Between Solutions Architecture and Detailed Engineering/Implementation

Overview

As established in “Solutions Architecture as a Practice,” Solutions Architecture itself stops short of detailed engineering. That principle is not unique to Solutions Architecture — it applies to every specialized architecture practice covered in the previous chapter. All forms of architecture go as deep as they need to into areas of engineering and implementation without actually completing that work themselves.

The depth actually reached, however, varies by practice. Technical/Technology Architecture and Application Architecture, in particular, often get into far more design and implementation detail than the overall Solution Set documents — simply because of the nature of their work. This does not mean they cross the boundary into engineering; it means the boundary sits further into the technical detail for these practices than it does for Solutions Architecture’s own overall Solution Set.

In every case, the resulting guidance — whether from Solutions Architecture directly or from one of the specialized practices it draws on — constrains Engineers and Developers on the key decisions they must follow. It is not, and is not meant to be, an exhaustive final specification.

Best Practice: Communicate the Boundary Explicitly at Handoff

When handing a Solution Set to engineering and development teams, be explicit about which decisions are constrained and which are intentionally left open. Ambiguity about where architecture’s authority ends and engineering’s begins creates false expectations of completeness on both sides.

Benefit(s)

An explicitly communicated boundary reduces friction and surprises at implementation time and sets realistic expectations with engineering teams about what has been decided versus what remains theirs to determine — distinct from, though related to, the broader case against undocumented improvisation made in “Solutions Architecture as a Practice.”