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.
Monday, October 31, 2005
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...
Sunday, October 02, 2005
Follow-up - Certifiable
In the September 26th Computerworld magazine, Virginia Robbins wrote an article that essentially mirrors my position on employers who require certifications or degrees before they'll consider someone for employment.
In her article, she says:
The point, as she succinctly puts it - "I've found no correlation between degree and competency" - is that the pieces of paper by themselves aren't important.
In fact, by themselves, they're not even relevant.
I'm fairly confident she believes as I do, that attitude and aptitude are the most meaningful factors in evaluating candidates. This is encouraging, because she's the CIO and Managing Director at Chela Education Financing in San Francisco, and we share an important belief for managers & executives who endeavor to build great organizations.
Certainly its easier for hiring managers to look for nice certifications, and nobody gets fired for hiring MBA's or MCSE's, but how often does taking the easy road lead to the best possible outcome?
Personally, I view companies that require degrees or certifications of their employees as types of bigots. They're effectively pre-judging candidates before they've met them, based on superficial and demonstrably irrelevant standards. (Ever met a "paper-CNE" or "paper-MCSE"? I have.)
I don't think they need to be tried in a court of law, but I do think they need to be called to the mat for this practice - publicly - and that self-respecting technology professionals should avoid them like the plague.
If you're on the wrong side of this fence (be honest with yourself) - keep in mind that people like me could work wonders for your company; and we won't come near you until you wake up and realize that talented people don't come with easy to read labels...You actually have to talk to us.
In her article, she says:
"I have found not only that a computer science degree is optional, but also
that many successful technologists don't have any degree at all. I've had great
employees who never finished college, and I've had wonderful employees who have multiple master's degrees."
The point, as she succinctly puts it - "I've found no correlation between degree and competency" - is that the pieces of paper by themselves aren't important.
In fact, by themselves, they're not even relevant.
I'm fairly confident she believes as I do, that attitude and aptitude are the most meaningful factors in evaluating candidates. This is encouraging, because she's the CIO and Managing Director at Chela Education Financing in San Francisco, and we share an important belief for managers & executives who endeavor to build great organizations.
Certainly its easier for hiring managers to look for nice certifications, and nobody gets fired for hiring MBA's or MCSE's, but how often does taking the easy road lead to the best possible outcome?
Personally, I view companies that require degrees or certifications of their employees as types of bigots. They're effectively pre-judging candidates before they've met them, based on superficial and demonstrably irrelevant standards. (Ever met a "paper-CNE" or "paper-MCSE"? I have.)
I don't think they need to be tried in a court of law, but I do think they need to be called to the mat for this practice - publicly - and that self-respecting technology professionals should avoid them like the plague.
If you're on the wrong side of this fence (be honest with yourself) - keep in mind that people like me could work wonders for your company; and we won't come near you until you wake up and realize that talented people don't come with easy to read labels...You actually have to talk to us.
Subscribe to:
Posts (Atom)