* How will that new feature, application affect the rest of your system?
If you are an end user, why cares about software architecture? After all, if a piece of software works, why be concerned with how it was put together?
It’s a good bet that most IT shops, if asked to catalog their top ten pain points, would put handling e-mail somewhere towards the top of the list. The reasons for this are known to all: more people send more e-mail every day, e-mail is invariably a key part of most companies’ business practices, regulatory controls are piling up, attachments are growing larger, Exchange seems to get slower with each release, yada yada yada. Everybody knows the symptoms, everybody knows the causes and, when it’s budget time, everyone sees the results.
E-mail offers us a good common reference point when it comes to discussing architecture, not because we can change the way Exchange (or Notes) itself is constructed but because, in this not-so-brave new world of regulations, compliance and continuous data protection (CDP), we at least have some flexibility in the way we connect the “after-market” modules we buy. Unless your e-mail is handled through a service provider, in which case the problem shifts to the provider, how things work together should be of interest.
There are almost as many after market products for e-mail as there are for a ’57 Chevy. We have security, contact manager and antispam plug-ins; add-ons that manage mailing lists, provide virus protection, and some that turn e-mail addresses into HTML links. There are also after-market programs offering CDP, regulatory compliance, and for all I know, cures for insomnia, hemorrhoids and the national debt.
Before you add a solution for any of these, consider the specific problem each solves and consider that problem within the context of the overall e-mail system. Is your problem limited to list servers? Is it a combo of unreliable system recovery and generally poor overall system performance? Is it a mix of three or four problems, any one of which could prove to be a showstopper?
In most cases, e-mail admins list multiple grievances concerning the product they use. Why then, do they often fix one problem at the expense of exacerbating another?
Take, for instance, a common complaint about Exchange Server 2003 – it runs slower than its predecessor. If that is the case, why add a CDP product or a security product that must be run on the same server, or that in some other way sucks cycles from the e-mail server? You may fix your security issue, but at what expense to the rest of the system? By adding additional load to an already over-taxed CPU, you may well be degrading the overall value of the entire e-mail system.
Many competitive products do the same thing, and in some cases, they all do that thing relatively well – but how they interact with the rest of the components within the system may be vastly different. When adding new products, remember the system within which they will be functioning, and put the squeeze on the vendors to show you what the overall system impact will be.
