<![CDATA[Blogs]]> <![CDATA[What to Do with PST Files]]> In last week’s blog, we learned that Netmail PST Radar allows you to scan all the workstations in your network to locate PST files. The great thing about Netmail PST Radar is that you can scan the workstations from a central location (for instance, the System Administrator’s workstation), and the scan can even be performed while Outlook is running. Netmail PST Radar’s Scan and Detect job lets you know how many PST files exist on your network and where they are located. This is the first step in combating the problem of PST files (the problem: they are not centralized).

You might be wondering, “After locating my PST files, what should I do with them?” There are a few key actions that can be performed on PST files to improve the efficiency of your network and to ensure that your email system is compliant with regulations and internal audits.

1 – Centralize your PST files.

We already determined that the major problem with PST files is that they are not centralized. After locating your PST files, it would be a great idea to centralize them. For instance, you could move the files to a lower-cost server, meanwhile maintaining the path for the Outlook user (to avoid end-user confusion / upset).

(Note: Netmail PST Radar allows you to do this through the Move and Update job.)

2 - Archive your PST files.

By archiving your PST files, you know that the important information contained in them is saved and accessible to you if you need it. You might need this information because someone outside the organization has requested it (for instance, due to an Open Records request or a lawsuit eDiscovery request), or an internal need for the information might arise (for instance, HR might demand the information or it might be needed to defend against a lawsuit).

The other advantage of archiving your PST files is that after the files are archived, you can move them off your desktops and live email server, thereby freeing up storage space and saving you money.

3 – Monitor your PST files.

If you choose to archive your PST files, you can subsequently delete the existing PST files and disallow users from creating new PST files. This stops future PST problems before they start. However, your organization might want to continue allowing end users to create PST files, in which case, you will want to monitor the PST files. The most important thing to monitor is the size of the PST files --- we don’t want the size of the PST files to become a mystery again!

4 – Backup / Restore your PST files.

If you choose to allow PST files to be created on your network, you should institute safeguards for ensuring that your PST data does not get lost. For instance, if an end user’s laptop gets stolen, you want to be sure that the PST files have already been backed up to a central location so that they can be restored to the end user’s workstation.

Using a PST management solution that allows “incremental backup” will save you a lot of time. Incremental backup means that the entire body of PST files is backed up once, but in subsequent backups, you can choose to have only new / modified PSTs backed up. This feature essentially saves you from doing work twice.

5 – Compress your PST files.

To improve storage efficiency, it can be useful to compress your PST files. This procedure will save storage space and therefore save money.

Netmail PST Radar allows you to easily perform all of these actions (and more!) on your PST files. Click here to learn more about Netmail PST Radar.

Thanks for tuning into our blog series on the PST Problem. As always, please do not hesitate to contact us with any questions.

]]>
Wed, 20 Jul 2011 00:00:00 GMT c5a69dad-c62f-4af8-8412-3abf2e8c5ed0
<![CDATA[A Solution for the PST Problem]]> In last week’s blog, I examined the problem with PSTs: they are not centralized, which translates into headaches for the IT department, inefficient use of storage, and the potential for data loss / non-compliance.

Now that the problem is clear, the solution is clear: we need to find and centralize the PST files that are scattered across the corporate network. By doing so, we will…

  • Rid the IT department of their PST headache = save IT time = save money!
  • Improve / reduce network storage requirements = save money!
  • Reduce the risk of non-compliance = guard against potential legal proceedings and fines, save money on eDiscovery costs, and generally sleep well at night (just like last week’s well-intentioned end user) ;)

You might be thinking, “Great idea, but this is a daunting task. Finding and centralizing PST files is a lot of work!”

Actually, finding and centralizing your PST files is easy with Netmail PST Radar.

The first, and very useful, function that we can perform with Netmail PST Radar is the Scan and Detect job. This job allows you to scan the workstations in your network to locate PST files. You can scan for PSTs from one single location (for instance, the IT manager’s workstation), even if Outlook is running on end-user workstations.

By using the Scan and Detect job, PSTs are no longer a mystery: you know the location and size of all the PSTs on your network.

Next week, we’ll cover the actions you might want to perform on your PST files now that you have located them. Be sure to tune in for Part Three of my three-part series on PST files.

Don’t forget to watch our Netmail PST Radar Scan and Detect demo on YouTube!

]]>
Tue, 12 Jul 2011 00:00:00 GMT d76997e5-b43b-4bf5-99cb-190a5d523d8c
<![CDATA[The Problem with PSTs]]> You probably know that Messaging Architects offers Netmail PST Radar, a PST management tool designed to solve the PST problem. But you may be asking yourself, "Why are PSTs such a big problem?"

 

First, let’s review the basics of PSTs. PST, an abbreviation for Personal Storage Table, is a file type used in Microsoft software including Exchange; the file extension is .pst. To store important information received via email, an Exchange end user can save an email record as a PST file. The end user has good intentions: he sleeps well at night knowing his essential data is safely retained in PST format. Also, space gets freed up in his mailbox (because the PST file gets removed from his mailbox quota). The end user is well-intentioned, but what looks like a solution to the end user is actually a big problem for the IT department!

Firstly, while the size of the end user’s mailbox decreases when a record is saved as a PST, the organization’s overall storage demands do not decrease. The PST file is still stored somewhere on the network. (The operative word is somewhere --- we’ll get back to this in a minute.) Sure, an end user might eventually delete the PST file or remove it from the network on a flash drive, thereby freeing up storage space, but this demonstrates the second big problem with PST files: the use of PST files can lead to loss of data from the email system, which can result in fines, sanctions, lost time and productivity, and more.

Ultimately, the problem with PST files is that they are not centralized. They are somewhere on the network, but where? They contain important data, but how do we find the data? They take up storage space, but how much? And how much is that storage costing?

In today’s world, it is necessary for an organization to archive its email system. To be successful, email archiving must be a planned and policy-based initiative that includes correcting the PST problem.

Tune in next week for Part Two of my three-part series on PST files. Now that we understand the PST problem, we’ll delve into ways to correct the problem.

Don’t forget to watch our brand-new "Netmail PST Radar Overview" on YouTube!

 

]]>
Mon, 04 Jul 2011 00:00:00 GMT d2d8ab8c-7f1a-4806-a197-8b0fb931f833
<![CDATA[Are You Afraid of FIPPA?]]> For Healthcare organizations in Ontario, a big deadline looms: as of January 1, 2012, the Freedom of Information and Protection of Privacy Act (FIPPA) will apply to hospitals.

Perhaps the scariest thing about FIPPA is the wide scope that it covers. To make it less scary, let’s examine how FIPPA applies to email.

FIPPA is intended to solve two issues protection of privacy and access to information. Accordingly, the act requires that hospitals using email must:

(1)    …safeguard confidential information that is sent by email. For instance, confidential patient records must be transmitted using methods that ensure privacy.

(2)    …make email records accessible in the event of a FIPPA-sanctioned Open Records request.

Designing an email policy is critical in becoming FIPPA compliant. Policy-based software is the next step; proper software ensures that policies are being followed by end users and assists in the event of a FIPPA request for information. Proper software can also defend against FIPPA sanctions by demonstrating how the hospital has indeed adopted and enforced a FIPPA policy.

For more information about FIPPA, read our new whitepaper.

 

]]>
Tue, 17 May 2011 00:00:00 GMT 614b870c-8a92-4259-bcc3-863ed2ae09aa
<![CDATA[Beware of Spear Phishing Attacks]]> It’s official: data stolen in the Epsilon breach is being used for spear phishing attacks.

Chase Bank customers, beware of a phishing email that is circulating. The email warns that there may have been fraudulent activity on your account, and you must click a link to verify the account activity. Otherwise, your account will be frozen.

Don’t click the link.

The link will not bring you to Chase Online; it will bring you somewhere other than Chase Online.

As you can see in the above sentence, it is easy to make a fake link look legitimate within the text of an email; though, in my example, you were brought to a site that is clearly not Chase Online and is a harmless (and super cool) site. << Insert Netmail Community plug here Netmail Community, Join the Conversation! >>

I'm sure you've heard the advice already, but here’s some highlights of how to beat a phishing attack:

-   Don’t click a link in a received email (unless you are absolutely certain the email is legitimate and the link is harmless). When in doubt, manually type the web address you would like to visit rather than clicking a link.

-   Don’t transmit personal information in response to email. Receiving an email from a bank about fraudulent activity can make us panic and want to rectify the matter ASAP. Scammers rely on this panic to trick us. Remember that if your bank needs to reach you with important information, they will not use email as their method of contact.

-   If you use the internet for banking, payments, etc., always double-check that the website you are using is secure (look for an "s" after the http).

-   Be alert when reading links and email addresses. Scammers rely on our busy brains to gloss over fishy (phishy?) links and addresses. Here’s a crash course on reading links.

-   Look for red flags in the emails you receive, such as grammatical errors or weird syntax — these are clues that an email is fraudulent.

-   Report suspicious emails to the proper authorities. Epsilon provides the following information on the "Consumer Information on Phishing" page of their website:

Forward phishing emails to spam@uce.gov – and to the legitimate company that is being misrepresented in the phishing email. You also may report phishing email to reportphishing@antiphishing.org. The Anti-Phishing Working Group, a consortium of ISPs, security vendors, financial institutions and law enforcement agencies, uses these reports to fight phishing.

If you've been scammed, visit the Federal Trade Commission's Identity Theft website at ftc.gov/idtheft and file a report with the Federal Trade Commission at www.ftc.gov/complaint.

Of course, effective security software is also critical in defending ourselves against spear phishing.

]]>
Tue, 26 Apr 2011 00:00:00 GMT 71bf35b8-e046-4867-b231-fede27d0a53d
<![CDATA[Should You Migrate to the Cloud?]]> The following question was recently posted on our community site (Netmail Community):

Although migrating your email system to the cloud may show significant cost reduction in the short term, do you believe it is the right thing to do?

Here's my answer.

Hmmm, this is a difficult question.

What is right for one organization may be disastrous for another. And the reasons vary from industry to industry, and country to country.

Just a fancy way of saying "it depends"...

Here are some thoughts:

1) In terms of pure operational cost, including infrastructure and personnel, sending everything to the cloud is of course attractive, particularly for organizations which need the service of an email platform but cannot compete to get the top notch IT resources needed to operate it.

2) From a storage and overall management perspective, it also makes a lot of sense.

3) Thinking about control of the information and insuring that the ways in which security may be breached are well understood, it is a potential disaster. When you contract out the service, you also relinquish a lot of control.

4) For the long-term ability to dictate policy and control infrastructure, it has many pitfalls. Some organizations may fall pray to proprietary formats and difficulties repatriating their data.

5) From a legal retention point of view, in some countries it is simply out of the question to let your data reside "lord knows where".

6) From an eDiscovery standpoint, it is very muddy: What capabilities exist in the live mail system? What are the processes and tools to support them? Etc.

Overall, I would call the picture "cloudy" (intentional pun). It certainly is not all blue skies ahead...

That is precisely why we strongly recommend (and promote, let's be frank, some of our products to do this) on-premise archiving of cloud-based email platforms so that a modicum of control of the data is maintained, and that it remains possible to take this data and "go somewhere else" with it, should the cloud ever start to rain down on your organization.  (Ok, I'll stop now with the cloud puns.)

I hope this helps. Again, just my perspective as a lowly Product Manager.

]]>
Fri, 08 Apr 2011 00:00:00 GMT c7ebb8e5-5c9f-4038-9696-9f84abb55967
<![CDATA[More Reasons to Join Our Team]]> We continue to have great people join our team. In January 2011, Pierre Chamberland posted a blog Why Ask Why, which lead me to ask myself the question why are people choosing to join our organization? I have written a blog showcasing a few quotes I received from some of our newest members of our team, at that time, sharing the reasons why they joined the organization. Since my last post, we have a few more members that have join our team who, when asked, were excited to share the reason why they too decided to join our team.

“Many companies like to tell you they're the greatest but only tell you one side of the story during the recruiting process. The honesty Messaging Architects showed me gave me confidence that I was making the right choice. I feel lucky to have been given this opportunity at Messaging Architects and look forward to the challenges ahead.  If you are looking for a dynamic work environment where you will matter and not be "just a number", this is the place for you” shares Ravi Singh, Account Manager.

Guang Li, Software Developer - .Net keeps it to the point, “The company has great product - The business is growing and healthy - It's using the newest technologies - It has a very good management system - The company has sufficient equipments - There is a good working environment - The employee benefits are quite good - People have very good relationship between each other - They work very efficiently - There are a lot of social activities - Everyone is happy in the company”

“The open book management made me feel like a player from day one.  I was attracted to the company at first because of the laid back atmosphere and the great location but as time passed I was able to enjoy many of the perks offered, such as the Fitness Program and the Opus au Boulot.  I certainly don't regret my decision to become a member of the MA Team!” adds Karina Huertas, Sales Development Representative.

“I had never heard of Messaging Architects and when the company first came to my attention I had spent a lot of time exploring the website and what I found was what seemed to be a company with a set of products that they strongly believed in and a corporate culture that put employees at the forefront. It's a lot to convey through a website but I swear it was all there. As well, after every step of the hiring process (which is intense, but appreciated), I felt that this was the place I wanted to continue my career.” confirms Sean Phillips, Software Developer - .Net.

Our newest team members are happy to have joined Messaging Architects where they will continue to learn and grow; our existing team members continue to think Messaging Architects is a great place to work - read what they have to say about it.

 

 

 

]]>
Wed, 06 Apr 2011 00:00:00 GMT 8e004439-2aec-42d6-888a-cc5c1269c888
<![CDATA[Netmail Community]]> We just launched Netmail Community!

Netmail Community is the place to talk about email.

Indeed, we created Netmail Community because we felt there needed to be a distinct online space for discussion about email migrations, handling PST files, and other topics related to email management.

The goal of Netmail Community is conversation.

Click here for a great post from Product Manager Sacha, explaining the purpose of the site.

Visit Netmail Community right now to join the conversation!

]]>
Mon, 04 Apr 2011 00:00:00 GMT 735eca18-21d1-468d-9287-b38e0ced3015
<![CDATA[The Future of HIPAA (Part 3 of 3)]]> It’s time for part 3 of my 3-part blog series on HIPAA now. In part 1, I reviewed some recent HIPAA violations. In part 2, I gave advice for remaining HIPAA compliant while using social media. Today, I discuss the future of HIPAA: precisely, what changes to HIPAA should we expect in the future? 

(1) Revised procedure (“5010”) for electronic administrative transactions

This upcoming change applies to anyone covered by HIPAA who submits administrative data electronically (for instance, electronically submitting patient claims or bills to a health insurance company). Essentially, this change may require covered entities to gather additional data from patients and / or to submit the data in a different format, with the aim of making electronic administrative transactions less prone to error.

There is a strict deadline for compliance: all covered entities must be using the new 5010 guidelines by January 1, 2012.

The American Medical Association provides a good summary of the 5010 changes on their website.

(2) Adoption of Unique Patient Identifiers (UPI)

When HIPAA was enacted in 1996, it included the provision that a unique ID number should be created for each patient and health care provider, and that these ID numbers should be consistent throughout the whole U.S. medical system. In 1998, however, Congress responded to protests by privacy groups by suspending this initiative until further notice. This part of HIPAA had caused a division, with one side arguing that UPI’s were critical in ensuring that patient information could be readily accessed (for instance, in emergency situations) and in reducing administrative bottlenecks (for instance, when a doctor requests test results from another doctor), and the other side arguing that the UPI’s would cause huge privacy issues if lost or stolen (an identity thief could steal a patient’s entire medical history with just one number).

This debate persists, but in 2008, RAND Health published a study called “Identity Crisis: An Examination of the Costs and Benefits of a Unique Patient Identifier for the U.S. Health Care System.” This study recommended the adoption of UPI’s in the U.S. and asserted that using UPI’s would actually increase the security and privacy of patient records.

On their website, the American College of Cardiology provides a good explanation of why they are in favor of UPI’s, pointing to the RAND study as an indicator of the initiative’s success.

It will be interesting to see how this debate unfolds in the future.

(3) Patient Access to Records (NYTimes article)

Perhaps you remember the Seinfeld episode in which Elaine frantically tried to view her medical file after noticing the word “difficult” written in it. She even tried to steal the file from her doctor’s office! This situation tapped into the anxiety that people feel about their medical records: your medical records contain highly personal information about you, but you might never get to read them.

Ironically, this Seinfeld episode aired in 1996, the same year HIPAA was enacted. Now thanks to HIPAA, patients in the U.S. are entitled to view their medical records. This does not mean, however, that patients take advantage of this entitlement. In fact, many patients still never see their medical records because it is simply too complicated to request them.

From a doctor’s perspective, it can be worrisome to imagine a patient reading his or her medical record — what if the patient simply does not understand some of the doctor's abbreviations? This could lead to miscommunication. (Read this great New York Times article for more on this.)

Currently, a project is underway called Open Notes. Three healthcare centers (and a total of 25,000 patients) are participating in the project including Geisinger Health System in Danville, PA. Open Notes offers an online portal where patients can view their doctor’s notes following visits, phone calls, and other correspondence. The goal of Open Notes is to see whether patients and doctors enjoy having this open access to patient records.

I'm curious to see the results of the Open Notes project, and if we will see easier ways for patients to access their medical records in the future.

Ultimately, we cannot predict all the ways that HIPAA (and our enforcement of HIPAA) will evolve in the future. I am confident, however, that just as technology continues to change, HIPAA and our HIPAA practices will also adapt so as to better protect patient privacy and security.

Thanks for tuning in for my 3-part HIPAA blog series! Don’t forget to visit the Resources section of our website for tips on ensuring that your email system is compliant. If HIPAA affects you, you’ll be especially interested in reading our whitepaper, “In the Labyrinth of Regulatory Compliance: HIPAA.”

]]>
Tue, 22 Mar 2011 00:00:00 GMT f2153101-5d4a-406e-8721-433adfaa9229
<![CDATA[HIPAA and Social Media (Part 2 of 3)]]> Last week, I explained that I was prompted by recent HIPAA cases in the news to dedicate a 3-part blog series to HIPAA in the context of 2011. In last week’s blog, I focused on some of the recent HIPAA infractions. This week, I discuss HIPAA and Social Media, because with the prevalence of social media today, an examination of HIPAA now would be otherwise incomplete.

1996: let’s think back. It was a leap year. Alanis Morissette won a Grammy. Bill Clinton was re-elected. Ladies wore long floral skirts and chunky heels. HIPAA was enacted. And there was no Facebook.

No Facebook??

Yes, kids, we lived in a world with no Facebook!

When HIPAA was enacted in 1996, email was steadily growing in popularity, but social media sites like Facebook were not even on the horizon. Well, not in most people’s minds, anyway. In the 15 years since, social media arrived and captivated our interest. People now communicate with all kinds of other people via social media — friends, family, colleagues, neighbors, teachers / students, etc. — so why would patients not also communicate with doctors via social media? And why would patients not seek information about healthcare organizations on social media sites — everyone else is engaging in conversation on these sites, so why not healthcare organizations and personnel?

One of the biggest roadblocks is HIPAA. Many healthcare organizations and personnel worry that by using social media, they will violate HIPAA and the safeguards it prescribes for protecting confidential patient information; if patient information is accidentally disclosed via social media, this would mean big HIPAA sanctions (if you don’t believe me, see last week’s blog!).

It’s true, there are risks, but with precautions, healthcare organizations and personnel can reap the benefits of social media (it’s an easy and popular way to disseminate information and have a conversation) while remaining HIPAA compliant.

Really, I see two simple rules for ensuring HIPAA compliance while using social media:

1. NEVER post information about real patients. For the purposes of education, healthcare organizations might want to post information about public health initiatives, best practices, etc. This is fine, and in fact, can be highly beneficial to the community, but the healthcare organization must be sure to never publish information or examples about real patients.

Information about real patients should not even be published in response to patient questions. For instance, if a patient “friends” a doctor on a social media site and subsequently asks a question of the doctor (via “wall post” or private “message”), the doctor should be extremely careful to not offer confidential patient information in the answer. If unsure, the doctor could always request that the patient call or visit to further discuss.

It’s important to note that if a patient (or family member or friend of a patient) posts sensitive data on a social media site, this is perhaps tactless, but it is not a HIPAA violation ;) However, the healthcare organization or personnel should be careful to not respond by further revealing information or by confirming / denying the information that was posted. Also, the healthcare organization or personnel should not edit the post, because once it is touched by an entity that is covered by HIPAA, a HIPAA violation can apply.

In your adventures on the Internet, you may have noticed that some healthcare organizations or doctors DO post information about real patients. For instance, some hospitals post success stories, etc. In such cases, we can assume that written permission has been received from the patients.

2. Beyond never posting sensitive information about real patients, training is key to social media success for entities covered by HIPAA. This means that all personnel who are covered by HIPAA should be made aware of the strict safeguards that protect patient information; it’s important for healthcare personnel to understand that HIPAA rules extend to social media.

Surely, healthcare organizations could benefit from the conversation that occurs on social media sites. I’m confident that with appropriate diligence, HIPAA and Social Media can coexist.

Oh, one last thing: when we think of social media sites, we think of photos, right? It is a good idea for hospitals and other healthcare organizations to post signs stating that photo-taking is not permitted on the premises (and have staff enforce the rule). This way, when photos of the new baby or of Grandma recovering from surgery show up on a social media site (potentially breaking another patient’s privacy rights by accident), the healthcare organization can be confident in the fact that they discouraged this behavior. (Again, HIPAA cannot penalize patients or patients’ family / friends for this behavior.)

Tune in next week for Part 3 of my 3-Part HIPAA Now Series: The Future of HIPAA

]]>
Tue, 15 Mar 2011 00:00:00 GMT 316d34b3-77d6-4f4e-88d0-65c33d23c594
<![CDATA[HIPAA in the News (Part 1 of 3)]]> Recently, there have been several HIPAA violations in the news. It’s gotten me thinking about the state of HIPAA today. HIPAA was enacted in 1996; those of us who need to know about HIPAA (or who are simply curious) have informed ourselves, right? We’ve read the law, we know what HIPAA means… right?

Sure, we’ve read the law, but what does HIPAA mean in the context of today, in the year 2011? I decided to dedicate a 3-part blog series to an exploration of HIPAA now. I start today by reviewing some of the HIPAA cases that have been in the headlines lately, hoping these cases will highlight the current state of HIPAA.

Violation 1: Records Accessed by Unauthorized Employees at University Medical Center in Tuscon, AZ

In January, three clinical support staff members and a contracted nurse were fired for accessing confidential patient records without authorization at University Medical Center (UMC) in Tuscon, AZ. At the time, Representative Gabrielle Giffords (who was the victim of an assassination attempt on January 8) was being treated at UMC. On its website, UMC stated the following: “With advances in technology, ensuring patient privacy has become the focus of hospitals nationwide. UMC uses sophisticated technology to help prevent and detect inappropriate access to patient information.”

Lesson Learned: Technology advances, but human nature stays unchanged. Humans are curious. Even in the face of HIPAA infractions, we are curious, and we are especially curious about people in the public eye. I suspect that curiosity was the motivator in the case of these HIPAA infractions. What do we learn from this? HIPAA training is crucial for medical staff, and it is important to stress that even in the case of curiosity, HIPAA infractions are serious and punishable.

For help formulating HIPAA policies, see our whitepaper, “In the Labyrinth of Regulatory Compliance: HIPAA” (check out page 10, Formulating Internal Policies).

Violation 2: Backup Tapes Stolen from the New York City Health and Hospitals Corp.

In December, backup tapes belonging to the New York City Health and Hospitals Corp. (HHC) were stolen from a truck while being transported to a storage location. The stolen data included personal information of patients like names, addresses, Social Security numbers, and more, dating back 20 years; 1.7 million individuals may have been affected. The tapes had not yet been encrypted, though HHC stated the following: “Although the data were not encrypted, it exists in a proprietary program that scrambles the records and would make it difficult for individuals without specialized technical expertise and access to the right software and computer hardware to view the private information.”

Lesson Learned: From an IT perspective, backup tapes are critical in the event of a disaster; essentially, they are an insurance policy to make sure the system gets up and running so business can continue. From a compliance perspective, the importance of the security of backup tapes should not be ignored.

Our archiving solution, Netmail Archive, is a secure alternative to backup tapes; lost data can be restored from the centralized (and secure) Archive repository following a disaster, without the need for backup tapes.

Violation 3: Massachusetts General Hospital Settles with U.S. Government for $1,000,000

In February, the General Hospital Corporation and Massachusetts General Physicians Organization Inc. (Mass General) settled with the U.S. government for $1,000,000 over HIPAA violations. The HIPAA violations arose from an incident in which a Mass General employee left documents containing patient information on a subway train. The lost documents included names and medical record numbers of 192 patients and billing documents containing the names, dates of birth, medical record numbers, insurance information, and diagnosis of 66 patients.

Lesson Learned: Again, we see the importance of creating and enforcing a HIPAA policy. In fact, it was stipulated in the settlement that Mass General is required to create and implement a policy regarding the removal of personal health information from the facility. Training of employees is also stipulated in the settlement.

For more information about formulating policies, watch our 4-part Email Records Retention video series (featuring attorney Benjamin D. Wright), available on our YouTube channel.

From these recent events involving HIPAA, we see that HIPAA violations are taken seriously and both individuals and organizations can be held accountable. We also see the importance of creating and maintaining policies regarding access to patient information and the securing of physical data.

Tune in next week for Part 2 of my 3-Part HIPAA Now Series: HIPAA and Social Media

]]>
Tue, 08 Mar 2011 00:00:00 GMT ed74c6bc-1378-4417-b23c-4dfd5bb730ba
<![CDATA[Bleeding Edge Technology Finds Spammers Where They Live]]> The short history of NSBL

In 2001, April Lorenzen was the co-owner of a web/email hosting ISP company who was growing frustrated with the available spam-fighting tools. "As a hosting ISP responsible for several hundred business domains in the late 1990s, we always employed moderate anti-spam techniques," April says. "However, our frustration level mounted as customers complained about the amount of offensive and annoying spam email that still leaked through daily."

So she started experimenting with radical approaches—such as parsing the Spamcop.net web page every 5 minutes, and automating a 24-hour block on the addresses found there. This method was neither 100% effective nor free from false positives. But she did notice, as part of this experiment, that spammers were skipping over a large and unpredictable variety of Class C netblocks, often only staying on a particular IP for a few hours.

The light bulb goes on

In June of 2001, April had an epiphany—she realized she was wasting her time chasing after lists of 'bad' IPs that would never stop growing and changing. Spammers have nearly 2 billion possible addresses at their disposal, so they won't run out of fresh unlisted IP addresses any time soon. Instead, it seemed far more efficient to create a worldwide index of domains and their associated, authorized outbound email servers, stored in a shared repository database that also contained other information useful to those fighting spam.

So she formed a new corporation to develop a reliable, scalable infrastructure for the concept of an email server identity database. She called it the Outbound Server Authentication Index (Outbound Index, for short). The people and resources needed to create and further refine the prototype came mostly from the Open Source community. Her team rapidly created a query-response server that interfaced to the prototype Outbound Index database and worked with Postfix and Sendmail. Now properly-configured mail servers could query this repository, and automatically reject mail with either a forged return address or one from servers operating on IPs forbidden by their own ISPs.

After that, they quickly realized they could add other reputation checks to the same infrastructure. Over the following years, they started to expand the checklists, focusing closely on spammer-like domain registration and reputation.

Some of the additional checks included:

  • Has a trusted SSL certificate on its website?
  • Has registration and usage patterns that match characteristics of a throw-away domain?
  • Shares name server hosts, whois data, registrar, etc. with throw-away domains?

Using this new reputation data, they found the data to be very effective. With it, they could help ISPs make very accurate decisions as to whether messages were coming from a spammer or other cyber-miscreant. The beauty of the approach is that it can detect bad domains days or even weeks before these domains are actually used as part of a global spam campaign. This headstart is a huge advantage in boosting the effectiveness of any security infrastructure.

In 2009, Messaging Architects started to work with April to further refine the concept and the reputation scores so they would also work well with corporate mail server patterns. We then added support for the feed directly as part of our Netmail engine and coined the new solution as NSBL, short for Name Server Block List. Today, we are proud to be the first company to ship a scanning & compliance solution to have this advanced and unique functionality.

In our real world tests, once again we improv

]]>
Sat, 19 Feb 2011 00:00:00 GMT 85b864f8-8acc-436c-bb19-97bb6108eb34
<![CDATA[Why Join the Messaging Architects Team?]]> These days, I continue to spend most of my time recruiting; reviewing resumes, screening calls, and doing full-fledged interviews, and I find myself asking, why would a potential candidate consider joining our team? We know exactly what type of talent we are looking for but who is looking to join a great organization like Messaging Architects? So in search of answers, I asked a few of our newest team members what made them choose to join Messaging Architects, and here is what they had to say.

"Everyone works so well with each other to work through the issues at hand instead of trying to undermine another member of the team like you see at some workplaces," comments Zac Watson, Front-Line Support Engineer.

"Most of all, I was excited about working with a company that is in a growing industry and has unlimited potential. In addition, it's 100% employee-owned with a flat organizational structure. This makes it easy to interact with my colleagues, especially when everyone is dedicated to the same goal - success!" confirms Mark Brown, Account Manager.

"I chose to join MA because it's privately owned, has an international market, a successful product line, and good growth prospects. There is a good workplace atmosphere and the employees are genuinely welcoming. The company values its employees and fosters a collaborative workplace," shares Derek Gaucher, Project Manager for our Professional Services division.

"The overall feeling in the office is very analogous to the heyday of the Silicon valley, where an employee is valued equally as much for their creativity as for their day to day contribution, where ties and suits for that matter - are for the most part optional. The entire company is a terrific mosaic of different cultures, which believe in each other and subsequently have created a culture of trust," observes Richard Cabana, Director of Technical Sales.

If you find yourself inspired, read more about the top 10 reasons to join our team!

 

]]>
Tue, 08 Feb 2011 00:00:00 GMT 39fcd22f-3d3e-4632-9690-6b1b05486f90
<![CDATA[A Software Developer's Advice on Passwords]]> Anyone who follows the news knows that using the same password everywhere is a very very bad idea.  A number of very popular online services have had their users' passwords stolen in recent months.  The mere fact that these sites store passwords in such a way that they can be stolen is disturbing.

That being said, I suspect that the vast majority of people reading this do use one password on many many sites.  The reality is that the average person can not easily remember multiple passwords.  It just isn't practical.  Your choices are to use a few passwords frequently, or to use many passwords and write them down.  Either is dangerous.

There is another option though.  Recently a Firefox add-on named PwdHash has been released (and been ported to other major browsers) that allows you to use a single password in a much safer way.  The add-on works by creating a unique password for each site you visit.  This unique password is based a password that you must remember, and the site's domain name.  Your original password is never sent to the site.

For example, if I had remembered a password of 'monkey' and I visited google.com then the add-on would generate a password of 'k3XrjUkt'.  If I visit yahoo.com then it would generate 'Rt0UnWkn'.

It works by creating an MD5 hash of the site's domain name, and your original password.  The hash is then modified a bit to make a short and simple password.  This calculation is done entirely in javascript on your machine.  This means that your original password is never sent over the wire.

It isn't perfect though.  There are some issues.  The biggest being that MD5 has been broken, and is now reversible.  So, if some one gets one of these passwords and knows the algorithms involved then it is possible that they will be able to reverse it, and obtain your original password.

I think this is rather unlikely to happen though.  If a site is hacked, and your password is stolen, then it is likely to be one of many that are stolen.  If this happens then the culprit is likely to use a script to try the passwords that they obtained, and will probably not pay much attention to passwords that don't work on other sites.  After all, you don't need to be faster than a bear to survive a bear attack.  You just need to be faster than the guy next to you.

Even if someone is specifically targeting you, and has one of these passwords it is unlikely that they will realize that you use PwdHash, and the passwords that are generated look like simple random passwords.  Nothing about them screams "I'm a hash!".  So, if you don't trust someone, don't tell them that you use PwdHash.

There are some very nice aspects to this solution as well.  The best part is that it is so easy to use.  Once the add-on is installed you can simply enter @@ before entering your password, and it will automatically convert it to the hash for you.  Simply get in the habit of typing @@ before your password, and it will take care of the rest.

You can even generate a password without installing the addon-by going to http://www.pwdhash.com and using the form on the site.  It works entirely in client side javascript, so it is just as secure as using the add-on.

One can argue that this is just a bit more security by obscurity, but in this case I think it is a big step in the right direction.  Hopefully a future version will use a better hash algorithm, which would make this a mu

]]>
Mon, 31 Jan 2011 00:00:00 GMT 4b8c1bc1-a6fc-477f-8c46-18298728be1f
<![CDATA[Why Ask Why]]> I have now made it a habit to ask Why?

Recently, the hotel I was at sent me down the street to a health club since their gym was being renovated. Before I could use the equipment, the health club wanted me to fill a complex form with full address and contact information + a detailed health assessment... Why? Insurance regulations, they said. Since I only wanted to use the treadmill for 30 minutes, I went back outside and speed walked for 1/2 hour instead.

Insurance regulations are very powerful things these days. Because of them you can't watch a mechanic repair your car, or visit the warehouse, or see the kitchen, etc...

It gets worse...

Medical clinics will not give you the phone number of the doctor that took care of you... Why?

My local bank is giving new clients a nice gift, I've been a client for years and get nothing... Why?

My old phone company wants me back, so they called to offer me much better rates. Why did they not give me great rates while I was a client?

Since I have made it a habit to ask Why?, I find that I do not get many decent answers. Most of the time the front line workers who are charged with implementing the asinine policies of their company have no clue. They are just frustrated by being asked the same question over and over, and having no real answer.

Most bureaucratic (not client intimate) organizations do not want any WHY questions to work their way up the chain - they want front line folks to be the only line of defense. The well known responses include:

- That's our policy.
- Sorry, I can't change this.
- Nobody here can help you with that right now.
- and of course - Insurance regulations.

Clearly, the primary goal of the response is to get the client (questioner) to go away, to stop bothering us. Does that make any sense?

Messaging Architects’ Goal - BEING REMARKABLE

At Messaging Architects, it is our mission to ALWAYS answer the WHY?

I am convinced we will surely improve a lot of things for our clients by doing so.

]]>
Tue, 11 Jan 2011 00:00:00 GMT f73af658-6583-4d33-a466-420aa3060ff3
<![CDATA[Email Writing Style: I waaana hearrr from uuuu!]]> We recently posted a news item about a study published in Social Psychological & Personality Science. The study focused on how corporate email users are perceived based on the writing style of their email messages.

The study found that people who write in the third person are perceived as being either angry or too formal. (Jane Bolton Lacombe hopes that someone will post a comment in response to this blog.) First-person messages, on the other hand, are perceived as intimate. (I hope that someone will post a comment in response to this blog!)

The study also reported how typographical errors and punctuation are perceived. Typographical errors: the sender was perceived as not caring (especially among older readers). Lack of punctuation: ditto, with question marks perceived as indicating confusion and exclamation marks as indicating happiness.

When I read this article, my first thought was how important it is for companies to educate their email users about email etiquette, including writing style. When drafting a corporate email policy, it’s important that email writing style be addressed, especially because some users might be simply unaware of certain perceptions surrounding email writing. (For example, I have encountered people who don’t realize that writing in CAPS = shouting.)

Obviously, it is not surprising that this was my first thought, considering where I work. But my second thought was something less related to my job responsibilities. I thought, what about the teens?

I’ve noticed the newfangled email / texting / facebook language of today’s teens. (Gosh, how old do I sound right now??) Have you noticed the new language too?

The main difference is: extraaaa leeetterrs.

Also, extra abbreviations. (I wish I could give examples but we’ve already established that I’m old.)

I know a mom who restricts her teen’s texting time because she’s worried about how the new language will affect the teen’s writing at school.

I want to know what you think.

Are the extra letters a fad? If not, what will corporate email style look like ten years from now? Will teens have difficulty adjusting when sending corporate emails, accidentally emailing their boossssess with extraaaa leeetterrs? Or, will the writing style of corporate email change and we old folks will have to adjust?

I have my opinions on this, but I really want to hear from uuuu!! Post a comment. If you do, ily.

]]>
Mon, 10 Jan 2011 00:00:00 GMT f9c0fdfe-61db-4b00-9a32-bb0d0082c5a5
<![CDATA[Nice, Hot Email Password Security for the Holidays]]> Password security is a hot topic right now, largely due to the Gawker hacking incident. It is hotter than a nice, warm mug of eggnog & rum. So before I sign off for the holidays (eggnog & rum, eggnog & rum!), here’s my advice on password security...

IMHO, there are two problems with our passwords (I’ll use the collective “we,” because I too have been guilty of weak passwording):

1. The password is insufficiently complex.

The number one password of the hacked Gawker accounts was 123456. Number two was password. Number three? 12345678. Check out the Wall Street Journal for more Gawker password stats.

2. The same password is used for multiple sites.

Sure, you don’t want your Gawker account hacked, but you definitely don’t want your banking, email, or social media accounts hacked because your Gawker account was hacked; that’s the risk with redundant passwords. Check out the news item we posted yesterday.

Why do we use easy passwords for multiple sites? We are impatient! Log us in now, now, now! Actually, log us in two seconds ago!

Also, we are lazy.

In reality, it’s easy to create strong passwords, and they will barely slow us down.

Our friends at Mozilla posted a video on YouTube with a method for creating strong passwords. Here’s their advice (rephrased à la Jane).

1. Select an easy-to-remember phrase: Kill two birds with one stone

2. Replace any numbers (or letters that sound like numbers) with actual numbers: Kill 2 birds with 1 stone

3. Take the first letter of each word to shorten your phrase: K2bw1s

4. Add some special characters: &K2bw1s%

5. Use this password for multiple sites, BUT add a distinct suffix for each site. For instance, add “:fb” to create your facebook password: &K2bw1s%:fb

Voila, your new password.

Using this method ensures that your password uses letters (upper and lowercase), numbers, and special characters, making it a complex password. Adding suffixes makes it distinct for various websites.

Microsoft offers similar advice, as well as a password checker for evaluating the strength of your password.

&K2bw1s%:fb tested as “Strong” according to Microsoft. Adding nine more characters at the end of the password tipped it into the “Best” category. (Microsoft recommends passwords to have at least 14 characters.)

I’m signing off. Enjoy your eggnog for now, but let’s resolve to be password secure in 2011.

 

]]>
Wed, 22 Dec 2010 00:00:00 GMT b2f15e3f-0eac-4ac2-b71d-8c27c47c194e
<![CDATA[Messaging Architects takes on the Movember Challenge]]> Here at Messaging Architects, when we're not busy developing email archiving and security solutions or helping our clients migrate between email platforms, we always try to find time to give back to our community whenever possible. This year, we participated in the month of Movember.

"The idea for Movember was sparked in 2003 over a few beers in Melbourne, Australia.  The plan was simple – to bring the moustache back as a bit of a joke and do something for men’s health. No money was raised in 2003, but the guys behind the Mo realized the potential a moustache had in generating conversations about men’s health. Inspired by the women around them and all they had done for breast cancer, the Mo Bros set themselves on a course to create a global men’s health movement.  

In 2004 the campaign evolved and focused on raising awareness and funds for the number one cancer affecting men – prostate cancer. The Movember moustache has continued to grow year after year, expanding to Canada, the US, UK, New Zealand, Ireland, Spain, South Africa, the Netherlands and Finland."

In early November of this year, Dan Bigras, a Technical Solutions Architect in the Messaging Architects head office in Montreal, channelled his inner Magnum PI and challenged his fellow Mo Bros to commit to growing a moustache for 30 days. Fourteen men, including our Chief Energizing Officer Pierre Chamberland, gladly took up the challenge and 1 brave Mo Bro even agreed to have his entire head shaved for the cause. It was a fun event that raised $2,156.00 for Prostate Cancer Canada before Messaging Architects matched employee donations dollar for dollar.

We are proud to announce that this year’s Canadian campaign raised over $19 million overall, and was #1 worldwide, beating out Australia (who came in at $18 million). Go Canada.

]]>
Sun, 05 Dec 2010 00:00:00 GMT a983d790-fb7c-4f58-99b1-50d94a49c097
<![CDATA[FIPPA vs PHIPA: Some things Ontario hospitals need to consider with respect to Bill 122]]> "One of the foundations underlying freedom of information is the principle that organizations that exist by virtue of public funding should be subject to public scrutiny through FOI laws... The government should also bring children’s aid societies, hospitals, and other publicly funded organizations under FOI legislation." - IPC 2005 Annual Report

On October 20, the Ontario government introduced amendments to the Broader Public Sector Accountability Act, or Bill 122, whose basic purpose is to promote a higher level of accountability in the public sector. The proposed legislation will enforce new standards for reporting and accountability for hospitals, local health integration networks, school boards, colleges, universities, and other broader public sector organizations that receive more than $10 million in public funding annually. The bill is expected to pass by November 30.

A key element of Bill 122 is that it extends the Freedom of Information and Protection of Privacy Act (FIPPA) to public and private hospitals. Unlike the Personal Health Information Protection Act (PHIPA), which regulates the access to one's personal information, under FIPPA, the general public will have a right of access to institutional records, unless they are excluded from the right of access or subject to an exemption.

Hospitals will have until January 1, 2012 to implement new procedures to meet the requirements of the new provisions, such as processing requests for access, managing complaints, and training for the staff. The new legislation will apply to all records in the custody or under the control of a hospital after January 1, 2007. Ensuring compliance with FIPPA is the responsibility of the chair of the hospital board. According to Ann Cavoukian, Information & Privacy Commissioner of Ontario, this move is absolutely necessary, as "Transparency will help build public confidence and trust in Ontario’s health care system, which is currently at an all time low."

Does FIPPA apply to email? Yes, it does. Emails messages are considered records under the Act and are subject to the same provisions, exemptions and exclusions as any other type of record. Unless an email falls into one of the exclusions outlined in the Act, this means:

  • Emails containing personal information must be protected and dealt with in accordance with FIPPA.
  • Emails are subject to access requests under FIPPA.
  • Hospital and staff needs to be aware of the requirements of the Act.

There is no doubt that the application of FIPPA represents a significant change for Ontario hospitals. Whereas previously the only right of access to information was by individuals to their own health records under PHIPA, if the proposed legislation is enacted and it is very likely it will be, many other hospital records will be accessible to the general public. Thus, it is key for Ontario hospitals to make appropriate changes to their record keeping policies, procedures and practices so as to be able to efficiently respond to access to information requests.

Download this brief. For additional information on what hospitals need to consider with respect to email retention, we invite you to contact our Healthcare Email Risk Management experts at 866-497-0101 x230.

]]>
Tue, 23 Nov 2010 00:00:00 GMT 5070ab98-ab12-4b62-b5b8-4f1183fa6e06
<![CDATA[Talk about teamwork!]]> Much of my time continues to be focused on recruiting efforts, and the search is paying off. New team members are joining our organization in the next few days. And I have to say that I am really pleased how efficiently and quickly my team internally has reacted to get them all ready and set to go right from day 1 at MA.

You probably noticed that I am repeating the word "team" a lot, right? That's not by chance. Team is the theme of today's post, pun intended. Team means a lot at our company and I want to convey this to you.

Speaking of teamwork, I'd like to share how our organization has brought our stellar client service to a new level with the introduction of our internal cross-functional teams. Here is what we did. We put together cross-functional teams that comprise eight members, each representing different facets within our organization. Every team is specially dedicated to a client.

It's all part of a new Elite Client Status Program we launched in the summer. As we strengthen our cross-functional teams, we are able to share ideas and gather information much faster, which in turn ensures we improve business processes and the benefits we offer.

Here's an example. During our last quarterly meeting, our cross-functional teams met and three issues that surfaced were remedied within 24 hours. This was possible because each team had teammates who had the knowledge and power to make the necessary changes. The results were two-fold. First and foremost, we were able to provide better client service. Secondly – something that's very important to me as a champion of the MA teams – there was conviction among the team players that working and collaborating together as a team does make us as a more effective organization.

If, when reading this you find yourself thinking that you'd thrive working within one of our cross-functional teams, check out the Careers section of our website.

More news coming soon…

]]>
Wed, 20 Oct 2010 00:00:00 GMT e0a961bc-19d5-4783-9c72-87b6c08c476d
<![CDATA[20 Years of Fighting the Good Fight]]> From the first computer worm distributed via the Internet (the Morris Internet worm) in November 1988, to the first trojan for PCs to receive widespread media coverage (a trojan horse disguised as an AIDS Introductory Information Kit) mailed on diskette to approximately 10,000 recipients, to the infamous Michelangelo virus, former McAfee researcher, Aryeh Goretsky, reminisces on his twenty years in the anti-virus industry fighting the good fight in a compelling article entitled Twenty years before the mouse.

]]>
Tue, 05 Oct 2010 00:00:00 GMT 576e9702-e074-4ea3-b5b5-69e073b2e68e
<![CDATA[Messaging Architects beats the odds! ]]> Judging by the activity around the office, you would hardly think the economy is recovering slowly. MA keeps on hiring to fulfill the demand of its email risk management and compliance solutions... Between resume reviews, screening calls, and full-fledged interviews, I haven't had a moment of free time this summer! Actually, I don't mind it all.

Much of my time has been spent on recruiting efforts, searching for the right talent to add to the unique ecosystem Messaging Architects has to offer. As an organization, we know exactly what type of talent we are looking for, and our rigorous and effective interviewing practice helps us do just that.

We are looking for those that have an entrepreneurial spirit and who would like to work in a business of business people. If, when reading this, you find yourself saying you'd like to work with us, please have a look at the Careers section on our website and see if the evolution of your career continues with Messaging Architects.

OK, back to the search. More news coming soon…

]]>
Mon, 27 Sep 2010 00:00:00 GMT 872113c7-592f-4a5f-947c-cd485edbb19e
<![CDATA[Introducing Stephanie Greenshields…]]> Last week, I had an informative talk with Stephanie Greenshields, the person who runs HR and takes care of the MA team. As a remote employee, I think it's important to have regular chats with my colleagues at headquarters outside formally scheduled meetings and phone calls, keep up with the pulse and energy of the company.

I like talking to Stephanie and I always learn something new. She is the person who's involved with new initiatives that help us be more productive in our day-to-day work and continuously improve the relationship with our clients. In fact, she was instrumental in defining the high standards for our client care and support that sets us apart from other vendors in the email risk management space – and I dedicated a whole post to that…

Stephanie had quite a bit of info to share: improved evaluation processes, upcoming internal awards nominations, new team members joining the company, exciting changes to our Careers page. Turns out, contrary to the general trend I hear on the news every night, Messaging Architects is actively seeking to recruit more people to join the team.

My suggestion to Stephanie: get the word out about what's happening in our company, tell the world about the different initiatives focused on growing the team, point out some of the reasons why high achievers have a lot to gain by working for MA. And she agreed.

So far the MA corporate blog has been about technology trends, email risk management and client success. Starting today, it will also provide a personal look about what it is like to be an MA employee.

Welcome, Stephanie!

]]>
Mon, 27 Sep 2010 00:00:00 GMT ff8c251a-bf3d-487b-8156-aef503655a3f
<![CDATA[Interview with Shane Brown, President of DigeTekS LLC]]> DigeTekS LLC is an Information Technology consulting services firm based in Firestone, Colorado. Founded in 2005, the company has a highly skilled and experienced engineering staff whose mission is to meet their clients’ IT requirements by bringing them the most effective and appropriate technical solutions. DigeTekS has strong partnerships with select software vendors. These relationships enable the company to provide rapid, expanded support and accelerated escalation services for their client base.

A few weeks ago, I spoke with Shane Brown, President of DigeTekS, about their company and the immediate technology issues they are helping their clients address. We also touched upon some of the reasons that underlie the successful and long-term partnership between DigiTekS and Messaging Architects.

RD: Who are DigeTekS’ clients? Do you specialize in supporting organizations from a specific vertical or geography?
SB: DigeTekS’ clients range from very small organizations to Fortune 500 companies. We have clients across the United States and naturally we are especially prominent in the Rocky Mountains region and California. We also work with several VARs for whom we handle specific IT implementations.

RD: From conversations we’ve had over the years I know DigiTekS maintains a very special connection with its clients. Once you have established a relationship with a company, you not only provide technical advice and implementation assistance, you have a much deeper involvement with them, isn’t that right?
SB: Yes, we have long-standing relationships with our clients. In addition to providing them with the necessary technical assistance, we also serve as trusted advisors. We offer them a high level of advice on environments they need assistance on and in some cases we completely manage these systems on the clients’ behalf.

RD: In other words, you really provide turnkey solutions to your clients. The clients task you with the IT project and then leave it up to you to plan its implementation, recommend the solution that would bring the project to a successful completion, and fully document everything.
SB: That’s exactly the case. The majority of our clients have been with us for a long time, they trust us and follow our recommendations on design, implementation and technology selection. In some cases, we complement their in-house IT resources with skills and experience they may not have in-house. For example, we have used our comprehensive expertise in Novell technologies to help our clients move from Netware to Open Enterprise Server (OES) and in the process upgrade to GroupWise and deploy IDM and Zenworks. What I mean is that we are able to combine several projects together and update our clients’ IT environment faster and cost effectively.

RD: DigeTekS and Messaging Architects have been partners for over five years. What do you think makes the partnership work well?
SB: I think that Messaging Architects has been developing innovative technology to address email risk management that in turn allows us to offer our clients the right solutions that best meet their business needs. Over the years, we have been very successful deploying M+Guardian. Our clients really see the power of the technology and currently we have a lot of Guardian licenses. At the same time, we are also starting to see increased interest in M+Archive as more and more companies are realizing that implementing email archiving is no longer optional.

RD: You have always been a strong proponent of M+Guardian. Where do you see its advantages over other email security products?
SB: M+Guardian just works really well. When we ask clients to compare it to other products that are available, they find it easy to use, really good as far as false positives are concerned and the different layers of scanning that are employed, and end users like it too. The IT staff like it because it’s simple and provides the level of email security they need. In terms of managing the spam quarantine and releasing trapped messages, it is much easier with M+Guardian than it is with some of the other products. On our end, we do internal tests comparing M+Guardian to other solutions and it consistently shows superior results. I am not talking only about low-cost products, such as Barracuda, over which M+Guardian is massively superior. As far as we are concerned, M+Guardian scores better than most of the other higher-end email security products on the market, such as Ironport or Ironmail, both in terms of spam catch rates and false positive rates. All these factors make M+Guardian is a pretty fast and easy sell for us.

RD: You mentioned that M+Archive is starting to rise in popularity. In so far as your clients are concerned, when they look at email archiving, is it to contain storage growth or because of eDiscovery and compliance considerations?
SB: Increasingly, clients are seeing eDiscovery and compliance requirements they have to meet and what really gets them moving forward is the fact that with M+Archive they are able to meet these mandates and at the same time achieve a level of storage optimization on their email server. Very often the organizations are running out of storage and when a solution can both free up some space and also let them find information faster and be compliant, they are ready to move ahead because they see the potential savings in terms of costs, storage, time, and overhead.

RD: So even though storage is coming down pricewise, it’s still a concern among your clients…
SB: It’s definitely a concern. Here’s a simple example illustrating the issue: Let’s say you have a GroupWise or an Exchange environment you have set up and to which you have allocated a certain amount of disk space. If you want to add more disk space to it at a later point, you look at adding along the lines of the same capacity you started with. For the email production server this is usually high-performance storage that is quite expensive. When clients realize that through an email archiving solution, they are able to offload email, free up space and continue to access the messages without any latency, they start doing the math and the savings can be considerable.

Here’s a real-life case: a school district we work with spent $150,000 on the disks for their email system. Now they’ve implemented M+Archive, they can by pulling some of the emails out and storing them on disks which cost them $40,000 for the same capacity; that’s less than a third of what they paid for tier 1 storage. So now they have accomplished several things: they’ve cut down on the costs of their disks considerably, at the same time the performance of their email system has improved dramatically, and the entire collaboration environment has become easier to manage.

RD: What can you say about the architecture of M+Archive when you compare it to other archiving products on the market?
SB: M+Archive is very well designed. As for the M+Archive interface, I can say that it has several benefits and we’ve noticed that clients really like it. It is straightforward and quite intuitive. Clients are able to do their searches and retrieve the information they need easily without having to spend a long time understanding what they are doing. In fact, we find that showing a product demo to potential clients really speeds up the sales cycle, as they are able to immediately grasp how M+Archive will help them solve their problems.

RD: From your point of view, is the fact that M+Archive offers eDiscovery capabilities in addition to the archiving functionality at no additional cost a benefit that clients appreciate?
SB: I focus primarily on design and implementation of the archiving solution and am less involved in the pricing stage of the selection process. However, I do know that from a cost perspective M+Archive ended up saving at least 40% for a client after all the components regarding the functionality they needed were factored in. So I would say that from a cost perspective M+Archive has some clear-cut advantages. And cost is a huge factor in the decision-making process for clients.

RD: What other IT projects has your team been most involved with lately?
SB: As I mentioned before, among the trends we’ve seen regarding IT projects our clients are involved in with have to do with file server. We are helping clients move from Netware to OES. As part of that project, we are also migrating companies to GroupWise 8. Clients need the enhancements in the GroupWise and WebAccess clients we are able help them update their messaging systems while doing the same for their file servers. This is another reason for the rising popularity of M+Archive. As a best practice, we recommend that they introduce centralized archiving prior to the upgrade. The result of this approach is a much better performing email system after the migration to GroupWise 8.

RD: In your experience, do you see many organizations moving away from GroupWise to other email platforms?
SB: The release of GroupWise 8 has slowed down this trend. The capabilities of version 8 are comparable to what clients are looking for and this is stopping them from moving to a different email platform. In some cases, unfortunately, the decision to move to Exchange has already been made and in those cases, DigeTekS is involved with designing, planning and implementing the bigger move. Clients really appreciate our expertise in multiple messaging systems as often they lack the know-how internally to successfully execute such a big and complex project.

RD: You are confirming what our clients also feel: the thought of migration evokes nightmares for a lot of IT departments. How does your methodology to email migrations prevent it from being a really painful experience for the clients?
SB: Over the years, we’ve accumulated considerable experience and best practices what to do and what to avoid in order to have a successful migration without the pain. It’s not impossible; it just requires careful planning and understanding of what the client needs and how best to attain it. We have a standard procedure we use for all implementations we do – step 1 is back up all the data to ensure that nothing is lost. The same rule applies to the messaging system. In this case, before we proceed to the email system switch, we recommend that all email data be archived in a platform-independent format. This ensures the data is always available to the business regardless of the outcome. Access to the archive is much more immediate than having to resort to backup. M+Archive provides the tools we need to implement this step. The fact that it works across email platforms also means that clients can continue using it on the new email platform at no additional costs. Moreover, M+Archive comes with a built-in migration utility that allows us to guide our clients through migrations much more painlessly than it has traditionally been.

RD: DigeTekS recommends M+Archive over Quest Migrator to its clients. What were the advantages you saw in Messaging Architects’?
SB: We have been been familiar with the Quest tool for a while. The basic premise they adopt is to take all the email from GroupWise and transfer it all into Exchange, regardless of whether it’s needed or not. As a result, there are serious risks of losing messages during the course of action, files get corrupted, storage requirements double or triple, and the overall process can be quite painful for the client. Besides, once you’re done with the migration, the tool is useless and cannot be used for anything else. It seems like a bit of a waste of hard to come IT dollars.

We are currently using M+Archive to migrate clients because we think it offers a better methodology that can result in considerable savings for them. What it boils down to for the clients is that by archiving and then migrating to a new platform, they have invested in a long-term solution that allows them to select the data to be migrated to the new system, while at the same time having access to the legacy archives in a standards-based platform-independent format. Moreover, they are able to use the same product to continue archiving email on the new platform as opposed to the Quest tool that they have to discard after the project is completed.

In so far as the actual migration process is concerned, a migration can be done faster using the with M+Archive migration utility because of all the preparation steps that we can do ahead of time with zero impact on the end users. With the Quest tool you’re completely limited to the number of hours in a day because it physically takes each email, pull it out of the old system, change it and inject it in the new system at the time of migration. Sure, you can set up multiple workstations to migrate more people simultaneously, but this approach introduces a lot of complexity upfront and increases the risks.

Here are some real-world numbers:

  • A 10GB GroupWise mailbox will take 7-8 hours to migrate to Exchange. If we want to run 10 workstations simultaneously, we need to prepare each one of them for the process. So even if the migration itself requires 8 hours, the work upfront would add up to double that time – more like 14-16 hours altogether.
  • The largest client mailbox we had to migrate using the Quest tool was 22GB. We had to run the migration 3 times as there was corrupt data. When the tool encountered an error, we had to go back, clean it up, and rerun the process again. Each time it took about 24 hours.

These examples confirm the limitations of the Quest tool. Beyond that, the more important question remains: why is it necessary to migrate 10 or 22 GB of email data when over 80% of will never be accessed again.

RD: How much data do you recommend as a best practice to be injected in the live Exchange system and how much do you leave to be accessed through the archive?
SB: This depends on the client. Some clients need more data to be injected than others. For the most part, we find a really nice number to be 90 days. In other words, inject 3 months’ worth of email into the new email system. The re-injecting of data is pretty clean and covers what the majority of companies search for. Very rarely do people need to access messages past 90 days, unless it’s some kind of discovery or internal audit requirement.

In the case of the school district migration we’re currently working on, they’ve requested that 12 months’ worth of data be injected in the new system; basically, they want to keep the information for the entire school year. This is a specific requirement that has to do with how teachers handle homeworks and other assignments, as well as grade assessments.

RD: So to sum up, when you advise clients on migrations, you’re approaching it as an email management consolidation project with a broader scope for the same investment.
SB: We are recommending M+Archive not only as a migration tool investment, but as a piece of software that will enable our clients to migrate and have an archiving solution in place. This is the strategy we are offering to our clients because we believe it bests meets their immediate needs while addressing them from a cost-effective perspective.

]]>
Thu, 23 Sep 2010 00:00:00 GMT 80ccbe5a-b7e0-4504-ac78-1653c40ce28c
<![CDATA[Messaging Architects Offers Its ePolicy Workshop at a Sizeable Non-profit Organization]]> The customer had previously purchased Messaging Architects’ M+Archive product because experience from a recent lawsuit had proved they needed a reliable way to preserve, manage and search email. However, the customer had been unable to implement the product due to a lack of a policy on email retention and destruction.

Earlier internal discussions on how to draft a policy had made little progress, and the IT department worried that nothing was in progress to make a policy come into existence. The IT department knew that it possessed no authority to impose a policy on their own. They needed a breakthrough.

The IT department scheduled Messaging Architect’s ePolicy workshop which I have been leading for over 2 years. When the workshop was announced, the IT department was able to ensure the participation of the key stakeholders: Legal and HR.

Compared to other workshops, this one was intimate, involving only a lawyer, an HR representative and two IT representatives. From the start, I engaged with the customer’s lawyer in a professional dialog about what the big issues are and what I have seen other organizations do. This led into a spirited, freeform discussion among all participants about the many places where copies of emails can reside, the challenges involved in confirming that all copies of any given email are ever destroyed, and the numerous new message types that people are using in business, including text messages and social networking.

Eventually, the customer’s lawyer admitted our discussion had changed his thinking. Electronic records behave differently from what he thought. This change of position became the foundation upon which the workshop eventually drafted a policy.

Two participants in the workshop said they wanted to hear about case examples from other enterprises and to examine the policy template I had brought. They debated which kinds of records needed to be kept for longer and which for shorter periods. They knew from experience certain records need very long retention periods.

As the day progressed, common ground began to emerge of which I kept track on a flip chart. By the end of the day, the group seemed to have direction. Using the agreed points from the flip chart, I drafted a sample policy for their review the next morning.

On day two of the workshop, the participants asked the Messaging Architects' systems engineer technical questions on how specific policy objectives could be met with M+Archive, which they already owned. Then the group reviewed the draft policy, followed by more discussion and changes.

Something surfaced in this workshop that had not surfaced before: a thorough conversation about documents on the customer’s document management system. The group decided the retention policy should be expanded to cover managed documents in addition to email.

The group believed it had reached consensus on policy. I made the changes to the draft and provided the revised policy to the customer’s lawyer. At the group's request, I also devoted some time discussing two optional sections from the ePolicy curriculum on how to implement legal holds and promote attorney confidentiality and on data security law.

As the workshop concluded, the participants expressed great satisfaction with the process and the outcome.

]]>
Tue, 03 Aug 2010 00:00:00 GMT 14a67238-4fd6-415f-8049-3bf90cfda34e
<![CDATA[The Benefits of Unified Messaging]]> As part of a recent client interaction and whiteboarding session, I was asked to express my views about the benefits that Unified Messaging might deliver in terms of enhanced collaboration. In my reply, I acknowledged that we are well into the era of Unified Messaging (UM) as close to 1/3 of enterprises are in the process of deploying infrastructure to unite telephone and email systems. This trend started off as a way to lower operational costs and deploy IP telephony, but has now grown far beyond its original scope. The future of Unified Messaging will enable an entirely new class of rich and interactive collaboration as well as much smarter infrastructure management. High definition video is certainly only a few steps behind voice as the next logical media-stream we will add to our networks.

One of the changes we will soon see to workgroup collaboration is what we call “Asymmetrical Messaging” whereby a voicemail may be replied to with an email (and vice-versa), or a message instantly converted to text by speech recognition agents. This text could then be automatically appended to a client’s record for future reference. These new types of interactions will dramatically enhance our collaboration experiences since voice is a much richer communication medium than plain text.

Research (and human experience) clearly demonstrates that it is far easier for us to detect emotions and intent from listening than from reading. However, it is usually much easier and faster to scan through a long text (speed-read) to get a feel for a situation. Trying to “speed-listen” to a lengthy recorded conversation would not be effective and might give most users bad headaches. UM will enable us to choose the media best suited for the task at hand.

The integration of calendaring and voice systems will also enable us to conduct more effective meetings – by simply inviting a conference bridge to a meeting, we can have the bridge agent record the entire meeting and automatically send a link of the conversation to all attendees. Smart voice tags can be used to identify action items, tasks and due dates, and automatically update our calendars or project plans.

The ability to consult our calendars and interactively book meetings while on a phone call will soon be as simple as conferencing in our calendar agent who will be able to reply to spoken commands such as “When am I free next week?” The same will go for address book lookups – “Call John Smith on his mobile” and smart reminders – “SMS me at 4 PM to remind me of my dentist appointment.” All these interactions will be logged in our collaboration systems for consultation and review. It will soon be easy for a user to request a unified composite view of the communications he has had in the last 60 days with an individual, whether via phone, email or other social networks.

Another exciting possibility is Intelligent Attachments & Smart Delivery. Intelligent Attachments are documents that a user can have emailed out by simply requesting them from the phone server. Smart Delivery is the ability to request that an email message be forwarded as a synthetic voice message, or request that a voice message be forwarded to an email account, in effect choosing the way a user wishes to interact with the content.

These applications and more we have not yet imagined will augment our capacity to deal with complex projects, shifting schedules and distributed virtual teams. Our productivity will be enhanced and soon we will not be able to remember how we functioned without these applications at our command. However, they will also need to be well designed against abuse and hacks so that users feel confident using them. The management capabilities will need to be fully integrated with existing directory services and identity management platforms for fast provisioning and de-provisioning. Of course these new capabilities will require copious amounts of additional processing and storage, but this will be a small price to pay for the enhanced collaboration and productivity they will enable.

 

 

]]>
Fri, 30 Jul 2010 00:00:00 GMT f392fe60-68d2-4e3d-9ca8-98d0bcf0a32d
<![CDATA[Successful IT Projects: Getting What You Want]]> A few days ago, I posted an article in our blog that was written by the CEO of Messaging Architects, Pierre Chamberland, on how CFOs and CIOs can help to minimize the risks associated with major IT projects by understanding the importance of project management. Entitled The 10.5 Essential Steps of Successful IT Projects, the article created a lot of buzz around the water cooler and led one of our Account Managers to forward me the following article as a potential companion piece to Pierre’s earlier submission. The article, entitled Successful IT Projects: Getting What You Want, includes a few more steps to help you make the most of your IT budget. It is reprinted below with permission from the author, James Flowers.

Successful IT Projects: Getting What You Want

 

Media reports are awash with stories of information technology systems and infrastructure projects gone wrong and cost overruns. This creates an impression that significant IT projects are 'risky', particularly in tough economic times where the emphasis is for IT departments to make the most of their information technology budgets.    

Whilst the success of an IT project can never be 'guaranteed', particularly if it is a complex project, the risks of failure can be greatly reduced, and acquirer's ability to mitigate the consequences of failure greatly enhanced, if that acquirer has satisfied each of the following steps:

1. Scoping the project before approaching the market

If an organisation does not have a clear sense of the outcomes it requires (functionally and otherwise), then inevitably it places greater reliance on the supplier to provide or deliver those outcomes. In such a case, it should never be assumed that the supplier's interests and objectives will be aligned with those of your organisation. A supplier will seek to supply a solution that meets its understanding of the requirements but also maximises the returns to it.

Further, if the customer is relying on the supplier's expertise not only to supply the solution/system, but also to determine what the solution or system should be, it becomes harder for the customer to manage project scope and costs.

The customer should therefore take time to determine what it requires, what is available, and whether the available solution(s) and systems are compatible with its requirements. If your organisation does not have that expertise internally, it could engage a consultant to assist with this process, or undertake a 'request for information' process – a precursor to a request for tender or proposal in which the customer seeks information about possible solutions or systems from the market.

2. Due diligence of suppliers – will the supplier see it through?

Whilst price and technical compliance are clearly important elements in evaluating a proposal or offer from a supplier, the history of IT projects is littered with examples of suppliers offering outstanding solutions or pricing that are too good to be true. The result is that such suppliers are not able to deliver on the solution, either because their proposals are not matched by their capabilities, or they lack financial substance.

Customers need to insist that prospective suppliers demonstrate both technical capability – regarding expertise and depth of resources – and solvency. To the extent that there is doubt on either front, customers should either steer clear of the suppliers, or require that those suppliers produce financial and/or performance guarantees. However customers must then ensure that the guarantor(s) has the capability and solvency that the supplier may lack.

3. Avoiding standard supplier contracts

Increasingly, many suppliers – particularly the large suppliers – are insisting that they will supply goods and/or services only subject to their standard supplier contracts. This may occur even where the supplier is responding to a request for tender.

Not surprisingly, standard supply contracts contain terms that are geared to maximise the supplier's position, usually at the cost of legitimate protections and rights for the customer. However, more fundamentally, if a customer accepts a standard supplier contract, it also accepts that its project will proceed in a manner that is largely mandated by the supplier, and is subject to the supplier's processes.

That may not be what the customer requires. For example, it may wish to ensure that the project is subject to its own project management and governance processes, and it may want to tie payment of fees to receipt of actual outcomes and benefits.

Therefore, at best, customers should challenge the notion that it must engage the supplier under the supplier's own terms. Naturally, if customers want to avoid supplier terms, they will need to develop their own template agreements.


4. Incorporating appropriate governance, reporting and oversight processes

 

A common feature in projects that 'come off the rails' is that problems or delays identified by one of the parties are not raised with the other party, then discussed and actioned in a forum that enables quick and effective decisions to be made about how to address that problem or delay(s). In many projects – particularly more complex projects – the prospect of unforseen matters and delays is relatively high.

However in the absence of an effective reporting, oversight and governance process, there is a real possibility that one party – usually the customer – will be kept in the dark about the existence of problems and delays, and may only find out about them at a point where the project is delayed, or where the costs have gone well beyond budget.

Appropriate governance will not of itself ensure that projects proceed smoothly, but transparency and effective communication will enable both parties to be more proactive as to how they address problems and delays. IT project contracts should therefore incorporate measures such as mandatory periodic meetings of project principals, and periodic reporting of progress and issues (which also tracks action taken on past issues raised). In projects of strategic importance to the customer, measures such as a governance committee, comprised not just of project principals but also other stakeholders of the party, would be worthwhile.

5. Tying payment to achievement of required outcomes and timeframes

For an organisation that has embarked on a business-critical or expensive IT project, there may be two nightmare scenarios.

It could be that the organisation is either contractually bound to continue paying the supplier for the work it is undertaking (even though the supplier is not delivering the contracted outcomes), or that the organisation has paid the supplier all of the fees and charges due only to discover that the supplier has not yet completed the project. Aside from the fact that the project is not delivered, an organisation in that position has largely ceded all of its commercial leverage: it either has to persevere with its supplier (at additional cost), or cut its losses and potentially have to start again.

From the customer's perspective, the preferable arrangement for payment of fees is that payment of particular amounts is tied to the supplier's achievement of milestones and/or delivery of required outcomes. This is not to say that the supplier should not receive any payment until the project is completed, but that the project should be divided into milestones, with instalments of the overall amount payable then tied to the supplier's achievement of those milestones. The amount received should depend on the relative importance of each milestone.

Nevertheless, the best form of arrangement is one where the bulk of the overall amount payable (at least 50% to 60%) is paid when the project is completed. Instalment payment arrangements do not provide the supplier with much incentive to complete if it has already received 90% of its payment.

6. Proactive contract enforcement

A well-drafted contract will give the customer a range of rights and remedies to address the supplier's failure to comply with that contract. If a customer feels that its proposed contract does not offer it the kind or range of rights or remedies that it would expect, then it should not sign it.

Assuming that the customer has all the contractual 'tools' at its disposal, the question will be which one of those rights it should use in particular cases. Regrettably, many customers feel that exercising any rights given to them to enforce their contract will in some way be a precursor to ending that contract, and so they do nothing. Once again, such an approach cedes commercial leverage to the supplier.

Issuing a notice of default, disputing an invoice and invoking requirements for a party to provide a guarantee are appropriate and usual actions for a customer to take (assuming that it has a right to do so). Customers should not feel that taking such action is a sign of failure. Rather, it should be seen as a proactive attempt by the customer to rectify problems, and a reminder to the supplier that legal obligations must be satisfied, or it will face consequences in the form of financial compensation or other remedies.

If your organisation is contemplating an IT project, it will be the one that has to live with the outcome of that project. It should therefore not be shy about requiring a contract and contracting process that ensures that the outcome aligns with its objectives.

 

 


]]>
Fri, 23 Jul 2010 00:00:00 GMT 7d1f04fb-dfdd-490a-962c-540b7d5eaebf
<![CDATA[Where is Greg?]]> GWGuru Greg SmithWhere is Greg Smith? This has been the leitmotif of several emails I received ever since we changed the format of our presence at Novell BrainShare this year by having one giant Brewfest meet-and-greet. It doesn't mean that Greg's not around…

Truth be told, Greg has been busy. With what, you ask? Here's a list of some of the things he's been involved this year: Greg has supervised tons of email archiving deployments, done half a dozen or so GroupWise audits, and assisted a few organizations in their legal discovery quests. At present, he's preparing to speak at the SANS Institute e-Records Summit on "Finding Email Records in the Real World." Not to mention the tidbits of advice on email retention and compliance he has been giving us internally - so we are really knowledgeable in our interactions with clients.

So, you see, Greg has really been awfully busy. However, after a lot of nagging supported by your adoring emails, we did manage to get him to agree to make a live Webex appearance this coming week.

On July 28, Greg will talk about email storage optimization and some of the innovative options you have to tackle this pesky issue. He will share real-life stories from the trenches, the problems our clients face with dealing with storage bloat and why he recommends M+SecureStore to solve them. It's a must-attend event, so reserve your spot now.

Greg Smith is here and now's the time have him advise you on your challenges.

]]>
Wed, 21 Jul 2010 00:00:00 GMT 9c407036-d891-4eda-aebf-e303603d1556
<![CDATA[ePolicy Case Study: Stakeholders Work Together to Draft Email Policy]]> Messaging Architects has held its ePolicy workshop in numerous, diverse organizations throughout 2009 and 2010.  One such organization was a sizable state government agency, which had approximately 5000 email users. One year prior, the agency had purchased Messaging Architects' M+Archive product, but it had not implemented it beyond the pilot stage because the agency had not settled on an email retention policy. Although stakeholders within the agency had discussed policy, they had not reached consensus.

With a view to breaking the logjam, the agency’s CIO invited Messaging Architects to bring its ePolicy workshop to the agency. Believing that she had not been able to get sufficient attention from the Legal Department, the CIO hoped that the workshop – led by an outside lawyer – would motivate more engagement by Legal.

Although the workshop is normally scheduled for two days, the CIO preferred to hold the workshop over only one day. Her objective was not really to have a policy drafted by the end of the workshop.  Instead, it was to break the logjam, get the stakeholders to work together, and to propel them toward final drafting of a policy.

Participants in the workshop expressed some strong, contradictory opinions. One opinion emphasized that each employee should (consistent with statewide guidelines) have responsibility to review each email, delete those that are not official records, and file the others into specified categories. Another opinion stressed that employees do not have the time and will not take the time to review emails in this way; this opinion argued for generous retention of email in an archive system, where it can be found through searching rather than through categorization.

Messaging Architects was represented in the workshop by attorney Benjamin Wright and system engineer Michael Dybala. Their primary role was to facilitate an orderly, informed discussion on e-records law, experiences in other enterprises, and the technical functions of M+Archive.

Agency stakeholders participating in the workshop included representatives from IT, Legal, Operations and Records Management.

After spirited debate, compromises emerged. The group agreed on an outline for drafting policy. At the end of the day, the workshop closed with a commitment between the IT department and the Legal Department to work together to draft that policy in an expeditious fashion.

]]>
Wed, 21 Jul 2010 00:00:00 GMT 11309909-27b4-49e9-8a70-e427147bc81d
<![CDATA[Email Acceptable Use and Retention Policies - Keep it Simple]]> I was recently involved in a consultation session with a Client who was looking to consolidate his email infrastructure from a decentralized model with many servers and domains in 10+ countries, to a centralized model where all the servers would be located in a single country. The stakeholders wanted to understand what shifts this would cause to their regulatory obligations and how they should consider various deployment options in this context.

Here is a summary of our discussion:

There are no hard int'l rules that have been tested to my knowledge, at least not formally in court with regard to moving electronic records around. In fact there is 2 contexts to your query: i) moving the records around and then what is the optimum email storage structure to minimize risk, and ii) how does discovery and rules regarding official corporate records work across multiple geos.

Regarding point i:

What I have read about and also discussed with clients is the following 2 approaches:

[1] Consolidate all servers and content in new geo, and have this geo's rules & regulations apply to all content (historical and future). A smart twist on this is to set an Archive anchor point at the day of consolidation, and manage historical (now archived) content as per old policies set while server was in original geo, and all new content managed according to regulatory frameworks in new geo.

[2] Consolidate all servers & content but continue to manage content as if it was virtually still in geo of original creation. Under this scenario, content created in France (sent or received) would be stored in Canada but not discoverable under Canadian laws or regulations, only under French ones. Of course from a technical perspective, I would recommend encryption on the message store, with the encryption keys being kept in the geo where the data was originally created.

Depending on the Risk Management strategy of the company and the value of the data, an option to strongly consider would be to keep the smallest minimum timeframe of international email on production servers (max 90 days). Everything older would be moved to Archival storage. Search indexes (which are not the messages or attachments) can be stored in Canada since these are not the actual record and as such is not discoverable. The archived actual messages are stored in an Object Storage system (like M+Securestore) with an off-site instant mirror.

So in essence there is a primary write of the message to a device here, and then an immediate replication to a device in the geo of origin, followed by the deletion of the original write. In this way it can be clearly demonstrated that the message was in fact never stored in Canada but simply "in transit" to its long-term storage location in the originating geo. If they wanted to also keep a copy of the message locally as a back-up of the remote location, this is both possible and OK. The local copy (Canada) is being made solely for disaster recovery, it cannot be discoverable - only the original record can be requested and it would sit outside of Canada.

Under civil law and copyright interpretation, the fact of where the digital content resides (stored as bits) can be disconnected from the regulatory obligations, or lack thereof attached to it. For example, if a contract is created, printed and signed in France, then an scanned copy is sent via email, and the email is stored in Canada - nothing about Canadian discovery regulation or laws will apply to this email or attachment.

Another example is e-commerce web sites that are hosted in other countries - the authorities of the hosting country does not have the right to interfere unless the complaint originates from a matter brought to a Canadian court, and then will likely only be allowed to request discovery for content created by Canadian workers.

Under criminal law, (think child porn) this construct does not apply and the country where the data is stored has full rights to exercise legal intervention on its soil and courts will not hesitate to provide the required search warrants or subpoenas.

Keep it Simple....

My advice is that simplicity dictates that a multi-national org should try to have a single retention/discovery policy that meets the baseline requirements of all geos, and then manage the occasional exceptions. If one thinks of a corporate Code of Ethics, there is usually only a single version.

Regarding point ii - it gets pretty messy, pretty fast:

Let us set the stage; a Canadian company, with a French wholly-owned subsidiary where email is considered private and requires a court order to discover, employing a German resident contractor working on a project for a Japanese client. The Japanese client decides to claim negligence on the part of the German contractor and sue the Canadian company in a Japanese court for damages and breach of contract.

Part of the lawsuit involves requesting access to encrypted email messages on the German Contractor's laptop that were circulated between the French and German, and that are believed to exist archived (in cleartext) on the corporate email servers in Canada.

What can be discovered? Who can decide who needs to produce what? How much will be spent in external legal fees? Experience to date shows that there is no cut & dried answer, there is no "good & perfect" response, only a bunch of "it depends" - and alot of the "it depends" has to do with the amount of money at stake.

So how can a company mitigate against these types of risks? There is really only 1 way - via a clear and well implemented Acceptable Use and Retention Policy that will ask exactly these types of questions and set the tone for the scope of involvement and technology deployment required to match this scope. Letting courts or lawyers decide about matters of internal policy is usually not a good choice. Being well prepared and having predetermined answers put the organization in a position to respond as needed, and in a matter that is consistent with its best interests and the ever-evolving legal & regulatory framework.

Best,

--Pierre 

]]>
Wed, 14 Jul 2010 00:00:00 GMT 8c9a2337-800e-4fc3-9ffa-dc26310a8e20
<![CDATA[Personal Email Archives: Do They Amount To IT Malpractice?]]> The amount of data within your messaging environment is constantly expanding as email communication continues to increase, replacing other types of communication. More messages each day, and message sizes that balloon due to large and numerous attachments. According to Gartner, the average number of email messages per user, per day has increased to over 130 and the average message size is over 100 KB. Many users will try to preserve between 1 and 2 GB of email data per year. In large organizations, this adds up to alarming figures for which email servers were never really designed.

In many cases, the response from IT has been to deploy complex, costly and fragmented email infrastructures just to keep up with the storage bloat. To further combat this growth, many organizations have also enforced stringent deletion rules such as a 90-day retention policy. The behavioral impact resulting from these policies is often the premature deletion of potential business records or the use of personal archives to maintain data beyond the stated periods.

When personal archiving is used, it moves data off the organization’s production servers and storage to a system-defined location that may include the user’s local machine. The data is then no longer accessible from the corporate messaging system, resulting in idiosyncratic and highly-interpreted data retention, based on end users’ perceptions of what should be preserved. Trying to recover messages as part of an internal audit or litigation rapidly becomes a costly nightmare. All to often data simply cannot be found, or the organization runs the risk of losing critical information when PCs or laptops are refreshed.

In addition, personal archives are not storage efficient. Since they re-create copies of all attachments in each personal archive, data sizes are usually between double and triple of the original size. The increased data, combined with the inability to run centralized searches, adds stress to most discovery requests, which are typically on tight timeframes to begin with. Collecting, processing, reviewing, analyzing, and producing large sets of disparate personal archives for external parties becomes an expensive and error prone exercise in redundancy.working effectively with vendors, and developing trust with department stakeholders.

