Skip to Content

An Architect’s Worst Nightmare

Amongst many other things, Architecture is all about trading off the best design that is commercially focussed and supportable by the organisation.  However, sometimes something called licensing gets in the way.

Licensing is what it is though, but when you need to re-architect something just because licensing is cost prohibitive; it is what I believe, the Architect’s worst nightmare.  This blog covers two scenarios that I think not only hurts the customer by driving bad architectural behaviours, but also hurts the vendors that offer these options.

Note – This is not specifically about SAP who is usually pretty good in my experience about non-restrictive licensing, though hopefully there’s lessons for all below.   

Named User License

The Problem

Okay – I’m not attacking what is possibly the most common SAP license.  Because of HR/Payroll it seems reasonable that everyone needs a license. What I am attacking is a scenario where you have a transactional system that has day to day data required by numerous individuals from a read-only reporting perspective, but because of licensing; it is more cost effective to extract the data to your data warehouse and give everyone access from there (or similar scenarios).  Alternatively, you may have a few minor scenarios that, due to licensing, you need to build an external “anonymous” interface that allows you to have your organisation transact with this system. 

Why the Vendor should care?

Do you want the customer to replace your product because the true TCO (including work-arounds, data warehouse extracts and disjointed processes) is too great?  For example, maybe the cost is okay but now with the work-around solutions, the business processes are disconnected, and the business finds it’s easier to invest further in the work-around solution.  If vendors really know their product, they should realise these limitations and not allow you to get into these predicaments.  Food for thought perhaps.

The Solution

Of course, named users is an easy way to get more money each year as you annually add users; but how about throwing in a CPU license or a fixed number of concurrent read-only users.  For the update transaction, how about providing an all of enterprise license for a specific set of functionality if it makes sense within your product.

Developer/Test Licensing

The Problem 

If you are an ERP customer, I don’t believe anyone would deploy a landscape that consisted of just Development and Production.  In some vendor solutions, this is fine (we do need to consider cost of infrastructure, support costs, complexity, etc); but for more complex environments, and especially those that you develop upon and/or have concurrent projects on; this is my most annoying license I come across.

In short, when custom development is involved; a 2-tier landscape is not sufficient without significant controls in place.  That said, licensing can force this scenario.  In some scenarios, you probably can’t even afford a sandpit system on a laptop to try things out.

Why the Vendor should care?

Okay – really this doesn’t require an answer but in case you need to point a vendor at a blog to explain this, I’ll put a few answers down:

  • Production errors and potentially corruption due to lack of testing. 
  • Sandpit changes in the Development environment making it through to Production accidentally.
  • Innovation freeze due to no Sandpit environment or inability to support Production and do concurrent projects.
  • Lack of involvement from the business in user acceptance testing meaning worse change management for end-users and potentially higher failure rates on projects.  
  • No Training environment means less effective training (could even be required to go live with just PowerPoint based training – urgh).
  • Stress and Volume testing is not going to happen after the initial go-live.
  • etc.

In short, if Production gets a bad reputation as unstable or not moving with the business; I guarantee the business will start looking to when they replace your systems sooner or later. 

The Solution

Simple – Price your product accordingly and don’t try recoup costs from Dev and Test licenses.  
If that won’t work for you, sell concurrent developer and test user licenses.  For example, with outsourcing now days, named users are not really possible as your outsourcer may leverage 100’s of developers over time. Similarly, projects will require user acceptance testing from many different users at different times.

The Customer’s Responsibility

Now I could always blame the vendor like most people like to do, but if the sales team start playing by these types of rules, there’s also responsibility for the customer to not attempt to avoid the licensing.  For example, virtualisation is a key technology in today’s IT world; and just because we can load up many servers on a single set of CPU’s; don’t go and get single server licenses that allow you to cheat the system.  FYI – Most Vendors would see through this pretty quickly and start to charge you for all CPU’s within the Virtualised environment which in turn will back-fire and kill your virtualisation strategy making you move back to physical.  It can be a vicious cycle.

The True Cost of Software Licensing

So next time you’re looking at buying a product; think about the true cost of that product, and look really closely at the software licensing.  Not just for the implementation, but the ongoing costs of keeping the software current, and making full use of the product.

And from a vendor perspective; let’s work together and get the model right, and help us out when we get it wrong. 

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply