A Conversation with Luke Hohmann, Part VI

---

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 Part V: Marketects and Tarchitects, 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.
• In this sixth and final installment, Hohmann discusses the impact licensing models have on software architecture, the sustainability of open source business models, and the benefits of providing licensing options.

The Impact of Licensing Models on Architecture

Bill Venners: In your book, Beyond Software Architecture, you write, "One of the key embodiments of the marketecture, the business model and its licensing model, may have a tremendous impact on your architecture, imposing requirements throughout the system. More sobering is the fact that if your business model is the way you make money, picking the right one, licensing it the right way, and supporting it technically, are essential to a truly winning solution." How does software licensing model impact the software architecture?

Luke Hohmann: Lots of ways. More than we can cover in this interview. Let's look at just licensing. It's not just the way you're going to license the software, but the way you going to enforce the license and the degree to which you are going to enforce the terms and conditions of the license. Let's say you are selling consumer-class software, a market that's highly pirated, and you'd like to try an annual license. Most consumer-class software is sold on a perpetual license, because the people who are licensing it know it is hard to try and prevent people from using the software after a year. An enforceable annual license on consumer-class software would only work if you build in the mechanisms that say on activation, one year after using it, the software is not going to work anymore. It is easy to do poorly, hard to do well (I know, because I managed a team that did this). How that all fits together is a technical implication.

Here is another example. In consumer-class software you are typically allowed to install on multiple computers, but only one licensed individual is allowed to use the software on any one computer at any time. How can you enforce that? You really can't in consumer software. But in enterprise software, you could enforce that, because there you can build in or leverage an authentication system.

Getting the licensing model and architecture in sync is truly a conversation between a technical person and a marketing person:

Marketing person: I want to use concurrent licensing.

Technical person: OK, I can do that. Do you mean concurrent session licensing or concurrent user licensing.

Marketing person: Concurrent user.

Technical person: OK, great. This means that the same user can establish multiple sessions with the application. Is that OK?

Marketing person: Yeah.

Technical person: If the customer buys a ten concurrent user license, what happens when the eleventh user logs in?

Marketing person: Hmmm. I didn't think of that. Can you make a soft limit and a hard limit? Something like a 10% overage with an error message?

Technical person: Sure. But there has to be a limit, right? If not, then why should I bother building the technical infrastructure to enforce the license?

Marketing person: Yes, of course—we're not giving our software away. When the users hit the 10% overage, they get a warning message, prompting them to buy more licenses, but we let them log in. If they go over this, we error out.

All of those licensing choices affect the technical architecture in huge ways. Any business model that I've ever worked on has had a huge impact on the technical architecture, to the point where sometimes it prevents you from servicing a new market.

Bill Venners: What do you mean, "servicing a new market?"

Luke Hohmann: Let's say that I'm in marketing, and I want to attack a new market with my existing system. In my current market, customers license the software via concurrent users. In my new market, they don't think in terms of concurrent users, but in terms of how the system actually performs work for them. They want a transaction model.

This may sound good in marketing terms, but technically, you have to check to see if the original system can support both a concurrent user business model and a transaction business model. For example, does the current system have a way to track transactions that match the definition of the license? Can each transaction be uniquely identified? What about billing and auditing requirements? If the existing system was based on users, presumably the concept of a user is important in the transaction system. How will these be managed? My experience is that making these kinds of transitions is hard. They require changes to the architecture, and usually require at least one full release cycle to implement.

Open Source Business Models

Bill Venners: In your book, Beyond Software Architecture, you write, "As of the writing of this book, I know of no provable long-term sustainable business models for open source software."

Luke Hohmann: I think it's too early to see if a purely service-oriented model based on open source is economically stable. I think we have some evidence with companies like SleepyCat software that some open source business models proving sustainable. I'm not convinced that RedHat is sustainable. I hope that they are. It's just that a pure service-model offering is a really tricky business to get big and successful.

Bill Venners: Why?

Luke Hohmann: How many times have you had good service lately in your life? It's hard to give good service. Service models don't tend to scale very well, because they are typically based on people. Maintaining consistency of the delivery of the service via the people as you grow is very hard. Some of the companies who are in the open-source services business are not cash flow positive, and some of the companies who are cash flow positive have not yet burned through their accumulated debt. That's not to say I hope open source models don't succeed. I hope they do. I think the open source movement is great. It's offering choice and providing competition.

Joel on Software has a wonderful piece on the macro and microeconomics of open source. In a nutshell, if you've got $1000 to spend on a computer, and the operating system costs $200, you've got $800 to spend on the hardware. If the cost of the operating system is zero, then the hardware manufacturer can get $1000. So the goal of IBM pushing open source software has nothing to do with IBM being altruistic. If IBM drives the cost of the operating system to zero, they get more money for the hardware.

I want to be clear that I'm neither for nor against open source software. My comments are strictly based on the business implications of open source. And I'm not alone. Michael Cusumano, of MIT's Sloan School of Management, echoes my analysis in his new book The Business of Software. He writes: "Time will tell if for-profit software companies can make a business out of selling services and products that complement free software. So far, the results have not been promising". So, let's see how things turn out, and hope that open source continues to provide us with better software.

Providing Licensing Choices

Bill Venners: In your book, Beyond Software Architecture, you write, "Many companies practice Model T license and business model strategies. They create few business models, often only one, and expect each of their target markets to adopt it. Moreover they define relatively rigid licensing models, failing to realize that within a business model, market segments will pay to obtain certain kinds of rights, like the right to upgrade, or remove certain kinds of restrictions. Just as we want to choose the color of our cars, so customers want choice in how they license their software." What is a Model T licensing model, and what is the problem with it?