As part of most recent litigations, an organization’s policy definition as well as the consistency of enforcement of this policy is reviewed so as to identify alignment with legal requirements. When daily practices are found to be inconsistent with policies or compliance frameworks, or if relevant data is discovered on other storage locations, it rapidly opens the door to in-depth questioning of what the organization may be trying to hide, or if legal holds are being adequately respected. Attorneys are now well versed in eDiscovery and have very good understanding of the technology at play. Their objective will be to cast a doubt on the preservation practices and the completeness of the data set provided – which if successful, can make the difference between winning a fair settlement and losing a case on technical deficiencies.

This risk is compounded by the nature of the legal hold process itself. Was the hold applied when “reasonably anticipated” and were appropriate actions taken to preserve “all forms” of relevant information, which may include requests to include personal archives. Personal archives represent a subset of e-mail that either was selectively or automatically maintained but is not necessarily captured at the time a legal hold is initiated.

Since personal archives effectively remove data from the corporate messaging system it may well also create questions about the effectiveness of the organization’s legal hold process. If personal archives are part of the ediscovery scope, this data will need to be handled appropriately. This may be stating the obvious but in many cases the consequences and impact are not considered, and as a result fall well outside the organization’s acceptable level of risk tolerance. The trend in litigation indicates a broadening definition of what is a record and what is considered relevant and discoverable. As with backup tapes, which at one point were rarely requested as “in scope,” they are now routinely considered a standard request.

Notwithstanding the philosophical debate which has been ongoing at the academic level, legal hold for email means really preserving all data from the point when “reasonably anticipated.” Thus it should include personal archives if the organization allows for this functionality to exist. Under those assumptions, the email data may be considered potential evidence and even unwillful destruction could be considered spoliation.

 

Things to think about:

 

  1. Can you defend the effectiveness of your legal hold process?
  2. If personal archives are requested, do you have a process to enable production?
  3. For every “Send”, there is a “Receive,” What might opposing counsel have that you are not aware of?
  4. Are you capable of determining if you should settle before having invested too much time.
  5. Does your current setup provide the tools for effective legal strategy planning?

Click here to download a copy of Personal Email Archives: Do They Amount To IT Malpractice?

 

 

]]>
Mon, 12 Jul 2010 00:00:00 GMT 6d43d395-5f03-4c51-88f7-4bfb88ff409c
<![CDATA[The 10.5 Essential Steps of Successful IT Projects]]> Major IT projects are risky for any organization. It is the CIO’s responsibility to minimize the risk by ensuring that projects are managed effectively. This begins with a process framework encompassing these 10.5 essential steps.

1.  Make feasibility evaluations obligatory. Too often haste to get approval and begin a project causes management to pay minimal attention to this step, leading to unexpected problems. A required project-feasibility assessment should be performed for all IT projects. Although it may slow the approval process, it will help avert project failure. This analysis should include a list of preliminary architecture and design specifications and a project-management plan proposal, which enumerates assumptions, required resources, constraints and timelines.

2.  Designate a Project Sponsor who will declare clear project objectives. A clearly-identified project sponsor (PS) should be responsible for the success and overall project implementation. The PS should be charged with monitoring progress constantly and resolving issues that can impede rapid progress. The PS is supported by an executive group or committee that can serve as a forum for problem solving and escalated issues.

3.  Appoint a full-time Project Manager (PM). One individual with experience with similar projects should oversee the day-to-day management, execution, and delivery of the project.

Before going ahead with the IT project, the proposed timeline, cost and scope should be clearly defined and accepted by all potential participants. Failure to ensure that all stakeholders are in agreement can lead to confusion, wasted effort, needless duplication, and ultimately project failure.

4.  Give the Project Team real authority. The team should include interdisciplinary senior staff with sufficient analytical, technical, and project-related expertise to guide the project to a successful completion. The team should have access to enterprise resources needed to ensure the project conforms to enterprise standards and should have sufficient authority to control the activities and resources necessary to complete deliverables within the set time frame.

5.  Create a detailed Project Plan. A comprehensive Project Plan should be developed as a guide to all major activities such as project deliverables, timeline, roles of team members, key risks, and approval processes. The document should incorporate all formal written agreements with external and internal suppliers, resource owners, and end-users regarding their roles in the project.

6.  Secure committed staff resources. The PM should obtain formal written commitments from department managers to allocate time for their staff to work on the project; similarly, commitments need to be obtained from all assigned staff. Managers need to plan ahead to free up designated staff and resources, while continuing to meet daily operational requirements.

7.  Establish performance measures and report progress daily. To assess project performance, a specific set of performance indicators should be identified. Performance should be tracked at the task level by team leads and summaries presented to the PM, who in turn, will report progress to the PS. Discrepancies between expectations and actual performance should be discussed so contingency plans can be made as soon as possible.

8.  Take corrective action sooner rather than later. Resolve any performance variances quickly and decisively. If the problem cannot be eliminated, such as changes to budget, schedule, and deliverables, steps should be taken to mitigate negative effects by reassigning team members to provide additional support in areas where it is needed.

9.  Implement formal change-control mechanisms. All changes should be documented and incorporated into the Project Plan so that everyone knows when and why a change was made. Such documentation should include the date the change was made and its effect on the plan. Major changes that raise costs, substantially delay completion or redefine major deliverables should require written approval from the Steering Committee.

10.  Proactively manage risk. IT projects typically involve a number of significant risks and controversial issues that can prevent the team from moving ahead. Consistent and pro-active communication among project participants, stakeholders and end-users is required to mitigate against such internal risks. The PM should have a formal escalation process if serious roadblocks are encountered.

And last but certainly not least…

10.5.  Celebrate success. Each project milestone should be celebrated and communicated organization-wide to foster team coherence and promote values that are intrinsic to high performance.

Click here to download the full version of The 10.5 Essential Steps for Successful IT Projects.

 

 

]]>
Wed, 07 Jul 2010 00:00:00 GMT f80db82f-525c-4cb7-a237-babd64541789
<![CDATA[Case Study: Drafting a Policy on Email Records Management]]> This case study describes Messaging Architects' recent delivery of an ePolicy Workshop in the offices of an enterprise client. The client is a large, privately-owned construction company. Its employees are spread widely across many locations. Knowing that the company needed a policy on email records management, the IT department discovered that Messaging Architects offers policy development services. The client had not previously done business with Messaging Architects.

The client engaged Messaging Architects to conduct an in-house workshop, with Texas attorney Benjamin Wright as workshop leader. A few days before the workshop started, Mr. Wright spoke with the client by telephone so he could customize the ePolicy Workshop to meet the client’s unique needs.  

Mr. Wright came to the workshop with a prepared agenda, but quickly found that the event took a life of its own, according to the interests and needs of the people in attendance. For the first two hours, the client’s employees in attendance were only from IT. They interacted with Mr. Wright and Messaging Architects representative Osman Baig to understand the issues as they uniquely apply to their enterprise. They also wanted to learn what other organizations are doing on email record retention.  

The group then expanded to include the client’s general counsel, chief financial officer and other officers. The group considered litigation issues and the costs of retaining email. After lively debate, consensus began to emerge around some principles.

A core group of workshop participants then undertook to start drafting language. On the morning of day two of the workshop, an agreed draft policy emerged. The client’s CIO had what he needed. With this policy in hand, a select team, including the CIO and Mr. Wright, presented a briefing to the client’s chief executive officer.

]]>
Mon, 05 Jul 2010 00:00:00 GMT 5cbf5dec-c45e-4a43-aadd-253a01197743
<![CDATA[A Word from Our Partners: Scott Kunau from IGTG - Part 2]]> Last week, I published the first part of my recent chat with Scott Kunau of the Innovative Global Technology Group (IGTG) on what sets their company apart and makes them such a hit with their clients. In the second part, Scott talks about his methodology to email archiving and migrations, some of the real-life challenges such projects involve, and why he recommends M+Archive to overcome them.

RD: In your experience what’s the primary reason for migrations away from GroupWise?
SK: Half the time, the GroupWise migrations we’ve seen happen have to do with some non-technical, purely political reason. In the other half of the cases, there are serious technical reasons having to do with replacing a messaging platform that doesn’t support a key company application easily.

Another major problem is the lack of Novell talent in the younger generation of IT technicians. They have little or no foundation in Novell technology and are usually unwilling to learn. We have an extremely talented young computer engineer on our team that we are mentoring in Novell technology. However, he is the exception to the rule, as the majority of younger IT technicians and engineers don't see the value in learning about Novell technology and that gives us an edge. In a way, this is one of the things that sets our company apart: our strong technology foundations make learning complex technology much easier for our clients. Plus, we're not biased about technology solutions.

But we make sure our clients are informed about a migration project they undertake. It is our job to ask the tough questions about cost, complexity, and overhead. We bring up all the things they need to consider before embarking on such a project. And we always make sure they fully understand the planning stage, which is more important than the implementation stage.

RD: Does this imply that planning takes a long time?
SK: It really depends on the internal policies of the organization. Some companies want extensive preparation and are ready to invest heavily in having engineers in-house to plan, document, and test the project management plan for weeks on end.

We offer a more efficient and cost effective solution. We set up a small fully virtualized pilot environment, work through the issues we encounter, do small test groups making sure that everything coexists together. When everybody is satisfied, we go ahead and schedule a specific date or period of time when the conversion takes place. In some cases, I believe we've saved our customers thousands of dollars with this approach.

RD: What can you say about your relationship with Messaging Architects?
SK: I think that we share are a lot of common values that make this a mutually beneficial partnership. We are both smaller and flexible organizations that offer solutions to make our clients successful, while also equipping them with the tools and knowledge to better manage their IT infrastructures.

We have had a lot of success implementing M+Archive at client sites, whether to address email archiving and eDiscovery needs or in cases of an email migration. M+Archive allows us to handle email migrations in such a way that only the necessary amount of data is migrated to the new email system, while the bulk remains in an archive repository that is fully accessible to the end users. The technology allows us to handle email migrations in a way that doesn't make it the "project from hell" but allows us to perform 90% of the work without impacting the end users. When all the prep work is done, we can switch them over to the new system quite painlessly.

Clients also appreciate the fact their investment in M+Archive continues to bring them value after they switch to Exchange. Recently, we helped a client upgrade to the latest version of M+Archive from the previous version which they were using on GroupWise. After they migrated to Exchange, we converted their GroupWise XML archive to and Exchange XML archive and they continued to use M+Archive on the new Exchange system.

I think there a lot of opportunities for Messaging Architects' technology and IGTG's expertise.

]]>
Sun, 20 Jun 2010 00:00:00 GMT eee06ad1-6dac-4004-ac5b-21faf32cb3ee
<![CDATA[A Word from Our Partners: Scott Kunau from IGTG - Part 1]]> In March, I wrote about the advantages being a small company when it comes to providing superior service to our customers. Recently, I had the opportunity to catch Scott Kunau of the Innovative Global Technology Group (IGTG) between projects for an informative chat about the company, their clients' most pressing IT needs, and the partnership with Messaging Architects. One of the things that makes the partnership work so well is the fact that IGTG is a small, hands-on company with comprehensive expertise in Novell, Microsoft and Linux environments that follows a very simple philosophy: total commitment to client satisfaction by outstanding performance and professionalism. Here's the first part of what Scott had to say...

Founded in 2006, Innovative Global Technology Group (IGTG) helps organizations of all sizes and industries find the right technology solutions in networking, messaging, virtualization, and storage. The two founders, Scott Kunau and Sam Lohrer, who between themselves bring over 30 years of technology experience, joined forces following a clear and simple philosophy: total commitment to client satisfaction by outstanding performance and professionalism.

What makes IGTG unique is their straightforward, tangible, measurable solutions without the fluff, spin, or unnecessary steps sometimes employed by other consulting firms. Their only concern is making sure the solution they offer a client is customized to their needs, exceeding only their expectations, not their budget or the time needed to complete the project. They also empower clients with knowledge transfer to help their IT staff troubleshoot various issues with ease.

What sets IGTG apart from other systems integrators and technology consultants is their extensive skills and hands-on expertise in Novell, Microsoft and Linux environments.

RD: What's your approach working with clients?
SK: One of the things that differentiates us is the fact that we work with clients in a comprehensive way: in addition to the software implementation, we help them with the planning stage, provide training following the deployment, and suggest best practices on managing the solution. We are also able to adapt depending on organizations' budgets, infrastructures, and deployment schedules.

RD: That’s a bit different from the typical approach of professional services, isn’t it?
SK: You’re absolutely right. Many IT consulting firms go into a company, do the project on a schedule they define and leave, perhaps providing documentation, perhaps not. When we work with a client, we insist on providing knowledge transfer and training during and after the deployment as part of the total solution we offer. We want our clients to be as self-reliant as possible while knowing that we are right behind them if they need us.

RD: I agree with you there - one of the strongest complaints we get from clients is the lack of knowledge transfer from consultants. In your case, it's actually part of your professional services engagement...
SK: Here’s an example with a recent email migration from GroupWise to Exchange that we did using M+Archive. The entire new email environment was set up by their IT department in-house. I didn’t physically run any of the installations, but I explained each stage of the project and discussed possible problems they could run into. The internal IT staff was implementing the steps. The result was, they came out of the migration knowing exactly what they had and how to manage it. This way, they are able to do future upgrades themselves and deal with potential troubleshooting. It's also a more cost effective way of using our services.

RD: You mentioned your clients highly value your flexibility. Can you elaborate on that?
SK: A big consulting company comes in, dictates the implementation schedule and then they walk away. Often, the client doesn’t know what was done, there’s little or no documentation, there’s no knowledge transfer and training. The end result is, now the client is married to the consulting company for any problem-solving, upgrades, fixes, additional deployments and so forth, which is their end game.

We work with clients in a way that best suits them. Our clients choose to work with us; they are not stuck with us because they have no other alternatives. For instance, some clients rely on their own expertise for many projects. However, when it comes to GroupWise-related matters, OES, or other Novell products, they turn to us because they know we have the Novell experience they don’t. Just recently, a new client selected us over another integrator because we were willing to approach the IT projects they needed assistance on their terms.

Or another example: a large company with thousands of users needed a GroupWise stabilization, virtualization, and clustering project. Now, I could have completed the entire project in about six to eight weeks, perhaps even less. But the client wasn’t interested in this blitz scenario. They wanted to go slowly, test things thoroughly in a virtual lab, implement changes only in off-hours when everyone was out of the system, schedule changes and upgrades well in advance, get full approval, etc. So the project ended up taking significantly longer, almost eight months. The point is, we are flexible enough to take as much time as necessary.

RD: It seems that while emotionally you have a strong allegiance to Novell products, which you regard highly, you are equally knowledgeable and at ease with Microsoft technologies.
SK: Ultimately, it’s all about the clients and what they are using. That’s why we make sure to stay on top of things, whether we are talking about Novell, Linux, or Microsoft. We have to be ready. And while this may seem likes a daunting task, it isn’t that difficult once you have a strong foundation and the ability to be a quick study. That's why we are able to execute complex and multi-stage projects, such as software upgrades, email migrations, archiving, clustering, data recovery, and compliance without being concerned about the particular operating system or messaging platform.

In part 2 of Scott's interview, he discusses why he recommends M+Archive to his numerous clients in healthcare, government, and education.

]]>
Thu, 17 Jun 2010 00:00:00 GMT 58dd1756-4764-40e9-bfd1-d9df733b9031
<![CDATA[Another Reminder Why Email Archiving is Important... ]]> Every once in a while, a story starts making headlines that reminds me why I do what I do (and why email archiving is important). This week’s headline grabber is all the hoopla surrounding U.S. Supreme Court Nominee Elena Kagan. Controversial for a number of reasons, if Kagan is confirmed by the Senate, she will be the first Supreme Court Justice in nearly four decades without any prior experience as a federal or state judge, which means she has not created a paper trail of court opinions typically used to assess a nominee's ideology.

However, she did serve as a Clinton adviser in the 1990s, around the same time that the Clinton administration implemented an email archiving strategy to archive email from its Lotus-Notes-based email system. At the time, the Clinton administration implemented the email archiving solution in response to a 1993 court decision that stated that that the president has an obligation to ensure that the emails of senior officials are preserved.

(The Bush Administration later replaced the Lotus Notes-based email system used by Clinton with Outlook and Exchange which wasn’t compatible with the old archiving system, and resulted in the loss of millions of email records, which were later found... but perhaps that’s the subject of another post.)

Over the next few weeks, the Clinton library, run by the National Archives, is expected to release every piece of email that Kagan sent and received during her tenure as a Clinton adviser, approximately 79,000 pages of email in all, to help establish her credibility as a nominee.

If Kagan wins the nomination this summer, she probably has a lot of people to thank. If I were her, I’d add Bill Clinton and his IT team to that list.

]]>
Tue, 01 Jun 2010 00:00:00 GMT 867ca237-0e91-4758-9644-2a700410ff27
<![CDATA[Why Your Company May Need a GroupWise Audit and Architectural Review]]> GWAudit White paperLast week, I was talking to one of our healthcare clients about upcoming plans for their messaging system and GWAudit, our company's new offering, came up. The client had some very specific questions about the scope of service – all of which are detailed in a comprehensive white paper on the website. While I strongly invite you to check it out, I thought I'd offer you a "CliffsNotes" alternative, as well.

The reality is, an actual company reached out to us and requested our help in evaluating their email environment, identifying the risks, and recommending a plan of action towards better risk management. The engagement was not only successful, but received very positive feedback from exec management. We thought we'd extend the service to more clients.

Here's how it works. The auditing methodology identifies 3 types of GroupWise risks based on the level of severity, the urgency to address them, and the IT effort required for an effective implementation: (a) Critical, (b) Important, and (c) To Be Considered.

Using standard analytics tools, such as ConsoleOne and GroupWise Monitor, our GroupWise experts investigate the company's collaboration ecosystem and look at:

  • System architecture, fault tolerance & redundancy
  • Message routing & delivery
  • System security, configuration settings & patch and revision levels
  • Retention and data management
  • System maintenance, health and manageability

Depending on the results, they make recommendations for improvement through system consolidation and adoption of best practices in email management and risk mitigation. The goal is to help you become more efficient managing your business-critical email system and reduce its vulnerabilities.

Let's face it, new communications and social networking tools or not, email still reigns king. An Osterman Research survey from March 2010 found that on a typical day the average user sends 44 emails and receives 123 emails. For an organization of 1,500 users this means 64.9 million emails in one year. And it's your job to keep them coming and going.

We want to help you get the job done. That's how GWAudit came about. The best part is, you don't have to do the heavy lifting and in about a week you've got a clear plan where you should start first.

Interested? Get the details from our website or just send me an email.

]]>
Fri, 28 May 2010 00:00:00 GMT 9c77687f-e7f2-49f1-ab92-82e61f0e9908
<![CDATA[Why Archive Email? To Reduce, Simplify, Succeed]]> Recently, ITBusinessEdge.com associate editor and blogger Lora Bentley contacted me asking for some insights and perspectives on email archiving. She was working on a piece she published last week about how IT can justify email archiving as a necessary and worthwhile investment. She was looking for the top 5 "must dos"/"must haves" for successfully selling such solutions to management.

It was a good exercise that forced me to sift through the huge pile of technical documents and marketing collateral looking for the essence. I found it in two words: Reduce and Simplify.

  • Reduce email system downtime and productivity losses;
  • Reduce risks of lost or deleted email and penalties for non-compliance;
  • Reduce the costs of storage and eDiscovery;
  • Simplify email lifecycle management;
  • Simplify email back-up and storage management;
  • Simplify internal and external search and retrieval of email records.

Our customers confirm this. For example, the exchange with Lora coincided with a I story I just published on how the University of Dundee is using our archiving solution to roll out a campus-wide email retention and risk management strategy for 28,000 email users. The main benefits they see M+Archive bringing to them are: contain the growing volume of email and storage requirements, address eDiscovery and open records requests quickly, simplify access to centrally archived email.

Jim Finlayson, IT Manager at the City of Grand Junction, also confirms how using our security and archiving solutions allows them to preserve the City’s resources and ensure uninterrupted email system activity while improving employees productivity and disseminating information across the community with minimum IT overhead.

