The Pragmatic Architect

I saw the following question on one of the forums I monitor:

Most often you would have come across a situation when you need to design a solution which is esoteric in nature and technically perfect, but ultimately undoable by the team you have (for development) or undoable due to unknown reasons.

What have you done in that scenario?

Have you designed applications that are doable today rather than tomorrow? Or have you designed applications that are technically perfect but doable only tomorrow and are bound to be a failure when developed by handicapped teams?

Which approach do you prefer as a Software Architect? Building perfect designs or building doable designs?

I think the answer is obvious -- I would go with doable architecture anytime. What I answered this guy was:

There is no use for a "undoable" design.it is just a waste of time and money.

The architect's role is to find a pragmatic solution that will satisfy as many as possible of the system's quality attributes (performance, availability etc.) required by the system. As an architect you need to strike a balance between these requirements the budget and time constraints and the capabilities of the team who will develop the solution.

If you have (or worse, you are or part part of ) an architect or architecture team that makes such decisions challenge them to evaluate their architecture early either on paper or better yet in code .I think there is no place for ivory tower architect in modern software development. Architects should be involved.

Posted by Arnon Rotem-Gal-Oz at 06:09 AM  Permalink