StrikeIron Blog

StrikeIron Can Deliver [fill-in-the-blank]-as-a-Service

Our recent announcement with Jaduka demonstrates our ability to go beyond data in delivering usage-based models for a range of technology. In this particular case, we worked with Jaduka to deliver their text-to-voice and .wav file messaging capabilities in the form of consumable, easy-to-integrate SOAP and REST-based Web services APIs.

Jaduka enables voice messaging to be delivered to anything with a phone number. In the case of text-to-voice, an automated process can deliver a computer-generated voice message from a line of text to recipients, usually triggered by some event, perhaps a product shipping notification or a meeting reminder. Alternatively, a pre-recorded .wav file can also be delivered in scenarios where it is preferred over computer-generated voice. This enables alert messaging using the telecommunications backbone of Jaduka's parent company, Network IP, for physical delivery. Land-lines, mobile devices such as the Blackberry or iPhone, VOIP lines from Vonage or Skype, or anything else that has a phone number can now receive a voice or .wav file alert programmatically, expanding the realm of notification capabilities beyond SMS text messaging where previously notification was limited to devices that have screens.

StrikeIron has normalized all of the communication with the Jaduka technology to match that of every service in our portfolio, from interface, to behavior, data structures, authentication, usage models and response messaging. This way, all of our existing customers and users can simply turn this capability on without having to learn a whole new set of disparate rules and communication exchange in an effort for a brand new integration with an advanced technology. This is also dramatically reduces the challenge in integrating these capabilities into internal and third-party applications that are in use, including CRM, call center, back-office, ecommerce applications, and more.

We also provide the business models that make it easy for customers to try out the service for awhile, and then increase or decrease its usage over time as necessary, providing all of the user management, metering, and automated billing necessary to commercialize the capability. In other words, we help reduce complexity and risk for the customers of the service while providing user management, analytics, billing capabilities, and a distribution channel for Jaduka.

As this new offering demonstrates, we can provide these capabilities for data sets of all kinds and formats, multiple types of API interfaces, and even installed software and SAAS applications. And, it can be for the purpose of private, controlled services as well as public, commercial services. Getting to market fast is a big selling point.

Reducing friction, complexity, and risk will be key in driving the adoption of cloud and [blank]-as-a-service capabilities, resulting in wins all the way around.

Tapping into the Growing "Hosted Outbound IVR" Market with Jaduka

We are glad to announce our new partnership with Jaduka today. We have partnered to deliver a subscription-based Web service product that enables custom outbound IVR messaging to be integrated and used as a voice-enabling component for a wide range of applications.

It enables either text-to-voice (meaning words are converted to a computerized voice mimicking a human) or pre-recorded .wav files to be delivered to anyone or anything with a phone number, including mobile devices, VOIP lines, land-lines, and more. As with all of our services, we provide a SOAP and REST API interface that can be used to integrate this functionality into applications, business processes/workflow, Websites, third-party solutions, mobile applications and more.

Some of our research has shown that the outbound IVR market is increasing over 20% per year (from the $300-$400 million that it is now), and all sorts of new use cases are emerging. This all makes for an exciting offering.

For example, within emergency notification systems where it is important to communicate with a large group of people unexpectedly in a very short period of time, an additional mechanism such as outbound IVR can be crucial to getting the word out.

Within the monitoring applications of I.T. systems, many of which use SMS messaging today to report system problems or malfunction, you have a much greater chance of reaching support personnel via an automated phone call (even if it gets them out of bed). It's a good career idea to increase the number of ways a technician can be reached and dispatched before a simple, resolvable problem becomes a disaster.

E-Commerce and customer service are also places where there is broad applicability for outbound IVR, adding capabilities to report shipping notifications, shipping delays, billing information, and other types of automated notifications. Communication is obviously a key part of maintaining happy customers, and something about voice can be a little more memorable than just an email notification.

Of course, there is a long list of appointment reminder uses from the healthcare industry, beauty industry, and other appointment-driven business scenarios.

I personally wish airlines would use this technology to deliver flight change information to me and the long list of people who have picked me up at airports from time to time. It would be a great time saver.