For Mark Hayward of market-leading satellite communications company Comtech EF Data, M+Archive’s value is in its ability to handle eDiscovery requests for intellectual property, contracts, and email records in seconds. This enables him to service his organization's legal needs and maintain a competitive edge quickly and cost-effectively.

Email archiving is not just an IT issue, much more it is a business issue. Retained email records are not IT’s documents, they are records of the business. That’s why the decision-making process for adopting email archiving needs to involve all primary stakeholders, not just IT. When you get everyone one the same page, the “reduce and simplify” IT aspires to easily translates into Success for the whole organization. Then the job gets much easier: while not everyone may understand why reduce and simply is a big deal, they all get Success.

]]>
Fri, 21 May 2010 00:00:00 GMT 9ac50a24-7f93-4d56-9bb7-7983d4521a70
<![CDATA[Candid Photos @ Brainshare Brewfest 2010 ]]> Dear BrainShare Fans!

Thank you for taking the time to attend the BrainShare Brewfest and meet the members of the Messaging Architects' client and partner community. Thank you for also sharing your thoughts, ideas, and advice during the evening. I look forward to more informative and engaging conversations in the future.

For those of you that missed it, the BrainShare Brewfest was an evening to remember that took place at Squatters Pub & Brewery in Salt Lake City, where everyone enjoyed a wide variety of locally brewed beer, great food, but most importantly, they had the chance relax and mingle with peers and friends.

Feel free to view the official picture gallery and spot some familiar faces:

netmail brewfest 2010Believe it or not, almost a third of all conference attendees made it to the event! Every Brewfest guest received a highly coveted Netmail T-Shirt and enjoyed over 800+ pints of beer and 300+ pints of lemonade served during Happy Hour!

We had fun and we hope you did too!
Sincerely,

Charles Nguyen
Messaging Architects

P.S. Thank you again for making this another successful BrainShare Brewfest event... send me an email if you recognize yourself in this non-official gallery, so we can tag you. You could Win a Secret Prize!

More photos ]]>
Wed, 21 Apr 2010 00:00:00 GMT bb80912a-4566-4865-ba28-caa165c6f2e9
<![CDATA[The Case for Being a “Smaller Company”]]> Here is an email we received earlier this month:

Client testimonialIt's great to hear from your clients you're doing a good job, especially so effusively. Naturally, I wanted to know what had prompted Eddie to send this email of "unsolicited praise".

 

In my case, satisfying my curiosity coincides with carrying out some of my responsibilities. Part of my tasks at Messaging Architects is to keep in touch with our clients, find out how they’re using our email security and archiving solutions, provide them with the occasional direct line to product management or our CEO, get a sense of how the overall relationship is going, demonstrate how companies can mitigate email risks through real-life case studies. Through these contacts I’ve met some really interesting people, as well as gained insights on collaboration in business, government and education.

 

So I called Eddie Parker and asked him. He was ready with his answer: our products are really helping him do his job well; he actually used "awesome" when describing the technology. But it is what he said next is what prompted me to write this post: Eddie couldn't say enough about the quality of client care and support he has been getting from Messaging Architects for the past 5 years. Every time he had a product upgrade, the Support team would call him proactively and do the upgrade for him. In Eddie’s own words, "Not once did I have to follow up with your support guys, they were the ones following me. And I am always very impressed by their level of expertise and knowledge. It’s a big differentiator."

 

In the case of Clinton City Schools, 3 technicians support 3600 end users for everything IT: from whiteboard and projection support to video surveillance and security management; from VOIP and telephony to network and desktop support; from email and switches to storage and file servers. Receiving such client care as part of the standard SLA is a big deal for the organization. He concluded our call with "We're pleased, you have a happy customer and we’re ready to share it with everyone." If you want more details, read the Clinton City Schools case study.

 

The chat with Eddie reminded me of a comment from Jason Piazza, Director of Network Services at Deer Park ISD, whom I interviewed for a case study I published recently. Jason, too, highlighted the superior client care, the personal touch, and the flexibility of the service he received.

 

Here's what he said: "Working with Messaging Architects was really a benefit to us because we felt taken care of… We always had access to engineers who were very knowledgeable on email management and archiving issues. I liked the training at the end that provided additional insights and free advice on the Exchange management that were beyond the scope of the migration project. And I appreciated the suggestions from the Messaging Architects Exchange expert on fine-tuning our system. It’s not something you often get from the large software vendors."

 

Another happy client, T.J. Russell from ISD #318, Grand Rapids, MN, is featured on our website: 'The excellent product and superb support are a win-win for your customers."

 

I can go on, but I think I’ve given enough evidence for us to agree that:

 

  • Messaging Architects' engineers are providing high quality service to our clients.
  • Messaging Architects' engineers are flexible and easy to work with.
  • Messaging Architects' engineers are highly experienced and knowledgeable beyond the scope of the products they support.

 

I can safely say I am speaking on behalf of all my colleagues when expressing the pride and satisfaction we share for getting the job done: helping our clients be successful.

 

Moreover, the big differentiators clients notice, appreciate, and talk about, such as the personal touch, the extra advice, the proactive human interaction, are - at least partially - related to the fact that Messaging Architects is not a "monster technology company," to quote Jason Piazza again. When you are a small, organically grown, privately held organization obsessed with putting the right people at the right place on the bus, it’s not surprising the clients get the right travel experience. It’s not rocket science…

 

Isn't it a bit paradoxical then that the "caution" industry analysts attribute to our company is that we are “a smaller organization”? It’s not the technology, the sales model, or the client care and support; it’s the size. I hear it regularly because the other hat I wear at Messaging Architects is that of Analyst Relations.

 

And so I want to end this rather long piece making the case for the "smaller companies" - especially after Nortel, Chrysler, Lehman Brothers... At Messaging Architects, we've been through a few bubbles and ups-and-downs, but we're still here – with innovative solutions, enthusiastic employees, and most important of all: a growing army of Raving Fans.

 

I think that's a pretty good place to be.

 


PS I am dedicating this post to my colleague, Stephanie Greenshields, who was relentless and instrumental in setting up the standards of what has become our "big differentiator": exceptional client care and support.

]]>
Wed, 31 Mar 2010 00:00:00 GMT 6c9a2b93-b236-4231-b0fe-8fa1cf76c973
<![CDATA[GroupWise Questions? Ask Morris the Magnificent.]]> Still have questions about GroupWise that you want answered? Here’s another chance to ask. Back by popular demand, the second installment in our GroupWise Guru Series... introducing, Morris the Magnificent!

Simply post your question here in the Morris the Magnificent Blog. Every week, Morris the Magnificent will magically select a question or two about GroupWise security, GroupWise archiving, or a general GroupWise question, and conjure up his answer.

Meet Morris the Magnificent

How to Participate:

  1. Register by creating a profile below. It's quick and easy!
  2. Post your question as a comment.
  3. Check back often to see if Morris has answered your question. 
Note: Please enable cookies.

 

 

 

]]>
Tue, 30 Mar 2010 00:00:00 GMT f20d784c-ae46-4e1d-9e47-5fe89a235cc2
<![CDATA[Free Speech vs. Your Business Cont.]]> Yes, I am reusing the title from Michael Osterman's blog posting today (March 25) and I am doing it intentionally. The topic Mike brings up is both amusing and serious – and he himself invites the discussion.

 

Here is an excerpt taken directly from Osterman's blog:

 

"…[S]omeone at a company that I follow on Twitter … yesterday tweeted a link to a very derogatory blog post about the CEO of a major software company, and tweeted this under the name of their employer. The blog post discussed the eternal fate of this CEO, implied he probably had multiple mistresses, and expressed the view that he looks like the 'child of Karl Rove and Stewie from Family Guy.' Not very complimentary stuff no matter how tongue-in-cheek might have been the intent of the author."

 

Funny story, indeed. But… What would happen, hypothetically asks Osterman, if at that same moment an executive of the company that employs the Twitter poster is trying to work a deal with the company whose CEO was denigrated in the blog post? Individual freedom of speech, corporate image and reputation, embarrassment during negotiations all enter into play.

 

Mike concludes by asking: what's the right balance between individual freedom of expression and potentially negative consequences for the organization an individual exercising this right may be responsible for.

 

In my mind, Osterman essentially extends the idea of acceptable usage policies – something we, at Messaging Architects, have been preaching for years in the context of email – to usage of social networking tools in the enterprise. The parallels between email and social networking tool usage are easy to detect: just like there are dos and don’ts about how you can use corporate email, so there should be rules and boundaries regarding Facebook, LinkedIn and Twitter usage.

 

Easier said than done – the social network fabric tends to be way more heterogeneous (not to mention public and harder to both monitor and constrain) than the considerably easier boundary demarcation between work and private email.

 

As the person managing Messaging Architects' presence in the social networking space, I've found that having separate "corporate" and "private" Twitter profiles works quite well. When I post to the corporate profile – MPlusNews – I adhere to guidelines that are quite similar to our corporate email policy, though I allow myself greater flexibility on spelling and tone in line with the medium character limitations and register. On my personal profile, where I don't identify any company affiliation, I can be more "adventurous" as to whom I follow and what I tweet. In that case, I am solely accountable for the content and I am not a spokesperson for the company I represent.

 

Facebook, however, is a whole different story – worthy of a separate discussion or maybe a whole series…

 

There is no doubt social media can help businesses and raise an organization’s visibility – for some useful Tips on using social media for business check out Rick Wagner's Computerworld blog. But there are also risks and liabilities we need to recognize – as confirmed by Osterman's hypothetical scenario. And these completely discount the IT security risks and liabilities related to phishing scams, hacker attacks and other fraudulent threats that all these media are regularly exposed to.

 

So, in the end, it boils down to training the users and winning their buy-in not through restrictions but through setting the right expectations. Just like with email, the sooner some type of acceptable usage policy with respect to social networking tools is adopted organization-wide, the sooner some of the risks related to preserving the organization's integrity and reputation may be addressed.

 

]]>
Thu, 25 Mar 2010 00:00:00 GMT c24a3119-af68-4511-8bb9-910df96a0058
<![CDATA[Email Archiving and eDiscovery: Two Sides of the Same Coin]]> Not too long ago, email archiving and eDiscovery solutions were considered separate, albeit necessary, components of enterprise email management. Moreover, eDiscovery was perceived largely as a service that companies sought outside the organization.

 

Then things changed. The recession brought the need to carve costs out of IT expenditure, take control of eDiscovery risks, and reduce overall litigation spending. Industry analysts and experts began talking about "in-sourcing eDiscovery." Fulbright & Jaworski’s 2009 Litigation Trends Survey reported almost half of the survey participants were already in-sourcing some aspects of the process. In December 2009, Gartner came out with a report, symptomatically entitled E-Mail Archiving and E-Discovery: What to Do Next, which confirmed a similar key finding: adopters of email archiving solutions are looking to expand the uses of their archives for eDiscovery tasks. Recent announcements from traditional email archiving vendors have all been revolving around support for eDiscovery and litigation readiness.

 

All this goes to prove that when, a few years ago, we redesigned the M+Archive architecture to combine email retention with eDiscovery, we were way ahead of the curve. And our clients have appreciated and benefitted from this. And they’re saving money.

 

How do I know this? Nothing more than some really quick back-of-the-envelope calculations based on what clients I’ve recently spoken to tell me. I see the following patterns:

  • Every single one of them has used M+Archive for eDiscovery, even if they originally purchased the solution to address email retention;
  • The investment in the M+Archive indexing server paid for itself after a single discovery request, which took minutes as opposed to days;
  • Legal costs were reduced on average by a quarter just because the subset of data presented for review was highly accurate.

eDiscovery softwareGranted, these are my unscientific observations; still, they are pretty compelling. What’s even more compelling is that the latest release of M+Archive will enable them to save even more. Enter M+Analytics.

 

Last week, I saw M+Analytics in action. This is a really slick case management system that’s part of our email archiving solution. It allows authorized reviewers, internal auditors, or legal professionals to collaborate on eDiscovery requests using the M+Archive central repository. So don’t forget to sign your internal auditing and legal teams up for the upcoming walk-through of M+Analytics.

 

According to data collected and analyzed by Michael Osterman, eDiscovery today represents about 35% of the cost of litigation. With an early case assessment system, such as M+Analytics, in place, the cost of processing and reviewing of data can be reduced considerably. In fact, one of my projects for this year is to track clients’ litigation cost savings directly linked to M+Analytics.

 

What prompted this posting, however, wasn’t the research suggesting a convergence between email archiving and electronic discovery technologies. Rather, it was the enthusiastic praise for M+Archive from a client with whom I had lunch two weeks ago. We didn’t go into an abstract ROI discussion, we didn’t talk about the granularity of the policies or the flexibility of the archiving jobs. It was much simpler than that: "The Terabytes of archived data are growing daily, we can find whatever we need in seconds – WOW!"

 

At the end of the day, it’s the validation from the clients that counts the most.

]]>
Mon, 22 Mar 2010 00:00:00 GMT 14bacfc8-efb6-4749-b708-d2c7964c2746
<![CDATA[Reining in the Information Overload]]> Wow, time does fly! The Ides of March are here and it’s daylight savings time again.

2010 has been pretty hectic for us: product releases, live webinars, trade shows, best practices seminars, on-site client visits, business partnerships, not to mention juggling the growing ecosystem of social networking from LinkedIn to Facebook and Twitter. The information is as overwhelming as it is relentless.

A recent special report in the Economist on “Data, data everywhere” discusses preserving, processing and using the Exabytes that surround us. (How do you even abbreviate an “Exabyte”?) 

Without a doubt, messaging takes center stage in the ever-growing information overload. To make things worse, it may turn out that email is making us stupid; yet, it’s unlikely that it will stop coming.

This rather dire scenario has a silver lining, which was uncovered by our clients. It turns out that over the past few months our website has transformed itself from being merely a source of traditional product-related information on email security and archiving software into a valuable repository of resources that help them deal with day-to-day email management, as well as empower them to implement a much broader email risk management strategy.

In my opinion, this is worth writing about. So in the coming weeks, we’ll be providing in-depth spotlights on the various sections on our website: from the newly launched Security & Compliance newsfeed to the eDiscovery and the Email Risk Management centers.

Our goal is simple and ambitious: offer as much relevant information as possible, make it as accessible as possible, reach as wide an audience as possible.

We invite you to share your feedback and bring your ideas to the table. We’re all in this together.

]]>
Mon, 15 Mar 2010 00:00:00 GMT 244779da-a2ae-47df-aacf-66e392ff6a04
<![CDATA[Communication Breakdown Between IT and Legal Departments]]> EDiscovery law is full of cautionary tales about miscommunication between IT departments and legal departments. When it comes to electronic records management, lawyers and technical professionals have historically not spoken the same language.

For example, a breakdown in communications spelled disaster for a pharmaceutical company in litigation over the Fen/phen diet drug. Plaintiffs said the drug hurt patients and sued. In the discovery phase of the lawsuit, plaintiffs requested email records. On numerous occasions, counsel for the company said there were no backup tapes containing email because counsel understood the IT department to say that there were no such tapes. However, a more careful investigation eventually revealed that there had been some tapes -- after the lawsuit started -- on which email had been stored. These tapes were created for short-term storage and then recycling, and IT did in fact recycle them while the lawsuit was pending.  The recycling caused email records to be destroyed. Counsel only came to understand this recycling process later, after counsel claimed there were no tapes containing email. The judge was unhappy. The judge felt that counsel misrepresented the truth about the existence of email on tapes. The judge levied sanctions against the company so as to deal it a severe strategic disadvantage in the lawsuit.  (Linnen v. A.H. Robins Co., Inc. , Mass. Superior Ct. No. 97-2307, June 16, 1999, Memo. of Decision and Order).

Today, this kind of miscommunication unfortunately remains common. It prevents enterprises from setting good policy on the retention and destruction of email, even before litigation starts.

This weakness of communication is a key problem addressed in Messaging Architects' ePolicy Workshop. The workshop aims to pull to one table the IT department, the legal department, and other stakeholders in the organization. It helps bridge the gap in communication on records issues, so the organization as a whole can set intelligent policy.

]]>
Mon, 30 Nov 2009 00:00:00 GMT f6cc4f25-e105-4c33-b741-b73ca92d3c64
<![CDATA[Stumped!]]>

You asked and our GroupWise gurus answered, but now it’s time for us to deliver on our promise. Congratulations to Gene Homan (Stumper1934) of Minneapolis, Minnesota, for stumping our gurus.

The winning entry was selected from all the entries submitted from GroupWise enthusiasts around the world who responded to the opportunity to stump our experienced GroupWise Gurus in our blog.

In the words of The Mentor, our winner asked a question about a new technology that none of the gurus have had time to work with yet. The winning entry was "Can you explain the flow of communications between the GroupWise (GW) Calender Publishing Host (CPH) servlet and the various GWPOAs and the users out on the Internet doing Free/Busy searchs and Subscribing to GW user calendars? What does the CPH do on startup? How does the CPH get its updates as users make changes to their Published calendars?"

As the grand prize winner of our Stump the GroupWise Guru contest, our winner will receive two hours of professional services with the GroupWise Guru of his/her choice.

Thanks to everyone who entered! If you haven’t already, you can stay updated with the latest news, announcements and contests like this one by following us on Twitter or becoming a fan on Facebook.

Also, be sure to check out our free GroupWise Interactive Quick Start Cards.

]]>
Tue, 24 Nov 2009 00:00:00 GMT fe5c5e07-748f-40d7-ad06-d9bc8e910c0f
<![CDATA[ePolicy Workshop Attracts Policy Stakeholders in the Enterprise]]> risks and benefits in mind.

All of these various stakeholders are busy with other tasks. To induce them to focus on email records policy is not easy. Email raises difficult issues that didn't apply to old paper records.  

As the legal department knows, email is the primary topic of the booming field of litigation known as eDiscovery. In a lawsuit, eDiscovery can be expensive if records are not well-maintained. And a lack of records can play to your disadvantage in the way of court penalties or lack of evidence to support your side of the case.

The HR and internal audit departments will point out that email has also become central to internal control, regulatory compliance and employee supervision.  

Improper retention of email can yield a waste of resources. IT will want to weigh in on the cost of data storage, including the cost of technology and the cost of management. Data security must be considered as well.  

In a typical enterprise such as a corporation or a government agency, none of the stakeholders has the clout to make all of the other stakeholders come to the table to examine these issues and to craft a policy. This is where our electronic records policy workshop comes in.  When someone like the CIO announces that our workshop will be held in-house, the many stakeholders are motivated to make room on their calendars. The workshop brings quality, up-to-date education into the enterprise, and provides a professionally-led format for analyzing the issues and coming to consensus.  

Time and again our customers have told us that the convening of the workshop was critical to their email policy development. The workshop caused the players, for the first time, to sit down long enough to hash out the components of policy. The workshop normally concludes with agreement on the basic outline of policy, with appropriate understanding on how the exact policy language will be drafted and presented to upper management for final approval. ]]>
Mon, 23 Nov 2009 00:00:00 GMT aa412e41-d345-4c3b-8fa9-5a5358a64861
<![CDATA[Shelter from the Email Storm]]> Winter is approaching, it's chilly out there, and many of you are digging out from under a blizzard … of unwanted email. I'm talking about snowshoe spam, which these days accounts for up to 50% of spam volume.

Just as snowshoe distributes weight across a large surface to avoid falling through the ice, snowshoe spamming spreads spam output across many IPs and domains — in effect, “spreading its weight” so it doesn't trigger automated filters. Using these techniques, spammers use many small IP ranges on many ISPs, which in turn use many different domains that rapidly change IP addresses. Snowshoe spam is particularly tricky because it appears to come from seemingly legitimate, uncompromised IP addresses.

Most importantly, although these IPs usually sends a modest volume of bulk email, collectively these anonymous IP ranges are capable of huge throughput. The result? An avalanche of spam.

Fortunately, M+Guardian and Spamhaus are there to shelter you from the harsh elements. M+Guardian now incorporates Spamhaus’ newly announced Composite Snowshoe (CSS) block list to combat the dramatic rise in snowshoe spamming.

