The Artima Developer Community
Interviews | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

Becoming an Architect
A Conversation with Luke Hohmann, Part IV
by Bill Venners
April 5, 2004

Page 1 of 3  >>


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, Hohmann discusses software architecture in the context of business.

The Social Role of Software Architects

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 perspective.

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 <table name>id 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 team.

Page 1 of 3  >>

Interviews | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use