Blog Host: Andrew Pollack - president, Northern Collaborative Technologies READ ENTIRE BIO

• The New Deal
• Some meaning to that tired, useless mantra "It's standards-based"

If you've got more questions, please e-mail me, send me an AIM or drop by my personal blog any time.

If you think I did a really exceptionally great job, send a note to Dana McCurley (the editor of the Expert Answer Center) and tell her to offer me a few million skins a year to write a column every once in a while. ;-) -- actually, just tell her thanks.

Best of luck with all your messaging plans.

"This way to the great Egress!"
-- P.T. Barnum
Posted by Andrew Pollack When to stop leveraging your products
23 SEP 2004 06:00 EDT (10:00, GMT)
Microsoft does it with abandon -- virtually everything is leveraged. It doesn't care what you fall in love with, it will drive you to update everything else. There's a downside, though. Sometimes if you over-leverage one product, you can kill the chances for a new one. I sent my outline of the meeting with the IBM people on Monday to them to review so I know what is strictly non-disclosure and what I can talk about (easier to do that than try to track it in the meeting), and I'm still waiting to hear -- but one key observation I can make is entirely mine (and this not subject to being crossed out) is that their new Rich Client is going to be a winner no matter what. I'm not convinced yet about the backend server it was built to talk with, though. It may; it may not. Things look good, but by no means does that make a market. The client side, though, will work regardless. It makes a great client to existing technology, to the new technology and to lots of other technologies. The catch is, if the marketing message ties the new client totally to the new server through name choice or branding or whatever, it could be hanging a weight around the client's neck. Nobody who isn't interested in the server will want to look at the new client. Are you following all this? Both MAY be great. I know one is. I want to see them clearly marketed as independent choices. We'll have to see what happens.

If I get the go ahead by Thursday, I'll post some thoughts here, otherwise, the next expert will take over, and if you want to find my thoughts, you'll have to go looking at my personal blog. It's been fun so far -- two more days to get me your great questions on enterprise messaging -- or anything else for that matter.

If you have suggestions for me to ramble on about for my last day, Friday, drop me an e-mail!

Thanks for reading!
Posted by Andrew Pollack Start reconsidering your mail file
22 SEP 2004 06:00 EDT (10:00, GMT)
Do you manage your mail file? You used to be able to get away with just "read" or "unread." Then you moved to folders. Folders are great for stuff that's already been dealt with, but not for ongoing stuff. Many of us manage our inbox. That is, we work toward a goal of nothing in the inbox, but nothing can be removed from the inbox until it has been handled. That's been a good strategy until recently for me. These days, I have two big problems with it. First, I'm on too many different projects at once. That means the inbox grows by multiple screens each day. Second, the document I'm saving to take action on gets superseded every 10 minutes because someone added a comment and copied everyone back. That means I'm spending too many cycles on inbox maintenance.

You need to start thinking about your own inbox. I'm giving a presentation called "The new face of messaging is just around the corner" in London in a couple of weeks at the Admin and Developers Conference. One of the things I hope to talk a lot about is how to start using some backend tools to classify information before it gets presented to you.

Lotus Notes, for example, gives me the ability to run all kinds of "agents" against the mail before I even see it. I'm working on something now that actually has the server dump my mail to what it considers my mailbox, but then has my Notes client pointing somewhere entirely different for mail. Background tools will use the inherent "threading" capability in Notes to take the new messages and "fit them in" to the conversation so that I can manage "the thread" as something to do, rather than managing a specific document -- one part of that thread. My goal is that rather than starting with a full mailbox and filtering "out" what I don't need to pay attention to, I am instead filtering "in" from a bucket I pay less attention to up the chain to my attention based on criteria.

What are you doing to manage those 150+ messages a day? Let me know.
Posted by Andrew Pollack What do you want from your cell phone?
21 SEP 2004 06:00 EDT (10:00, GMT)

Figure 1              Figure 2

