Sponsored Link •
Luke Hohmann talks with Bill Venners about the impact licensing models have on software architecture, the sustainability of open source business models, and the benefits of providing licensing options.
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 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.