IT Management Blog: my thoughts about putting the "i" in IT

Know your licenses - Oracle e-business suite licensing hell

As a customer you often need to know the vendor's software licensing rules and constructions better than anyone from the vendor.

Take for example Oracle's E-Business Suite. When you buy the EBS, you get in theory the Internet Application Server and the database (DBMS) for 'free' as part of the package. This is the theory. In reality you need to buy a full license for them.

We are faced with the challenge of upgrading from release 11 to release 12. There is the option to buy extended support so we would be able to delay the upgrade with a year or two. To evaluate this option, I asked Oracle what the extended support costs for us would be. We have only one signle installation of the Oracle EBS, so it would be all or nothing. However when you ask the question whether you need to buy extended support for the database and the application server as well, you are directed to others within Oarcle. Nobody within Oracle will have a full and holistic understanding of the licensing. However, you as client are required to know it all.

Image: Creative Commons
So far, it sounds that extended support for the database is not required for the database as long as you make sure the version is on a supported level. From what I gather, the same applies to the application server.

However Oracle writes in its "Oracle Information Driven Support document - Oracle Lifetime Support Policy - Oracle Applications" document:

Extended Support for Release 11.5.10 requires the minimum baseline patches defined in My Oracle Support Document 883202.1. Customers running Oracle Fusion Middleware 10gR2 and 10gR3 in the Oracle E-Business Suite version 12 internal technology stack will remain supported for the duration of the support period for Oracle E-Business Suite 12. All Release 12.0 patches and Critical Patch Updates (CPUs) will only be provided for Release 12.0.4 and above

So if version 12 will be supported till the end of its life on the 10gR2 version, would the same not apply to version 11 of the E-Business Suite? What I recall from the Insync10 sessions, it was said that IAS 10g would still be supported with the EBS 11i. When talking to Oracle, I find that hardly anyone really understands the question and noone can give an answer.

The EBS comes with the Application Server and the database shrink-wrapped for free. Oracle explained very clearly that they do not have any customers who do not have any form of customisation and therefore you always need to buy the database and the application server as well. If Oracle states that IAS 10g will be supported with EBS 11i, then you can assume that your customisations to certain extend will also be supported?

Extended support is 20% of the normal license support fee (which is 20% of the original purchase price of the license).

As part of our license contracts we are licensed for a module that we don't use. Removing this module from the contract would mean that the contract would be opened up and in the end would cost us more than just paying for the module as part of the current contract.
The question arises whether we would need to buy extended support for this module or not. And to answer this you need to know whether it forms part of any of the other Product Families we have: (this link requieres a login to Oracle Support)
Extended Support is available on a product family by product family basis. What this means is Customer can choose to patch one Applications Product Family area, but not another. This allows a Customer to leave areas of the code that might be extensively customized at their current levels, but gives that same Customer the option to receive Extended Support on other modules that are eligible.

And it seems that Oarcle itself has a hard time identifying this ...
Steven Chang explaining about Product Families and Versions.
As far as I'm aware, there is no straightforward means of taking a specific product and traversing "up the tree" to figure out which product family it belongs to. I agree that this would be useful, and will ask internally whether we have information we can publish on this.

The SharePoint Adoption Gap (on: the Distracted Enterprise)

Thirty seven percent refuse to use SharePoint, or use it once a month or less.

A quick and simple post this time which is basically a link to a blog post by Jenna on the "Distracted Enterprise" about the SharePoint adoption gap.

A survey by Usamp on the adoption of SharePoint identified (quoting Jenna):

  • According to a uSamp survey of 317 US business email users, only a third of survey respondents with access to SharePoint use it on a daily basis (1) Thirty seven percent refuse to use SharePoint, or use it once a month or less. Why? People say it takes too much time and effort to search, access, and share documents on SharePoint. From email, they have to switch contexts, juggle multiple browser windows, and learn a whole new way of collaborating.
  • Email remains the #1 business communication and collaboration tool, preferred 2 to 1 over the phone. In fact, 80 percent of survey respondents with SharePoint access resort to email ping pong when it comes to document edits.
Read the article here:

You're not alone!

Forget governance, I want an iPhone!

We have seen that iPhones and iPads have become popular products, firstly for personal use and secondly now within the business context. In our organisation we went through a similar process to ‘adopt’ these devices as I expect as it would have taken place in many other organisations. Though I think that these devices are great products, I just want to reflect on the process of how these devices seem to be rolled out in some organisations. Besides the business reasons, there is that other pull of the new shiny device... Normal governance does not seem to apply to iPhones.