In early 2001 I bought a Kyocera 6035 (Figure 1) and I've used it as a Palm Pilot, a phone and a POP3 client since. New phones promise to be camera, television, organizer, music maker, and, oh yeah -- telephone. What do you want out of yours? I want one the size of pager that's a good POP3 client, a tri-mode (go-anywhere) phone, and that can take an occasional bounce off the concrete. They can hold off on the hard drive, the television, the MP3 player, the camera and all the other nonsense. Phones with too many things in them, bring us back to Figure 2.

Well, today should be interesting. About the time this blog entry is due, I will be in Westford, MA at the offices formerly known as Iris Development looking at the latest and greatest and trying to negotiate enough leeway on the NDA to make a good presentation. Wish me luck.
Posted by Andrew Pollack What is enterprise messaging?
20 SEP 2004 05:30 EDT (09:30, GMT)
I've been seeing questions here for about week now, and one thing I've noticed is that I'm seeing a very ground-level "tactical" view of enterprise messaging. Most of the serious questions that touch on larger corporate issues are around e-mail -- and those deal with scale or interoperability of present systems.

Messaging at the enterprise level goes beyond that. Think about messaging as all the asynchronous interactivity between and among systems and people. An application on the mainframe sends a notification to a reporting system -- that's messaging. A batch process gets triggered by an employee termination in an HR system -- that's messaging.

Preparing a messaging strategy goes beyond choosing between IBM Lotus Domino and Microsoft Exchange. Users are increasingly using instant messaging; some companies are planning and capturing data around that, while others are letting that happen organically with publicly available tools.

Cell phones are increasingly being called on to be part of the messaging infrastructure. Sometimes they do this with IM clients, sometimes just as text messaging notification devices.

I know one company who has created instant messaging "bots" that monitor situations and log in to the IM system only in the event of an issue. An example may be a "bot tied" to the inventory status. If the process spots inventory levels outside norms, it logs in to the IM system and waits. When they get off planes, executives look at their wireless devices and see that "Inventory Alert" is logged in. Simply by seeing it signed on, they know there is something unusual going on. They may open a "Chat" with the bot. Sending a comment like "status" will generate a response from the process, which will create a brief report on what caused the bot to log in. Suppose you have a number of these kinds of process monitors -- you end up with a very quick snapshot of company status without doing anything more than looking at your mobile device.

So what are you doing? Let me know.
Posted by Andrew Pollack Notification communities
17 SEP 2004 06:00 EDT (10:00, GMT)
Well, folks, another day another project. This week I've set up a pager notification system for my local fire department on my Domino server. You see, we're all having to carry the same pagers, which is nuts. Who needs a pager anymore? Your cell phone can do that job. Problem was, there was no easy way to handle all-page situations or pages to groups unless we set up e-mail groups -- and that's really tricky. Until now, we've had to stick with one vendor and use their software -- locked into their pagers.

The new system lets everyone have their own profile, and list as many devices as they like, each with its own notification number. Help is provided, users put in their mobile phone numbers and provider names, and the system knows how to route 99% of them already. Users then use "rules" to configure which kind of pages they want, during what hours and sent by whom.

Result? Most of us will turn in our pagers and use our cell phones without worrying about which user has what provider. That's going to save lots of money overall. On top of that, we can review a log of messages sent.

Of course, this will never replace our emergency dispatching system with radio pagers called "Minitors" by Motorola for emergencies, but for non-emergencies, text messaging has a broader range and some other benefits.
Posted by Andrew Pollack Notification communities
17 SEP 2004 06:00 EDT (10:00, GMT)
Well, folks, another day another project. This week I've set up a pager notification system for my local fire department on my Domino server. You see, we're all having to carry the same pagers, which is nuts. Who needs a pager anymore? Your cell phone can do that job. Problem was, there was no easy way to handle all-page situations or pages to groups unless we set up e-mail groups -- and that's really tricky. Until now, we've had to stick with one vendor and use their software -- locked into their pagers.

The new system lets everyone have their own profile, and list as many devices as they like, each with its own notification number. Help is provided, users put in their mobile phone numbers and provider names, and the system knows how to route 99% of them already. Users then use "rules" to configure which kind of pages they want, during what hours and sent by whom.

