Monday, August 27, 2007

Moving On Up


Well, the time has come to move the blog off of Google, and on to our new site at The Thomas Howe Company.  Pat and I will be posting to our blog there, and we're just going to let this one mellow with age.  (I'm going to imagine that, in this allegory, I'm George because I'm shorter than Pat.  Pat can be Weezie.)

See you on the other side.

Wednesday, August 22, 2007

Brian Mahoney and Jon Arnold Podcast: IPTV

When you have a chance, check out Jon and Brian's Podcast on PulverMedia. If you are basically unfamiliar with the IPTV market, this is an excellent introduction by one of the best marketing guys out there. Brian and I worked together at Netcentrex, and now he is the Vice President of Marketing for Espial, a leading vendor of IPTV middle-ware that recently went public. I think my days of PictureTel cured me of video, so I'm not sure I'm moving into IPTV anytime soon, but if you want to see good business cases for small, niched applications and programming, I think the IPTV market has them in spades.

Tuesday, August 21, 2007

Ruby and The Role of Culture in Development

In the Web Integrated Telephony Architecture, I identified the middle piece as being a Ruby on Rails application. It accepts data from the User Interface (commonly implemented as Voice XML forms), and then drives action through Web Services, and for WITA, telephony web services. As I thought about this component, there are actually a number of technology choices. This could certainly be a Java component, as the functionality would be equivalent. You could argue about speed (as Java does run faster), and you could argue about installed base (Java is much more prevalent in the carrier and enterprise). Each is fair, each has technical advantages over Ruby.

The reason why I advocate Ruby is straightforward : it's what the cutting edge Web developers use. When I coined the term WITA, I wanted to emphasize that this was a Web integrated architecture - not an IP integrated architecture. By integration, I mean integration of culture - the way that the community approaches, understands and tackles problems. In order for telephony to spiral into the much larger market of the Web, and therefore into the Enterprise, it needs to be introduced into the culture of Web development. Ruby is the prime ambassador for this, especially on the cutting edge of development.

This will, undoubtedly, cause major headaches for telecom engineers, who by-and-large have no experience with Ruby. (Maybe this is the Karmic payback, as the Ruby developers have no experience with phones). However, when the Web mindset is adopted and understood, then Ruby becomes a natural language for its implementation and development. In time, it may become the lingua franca of Web development; certainly Web development over time will become the definition of programming and architecture. The successful implementation of WITA applications will require the adoption of this mindset. Personally, I have pushed myself down the Ruby road primarily for culture - so that I can learn Web development in it's native tongue.

I feel there is no point where this is clearer to me than when I consider IMS. As an architecture, IMS is clearly the son of the companies that advocate it: big vendors making big equipment for big carriers with big budgets. It is a product of the culture of carrier based telecom development. The essential issue is that IMS, although making claims to enable the deployment of innovative services, makes the implementation of new applications nearly impossible because of culture. It is unreasonable to think that development of high value, niche applications is served by ever larger architectures. It is implausible to think that, with a ratio of nearly ten Web developers to one telecom developer, that the web developers will toss Ruby for P-SCSFs and HLRs. I recall a conversation with Henry Sinnreich a few years ago, where he said that he loved SBCs, as they hastened the demise of carriers because they were wasting their money purchasing them, instead of deploying pure SIP networks. I wonder if IMS has sent him into some sort of Nirvana.

Ruby is about culture. WITA is about deploying telephony architectures where that culture rules.

Monday, August 20, 2007

The Depressing Mashup of the Week

Apparently, the one thing you don't want to be in LA is a male Hispanic on Sunday. Avoid that, if you can. Especially if there's a gun around.

I love my hometown on Cape Cod, and (I can't believe I'm saying this) when I see things like this, I wish it could hold more people.

Mashup Competitions (or Telephony Finds it's Tail)

Well, the ten thousand dollar VoxBone competition is now over, and Oigaa from VozTelecom took first prize. Oigaa is a web based telephony service targeted towards small and medium businesses, much like Flat Planet Phone Company. My congratulations go out to them; it is an example of a service that simply could not have existed five years ago. I was considering entering the VoxBone contest, but I know I have the greatest success in my projects when they come from the heart. Personally, I like VoxBone's API for allocating PSTN numbers I can forward anywhere, but every unique and commercially useful idea I had was a bit purient. My Mom might read my blog one day, and I don't think I ought to get myself in that situation. Damn - maybe I just did.

As I'll reveal soon, the mashup contest fad is coming to our neck of the woods too. Have you ever stopped to ask why there are mashup competitions, but not VoIP design competitions? Sure, on the trade show floor they have some "best of shows", but we all know how that game is played. You don't see designs done just for competition in telecom, but you do in the Web / Mashup world. As an example, the 2006 Mashup camp mashup I liked was the blinking Google pin. Some geek took a blinker pin from the Google booth at a trade show, attached it to the serial port of his laptop, used the Google Mail API to check for mail, then it blinks the "G" when new mail arrives. So geeky. But why compete with mashups?

The knee jerk answer is: because you can. Mashups are pretty simple to put together, but more so, you can do pretty creative and impressive things with them. Mashups are more about imagination than shear technological prowess. Designing even the simplest of VoIP devices (say a phone) requires an impressive amount of time and money, much more than the typical engineer can afford. (Never mind skill set.) More so, designing even the simplest of VoIP devices for a competition is more than most companies wish to spend in time and money. Therefore, the marketing kick or product risk doesn't make sense for traditional services, but not so for mashups.

The business answer is: because every Internet technology has a long tail. Amazon proves that products have a long tail. iTunes proves that music has a long tail. EBay proves that junk has a long tail. Mashups prove that Web services have long tails. Telco Mashups prove that telephony services have long tails. And that's stunning, because it means that we finally have an environment in which we can create new services. After all our efforts since the divestiture, it comes down to the simple fact that single greatest reason that new services often fail is not because people don't want them, but they were too expensive to develop and deploy for the masses. When they are inexpensive enough so that you can make one just for yourself, then people develop them just for themselves, or rather, just for mashup competitions. Just like iPTV, if you can make a video in your house that ten thousand people want to see, it makes complete sense to make it. NBC needs what, a million viewers to break even? If you have ten thousand people who will pay ten bucks a month for your find-me-based-on-my-facebook-whatever service, you and your two technicians will make a living. In the grand scheme, a good one too. Mashup competitions are, for me, prima facie evidence that Telephony has finally found its tail.

Technorati Tags: , ,

Wednesday, August 15, 2007

Thank you for some serious link-love

Wow - thanks to all of you out there for some serious link love: Ken Camp's Post, Jon Arnold's Post, Solomon Ige's Post, and Phone Boy's. As I told Ken, I sometimes feel like I'm designing in a cave, and never really know if anyone else cares. I absolutely love what I do for a living (and I know some of my clients are hoping I'm going to say that I would do it for free), but it's a pleasure to see someone else cares, too. Thanks.

What's even better, though, is that these bloggers have readers, and at least some of those readers are just like me : telephony guys trying to create cool things that people will use. Each of these guys recognizes that telephony engineers have a new tool in the box : mashups. And hopefully, because of this sort of light weight programming model (I call it the anti-IMS), the wider world of engineers have a new tool in THEIR box : telephony. Telephony was once heavy weight, now it's light weight. Telephony used to be capital intensive, now it's pay-as-you-go. Telephony integration used to mean that enterprises would buy telephony equipment and integrate it, now enterprises can integrate with hosted, online solutions. Telephony mashups provide the right sort of light weight programming models that finally lower the barrier to integrating telephony with applications that will allow all engineers, not just us deep telephony geeks, to include telephony in the application.