And these examples are just the beginning.

From a technology perspective, there is also a considerable amount of customizable functionality a developer or message sender has control over, including voices, volume, pitch, speed, repetition of message and more. Also, the text-to-voice functionality can take input such as HTML, SSML, standard text or email (yes you can program it to call you and read an email message to you based on business rules.)

Since it is a usage-based model, organizations can start with lower usage levels, and then steadily increase the usage over time as they begin to experience the ROI. Subscription levels can be adjusted at anytime as always with StrikeIron, so it's a low risk approach to adopting the technology,

And of course the standards-based Web services API enables it to be used in all sorts of applications, including interactively from a Web form like that shown below, or within a broad range of applications such as Microsoft Excel (a communications dashboard can be built with zero programming), CRM, call centers, ecommerce systems, and anywhere else a SOAP or REST-based Web service can be invoked.

Now, thanks to this partnership, voice can be added to just about anything in a few minutes of simple integration.

Using StrikeIron's IronCloud to Integrate Your Own Data into Salesforce.com (SFIAAS)

One of the key features of our IronCloud technology is to the ability to take data in various forms and formats, structure it, setup refresh mechanisms, and then surface it as a normalized Web services XML API. This resultant API is then ready for integration and use into various applications, Websites, and devices.

The beauty of the hosted API model is that access to the API can be controlled and measured, and then easily made available for use by a broad range of internal and external applications over broad geographies with complete usage analytics and without the traditional software and hardware infrastructure investments and the time it would otherwise take to pull it off internally.

Once the API is available, sometimes the integration step into other applications can be simple and straight-forward, such as into an online shopping cart that utilizes sales tax rates and verifies shipping addresses. In other scenarios however, perhaps there is a requirement (or desire) to add additional business logic and capabilities around the integration of the API product.

An example of this is Salesforce.com and utilizing its Force.com cloud development platform. Here you might not only want to add integration to an internal or external data source, but you might want to have some business rules and user interface additions in support of that integration.

This is what we did with our Federal Do Not Call list data. Not only did we integrate it and make it available for use within Salesforce.com, but we also added visible green check marks to a contact record that had been verified as callable according to the data. We also recorded the last time the check was performed to ensure that compliance with the various Do Not Call rules was maintained. All of this adds to the usability of the integration, but none of it would be possible, or at least practical, without the underlying standards-based API that delivers the right data to the application when requested.

Other examples that we did this with using IronCloud-hosted APIs and Salesforce.com include US address verification, global address verification, and checking validity of email addresses.

This same concept could be applied to any data (or API-driven business process) where desire exists to incorporate that data into Salesforce.com for employee use. For example, if there are various data sources available within the organization that might be useful when viewed next to a contact record in Salesforce (such as previous transaction data, notes from other systems, internal trend data, etc.), that data could be hosted utilizing IronCloud. The API could then be generated, access rules created, and the same integration mechanism into Salesforce.com could be utilized. This is all pretty much turn-key with the technology we now have in place. Then of course there might be some user interface tweaks to provide the desired effect within Salesforce on top of the data. But pretty quickly, it can be done, and the selling and customer service process can be uniquely and considerably enhanced.

So of course, this ability to integrate data into Salesforce via a third party needs a name. How about SFIAAS, or Salesforce-integration-as-a-service? Because we all need another acronym.

Using Microsoft Excel to Send an SMS Text Message to a List of Recipients

Here is an example spreadsheet built by one of our talented technical support personnel that uses a macro to send the same SMS text message to a list of mobile telephone numbers. This does require downloading StrikeIron's LiveData for Excel add-in (it's free for use with all Web services that come through StrikeIron's Web Services Delivery System, including both public and private APIs - but there is a $495 license fee for use with all non-StrikeIron Web services APIs.)

The macro uses the authentication information cells, the "from" cell and the "message text" cell to compose the SOAP message, and then gets the target mobile number from the list starting with cell A8 in this case. The macro then iterates through A9, A10, etc. until it gets to the first blank cell in the list. In other words, this list could be 5 numbers, or 500 numbers. With each target number, StrikeIron's SMS Web service API is called (supports over 400 carriers worldwide) utilizing the parameter data from the spreadsheet, at which point the message is delivered.