Result? Most of us will turn in our pagers and use our cell phones without worrying about which user has what provider. That's going to save lots of money overall. On top of that, we can review a log of messages sent.

Of course, this will never replace our emergency dispatching system with radio pagers called "Minitors" by Motorola for emergencies, but for non-emergencies, text messaging has a broader range and some other benefits.
Posted by Andrew Pollack What about antispam?
16 SEP 2004 06:00 EDT (10:00, GMT)
So far, I haven't had any questions at all about antispam measures. That surprises me a great deal. Unsolicited and unwanted e-mail is, according to some, now above 80% of the SMTP traffic on the Net. I started with a commercial product and have rolled my own additions to it -- now I'm processing about 75% based on my own code.

I've had the same e-mail address for more than 10 years now, and some days I get more than 400 unwanted mails a day. Fortunately, good antispam software can take care of most of them. You have to be careful though -- the false positives will really anger the user base. The trick, I've found, is to quit trying to detect all the tricks and word variants and focus on the things that cost spammers money.

A spammer can send a million messages out at virtually no cost. What I've seen is that they tend to send the same spam several different ways. Each send method is designed to get past one form of filtering or another. To stop the Bayesian filters, they include a copy of some random article from the Net. To stop the word filters, they encode and encrypt and misspell. To stop domain name filters, they falsify the headers. For every message your filter lets through, I'll bet it's already stopped a dozen just like it, just sent differently, in a way your filter finds easy to catch.

The code I've been working on -- and I know I'm not unique in this -- works by finding the one thing spammers have the hardest time messing with. The "call to action" -- the link you click on -- has to work. It has to be readable and thus conform to some basic standards of format, and it has to take you somewhere valid. On top of that, registering a domain costs money, even if just a little. If you strip off the higher-level zone information and get down to the first significant name (domainname.com or domainname.co.uk, for example) you have something of value. Hash that -- and run your Bayesian algorithms against it, and you can catch a HUGE percentage of spam.

By itself, that's useless. Combine it, though, with another tool or method that catches the easy stuff (it says it's from aol.com but the server connecting doesn't have one of AOL's published addresses for sending mail, or the server is in a known spam blackhole list) and then scan the known caught mail as it comes in to update your Bayesian hash on the fly -- now you have something. You've got a "heuristic" (learning) process that learns to catch the new kinds of spam shortly after they start bombarding your server. The more spam you get, the faster your tool adapts. Start sharing those hash lists, and things get interesting.

What do you think? E-mail me or hit me on IM at AndrewJayPollack.
Posted by Andrew Pollack Where does instant messaging fit into your company?
15 SEP 2004 06:00 EDT (10:00, GMT)
I've seen instant messaging grow from a cute trick to business critical application for some companies. How about yours? Are you satisfied with a haphazard approach to IM that has users signing up for public services and using whatever names they like? Or do you have an enterprise server of your own and log every session?

Some recent court decisions are requiring logging and archive for this data and the third-party market is responding. Some companies block the services at the firewall and feel it's a waste of time.

My experience with it early on when I was supervising a development team in another office was that the young developers were more likely to contact me on it, even if just to ask if I had a minute to discuss their issue. This kind of interaction lead to big-time savings and knowledge transfer.

I've also seen the "dark side" -- endless wasted hours. IM, like e-mail, has become both insufferable and indispensable to me. What about you? IM me at AndrewJayPollack or drop me mail.
Posted by Andrew Pollack The new desktop and messaging war...
14 SEP 2004 06:00 EDT (10:00, GMT)
The corporate mail client wars are all but meaningless right now, but that's about to change. There's a new desktop battle brewing and messaging is one of its big battlegrounds. Are you ready to pick sides yet?

For now, most corporations are running either Exchange or Domino for their mail servers. There are others, but the overwhelming bulk of the market is split by these two giants.

