Context:
An organization of Developers that needs strategic technical direction.
Forces:
Totalitarian control is viewed by most development teams as a draconian measure.
The right information must flow through the right roles.
Solution:
Create an Architect role. The Architect role should advise and control Developer roles, and should communicate closely with them. The Architect should also be in close touch with Customer.
Resulting Context:
This does for the architecture what the Patron pattern does for the organization: it provides technical focus, and a rallying point for technical work as well as market-related work.
There is a rich relationship between this pattern and Patron that should be explored.
Resentment can build against a totalitarian Architect; use patterns like Review the Architecture to temper this one.
Design Rationale:
We have no role called Designer because design is really the whole task. Managers fill a supporting role; empirically, they are rarely seen to control a process except during crises. While the Developer controls the process, the Architect controls the product. The Architect is a "chief Developer" (see pattern Architect Also Implements). Their responsibilities include understanding requirements, framing the major system structure, and controlling the long-term evolution of that structure.
The Architect controls the product in the visualization accompanying the pattern Engage QA.
"Les oeuvres d'un seul architect sont plus belles...que ceux d'ont plusiers ont taché de faire. -- Pascal, Pensées.
Next: Conway's Law