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

In this fourth installment, Hohmann discusses the social role of software architects,
the value of sticking with a product release after release, and the importance of domain knowledge.

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.

Sticking with a Product Release after Release

Bill Venners: In your book Beyond Software Architecture,
you write, "You're not an architect after your very first job. You're not an architect
after the first release. There is simply no substitute for sticking with a problem
long enough to receive and process the feedback generated through customer
use of your system." What kinds of lessons can be learned through actually
seeing the results of your decisions at a much later time that you wouldn't learn
otherwise?

Luke Hohmann: Let's compare two candidates whom we are considering
hiring for one open position. The first person says, "Hi Luke, here's my resume.
I was the architect for this system. I did it, and then I moved on. Then I did this
system, and I moved on. I did this other system, and I moved on." That person
has the advantage of seeing different problems. I'll give them that. It's not one
year of experience five times, it's five different kinds of experiences. But let's
compare that to the other person, who says. "Hey look, I did this system
through three releases, and I did this system through two releases, and then I
did this system through four releases." I can have a qualitatively different
conversation with that second person. I can ask, "What did you learn about the
first system that informed your choices for the second?" What did the first person
learn about the consequences of their decision that helped them
make a better choice for the next system? Nothing, because they weren't around.

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. Is it better to give each table a column named <table
name>id or id? Which is better? A person who sticks
with a product as the database schema migrates and changes over time will
be able to give you an answer.

The Importance of Domain Knowledge

Bill Venners: In your book, Beyond Software Architecture,
you write, "The requirement of domain knowledge for a [technical architect] is
so strong, that few developers can be promoted to this position until they have
considerable experience and skill building systems in the specified domain."
Why is domain knowledge important? Why isn't good general knowledge about
software development sufficient?

Luke Hohmann: In the field of cognitive psychology, there is a
tremendous amount of literature that says that domain knowledge trumps
technical knowledge in many endeavors, including software. Almost invariably,
the ability to make correct decisions about the handling of a given issue in a
given domain is based not on technical skills, but on domain skills.
I discuss this extensively in my first book, Journey of the Software Professional.

Bill Venners: Can you give an example of the importance of domain knowledge in software?

Luke Hohmann: I am working right now with a company that provides
analysis tools for engine performance, and driver performance of the engine,
because engine performance is partly correlated to how the driver drives it. One
of the issues is idle time. If you can lower your idle time, you lower your costs.
One of the requirements of our software, therefore, was to measure the idle
time of the engine.

I didn't know how to measure idle time, so I floated an idea to the development
team of how we should do it. Other developers came up with some alternative approaches,
and we compared these to what a customer had provided. We eventually settled on one,
but, before implementing it, we took it to a major customer to see what they thought.

I learned that my approach was wrong, as were the other ideas floated
by the development team. It took a customer -- an expert in the domain, to
tell us "This is how you measure idle time," and, "This is why you
measure idle time this way, because this is the behavior that we want to be
able to control."

For example, should the software measure idle time at a stop light? The
developers said, "No, you should have a threshold below which you throw
away idle time, because the driver can't control idle time at a stop light." And the
domain experts in the industry said, "Actually no, you never want to throw
any data away. What you want to do is capture all the idle time. As a
developer were expecting us to be able to drive idle time to zero. We don't.
We expect idle time to have different values based on the terrain and the climate.
We don't expect idle time to ever be zero." I like to think of myself as a fairly
good developer. I'm strong on the technical side. In this domain I'm weak on
the domain side. In this situation, strong technical skills would have
implemented a completely wrong domain solution. Thank goodness we triple-checked
with a committed customer.

Bill Venners: This is another way in which the right way to
design something depends on the situation, in this case, the domain.

Luke Hohmann: Absolutely. Let's leave the business domain out of it,
and just look at the technical side. The idioms and practices for programming
embedded systems are extremely different than those of multi-terabyte data
warehousing. If I'm processing payroll receipts for Safeway, it's pretty different
than building BREW applications on a BREW phone, right? Independent of the
domain that I'm servicing, the technical infrastructure of those two kinds of
applications is very different. If you are an expert in one, are you by definition an
expert in the other? No.

Bill Venners: So as a developer, how do you become knowledgeable in
both a technical and a business domain? How do you decide where to focus?

Luke Hohmann: The trick is to have enough of a broad base of
experience that you can pick the area of technology that you, by interest and
skill, are suited to do. In other words, find something that you're reasonably
good at that you also like as an interest. Become skillful in that area. If a team
chooses C++, fine, but learn the bloody language. Learn how to use a copy
constructor. Learn how to use an assignment operator. Learn the idioms that
create high quality C++ code. Then focus on your domain skills. If you're in
real estate, take a real estate class. If you're in graphic arts, learn how artists
use pallets.

As a consultant, I do ask my
clients, "What magazines do you read?" And then I'll read those magazines. I
want to learn what they do. How often have you walked into a place and they're
just zinging acronyms back and forth? And your sitting there thinking, "What the
hell is a GRB?" Well that's part of what it means to be a domain expert: knowing
what a GRB is.

The person who is an expert both technically and in the domain is a master in
both dimensions. In your professional development, you want to zig-zag between them. You want to start with the
technical foundation. It's why you take classes and learn the idioms of C++, or whatever
technology you've chosen. It's
why you learn how to program safely in C++. And then you start applying that
technical knowledge to your domain. As you build experience in that domain,
you start to settle in on areas that will be the focus of your career.

Next Week

Come back Monday, April 12 for the next installment of this conversation with
Luke Hohmann.
If you'd like to receive a brief weekly email
announcing new articles at Artima.com, please subscribe to
the Artima Newsletter.

Talk Back!

Have an opinion about the design principles presented in this article?
Discuss this article in the Articles Forum topic,
Becoming an Architect.