Microsoft's advantages in terms of their tightly leveraged integration between their directory structure, operating system and user interface, as well as an excellent understanding of how users like to see things, has let them keep around half of the market despite a never-ending barrage of security problems and an incredibly high cost of upgrade from one major version to the next. That upgrade cost came because of the very integration they want; you get customers to upgrade everything at once -- operating system, directory schema and mail system. They fell down this time, though. They had everything bet on the new database capabilities promised in their SQL Server product. It was to be the root of everything from directory to file storage to e-mail. Not only will it be delayed, but now it looks like it could be another year or more before any sign of it hits the market. Their entire strategy has had to be delayed and instead they're going to release small bits -- hopefully (from their perspective) just enough to get you to keep upgrading.

It's a good thing for IBM, though, that Microsoft has stumbled so badly for so long and so often as it works to create enterprise-class products. If they could be as successful at the enterprise as they are at the desktop, IBM's recent difficulties would have lost them massive market share. IBM spent nearly two years with (in my opinion) a very poorly defined strategy for their own next steps in enterprise messaging; it has only in the last six to eight months been able to produce a vision that makes sense and get that vision out to its resellers and business partners.

In short, the market is mostly stable because there has been no real reason for it to move in either direction for a really long time. Some customers on both sides get fed up and switch. It's easy to go from Microsoft Exchange to IBM Lotus Domino because Domino provides a superset of the services that Exchange does. This tends to act as a counterweight to Microsoft's more successful marketing machine and keeps things pretty much status quo. So much so that at any given time you can find reports claiming each to be the market leader -- and at least one research firm that writes it both ways.

So, what's changed? Well, open source has changed everything.

For Microsoft, the threat of a really usable and manageable PC hardware-based machine for users built on Linux gets closer and closer and has pushed Microsoft to innovate or lose market dominance. Their response appears to be their Sharepoint Portal -- at its heart, the idea is to continue to increase the power and complexity of the local workstation while promoting secure sharing and collaboration around the "document" through Office and shared through personally managed spaces, or "portals." To be successful, they have to produce a compelling solution that users just intuitively understand, but with enough underlying complexity that it can't be quickly duplicated by the open source community.

For IBM, it is the need to integrate their platforms and begin to promote crossover from one product line to the others. They're sitting on a wildly successful mail and collaboration platform that, from their perspective, is doing nothing to promote the purchase of their other products. At the same time, visions of the Web browser replacing the terminal have failed to be cost-effective and easy enough to produce to make their long-term core customer base happy. They have their Websphere Application Server, which is great for transaction processing, but most apps aren't about transaction processing, and even those that are do the bulk of their work just handling menus and options or displaying pictures and text.

Their next step -- finally starting to see some daylight and rational sense -- is called Workplace. Workplace starts with their J2EE application server (Websphere) and adds the idea of "portlets" -- mini applications that have some functionality tied usually to some user interface definition -- and wraps them together with communication and message infrastructures with XML definitions and turns them into applications. Workplace does two big things for IBM. First, it provides a componentized approach to application building, and, in the long term, maybe a direction for their Lotus Domino customers to move toward their other architectures. Second, through their soon-to-be-released Rich Client (based in Eclipse), they may finally have a platform to create those classic applications that need a good enough user interface to give to a line worker enough performance to handle live processing, enough security to do transactions and enough componentization to let their consultants quickly make changes for their customers. In short, they can finally treat those 3270 terminal customers better. It's enough better than a browser interface that Seibel, SAP, Oracle and PeopleSoft need to be worried about the awakening giant.

