Miro Consulting's Blog

Six steps to SAM

ScottR — Fri, 03 Jul 2009 15:00:37 +0000

Software asset management (SAM) doesn’t have to be a daunting process. It can be very simple and rewarding if implemented properly. Here are six necessary steps to a successful SAM program (tongue twister eh?):

1. Know and understand your SLAs for all your software vendors (not all licensing agreements are created equal), the terms and conditions, and if you have questions, ask your rep or a consultant to explain them to you. Now this seems basic and it should be, but I would be remiss not to mention it here as the first step.

2. Take an inventory of all of your IT assets - software and hardware. With Oracle entering the hardware business, companies need to be aware that this may be of significance to future ITAM. Keep track of what is currently in use, who has access to it and where it is being used. Is it being access remotely? How many employees are using it at the same time? While this sounds simple enough, take step 2 and tie it back into step 1.

3. Compare and Contrast your inventory to the most up-to-date software purchasing records to determine whether or not you have assets that are out of compliance. This should also be checked against employee usage - perhaps more than one employee is using the same licensing which does not comply with your SLA on that program.

4. Fix the problems once you know what the problem is, uninstall software that is not compliant, buy additional licenses and re-negotiate your contract(s). You must plan for the needs of the business over the next 12-18 months to determine whether or not additional licenses will be needed in the near term.

5. Further planning is needed now that you have a clean slate and have fixed compliance issues. Now is the time to implement a plan for the future, which may include developing a repository for assets, purchasing SAM software with an automated discovery tool, or bringing in outside help. It is always a good idea to assign a group of internal managers to oversee the process and of course, get buy-in from the management team (which can be done by showcasing cost savings associated with a proper SAM program). You will also need to develop and market a new set of policies and procedures across your organization that will keep employees from misusing licenses.

6. Keep it up! After a plan is in place; policies and procedures have been created and communicated; and licensing is up to date, the last step is maintaining the SAM program. Remember to:

Continually run reports on your IT assets to ensure that you are remaining in compliance as business needs change

Re-educate employees on IT policies as turnover occurs and/or the business changes.

Guard your assets – for example – when an employee leaves the company, be sure that they don’t have copies of your software on their home computers or have a burned disk of your software. You are liable for the terms and conditions, not the ex-employee.

GRC for financial compliance

ScottR — Mon, 29 Jun 2009 15:00:52 +0000

We are always talking about software asset management (SAM) as a means to cut costs and also keep up with compliance. For financial firms, SAM, combined with a Governance, Risk and Compliance (GRC) program are a necessity to keep those regulators happy. Many firms choose to use GRC software to automate the process should they get audited (which the frequently do) to have information at the ready. Here are some tips for those that are in need of a GRC program to track data and remain in compliance:

Location, Location - know where your important financial data resides, you will need to be able to map where your data is at all times and be sure to have a structure in place to track it. This can be done with network diagrams or even with a discovery tool.

Controls - controls and/or policies should always be in place to protect your data. Who has access and who does now also needs to be tracked. Create a repository, just like you would for your software assets, for your financial controls, policy documents and security configurations.

Log all activity - you need to track your systems vulnerabilities, know who is accessing what and when.

Process for mapping data - a good GRC software program should have an underlying workflow and project management engine that can link data to specific regulations. This way, multiple reports can be automatically generated, creating a central compliance reporting process.

Another thing to consider when shopping for GRC software is that not all organizations have the same needs; therefore, finding a solution that fits your business may be a larger task than the actually implementation. Keep in mind that there is a difference between compliance and security and both should be addresses as individual processes. Regulators will be looking for processes for both to be in place and therefore both needs should be addressed.

Processor/CPU licensing: Intel Hyper-threading throws off count

ScottR — Wed, 24 Jun 2009 15:00:29 +0000

Some processors have a dual core, single chip that appears to be two CPUs within the Oracle kernel (the Oracle kernel determines the number of CPUs on a system during start-up). This is the case with Intel Hyper-threading, where the number of physical CPUs doubles when running on Linux or Windows with a hyper-threading setting of OS or BIOS.

Oracle will charge a CPU license fee for the extra cores in multiple core CPUs. Therefore, you will need to license for each CPU core in multiple core CPUs, meaning that a hyper-threading CPU is considered a single CPU for licensing, but a dual core CPU is considered 2 CPUs for licensing.

