97 Things Every Software Architect Should Know

Chapter 88. Don't Be a Problem Solver

Eben Hewitt is a principal on the architecture team at a multibillion-dollar national retail company, where he is currently focused on designing and implementing its service-oriented architecture. He is the author of the upcoming Java SOA Cookbook from O'Reilly.

—Eben Hewitt

WITH SOME EXCEPTIONS, ARCHITECTS USED TO BE DEVELOPERS. Developers get rewarded for solving programming problems, which are more local in scope than architectural problems. Many programming problems are small, tricky, algorithmic problems. Such problems are frequently presented in programming interviews, books, and university courses as if the problems exist in a vacuum. The trickiness is alluring and seductive. Over time, we begin to accept such problems out of hand. We do not ask if this problem is meaningful, or interesting, or useful, or ethical. We are not rewarded for considering the relation of this problem to a larger landscape. We are trained to focus only on our solution, which is aggravated by the fact that solving hard problems is hard. We leap into action in programming interviews, which often begin by presenting us with some number of jelly beans we are meant to sort according to an arbitrary set of constraints. We learn not to question the constraints; they are a pedagogical tool, intended to lead us to discover what the teacher or interviewer or mentor already ...