Enterprise Telephony Business Case : Morisky Surveys

I'm often asked to give an examples of a business case for a deep integration of the business process with telephones, so here's a good one for you: Morisky Surveys.

Morisky surveys ask four questions that can determine, with fairly high accuracy, a patient's probability of adhering to a course of drug treatment.  In other words, the survey can tell the doctor what the likely hood is that you'll finish your bottle of pills, take your shots, etc.  The health impact to patients, and to the health care companies that provide his care,  of NOT sticking to the plan can be critical.  For instance, in people with diabetes, tight blood glucose control is correlated to reduced complications, and control is affected by medication adherence (Medication Adherence, Journal of Diabetes Nursing, Feb 2005).  26.9% of people with Type 2 diabetes have poor medication adherence. 20% of the elderly in the United States have this form of chronic illness.  Both patients and health care companies have vested interests in reducing the complications from the disease, which can be reduced through compliance. Those patients that may not comply with the course of treatment can be identified using the four question Morisky survey.

In comes mashup telephony, which can use elements such as Voice XML platforms and services, database driven web sites and social networking features to identify which patients are likely to need extra help with their medication. Patients can be called with the survey to determine which ones need a visiting nurse, reducing costs for the HMO (which can be monetized) and increasing quality of life for the patient.   This drives the financial model for the business case.

The fact that it's a mashup architecture makes it practical to implement on many fronts. First, the costs of demonstrations are amazingly low,  with the only costs of demonstration being the engineering time to create the survey (a week, at most), the costs of hosting ($100.00 a month) and the incremental cost of making the calls (0.10 to 0.25 cents per minute).  Secondly, since the demonstration architecture is identical to the deployment architecture, it scales very nicely. Since it uses a web services architecture, integration into the current enterprise back end is straightforward and achievable with internal staff or external consultants. 

The Morisky Survey is only one of about ten such integrations that we at my company have found in the past three months, and that's only counting health care.  Since the barriers to entry in terms of up-front investment and ongoing costs to implementing telephony solutions have fallen so far, these ideas are now practical, and I hope one day, wide spread.

Cluecon 2007

Well, off I go to the ClueCon 2007 Conference. If you will be there, I will be speaking with John Hibel, VP of Marketing for Voxeo, at 1:30, and we'll be describing the demonstration voice mashup I wrote using Voxeo's Evolution Designer, Amazon EC2 and Ruby on Rails. If you can't make it to the show, and still want to hear the demo, why don't you give it a ring at (407) 982-5896? It's not perfect, but I think it gets the point across.

If you want to see how I did the first part of the demonstration, I did up a quick screencast here. I'll make it more formal after the show, and add in some Ruby and EC2 stuff. See you there!

$12,107.09

I might be misquoting here, but I believe I once read in Playboy Interview with John Kenneth Galbraith that his biggest disappointment with people was that they sought out data that supported their currently held postions and opinions, and rejected all other data. With that firmly in mind, I nonetheless want to share Guy's post entitled : By the Numbers: How I built a Web 2.0, User-Generated Content, Citizen Journalism, Long-Tail, Social Media Site for $12,107.09. In it, he details what he spent, in time and in money, to launch his often reviled, and often visited, new site called Truemors. Of course, his initial success has a lot to do with the fact that it's Guy Kawasaki that launching it, but let's face it : $12,107.09. As I recall, that was probably the monthly fedex bill for the smallest of the 2000 class of VC funded startups.

I call your attention to it to illustrate my currently held belief, that service providers are so easy and simple to deploy that the game for all businesses has fundamentally changed, not only for service providers. As the costs to deploy these sorts of services goes down, the required market share to support a busines is much smaller, allowing much more targeted businesses to be created. This drives my focus into the new Web services based architectures, which are ideal to support businesses exactly like this. I was not surprised to see an Amazon Web services URL flash by on Truemors...

As I look at the recent crop of Voice Over IP startups, I use this picture of the future to predict the success of my industry peers. It's why I like Twitter as a small, bootstrapped place, but have a hard time seeing valuations that would support massive investment into it. The technical implementation of Twitter, to telecom standards, is nearly trivial. The mob effect and it's value to the mob seems marginal to me, but the service and infrastructure are useful, and if they stay close to customers that will pay, they'll do quite well. Apparently, Twitter is out to raise some dough. For their sake, I hope they fail there, and succeed by sticking to their knitting.

I think I ought to get some sort of report card together to help me keep my thoughts. How would Twitter fare?

• I'd give them a B for technology, as they did a good job with integrating existing technologies, but have not really made any new technology or architecture improvements. A decent job there, but not exactly Stanford or MIT.
  
• I'd give them an A- for business if they don't take investment (and a definite C if they do). Twitter's service is still very horizontal, and as such, can be commoditized. However, the service itself is quite cool, and has many applications, and they have first mover advantage.
  
• We need to give the Twits an A for buzz. Like a friend of mine in the Valley says, they love Twitter because they showed that using text messages was something that people might even like to do. I agree. I'm a fan.
  

SQS: Messaging Backplanes in Communications Architectures

For me, 2007 looks like the year of messaging backplanes. As an architect, it's a wonderful thing. Long a staple of enterprising messaging architectures, such as financial transaction applications, I believe it to be a very valuable addition to the standard telecom architecture. I'm doing two independent designs at the moment based on enterprise messaging technologies. The first is a gateway between two messaging architectures, designed to help customers migrate legacy messaging applications. An excellent project for me, as if you want to truly understand a protocol, do a gateway that converts it to something else.

