Sponsored Link •
Luke Hohmann talks with Bill Venners about the social role of software architects, the value of sticking with a product release after release, and the importance of domain knowledge.
Luke Hohmann is a management consultant who helps his clients bridge the gap that often exists between business and technology. In his past experience, he has played many of the varied roles required by successful software product development organizations, including development, marketing, professional services, sales, customer care, and business development. Hohmann currently focuses his efforts on enterprise class software systems. He is the author of Journey of the Software Professional: A Sociology of Software Development (Prentice-Hall, 1997), which blends cognitive pyschology and organizational behavior into a model for managing the human side of software development. He is also the author of Beyond Software Architecture: Creating and Sustaining Winning Solutions (Addison-Wesley, 2003), which discusses software architecture in a business context.
On March 8, 2004, Bill Venners met with Luke Hohmann in Sunnyvale, California. In this interview, which will be published in multiple installments on Artima.com, Hohmann discusses software architecture in the context of business.
Bill Venners: What's the role of a software 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."
An architecture is like a dirt road. The first time a car drives over it, the road looks about the same. By the time the 10,000th car drives over it, though, there will be grooves in the road. As an architecture mature, it gets grooves.
For example, one kind of groove that is common in architecture is error handling strategy. Whether you handle errors by returning error codes or throwing exceptions is part of your architecture. In practice, most teams will choose one error handling mechanism as the dominant approach, the other as the subordinate approach, because you often need to use both. Among the roles of the architect is choosing the dominant approach to error handling, keeping the flame of the dominant approach, and educating the team on when the subordinate approach is an acceptable alternative. That's one aspect of the architect's job, and that's a social role.
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
<table name>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
Bill Venners: What do you mean by conceptual integrity?
Luke Hohmann: That goes back to Frederick P. Brooks in his book,
The Mythical Man Month. Conceptual integrity means that one or
few minds are making the decisions, and the rest of the people associated
with the project honor the decisions that were made. I may have an opinion on
how to name table identifiers, but it's not like I would really care whether they
chose to give every table a column named
or one named
id, because at least there would be regularity.
The current approach requires you to have the schema in front of you, because
unless you magically remember which table does which thing, you've got to
look it up. That little bit of friction is an example of a technical architect not being
involved. So the technical architect is a person who helps make sure the big
picture decisions are made, and then keeps them consistent throughout the