Sponsored Link •
Luke Hohmann talks with Bill Venners about mapping software architecture to human needs, choosing languages for social reasons, and selecting the appropriate architectural granularity.
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: In Part I of this interview, you said that an architecture is good to the extent it is fit for the uses to which it is applied. To what extent does an architecture also need to fit the team that's working on it?
Luke Hohmann: This is loosely called Conway's law. In a paper published in 1968, Melvin Conway wrote:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
I like to extend Conway's law to talk not just about communication structures, but also about human need.
For example, as a manager I once had to choose between two competing architectures for a project that was to be built by two teams, one in Germany and one in the U.S. In the first option, the U.S. team would do requirements analysis, design, and implementation of the architecture, and German team would build a component that fit within that architecture. In the second option, both teams would do architectural analysis, design, and implementation, and then we'd link up the two subsystems through a well-defined API. I chose the second option, because the team in Germany was used to doing architectural-level analysis, design, and implementation. I think an architecture needs to honor a large degree of human desires and motivations beyond just the communication constraints that are talked about by Conway's law.
Another aspect of matching architecture to human needs is matching roles and responsibilities of the people building a system to the appropriate parts of the architecture. Some pundits say that everyone likes to do everything, but that's not true. I suspect that a lot of people who write about architecture, although they are very smart, have never managed large teams. I've managed a 60-person team, and I personally know UI guys who would never get near a database, because they think databases are "stupid". And I know many database developers who would never go near a UI. The last thing these database people want to do is the full architectural stack. They've spent their life becoming an expert at Oracle. And you know what? They are an expert at Oracle. They aren't going to be an expert at UI design, and given what they would normally design for a UI, you wouldn't want them to be touching the UI anyway. When you look at the stack in your architecture, and then you look at this mass of people on your team, the architecture and the people have to match. Otherwise you'll have problems.