Sure, there are a bunch of tools in our tool box, but for me, mashups are a keeper.

Fall VON Innovator's Track

Well, now that the programmable web ball is rolling, we're getting ready for the tradeshow season. A big part of that for us is going to be in our hometown at this year's Fall VON in Boston (Wait a second. Does that mean we have to buy the beer?) Carl Ford, a pretty impressive bunch of telephony guys and I have been working on a new addition to the VON show floor : the innovator's track. The innovator's track is roughly based on an unconference, and is focused on cutting edge telephony innovations. Our basic model is to have eight sessions, and we're sort of looking at the following topics :

Rapid Apps on Rails:
A discussion about the impact of Ruby on Rails, Ajax and other tools that aid the developer in building new services rapidly and how combined with Amazon and Level services represent a new era in service deployments.

Enterprise 2.X
This is a discussion that looks at how the Enterprises are finally gaining the ability to provide services across a network and how it changes service models.

Social Networking
According to Cisco its working. Social networks are eating up the bandwidth and the Internet is again growing. What makes these services compelling and who is going to gain from these changes.

The New Age of Communication
We have talked about the concept of these new services now lets look at some of them and lets talk about why this is the perfect time to
offer services in the marketplace. Is the price of rollout so low that adoption can be small and niche, or do we all need massive viral adoption?

New Services with old lines
Single Number is thing of the past, now we have disposable numbers and with the ILECs having to watch the Cable companies expand into their space the time may be ripe for these kind of services. Best of all by extracting the person from the number the service is much more intriquing.


As you might notice, there's only five topics here. That's where you come in. Not only are we looking for audience participation during these five sessions, but we need to hear what you want hear at the show. Do you have an idea for a topic that's not here? What problem are you trying to solve? Something you really need to learn? Spit it here, and we'll talk about it there. Bring your two feet with you, participate, and let's make this worth more than our time.

Tuesday, August 14, 2007

The Thomas Howe Company Now In Partnership with Programmable Web

Well, the day is here - today we announce our partnership with ProgrammableWeb, the leading go-to place for mashup developers. I met John Musser at the O'Reilly Web 2.0 show this March, and we've become fast friends and partners. John's site is invaluable to everyone in the mashup community, and all of us at the office are flattered and excited to be part of that family. We see our position in the market as ambassadors of telephony to the larger Web community, and as ambassadors of the Web world into the telephony market. ProgrammableWeb is the capital for mashup developers, and now telephony has established an embassy.

If you haven't visited ProgrammableWeb (which is to say, you haven't written a mashup or web services based application), here's some places you ought to look at real quick:

  1. Let's say you want to see what APIs are out there to write your application with. Here's a list of all of them.
  2. Sure there are five hundred APIs, but which are the popular ones? Here's a great twist - mouse over the matrix, so you can drill down and see all the advertising mashups written using the Google AdWords API.
  3. What's a mashup? You can check out the two thousand, two hundred and twenty listed here.
  4. Do you think mashups are simply cool sites that have no business value? Check out the markets section of the site for another opinion. That's where we live, next to shopping and mapping.
So, take a spin and check out the site: you'll be amazed at how much momentum this market has already. If you haven't seen it, I attached the press release below:

THOMAS HOWE COMPANY NOW IN PARTNERSHIP WITH PROGRAMMABLEWEB
Award-winning consulting firm and application developer shares business communications solutions with ProgrammableWeb's online mashup community

W. BARNSTABLE, Mass., and SEATTLE - Aug. 14, 2007 - The Thomas Howe Company, a leading designer and developer of interactive voice and data solutions for businesses, has been named as a premium content partner for ProgrammableWeb, the leading web site for mashups, APIs (application programming interfaces) and the new "Web as Platform" approach to site development.

As a content partner, The Thomas Howe Company is providing expertise in the form of communications mashups, original articles and other materials that are posted in a new channel of ProgrammableWeb.com under the "Mobile/Telephony" section. The content will focus on telephony and mobile web services, APIs and mashups.

"Thomas Howe and team have an entrepreneur's knack for hunting down business-oriented APIs and an engineer's skill for putting them together," said John Musser, founder of ProgrammableWeb.

Howe was the first-place winner of the recent telephony mashup contest sponsored by O'Reilly Media and data-services provider StrikeIron. His entry, "After Hours Doctor's Office," transcribes office voicemails left by patients for doctors into text and then sends them via SMS to the doctor. A case study of this mashup is one of the items posted in the new section of ProgrammableWeb.

"At The Thomas Howe Company, we're interested in building real-time communications systems that help our clients save money while also increasing the quality of service for their customers," said Howe. "I hope that by sharing the information we have found useful, along with details of our own experiences, it will drive further creative thinking within the growing mashup community."

To view content from The Thomas Howe Company on ProgrammableWeb, visit www.programmableweb.com/telephony.

Friday, August 10, 2007

API of the Week : DBpedia API

If you were to ask me, I would say the twenty year old software engineer has a distinct advantage over the older telephone guys (such as me) in the realm of innovation.  Since the barriers to entry to deploying a service provider have fallen through the floor, the larger challenge is not in complex engineering, but is instead in innovation.   The younger engineers are free of the legacy of the PSTN, and many things would occur to an experienced engineer won't to them, and it's not a bad thing. 

For the benefit of everyone who actually remembers when Carter was president, I bring you the API of the week : DBPedia.  It's not in any way a telephony API, and that's my point.  A large number of innovative applications that use telephony will include APIs that have NOTHING to do with telephony.  The DBPedia API is an effort to put a Web Services API on top of the Internet's encylopedia.  With it, you can query Wikipedia from your application for structured answers such as "Tell me all of the authors born in Canada during 1954".  Essentially, it allows you to access all of Wikipedia's 1.6 million articles from your application, whatever that application might be.  You can learn more about it on the their site.

What does this have to do with telephony? Nothing. What does this have to do with next generation applications? Everything.  Applications that use the Internet as the platform use APIs from a large number of sources, and by and large, these APIs are not telephony. However, nearly every time a telephony API is used, an API such as GoogleMaps, Amazon SQS or DBPedia will be used right alongside it.  As a developer in this market, it makes a lot of sense for you to get to know your neighbors for two reasons. First, the more you can make your API play well with others, the faster the adoption of it will be. Secondly, the more you can understand your customers, their problems and how they need your part for their solution, the better you can make your API for them.   I'm supposing this means that you need to get familiar with APIs like this.

Which leads me back to my original statement.  The twenty-something-don't-know-or-care-about-SS7 engineer will sit down and design their version of the hot-or-not site one day, and use a whole bunch of crazy APIs to put together the application.  Then, they will go have a beer, come back, and say "You know, it would be really cool if you could just call the person you want to hook up with.  Is there an API for that?"  They won't even consider for a minute the words "termination", "LATA" or "CALEA".  They're just writing an application.  They need an API for some function, and it will take a few minutes to integrate it into their application.  And, there are many, many more of these guys than all the telecom engineers that have ever, and will ever, exist.   

So, I bring you the DBPedia API, as an example of the hundreds of APIs that will live in the same neighborhood as the Telecom APIs.   Go check it out; let your imagination run.  And one day, when a web guy surfs for a telecom API, I hope it's your API they choose. 