Luke Hohmann: The famous Henry Ford quote about the Model T is, "You can have any color you want, as long as it's black." Most software manufacturers say, "I'm happy to license you my software. It's a perpetual license, and this is how much it costs."

I'll give you an example. I recently had a project for which I needed to do some sound editing. Cool Edit, an audio editing product from Adobe, cost $99. I didn't really feel like spending $99, so I found a less full-featured piece of software I was willing to pay for that cost $29.

I can't speak to other people's purchase behavior, but whenever I think I need something, I have a price point in my mind, relative to the duration of use, that I feel comfortable paying. I wanted sound editing software for an urgent project that I needed to get done quickly. I had to take transcripts of tapes and edit them. I wasn't by any means planning to become a sound engineer. I was willing to spend about $30 or $40 to get a decent piece of software. I actually ended up spending $60, because I downloaded one piece of software for $29, and it didn't really meet my needs. I subsequently downloaded another piece of software for $29, and it was great. I loved it. Neither of these products were as good as Cool Edit, according to the independent comparisons I read on the websites, but Cool Edit was $99, and I just wasn't going to pay $99. So by only offering Cool Edit as a perpetual license, Adobe missed me as a market. If Adobe would have offered Cool Edit as a rental, I would have rented the software a week or two.

Bill Venners: For a software rental, how does a company decide how much to charge for what period of time?

Luke Hohmann: That requires a careful analysis. But it can be done. In the physical goods world, you can rent pretty much anything. Go to United Rentals. You can rent brakes, lawn mowers, backhoes, saws, hammers, screwdrivers. You can rent just about anything. Over the years, they have worked out the right way to rent something. This is hard work, but if we have figured out how to do this in the physical world, I'm confident we can figure out how to do this in software.

My point is that most companies go to market with very few options. They think they have a lot of options, but they really have very few. And because of that, they don't know what markets they are missing, because they aren't giving themselves a chance to go meet the needs of those markets.

Bill Venners: How do you balance the benefit that licensing options provide with the complexity they add to the buyer's decision making process?

Luke Hohmann: How do people make choices in the physical world, where there is a complex set of options right now? I can buy a lawnmower, rent a lawnmower, or hire a lawn service.

Markets tend to complexity of choice. Perhaps surprisingly, part of that is software driven. If you look at the average supermarket of the 50s, they only stocked between 5000 and 8000 items, because that was the most that human bookkeeping could handle. A large supermarket nowadays stocks between 100,000 to 130,000 items. Why are there 27 kinds of mustard? Well, because we have software to handle it. Are you happy that there are 27 kinds of mustard? I am, because I get the mustard that I like, and you get the mustard that you like. We could apply this analysis to numerous other domains. Production runs on car models are shorter because software enables shorter design and manufacturing runs. We can order the car we want, with the options we want, and get it in 6-8 weeks (or less) because software is powering the supply chain. As consumers, we're generally happier with choice.

Therefore, the concern that people can't handle the complexity of the choice of what software to get at what license point is only a temporary condition of the market itself. It's only the fact that people don't routinely have the choice of renting software that's causing rentals to be complex. If all software were offered as a rental overnight, there would be a high degree of uncertainty. Over time consumers would learn that they could get different kinds of software with rental, and they could make better choices.

For example, I would never rent Microsoft Office, because I use it every day. Usually in rental markets, you're going to pay more for the rental. I can buy a rake for $40, but I can rent it for $10 a day. If I'm going to use the rake for 2 days, it's a deal to rent. If I'm going to use it for more than two days, it's a deal to buy. There's no way Microsoft could rent Office lower than I would buy it for, but sound editing is a different story. Software for one-time tasks is a different story.

Of course, I'm grossly simplifying the complex infrastructure that would be required to manage rentals and make this seamless for the average user. There are a whole host of issues that need to be managed, including billing, managing data, and so forth. I'm betting that the entertainment industry will be leading the charge to really figure out how to do rentals, and the lessons learned there will slowly work their want into commercial software.

Bill Venners: You indicate in your book that more flexible business models can help maximize revenue, especially for mature markets. Does it follow then, that it's more important in the early stages of a market to balance keeping things simple with offering many licensing options? Prospective customers don't have a lot of time to spend with you. You may have two minutes to make your sales pitch, and if you have to spend an hour explaining all your options, you could be in trouble.

Luke Hohmann:Yes. Any market, if it's successful, will complexify over time. Too many choices is just not what you want at the beginning. As the markets mature, you want to have more choices to go after more niches.

Summary

Bill Venners: How would you summarize the main ideas you are trying to get across in your book?

Luke Hohmann: I've been asked this before, and, to be truthful, I find it hard to summarize the book. However, my good friend and colleague Elisabeth Hendrickson (who runs Quality Tree Software) summarized the book this way:

"There's no business decision that doesn't have a technical implication, and there's no technical decision that doesn't have a business implication."

This is a great summary. It's your job to understand and manage these decisions and their implications.

Next Week

Come back Monday, April 26 for an article about the SuiteRunner testing tool. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.

Resources

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/

Joel Spolsky's discussion of the macroeconomics and microeconomics of open source software in Joel on Software is called "Strategy Letter V":
http://www.joelonsoftware.com/articles/StrategyLetterV.html

SleepyCat Software, which Luke pointed to as a successful open source business model, are the makers of BerkeleyDB:
http://www.sleepycat.com/

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

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? Be the first to post a comment about this article.

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.