In an ideal world software design shouldn’t be driven by software license costs if constraints. But when you can be paying tens or hundreds of thousands of dollars per server for an application or middleware it isn’t an aspect you can ignore. The challenge is when licensing rules are so complex like those for Oracle you either end up with licensing experts reviewing design artefact or you need to find an alternate approach (and the hope of using agile strategies with such a review framework necessary have gone).

For those less aware of Oracle’s licensing you have be licensed by CPU, by users, by profitability and probably will be impacted by atleast 2 of these models. Then each license can also be constrained by usage (unlimited or limited) which says that you can use some products with some things and not others, or use your licenses for only particular activities. Finally you have product dependencies, so the licensing of 1 product and indirectly impact how you can use another. For example I may have unlimited use for Weblogic (on 20 CPUs) but SOA Suite, the components that together allow you to run Process Integration Packs (PIPs) which as a Fusion Middleware offering provide a collection of middleware components to achieve common tasks – for example keep your customer information synchronised between a CRM solution and your accounting solution, which maybe limited to only work with Oracle applications – so extending a PIP to also send one of your own application an event wouldn’t be allowed (unless you’ve built an extension on an approved Oracle application).  Then for fun you have what are called Unlimited License Agreements (ULAs) – although they’re not really unlimited.

Just when you think you’ve got a grip of the licensing story, there is one more mix of the pot.  When you’re negotiating licensing you’re likely to be working through a purchasing team who aren’t technical Oracle product experts, and licensing discussions are likely to be done whilst costing a programme where unless you’re an enterprise mature organisation or operationally very well instrumented to measure this information it isn’t going to be easy to get volumetrics and an ability to determine likely throughput (i.e. how complex and demanding will your custom logic be).  So by the time you get to from your conceptual to-be perspective which told your which products you need to when you’re actually working on the realisation you may well hit  challenges.

With all of this in mind, we’ve arrived with the idea of usage scenarios. We’ve tried to differentiate usage scenarios from design patterns, as their goals also differ; a pattern is typically to provide a means to describe and provide good design approaches to technical problems, think of things facades and factory’s from the Gang of Four (GoF) or composite patterns such as VETO and here we seeking a means to communicate what can or can’t be done. These aren’t use cases either, if for no other reason to avoid the UML notation association.

So how does it work, so we have identified common or likely approaches to using our Oracle technology stack, need them so there is a short hand reference (as you have with design patterns) and then determined of the scenario is permissible by licensing rules. The idea is that an application architect or developer can design a solution and then verify the solution against the scenarios. To start with go for the obvious scenarios, as things go forward when a situation crops up where there isn’t a scenario you can add the the catalogue  and get confirmation as to compliance.  This should mean after a short period of development you’ll reach a point where you’re not consulting licensing experts all the time.  The secret is not to try ‘boil the ocean’ on day 1 as you’ll invest a lot of time, potentially creating representations of things you’ll never do and produce a very bulky artefact for your developers to try and work with.  Oracle’s AIA Developer Guide

With the scenario we document references to the various license and contract documents showing which clauses drove the decision so you don’t have to rework out how you determined the legitimacy of the scenario.  I’ve created a fake representation of a usage scenario below.

There is a further bonus, you can drive into the guidance when there is a need for additional governance attention.

Of course this mechanism doesn’t tackle the question of is there sufficient licensed capacity. As capacity management has its own set of challenges (such as balancing the capacity requirement forecasts for multiple current development programmes that are likely to be taking place vs actual consumption and forecast consumption for business growth).

The following diagram is a mock up of the sort of diagrams produced. Mocked up as I don’t want (and shouldn’t) disclose any information about what specific technologies and approaches we’ve adopted internally.

Usage Scenario with 1 scenario acceptable, another not