Note there is also a tracking tag returned from the Web service after completion of the send call which can be used to ensure delivery to the recipient's carrier (the Web service itself is able to determine the carrier). There is another method in the API which enables the status of the tag to retrieved, and it may take a few seconds for a status of "delivered" to be reported.

This is a great example of pulling together server and client technologies to help complete a vision of what Cloud-based Web services components can deliver, especially when they are being delivered to applications that people are already using on a daily basis, like Microsoft Excel or Salesforce.com's CRM applications (which we also have created add-ins for.)

This particular StrikeIron-enabled spreadsheet could be used as a dispatching application, an interactive notification dashboard, the basis for opt-in marketing campaigns, or even combined with other Web services calls from StrikeIron or elsewhere.

If you would like me to email you the workbook, drop me a note at bob.brauer "AT" strikeiron.com:

Reducing Friction the Key to the Data Highways Driving the Cloud

A lot of "cloud" applications will have a need to communicate with other applications and data sources that are also living out in the cloud, or even with applications living behind a firewall that are somehow leveraging the cloud.

An ideal way for this communication to occur is via APIs, interfaces where data is passed back and forth between these applications (typically with XML using protocols like SOAP or REST) with an increased effort towards automation and getting more ROI out of these applications.

Not only will APIs enable the retrieving of information from external data sources to create a more data-driven and therefore useful application on a one-to-one basis, but exposing a public API enabling communication with a given cloud application can unleash waves of creativity to be driven by other developers and business users who have their own specific or custom use for that cloud application.

An example is all of the innovation that has emerged on top of the Twitter API, many of which are entirely re-defining what Twitter means to certain audiences, making people more productive with Twitter, and creating all kinds of additional value and staying power for the Twitter application itself, with each new application further increasing Twitter's shelf life.

However, driving adoption of a public API isn't always easy to achieve because of the inherent randomness to API development, from interfaces, authentication and usage models, data structures, response codes, and general API behavior. So even if user management, metering, and in some cases usage-based billing is already in place as part of a well-managed API, having a difficult or non-standard API can substantially slow adoption of that API, and perhaps even rendering it useless.

For example, there are hundreds of different ways to respond with a "data not found" response for a Web services API invocation, and a developer typically needs to learn what it is and a whole other set of rules for each API that they come in to contact with so they can develop on top of it. This adds a great deal of complexity, is not really scalable, and represents a major impediment to development of the back-end data highways servicing the cloud (not to mention a future mess of custom code), highways that otherwise could really help drive the usefulness of cloud applications.

What we have tried to do at StrikeIron is create a normalization layer for all of the potential differences that might occur from API to API so that a developer's workload and ongoing maintenance complexity is dramatically reduced. This is key when connecting APIs together to build exciting new applications and functionality, or connecting these APIs to existing applications that can benefit from their use (such as simple address verification call). Authentication is the same for APIs that live in the land of StrikeIron, as are interfaces, data structures, response codes and behavior, and of course all of the APIs published through StrikeIron share the same analytics formats, all regardless of what the underlying technology driving the API happens to be.

Take a look at the frictionless (or nearly frictionless) StrikeIron ecosystem below as an indicator of what the future cloud might look like, with several centralized pods like StrikeIron directing traffic and enforcing consistency and simplicity. As these API and data highway network ecosystems emerge, they will reduce a lot of the inherent complexity and randomness of cloud interfaces and enable others to easily hook into ecosystems without having to modify their own approach to the cloud, whether it's on the consumption side or publishing side of the universe.

The key is getting all of the inhibitors out of the way so that these data highways can flourish and connect applications to data and to other applications, including Web applications, social media platforms, internal applications, internal data, external data, CRM platforms, other on-demand applications, mobile devices, and any other component of value that someone might want to bring into the cloud.

What we have going on at StrikeIron I think this is a pretty good start to making it so. Fire me an email to find out how to hook into this (bob.brauer "AT" strikeiron.com) and see it in action.