Wednesday, August 08, 2007

VoIP's Top Techies

As I was having a conversation with a friend, I mentioned that I felt really lucky to have worked with some of the best guys in the business. He asked me who they were, and why, and it triggered something for me. In our industry, as in most, you know the company's names, and maybe you might have heard of the CEOs, but do you ever really hear of the great engineers behind the scenes? No, probably not. So, in honor of the geeks you might not have heard of, here's Tom's list of Gods of VoIP Engineering. The criterion? First, I had to actually work with you(or at least had a meaningful conversation, digital or otherwise) at some point. For instance, Richard Shockey is well known and respected, but I never had a chance to work with him. Rosenberg, too. Yet. Secondly, I tried to pick complete no brainers - practically everybody I know respects these people. Thirdly, my main criterion is that of envy : these are people who's skills I not only admire, but deeply covet. These are the folks who are my teachers, and whom I think are worthy of your respect as well. Sort of my fantasy geek-ball team. If you see one of their resume's cross your desk, jump. Finally, I'm trying to keep the list short, so if your name ISN'T on this list, I reserve the right to amend it at a later date, don't hate me, still love you, all that stuff.

That said, my personal list of geek gods includes :

  1. Henning - One of the three writers of SIP, currently a Columbia Professor. (Just like Madonna, Sting and Bono, Mr. Schulzrinne needs only one name)
  2. Doug Tucker - CTO of Ubiquity, and in my opinion, the whole and complete package. He even took Kung Fu back in the day. Gotta love the dangerous geeks.
  3. Mark Reid - Editor of H.245, big shot at NMS and a perfect technical manager.
  4. Brough Turner - Long time CTO of NMS, long time leader, long time VON show dancer.
  5. Eric Burger - Interim CTO of BEA, founder of Snowshore and instantly credible in any room.
  6. Daniel Biage - CTO of Versatel Networks, old school engineering at it's finest. Go to Quebec to learn how to deeply care about what you do.
  7. Jeff Bernstein - Founder of 2Wire and PictureTel, really nice, really smart. Really nice, too. God is he smart.
  8. Dan Petrie - Independent Consultant and smart guy at PingTel, among the first to "get it"
  9. Ed Bassart - Founder of ShoreTel, been at it since the beginning, and deeply smart.
I'm sure there are other's I've missed (I might blog this again). Who's on your list? Give'm some love.

Tuesday, August 07, 2007

GigaOm says it's time to REST

I know that many of my readers are telco guys, so you might not even know the difference between SOAP based web services and REST. I'll make it easier for you... In the parallel universe of SOA, SOAP is like H.323 - big, clunky, slow but complete. REST is like SIP - fast, light, scalable and composable, but incomplete. Anne from GigaOm just wrote a great article declaring a winner, and why.

Technorati Tags: , , ,

API of the Week : Amazon Flexible Payments Service

In the "Internet as platform" game, the big gorilla isn't Google - it's Amazon. Amazon announced the private beta of their payment service called Amazon Flexible Payments Service (AFPS), filling out a complete platform for deploying highly scalable, robust and feature complete web applications.

From their site :


Amazon Flexible Payments Service (Amazon FPS) is the first payments service designed from the ground up specifically for developers. The set of web services APIs allows the movement of money between any two entities, humans or computers. It is built on top of Amazon's reliable and scalable payment infrastructure.

Amazon FPS offers developers unmatched flexibility in how they can structure payment instructions, including standing instructions that can remain in place for multiple transactions. These instructions impose conditions and constraints on money movements and can be set by both senders and receivers of funds. For example, a sender might set a spending limit per week for a particular named recipient. Only that named recipient would be able to withdraw funds and only up to an amount per week equal to the spending limit. A piece of FPS functionality called the GateKeeper automatically enforces the constraints you set with payment instructions. When the sender or receiver is a computer system, payment instructions are set programmatically using APIs. FPS also provides a simple set of user interfaces that humans can use. From the users' point of view, they simply see terms of service and a request to accept those terms.

You can use the extensive feature set of Amazon FPS to conduct a wide variety of transactions under virtually any set of constraints. Key features include:
Send and receive money using credit card, bank account or Amazon Payments balance transfer as payment methods.
Create "Payment Instructions" to define conditions and constraints desired for a given transaction, and programmatically obtain payment authorizations or "tokens" that represent these Payment Instructions from customers.
Execute one-time, multiple, or recurring payments on behalf of customers.
Aggregate micro-transactions into a single larger transaction using Prepaid and Postpaid capabilities.
Build payment applications where you are neither the sender nor the recipient of funds. You can build marketplace applications that enable the movement of money between two third parties.
View account balances, transaction histories, and transaction details on the Amazon Payments web site.
Utilize the Amazon FPS sandbox to build and test applications without using real money or incurring any transaction charges.

Technorati Tags: , ,

Monday, August 06, 2007

WITA : Scripting Front End


Let's take a look at each of the three major parts of a Web Integrated Telephony Architecture (WITA) in depth. WITA contains three basic architecture blocks : a voice scripting front end, a Ruby on Rails back end, and a collection of web services to implement telephony applications. Today, I want to talk about the scripting front end.

Summary
The scripting front end provides the user interface for the user. User interfaces may be implemented through traditional web applications or desktop clients, but WITA applications typically use as a primary interface a voice scripting language such as VoiceXML. The VoiceXML script acts exactly as a web site, but instead of filling in forms, you use your voice to fill in forms to be posted to the web site. Instead of reading web pages produced by the site, the VoiceXML script will read the results back to you. VoiceXML scripts can be localized as web pages do, and can speak the native language of the caller. Different views into the application can be rendered to the user by either a voice menu choice (analogous to web site navigation) or through different dial in numbers or SIP addresses (analogous to using different URLs). In general, the scripting front end doesn't provide much in the way of call control, as the telephony features are implemented using the web services back end.

Interfaces
  • Interfaces to the user through any telephony device, either from the PSTN to SIP. Can use natural language recognition, DTMF detection, or some combination of both.
  • Interfaces to the Web server back end (typically implemented using Ruby on Rails). Fetches VoiceXML forms based on inbound dialing information. Presents data to user as provided by Web server back end. Collects data from user as a form and uses HTTP POST to save on server or to cause some action.

Scaling Concerns
From a human to scripting standpoint, the scripting front end scales linearly with use. You need as many ports of inbound scripting as you have inbound callers. It is unimportant if each of the scripting ports come from a common source, as the scripts have no interaction with each other. Thus, you can use an arbitrarily large number of scripting engines (either hosted or platform) without any architectural impact to the application. Voice is not typically passed from the VoiceXML platform into the larger Internet, so quality of service issues are not typically important at this level. From a scripting to Web server standpoint, common and well known Internet scaling techniques of load balancing, server replication through DNS, etc, are fully available to the system engineer. No additional nor unique requirements are placed on the Web server farm in the WITA architecture.

In terms of business scaling, the WITA front end may be completely functional using a hosted provider (see below) at only a dime or so a minute of use. These hosted providers will be happy to scale with your application, or you can choose to deploy with a platform solution. Platform solutions typically make sense only for large or sensitive installations.

Suppliers
There are many hosted suppliers of voice scripting. My favorite happens to be Voxeo, because they have excellent service, they are well adopted by larger corporations in the US, they are price competitive and I happen to like those guys. There are a few other good choices as well, including BeVocal, TellMe and Angel.com.

