Beyond Software Architecture[c] Creating and Sustaining Winning Solutions

Before you actually license any technology, you have to make certain that your business model is compatible with your provider's business model. If the two are not compatible, you're going to have to negotiate an acceptable compromise. These choices can have a significant impact on the tarchitecture , so everyone needs to be involved.

Suppose, for example, that you're building an enterprise application and you want to base your business model on concurrent users. You want to integrate a search engine, for which your preferred vendor will charge an annual fee. While the business models are different, this situation can be fairly easily resolved. If the annual fee is low enough, you can just pay it. If it is too high, you might be able to negotiate something more acceptable and, again, pay it.

A more complex strategy is to negotiate a license fee based on the projected revenue from your concurrent users, with a floor (a guaranteed minimum amount you'll pay) and a ceiling (the maximum amount you'll pay). You can pay the floor to gain access to the technology and, at the end of the license term (one year), provide the licensor with a statement that details your actual revenue and the amount of money you owe. This isn't an easy choice because it requires you to disclose potentially sensitive information to your provider (such as the number of concurrent users and your annual revenue). Along the way, your tarchitecture or, more likely, your back-office systems will need to be checked to ensure that you can meet your license payments.

Let's invert the above example and see what happens. In this case, your business model is based on an annual license and your technology provider's business model is based on concurrent users. You can resolve these incompatibilities by creating a mutually agreeable estimate for the number of concurrent users accessing your system for a given annual license, by negotiating with your technology provider to accept an annual license instead of charging by concurrent user, or by offering your provider's technology as an "optional" module and licensing it as a concurrent user option. If you really need this technology and you can see no realistic way to make it an optional module, and if the provider is adamant about maintaining its business model, you may have no other choice but to convert to a concurrent user business model. The point is that you must understand the business models of all your technology suppliers and how they relate to your own.

Nice Try, But

One product team I managed planned for their system to be built on a major J2EE vendors ' application server. The target market was both end users and application service providers who would operate the product on end-users behalf . The default license agreement of the J2EE application vendor explicitly prohibited the right to operate its product in an ASP or service provider environment. Product development stalled until I was able to negotiate a fee schedule that protected the interests of the vendor and was acceptable to our company.

A special case of business model negotiation is required when you change technology vendors. Let's say that you've created an enterprise application and have licensed a search engine from technology vendor A. Sometime later, for whatever reason, you decide to change to technology vendor B. Along with the fees associated with new systems sold using vendor B's technology, you're going to have to calculate the fees associated with upgrading from vendor A's technology to vendor B's technology. Depending on your licensing agreements, you may or may not be able to charge your customers for the upgrade and/or change. Marketects must model the complete costs associated with changing technology vendors, including the cost of converting the installed base.

Related

Категории