Spamhaus CSS is an automatically-generated list of IPs that have been detected sending snowshoe spam. CSS listings are automatically removed a few days after the last time a listed IP or one of its near neighboring IPs stops sending snowshoe spam. The Spamhaus block list team is taking the CSS data and continue to create manual listings for active snowshoe ranges, identify the spammers behind snowshoe operations, and associate those listings with Register Of Known Spam Operations (ROKSO) records or create new records where appropriate.

We knew that, even though several botnets were knocked offline last summer, the reprieve would be short lived. Fortunately, there are organizations like Spamhaus to fight the good fight. It might seem like the good guys are always one step behind, but spam-blocking by nature is reactionary. So, a more accurate way to think about it is we're hot on their heels, always watching and quickly reacting.

]]>
Mon, 09 Nov 2009 00:00:00 GMT 22c650e1-7a9b-4530-8cd4-df282531bb25
<![CDATA[Don't Be the eDiscovery Cautionary Tale]]> It might have slipped below your radar but, last month, the Boston mayor's office had some email troubles. Although most people wouldn't consider this a "scandal"  — no affairs, bribes, etc. — those of us in the messaging world would certainly consider it scandalous. A top aid to the mayor was accused of routinely deleting emails in violation of  state law, which requires employees keep all email for a minimum of two years.

The spin-doctors at the mayor's office defended the aid by explaining that "double-deleting" (moving emails to the trash and emptying the recycle bin daily) is simply a good organizational habit. Then, of course, the finger-pointing began with the aid contending that he just assumed the email was being backed up by the city's servers. The city's IT department insisted it was the employee's job to archive the messages.

No one is saying that the deleted emails contained evidence of any wrong-doing. Here's the real "crime" in my estimation: The aid was deleting email, despite the fact that, a year ago, a judge warned the mayor's office about the practice of deleting emails. (It had been revealed that employees were deleting emails to save on storage space.) The city then bought email backup software, but didn't bother to create an email retention policy.

Seriously. They bought an email archiving system. Presumably, they fixed the storage problem when they bought the archive. And, then … nothing. Folks, all the software and storage in the world isn't going to solve your email management problems if you don't have policies to guide what you do with it.

Because we understand that polices are the absolute foundation of message management, we've created an ePolicy Workshop. It's a private, two-day workshop that helps organizations think through and create clear, written policies. You start by assessing your organization's current retention policies (if there are any), how you're enforcing them (if at all), and how the policies might help or hinder a potential discovery or disaster recovery process. You'll learn what areas of an email infrastructure typically present security and compliance gaps and how your organization scores in each of these areas. Once you understand where you are, you can determine how far you have to go.

It's important to include all the people who have a stake in the policy. This isn't just an IT issue, so key executives and people from legal, records management, and human resources also need to be involved. If you're worried about the logistics of getting all these people to a seminar or conference, don't worry — we come to you. Because we hold the workshop onsite, you don't have to figure out how to get everyone to some offsite location. Another bonus is you're someplace where you can have confidential discussions of sensitive, company-specific issues.

Although you might cringe at the idea of being pulled off other projects for two days, the time-frame really is pretty short and sweet. If you were doing this on your own, you'd be faced with assembling a policy team, scheduling a series of meetings, and going through draft after draft trying to come up with a policy that meets everyone's needs. With the workshop, our technical and legal experts guide you through the process, and in two days you walk away with an email retention and deletion policy tailored to your business needs and industry requirements. You'll know what email needs to be retained and for how long; how to maintain secure and auditable records; what should go into formal, written policies; and what technologies will enforce those policies.

Beyond policies

Enforcement is key. As we've seen from the Boston situation, it's important to have policies, but it's also unreasonable to expect  employees to implement these policies with completely accurate judgment 100 percent of the time. It isn't their core competency, it distracts them from their daily work, and — should they slip even once — the stakes are too high. To be sure your policies are being strictly and consistently followed, you need a way to automate their enforcement. If the employees in the Boston mayor's office had these two elements in place – policies and the technology to enforce them — we wouldn't be reading about them today.

]]>
Wed, 28 Oct 2009 00:00:00 GMT 4feda5be-d143-4031-ae77-365b5c549952
<![CDATA[Think You Don't Need an Email Management System? Think Again]]> In a previous post, I highlighted an interesting study from AIIM, “Email Management: The Good, the Bad, and the Ugly.” Since reading that study, a few of the findings keep nagging at me — specifically, that 54 percent of the organizations participating in the survey have yet to implement email management. Here are the top 6 reasons those participants gave, followed by some points to consider if you are still on the fence.

[ ] We're happy to rely on backup tapes.

Backup and archive are not the same. Backups take periodic snapshots of active data so you can recover it in the event it's deleted or destroyed. OK for use in an emergency, backups usually contain multiple copies of messages, and there's no clear information about which messages exist on which backup tape — an eDiscovery nightmare waiting to happen. Think of backup as a short-term insurance policy to facilitate disaster recovery. Think of archiving as ongoing, rapid, and precise access to years of business information.

[ ] Outlook/Exchange archiving is sufficient.

The Outlook/Exchange 2007 Archiving feature is primarily used to keep inbox size down and circumvent fixed-term deletion policies. To do this, it creates a secondary database to store messages. The default location for this database is the user's local hard drive or, if a user has both a desktop and laptop, multiple archives. Without structured deletion policies, this approach will soon cause serious compliance gaps.

In Exchange 2010, Microsoft is adding multi-mailbox search functionality that offers only basic query (date, keyword, boolean). However, every search creates messages in a "search" mailbox, which in even moderately sized enterprises will quickly become bloated and unresponsive. Storing archives in Exchange also means using expensive hardware (SAN) rather than lower-cost devices or optical disc.

[ ] We don't view email as a sufficient threat to our business to take action.

Hard to believe that organizations are ignoring the evidence (so to speak) all around them. The Federal Rules of Civil Procedure that addressed electronically stored information went into effect in 2006, and the scandals (Enron, WorldCom, Tyco…) which led to the enactment of various regulatory frameworks date back almost as far. An entire industry has built up around providing software and services to ensure compliance with these laws, which apply to both private and public organizations, across almost all sectors. Inaction or the choice to not abide by these clear and legally binding obligations for preserving records is the real threat.

[ ] We have bigger email concerns right now, e.g., security, spam, mobile, etc.

Another stunner. We know that M+Guardian users are not part of this bunch.

[ ] Our staff is responsible for filing email appropriately on paper or file shares.

It's great to hear that so many of the survey participants are confident in their employees' ability to understand and implement their organizations' email retention policies! Sarcasm aside, I truly doubt professional IT Managers trust that every single user will implement those policies. Perfectly. For every single message. Every day. Professional IT Managers implement applications and frameworks to ensure that the end result they know needs to happen, actually happens. Except in the smallest organizations (less than 15 users), no policy management usually means that each user implements their own slightly modified version of their interpretation of what the policy might mean to them. The result is a quagmire of hundreds of individualized and idiosyncratic archives that are nearly impossible to manage.  

[ ] We would like to save email to a records management system, but we don't have one.

When it comes to email management, the costs and potential penalties are high. The average lawsuit cost can easily exceed $1 million, and 30 percent of the cost is associated with IT-related tasks such as searching for emails and files. Failure to produce email records altogether during legal discovery means the organization doesn't have the evidence needed to defend itself. And if the courts determine that an organization has willingly destroyed its email records, it will be slapped with hefty fines — in fact, 84 percent of all eeDiscovery fines are due to email destruction.

We're well past the point where organizations can plea ignorance when it comes to electronically stored information. If you haven't implemented email management in your organization, today is the day to begin. We have tons of resources available, and most of them are free.  We regularly conduct public webinars and can provide material you can use to educate your team.

We have a passion for archiving, and with more than 500 M+Archive deployments in 20+ countries to date, we’ve learned a lot about how to do things the right way. Let us know how you’d like us to help.

]]>
Thu, 22 Oct 2009 00:00:00 GMT 040c7d4c-7c4f-4c32-bb00-769642555002
<![CDATA[Stump the GroupWise Gurus Contest! ]]> stump the groupwise gurus

 

Got a question about Novell GroupWise that you want answered?

  • Don't know how to set up an external busy search?
  • Do I need to run GWCheck?
  • Got a question about upgrading to GroupWise 8?

Post it here for a chance to WIN two hours of professional services with the GroupWise guru of your choice. With over 80 years of combined GroupWise expertise between them, it will be hard to stump our panel of gurus.

Meet the gurus.

 

 

How to Participate:

 

  1. Register by creating a profile below. It's quick and easy!
  2. Post your question as a comment to the GroupWise Guru of your choice.
  3. Check back often to see if you’ve stumped the GroupWise Gurus. 

Thank you and good luck!

NOTE: Please enable cookies so we can log your official entry! 

 

 

 

 

 

]]>
Wed, 07 Oct 2009 00:00:00 GMT f2eaaba6-4f4e-491c-b6f3-f2a4ad841599
<![CDATA[To Stub or Not to Stub … and What to Stub?!]]> In my previous post, I discussed the much maligned and misrepresented concept of stubbing. If you read that post, you learned that when used properly, stubbing can reduce the size of your mailbox store, thus improving the performance of your live mail system and reducing backup time.

So, what does “used properly” really mean?

Let's dive into the details, starting with attachments. Although usually a relatively small percentage of messages in our mailboxes contain attachments, these messages typically occupy 80 to 90 percent of mailbox disk space. Being able to remove these items from the live mail system, yet still have them easily accessible through the native client, could reduce the size of your mailbox store by 80-90 percent! This is a great example of using stubbing in an intelligent manner — a small number of items are stubbed, but you're saving a large amount of space.
 
Another smart way to use stubbing is to stub aging data. Automatically removing aging information from the live mail system is a good way to control/manage the size of the mailbox store. It's becoming more and more impractical to let users keep infinite amounts of mail in their mailboxes. Unfortunately, this can clash with the user’s need to access aging information in a seamless manner (through the client) without having to access the secondary storage (archives) using a third-party app or browser. 

Imagine a policy where all items in a user’s mailbox fall into three categories, based on their age:

0 to 6 months — Messages reside on the primary mailbox store.
6 to 12 months — Messages reside on secondary storage and are stubbed.
12 months+ — Messages reside on secondary storage (archives).

In this scenario, users would have access to a full year's worth of mail through the native client, even though half of that data resides outside the live mail system. You could even get more granular and apply different policies to different to users, or groups of users, depending on their needs or role in the organization.

How Stubbing Should NOT Be Used…

Let's stub 100,000,000 items back into the live mail system! Or not. Although you will not take a huge hit on disk space because stubs are tiny little files, most enterprise-class collaboration systems (GroupWise/Exchange/Notes) store mail items in proprietary databases and have limits on the number of items that can exist and be indexed in a mailbox or folder. Stubbing doesn't change these limitations and should NOT be used in an attempt to give access to more mail items than one would otherwise keep in the live mail system.

]]>
Mon, 05 Oct 2009 00:00:00 GMT 865ea8d5-ec8e-4a28-8c57-ee438168e2c0
<![CDATA[Records Managers as Agents of Change]]> ARMA 2009I mentioned yesterday that I am eagerly anticipating our first participation at the ARMA International Conference. I am sure I’ll learn a lot from the attendees; I am also curious to hear Ben Wright’s views on the roles of records managers as Agents of Change.

Ben has an original and somewhat provocative position on records retention. He argues that time-honored legal advice on records retention, especially email, doesn’t fare too well in court. Why? Because electronic records aren’t retained properly or for a sufficiently long period of time. But, there's hope. Ben considers records mangers as those "Agents of Change" who can be most effective in promoting the message that it’s time to manage email differently and change records retention policies.

The scheduling of our session on Saturday afternoon as part of the Industry Intelligence Track may turn out to be inconvenient for some attendees, so we’ve come up with a Plan B. Ben is offering highly personalized one-on-one or group discussions on this topic and surrounding issues at our booth all day Friday, October 16.

Do these questions resonate with you?

  • Is it possible that organizations destroy email too quickly?
  • Do organizations risk incurring great expenses recovering deleted emails?
  • Do users truly understand and follow email retention policies in practice?

If so, do stop by to talk to us and share your views. It's a great opportunity to get personalized perspective that will help you out in both the court room and the server room.

If you aren’t attending this year’s ARMA International Conference, but would like the materials, send me an email or — even better — get involved in the discussion on Ben’s blog. The more we know, the stronger we are.

See you in Orlando or online!

]]>
Sat, 03 Oct 2009 00:00:00 GMT 1e523cb2-ae10-4c93-91ba-26b23c0141e1
<![CDATA[Messaging Architects at ARMA International]]> ARMA 2009I am quite excited because I just learned that, together with technology attorney Ben Wright, I will be representing MA at the 54th annual ARMA International Conference. My excitement comes not because this event is happening in sunny Orlando (I live in Phoenix, so I get my fair share of sunlight as it is). No, I'm looking for enlightenment of a different kind.

[Begin Shameless Plug]
It’s Messaging Architects’ first participation at the conference, so come visit us at Booth # 932 and attend our session on Saturday, October 17.
Topic: Records Managers Can Become Agents of Change for eDiscovery and Records Retention
Date: Saturday, October 17, 2009
Time: 11:15AM - 12:30PM
Location: Expo Floor, Room 1230
It will be time well spent.
[End Shameless Plug]

I'm really looking forward to attending the event because I finally get to meet the records and information managers up close and personal. As part of my responsibilities at MA, I am constantly in touch with clients and getting their perspective on the ins and outs of email risk management. So, I am quite familiar with the IT point of view: Retain everything forever, ensure the messaging system doesn’t choke from the information overload and the company doesn’t go broke from the costs of legal discovery, be able to instantly recover your CEO’s emails from five years ago, don’t make your end users think ... I'm sure these concerns sound familiar to most of you.

But, I’d like some insight from some of the other players in the records retention game, i.e., the records managers. Today, where everything is regulated and mandated, what can turn them into heroes in their organizations? In fact, at the ARMA Conference, Ben is actually going to challenge some of the long-standing precepts of email. What’s more, he thinks that records managers are actually in a perfect position to become Agents of Change and bring about a much needed shift in electronic records management. Stay tuned for more about the Ben’s thoughts and provocative session in my next post.

]]>
Fri, 02 Oct 2009 00:00:00 GMT 8744ba2c-e436-45e0-b239-f605056fd5b9
<![CDATA[MA Is on Twitter]]> It took a little while to get Messaging Architects on Twitter, but it's not because we weren't paying attention to this new medium. I sat through numerous webinars highlighting the “benefits of Twitter for the enterprise,” watched videos on Tweeting best practices, and even reviewed the “Twitter for Dummies” slideshow. Still, I wasn’t sold. I couldn’t see the dramatic difference we could bring our clients, partners, and the M+ community by being on Twitter.

And then last week I saw the light. At the weekly huddle, we started discussing how best to share the fall activities, webinars, events, conferences, contests, product spotlights, client success stories, industry news, and analyst reports... I got dizzy just trying to outline the communications schedule, keeping everyone in the loop without abusing email etiquette by going in email overdrive. And then it dawned on me — MA on Twitter. Short, sweet, and compelling.

And so Messaging Architects is on Twitter and I’d like to invite you to follow us: http://www.twitter.com/MPlusNews. We promise to bring to you daily useful nuggets of information to keep you informed, amused, entertained, challenged, and always connected.

]]>
Thu, 01 Oct 2009 00:00:00 GMT 7d58cd80-4377-44c4-9dbe-65ab0a3b3a4e
<![CDATA[The Downsides of Stubbing (And When You Should Ignore Them)]]> Because of its introduction in GroupWise 8, stubbing is getting a lot of attention lately. The idea behind stubbing is to display email in a user's inbox, but have the actual email content reside outside the email server. The benefit is that you get to keep your messaging system relatively streamlined, but still give users easy access to those stored messages.

This sounds pretty good, but a bit of Googling may have you wondering about the value of stubbing. Although there are some mixed opinions about stubbing, I fall into the “pro-stubbing” camp. Let me re-phrase that. I'm pro-stubbing when stubbing is done correctly.

The criticisms of stubbing are usually rooted in poor uses of stubbing. It's kind of like saying you shouldn't exercise because you might get hurt. Well sure, if you don't warm up properly, you might end up with a pulled muscle. But, does that mean you shouldn't exercise at all? (If you're looking for an excuse to skip a trip to the gym, don't answer that.)

Here's a good rule of thumb: Stubbing works well for large items and aging items. Anything else, and you're not using the technology the way it was intended.

For example, here are some of the “downsides” you might read about stubbing:

1. A stubbed message will take longer to open then a non-stubbed message.

Well … ya, it will. That's because the message resides on non-local, cheaper/slower storage. That's why it makes sense to store aging information (which isn't accessed as frequently) or large items (which one might expect to take longer to open).

2. A new point of failure is introduced. If the stubbing agent or the secondary storage become unavailable, stubbed items can no longer be opened.

There are two points to consider here. First, the instability resulting from keeping massive amounts of large and aging messages in the live system is a far greater problem than the risks introduced by a secondary storage system. Plus, even if the secondary storage becomes unavailable the organization is only temporarily losing access to aging data, not the mission-critical, newest mail.

3. Stubbed items can only be opened using the native client. For example, a GroupWise user can access their mailbox via GroupWise and the stubs will work just fine; but, if a user wants to use some other mail client, like Thunderbird, to access their GroupWise mailbox, the stubbing won't work.

It's true that you can access the live mail using any mail client via standard protocols like POP and IMAP and get basic functionality; but certain features specific to GroupWise -- like stubbing or proxy access – won't work. However, if you're using something like M+Archive, which is policy-based, it isn't an all-or-nothing scenario. You don't have to apply the same policies to all the users, so you wouldn't have to implement stubbing for users who access their mail via a POP or IMAP client. Those users could still access their archives using WebAccess.

Read between the lines

If you find someone who isn't a fan of stubbing, check the source. Is it a solution vendor whose product doesn't support stubbing? They may well be downplaying the benefits of stubbing to justify this missing feature.

Here's another gem I've come across: “To compensate for its inherent instability, Exchange has something called stubbing that is being introduced into GroupWise.” They'll then make to leap to imply that Exchange uses stubbing because it's unstable and, because GroupWise now offers stubbing, it must be unstable, too. Not true.

Here's the upshot: Stubbing addresses a common and serious problem, i.e., that users keep too much mail. This uses a lot of primary (expensive) disk space and reduces the performance of the mail system. When used intelligently, stubbing can bring huge storage management benefits by reducing the size of your mailbox store, thus improving the performance of your live mail system and reducing the amount of time it takes to perform backups.

In my next post, I'll share some tips for getting the most out of stubbing.

]]>
Tue, 29 Sep 2009 00:00:00 GMT 777cfda1-68a6-45d1-8492-034c351c6caf
<![CDATA[10 Steps to Creating a Single Point of Discovery ]]> In my previous blog posting, I discussed some of the complexities of eDiscovery and alluded to a potential solution. I believe the key is Unified Retention --  a combination of policy enforcement and different systems working cohesively to ensure a single point of retention and discovery for all email records.

The simple philosophy is that if the organization can state with 99.9-percent certainty that the requested messages exists or does not exist then expensive eDiscovery exercises can be avoided. Courts will usually require proof of such statements through formalized policies and audited processes within the organization.

Part of the challenge of defining a unified retention solution is controlling the data sources inside and outside of the defined retention area. If the organization can't identify or control the records outside of the retention area, how can it implement a record-destruction policy without reverting to disparate data storage again? This is where the alignment of the various policies and procedures comes in.

There are ten areas you must address to define and manage a unified retention area:

  1. Identify email sources, including: backups, personal archives, IMAP/POP3accounts, mobile messaging, and any other copies (even printed copies).
  2. Evaluate the organization's ability to control those locations through either process or policy.
  3. Consider alternatives for handling information that you can't realistically control via processes or you can't audit effectively with an associated policy.
  4. Define some type of formal retention policy that details how and where data will be stored and retained.
  5. Back up these policies with formal processes.
  6. Consider an archival and retention package for the email system. This will form the basis for the unified retention area.
  7. Once you've selected the archiving and retention package, the implementation should provide for 100-percent retention of all email messages in a single or multiple repositories.
  8. Decide what to do with current data, for example tape backups outside the unified retention area.
  9. Implement a data-destruction policy on the unified retention area. Be sure the destruction policy does not conflict with external data policies.
  10. Ensure the actual integrity of the unified retention area.