For large corporations, there are a number of good options for platform solutions such as Convedia (now Radysis), Snowshore (now Cantata) and Voxeo (another reason I like them). In large measure, VoiceXML scripts are pretty portable, and only small code changes should be required when moving from hosted solutions to platform solutions.

Friday, August 03, 2007

Ruby on Rails Screencasts

If there was a moment for me where the light went on for Telco mashups, it's when I saw the Ruby on Rails Screncasts. They are a bit goofy, but if you actually sit through one, and realize what you are seeing - it's earth shattering. It's earth shattering especially when you realize that the other parts of telephony applications, such as scripting front ends, and web services back ends, have very similar productivity gains associated with them. Just check these out... especially the Flickr screen cast. Be careful that you don't drool.

Technorati Tags: , ,

Getting Ready for the VON Show

Pat and I had a wonderful surprise yesterday, when Carl Ford and Bill Kelley stopped by for lunch. I'm always talking about how "Brigadoon-ish" I think the VON show is, and it was actually pretty nice to have a friend from the show come to my hometown on Cape Cod for a meeting. I suppose the water view doesn't hurt, either.

As I've said in the past, instead of complaining, I'm committed to helping out at this year's VON show, and as part of that, I'm taking a pretty active role in the "Unconference" potion of VON. More about that later, but as part of that, Carl and I thought that a real cool thing to do was to show the audience, in real time, how much the new web technologies change the game for new services development. Sometimes, you just gotta see it. So, we're going to show you.

I'm planning a two hour session where we are going to develop, from scratch, an WITA (Web Integrated Telephony Architecture) service from scratch, in front of the audience. Three of us are going to work together on each of the major pieces : a scripting front end, a Ruby on Rails framework and a number of web services below us. As we work, we'll work out something were either the developer is explaining it as he goes, or another talks as he works. At the end, it will be an application that not only works, but can scale as high as you want it to - just like a web site.

The application? I like this one : my mother's memory is failing her. I'd like a reminder service that will call her cell phone with a voice message sometime in the future. For instance, you call a phone number, give your Mom's phone number, a voice message, and a time when you want it delivered. Maybe somebody will have another idea that's better, but that's what I got.

For you, if you don't really know how Telco mashups work, or what they look like, or why they are so revolutionary, come and join us. Grab a beer, kick off your shoes, and watch.

Technorati Tags: , , ,

Wednesday, August 01, 2007

Oooma Tech Update

Alec Saunders did a fantastic job digging into some of the tech issues in this entry his blog.
Alec, I thought YOU were the marketing guy and I was the engineer. Good job, old man.

An example of a good Ooma feature!

I had a pleasant conversation with Ooma CEO Andrew Frame last night. No, really, it was mostly pleasant. Apparently, of my three blog readers, one of them is an Ooma employee. Hey - big shout out. Hollywood in the house.

So, I'm not going to go into too much depth here about our conversation. Andrew promised me my own Ooma box to play with, and I'll give you an honest appraisal of it when it arrives. We couldn't talk long (as my cell phone kept dying), but I frankly didn't hear anything from Andrew that was earth shattering from a business perspective. I hope that Andrew's sudden "I have to go" response to "Tell me why your customer acquisition costs will be substantially less than Vonage's" was about schedule, and not about an uncomfortable question. We've planned to speak again after the box arrives, and I'll tell you how that goes.

No, what I want to mention is a good Ooma feature. According to Andrew, one Ooma feature is that when you are on the phone, if another call comes in, the other phones in the house ring. I love that feature - and I'll tell you why. It's a feature that doesn't require customer education, and doesn't require the customer to change his habits : the two killers of value added services. And, as Andrew rightly states, it works almost by surprise, which might be the best way that consumers learn about their product.

The second reason why I love that feature is because I'm getting excited to see some good engineering. What I mean is, I can't wait to see how they pulled that one off without causing serious head-aches for the installers. Near as I can tell, you need to drive each wired phone in the house independently to pull this off. If you had a multi-line wireless phone driving your house, it would be pretty easy, I suppose, but how many people have that? Typically, don't those Comcast installers cut the main line into the house, and then drive all the phones from their set top box? I don't think most houses have a system where all the wired phones go to the same place in the house, then are bridged together. Andrew told me these guys are the best in the business. I am truly excited to see how good their product is, and how innovative their solutions to problems like this will be.

Tuesday, July 31, 2007

iPhone Marketing

As I was being a bit lazy (on a conference call), I caught this post from the latest Apple insider. Mike Abramsky, an analyst, details how he believes the iPhone will mature :

Abramsky speculated that upcoming iPhone software updates would include new widgets, peer-to-peer applications (chat, picture messaging, social networking), location-based services, MMS support, home networking, and possibly some integration with Mac OS X Leopard.

"No word however on integration to Microsoft Exchange," he wrote. "It appears to us that Apple, classically, has more pleasant surprises in store for iPhone fans and investors."

After speaking with Joswiak, the analyst also made changes to his predictions for future iPhone models. Although he spoke of "higher resolution" iPhones earlier this month, Abramsky now says he expects Apple to differentiate its iPhone lineup not by features, but by price and memory capacity. The move, he explained, would be similar to how the company grew its iPod lineup, simplifying market positioning.

"This affirms our view of a lower priced ($349-399) iPhone [in the fourth calendar quarter of 2007 or first calendar quarter of 2008], with a higher priced version at higher capacity, to expand its market opportunity," the analyst wrote.

I personally find this fascinating, as Apple plans to differentiate the iPhone not by features, but by price and performance. If you recall, for most of era of competitive phone service, market success was found only through variations in price, as the basic service was essentially feature complete, and value added services had benefits which were only marginally valuable. Could it be that Apple has already caught on to what took telecom 100 years to understand?

Monday, July 30, 2007

WITA : An Architecture Standard for Telco Mashups

One big difference between the Web world and the telecom world are standards. I don't mean that they use different standards (although they do), they have a different approach the standards entirely.  Other than the two worlds of standards represented by the Telco and Web world, there's a third sort of standard - an implementation standard.   A "this is how we tend to do this sort of stuff" standard.  For instance, there's really no one PSTN standard - it's just how we have put together many other standards to make something that works.  We need to establish a standard for Telco Mashups; a set of conventions as to how we tend to write these applications.  Since I've been at this, I've noticed a standard pattern I'll call the Web Integrated Telco Architecture - WITA.   From where I sit, the an application written to the WITA standard is more scalable, more reliable and easier to write than anything else I have seen put forward for telephony enabled services. As I put together my telco mashup applications, and see companies like Gaboogie and Twitter do the same, I see that we all use approximately the same approach. If we can standardize it, give it a name, we can build the community quicker. 
 
The telco world has organizations such as the ITU and ANSI; indispensable tools in creating standards that telephony vendors need to design their equipment.  An ITU standard takes several years to  ratify and formalize, and a typical vendor cycle of development lasts around eighteen months. The Internet community runs off of the IETF, and creates nearly all the web standards used in networking, such as TCP, HTTP and FTP.  The IETF is a bit different than the ITU, in that the IETF documents stuff that's already working, so that the standards lag the availability of a product.  IETF standards take much less time to appear as drafts, and Internet application development lasts three to six months. 

