Reprise Software
www.reprisesoftware.com
info@reprisesoftware.com
781-837-0884 |
|
We hope that you find the
April '08 issue of
Options useful and informative. We
also would like to hear suggestions about
topics of interest to you that you would
like us to consider for future issues.
Please feel free to
forward this to a friend
using the link at the bottom of the page.
Thanks. |
Are you new to
Software Licensing?
How do I get my
Company to adopt Licensing?
So, you've been trying to
introduce the concept of
software licensing into your
company. But, you're not sure
of the best way to move the
process forward. Maybe we can
help. Here's what we think you
should do to get to the finish
line.
IT ALL STARTS AT THE TOP
We're asked this a lot and have
assisted many companies in
making the transition from
"trust-based" to "trust, but
verify" with a license manager.
To us, the key ingredient in a
successful license management
project starts at the top: You
need executive (hopefully, Chief
Executive) support and
sponsorship to ensure you gain
the benefits available from
licensing. Since the decision
to adopt license management
touches so many parts of your
organization, you'll need to
make sure it's clear to others
in your company that a licensing
program will not only help
increase revenues, but also has
visibility at the highest levels
of your company.
IT ALSO STARTS WITH JUST ONE
PERSON
As important as it is to have
executive-level support for your
licensing program, it's equally
important to have a single focal
point in your organization to be
the "go-to" person for
licensing. Ideally this person
is well-known and respected
throughout the organization and
has good knowledge of the
functional groups that will be
impacted by licensing and how
they will respond. While
neither an MBA nor a Computer
Science degree are necessary,
being able to both "walk the
walk" as well as "talk the talk"
are important to lending
credibility to your licensing
program.
SHOW ME THE MONEY
The focus for the licensing
program, ideally, should be
revenue- and profit-driven
(hence the need for an
executive-level sponsor.) There
will be an investment made by
your company in the form of
man-hours devoted to the various
aspects of implementing
licensing; naturally, there
needs to be a payback for this
in terms of increased revenue
and profitability.
WHAT'S IN IT FOR THE CUSTOMER?
While more money is always a
good thing, this shouldn't come
at the expense of
customer/end-user goodwill.
Remember, software licensing is
all about keeping "honest users
honest" and giving them an
easy-to-use tool to help ensure
compliance with the terms and
conditions of your existing
paper or clickwrap license
agreements, as well as to easily
acquire more licenses. Taking
an overly negative attitude
towards customers and end users
with your licensing program will
be immediately obvious to them
and will negate benefits from
increased license compliance.
Talk to trusted users of your
products, or co-workers most in
touch with your users (support,
sales, etc.) and do a "sanity
check" with them on your
proposed licensing policies.
Obviously, thumbs up are what
you're looking for. While no
licensing system will make
everyone completely happy, on
balance, both revenue and
customer satisfaction should go
up with a well-done licensing
program.
OK, GREAT; SO HOW DO I START?
First, reconcile your current
licensing policies, agreements
and existing infrastructure (if
any) with what your marketing
and sales folks tell you would
be most desirable. If you
currently provide permanent
licenses, and see that customers
are asking about annual
subscription licenses, that's a
good place to start. What about
adding floating licensing to
your existing per-CPU model?
Per user? Time zone based? Do
lots of market research, both
internal and external to figure
out where you want to go license
policy-wise.
SO, WHO'S GONNA DO ALL THIS
WORK?
Now that you have several great
business policies to put in
place via licensing, you'll need
some resources. Now's a great
time, if you haven't been doing
so already, to go back to that
executive sponsor with a
briefing on what may be possible
with software licensing. Do a
quick "back of the envelope"
calculation about impacts on
revenue and profitability. No
need to make this pie-in-the
sky; there will certainly be a
short term negative impact to
get infrastructure set up,
employees trained and the
product and documentation
updated. However there should
certainly be an obvious payback
in the one-to-three year
timeframe. Now, you get to make
your sales pitch: Will your
executive sponsor approve the
internal resources to implement
the needed programs to create
your dream software license
management program and help
ultimately increase revenue and
profitability?
OK, WHEN?
Now that you've got some people
to help you, next you should try
to nail down a "ship date" for
your product(s) that will have
the new licensing scheme(s).
It's quite likely that there's a
new release or two already being
sketched out on someone's
whiteboard in the company. Use
your charm, or if needed,
executive sponsor, to ask about
changing that date (or setting a
new one in the future) to
accommodate your licensing
program. On the software
engineering side, you'll
probably need a day or so to
integrate and test the licensing
libraries, change the install
routine and document everything.
IF AT FIRST YOU DON'T SUCCEED...
It is possible that there
could be some complications
in your first rollout of a
product with licensing.
Hopefully, this will be seen
as something that happens
normally with software.
But, it wouldn't hurt to try
to forsee all possible
problems as part of getting
ready to roll out
licensing. Be sure to have
a contingency plan for what
happens when a customer is
frustrated with getting your
software up and running
under license management.
It may certainly be worth
it, long-term, to just give
that customer a temporary
"everything works" license
to get them over the hump
and up and running with
licensing. You may also
want to have dedicated
support and engineering
resources "on call" when
that all-important roll out
date arrives. It's safe to
say that you'd be better off
having the resources but not
needing them due to your
brilliant foresight and
mitigation of all possible
licensing-related problems.
NOW THAT YOU'RE OVER THE
HUMP
Don't forget to brief your
executive sponsor on the
effects of the rollout of
your software licensing
program. They were
instrumental in getting the
program going and they
should be able to share the
glory of the success of
getting licensed products
out the door. As part of
your rollout plan, put a
stake in the ground 30, 60
or 90 days after release to
come up with some simple
performance metrics. Have
support calls gone up or
down? What above revenues?
If you time your first
licensing release to
coincide with the beginning
or ending of a fiscal
quarter, you may be able to
get more bang for your
licensing buck. Make
performance stats available
as soon as you can and be
sure to publish them inside
your company. Even if the
numbers aren't all
wonderful, give everyone the
story, including plans for
future releases with
licensing, new licensing
models in the queue, etc.
MAKING LICENSING PART OF THE
CULTURE
Hopefully, your results will be
paid back in the short or medium
term. Ideally your company is
making more profitable use of
the employees and infrastructure
devoted to software creation and
both customers/users and
employees are happy with the
decision to go to software
licensing. If so, great; to the
extent you can, keep doing what
you have to push software
licensing into more products in
your company. Heck, we even
know of companies you might
think of as "hardware" companies
that now treat their physical
stuff as platforms for enabling
what their customer gets via a
software license.
In any case, best of luck in
your quest to adopt software
licensing. If you have any
questions, don't hesitate to
contact us.
COMING NEXT MONTH
Ok, you've gotten an official
licensing program off the
ground. How can Reprise and RLM
help? Why shouldn't we just
write a license manager
ourselves? After all, we are a
software company. Stay tuned... |
|
RLM
Customer Story: Zentech
International, Ltd.
Delivering high
powered analysis tools the
engineering community
Zentech provides engineering
software and consultancy
services - in particular to the
aerospace, nuclear and
manufacturing industries.
Its main product - Zencrack -
enables engineers to model and
analyze 3-dimensional cracks,
using finite element (FE)
analysis to allow calculation of
parameters such as energy
release rate
and 
stress intensity factors. These
capabilities can be applied to a
wide range of problems. Surface
cracks and embedded defects can
be analyzed. Existing defects in
components can be modeled and
their remaining life calculated.
Forensic analysis of failed
components can be carried out to
determine the failure mechanism
and much more.
Zencrack interfaces with leading
FE programs, such as Abaqus,
Ansys, Finas and MSC.Marc - on
Windows 32 & 64 bit, Linux and
other proprietary platforms. It
is available in either Standard
or Professional versions.
Having used different licensing
methods, including 'dongles',
and the company's own
node-locked mechanism, all of
which satisfied requirements in
the past, an increasing need to
provide greater flexibility for
users to access the software was
recognized. It was important
also that the license manager
could be downloaded easily from
Zentech's web-site, as Zencrack
is distributed solely via the
site (most customers are outside
the UK where Zentech is based).
Finally, the license management
had to be implemented with
minimum time and effort and at a
reasonable cost.
Initially, to make it simpler
for clients, the license manager
used by the FE code suppliers
was investigated but the
entry-level pricing was far too
high. Other vendors' products
either could not support the
range of platforms, or did not
appear to provide the features
needed.
RLM, however, provided all of
these. The Token-Based license
facility was particularly
useful, enabling simple control
of program features, eg.
Version, allowed FE code
interfaces, etc..
Zentech found that RLM was
most helpful in supporting a
trial-to-enable testing on
Windows & Linux. Reprise
Software's pricing was
reasonable and any technical
problems were resolved quickly
and effectively.
Roger Hewitt, Zentech's
Technical Director, says, "The
SDK is straightforward and
well-documented, and Reprise's
support is excellent. The
end-user footprint is small and
we implemented the RLM into our
latest version without
difficulty and with no user
problems reported so far. I am
confident we made the right
decision." |
|
|
The Great Debate:
Redundant Servers v. Independent Servers
A little history...
The concept of redundant license servers
dates back to the early days of
licensing software circa 1988. At that
time, networks and servers were
unreliable and fixing them was a very
time-consuming process, often taking
days or even weeks. So, when a license
server went down, customers wanted a way
for their licenses to be available
during the outage. Redundant servers
were born.
The most popular license managers still
use three redundant servers operating
together with exact replicas of the
license servers and license files on
each of the three machines. Service
remains intact as long as at least two
servers can communicate with each other
and client applications can connect to
them. The primary benefit of a properly
configured redundant triad is that a
customer's complete inventory of
licenses will remain available to at
least part of the user community in the
event of a single server node failure.
Application developers using these older
license managers were unable to
communicate with multiple independent
servers without coding complicated
licensing routines into each
application. As a result, many of the
features of these older license managers
simply worked better with redundant
servers than with independent servers.
Redundant servers have survived because
of the lack of a better approach - until
now.
Is there a better way?
A redundant server sounds like a good
idea, but is the added administration
complexity and overhead worth the
trouble in today's more reliable
computing environment? Are redundant
servers still the best approach? If
vendors and their users had a better
option, would they still prefer to use
redundant servers? Let's first examine
what can go wrong with redundant
servers. Later we will explain the
alternative RLM approach.
Server Redundancy
Problems
Faulty server deployment decisions:
In order for a redundant server trio to
operate properly, each server must have
a complete and independent copy of the
license server software, and license
files. Often this setup is not achieved
because shortcuts are taken to make the
administrator's job easier, such as
placing a single copy of the server
software on a shared file system. This
situation creates a single point of
failure, defeating the purpose of the
redundant setup.
Extra administration coordination:
If each license server in the triad is
managed by a different team of system
administrators, then special
coordination is needed between them
whenever changes are made to any of the
license files.
DNS name server time out sensitivity:
A redundant trio, especially one on an
unreliable or slow network, can suffer
outages whenever a DNS name server times
out waiting for an address to be
resolved. This is a hard problem to
diagnose and it not usually well
documented in the triad setup guide.
Poor scaling characteristics:
Since all licenses that belong to a
redundant server group must be combined,
there is no way to improve licensing
throughput unless the user upgrades all
three of the server computers. And even
if he does, there are still operating
system limits that govern the number of
clients than can be served by a single
license server (whether it is a
redundant server or not). If scaling
becomes a problem, multiple sets of
redundant servers must be deployed. This
could be an issue at any site, but it is
most problematic where large numbers of
your licenses are in use - at your
biggest and most important customers.
Version incompatibility between
server releases: Whenever a new
license is introduced into the common
redundant license pool, administrators
have to check the version of the license
server software associated with that
license. If it is later than the current
version, then it needs to be copied to
all three redundant servers
simultaneously to keep the redundant
trio in sync.
Some advanced features may be
unavailable: Often end-users are
unaware that they are making
functionality tradeoffs by deploying
redundant servers. With redundant
servers, access to some valuable license
management features, such as license
borrowing, may be at best awkward to
support or at worst simply unsupported.
Network segmentation problems:
Since redundant servers operate only
when at least two servers can
communicate with each other, a network
failure can take one of the servers
offline. If you are a user on the "wrong
side" of a network break, then you
cannot access any of the licenses in the
managed pool, even though your local
network may be functioning normally. In
this case, the license pool is available
only to the users who are lucky enough
to be on the right side of the break.
Report log consolidation problems:
Whenever a redundant license server
fails, a new master server must be
nominated. If the failed server was
writing to a report log, then logs from
the new master server must be later
combined with the original report log in
order to obtain a complete and accurate
picture of license usage. If the clocks
are not completely in sync, then the
report log may be difficult to
reconstruct accurately.
ISVs must know all three redundant
HOSTIDs: Server redundancy
complicates the license creation process
for the software vendor because all
three hostids must be known at the time
the licenses are created or modified.
This means that the ISV has to support
both redundant and non-redundant license
file types. Also, changing any of the
hosts in the triad requires license
files to be reissued, which must then be
reinstalled by the customer across all
three redundant server nodes.
An
Alternative Approach:
Automatic Support for Decentralized
Independent License Servers
The Reprise License Manager does not
support redundant servers. Instead it
supports decentralized independent
license servers. Vendors can take
advantage of this new approach
automatically without writing a single
line of new code.
RLM was designed from day one to support
multiple independent servers. As a
result, we have been able to make
multiple servers operate in a much more
transparent and efficient manner than
redundant servers, giving end users more
flexibility and control over how their
licenses are deployed and managed.
Virtual License Pooling:
Conceptually, you can think of the
decentralized, independent RLM server
approach as a Virtual License Pool. The
pool consists of all the licenses
managed by servers that
the user has access to. Instead of
aggregating redundant licenses into a
single license file, then replicating it
across all three redundant hosts, RLM
aggregates the licenses virtually,
leaving the licenses on servers that are
most conveniently deployed and managed.
RLM transparently queues, connects and
reconnects to the entire list of
decentralized servers giving each user
access to his own "virtual pool" of
licenses across the enterprise. The RLM
servers remain independent, meaning no
extra effort is needed to coordinate
them.
Transparent reconnection to dispersed
license servers: With older license
managers, once an application had
successfully checked out a license from
a given license server, all subsequent
license requests from the same
application had to be satisfied from the
same server. In the event that the
application made subsequent license
requests and no more licenses were
available from that server, the license
request was denied even though licenses
may exist on another license server. To
override this behavior, it was necessary
to write complicated
disconnect/reconnect logic in order to
properly obtain licenses from other
servers. With RLM, multiple license
checkouts over multiple servers are
handled transparently, simplifying the
implementation within the application,
and also giving the end user more
consistent, predictable behavior across
all vendors who support RLM on his
network.
Enterprise-wide Queuing:
Additionally, the RLM design supports
license queuing across multiple license
pools. With older license managers
developers had to write complicated
licensing routines using the API to
queue at any license server other than
the master. Without this special coding,
it was possible for pools of licenses
were to available on alternate servers,
yet remain inaccessible to your
application. By contrast, RLM
transparently queues on each server (and
on each license pool within the
server). Once the application
acknowledges the license grant, all
other license requests are dequeued.
This happens completely transparently to
the application code. End users can
decide whether to use queuing or not.
License Server Load Balancing:
With RLM, license loads can be balanced
by instructing RLM to randomly select
the server from the server list to which
to connect. Over time, a balanced load
will be achieved.
Better License Server Scaling:
With RLM, license service can be scaled
up by simply adding server machines with
new licenses into the existing network.
More Tolerant of Slow Networks:
RLM's design is more forgiving of slow
or unreliable networks because a quorum
of servers is never required.
Simplified Administration: When
you install an RLM license server, you
install it in one place, period. You
don't have to worry if there are
identical license files, binaries, etc.
on each of the 3 machines. Your report
logs remain independent so that the
usage can be summarized across servers
to gain a full picture of concurrent
usage.
|
|
|