You hear more and more that IT departments are not able to keep up with the speed of how technology and specifically consumer technology changes. I read that about website development including the use of social networking sites and also about all the mobile devices. I don’t really belief that the IT department per se is not able to keep up with the speed of these new developments but that one the one side they are not given the funding and resources to work on these items and that on the other side they bring quite often many practical issues on the table. These issues are usually considered road blocks by management and the business.

When in our organisations the first calls for an iPhone were raised and for good business reasons, we said that we could provide one to a selected few people but that there was a big risk in relation to security. We simply did not have had the time to assess the risks for the network and for the sensitive data on the device itself and find ways to control them. We could do that with the Blackberry which was our standard mobile phone and for the time being advised against iPhone for broader roll out.

This is not much different as it happened in a large organisation in Australia. Management wanted the iPhone but the IT Department raised issues in relation to the risks. The device was however so appealing to management that the response simply was “Give us the phone or else ....”.

It is actually funny to observe how the iPhones with their security risks have been rolled out into organisations. These days auditors are very strict in relation to security and business continuity. Just like many other organisations we have now strict rules around our network security, password policies, etc. When I informally asked our auditors what their position was in relation to the iPhone, I did not get an answer. But what they could tell me was that their management also used iPhones. In other words, the same probably happened there just as in any other organisation: the IT department probably advised against it but that this advice was put aside in favour of the attraction of the new shiny device. So if the auditors can use the device, they would never come with an audit report telling their customers not to use it or that they were not diligent enough with the roll out. Doctor, help yourself!

The problem we run into is that there is this nice shiny device that looks so great and so handy, that any potential risks are put to the side going against any rules and measures put in place to control those risks. In recent years many organisations have focussed on improving policies and security mechanisms to control unauthorised access to data and systems, but these policies don’t seem to apply to iPhones. If the reward is big enough, people are willing to take the risk and simply don’t want to hear about the risks. And the reward here is much the sensation and feeling good, not much different than a drug addiction. The iPhone makes you feel good and increases your status.

My wife is considering an iPhone as well. If I explain that you can get the same from a different brand with the android operating system, she just looks with glary eyes and replies simply that she wants an iPhone. And no wonder, you got to have an iPhone these days to be considered a modern human being. Would you think that 13 and 14 old kids need an iPone? Probably not but the truth is that large number of kids come with an iPhone or iPod Touch at school. On top of my 9 year old daughter’s whish-list is the iPod Touch. But with all these electronic toys, aren’t we spoiling our kids a tat too much? Can’t they just play their games on the Nintendo that was so important to have a year ago? How square can their eyes get? Isn’t there already enough peer pressure and cyber bullying?

The initial risks that we identified with the iPhones was that sensitive data will be stored on the device, specifically because they will be used by the those on the most senior level. This risk is primarily with the loss or theft of the device making all the data on the device is accessible by the new owner. The risk that the phone would be hacked remotely to gain access to the corporate network would exist as well but I considered that risk already much lower but not unrealistic. You’ve spent millions to secure your network from all sides just to open a new door?

To mitigate the risks and provide support to the mobile devices, the helpdesk and some key IT staff need to build up their knowledge and experience and therefore need to use one themselves. Of course they understand the technical risks and you expect them to use it sensibly. It is not unthinkable that some of them are not immune to the attraction of the device. They might opt to access various systems via the device and therefore introduce the real risk for hackers by storing various network addresses with usernames and passwords on the device. That device with its high risk of loss, theft and lack of security will then form a realistic threat to the whole network.

I see this not much different than the use of opium over 100 years ago as a solution for psychiatric problems. The symptoms temporarily disappeared and it made the patient feel good. There was in those insufficient understanding of the risks including the addiction that would follow. In those days many doctors experimented themselves with the drug as well with of course the necessary consequences. Sigmund Freud experimented with cocaine, not only for himself, but also for patients. Doctor, help yourself!

In public places I notice, that I am still one of the happy users of a classic Blackberry and do not have an iPhone. And there is something to say about the iPhone (or equivalent modern device). You can access your Google Maps or run a sat-nav program to give you driving directions. As I said before, I am quite often a big fan of old technology. For driving through Sydney I get by very well with the old fashioned street directory on paper. Specifically when it comes down to the last bit of the drive, I sometimes need to stop and look up the directions again. You might think that a sat-nav is then so much better, but I hear others who have a sat-nav also often say that they were steered in the wrong direction. I think the old technology exercises my brain and keeps it young (I love old technology), but there are of course the odd situations that you wished you had sat-nav with you.