Another sort of standard is an architecture standard.  Strictly speaking, IMS is an architecture standard, not an implementation standard.  In the Web world, AJAX is an architecture (or web development technique) that uses Asynchronous Java and XML to make rich, interactive web sites.  Ajax is a standard because that's how people normally them together - there is no committee and there are no plenary sessions.  What is the telco mashup standard? What is an application that uses WITA? I'll define it today, and we can delve into it over the next week. I use WITA for nearly all my telephony mashups, and I've seen many others do the same.

Web Integrated Telco Architectures use the following standard components:
  1. Voice XML: WITA uses VXML to handle inbound interactions with human beings, and most outbound voice messaging applications use VoiceXML to make those messages rich an interesting.    The VXML scripts are delivered by a web services application, and post the inputs the collect to a web services application.
  2. Ruby on Rails : WITA uses Ruby on Rails to implement the web services application. It's responsible for putting the logic on top of the database, and for rendering views to the user in the form of VxML scripts, Web Services APIs and graphically intensive web pages. 
  3. Telco Web Services : WITA uses telco web services to deliver telephony features such as outbound messaging, conference calling, click to dial and SMS messaging.   These web services are called from the Ruby on Rails frame work, and provide the scaling and reliability components of the architecture.
VxML + Rails + Telco Web Services == WITA.

Wednesday, July 25, 2007

The Game's Afoot

A massive shout-out to my man Dean at Cognation, who has taken up my recent challenge about the future success (or lack thereof) of Ooma. From his recent comment :

Ok Thomas I'm prepared to step up and take that bet from you, easy money in my books.

In 12 months from now I bet that Ooma will still be in business and am prepared to wager a dinner here in New York.

Reply post here to your blog to accept so we have this on public record.

It may be because of some of the consulting projects I've been involved with here at www.Cognation.net but I think Ooma have capture some very interesting aspects;

1/ Ease of use and design (so sorely lacking in a large number of basic projects I see) their ATA is 'the' best ata I've seen, nothing revolutionary but it's just well designed plain and simple.
....and whats dissapointing about this fact is that with all the brains in the voip industry no one else came up with this design until now.