However, when Oracle audits/asks the OS how many CPUs are in the system, the OS just reports the total number of logical CPUs. In the case of Intel Hyper-threading, if the one core looks like two processors, then it is counted as two; therefore, two separate licenses are needed.

Embedded Software License

ScottR — Mon, 22 Jun 2009 15:00:43 +0000

A number of years ago, Oracle introduced its Embedded Software License (ESL) model - available to Independent Software Vendors (ISVs). Once in a while, we get an extremely nervous ISV who didn’t understand the licensing restrictions on ESL …..

The ESL is a highly restrictive license that allows ISVs to embed Oracle technology into their products. The end-user would not necessarily know that they are using an Oracle-powered product. Examples of possible systems using this licensing model include point of sales systems, kiosks, online commerce or an electronic library. It can be any system that requires a database to capture or become a repository for information or transactions.

The one item to note in the ESL model is the party responsible for Oracle software licensing agreement (SLA) - the ISV. Therefore, if you happen to be using the ESL within a market or markets, be cognizant of the usage, users and any alterations to the program that might affect your Oracle licensing.

Microsoft License Advisor

ScottR — Fri, 19 Jun 2009 15:00:51 +0000

Hmmm, an online self-service resource - Microsoft License Advisor for Volume Licensing - can be used to figure out what licensing needs your company has. This is a great initial start to understanding licensing needs. It’s also a great marketing tool for online self-service resource.

Only issue is that it doesn’t give you insight into how you AREN’T compliant. Devil is in the detail!

Ignore the too-chipper voiceover. It gets on your nerves after the first 30 seconds.

Processor/CPU licensing: Multi-core

ScottR — Thu, 18 Jun 2009 15:00:32 +0000

Software vendors have different licensing rules. With Oracle, you have to understand that you’re licensing per processor (CPU) for running the Oracle software, versus per user. There are various scenarios and factors that change the licensing and pricing. For example, multi-core processors are counted by number of cores, and processors have a different multiple.

0.25 for SUN’s UltraSparc T1 processors

0.50 for Intel and AMD processors

0.75 for SUN’s UltraSparc T2 processors

0.75 for most other multi-core processors

1.00 for single-core processors

Note: There are many variables that may change the core processor count or formula. But, in general, the above count is a good baseline.

Proactive Auditing: Software compliance

ScottR — Thu, 18 Jun 2009 13:52:04 +0000

I wouldn’t have said it better myself….

News: Oracle Holding Firm on License Discounts

ScottR — Wed, 10 Jun 2009 19:27:27 +0000

Yesterday’s Open Q&A Forum on Oracle licensing, audit and procurement was very much a success. Chris Kanaracus (@chriskanaracus) did a great condensed summary on one of the points being made – what’s happening during Oracle discussions.

Read the entire article from ComputerWorld: Consultant: Oracle Holding Firm on License Discounts

SLA – it’s never done

ScottR — Fri, 05 Jun 2009 15:00:43 +0000

Many of our clients think that once a Service Level Agreement (SLA) is signed and agreed upon, it’s untouchable until the end of the term. This is not the case in most circumstances. In fact, a good SLA should be changed periodically. Particularly, in the case of penalties and rewards built into the SLA, where there is often a need for change. Let’s say, for example, the software vendor is repeatedly missing deadlines and it has become detrimental to your business. Re-negotiating the SLA and increasing the penalties is a motivation tool to get that vendor to meet your deadlines. Otherwise, you’ll have to find another vendor that can do the job. This is the same should the rewards be paying out very well to the vendor - if the goals are being met so easily, perhaps a higher goal should be set to raise the bar?

SLAs are a tool, to be used by the purchaser and by the vendor, to insure quality service is provided over the life of the contract. Just because its signed, sealed and delivered, does NOT mean there is no room for re-negotiation.

SLA = shared goal

ScottR — Wed, 03 Jun 2009 15:00:29 +0000

One of the best uses of a Service Level Agreement (SLA) in our eyes is its use as a way of setting goals for the vendor. When implemented successfully, an SLA can be a means to manage risk, and create accountability on both the part of the vendor and your own obligation to the technology investment. We have seen many SLAs with built in penalties for vendors for non-performance, and/or missed deadlines. This can certainly work in your favor in two ways- cost savings and motivation for the vendor to get the project done on time and in good form.

The reality is, that the goal set forth by the SLA is a shared goal. If the terms are not met, everyone loses. Therefore, it’s equally as important as the vendor’s participation, for you to be actively involved in the goals of the project in order to be successful.