Building n-Tier apps can be difficult. Instead of a single monolithic application that can easily hide its imperfections, a client-server model traditionally means making an API, choosing a transport, and sticking to it.

It’s like marriage, but with TCP/IP settings. Throw in a wireless client and it can be difficult to find a solution that fits. XML-RPC? SOAP? REST? Each way of communicating has benefits and drawbacks.

This is what we’re doing for client X, a niche healthcare business.

The requirements for the project are a web site with both static content and user-only pages with geolocation, pricing and communication features. These features are duplicated on iPhone/iPad and (in the future, Android) clients.

The obvious solution is an n-Tier architecture where we can centralize the business logic. The less obvious part is how to communicate with it. The iPhone app (Boomer) is using a wireless connection, so lightweight formats are obviously attractive. Also, iOS has a poor selection of XML-RPC and SOAP clients, so a JSON/REST solution makes sense.

On the other hand, the web client (Apollo) is running in the same location – initially on the same server – as the client, so it can use a fatter, more full-featured connection. Since we’re using Microsoft stack for this project, that means WCF. WCF also generates model code for the web client, so most of the work is just converting these models into HTML output. The server (Athena) consists of both conventional and restful WCF services each accessing the core logic of the server, which in turn consists largely of LINQ-based interaction with the database.

The neat thing about offering parallel services like this is that it makes adding additional transports much more straightforward. For example, if client X decides they want to use an RPC-based tool with the server, it just means adding another service; the business logic has already been prefactored out of the way.

We copy/paste the elevator pitch from the CoverMyMeds website many times per week. Not because it is easier, but because it is the best 15 word summary of our company that we can write.

But the best part about an honest and simple elevator pitch is that it can be used by others outside your company: your happy users, your partners, and the press.

And today, I received an email from HealthTechTopia that we’ve been awarded their #2 slot in the 25 Notable Startups that are Changing the Medical Information Industry. We’re listed among a number of very good companies, many of which I know, but something that struck me is that we had one of the only usable elevator pitches on our website out of the whole list.

Unfortunately, I’ll need to pick on someone to illustrate my point.

CoverMyMeds helps physicians and pharmacists complete Prior Authorization and other insurance coverage determination forms for any drug and for most drug health plans…

DOMA Technologies: This is a privately owned Virginia Limited Liability Corporation founded in 2000, which provides Software as a Service (SaaS) document management applications and services aimed across multiple vertical markets…

Assuming you even care about healthcare IT, which description is better? Without a good pitch, the nice folks at HealthTechTopia had to work very hard to describe what these other companies do-and it probably isn’t the very best explanation these companies could offer.

What we’ve done is improve our chances of being listed and described positively, with nothing more than a simple paragraph on our homepage (but lots of thought about who we are).

Let me close with a few simple metrics we have to evaluate our pitch. A good pitch is something that:

• A real person would repeat to their friend/colleague without feeling like a dork or shill
• A (non-paid) person can actually remember
• Describes why we matter and who should care
• Is differentiated from other pitches, but is relevant to problems to which the mainstream can relate
• Is copy/paste-able in an email or website
• Everyone in the organization is happy to repeat to open sales calls and meetings

Download the slides (4.8MB PDF)

This is the PDF version that was shown at the OWASP presentation (including the OWASP chapter introduction), with the following changes:

• HIPPA spelling corrected to HIPAA (yes, I work in this field).
• OWASP’s PHP ESAPI (Enterprise Security API) link added near the end of the presentation.

Since I’m horrible at remembering names and faces, I can’t actually give credit for these fixes. If that was you: let me know, and I’m sorry.

Important Note: There’s an example of how to implement a Random Form Token to help prevent against CSRF attacks. This is a very naive implementation — in particular, since the token is generated from the current timestamp, someone could (with the proper tools) guess the correct token, which defeats the purpose of having the token at all. This was all covered during the talk.

The presentation (at least my part) was developed in Keynote, and I have the source files available if anyone thinks they’d be useful.

Chip, Eddie, Keith, Reva, Matt, Dan, Jon, Michelle, Scott, Amanda, Bruce, Mary, Kent, Brian, Robert, Chris. Chad, who holds court at the Oregon branch office not pictured.

It turns out that Flickr does the same sort of thing. Their solution: flags and flippers. Interesting read.