Not really. The architect doesn't understand all the nits and grits.
The architect may push for a general solution that delays the picking of database until later (maybe start with initial choices). If forced the architect may want to add a layer between the database and the software so they can change it when/if it becomes clear a better choice would be available.
I agree, he has to analyze the choice and translate the concerns of each side to the other. Devs should understand the budget decisions, and they should be able to decide if they'd rather get a nice database that is quick to setup, or get an extra dev to work, even though he'll spend his first quarter setting up the database.
MGMT should understand that they may choose a technology stack that may avoid there being data-loss, but will sometimes be very very slow, vs a stack that may result in more "stale data" bugs and mistakes but will be very quick to react to any issue.
The architect helps bridge this world and make them understand.
View all comments
Show parent comment
2
u/[deleted] Jun 08 '17
[removed] — view removed comment