2/ Ease of uptake (keeping original number is such a barrier to entry to skypein and similar - yes I'm looking at you Grand Central).

3/ Ease of implementation in their business model (peer to peer using existing ethernet/internet infrastructure with zero billing - how easy is that).

Like I said easy money and I look forward to accepting your bet.

I'll set up a page on the www.cognation.net website to track developments over the next 12 months.
Now, since they've raised a bazillion dollars, there's no reason why they should EVER go out of business, so we'll need a better measure than the doors closing. That aside, I'm up for this bet, partly because I think it will be fun, but partly because I love dinner in New York. I'm betting that ease of use, ease of implementation and ease of uptake will spiral into the ground because it's simply not that valuable to the target customer. I say we pick a number of Ooma subscribers, and let's see if they go over that number. I'm not going to suggest that Ooma get a five million subscriber number, like the iPhone - or even a moderate number, like a million, that Vonage had. Can anyone think of a good metric? Outside of dinner, it's not that I'm hoping for Ooma's demise. In fact, I'd be tickled pink for them to succeed. My breath? Not holding it. I'm just hoping, just like many others, that this is the last effort at a business model that seems to fail nearly every time it's tried.

Paprika

Recently, the man in the Purple Shirt challenged the community to finally come up with compelling real time communication services. I suppose it was spoken during a moment of frustration for Jeff, as this industry has spent a lot of time and energy making these wonderful IP based technologies, but we are still doing pretty much the same old things with them. For those that do make something that turns him on, he might provide some early-early seed capital, and more importantly, he would provide some visibility and friendship. I applaud Jeff's continuous efforts to move voice technology forward, and as I've said before, I'm here to add my efforts to his. To help developers, Aswath pitched in by providing some pointers to how he'd do it. Well, here's what I have to add to the discussion, and it's a single word.

Paprika

To use voice in a compelling way, recognize that voice is a spice, not a main ingredient. Voice and other real time communications brings out the flavor in some other application, but it isn't the star. A compelling application starts with solving a real customer problem, and unless your customer happens to be a telco, carrying voice probably isn't the issue. The issue is something else. Take any vertical and check to see if I'm right. Here's a classic example: entertainment. American Idol had an innovative idea, which was to make a TV show where the people emotionally enroll in the outcome. If you think about it, it's just like sports: people watch because they care about their team. But how did they deeply involve the audience? They made them vote. How did they make it compelling and unique? They made them vote using text messages, which made the process unique and pandered to their core, young audience in one fell swoop. Brilliant. Compelling.

Why do we have such a voice services focus? My bet is that telephony has been so hard, for so long, that the people involved only know the telecom industry. We don't know the problems faced in other verticals because we've been so focused on the problems in ours. I bet you that if you spent just the smallest amount of time looking at transportation, or financial services or education, you'd find all sorts of places you could sprinkle basic communications into the mix to make it more delicious. Because we haven't done that, Jeff's food is bland and boring. He deserves better, you deserve better, and most importantly, customers deserve better.

Apparently, I'm irrelevant, repetitive and nonsensical

Oh my, Google is on to me. As I logged into my blog this morning, a large red box stopped me in my tracks. Apparently, Blogger thinks that this log is a spam bog. What's a spam blog?

As with many powerful tools, blogging services can be both used and abused. The ease of creating and updating webpages with Blogger has made it particularly prone to a form of behavior known as link spamming. Blogs engaged in this behavior are called spam blogs, and can be recognized by their irrelevant, repetitive, or nonsensical text, along with a large number of links, usually all pointing to a single site.


Shoot. You know you're in trouble when even a Google robot thinks that your posts are irrelevant, repetitive or nonsensical. Did I say that they were irrelevant, repetitive or nonsensical?

Monday, July 23, 2007

Aspirin or Penicillin?


Is your business selling aspirin or penicillin?

Is it aspirin? Does your customer have a headache, and if he would just take your product/service, he'd get rid of it? Does your customer have achy muscles, and a few pills would put him at ease? Or is it penicillin? Does your customer have a life threatening illness? Is he more than uncomfortable, more than achy? Is he truly sick, and in trouble? Without your product, how in trouble is he? I'm sure it is obvious by now, you want to sell the anti-biotic, not the analgesic. If you avoid taking aspirin, you can get through the day. It's optional. If you avoid taking your penicillin, you might not have another day.

So, let's take that filter against today's whipping boy, Ooma. Is there any customer in the world to whom Ooma will be penicillin? (Not from where I sit.) And if so, would the medicine be generic? (Yup).

Ok - that's the easy part. Why is this so? I firmly believe that Ooma is aspirin because they have a horizontal product in an unregulated space, and it's really hard to differentiate the service to create any sort of brand loyalty. Outside of branding, horizontal products and services very, very rarely have points of competitive advantage other than price. In an unregulated space, businesses and consumers have choice. Although every business or home needs phones, they don't need Ooma phones. In phones, it's hard to make a brand. Apple is going to have the best shot of anybody, ever, of doing this, and the jury is still out.
Simply put, Ooma, and every company like it, sells aspirin, because it's an aspirin market. The basic issue with Ooma, and the cap on their success, isn't the team, or funding, or even their feature set. The basic issue is in the market they pursue.

Is your business selling aspirin or penicillin? Here's a hint - the first step is to find the market where the customers have a fever.

Technorati Tags: , ,

Friday, July 20, 2007

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.

Thursday, July 19, 2007

Application of the Week: Ooma -Yes! We've hit the bottom!

How long have you been saying that carrier based telephony is a race to the bottom? Well, you can stop saying it, as we've arrived.  When you purchase an Ooma phone, you never need to pay for your minutes again. You might shell out four Bennys for the privilege, but that's it.  Yes, that's it folks - no more paying by the minute ever again.  We've pressed the bottom button on the ol' telecom elevator, and the doors have opened.  And what I love about this story is how complete the bottoming out is.  Andy is always telling me to be as positive as I can in my posts, and when I criticize, to give an example of somebody who's doing it right.  A challenge here, my old friend - but I'll try.

Technical : C.  No, C-.  I wonder if anyone told the investors that the Chinese could produce the exact same phone for fifty bucks, or that it simply isn't that hard to write a peer-to-peer VoIP network.  Of course, if Ooma makes any connection to the PSTN (such as DIDs), Ooma has to pay for that somehow, so they have an incremental cost for each customer, no matter how peerish they get.  If they don't, why would you make a bet on yet ANOTHER walled garden? Maybe the phone rocks, but so did PingTel's.  And you know how they turned out.  Let's face it, do you think any phone that attaches to a wall is that compelling? How much better would this be: don't make a new phone. The old one works fine. Use the same old phone to do something valuable, like Jott is doing.

Business : D From a business perspective, when do you think the investors will learn that business plans that start out with "Yes, we won't make any money on the basic service, but we can monetize it later on by doing..." are like something that's too good to be true? Right - it usually IS too good to be true.   Ooma (minus five points for stupid Web 2.0 name) will rely on selling value added services to their subscribers to increase their profits from the phone sale.  Value added services?   Did anyone check to see the adoption rate for new services with cell phones?  The most popular VAS available for phones are ring tones (you want that in your kitchen) and text messaging (does this thing have a keyboard?)   How much better would this be: find something so valuable that I'd be willing to pay for it, like GrandCentral.  Give it a smart name, like GrandCentral.  Get a real business plan, like GrandCentral.

Buzz : B.  Well, compared to Ashton Kutcher's acting career, this might be a real step up.  He typically entertains me for an hour or so at most, but now I can watch Ooma blow through 20 million dollars, it will take months! Maybe even a few years! Nice. Best thing about the company is imagining my retirement with commercials from Ashton encouraging me to make phone calls.  I met Demi in 1986 when she came to the restaurant I was working in, and let me tell you, she's not just pretty - she's 100 foot pretty.  I might buy the damn phone if she signs the box.

Overall : I so wish I could short a private company. Anyone want to bet me?  

Will it blend?

Well all know that the iPhone will mash, but will it blend?

Wednesday, July 18, 2007

Hello to the VON Show?

I think I should make an honest apology for underestimating Jeff Pulver and his organization. I was wrong.

As you might recall, I did not attend last Spring's VON show that grew from a conviction that the venerable conference's best days were now behind it, and for content, it had gone off the tracks.  I surely missed seeing all of my friends, and was quite sad about it all. I believed then, as I believe now, that the future of innovation is far from telephony carriers, and far from technologies such as IMS.   So, in a fit of whatever, I boycotted the conference.

To his everlasting credit,  Carl Ford rang me up and challenged me to help him understand where I thought the market was going, and if I would, help the community learn about the new opportunities provided by Web services architectures and mashups.  I committed to him then, as I now share with you, that I would do my best to help bridge the worlds between my 20 year old, Ruby hacking, Adhearsion writing, mashed-out friends and those 50 year old, SS7 and CALEA scarred grey beards. (I'm growing one myself!)  You see, my young friends really don't know how to make money with telephones... and my older friends really don't know the tremendous productivity and functionality gains now available because of Web 2.0 architectures, development approach and tools.  Thus, I am taking an active part in next Fall's VON.  I hope you do, too.

I'm moderating a panel on next-generation mashup applications, and we are running a fifth-track at the show to be run as an un-conference.  Carl has assembled an excellent group to help him with this, and I'm so happy to have a chance to work with them.  Our goal is to try to make the conference more than a business development show, where partnerships are made.  If we do this right, we'll show you how important and revolutionary this new light-weight architecture model is for your career and your business.  And maybe you'll say "Damn", just like we used to back in 2000. 

It has to start with your participation, though.  Call or write to me to tell me what you want to learn about - what you want to see.  I have an idea for myself, and I'll share it here.  I'm thinking that I am going to assemble two or three other hacks, and we'll make a date to go into a conference room for a few hours to put together an application using only open source or openly available tools that you simply couldn't do a just few years ago with a month and a hundred thousand dollars.  You can see it when we're done, (what the hell, you can visit us as we write it, just bring wine, beer or pizza) and we'll show you how we did it.  And then, with your imagination, you can go off and do the same.  I want to show those unfamiliar that it's real, not just hype, and what better way than to just do it.

And to Jeff, Carl, and all those in his organization : I wish I was the one who picked up the phone and said "I would love to help you out here." Instead, they were the better men, and I'm glad of it.

Tuesday, July 17, 2007

SunRocket c'est fini

According to CNN, Om and Andy - the end is here for SunRocket. Yesterday was their last day in business, and I think with it goes the dreams of a VoIP generation. The consensus opinion is that the triple play offerings from the Cable companies are too competitive for players like Vonage and SunRocket, but I have a hunch that the answer is a bit more direct and simple : there's simply not enough unique value for a VoIP carrier to establish good margins.

It's not unique enough because the cost to establish a carrier is effectively zero, and the flip side of being able to offer the service to anyone is that all your competitors can too. Other than price, I have yet to see any land-line or VoIP carrier truly differentiate a service. These days, and IMHO, only GrandCentral, Iotum and the new iPhone actually make telephony services that are differentiated and valuable in a mass market. And none of those is a carrier, per se. If you were to measure brand loyalty for VoIP services, you would not need all the numbers on your keyboard, since it's practically zero. Number portability is the only sticking power of a telephone service these days, and that has nothing to do with brand.

I remember reading a book about entrepreneurship a long time ago, and I think the first or second rule was to methodically grow from a profitable base business. Exactly what was the profitable base business of SunRocket? Do a little test, and pick a handful of long term, substantial companies on your favorite stock market. Can you identify what their small, profitable base business was? I bet you can find it out. They nearly all have it. Is it all surprising when you see a company fail when it tried to make up with high volume what they couldn't make in margin? And unfortunately, this is the lot of VoIP carriers, and from where I sit, forever will be.

Friday, July 13, 2007

API of the Week : Adhearsion

OK, so maybe Adhearsion isn't a Web API, but it certainly is a programming API, and if you're involved in emerging telephony, you ought to know what it is.

Adhearsion is a Ruby library that takes over Asterisk's internal processing of calls and puts them into the Ruby framework. You setup the dial plan of an Asterisk server to forward all calls to the Adhearsion server, either running locally or an a remote server. Once the call hits the Adhearsion server, you have the call in Ruby Land, and the world is your burrito. What can you do from there? Tons. You have at your disposal all of the Ruby integration with databases, UIs, web services calls, etc.

An example would be a hyper dial plan, that would connect calls, but also provide a gateway out to a Web Services function that would retrieve the latest weather report. Here's what it looks like :

#This is an example extensions.rb file which
# would handle how calls are processed by
# Asterisk. This is all completely valid Ruby
internal {
case extension
when 100...200
callee = User.find_by_extension extension
unless callee.busy? then dial callee
else
voicemail extension

when 111 then exec :meetme

when 888
play weather_report('Dallas, Texas')

when 999
play %w(a-connect-charge-of 22
cents-per-minute will-apply)
sleep 2.seconds
play 'just-kidding-not-upset'
check_voicemail
end
}

Now, here's a proof point. When I was at the Cluecon show, I told the crowd about the demonstration application I wrote to do a daily collection of body weight for Congestive Heart Failure cases. As I was describing it to the crowd, Jay - the author of Adhearsion - implemented the same application in Adhearsion as I was speaking. It didn't have the insane scale that my Amazon EC2 and Voxeo implementation did, but it was an amazingly complete implementation. Completely impressive stuff. Check it out.

Technorati Tags: , ,

Wednesday, July 11, 2007

Congratulations, Andy and Helene!




technorati tags:, , ,

What I really want for my summer toy

Is it an iPhone?  No, although I bought two of them.  It is Dead Rising for the Xbox360? That's what my son wanted for HIS summer toy.  I am sitting on pins and needles to get a Chumby.

What's a Chumby? It's a mashable toy.  A chumby is a Wifi Enabled stuffed-animal, alarm clock, picture frame hybrid thing that you can put next to your bed (or on your desk, in your living room).  It's always connected to the Internet, and displays whatever you would like it to from the Web - pictures, news, photos, weather, whatever.  When you receive one, you set it up with a playlist of widgets from their web site, and off you go.  Chumbys go for less than $200.00 and don't have any monthly fee.  Now, I'm sure that at least three of my four kids will want one (they might not get one, but the want will be there), but why do I want one?

It's mashable. The chumby is open, and the fine Chumby folks make the hardware and software specs available to you. I would like to purchase one for each member of my extended family, then make a flickr channel with the family's pictures (from my four brothers and sisters, and their family) so that we could have a distributed family picture slideshow for everybody.  How about taking the top 100 songs from each of our iTunes playlists and making the Howe Channel for music? How about using some client of our cell phones with a giant Google Maps where is the Howe Now?

The deeply amazing thing about lightweight programming models is how they radically expand the set of people who can create new services, and therefore the new services they create.  I want all my engineering friends to have the Chumby  mindset, so we can dream more and be disillusioned less.

technorati tags:, , , , , ,

Tuesday, July 10, 2007

Two steps ahead....

Apple to launch cheaper, "nano-like" iPhone in Q4 07?

I'm really happy I'm not running Nokia's handset division right now.

Xeni Jardin:Snip from Reuters:

Apple Inc. plans to launch a cheaper version of the iPhone inthe fourth quarter that could be based on the ultra-slim iPod Nano musicplayer, according to a JP Morgan report.

Kevin Chang, a JP Morgan analyst based in Taiwan, cited people in thesupply channel he did not name and an application with the U.S Patent andTrademark office for his report dated July 8.

Apple filed a patent application document dated July 5 that refers to amultifunctional handheld device with a circular touch pad control, similarto the Nano's scroll wheel.

Link

technorati tags:, , , , , ,

Monday, July 09, 2007

Time to brag yet?

No, I don't think so, but boy do I want to.

I caught a link from mashup meister John Musser from Light Reading called Telco Web 2.0 Mashups. In it, Caroline Chappell speaks about the impact Web 2.0 technologies are having on IMS deployments in her new report. I think Caroline what has is mostly right from a technology standpoint, but misses on some critical cultural points. For instance, the mashup phenomenon has, at it's core, this idea of the perpetual beta. Without regard to how mashable the carriers make their offerings, it won't make them any more fleeter of foot. That said, I am in complete and violent agreement with Caroline, and I hope my industry has the good sense to listen to her advice.

Now, if I were to brag, I'd point my readers back to something I wrote nine months ago....

Is Facebook the Promised Land?

There's no denying an exodus is underway. So far, I've seen Pat, Moshe, Alec and a host of other go over to Facebook from LinkeIn, all in the space of a week. Is it just me, or do you find this remarkable? I mean, not only for the abruptness of it, or the lemming like nature by which it's happening, but for what it says about Web 2.0 principles?

I went back and checked the original piece by Tim O'Reilly, and I found what I remembered reading :
The race is on to own certain classes of core data: location, identity, calendaring of public events, product identifiers and namespaces. In many cases, where there is significant cost to create the data, there may be an opportunity for an Intel Inside style play, with a single source for the data. In others, the winner will be the company that first reaches critical mass via user aggregation, and turns that aggregated data into a system service.
And when I read it, I remembered thinking : "Oh yes, that's part of the reason social networking is such an excellent idea. Since there's a bunch of information that exists between contacts, not simply IN the contact, there's real value in owning the data. " For instance, the service can tell you when a classmate joins the service, so that you can be connected.

Now, here's what I'm looking at. LinkedIn has something like 11 million users, and nearly all the fortune 500 is represented in that group by at least one leader. It's a big group, and it's a well known group, especially to business users. If there's a mass exodus to Facebook, doesn't it sort of suggest that the creation of these large databases of information isn't THAT hard to replicate? That the Web 2.0 promise of monetizing hard to replicate data using other people isn't as valuable as we thought? Now, if LinkedIn keeps going, and keeps going up in membership, we'll know just how valuable that data is. If not....



Friday, July 06, 2007

What time of year is it?

What am I doing these days?
  • I'm reading Garrett Smith's blog about the bad signs from SunRocket. SunRocket has shut down their affiliate program, and admits to owing commissions to their partners from March, and can't guarantee when they can pay. Ouch.
  • I'm following Andy's blogs from France, as he prepares to tie the knot. I think that the South of France might just be the only place in the world prettier than Cape Cod in the summer.
  • I'm waiting for my iPhone to arrive this afternoon, so by next Monday, my friends can stop asking me why I haven't mashed it up yet.
  • I'm wondering how the h*ll Moshe got that close to Joanne from Rocketboom. I tell you, there's no justice in the world. Joanne might be the prettiest thing in the world other than my wife on Cape Cod in the summer.
  • David Galbraith has me laughing and rolling on the floor with his iPhone meets the book of Job article.
  • It may be the 114th year that the Cape Cod Baseball League has played, and it may be that 1 in 7 MLB players are alumni, and it may be that this all-free, all-volunteer league is the best and last place where the true game of baseball is played, but I'm just waiting for Sunday, where I'll get to sit at a Kettleers game and talk the night away with my kids. I think Jon should get his Canadian butt down here and join us. Bring the beer, Jon. It's summer on Cape Cod.

Thursday, July 05, 2007

API of the Week : 411Sync

A vastly underused component of communications applications, especially as it relates to business communications, is SMS or text messages. Text messages have many unique practical advantages that become valuable in the real world of the mobile workforce. First, and perhaps foremost, text messages work nearly everywhere. When signals are too low for a voice call, text messages are your best bet, even better than e-mails which require a stable data connection. Text messages are a store and forward technology, so workers can read them when they are available. Text messages can be read without disturbing those around you. Text messages are the best technology for communicating detailed, but short, information such as part numbers or other phone numbers, because the recipient is not required to grab a pen to write it down on a piece of paper, which might get lost. The number is safe on the phone, and very hard to lose. The downsides are few - 168 characters per message - but surmountable.

There's a large number of providers today that you can sign up for to send text messages. I use Strike Iron's Global SMS Pro, because it's reliable, easy to setup and and simple to pay for. Sending text messages, however, is a much easier task than receiving them. Since text messages use the PSTN's SS7 network, it's a pain not only because of the equipment requirements, but the regulatory requirements. Signing up to receive text messages is a commitment and an investment, and typically costs over a thousand dollars to register your inbound number (called the short code) and a over a thousand dollars a month to maintain it, and that's before you start paying for traffic. Sending is typically much cheaper, since you only pay your ten cents or so a message to your provider.

This is where 411Sync's service comes in. 411Sync provides the developer with a free, and fairly easy, way of accepting inbound text messages. The 411Sync service provides a freely customizable way of enabling mobile search, but you can extend it to whatever your needs are. When you send a text message to the service, you specify a keyword (such as 'red_sox_score') and whatever parameters you desire (such as 'today'), and it will pass it to a standard Web CGI script that you specify when you create the keyword. Your program takes the parameter, calculates an answer, and passes it back as a formatted RSS or Atom message. 411Sync passes that answer back to the phone, with an ad attached. In our Red Sox example, if you sent a text message to 411Sync of red_sox_score today, it would respond with something like Red Sox 10, Yankees 0. You would register a program with red_sox_score, and it would be called with the parameter "today".

The business example? How about mobile workforce automation, with the target audience being a service technician. After you finish a job, you could send a message to your service like "wrico tom 5083649972 complete". Tom would be the technician's name, and the number would be the contact number of the job, and the keyword would tell the front office that the job is complete. The CGI script might record the time spent on the job for billing purposes, then as an answer, provide the address of the next job. In fact, for mobile status reporting, 411Sync is the best, and cheapest game in town. Check it out.

Happy 4th of July --- Cape Cod Style

Tuesday, July 03, 2007

Walled Gardens... End of an Era?

The more I think about Google's acquisition of Grand Central, the more I see it as a watershed moment in telephony.  Unlike Yahoo!, AOL and nearly every other large telephony concern, Google now supports, at the same time, open Internet standards and connections to the PSTN.  This is truly valuable, and unique, and should be celebrated.

From the start of telephony, every major carrier has protected its network behind a series of barriers: technical, legal and financial. Although some of the reasons for keeping their networks closed have some credence, such as security and reliability, it's pretty clear that carriers hold the opinion that opening up their network does not benefit them.  As time has gone on, and technology has matured, the closed nature of networks is less and less about technical concerns, and more and more about carrier fear and an inability to present compelling business cases to customers.  

With the GrandCentral acquisition, this has now changed.  Google now owns a company that is a legitimate PSTN service with strong integration into open VoIP standards, and did it in a very Voice 2.0 way.  GrandCentral currently supports free and unfettered SIP connections to Gizmo accounts, unlocking the entirety of the SIP architecture, benefits and approaches.  And more so, GrandCentral has done this in a completely Web 2.0 manner, freeing itself from the chains of a technology play and firmly focusing on a valuable application that people will pay for.

Is this is the end of an era for closed telecom networks?  Yes, I think it's the beginning of the end.

Jott : A Diamond in the Rough

Jott is a true diamond in the rough.  
The premise is quite simple. Sign on to Jott, upload your contact list, call their number and leave a message.  The message is translated and forwarded to the contact, or group, as an e-mail.  So, if you're driving down the highway and you want to leave a quick e-mail for your wife, you pick up your phone and leave the message.  I've been using it on and off for a bit, and the translations are fairly accurate and certainly usable.  Like Twitter, Jott sits at the intersection between real time communications and social networks.  You can create groups that you can Jott too, and I see that Andy Abramson uses Jott as well. It keeps a  history of all my Jotts, and could almost serve as a to-list archive. All very cool. 
Jott is still in Beta (what does beta mean these days, anyways?), so I suppose I should feel some reluctance to bash them for not having an API.  I don't. They need one, because if they had one, I would be in telephone mashing Valhalla.  The current system only works on e-mail, so although it's great that I can communicate quickly with my friends, family or take notes for myself, the interface to the rest of my workflow is clunky.  If I had an API, then it would be a simple matter to Jott myself tasks for my 30boxes calendar.  As it is, I'll have to go through hoops to get that integrated.  Any cursory glance into mobile workflow automation shows you how important Jott's functionality is, and their lack of API hinders that important, and lucrative, market adoption.  I'd also ping them for having a "I simply scaffolded this in rails" contact management solution. I have about 500 contacts in Jott, and I'd like to erase them, so I can load up a more current set. I have to page through 20 pages of 25 contacts each to delete them, and unfortunately, I've seen speedier web sites.  A little more sophistication here would be nice. 
There's a kid in my Karate class who's so excellent when he concentrates and pays attention. A true natural.  When I catch him looking anywhere but in front, I want to smack him - because I hate to see such talent wasted by stupid stuff.  The Jott implementation is a bit rough, but a diamond, nonetheless. 

  • Technically, I'd give them a B.  They could be an A, and I think nothing hard is stopping them from getting there.  Give me a more mature contact management solution, I'll give them a B+. Give me a good API, they earned that A. 
  • From a business standpoint, I give them an A-.  The service is valuable, and over time, because of their social networking angle, hard to replicate. I don't see them charging money yet, but they could.
  • From a buzz standpoint, a B+. I'm buzzed about them, and think they have great things in front of them.  In the circles I travel, Jott isn't spoken of with awe and respect, but they should be. It's a great idea whose time is come.

Monday, July 02, 2007

Tom's Tools : Ruby on Rails

In 1995, Yukihiro Mastsumoto released the first version of a new computing language called "Ruby" to the outside world. Ruby was grounbreaking not in terms of technology per se, but in terms of audience. Previous to Ruby, programming languages had distinct directions and purposes aimed at computers. C was designed to write operating systems for computers, and was small and light. Fortran was excellent at pushing the details of equations into a procedural language. Java can execute anywhere. Ruby was optimized not for computers, but for people. In Yukihiro's words :

Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.
Ruby is an optimized language that allows programmers to write code, really really fast. Ruby on Rails is a framework for writing database backed web sites, really really fast. Using Ruby on Rails, you can literally make a database backed blogging web site in fifteen minutes, including complete access to your data model : create, read, update and delete (CRUD) with complete validation. Don't believe me? See for yourself. Using Ruby on Rails, you can create a web site that will allow you to browse Flickr sets in five minutes, using Ajax. Don't believe me? See for yourself. Is Ruby hard to learn? No, it's actually a joy. It's so easy, why don't you spin it up in your browser and take ten minutes to learn some.

I wanted to call your attention to Ruby and Ruby on Rails because it's fast become the standard implementation language for the Web 2.0 community. Companies such as Twitter and Basecamp, use Ruby to implement their sites, and we at the Thomas Howe Company use Ruby to create nearly all of our applications, and are using it for our new service. When I learned about Apple's iPhone development strategy, it was clear that they were telling us to use Ruby for the development.

There's downsides, as it runs pretty darn slow. In the great computer language shootout, Ruby comes in nearly in last place. How slow is slow? Ruby runs three times slower than Python, and about 60 times slower than C. However, there's some things to mention. First, it is getting faster all the time. I know I'll get slammed for being impertinent enough for saying so, but Web sites really don't have the same performance requirements of DSPs. And there's always EC2. Besides, as you grow past a hundred thousand subscribers, and you need five servers for your application, that's called a good problem to have.