We're trying to figure this question out. Again, simple lab install of a product using the newest available media...problem after undocumented problem have cropped up, and nobody within our reach seems to have any concrete answers (or blame to lay).
We're on the cusp of a pretty big project, and the timeline is severely compressed. We don't feel confident enough in NetWare to support the project long-term...so, unfortunately, for the first time ever, we have to decide between OES (about which we know nothing yet), or Windows Server.
Novell have been sent a series of flares and distress signals (and we are a 'reference' / success-story account)...unfortunately, we've been let down by the sales organization as a whole in bringing focus to our plight.
Good thing my rolodex is filled with the names & numbers of old friends who still roam the Provo halls. With a little luck, we'll get the help we need to translate our significant NetWare expertise to the OES/SLES platform combination.
Tuesday, December 13, 2005
Thursday, November 10, 2005
ComputerWorld IT Management Study Released
I recently participated in a study conducted by ComputerWorld, asking questions about IT management and strategic vendors, etc. The results were forwarded to me today, and I found them to be pretty interesting.
Of particular interest was the fact that Dell and CDW - two vendors that are well known in the market, but with whom we've not had great experiences - appear to be less important to companies the larger they get. Companies below 1,000 employees find Dell and CDW to both be very strategic, but beyond that, neither has made enough headway to be frequently considered a "top" vendor.
IBM on the other hand, is virtually off the radar until your company reaches 1,000 employees in size. If that's you, there's a 50% chance you would name IBM as your "top" vendor.
I once developed a PowerPoint deck entitled "Why Dell Doesn't Get It - A Summary View from a Customer at a Crossroads", and dropped the bomb on our Dell account team when they showed up for a visit one day. It outlined the atrocities they had committed toward us in the form of product design and support of our strategic OS platform, and in overall product quality.
From that day forward, our rep never showed up without first confirming a projector wasn't awaiting him in the conference room. That PowerPoint deck made it to a bunch of people at Dell, and we continued to give them opportunities to do the right things for us (fix problems they caused us). In the end, Dell took the position that an expenditure on their behalf to help correct a significant set of Dell-admitted issues with their RAID controllers was greater than our value to them as a customer.
We're no longer Dell customers.
Of particular interest was the fact that Dell and CDW - two vendors that are well known in the market, but with whom we've not had great experiences - appear to be less important to companies the larger they get. Companies below 1,000 employees find Dell and CDW to both be very strategic, but beyond that, neither has made enough headway to be frequently considered a "top" vendor.
IBM on the other hand, is virtually off the radar until your company reaches 1,000 employees in size. If that's you, there's a 50% chance you would name IBM as your "top" vendor.
I once developed a PowerPoint deck entitled "Why Dell Doesn't Get It - A Summary View from a Customer at a Crossroads", and dropped the bomb on our Dell account team when they showed up for a visit one day. It outlined the atrocities they had committed toward us in the form of product design and support of our strategic OS platform, and in overall product quality.
From that day forward, our rep never showed up without first confirming a projector wasn't awaiting him in the conference room. That PowerPoint deck made it to a bunch of people at Dell, and we continued to give them opportunities to do the right things for us (fix problems they caused us). In the end, Dell took the position that an expenditure on their behalf to help correct a significant set of Dell-admitted issues with their RAID controllers was greater than our value to them as a customer.
We're no longer Dell customers.
Wednesday, November 09, 2005
Concerns about Novell - Layoffs, etc.
I've had the opportunity of late to provide commentary - directly and indirectly - to Novell regarding their long-term viability. This topic comes up as a result of their recent layoffs, which as I had stated earlier, do not surprise or concern me greatly.
Here's some excerpts of what I've said on the topic of Novell and 'execution':
I followed that commentary with the one below several days later, aimed at a Novell employee who still thought the onus for finding additional value with GroupWise in particular, lay outside Provo:
In response to this, I was told by that Novell employee that the "channel program" probably isn't going away, because Novell has too many smaller customers to sell to directly. It will however be changed significantly. I was told, however, that the team responsible for marketing GroupWise is definitely focused on selling it in the form of point solutions.
My reply:
Here's some excerpts of what I've said on the topic of Novell and 'execution':
"Nobody will tell you that Novell's problems are technology related. Unfortunately, marketing alone isn't going to fix the most significant problem facing our Provo friends. There are a lot of sacred cows at Novell, and very few people there are brave enough and/or sufficiently empowered or incented to slaughter them in pursuit of the greater good.
If Novell suddenly happened upon the ultimate advertising campaign, all of the underlying issues within the organization - the self defeating corporate architecture that has been built there over years and years, the lack of communication, direction, and ability to execute - would come sharply into focus.
...
I've no doubt that Novell is committed to keeping GroupWise around for a long time, because tens of millions of seats renewing each year pay a lot of bills. I'm also excited to hear that consultants are replacing Exchange with GroupWise. My fear is that without a significant series of changes at Novell, none of that will matter.
Novell's problem is that they are no good at engaging medium-to-large companies as strategic partners. As others have noted, Novell is great at developing products that allow IT groups to spend less time on tactical activities - once these solutions are in place, there's very little on-going sales opportunities. To be a strategic partner, you need to be able to provide simple, effective, solutions that add value, not just help to avoid costs. ZENworks is primarily a cost avoidance investment -
it doesn't make duties disappear, it just makes them vastly simpler and less
expensive to perform. To a large extent NetWare was kind of in this boat -
you could perform the same duties for a larger number of users, with fewer IT
staff (or in less time). Cost avoidance.
GroupWise could be a strategic platform for companies, but neither Novell or any other third party have been effective at developing applications that meet the "strategic" test. The fault for this situation can be widely dispersed, but Novell doesn't make money by finding fault or assigning blame. GroupWise could and should be the foundation for document management, workflow, intranet publishing, knowledgebases, customer self-service, etc. All of these things add value, because they make non-IT employees (e.g. the business) more efficient. They are all, therefore, strategic. And yes, I know that GroupWise has a DMS capability. However, if it's something that two former consultants, a CNI, and a CNE can't get working reliably, it's too damned hard to use.
In all my years dealing with Novell, I've never seen or heard of anyone presenting GroupWise as the foundation for a BPM/re-engineering/intranet/document management strategy. I have sat through hour long demonstrations of nifty client features, while nary a word is spoken about back-end management. I've also sat through demos where every feature was positioned against Outlook.
For a person in my position (Manager of IT for a $1.5 Billion company), this kind of thing is maddening. "Better than Outlook / Exchange" is not the same as "great" or "exceptional". I don't use Outlook or Exchange. I don't care how great the client is. What can I do with this tool to provide a strategic benefit to my company? I will immediately take issue to anyone who argues that this is forefront in Novell's marketing strategy, because we have challenged Novell's sales and SE teams for years to differentiate themselves - they have failed at every opportunity.
For Novell to be relevant, they need to be able to sell themselves as strategic partners to VP's, SVP's, and CxO's. Nobody in the boardroom cares how nifty the client is, how many seats you've sold, or the cool indexing features in the DMS system. Companies don't have document indexing problems, they have business
problems. When Novell figures this out, discussions like this will be a
thing of the past."
I followed that commentary with the one below several days later, aimed at a Novell employee who still thought the onus for finding additional value with GroupWise in particular, lay outside Provo:
"As I've stated before, if Novell wants to become/remain relevant to larger enterprise organizations, they should be developing presentation decks right now titled "Improving Business Processes with GroupWise", or "Enterprise Strategies for GroupWise Document Management".
Novell has continually barraged customers with product features, leaving it to them to figure out how best to implement them. All around you, competitors sell lesser products as point solutions, with the added benefit of re-use for other purposes. If you're relying on the channel to be the "value add" part of the equation to large enterprises, you're kidding yourself. My company, like many others, doesn't deal with the channel because they rarely ever truly add value. Looking at revenues, etc., I think the question "How's that working for you?" is valid here.
One of the most significant sacred cows in Provo wears a nametag called "Channel Partners". Slaughter it, butcher it, and serve a big steak lunch in the quad behind Building H. When everyone's done eating, go back and figure out how to sell your products as value adds / strategic assets to companies yourselves."
In response to this, I was told by that Novell employee that the "channel program" probably isn't going away, because Novell has too many smaller customers to sell to directly. It will however be changed significantly. I was told, however, that the team responsible for marketing GroupWise is definitely focused on selling it in the form of point solutions.
My reply:
"...please know that I wasn't advocating Novell sell directly to every customer, but that you not rely on the channel to make your value propositions to large enterprise customers (as has been done for some time). As a former employee, the argument I heard against this wasn't the size of sales force required, but that acting in this way would alienate channel partners. I found this to be alarmist and
unfounded - companies like mine have always dealt with Novell sales directly.
We've not seen GroupWise effectively positioned as much more than a mail product. It's issues like this I'm interested in seeing fixed - not only for myself, but for the health of Novell as a company."
It's amazing to me how much Novell professes to care about and invest in GroupWise, given how little they do to reduce adoption barriers in large enterprises. This problem isn't GroupWise product-specific though - it's pervasive throughout the company. I certainly hope that changes...soon.
Monday, October 31, 2005
The axe falls in Provo
As I indicated in a reply to a comment earlier this month, rumors regarding Novell layoffs are rarely false. Sometimes the figures are wrong, and the timelines aren't well known, but both are easily guessed.
Thursday, Information Week reported that the big red "N" will in fact be eliminating around 1,000 jobs. The good news to me, is that many of the jobs on the block are in the Consulting branch. The acquisition of Cambridge Consulting was done more for Jack Messman than for their bench of consultants - these people had very few practical implementation skills that could translate to Novell products, and the reputation & quality of Novell Consulting in America suffered as a result. Making matters worse, much of the Consulting group's management were replaced with Cambridge staff - these people had very different, borderline incompatible views of Consulting's role within Novell and to their customers. Their departure is long overdue.
I'm not certain what the signifigance of firings in the SuSE group in Germany may be, but I expect these are redundancies which have developed post-acquisition and are to be expected.
What does concern me is that Novell is losing market share, losing customers, not servicing existing customers well, experiencing flat stock price trends for years on end, and yet is still accumulating cash reserves. In fact, the reported $1.6 billion of cash-on-hand is nearly double what it was two or three years ago.
One of the principles of personal finances is that you don't save aggressively when you're paying off debt - you eliminate the debt first. Novell is being fiscally prudent, but is being irresponsible with its handling of debt in the areas of market share and PR.
I hope that some of the 1,000+ job cuts also spell the death of some sacred cows which have been roaming the halls of Provo for far too long.
Thursday, Information Week reported that the big red "N" will in fact be eliminating around 1,000 jobs. The good news to me, is that many of the jobs on the block are in the Consulting branch. The acquisition of Cambridge Consulting was done more for Jack Messman than for their bench of consultants - these people had very few practical implementation skills that could translate to Novell products, and the reputation & quality of Novell Consulting in America suffered as a result. Making matters worse, much of the Consulting group's management were replaced with Cambridge staff - these people had very different, borderline incompatible views of Consulting's role within Novell and to their customers. Their departure is long overdue.
I'm not certain what the signifigance of firings in the SuSE group in Germany may be, but I expect these are redundancies which have developed post-acquisition and are to be expected.
What does concern me is that Novell is losing market share, losing customers, not servicing existing customers well, experiencing flat stock price trends for years on end, and yet is still accumulating cash reserves. In fact, the reported $1.6 billion of cash-on-hand is nearly double what it was two or three years ago.
One of the principles of personal finances is that you don't save aggressively when you're paying off debt - you eliminate the debt first. Novell is being fiscally prudent, but is being irresponsible with its handling of debt in the areas of market share and PR.
I hope that some of the 1,000+ job cuts also spell the death of some sacred cows which have been roaming the halls of Provo for far too long.
Thursday, October 27, 2005
And on another front...
Our kind & friendly IBM account rep stopped by yesterday to see how things were going. We have a couple of pain points with our newly purchased TSM solution, which have two separate month-old "Crit Sit" incidents open...but as we continued to talk to him, it became evident that there were deficiencies at virtually every turn that needed to be addressed. New PC imaging process issues, pSeries performance issues, tape library/FC issues, etc. To talk about it out loud made it sound worse than we perceived it ourselves, which is counter to the normal scenario for us.
Vendors must hate dealing with us. The reps are usually nice enough, but if there's a crack anywhere in the foundation behind them, we're going to find it and challenge them to fix it.
Vendors must hate dealing with us. The reps are usually nice enough, but if there's a crack anywhere in the foundation behind them, we're going to find it and challenge them to fix it.
Monday, October 24, 2005
Red-headed step-child syndrome
Not too long ago, I was Red. I used to wear red underwear. Bled red. For a while, I even ate, drank, and slept red. I wasn't alone, either. I used to know dozens of customers - hundreds of people, who were every bit as Red as I was.
Most of our vendors even fancied red, although you always got the feeling they were kind of cheating on their main squeeze when they were with Red.
I'm not talking about being a communist. I'm talking about being something much, much more heinous - a Novell customer.
Now it seems, Red is somewhat out of fashion. Faded. Unkempt. Losing teeth, or something. And I'm not so certain I want to be Red anymore.
Novell is one of the most confounding organizations I've ever come across. I've been their customer. I've been their employee. I've been their partner. And it never ceases to amaze me how good they are at defeating themselves.
I've told people privately, and am willing to tell the world, that Novell will never become the company it can and should become until it learns there's no such thing as a useful sacred cow. It's likely that Novell will never learn that lesson while headquarted in and recruiting from Provo, Utah. I'm sorry, it's a very nice place to visit and live, but the gene pool is only deep at one end in Utah - technology.
As anyone can attest, Novell's problem isn't - and has never been - technology. Novell's problem is the systematic construction of self-defeating business models and practices.
In one half of the house, you have people churning out the most amazingly insightful and useful technologies the IT industry has ever seen. In the other, you have people so hell bent on maintaining product release schedules and developing innovative sales incentive programs that they become a black-hole for great ideas.
I have proof. You may have forgotten their names, but I haven't. Remember Novell Portal Services? NetMail? DeFrame? Those are a few of my favorite casualties.
Were the technologies bad? No. Did something better come along? No, but sometimes something different came along.
So where did they go? Great question. The answer is simple - Novell couldn't figure out how to sell this stuff, or indeed what to do with it at all. Some products stepped on the toes of other products...in which case, no matter how good one was, the bigger one prevailed. Pretty smart.
It gets worse. Novell's strategy and direction - when somewhat more tangible than a box of mud, changes pretty frequently. This is confusing to partners, who need to follow if they are to provide support and feed off the customer base.
When the vendor is confused, the partners become confused. When those partners are confused, they do what any smart entity does. Evaluate risk and reward. Without enough customers crying for Novell support to outweigh that vendor's cost of continuing to provide it, vendors will drop it like a hot rock.
And drop it they have.
Try to find a single backup solution that supports NAS, SAN/FC, Near-line storage pools & tape libraries, AIX, Solaris, Windows, Linux, and NetWare 6.5 Clusters. Bakbone? SyncSort? Tivoli? Veritas? Try them - I dare you. TSM's documentation for NetWare 6.5 Clustering support was copied & pasted from the Microsoft documentation. SyncSort is in the backup software business exclusively, and they couldn't figure out how to get their stuff to work reliably in a lab!
But don't stop there. Try to find an enterprise monitoring & management console that runs on or integrates with NetWare, and will scale to monitor & alert on more than 55 devices. Try to find more than one vendor who provides IP telephony integration with GroupWise.
Try to find enterprise grade contact databases, CRM solutions, call center solutions, networkable-MFC machines, printer drivers, even business-card scanners that know about or directly support NetWare, eDirectory, or GroupWise.
Try to find a single web-based or Win32-based console to administer all the parts of your Novell infrastructure!
Novell doesn't even use it's own products in-house. NetWare/OES runs a scant portion of their enterprise. GroupWise is on the way out. ZFS hasn't been part of their monitoring solution for years - the IS&T NOC uses mostly home-grown or third-party software.
Got eDirectory, GroupWise, Oracle, Active Directory, Cisco IP Telephony with Unified Messaging, and want the Novell "Zero Day Start" solution? Get ready to hire a consultant to do some breadboard patchwork driver development...at least two of those components are totally foreign to Novell's IDM solution despite their significant market penetration.
Some of Novell's own products are incompatible or losely integrated with one another. How is that possible? Everything Microsoft writes is compatible with every other thing it writes! What gives? From my view, the problem is that Novell doesn't understand the most significant law of Human Nature (I think I wrote on this earlier). "People do what they are incented to do." And in Provo, people are not incented to help out their friends in other product groups.
To the contrary, they play their cards best when they avoid contact with other product groups alltogether. Financially and intellectually, they're in a battle against their fellow employees. They are fully incented to deliver the best individual product they can - even at the expense of their peers. To hell with integration or compatibility, to hell with ease of use, to hell with whomever is already working on a similar solution.
Instead of competing against a standard of greatness, they're competing against each other. The problem is, nobody is winning.
I once e-mailed Chris Stone, asking him to please read Good to Great. He replied, indicating that he had, and agreed with many of the ideas therein. I almost bought stock in Novell that day. I was convinced that Chris Stone could knock skulls in Provo, and get rid of the idiots who keep running great technologies and ideas into the ground because they don't know how to make money from them. Apparently, I was wrong about Chris (or I was right, and he just got tired of fighting).
So to top off the facts that their products don't often work well (or live well) with each other, and that vendors are running away from them faster than Edwin Moses, with the fact that their support model is based on information that can't be less than 15 years old. Product support and upgrade protection are sold separately, and in very finite quantities - the only self-proclaimed "enterprise software vendor" to have such an arrangement in my experience.
The short of it is that you - as a Novell customer in good standing - may have a significant problem with a Novell product and not be able to get support for it from a Novell technician. A pretty significant barrier to adoption if you're considering becoming a Novell customer, or considering renewing as such.
Now mix in a myopic sales & marketing organization who can't make any of this stuff relevant to anyone but a deeply technical IT Manager or group of Engineers, and you have a recipe for long-term atrophy & disaster.
Message to Novell - I don't care about your new patch utility, I have ZEN. You want to add value? Tell me about building an intranet with simple content management facilities, that fully integrates all the Novell products I've purchased, using a point-and-click GUI and requires no code (and if you mention exteNd I'm going to tear your arm off and beat you with it).
As easy as it would be to lose faith and jump ship, I won't. There's hope on the horizon. New blood being infused into the company is sick and tired of the stupidity, and they aren't going to take it anymore. NetWare is recognized as the abominable lopsided wheel it has become, and all eyes are on Linux to carry the torch. I'm willing to stick it out and see if life is better as a Linux shop than a NetWare shop. I don't imagine how it can be any worse, but I'm obviously not good at predicting the episodes in which Novell shoots itself in varying parts of the body.
I can say that it's remarkable how good or bad a company appears to the customer, based solely on the quality of the account executive. Fortunately, we seem to have been placed into the hands of a pretty good one recently. I hope for Novell's sake that ours is the first of a growing breed.
I need a drink. Wonder if I can get a vendor to buy me a Guiness...
Most of our vendors even fancied red, although you always got the feeling they were kind of cheating on their main squeeze when they were with Red.
I'm not talking about being a communist. I'm talking about being something much, much more heinous - a Novell customer.
Now it seems, Red is somewhat out of fashion. Faded. Unkempt. Losing teeth, or something. And I'm not so certain I want to be Red anymore.
Novell is one of the most confounding organizations I've ever come across. I've been their customer. I've been their employee. I've been their partner. And it never ceases to amaze me how good they are at defeating themselves.
I've told people privately, and am willing to tell the world, that Novell will never become the company it can and should become until it learns there's no such thing as a useful sacred cow. It's likely that Novell will never learn that lesson while headquarted in and recruiting from Provo, Utah. I'm sorry, it's a very nice place to visit and live, but the gene pool is only deep at one end in Utah - technology.
As anyone can attest, Novell's problem isn't - and has never been - technology. Novell's problem is the systematic construction of self-defeating business models and practices.
In one half of the house, you have people churning out the most amazingly insightful and useful technologies the IT industry has ever seen. In the other, you have people so hell bent on maintaining product release schedules and developing innovative sales incentive programs that they become a black-hole for great ideas.
I have proof. You may have forgotten their names, but I haven't. Remember Novell Portal Services? NetMail? DeFrame? Those are a few of my favorite casualties.
Were the technologies bad? No. Did something better come along? No, but sometimes something different came along.
So where did they go? Great question. The answer is simple - Novell couldn't figure out how to sell this stuff, or indeed what to do with it at all. Some products stepped on the toes of other products...in which case, no matter how good one was, the bigger one prevailed. Pretty smart.
It gets worse. Novell's strategy and direction - when somewhat more tangible than a box of mud, changes pretty frequently. This is confusing to partners, who need to follow if they are to provide support and feed off the customer base.
When the vendor is confused, the partners become confused. When those partners are confused, they do what any smart entity does. Evaluate risk and reward. Without enough customers crying for Novell support to outweigh that vendor's cost of continuing to provide it, vendors will drop it like a hot rock.
And drop it they have.
Try to find a single backup solution that supports NAS, SAN/FC, Near-line storage pools & tape libraries, AIX, Solaris, Windows, Linux, and NetWare 6.5 Clusters. Bakbone? SyncSort? Tivoli? Veritas? Try them - I dare you. TSM's documentation for NetWare 6.5 Clustering support was copied & pasted from the Microsoft documentation. SyncSort is in the backup software business exclusively, and they couldn't figure out how to get their stuff to work reliably in a lab!
But don't stop there. Try to find an enterprise monitoring & management console that runs on or integrates with NetWare, and will scale to monitor & alert on more than 55 devices. Try to find more than one vendor who provides IP telephony integration with GroupWise.
Try to find enterprise grade contact databases, CRM solutions, call center solutions, networkable-MFC machines, printer drivers, even business-card scanners that know about or directly support NetWare, eDirectory, or GroupWise.
Try to find a single web-based or Win32-based console to administer all the parts of your Novell infrastructure!
Novell doesn't even use it's own products in-house. NetWare/OES runs a scant portion of their enterprise. GroupWise is on the way out. ZFS hasn't been part of their monitoring solution for years - the IS&T NOC uses mostly home-grown or third-party software.
Got eDirectory, GroupWise, Oracle, Active Directory, Cisco IP Telephony with Unified Messaging, and want the Novell "Zero Day Start" solution? Get ready to hire a consultant to do some breadboard patchwork driver development...at least two of those components are totally foreign to Novell's IDM solution despite their significant market penetration.
Some of Novell's own products are incompatible or losely integrated with one another. How is that possible? Everything Microsoft writes is compatible with every other thing it writes! What gives? From my view, the problem is that Novell doesn't understand the most significant law of Human Nature (I think I wrote on this earlier). "People do what they are incented to do." And in Provo, people are not incented to help out their friends in other product groups.
To the contrary, they play their cards best when they avoid contact with other product groups alltogether. Financially and intellectually, they're in a battle against their fellow employees. They are fully incented to deliver the best individual product they can - even at the expense of their peers. To hell with integration or compatibility, to hell with ease of use, to hell with whomever is already working on a similar solution.
Instead of competing against a standard of greatness, they're competing against each other. The problem is, nobody is winning.
I once e-mailed Chris Stone, asking him to please read Good to Great. He replied, indicating that he had, and agreed with many of the ideas therein. I almost bought stock in Novell that day. I was convinced that Chris Stone could knock skulls in Provo, and get rid of the idiots who keep running great technologies and ideas into the ground because they don't know how to make money from them. Apparently, I was wrong about Chris (or I was right, and he just got tired of fighting).
So to top off the facts that their products don't often work well (or live well) with each other, and that vendors are running away from them faster than Edwin Moses, with the fact that their support model is based on information that can't be less than 15 years old. Product support and upgrade protection are sold separately, and in very finite quantities - the only self-proclaimed "enterprise software vendor" to have such an arrangement in my experience.
The short of it is that you - as a Novell customer in good standing - may have a significant problem with a Novell product and not be able to get support for it from a Novell technician. A pretty significant barrier to adoption if you're considering becoming a Novell customer, or considering renewing as such.
Now mix in a myopic sales & marketing organization who can't make any of this stuff relevant to anyone but a deeply technical IT Manager or group of Engineers, and you have a recipe for long-term atrophy & disaster.
Message to Novell - I don't care about your new patch utility, I have ZEN. You want to add value? Tell me about building an intranet with simple content management facilities, that fully integrates all the Novell products I've purchased, using a point-and-click GUI and requires no code (and if you mention exteNd I'm going to tear your arm off and beat you with it).
As easy as it would be to lose faith and jump ship, I won't. There's hope on the horizon. New blood being infused into the company is sick and tired of the stupidity, and they aren't going to take it anymore. NetWare is recognized as the abominable lopsided wheel it has become, and all eyes are on Linux to carry the torch. I'm willing to stick it out and see if life is better as a Linux shop than a NetWare shop. I don't imagine how it can be any worse, but I'm obviously not good at predicting the episodes in which Novell shoots itself in varying parts of the body.
I can say that it's remarkable how good or bad a company appears to the customer, based solely on the quality of the account executive. Fortunately, we seem to have been placed into the hands of a pretty good one recently. I hope for Novell's sake that ours is the first of a growing breed.
I need a drink. Wonder if I can get a vendor to buy me a Guiness...
Sunday, October 23, 2005
Oktoberfest in Tulsa
This certainly has nothing to do with IT Management, but it does deal with the other half of your waking life that needs attention.
The Tulsa Oktoberfest celebration is one of the top 10 in the country according to USA Today. That distinction is rightly earned. It's cheap to get in, it's huge, authentic yet diverse, and even with a 7-year-old in tow, it's quite a lot of fun.
If you find yourself with the hankering to drink great German beer (Spaten lager is quite good), eat sausages and gigantic desserts, and do the chicken dance every 10 minutes, you'll find a few thousand other like-minded individuals on top of the picnic tables under the big tent in Tulsa each year around this time. It's over far too quickly.
Oh well, back to the grindstone.
The Tulsa Oktoberfest celebration is one of the top 10 in the country according to USA Today. That distinction is rightly earned. It's cheap to get in, it's huge, authentic yet diverse, and even with a 7-year-old in tow, it's quite a lot of fun.
If you find yourself with the hankering to drink great German beer (Spaten lager is quite good), eat sausages and gigantic desserts, and do the chicken dance every 10 minutes, you'll find a few thousand other like-minded individuals on top of the picnic tables under the big tent in Tulsa each year around this time. It's over far too quickly.
Oh well, back to the grindstone.
Wednesday, October 12, 2005
The Great Java Lie
I'm certainly not the first person who has said that promise of Java in the enterprise was more of a dream than reality.
The oft-touted Sun cliche' "Write once, run anywhere" should be followed by an asterisk.
*Depending on the version of JVM on your customer's PC.
I'm not quite certain if the blame can be placed solely on one entity, but in my mind, most of the blame falls on Sun Microsystems - Scott McNealy and Eric Schmidt, specifically - for being either very dishonest or very inept.
What we in the enterprise are seeing is an increasing number of vendor websites that carry with them exacting requirements for the JVM they expect to be installed on local PC's. As it happens, most of the requirements are for fairly old versions of the JVM. In other instances, vendors require versions of Microsoft's JVM - not Sun's, even though Sun wrote the damn thing to begin with.
Want proof? FedEx's website will not print to a locally attached label printer without JVM v1.3.x. Two other insurance websites require varying versions of 1.3.x - not the same as FedEx, mind you - in order to process employee benefit claims. McGraw-Hill requires Microsoft JVM version 3805 to be installed on your Windows 2000 SP4 PC if you wish to access their Construction Dataline service.
These companies are unabashed in dictating technology requirements to me, their customer. They "wrote once"...So if you want to "run it anywhere", you're damn well going to use the JVM around which their code was written.
Somehow it's my fault - the customer - that my company uses more than one vendor for unrelated services, and that they can't figure out how to architect a website with simple old HTML and server-side code.
They were told to use Java - they were sold a lie, and they bought it whole hog. They were told, "People can use your web services at home, at work, on their phone, on their refrigerator, their TV, everywhere!" While that may not be false, it's certainly not completely true.
Let's face facts.
95% or more of all internet traffic originates from or is destined for a PC. Not a toaster. Not a phone. Not an E15000.
Just a simple, standard, utterly ubiquitous Personal Computer.
So the problem is, I can't manage more than one version of JVM on a PC to be used by the browser - any browser. Nor should I have to.
The reason this problem exists, in my opinion, is because Sun has been utterly incompetent. With regard to managing features and functionality as they expand and refine Java, backwards compatibility is a phrase they've never heard.
Vendors specify a version of client-side Java software to access their website, not because they like it more, but because it's the only one that works. Sun hung these companies out to dry, by making significant-enough alterations to the JVM that a developer's code no longer works.
Who is to blame? Tough to say. The code can't be that bad, it works with a certain JVM right? If it doesn't work with a later version, how is it the developer's fault? Even so, who am I (a single customer) to tell them get their act together? It's easier for me to install a different JVM than it is for them to completely rewrite their website.
I admit that I've considered the problem to be our fault...maybe the issue is a combination of factors under my control - Windows 2000 SP4 and a million patches, Internet Explorer 6 and all it's patches, Windows entropy, etc. Maybe we won't have this issue on our new Windows XP machines (although I have no idea why not - the vendors are specific in telling us what JVM we need).
I just know that I should be able to download the latest JVM, install it on my new PC's using a standard image, and anything developed in Java up to that point in time should work.
It doesn't though. And when it doesn't, it's not my fault...just my problem.
I really and truly feel sorry for Google. Eric Schmidt has a history of turning everything he touches into finely polished, almost gilded, pieces of crap.
Take Novell for instance.
Schmidt made Novell relevant again by making TCP/IP a native protocol in NetWare. Then, in one fell swoop, he set it marching off the cliff by forcing Novell's internal developers to use Java for new products. The result? Servers that crash more than ever. Separate pools of memory for Java that are nearly impossible to manage. Products that can't co-reside with one another on the flagship NetWare platform. Customers who have cried for and lacked a unified administration console for upwards of 7 years. The list goes on and on.
The apple doesn't fall too far from the tree, and the tree from which he fell and has lived his life is one that's hell-bent on ruining Microsoft. He's not interested in making things great, he's interested in being better than Microsoft (which, incidentally, any great organization could do handily).
That said, I'm smart enough to see Java for what it means - and I'm not a developer. Java applications need to relegated to the intranet. Keep it out of the DMZ. Keep it off my PC's. Let me decide when my company needs an application built on Java - not the other way around.
Do you hear me FedEx????
The oft-touted Sun cliche' "Write once, run anywhere" should be followed by an asterisk.
*Depending on the version of JVM on your customer's PC.
I'm not quite certain if the blame can be placed solely on one entity, but in my mind, most of the blame falls on Sun Microsystems - Scott McNealy and Eric Schmidt, specifically - for being either very dishonest or very inept.
What we in the enterprise are seeing is an increasing number of vendor websites that carry with them exacting requirements for the JVM they expect to be installed on local PC's. As it happens, most of the requirements are for fairly old versions of the JVM. In other instances, vendors require versions of Microsoft's JVM - not Sun's, even though Sun wrote the damn thing to begin with.
Want proof? FedEx's website will not print to a locally attached label printer without JVM v1.3.x. Two other insurance websites require varying versions of 1.3.x - not the same as FedEx, mind you - in order to process employee benefit claims. McGraw-Hill requires Microsoft JVM version 3805 to be installed on your Windows 2000 SP4 PC if you wish to access their Construction Dataline service.
These companies are unabashed in dictating technology requirements to me, their customer. They "wrote once"...So if you want to "run it anywhere", you're damn well going to use the JVM around which their code was written.
Somehow it's my fault - the customer - that my company uses more than one vendor for unrelated services, and that they can't figure out how to architect a website with simple old HTML and server-side code.
They were told to use Java - they were sold a lie, and they bought it whole hog. They were told, "People can use your web services at home, at work, on their phone, on their refrigerator, their TV, everywhere!" While that may not be false, it's certainly not completely true.
Let's face facts.
95% or more of all internet traffic originates from or is destined for a PC. Not a toaster. Not a phone. Not an E15000.
Just a simple, standard, utterly ubiquitous Personal Computer.
So the problem is, I can't manage more than one version of JVM on a PC to be used by the browser - any browser. Nor should I have to.
The reason this problem exists, in my opinion, is because Sun has been utterly incompetent. With regard to managing features and functionality as they expand and refine Java, backwards compatibility is a phrase they've never heard.
Vendors specify a version of client-side Java software to access their website, not because they like it more, but because it's the only one that works. Sun hung these companies out to dry, by making significant-enough alterations to the JVM that a developer's code no longer works.
Who is to blame? Tough to say. The code can't be that bad, it works with a certain JVM right? If it doesn't work with a later version, how is it the developer's fault? Even so, who am I (a single customer) to tell them get their act together? It's easier for me to install a different JVM than it is for them to completely rewrite their website.
I admit that I've considered the problem to be our fault...maybe the issue is a combination of factors under my control - Windows 2000 SP4 and a million patches, Internet Explorer 6 and all it's patches, Windows entropy, etc. Maybe we won't have this issue on our new Windows XP machines (although I have no idea why not - the vendors are specific in telling us what JVM we need).
I just know that I should be able to download the latest JVM, install it on my new PC's using a standard image, and anything developed in Java up to that point in time should work.
It doesn't though. And when it doesn't, it's not my fault...just my problem.
I really and truly feel sorry for Google. Eric Schmidt has a history of turning everything he touches into finely polished, almost gilded, pieces of crap.
Take Novell for instance.
Schmidt made Novell relevant again by making TCP/IP a native protocol in NetWare. Then, in one fell swoop, he set it marching off the cliff by forcing Novell's internal developers to use Java for new products. The result? Servers that crash more than ever. Separate pools of memory for Java that are nearly impossible to manage. Products that can't co-reside with one another on the flagship NetWare platform. Customers who have cried for and lacked a unified administration console for upwards of 7 years. The list goes on and on.
The apple doesn't fall too far from the tree, and the tree from which he fell and has lived his life is one that's hell-bent on ruining Microsoft. He's not interested in making things great, he's interested in being better than Microsoft (which, incidentally, any great organization could do handily).
That said, I'm smart enough to see Java for what it means - and I'm not a developer. Java applications need to relegated to the intranet. Keep it out of the DMZ. Keep it off my PC's. Let me decide when my company needs an application built on Java - not the other way around.
Do you hear me FedEx????
Friday, October 07, 2005
Centralized Shared File Access
One of the nagging requests we've received of late is from a certain group of users we have around the country. There are pockets of these users that use a vertical application, and since there's no database server, the files they work with are very large. Worse yet, the values in each file are derived from a central "knowledgebase" or "standard" - altering the standard affects the values in each file on which they're based.
This group has requested that we develop a centralized location for this standard, and further allow them to centrally share these files. Given their size, and the fractional-T1 frame relay links we have connecting locations, the request has not been feasible.
However, I've recently read of a technology that may have some applicability here. We use NetWare and Nterprise Branch Office, which does provide sync capabilities via RSYNC. RSYNC doesn't provide for an elegant solution, nor one that is capable of resolving write collisions. Furthermore, the 'solution' should be transparent to our end-user community - a consistent standard we set for ourselves when improving on or replacing technologies.
The iServer solution from Tacit Networks however, appears that it may largely solve the problem for us. It lacks eDirectory integration, but it very intelligently handles file synchronization and caching over WANs in an appliance footprint. It's caching and sync engines are very intelligently designed, and they advertise functionality & performance that are LAN-like over WAN links. This will be a product I continue to investigate and watch.
If it weren't for ComputerWorld, I might not know this company existed. If you can only subscribe to and read one industry publication on IT, ComputerWorld should probably be it.
This group has requested that we develop a centralized location for this standard, and further allow them to centrally share these files. Given their size, and the fractional-T1 frame relay links we have connecting locations, the request has not been feasible.
However, I've recently read of a technology that may have some applicability here. We use NetWare and Nterprise Branch Office, which does provide sync capabilities via RSYNC. RSYNC doesn't provide for an elegant solution, nor one that is capable of resolving write collisions. Furthermore, the 'solution' should be transparent to our end-user community - a consistent standard we set for ourselves when improving on or replacing technologies.
The iServer solution from Tacit Networks however, appears that it may largely solve the problem for us. It lacks eDirectory integration, but it very intelligently handles file synchronization and caching over WANs in an appliance footprint. It's caching and sync engines are very intelligently designed, and they advertise functionality & performance that are LAN-like over WAN links. This will be a product I continue to investigate and watch.
If it weren't for ComputerWorld, I might not know this company existed. If you can only subscribe to and read one industry publication on IT, ComputerWorld should probably be it.
Wednesday, October 05, 2005
Sweating the small stuff
Sometimes it's the tiny little things that keep big plans from becoming a reality.
We're trying to simplify and consolidate our eDirectory tree, and make our remote sites easier to manage. The product we've been piloting is Novell's Nterprise Branch Office (NBO or BOMA if you will) v2.0. It has so much potential, yet it falls short in small areas that are important - and would be easy for Novell to fix.
One issue we have, is that it's very difficult to manage PC's and application distribution at sites running NBO. This is because, despite the marketing hype, NBO doesn't actually "cache the corporate tree's eDirectory". It maintains it's own separate tree, and populates it with user and group information from the corporate eDirectory tree - nothing more.
What's worse, if you use PC's with the Novell client at NBO sites, it's even harder to get that PC connected to your corporate tree via ZENworks. (We eventually found an undocumented, unsupported method for doing this, and are testing it now).
The other big problem is that NBO doesn't handle password changes or password policices in the corporate tree very well at all. We should be able to change a password in the main eDirectory tree, and that change should be immediately recognized by NBO - that's not the way it happens. If someone changes it at the far site via NBO's "Virtual Office" portal, that change should make its way to eDirectory.
The reality is that not many users actually use password self service tools proactively- certainly not in our environment, or many that I've seen as a consultant. This means the HelpDesk does a lot of password resets reactively. They can either do this from their admin console, or by opening up a web session to each server where the problem may occur (sounds like the bindery in NetWare 3.x, doesn't it?).
eDirectory and NetWare 4.x were supposed to save us from this mess. You log into the network, not the server. It was a tough concept to grasp at first, but it makes a lot of sense. NBO breaks all of that, sending us back in time some 15 years.
So much for technology making our lives easier...
We're trying to simplify and consolidate our eDirectory tree, and make our remote sites easier to manage. The product we've been piloting is Novell's Nterprise Branch Office (NBO or BOMA if you will) v2.0. It has so much potential, yet it falls short in small areas that are important - and would be easy for Novell to fix.
One issue we have, is that it's very difficult to manage PC's and application distribution at sites running NBO. This is because, despite the marketing hype, NBO doesn't actually "cache the corporate tree's eDirectory". It maintains it's own separate tree, and populates it with user and group information from the corporate eDirectory tree - nothing more.
What's worse, if you use PC's with the Novell client at NBO sites, it's even harder to get that PC connected to your corporate tree via ZENworks. (We eventually found an undocumented, unsupported method for doing this, and are testing it now).
The other big problem is that NBO doesn't handle password changes or password policices in the corporate tree very well at all. We should be able to change a password in the main eDirectory tree, and that change should be immediately recognized by NBO - that's not the way it happens. If someone changes it at the far site via NBO's "Virtual Office" portal, that change should make its way to eDirectory.
The reality is that not many users actually use password self service tools proactively- certainly not in our environment, or many that I've seen as a consultant. This means the HelpDesk does a lot of password resets reactively. They can either do this from their admin console, or by opening up a web session to each server where the problem may occur (sounds like the bindery in NetWare 3.x, doesn't it?).
eDirectory and NetWare 4.x were supposed to save us from this mess. You log into the network, not the server. It was a tough concept to grasp at first, but it makes a lot of sense. NBO breaks all of that, sending us back in time some 15 years.
So much for technology making our lives easier...
Subscribe to:
Posts (Atom)