This is a big day for Aircell, which spent tens of millions to acquire the exclusive spectrum license that allows them to shoot Mbps to and from planes. My big question will be whether coverage remains seamless across an entire flight--how often one has to reconnect their VPN would be a big issue. If Aircell has architected the network correctly, passengers should never be reassigned an IP address, and connections shouldn't be dropped even if there's a hiccup in air-to-ground communication.

I've covered in-flight broadband for several years, and I've been wondering lately whether we'd be waiting until 2009 to see real production service. American is calling this a 3-to-6 month pilot to see what their passengers think. Just yesterday, I wrote up veteran travel writer Joe Brancatelli's frustration with the lack of information and some misinformation about in-flight broadband.

You can read more background on American's plans and Aircell's technology in a post I wrote for BoingBoing on 24-June-2008.

An interesting blog post this morning discusses the obstacles and implications of this kind of technology, in part quoting a recent New York Times article —

In short, we need a log-on system that relies on cryptography, not mnemonics. As users, we would replace passwords with so-called information cards, icons on our screen that we select with a click to log on to a Web site. The click starts a handshake between machines that relies on hard-to-crack cryptographic code.

An obstacle to this kind of system are the current initiatives toward Open ID and single-sign on services, strategies that are backed by large industry players such as the Equifax, Google, Novell, Microsoft, Oracle, etc. In the open ID system, you would log in to a session on the web with one password, which would be accepted by any application/account supporting the open ID infrastructure.

To me Open ID sounds like a step backwards, toward less security…
then again, I would think that encrypting everything could also make your system run significantly slower, and that it wouldn’t prevent all the risks either…

ScienceLogic: Mike, what’s your background working with network and management system tools?

Mike Lawson: Before joining Apptis, I worked for the Air Force, mainly in satellite communications for almost nine years. I’m probably most familiar with HP OpenView and BMC Remedy. I managed a team that used them but wasn’t involved in tool selection; like many other federal IT workers, we didn’t have a choice of tools because there were existing enterprise licenses and maintenance contracts.

I also saw a large systems integrator do a full Remedy/Crystal Systems/OpenView installation. It took 6 weeks to stand up and customize to meet just the basic monitoring requirements, and it cost something like half a million dollars. At the time, I thought that wasn’t bad and was a pretty typical experience.

ScienceLogic: Coming from where you did, what’s your take on EM7?

Mike Lawson: Honestly, I didn’t believe that EM7 could really do all that it claimed. In many ways, it was the complete opposite of what I had seen first-hand with other monitoring solutions. Could it really cover that much functionality? At relatively much lower cost to the customer and without the licensing nightmare?

That quickly changed when I needed to understand the system enough to run it at a customer’s site. I went back over the training docs I received during my initial training class and jumped in; now, 6 months later, I’m the EM7 expert and can tell you that it delivers on all those promises. (But I still need to show people to get them to believe it too)

I preach the “EM7 gospel” and when anyone wants to talk monitoring, I ask about the universal pain points: cost, maintenance contracts and licensing, and then I explain EM7. The cost difference is real; the solution is based on capacity, so there’s no licensing and it’s easy to use. They are shocked to learn that they can buy multiple EM7 appliances and years of maintenance for what they paid for most other tools.

ScienceLogic: Apptis won the contract for monitoring aboard the USNS Mercy. We love that you’re using EM7 for one of the Navy’s hospital ships. Can you tell us more?

Mike Lawson: The USNS Mercy is a Military Sealift Command hospital ship. Some stats:

• 849 feet long (nearly the size of a football field)
• 12 fully-equipped operating rooms, a 1,000 bed hospital facility, digital radiological services, a diagnostic and clinical laboratory, a pharmacy, an optometry lab, a CAT scan and two oxygen producing plants
• Crew: 61 civilian mariners, 956 Naval medical staff, and 259 Naval support staff

The USNS recently departed on a five-month humanitarian mission in the Western Pacific and Southeast Asia in support of Pacific Partnership 2008. The partnership provides international medical, dental and engineering teams this summer to provide humanitarian support and conduct joint, combined, and cooperative Civil-Military Operations in order to improve regional stability and build partner capacity to respond to natural disasters and pandemic.

For the most part, the ship’s network is self-contained, but can also use a landline when docked. The network covers 400 devices, including Windows/Exchange servers and VMware for server virtualization. Prior to using EM7, none of the monitoring was integrated; each system was independently monitored through individual vendor-specific consoles.

Out of the box, EM7 provided integrated systems, application and network management for all network gear, applications and virtual machines in one solution. We didn’t have to do a lot of customization – EM7 includes best-practice based thresholds, event and monitoring templates and this covered what USNS Mercy needed to monitor.

ScienceLogic: You’re a systems integrator with a very useful “customer point of view” when it comes to looking at tools. From that perspective, can you share what you think are the biggest benefits that EM7 provides?

Mike Lawson: First of all, EM7 stands up right away. We’re talking days, not weeks. In contrast to the lengthy installation of OpenView and Remedy I witnessed during my military career, I was able to configure, customize, and implement the EM7 solution for the USNS Mercy in three days.

Second, it’s easy to train people on and the support is outstanding. This judgment is from first-hand experience. Right before the USNS Mercy departed on its latest voyage, the system administrator I had trained on EM7 left, so I had all of a day to train some new EM7 admins. I prepared a seven-page “cheat sheet” and over a 3-hour conference call, we walked through the entire EM7 solution; I haven’t gotten a support call since.

