Becoming an Architect

Becoming an Architect Luke Hohmann: Most people think of architecture as technical, and the architect as a technical person. And absolutely, the architect must be technical. But there's also a social aspect of the architect role that I think is not well communicated or understood. The architect is the person who will say, 'This is the way we do things.' [...] Conversely, you can tell when a system hasn't had an architect, because it lacks consistency in things like error handling, naming, and so on. In a system I'm working on right now, for example, I noticed that some of the database tables have a unique identifier column named id, other tables have a unique identifier column named id, and other tables do something completely different. So table foo would have a fooid column, and table bar would have an id column. I finally went to the development team and said, "Let me guess. You've had more than one DBA [Database Administrator] in your time here." And they said, "Oh yeah, we've had five of them." Every DBA had their own way of naming columns. They didn't have an architect to ensure a technical consistency in column naming. There wasn't a notion of conceptual integrity from a technical perspective. [...] Humans are failure machines. We're not success machines. We're failure machines. We fail all the time. And it's only through processing the feedback of our failure that we learn how to correct for them and do better. That is why it is important to stick with the choices you make and understand how well they worked.