An iPhone is of course a fantastic business tool. Browsing the web, reading emails etc. just became much easier and comfortable. I do belief there is some level of productivity gain and there are many cases where these gains can become significant. Many organisations have staff out in the field and if you can bring the relevant software applications to them on their travels, it is easy to see the benefits. It is easy to develop a business case for it.

But there are also so many instances or aspects of the roll out of those devices that purely are driven by the feel good sensation and I observe that common sense is being put to the side. Whether that is that we give in to our kids or demand as executives what that they give us the latest gadget. We should consider better if this really is the right thing to do or if we should first develop our business case and assess the pros and cons.

Let me make it very clear that I don’t have anything against iPhones! This is not a rant against iPhones. Apple did a fantastic job and finally delivered something that was already anticipated over 10 years ago during the heydays of the Internet boom.

I think that the IT department should be given more time to evaluate such a product and develop their control mechanisms and that you also should give the product itself the time to mature. Over time Apple introduced improved security mechanisms and the question is whether you should give it a bit more time to mature and really need to jump on the bandwagon straight away.

There are many good business cases for mobile devices such as the iPhone and in combination with the above you should work those out. Feeling good is always important in life – at work as well as at home. But sometimes you should also consider whether it really improves your productivity and what the real benefits and threats are. Of course I also want an iPhone but for now the Blackberry suffices, just as my street directory.

Just a note for mothers. I think that all mothers of young children should have an iPhone. All parents know that babies and toddlers prefer their parents keys and phones above all toys in the world. And the beautiful thing of an iPhone is that it is not only a nice shiny thing, there are actually moving images on it. It is a small TV and we know what that does to kids. It keeps them quiet! iPhones signficantly reduce the screaming and crying in public places. Here some apps. The iPad with fully downloaded movies will be the next step in this silent revolution.

How many bugs a day do you make?

The other day I did a little exercise and calculated how many bugs a day were created in my recent custom development projects. I compared two outsourced projects with two internally managed projects. I wanted to see how many bugs were identified by the end users as part of the acceptance testing and how many are found by the testers as part of the system testing. For the latter I did not have the details from the vendors for the outsourced projects.

There was a big difference between the internally managed and outsourced projects. Our end users hardly found any bugs during their acceptance testing for our internally managed projects. But the outsourced projects resulted in a total number of bugs found during user acceptance testing equivalent to the total number of bugs we found during our system testing for the internally managed projects. In other words, the vendor seemed to off-load the proper testing to us. Not happy.

The number of bugs are usually measured based upon lines of code (LoC). I calculated it by developer-day. There are many problems measuring bugs with either metric. Lines of codes measured as the total line-count in the set of source files does not mean much. You measure empty lines, comments and simply the layout style of the programmer. I know for example in C, you can have many lines with a single character while in many 4GL programs that would hardly occur.

Bugs per day have problems as well. First of all, my total day count was a rough estimate for our internally managed projects. I do not keep a tally for my internal developers. For the outsourced projects I used the project costs divided by the day rate that the vendor usually charges. But that is probably not the actual effort the vendor put in. So we should be careful about being too smart with these numbers.

For various other reasons, I do like to have a bit of an idea how effective developers are and how many bugs they leave in the code when they give it to the testers. And for us as a project team, how many bugs we leave in the system when we give it to the end users for acceptance testing. There are many aspects involved in programming, but in the end simply measuring the number of bugs per developer-day gives me a bit of an idea.

I think it is common knowledge that its cheaper to have a bug found and resolved by a developer than found by a tester and given back to the developer to fix. The same logic applies to bugs found by end users versus bugs found by the testing team.

I found that the number of bugs in general turned out to be between one to three bugs per day and specifically for our internal projects towards one bug per day.

The crucial insight in the exercise was that our internal development resulted in a much better service to the end users.

There are many reasons why this happened.

First of all, I have included the people involved in the requirements and analysis of the business process into the testing team. The Business Analyst and Service Delivery Manager who had first hand interaction with the business would find most of the flaws similarly as the end users would. Better even, because they really focussed on the testing while end users would do it much more superficially. For the outsourced projects, we created the requirements internally and provided these to the vendor to build. The vendor was in that sense disadvantaged.

Secondly, our testers were close to the business. In cases where they were uncertain about the right behaviour it was easier for them to consult the business. The vendor worked on a different location and this case on the other side of the globe and had with that another disadvantage.

I must conclude that the closer the development team is to the business, the more effective the development and testing will be. I think I already knew this ;).

For the future I will challenge my developers to create less than one bug per day.

For outsourced projects I will need to consider to put some metrics in the contract around the number of bugs.