Well, the fat lady has sung, and Novell is no more. I'd like to say the company fought the good fight, but I can't bring myself to do so. I expected, or at least hoped for, a better end. We are now evaluating our options as to how quickly we can work our way out of Novell's presence in our environment. File and print? Underway. Zenworks? Probably no later than the end of this year. Novell client? A little longer; that wraps into e-mail. We are evaluating RFPs now, and should have an action plan for conversion in 2012. That leaves Linux. We have been heavily committed to SuSE, using it for file and print as well as Oracle RAC clusters. File and print will be going Microsoft, and our AD implementation is in process. I expect that we will migrate our Linux to Red Hat. I have no desire to put our databases on Microsoft servers - they tend to be too expensive and clustering for RAC is hard enough in a Linux environment.
I hope Attachmate likes owning what's left of Novell - I expect operations similar to ours are making similar plans, and in the next few years Novell will be another memory, something like Netscape. Bits and pieces may live on, but the vital essence will be gone.
Labels: Microsoft, Novell
SCO v. Novell
Well, the next round in this fight is over: see this article on Groklaw
. Novell owns the copyrights, according to the jury, which effectively moots SCO's slander of title claim. There are still some issues for Judge Stewart to decide, and there is some concern that he may assign the copyrights to SCO under specific performance. We'll see how that works out. And, of course, we will likely see SCO appeal this judgment, just as it did the previous decision under Judge Kimball. This case is at seven years and counting. . . .
The bankruptcy trustee, Mr. Cahn, has expressed his disappointment at the decision, but has said that he will continue the fight against IBM. Given that almost the only thing left in that case are the IBM counterclaims, it is hard to see how that one can turn out well.
And there is the Novell appeal to the US Supreme Court, asking the High Court to look at the 10th Circuit Court of Appeals decision. That is a narrow issue, dealing with how copyrights transfer. The decision of the 10th Circuit is out of step with other circuits, where more specificity in the written document of transfer is required. But as of now, we don't yet know if the High Court will take this up or not. It appears eligible, because of the split opinions of the circuits. But mere eligibility is not enough.
One more story in the Linux saga. The next installment will be interesting!
Here We Go Again
Gosh, this feels awfully familiar. I haven't blogged here for over a year, and now it is on the same topic as my last post. Oracle has filed suit against Rimini Street, a third party provider of maintenance for a line of Oracle products (among them J.D. Edwards and PeopleSoft). The suit, filed in California, is filled with allegations that look very similar to those in the suit Oracle filed against SAP / TomorrowNow. It alleges "massive" intellectual property theft by Rimini Street employees, who supposedly use valid Oracle customer IDs and passwords to download more information than the customers are allowed. Oracle has also asked for a preliminary injunction that would prohibit Rimini Street from doing pretty much anything having to do with Oracle code. That will essentially put the firm out of business and strand its customers.
The organization I work for is such a customer, and we have been very pleased with the support from Rimini Street. It certainly beats the support we received from PeopleSoft and Oracle. Rimini Street is much more responsive; we typically get responses within hours - not days. Oracle's suit states that Rimini Street can't be providing the same level of support as Oracle - it has nowhere near the resources. That is true, as far as it goes. But guess what - WE DON'T WANT OR NEED THAT LEVEL OF SUPPORT! All we want is to keep our "frozen" level of software running and to supply us with required tax and legal updates. Upgrading every one or two years cost us about $500,000 per upgrade, and we were not taking advantage of the new functionality anyway. Further, most of the maintenance fee goes to new product development, providing features we have no interest in using. The model that the major software firms use may be good for them; it is not necessarily good for all their customers.
Rimini Street indicates that it will "vigorously defend" the lawsuit. See an article in ComputerWorld commenting on the suit here
, and an interesting blogger's view here
While I sincerely hope the suit goes nowhere, we are beginning to look for alternative providers as a fallback. This is NOT something we wanted to get into again after moving over from TomorrowNow. As I said, we're pretty happy with Rimini Street and feel it is a good value.
One more thing - the complaint alleges that Rimini Street downloaded more information that was allowed to the customer whose ID / password was used. This was the same complaint Oracle made against TomorrowNow. Wouldn't you think a company with the resources of Oracle would have figured out a way to plug that hole after it was exploited the first time? I'm not condoning Rimini Street's behavior if it did what Oracle alleges, but this still makes me wonder.
More updates to come as this proceeds. You can be sure I'll be watching closely.
We're in the midst of determining what to do now that our third-party support vendor for PeopleSoft (TomorrowNow) will be departing the scene. We were notified about a month ago that SAP was pulling the plug on TN. While SAP was not explicit about the cause, it is almost certainly due to the significant legal cloud hanging over TN's head. It has been public knowledge for some time that SAP was shopping for a buyer for TN, but apparently no one wanted the liability given the assets.
This is a major disappointment. We were quite satisfied (well, most of us were) with the service and support from TN. From IT's perspective, TN helped us solve issues that neither PeopleSoft (in its original corporate form) nor Oracle (after it acquired PeopleSoft) were able to address. I think that is significant, and I believe it is entirely due to the business model TN followed. Software vendors have little incentive to fix certain classes of problems in a given release; rather, they wrap the problems up in a subsequent release. That works well as long as you stay current. However, staying current with PeopleSoft was very expensive for us, particularly given that we do not use much of the base functionality of the application. Freezing at our current release level and going with third-party support made much more sense - or, at least, that's what I believe. For the record, I was not with this organization when they made the commitment to PeopleSoft, so I can't comment as to the appropriateness of the original decision-making process.
TN's departure from the scene is also causing a mini-crisis. We have to get a new support vendor by the end of October. We have been on multiple conference calls, and are continuing to check references. It comes down to one of two choices; go back to Oracle for support, or find a new third party-vendor.Oracle
This is the safe choice, but it will be a budget-buster. This is due not only to the raw support cost (roughly double what we were paying TN), but also because Oracle's first question is ALWAYS "Have you installed the latest bundles?" That means we will have to upgrade our current installation of PeopleSoft, and keep installing bundles as they are released. And, by the way, the bundles rarely, if ever, solve the problem we are experiencing. It is just another hoop you have to jump through to get to the support you really need. Another hidden cost is that it appears Oracle is investing little in PeopleSoft upgrades; rather, we will be paying for Fusion development. Whether we would ever migrate to Fusion is unclear. According to Gartner, it is likely that a migration to Fusion for us would be more like an implementation of a new application, with all the significant costs that entails. And we want to pay for that with high support fees?
However, there are some of our users that insist this is the best option. PeopleSoft is, after all, the users' application, not IT's. If that is what they want and they will fund it, that's where we will go.Third Party
TN has offered us a list of third party support vendors, and we are now performing reference checks and other due diligence. Because of some non-disclosure agreements I can't get much more specific. However, it is good to know there are other third party vendors out there delivering much the same product as TN. They all appear to have learned from TN's mistakes. That issue is a significant portion of our due diligence, as we don't need another surprise like this one anytime soon. I personally like the third-party approach, and think it will fit us well until it comes time for us to replace PeopleSoft, sometime in the middle of the next decade. Oracle support for the current PeopleSoft version ends in 2014; that is a little soon for our comfort level. Third party support can keep the application alive for some time past that, although I am concerned that the technology platform and / or stack may become obsolete and cause other support issues.
I'm sure it will be interesting reaching a conclusion, although as I keep stating it is not an IT decision. We have an opinion, but in this situation we will go whichever way the user groups feel is best.
Daylight Savings Time
Well, folks, the infinite wisdom of those folks in the US Congress has demonstrated itself yet again. The modification of the rules for going onto and off daylight savings time has created a fair amount of inconvenience (if you are a computer user) and downright extra work (if you are in a corporate IT position). Unfortunately, while the vendors understand they need to make changes, they haven't really investigated what is needed in total to achieve success. Therefore, we have patches from one vendor that are dependant on another vendor to be successful.
Let me give one concrete example, from last week's experience. The Help Desk began receiving calls that appointments in late March appeared to be an hour late. Shortly after getting some of those, we started receiving additional calls that the working hours in late March were showing later than they should be shown. Well, after digging into all this, it turns out we did appropriately patch our Novell GroupWise application (version 7). What we didn't know, though, was that there was dependency on the Windows desktop knowing about the change as well. The Novell patch was delivered in February, and we duly installed it. From the server perspective, it worked as advertised. However, on a desktop, which we didn't examine closely enough, it did not work. Microsoft delivered their patch in mid-February, too late for us, as it turns out. We have pushed it out via WSUS, but the for the additional three weeks in March and the one week in November appointments are an hour late. And at that, we're fortunate since we're geographically limited to a single time zone. I suspect it would be worse for those that span time zones, particularly outside the US. We're in recovery mode right now, and should have everyone back to snuff next week.
This certainly isn't Y2K, but we are spending more time investigating time dependent systems. In particular, we are looking at those that are outside our network, but look at the time for handling functions like adjusting environmental conditions or locking / unlocking doors.
Just when you thought it was safe to back into the water ........
Security vs. Usability - A Good Fight
Oh boy, a good old slugging match, and from two writers for the same magazine, no less. Bob Lewis writes on Information Security, Off the Deep End
in response to Roger Grimes' Unauthorized Applications (still) a bad idea
I find myself in agreement with both points of view. I have great sympathy for Roger's (as well as most IT managers') dilemma in trying to keep the place secure in the face of increasing pressures. At the same time, though, Bob correctly observes that people do unsecure things because they are trying to do their jobs.
So how do I reconcile the two? Actually, I think Bob has most of it right, as he observes that a good IT department will be listening to its users and have appropriate tools in place. If someone wants to work from home and get data from the office there should be some type of VPN connection and either access to files or Citrix in place to make that possible in a secure manner. Need a laptop because you need the applications as well and either don't have the bandwidth or some other restriction? That should be thought out and machines should be available as well.
Where Roger is correct, however, is that user's shouldn't be allowed to use applications that haven't been through the acceptance process. The word "process" isn't meant to imply some long, drawn-out affair. It is meant to see that IT supports only the number of applications it really needs to, and that it has a decent handle on the security implications of those it supports. Otherwise, you could easily have half a dozen (or more) IM solutions running around, with significant support and security implications. As Bob says, implement a secure corporate-wide IM solution.
Security needs are valid, and with the ever-increasing number of security violations that are in the news, no organization can afford to ignore them. What the IT department needs to do, in conjunction (hopefully) with top management, is strike an effective balance between the security needs and efficiency / productivity needs of its internal customers. This implies, of course, an IT department that is "on the ball" and listens to what its users need to be effective. Easier said than done, of course, but after all, IT is (typically) in the internal customer service business. If you're not delivering what users need and what the organization needs, why are you around?
The recent issue of InfoWorld (July 10, 2006) features net neutrality on its cover, and in a series of articles. One, "Battle Lines Drawn Over Net Neutrality"
sums up the issue and the players.
I've been sitting out during this debate for some time. At first, I did so because I wasn't sure I really understood the issue. Shortly after, once I figured that out, I stayed put as I believe there is merit in both sides. After due consideration, however, I've decided to finally cast my vote - which is, that we don't need rules for net neutrality. At least, we don't need them today.
I believe the fears of the players like Amazon and Google have possible future validity, but they aren't true today. And, as we all know, legislators can't really dictate a desired result. All they can do is either punish "bad," or undesired behavior and reward "good," or desired behavior. And with all the competing interests at play, the process is at best cumbersome, with little finesse, and at worst disastrous. Given the money and lobbyists at work on this issue, and you have a recipe for rules that none of the companies involved nor the public would find palatable.
And so, I think it is best to let events transpire uninhibited by legislation. If truly destructive behavior does begin to appear, then Congress can address it and do so in a more surgical manner. At the same time, we unleash the market to do what it does best, which is innovate.
If the telcos and cable operators want to offer higher speed, specialized offerings that command premium pricing, let them do so. Will there be the opportunity to indulge in some "channeling" that allows for favortism? Absolutely. Will the owners of the pipes indulge in that behavior? Most likely. However, I'm not yet convinced that is automatically a bad thing, which is the argument raised by Google, Amazon, and others.
In the meantime, the best thing for those really worried about what might happen is to concentrate on making your web presence, whatever that might be, as compelling as possible for your target audience. That stands a better chance of keeping you intact and growing as innovation roils the Internet than any other action.