Hi All,

Rumors say that Infor is going to raise the license fees for cluster- and backup-server installations.


High availability clusters (2 servers with installed software like HP Service Guard etc.) or
A number of application server and at least one DB-server

will require a 20% surcharge on current licence fees (per server?)*



A backup (standby) server installation

will require a 10% surcharge on current licence fees (per server?)*


* except those customers who's contract covers these scenarios

According to my source Infor is going to roll out this plan in Europe by September this year. US customers are already informed.

Has anybody heard of this already? What about seperate testsystems? I can't believe that this is true.

Best regards,

Martin

Even though I am certainly no lawyer and you never know, what Infor has in mind, I doubt that test systems will be effected by this:

A test system is usually validated either

a) with a small seperate license, which expieres after 6month or a year

b) by pulling licenses from the life system.

Both is not related to the HA license available in Baan.

Regards

Markus

P.S.: Baan many years ago unfortunately did not clarify many things in their support contracts. One topic was concurrent vs. names users. Another was the availibility of source code. A third topic is the use of extra features like HA. In the past all this was included in a normal license. But obviously Infor is "inventing" every year a new source of income, by simply changing their mind about, what they sold some years ago. Very ethical business practice.

Very interesting in this context is this "career opportunity" currently open at Infor:

http://app1.infor.com/jobs/1213612890_licences_manager_june_08_hkmt.doc

Uli

We currently wonder which licenses a company needs in case it will be able to develop/customize software. It looks like you cannot buy the sources anymore...

It's easy: Don't buy an ERP software, if you can't also get the source and the right to modify it so it fits your needs. It seems the customer base has to educate Infor a little in this respect. *No* standard ERP software can be used efficiently without *changing* the standard to better fit to your business processes (set aside some very trivial environments). For ERP LN that's even more true, because it's a lot harder to customize LN without sources than it was with Baan IV (on the other hand, it's now a lot easier *with* sources).

Personally, I think it's pretty irresponsible to operate a Baan Environment without sources. If Infor does not learn it by people telling them, they have to learn it by losing customers, potential ones as well as active ones.

Uli

I run Baan 4c4 out of the box with no mods (just bolt-ons) works great for our company.

That being said, one of the biggest reason people bought Baan instead of SAP was the customization availability. If they're going to remove that, then you have no more edge over SAP in that area, which is a downside.

However - In my opinion, you shouldn't be customizing Baan - EVER.
Use Bolt-ons (using DAL, etc that they provide you with)
Or better, come into this century and use Openworld/Technology Architecture

Dave

Source encapsulation has been around since Triton 3.1b (Tools 6.1), and is great for customizing the application. Even better, it was easier to upgrade and apply patches without loosing your changes, or needing to reapply them.

Even for those who have source code, this process would save cost when applying patches.

That being said, having the source for reference is a invaluable tool.

Of course, if you can do something without changing a standard source, do it without changing a standard source. On the other hand, if you *can* change a standard source with adding or removing some lines of code, instead of either

* not having the functionality you require

* write a badly integrated addon

* misuse some standard functionality that wasn't intended for such a use (this, in the end of the day, is the most expensive variant)

then go ahead and change the standard. As little as possible, of course: Whenever possible, encapsulate your functionality in an DLL and only call this DLL from within the standard.