In mail though, what does IBM Workplace mean? Well, it provides a way for some of those big companies to reduce and simplify desktop PCs enough to centrally manage them. Workplace provisions the application's modules and manages versions in a centralized way. If they can produce the tool in a way that users are happy with, they'll have saved their customers billions of dollars in management costs associated with huge, powerful, local desktop computers. To get there, they need to make a mail client (today's critical application) that passes the look and feel test. Stay tuned, we're all waiting to see it.

So, which do you want? Which do your users want? Is the answer the same in both cases? Will you use big, powerful, pretty and expensive to manage PCs at the desktops? Or will you have generic, centrally provisioned, easily managed workstations that let users worry about doing their job, not managing their PC?

Let me know what you think.
Posted by Andrew Pollack My turn -- but don't worry, I'm used to being in the hot seat!
13 SEP 2004 05:00 EDT (09:00, GMT)
Welcome to my little stint here in the Expert Answer Center. I've been given this soapbox to talk a little bit about "Enterprise messaging management" and to answer as many questions on that topic as I can. I've been given a few of the questions that were submitted in advance, so we can prime the pump a bit; and I've tried to be more than a little complete in answering them. I can't say I'll be able to give every question that much time, but if we work together maybe everyone reading can learn something -- including me.

What I hope to do each day through this blog is toss out my own current thinking on where we are, where we've been, where we're going and where we should be going in terms of providing our users a functional set of tools for messaging without making their lives more burdensome with bizarre interfaces and annoying gimmickry. I'll also toss out some personal anecdotes from the daily life of one of the world's very few consultant/alpha geek/firefighters. Believe me, if you got all of us together in a convention, you would not need to host it at the Walt Disney World Swan resort to find enough space. I'm fairly sure the back room at Red Roof Inn would suffice.

Most of all, I want to get past just the boring tactical stuff and talk strategy and direction a bit with you. My clients pay me to think way, way outside the box. They want me to look at the reasons why things are they way they are and question just how much of that is just inertia. I hope we can push some of those boundaries here, as well.

I should warn you all here and now that I am an unabashed fan of the IBM Lotus Domino mail environment. I'll try to take a balanced approach to my responses here, but it's only fair that you know from whence I come.

I have something like 15 years experience in the IT industry, and my interest in it was entirely sparked even earlier by messaging. I still remember seeing my first "bulletin board" at a friend's house back in the '80s. What struck me immediately was that here were dozens of people who otherwise would never have met, having intelligent discussions about every topic imaginable (and frankly a few I had not, at that age, done a whole lot of imagining on). Something about that early collaboration really grabbed hold of me, and it has stayed with me. It drives my thinking about technology even today. The first programs I wrote were to transfer mail on "fidonet" systems (Anyone out there remember Zapper, the first zone-aware replacement for OMMM?) and my first decent paychecks were made building beige-box clones before the likes of Michael Dell were so successful turning them into staplers.

The messaging industry, and IMO the entire desktop computing technology industry, has been in a bit of a lull the last couple of years, and as a result a lot of our tools are feeling tired and growing more and more susceptible to their inherent weaknesses. The crazy '90s' tech bubble made religious icons out of poorly thought out standards and put too much industry power in the hands of a bunch of kids fresh out of college who wouldn't have known long-range thinking if it jumped from a time capsule and bit them. Let's face it -- most of the standards that have made it are from BEFORE the standards wars of the '90s. IPv4, ZIP, SMTP, DNS, FTP, HTTP, POP3, GIF and JPG -- I could go on. Now think about the standards that came AFTER every sales guy in the country decided that "The Internet" was the same thing as "Web Pages" and for a while anything cool had to have some kind of coffee reference. With some notable exceptions, very little really new has happened since. Sure, it's gotten better, faster, prettier, safer and at the same time more dangerous, but overall it's just been variations on a theme. The now ubiquitous "Web Browser" is still a really crummy place to do any real work, and messaging has gone from generally useful to an indispensable, but at the same time incredibly onerous, form of meeting. I call it the "meeting you can't afford to miss."

That's all about to change. We live in interesting times as it is -- the messaging market is in for a whole new series of paradigm wars. This week I'm going to try to lay out the players and their strategies for you. I also want to talk about strategies for blocking spam, as I've had a good deal of success writing code for myself in that space through the use of heuristic methods that use the spam they know about to catch the spam they don't; just like we do, only with reaction time in minutes or hours instead of days or weeks.

I'll also be talking about fun things. I'm coaching two of my three daughters in soccer this year (our readers in Europe know this sport as football, and probably would laugh at our skills), and we're doing very well. I'm also finishing RIT training at my local volunteer fire department. That means I'm moving up a bit from being a firefighter to also being on the "Rapid Intervention Team" to rescue downed firefighters. That leads to some good stories, as you can imagine.

So let's start those questions up! You're welcome to post the ones you're willing to share, e-mail me those you prefer not to or check out my personal blog if you want to learn more about me.
Posted by Andrew Pollack