A Conversation with Luke Hohmann, Part V

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 Part I: Growing, Pruning, and Spiking Your Architecture, Hohmann discusses architecture and culture, the importance of completeness in new architectures, and implementing features in spikes.
• In Part II: Entropy Reduction, Hohmann discusses entropy reduction, the cost of change, and programming as choreography.
• In Part III: Human-Oriented Architecture, Hohmann discusses mapping software architecture to human needs, choosing languages for social reasons, and selecting the appropriate architectural granularity.
• In Part IV: Becoming an Architect, Hohmann discusses the social role of software architects, the value of sticking with a product release after release, and the importance of domain knowledge.
• In this fifth installment, Hohmann discusses the different roles of technical and marketing architects, the source of innovation, and the importance of pursuing the same vision of the future.

The Role of the Marketing Architect

Bill Venners: In your book, Beyond Software Architecture, you talk about two kinds of people involved with software architecture, tarchitects and marketects. What are tarchitects and marketects?

Luke Hohmann: The tarchitect is the technical architect, whose role it is to make technical architecture decisions and see that they're implemented consistently by the team. [See Part IV.] The marketect is the marketing architect, the person who will take the solution to the market. The marketect makes sure the solution that's been crafted meets the needs of the market—not just the functional and non-functional needs, but the full set of needs: the distribution, the pricing, the channel, the documentation, the education of the market and the customer, the idea that "new and improved" really means new and improved and gets promoted as such, and so on.

The Source of Innovation

Bill Venners: You say in your book, Beyond Software Architecture, that "Envisioning the future on behalf of customers, even when they can't articulate what they want, is the world-class marketect's key distinguishing feature." How can marketects and tarchitects envision the future on behalf of customers even when the customers can't articulate what they want?

Luke Hohmann: That's the source of innovation. I'll give you an example. At one point in my career I was working in the field of patent analysis, and I learned that citation analysis—how the different documents cite each other—is really important. I would see people draw out trees of citation relationships. At around the same time I saw the Inxight hyperbolic tree, and I put the two together. The Inxight hyperbolic tree was showing an org chart, but the nature of the citation relationship is also a hierarchy, so why not put the citation relationships in a tree? You could then see hundreds of thousands of citation relationships between documents. So I put the citation relationships in a tree, and the users loved it. It was one of those features where you think, "Wow, it's going to be hard to use," but it turned out it wasn't. The feature mapped into the users' model of how the documents are structured. It required virtually no training. Anyone (who knew how patents are structured) could pick it up.

No one had walked up to me and said, "Hey that's what I need." And no one actually said, "We have a problem understanding and looking at citation relationships." The idea came just from the ability to put two things together. That's a kind of envisioning the future that creates a better environment for the future. I even got a patent for it.

Pursuing Different Visions of the Future

Bill Venners: You write in your book, "If the marketect and tarchitect pursue different visions of the future, the total system will fail." Could you elaborate on why?

Luke Hohmann: We talked earlier [in Part I] about architecture being good relative to change. The Extreme Programming (XP) crowd says, "We're not going to worry about change," but that's not true. They worry about change all the time. When they say, "Ya ain't gonna need it," they implicitly make decisions that other people make explicitly. That's fine, but they are in fact making decisions. In the The Pragmatic Programmer, Andy Hunt and Dave Thomas talk much more explicitly about worrying about change. They'll say, "We think things are going to change here, so we put this extra flexibility in there, even though it is not changing now."

Both the XP crowd and the Pragmatic Programmer crowd are making a bet. Either bet is a future option: the option to not spend the money now, or the option to spend the money now so that the cost of future change presumably is less. If the Pragmatic guys make the bet to spend some money now, and they're right, we're all happy. If they're wrong, we may have some crud to take out or clean up. If the XP guys make the bet to not spend the money now, and they're right, then we haven't incurred the cost, and we're happy. If they're wrong, if it turns out you need to make the change, then you've got to go back and refactor and retrofit.

How well you make those decisions is typically a function of how well you know how to structure systems technically and how well you know the domain itself. If you know the domain, you know the nature of the changes in that domain. If you are Intuit building TurboTax, for example, you may know that certain sections of the tax code are more likely to change than other sections of the tax code. That doesn't mean that you don't make the tax code hard-coded throughout the product, but you might put a little bit more effort into making some of the tax code portions of the product a little more data driven than others. That kind of bet on the possibility of future changes, if pursued differently by the marketect and tarchitect, is going to cause problems. The marketect might say, "I want to take the system and into this new market. And what this new market needs is different from what the existing market needed. The technical architect might say, "I'm going to take a bet that the system is going to go over here." If they shoot into different spots, the architecture will be prepared to solve the problems of the wrong market.

Bill Venners: I see. The tarchitect is doing the technical architecture. The marketect is doing the business architecture. If they're going in two different directions, when the time comes that the marketect says, "Hey, we've got this great opportunity that I saw coming," it doesn't work.

Luke Hohmann: Right. It flat out doesn't work. A great example of when that divergence occurs is whenever a team says, "You can't have that for a full release," because usually these big architecture changes take at least one release to get through.

Bill Venners: "You can't have that for a full release," means, we weren't ready for it.

Luke Hohmann: And we've got to pay the price of a full release to get there. It's a sign that those people, the marketects and tarchitects, were not working in concert.

Next Week

Come back Monday, April 19 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.

Luke Hohmann is author of Beyond Software Architecture: Creating and Sustaining Winning Solutions, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0201775948/

Luke Hohmann is the author of Journey of the Software Professional: The Sociology of Software Development, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0132366134/

The Pragmatic Programmer's home page:
http://www.pragmaticprogrammer.com/

A good place to start looking into Extreme Programming is:
http://www.xprogramming.com/

Frederick P. Brooks classic book, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition), is is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0201835959/

The hyperbolic tree that Luke mentioned was from Inxight Software:
http://www.inxight.com

Talk back!

Have an opinion? Readers have already posted 3 comments about this article. Why not add yours?

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.