Ed Gould writes:
>I have been out of the loop and I am not familiar with the term ELA.
>But I guess from your entry it is a modifiable contract.
Enterprise License Agreement.
Let me back up two steps, though. Speaking for myself here, of course, as
always. Any company presumably tries to maximize profits. That's what the
shareholders expect, and I'm sure most people here work for companies (or
used to work for companies) with the same core economic mission. But
there's a funny thing about profits: it's impossible to sustain them for
any length of time unless you continuously work to earn them.
OK, so what's that got to do with ELAs or similar sorts of contracts? Well,
the first thing to know is that the mere act of fulfilling someone's
purchase costs money. You pay sales reps who then have to negotiate terms
and conditions (and prices), figure out how to ship products, collect
money, report tax liabilities (if any), establish support entitlements, get
everything reported correctly to accounting (and in the correct quarter),
arrange financing, verify configurations/prereqs, arrange services and
education, etc., etc. And I'm also sure many vendors reading this list know
all about those challenges.
To try to reduce the burdens incurred through the mere act of selling and
delivering something, most vendors like to establish longer-term,
pre-negotiated relationships, at least with their most valued customers.
And a lot of buyers do the same thing for many of the same reasons. The
U.S. Federal Government, for example, has the big GSA contracts. Thus it's
not at all surprising why ELAs exist and what the first order benefits are,
to both vendor and customer.
Also, vendors like stable (or growing), predictable revenue streams. This
is especially true for companies heavy in R&D, because R&D takes years to
show any business results, and most sensible R&D requires steady investment
in order to bear fruits. Customers have related needs, like making sure
they have a steady, reliable supply of products at certain prices and with
certain terms. One basic and typical arrangement in the software business,
for example, is for customers to get rights to new versions under certain
terms. So this is another big reason for ELAs and similar contracts.
My point about ELAs in this specific case is that, if you're getting a
piece of hardware, you'll need software to run on it. You might need some
IBM software, so you might be spending some money with IBM. The same
justification for buying the hardware will also point toward an extremely
high probability that you will be able to predict, with a degree of
confidence, what your software needs will be. (You may still be able to do
that without any contemporaneous hardware decision, but the hardware
decision alone is proof that your predictive powers are adequate.) So if
you say to IBM Software something like, "I'm not totally sure what the
future holds, but I'm sure I'll need my accounting system for some years,
and that means I'll need a minimum of 16 MSUs of z/OS, CICS Transaction
Server, DB2, and MQ for the next 36 months, growing at about 10% per year."
(Insert your own numbers here.) IBM Software can then say, "OK, that's very
helpful. Here's a draft ELA which establishes that forecast on paper. In
exchange for making the forecast, we will grant you a credit which you can
use to acquire cool new System z one-time charge software. You may still
cancel your MLC at any time, but if you do we'll expect you to pay enough
to cover this OTC credit before we part ways."
And that's the basic idea of an ELA, at least an IBM one. You're making a
very calculated bet that you can "promise" IBM some of that predictable
revenue stream, and in exchange IBM is delighted to give you a substantial,
tangible benefit. You can use the OTC software or not, and you can choose
to continue subscription and support or not, product by product. You
probably want to choose stuff you might actually use, but even if you toss
it into the garbage, no harm. Most customers can make this bet -- some bet
-- extremely confidently.
If the world changes, you and IBM can agree to amend an ELA. For example,
if you acquire another company, and your z/OS accounting system workload
doubles, then you can raise your forecast and get some more credits. If the
opposite happens then it gets more "interesting" -- which is why a slightly
conservative forecast is generally advisable -- but you might extend the
term, for example.
Anyway, I doubt IBM is unique here, and you can probably see why vendors
and customers might reach such an arrangement. Where I get frustrated (on
the technical advice side) is that I see customers that emphatically make
this bet on hardware and fail to make the same (fully conforming) bet on
software. Thus they fail to win investments they really should be making in
their businesses (i.e. in their software infrastructure), and they don't
get that "cool new" stuff to speed up application development, or to
connect their applications more easily to the rest of the world, or to
tighten security compliance and protect their company's information better,
or to move some functions to save data center space/power/cooling, or
whatever.
>Glad to hear
>IBM is offering such a contract but I would have to know a lot more
>(and understand it ) before giving any blessing.
As always, read the fine print, but I just gave you the core essence (and
mutual rationale) for these sorts of agreements. IMHO they are
underutilized, at least by IBM's customers.
I should also say that occasionally an individual sales rep might not
totally like an ELA. If you rewind to what I said above, you might guess
why. That's generally not true, but there are always a few odd people. :-)
I do think customers should challenge IBM (and other vendors) to think and
act more strategically in these mutual relationships.
Also, I should say there are several three letter acronyms in the IBM
lexicon here, and I don't begin to understand them all in detail. ELA, SRO,
OIO.... those are all in the same general category. ("What are types of IBM
contracts, Alex?")
>Which leads us to
>the age old complaint about IBM Sales types and their lack of
>interaction with the CIO's (or appropriate manager types).
Amen. I've seen some outstanding sales reps at work and also some dreadful
ones. I don't think the dreadful ones last long.
>Now its
>too bad that other vendors don't offer similar contracts.
I think they do, at least to some degree. IBM is perhaps a bit unusual in
having such a large number of part numbers and service offerings in its
full catalog, so the contract scope can be quite broad. For example, if you
can't find an OTC software product you like among the 13,000+ (a guess),
you ain't trying. :-)
>I know you
>can't speak for OEM but they are in it to get all the money they can
>possibly squeeze out of the rest of us. While profit is good costs
>are one of the major factors that the MF is going belly up. I would
>name names but everyone knows who the biggest offender is so make up
>your you own name.
There are more alternatives, thank goodness. I know IBM has done a lot of
work in this area, starting especially in the year 2000.
There is certainly a cost perception problem, but I've said before that
we're in a different world now with radically different economics.
>I don't want to get side tracked by the evil empire but they aren't
>the only ones out there. Heck there used to be a DB2 vendor that at
>times made the other vendor look like like a mouse.
Evil is a bad business strategy, at least if you want to stay in business
very long. Google has that famous corporate motto, "Don't Be Evil," and
they're absolutely correct.
>What can IBM do to educate customers and keep them informed of
>offerings? Not once a year but 3-4 times a year (at least)?
In my own little corner of the world, I offer some thoughts on the
Mainframe Blog (http://mainframe.typepad.com), so that's one new way. The
ranks of architects are growing, so that's another.
- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