If item #6 caused you to pause and wonder about my motives (after all, I do work for a company that produces an archiving product), I understand. However, as messaging expert, regardless of whom I work for, I can tell you that, although you can use a live messaging system as the unified retention area, unfortunately email systems were not designed for this function and are impractical for long-term storage and retention of information.

The retention system needs several key components in order to ensure a comprehensive retention area:

  • Automatically capture 100 percent of all email
  • Index and search data
  • Maintain message integrity
  • Provide scalable and cost-effective storage
  • Perform selective destruction
  • Apply litigation holds to data
  • Audit deletions to validate corporate destruction policies

One final note: Unified Retention gives organizations a way to effectively handle and process eDiscovery requests in their email system. However, Unified Retention doesn't come in a box. It must be architected and deployed by skilled individuals who know the systems and the processes, and accompanied by a willingness of upper management to develop or sign off on email usage and retention policies that will ultimately protect and benefit the organization financially.

]]>
Wed, 23 Sep 2009 00:00:00 GMT c390cf73-237d-49fe-b105-7ab560346a68
<![CDATA[Your Portal to eDiscovery]]> I'm pleased to announce the launch of a new section of our website dedicated entirely to eDiscovery: The eDiscovery Resource Center. We created this section as a portal to educate visitors about the technical and legal issues surrounding eDiscovery.

We've filled the Resource Center with interesting and relevant information that you can turn to, for example, compliancy briefs on SOXOpen Records and FRCP. These briefs were created in conjunction with our legal expert, Ben Wright, who writes a compelling and useful blog on all matters involving eDiscovery. Ever wonder about the implications of Facebook as a business record in the corporate environment? Ben talks about it here.

Learn from Your Peers

The eDiscovery Resource Center also spotlights specific Messaging Architects clients and how they use our products to manage compliance and answer eDiscovery requests. Reading how another university or major hospital handles compliance can inspire ideas for your own organization, or make you ask the questions that lead you down the path to a solution.

Not all of our solutions are products. We offer a wide range of services to help clients understand the complexities of the legal landscape. One such interesting case study comes from Jackson County, which used our e-Policy Workshop to successfully build and get buy-in for an organization-wide email retention policy.

Take Advantage of Our Experience

We work with hundreds of organizations, across many vertical markets, all over the world, so we see all kinds of issues pertaining to compliance, security, and eDiscovery. Our goal with the eDiscovery Resource Center is to give you a way to take advantage of our experience and expand your understanding of eDiscovery.

This is a growing field that is maturing. Organizations such as the EDRM Group are standardizing the processes involved with eDiscovery. We will be updating this Resource Center with the latest information around eDiscovery, so be sure to check back often!

]]>
Tue, 15 Sep 2009 00:00:00 GMT 2c030e94-6280-4fd0-ad3d-eb1c1fbf3a9b
<![CDATA[Email Management: The Good, the Bad, and the Ugly]]> Like it or not, email is the nerve system of modern business. Compared to the phone, it is asynchronous and provides a written record to the sender and recipient for follow-up action or later reference. In this respect, it is much more useful than instant messaging or social networks.

It can be frivolous or deadly serious – it’s possible to be fired via an email, but also due to an email. Many vital decisions are made by email exchange, and the implication of our usage findings is that these may be made on the move, on tiny screens, and when otherwise off-duty.

Continue Reading

]]>
Thu, 03 Sep 2009 00:00:00 GMT f7a8601f-f27f-4eda-92fe-251fe1d36aa3
<![CDATA[The eDiscovery Dilemma]]> In the current legal discovery landscape where email has become the predominant form of evidence, more and more organizations are finding themselves in the unenviable position of having to provide email records in support of litigation. Regardless of the merits of the case (or lack thereof), rather than go to trial, many of these organizations opt to settle out of court because of the potential cost of eDiscovery or lack of available evidence.

Legal precedence has shown that the courts favor the side that can produce the most credible evidence, and penalize the side that provides incomplete records or consciously and prematurely destroys records. This provides a legal dilemma: In order to properly defend your organization, you must maintain comprehensive records; but, more records bring higher processing and legal costs to locate, process, and examine those records.

Keeping comprehensive records isn't the real issue though. The issue is the management of those records and the pervasiveness of email as a record.  Once you're forced into an eDiscovery exercise, you start to see that gathering email evidence isn't as easy as it should be. The reality is that email records are pervasive and can exist in many locations, many formats, and many copies. A typical organization at any one time maintains multiple email record copies between their backup systems and their online systems.
 
While duplication may exist, so may disparateness where records exist on one media but not another. It is this potential for information or record existence that prompts court-ordered discovery of all media sources to ensure that all records are provided as part of the evidentiary process. The problem of multiple information sources is not simply related to backups, other business productivity processes factor in, too. Perhaps one of the biggest problems is that of end users circumnavigating message management policies and implementing their own retention processes. This can result in remote copies of messages on local and home workstations, personal archives, mobile devices, printed copies, and external email systems.
 
With the myriad locations that email can exist within organizations and the inability of organizations to properly control or inventory those locations, it is no wonder that projected costs for eDiscovery in 2009 are estimated at more than $10 billion. 
 
In this electronic information battlefield, organizations have to be able to defend themselves by being prepared for electronic data requests but also need to be able to provide specific records. By knowing what information they possess and where that information resides, the organization can respond quickly, efficiently, and economically to information requests. 
 
In my next post, I'll follow up with a strategy that reduces the complexity of eDiscovery. This essentially turns a technical issue — that for many organizations is an obstacle — into an advantage.

]]>
Tue, 01 Sep 2009 00:00:00 GMT e39970c1-0241-48c4-bea6-7b21a0edda56
<![CDATA[Ten Security Lessons to be Learned]]> Here's a good article from Baseline on ten security lessons to be learned from the biggest data breach of all time. Enjoy.

]]>
Thu, 20 Aug 2009 00:00:00 GMT 3796f1ab-1805-4323-84c4-7f389d3355c2
<![CDATA[Enabling Email Search for Innovation and Productivity]]> Think of any high-profile project in your organization. Now, think of any files (document, presentation, project plan, budget) linked to that project. Where would you look for the most recent version of these files? On a departmental file server? On the corporate SAN? Stored in your document management system? Or maybe on someone’s laptop?

I can tell you with a very high degree of certainty where you’ll find the files — in your Enterprise Messaging System. It is pretty clear that if a document, spreadsheet, or presentation has any value whatsoever to your organization, it's being circulated among team members, partners, suppliers or customers, and at least 95 percent of the time as an attachment to an email message.

This isn't necessarily the way you want things to be done, especially if your organization has spent tons of money on a content or document management system, but it's simply the reality of how email gets used across most organizations today. As a result, we all know that email messages have come to be regarded as vital business documents, meaning they need to be stored and searchable.

However, what's driving the need for reliable, fast email search is mostly compliance and control — legislated eDiscovery, internal audits or mailtaps, and workplace litigation. It's all about finding the smoking gun. As a result most of the solutions have a narrow, negatively tinged focus. I’ve found that the decision to purchase and implement our solutions is rarely about improving knowledge sharing and enhancing productivity or competitiveness.

Time for an attitude shift! Once you approach email archiving from a new point of view and recognize it as one of the richest collaboration engines in your organization, a whole new perspective takes shape. You can start to effortlessly capture these rich conversations and content, index them, and make them available across your entire organization in new and positive ways.

Why not start to use stored email as a competitive advantage? For example, say I'm the new sales guy in an organization. The ability to search email lets me dive into the threads between customers and my company's most experienced salespeople. I can see how they walked through an opportunity with a customer. It's all right there in a threaded view: the customer's question, the account executive's reply, the attachments he included, the business case, the worksheet, the ROI information.

What a treasure trove of information. And, the organization didn't have to do anything special to compile it. Because it's email, it's organic. These conversations are taking place every day; why not leverage them for more than just that one moment of communication?

I hope I’ve got you excited about this new, more positive and broader perspective on why you should consider the deployment of an Email Archiving solution as one of your most strategic projects — instead of just a way to avoid restoring messages from backup tapes in the event of a nasty lawsuit.

]]>
Fri, 07 Aug 2009 00:00:00 GMT aabc663c-ff99-4816-b772-88c1bf1d731c
<![CDATA[Message Nirvana? Why Not?]]> In a previous post, I talked about milestones and their literal role reassuring travelers that the proper path is being followed, and to indicate either distance traveled or the remaining distance to a destination. In this post, I'd like to continue that theme and discuss our most recent milestone: M+Archive 2009.1.

Messaging Architects has always been about open standards, file format neutrality, and application independence. This is one of the design principals of the M+Platform. The new release of M+Archive simply continues this direction and achieves the milestone of fully transparent message co-location.

We recognize the reality many organizations use multiple email systems, or are investigating migration. Mailbox and message co-location is MA's open approach, and far, far better than migration.

It's also no easy accomplishment. As opposed to format transcoding, letting messages live in multiple locations at any given time is a real engineering challenge! For now, our focus has been to figure out how to let GroupWise and Exchange coexist, but Notes, Sendmail, Gmail, and others are also potential options. It all really depends on what our customers need the most.

Where are we going with this? What other milestones might be down the road? This list will probably inspire more than a few sleepless nights among my Product Managers, but here are a few things we'll probably start to work on in the coming months/years:

  • Moving messages and appointments transparently from application to application (Exchange to GroupWise to Notes to Sendmail to ... ).
  • Allowing these messages to move from on-premise to off (i.e., supporting private clouds, both on premise or off, and public ASP clouds from the likes of Google & Amazon).
  • Conversion to/from dynamic states (live messages and attachments) to static states (archived messages and fixed content/attachment stores with both point-in-time view and recovery).
  • Letting message items morph from message to appointment to task, across different messaging systems.

I'm not sure in what order these will occur — or even if they will all occur — but I can make a strong business case for each of them.

Today co-habitation is a process that involves smart agents and some heavy lifting from our pro-services team to configure the stack the right way. Eventually this will shift to intelligent message queues (pre-processors) that add meta-data to messages directly at the gateway, or as we extract and archive. This will enable our vision of boundary-less messaging and collaboration across the most important open protocols (SMTP, CalDAV, CardDav, GroupDAV) and many of the proprietary closed ones such as MAPI. This transparency will be achieved via open format translators that know how to move messages around while maintaining the meta-data as part of the message body, and our intelligent agents will understand how to process the content according to organizational policies and roles.

The message system co-habitation we are delivering in M+Archive 2009.1 is just the first step of a rather long journey, with many significant future milestones, to a destination we may never fully reach. But, we'll be making sure you enjoy the ride.

]]>
Tue, 28 Jul 2009 00:00:00 GMT 59d7377a-fb8e-4a84-973e-36b00f869ccc
<![CDATA[The Great Debate: Indexing vs. Relational Databases for Email Archiving]]> Archive vendors have long debated the merits of using indexing technology vs. relational databases to archive ESI. As a result, I’m often asked what kind of database M+Archive uses. In fact, many clients even specify a database to be mandatory in their RFPs.

The confusion primarily results from the fact that other archive vendors rely on an enterprise database such as Oracle, MySQL (which happens to be owned by Oracle), MS SQL Server, etc. Clients need to know what database they're using in advance so they can anticipate the additional cost of licensing the database, hiring expert DBAs to manage a large enterprise database, support issues, etc.

Why relational databases and email archiving are a mismatch

Relational databases are great for storing certain structured data, like the line items of expenses we have when we make budgets in Excel. The problem is most ESI such as email is unstructured data. It just doesn't fit properly in a database. Add to that the fact that email archives can run into hundreds of millions of documents. Imagine the headache of managing a database of that size.

The good news is M+Archive doesn’t need a database. Messaging Architects' use of indexing for M+Archive is unique — no one else that I know of uses indexing technology only.

So how is search performed? That’s where indexing comes along. All of these files are indexed by the M+Archive Indexing Server. All searches go against the index to be able to retrieve results in less than a second. For a client, this means you don’t need to hire a fancy DBA, and there's no Oracle license to buy/renew. Eliminating the database dependency simplifies things greatly — and the performance is scorching fast. Indexing technology was built to handle billions of documents with unstructured content.

The best way to understand indexing is to think Google. There is no way Google would exist if they had to use traditional databases. In fact, their search engine relies on a proprietary object storage system called Bigtable. The indexing technology M+Archive uses also powers another public search engine that has indexed more than 8 billion Web pages.

Indexing just makes sense, especially in the context of archiving hundreds of millions of records where a few terms hidden in one of these records can make or break a litigation case.

]]>
Mon, 27 Jul 2009 00:00:00 GMT d8e57043-0a56-4990-86f1-5267270ae969
<![CDATA[California ESI format woes on the horizon?]]> After vetoing proposed ediscovery legislation in October 2008, Governor Arnold Schwarzenegger has finally passed into law California's Electronic Discovery Act, bringing it more in line with federal ediscovery standards. There's a catch though: Under California's new amendments to the laws of civil procedure, the party requesting production of electronically stored information (ESI) can specify the format in which it should be produced.
 
But, what if opposing councel requests ESI in a format your IT infrastructure doesn't natively support?

The concept of native format might mean different things for different circumstances in an enterprise information system. For example, the structure and metadata applicable to a given e-mail might be different depending on whether the email is collected from an electronic mail system like Microsoft’s Exchange or from an archive appliance like Symantec’s Enterprise Vault. It’s my job to help trial counsel understand the different possibilities, evaluate options, and then document/explain the format decisions and actions that are executed in ESI collection and production. 
 
Sometimes disagreements about the format of ESI production must be resolved by the judge in a
lawsuit. I asked Ben Wright, noted eDiscovery blogger whether, in his experience, he finds that judges have a good grasp on the technology issues involved with eDiscovery.

Ben's reply: "The judicial system is quickly learning about electronic discovery and digital evidence. State and federal judges are indeed gaining practical experience with e-records. In their own courses for continuing professional education, judges are being trained to apply law in new technical environments, such as e-mail and Web 2.0. They are also learning how to seek help, such as input from special masters and magistrates who are better versed in technology issues. Still, technology is evolving at such a breath-taking pace that the court system struggles to keep up. Changes in technology are accelerating, as we see new developments like social networking and cloud computing arise virtually overnight."

]]>
Fri, 17 Jul 2009 00:00:00 GMT f2383955-61ae-4145-9735-3ba0a56afc70
<![CDATA[With great power comes great responsibility]]> Never before has the world's population been more connected. With access to information bordering on the absurd, suddenly anyone with an Internet connection can wield a perverse god-like savvy-ness. So while you’d think the level of common sense would be exponentially increasing, the reality is that we live in a day and age where some people are still falling for scams like those perpetrated by a con artist posing as the Nigerian Ambassador to the U.S. with twenty-five million dollars to share. Started back in the 80s, the now infamous "419" scam — named after the law banning it — to this day makes money by promising its victims much wealth. (See some undercover reporting here.)

I bring this up as just one example but, depending on your role on the Internet, the very same victims who fall prey to Internet scams may have access to your computer systems. The rich Nigerian with no friends is only one example of a personal con. Imagine the same con playing out at the corporate level, where the goal is not money, but intellectual property, client databases, inside information sold to the competition by a disgruntled employee. These scenarios aren't just the basis for cheesy movie plots, but routine occurrences that cost organizations billions of dollars.

And so, it is our duty as IT specialists to mitigate these cyber disasters, if not completely avoid them altogether. I like to call it "Business Intelligence on the Wire,” but it is also more commonly known as DLP or "Data Leak Prevention/Protection." Often positioned as a compliance requirement enabling organizations to be "regulation X-compliant,” DLP is rarely discussed in the context where it's direly needed: to monitor an organization’s inbound and outbound traffic based not only on the law but also on patterns, such as the roles and responsibilities of people in the organization. We should be asking questions like, "Why is our accountant sending out source code?" Or, "Why is the receptionist sending our client information at 3AM?" Unfortunately, most organizations don’t ask these questions, and more importantly, can’t identify if and when this kind of communication is happening.

Fortunately, the technology exists for organizations to wield that same god-like savvy-ness about their own IT infrastructures, and there is no better time to implement it and pro-actively avoid the potential scams lurking inside our own networks.

]]>
Mon, 13 Jul 2009 00:00:00 GMT c70144d2-923c-4f95-a262-b50f6dde01e4
<![CDATA[The evolving face of eDiscovery]]> At Messaging Architects, we’re in a position to see trends in how organizations deal with email. We have thousands of clients representing millions of end users, all of whom rely on email in their day-to-day work life. It’s a pretty good representation of the population as a whole since email has become the primary method of communication for business. One of the biggest and fastest moving trends in the last few years has been the need for organizations to handle eDiscovery.

So what’s eDiscovery? Well, eDiscovery or “Electronic Discovery” is just that – the act of discovery of electronic information. And what qualifies as electronic information? That was pretty much answered by the U.S. Supreme Court in April 2006 when it approved the amendments to the Federal Rules of Civil Procedure. The amendments basically outlined that all Electronic Stored Information (ESI) is deemed discoverable and needs to be easily accessible.

There were some big cases before 2006 that highlighted need for electronic discovery, most notably Zubulake v. UBS Warburg. In this landmark case, USB Warburg wound up paying $29.3 million in damages because it could not produce email evidence. A key factor in the decision: The jury was instructed to assume that any email USB discarded after Zubulake filed her complaint would have hurt the bank’s case. The updates to the Federal Rules of Civil Procedure, however, were what what really got people to take eDiscovery seriously because Electronic Stored Information is so pervasive.

What’s the largest source of ESI at any company? What is the number-one ESI requested by opposing parties during eDiscovery? Email. Email — the preferred way to communicate in the 21st century — is ESI. More often than not, if your company gets sued or is under investigation, your corporate email needs to be discoverable. As a result, eDiscovery has grown from being a "nice to have" feature to becoming the main driver for organizations looking to deploy an archiving solution. Fast forward a few years from 2006 and eDiscovery has matured; organizations such as EDRM are leading the way in formalizing the eDiscovery process and getting a large group of legal firms and technology vendors together.

Over the course of the next few blogs, I’ll be talking about eDiscovery in a bit more depth. I’ll take a look at how our products can help facilitate eDiscovery, but also why it’s important to understand the policy and legal reasons behind the technology.

]]>
Thu, 09 Jul 2009 00:00:00 GMT ec88f3a7-9e88-466e-87e8-d58b16cdb36e
<![CDATA[About technology and milestones]]> Wikipedia defines traditional milestones as objects constructed to provide reference points along the road, used to reassure travelers that the proper path is being followed, and to indicate either distance travelled or the remaining distance to a destination.

The technology industry has adopted a lot of the vocabulary from the roadbuilding sector; we talk about product roadmaps, routes to market, paving the way and of course the ubiquitous milestone.

In many ways this first blog entry is a major milestone for Messaging Architects. It is a reference point along a road to build a more user-friendly web presence for clients and partners and is the combination of many months of work by our dedicated Product Marketing team.

Most of you have noticed the complete website overhaul that has taken place. We are quite proud of our new website and we've received numerous positive accolades and feedback about both the layout and the content. The unveiling of this blog section is part of our larger strategy to make our site a regular destination for Email Administrators and Policy Gurus, and it is part of a journey that started almost 15 years ago.

Over the years, we have helped thousands of clients and millions of end users to deploy robust and secure messaging infrastructure - or as we call it Business Driven Email. In the coming months, you will see others at Messaging Architects contribute their observations, knowledge and passion.

It is all part of what we perceive to be our mandate to provide thought leadership, awareness, conversation and perhaps even controversy on the topics that concern us, and you. It helps drive the bigger picture, our role as technology developers and global providers of risk management for enterprise e-mail. Hopefully you'll find some gems, some humor, some best practices, and many practical tips and tricks that you can implement overnight.

In future posts, I'll discuss some milestones that we've achieved recently and why I think they are significant.

]]>
Tue, 16 Jun 2009 00:00:00 GMT a55fcb35-56b8-4ce4-bb05-5e03d388a9de