The second project is an internal project we'll announce sometime later on in the year. For this one, we are using a hosted messaging backplane from Amazon called Simple Queue Service. (In fact, we are using nearly all of the Amazon APIs in the hosted version of this project, including the elastic computing cloud, simple storage service and, of course, the Turks.) Simple Queue Service, or SQS for short, is a simple, but extraordinarily powerful idea. SQS allows software to send messages between applications in a reliable and scalable way, using Amazon's hosted service. Messages are created by message producers, stored in the queue, and read by message consumers. Many different message producers may add to the same queue, as many different consumers may read from it. Amazon guarantees that a message is read at least once, and will hold a message for at least fifteen days. In practice, messages tend to be consumed nearly instantaneously, but it's good to know you've can go get a cup of coffee and not worry too much about missing a message. Messages can hold any data and, when combined with Amazon's simple storage service, can hold any data of arbitrary size.

An example might help here. Imagine you are designing a billing system for a large telecom carrier. If you have a switch creating call detail records, you could store those CDRs as an XML records in a local database. You could also take that XML data, and put it into an SQS queue to be read by a far end billing system. The billing system would wait for the XML record, and when it arrives, record it, bill it, invoice it, whatever. The calls to SQS are very simple and straightforward, and the service itself is quite inexpensive. Today's alternative implementation would probably use a standard such as Radius, which is supported in the billing world, has no traction outside of ISP billing in the Web world. SQS is a simple and straightforward alternative.

The advantages are numerous. First, since many producers can add to the same queue, you could use SQS to aggregate information from several sources. So, to extend our example, you could aggregate CDR data from many switches into a single outbound stream. Since SQS carries data only, different manufacturers can submit their XML into the queue without any impact to the billing system that consumes the data. Let's keep with the CDR example, and imagine that one of your twenty switches uses a different XML format than the other nineteen. Pretty simple with SQS. Create a piece of software that reads all of the XML from the aggregated stream, looks for the messages that need to be translated, translates and puts them back on the aggregated queue. Worried about the bottleneck? Don't be, as you can have as many instances of translators as you wish, as SQS guarantees that a message is read at least once, and if you wish, only once. The same argument is made for redundancy. You can have as may consumers or producers as you wish. If one fails, your throughput does drop, but the rest of the system is unaffected. (By the way, this is where the elastic computing cloud just rocks. Throughput dropping? Take 60 seconds to spin up a hundred or so servers to take care of it until you catch up, then give the servers back. Since a server costs about ten cents an hour.... well, you do the math.) This also makes components that hang off the message stream safer to deploy in production environments, as you can fractionally deploy components without affecting the core system.

The downside? Messaging backplanes do introduce a bit of delay into the system, and are probably inappropriate for communication between components where real time operation and response times must be guaranteed. As I think about the heuristics of real time design for web services based communications infrastructures, my gut tells me that the logical place for components is where real time communication is critical, where bottlenecks would occur, or where linear scaling is critical. Those components would then be best implemented in an Web Services, or SOA, architecture with messaging backplanes as the scaling and communication backplane.

We've been talking about Amazon SQS, which is undeniably the only reasonable hosted choice we have today. In a platform environment, there's a number of good choices ranging from legacy offerings from Tibco, down to the open source ActiveMQ offering. But honestly, the Amazon web services suite is so easy and inexpensive to use, it would take a lot for me to deploy my own platform. I suppose if you're Verizon, you could match the Amazon platform. Maybe. Either way, I expect to see communications architectures move from the inherently fragile legacy telecom designs towards new, service oriented designs, all on the backs of messaging solutions.

Mashup Camp : Day 2 : Amazon EC2 Web Services

Starting out here at day 2 of Mashup Camp. This is a shorter day for us than yesterday, but I think we're going to make up for it in quality. The first conversation that I'm attending today is given by Amazon, and concentrating on Amazon's Elastic Compute Cloud. In essence, EC2 are computer in the sky. Why have a computer working for 700 hours, when you can have 700 computers working for an hour? The EC2, you can scale capacity up and down in minutes. Developers can control their machine instances, and is very inexpensive, since you only pay for what you use. If you only use 700 hours, you only pay for 700 hours.

EC2 works with amazon machine images. You can clone these images over as many servers you want using a web services call. Typical images contain LAMP stacks, Ruby or Ruby on Rails. Once you have loaded that image to one EC2 instance, you can clone them to as many as you need, and tear them down. The example Jinesh (our speaker) is using is a typical web server farm, where a load balancer is sitting in front of ten web servers. You can increase your capacity by adding an eleventh server, or decrease your capacity by removing one. It is your responsibility to update the web balancer with the IP addresses of the server.

Now, here is (for me) a very exciting development for VoIP. With a system like amazon web services, you can quickly scale up the capacity of your VoIP service. You simply add more servers to your application. Here's an example. Imagine a SIP application server running an application like voicemail. In front of the application, put a SIP proxy server to load balance inbound calls. Instantiate a single instance of the SIP proxy server, and a single voicemail server. Run these both on an EC2 servers. (By the way, if you were using it all month, it would cost you $72.00 a month for one of these servers.) Adding subscribers? Add an EC2 server. Shampoo, Rinse, Repeat. At this point, the software you want to write will manage your server instances.

It gets better. Want to update the voicemail? Simple, take a new EC2 server, put the new image on it. From the SIP proxy server, send a small amount of calls to it. Test it. Work OK? Great - start migrating over. What about storage? You can use Amazon's S3 to store the data, with a similar dynamic nature. Want it to sync to your local database? No problem, use the S3 web services interface to synchronize it with your local data storage. And you have done ALL of this without buying a single piece of hardware. Of course, all of these things COULD be done by buying your own hardware and putting it into your co-location space. How much money are you spending on installation and maintenance of your servers?