And when a problem did crop up with a device being discovered incorrectly, ScienceLogic was very responsive. We contacted ScienceLogic support on a Saturday and they created and emailed us a video to help troubleshoot the same day. Within 30 seconds of watching the video, the problem was resolved.

Finally, EM7 helps us be good stewards of the government’s money. This is very important to me personally and to Apptis as a company. Because EM7 is cheaper and deploys so quickly and easily, you might think that it’s just the opposite of what a system integrator would want to use. But that’s short-term thinking. We believe in deliver the most value for customers every time. It’s what creates trust and long-term relationships with our customers. Instead of that half million spent on standing up the solution and basic setup, I’d much rather (and I know the customer would rather) spend that on fine-tuning or extending the solution to do much, much more.

As a former government employee, I know what it’s like to use a tool that doesn’t fit my needs. EM7 proves that the best solution can totally break the old model of costly, lengthy installations. EM7 has the right model: the right solution and the right price delivered as an appliance that is easy to deploy, train on and use.

ShareThis

Back to CEP and EPTS, there are folks who appear to believe they may define “CEP” by the current use cases from self-described CEP vendors. Frankly speaking, I am puzzled by the bottom-up approach.

The bottom-up approach is a bit like saying “We have a lot of prototype rockets being built, so let’s define the future of space travel based on the prototypes!”

It really makes little sense, at least to me, to attempt to define CEP based on what the current generation products (self-described CEP products) are capable of doing.   

From my persective, it would be more beneficial to customers to define the types of complex events (and situations) businesses need to detect in real-time and match the technologies and solution architectures to detect those events, in real-time, with high confidence.

A lot of this “top down thinking” has been already done.

IT businesses need to detect operational threats and problems, and be able to pinpoint, with very high accuracy, where the problem is in a complex network, for example.  This problem remains mostly unsolved with a very low signal-to-noise ratio.

Also, most businesses would like to detect fraud and other criminal activity on their network before the activities adversely impacts their business.   This problem remains unsolved for most companies.

Scientific researchers seek models of weather, epidemiology, and so much more; and they need event processing solutions to obtain situational knowledge into current events and predict future ones.  We know how difficult predicting the weather can be!

Folks on the ground need to model urban traffic as events and design better event-driven traffic models and solutions.

The list of important event processing challenges we face go on and on.  

While I see some merit in the bottom-up approach, it is better for users to define what are practical “complex event” related problems and then look for the solutions, vs. define the solution and then look for the problem.

From a strategic perspective,  self-fulfilling CEP use case studies are interesting, but they hould not limit the vision, definition, and future of processing complex events; and be careful of use case fallacies.

The trick to doing this is not to hardcode things like host, port, etc. for your SMTP server when you use System.Net.Mail to send mail. Instead, use the default ctor for SmtpClient as I've done in the code below.

static void Main(string[] args)
{
    // note the use of the MailAddress class
    // this allows me to specify display names as well as email addresses
    MailAddress from = new MailAddress("admin@fabrikam.com", "Fabrikam Website");
    MailAddress to = new MailAddress("mari@fabrikam.com", "Mari Joyce");

    MailMessage msg = new MailMessage(from, to);
    msg.Subject  = "Testing 123";
    msg.Body = "This is only a test!";

    // note use of default ctor
    // this looks in config to figure out how to send mail
    new SmtpClient().Send(msg);
}

What you're telling .NET by using the default ctor for SmtpClient is, "please use my config file to figure out how to send mail". Now you can use the system.net/mailSettings/smtp section in config to specify the details of your mail server, and all of the code in your app that is written to use the default SmtpClient ctor will inherit these settings. Here's an example of what the config on a production server might look like (if you put passwords in your config files, be sure to encrypt those sections):

<configuration>
  <system.net>
    <mailSettings>
      <smtp deliveryMethod="Network">
        <network host="mail.fabrikam.com"
                 port="25"
                 userName="WebsiteMailAccount"
                 password="whatever"/>
      </smtp>
    </mailSettings>
  </system.net>
</configuration>

During development, I use different settings because I don't usually want to deal with the hassle of installing an SMTP server on my development box. Instead, I want email messages delivered as individual files in a directory on my hard drive (I always have a c:\mail directory on my development box for just this purpose):

<configuration>
  <system.net>
    <mailSettings>
      <smtp deliveryMethod="SpecifiedPickupDirectory">
        <specifiedPickupDirectory pickupDirectoryLocation="c:\mail"/>
      </smtp>
    </mailSettings>
  </system.net>
</configuration>

Now when I run the program above, I get a .EML file in my c:\mail directory:

Outlook Express is normally registered as the viewer for .EML files, so double-click the file to view it:

If you've never seen this method of simulating email before, I hope you find it as useful as I have. Happy coding!

• Certified Information Systems Auditor (CISA) : http://www.isaca.org/cisa/
• Certified Information Systems Security Professional : https://www.isc2.org/cissp

Are You Ready ?
A few basic questions to ask yourself to gauge how ready you are:

• Do I meet the spirit, and not just the letter, of the experience requirements ?
• Has there been sufficient diversity in my experience ?

Five Step Approach to CISA or CISSP Exam Preparation

1. Perform an initial benchmark and assessment of your readiness
2. Read a “survey” level preparation guide cover to cover
3. Perform a secondary benchmark, and compare your readiness
4. Review official, or “deep dive”, preparation materials on areas identified as your weaknesses
5. Re-benchmark, and repeat targeted reviews until ready

CISA and CISSP Preparation