SAM: Taking controlled risks

20 nov '14 - Mark van Wolferen - share: LinkedIN Mail
sam-taking-controlled-risks

Are policies and procedures the way to go?

The Software Asset Management (SAM) industry has increasingly been publishing about the preventive actions companies should take to either ensure that no unlicensed software can find its way into companies, or ensure that software can no longer be out of compliance.

Recently, I read yet another article about the need for policies and procedures to prevent risk. The human response to add control in case of risk is very logical and I adhere to this behavior myself. However, I sometimes wonder if it is always the best approach.

Most companies don't see software as their core business but as a a necessity to run, support and optimize their business. They want control, but at the same time, companies require flexibility; being able to shift quickly enough to follow the market. Deploying software is not like mathematical science: it requires adjustments, people who make it work, and especially new technology needs to be explored and played with.

This  can be compared to wall climbing. The climber plans a route, studies the wall, and decides the best way to reach his goal. However, when climbing, adjustments need to be made. A set path turns out to be not as stable as viewed from the ground; other grips might provide a better route. Alternatives are necessary. The ropes that secure the climber, or the be-layer at the bottom, secure the climber. However, there is always some slack on the line. Excessively tight control does not allow the climber to move, to make decisions that differ, or to help them move forward. The goal is for the climber to be safe, not to be without risk.

SAM is the same. It is the be-layer that provides support to the business, a control that is fully in support of the business. It should not restrict or limit the company from moving forward. This means that it requires some slack on the line. Rather than attempting to implement controls that ban the risk fully, if at all possible, SAM should be about securing the organization while at the same time leaving enough room to be a truly entrepreneurial business. Some risk is perfectly acceptable as long as there is mechanism in place that limits it to an acceptable size. It cannot be predicted, but it can be budgeted. 

Instead of investing all time and energy in policies, procedures, and their controls, time should be spent on operational checks and watching the business. If SAM is close to the business, i.e. close to IT, it is not hard to spot risks during the IT processes and new IT projects. SAM should not demand approval for each step, but should rather allow IT to make adjustments and serve the business to find the solutions that are needed; even if it means some risk at certain moments in time.

If a be-layer knows climbing, they know what the person on the wall is experiencing and will flexibly respond, reducing the slack when possible, enlarging it when required. This requires trust and a well set up partnership. When applying this to SAM, I can only conclude that we're still a long way off. The current dynamics and guides aim to abandon risk and are mostly reactive. The business needs to follow this process, and adhere to the following rules/policies. If not followed, it is clear who made the mistake, who should pay for the cost, etc.

Although policies and procedures are required, SAM as a service of the business needs shift thinking. Answers need to be found to questions such as "how can we read the business better," "size risk better," and "see and address risk instead of seeing who's guilty." SAM is a young industry and has some very bright minds. I'm sure the answers will be found in the future and I’m definitely motivated to play the role we can.  

Like a climber, doing business is not without risk. The only question is how we deal with it, even if it apparently collides with human instinct sometimes.

Oracle Database and hardware infrastructure

The required number of licenses for Oracle’s Database programs are (almost) at all times related to the hardware infrastructure on which the software is installed. Incorrect interpretation or understanding of whether the software is deemed to be installed and how the installed software should be licensed in a certain specific hardware infrastructure is by far the number 1 license compliance issue. 

Oracle Database and hardware infrastructure

Download

Fill out this form to download our free whitepaper

Please make sure you've filled out the form correctly.