StrikeIron Blog

Reducing Friction the Key to the Data Highways Driving the Cloud

2009-07-09T11:08:51-04:00

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.

ClearSaleing Uses StrikeIron Currency Rates API to Keep Media Costs and Associated Revenue in Consistent Currencies

2009-06-29T10:59:28-04:00

As one of our many e-commerce related Web services, StrikeIron provides both current and historical foreign exchange rates that can easily be integrated into any application with a simple SOAP or REST call. The current/live exchange rates are updated every 30 minutes throughout each business day and are aggregated from a variety of global banks and currency markets. The historical rates provided (currently back to 2004) are based on the London close.

ClearSaleing is a customer of StrikeIron who is taking advantage of live integrated currency rates in an innovative way. Clearsaleing provides an advanced advertising analytics platform that tracks all forms of online advertising and measures the impact each ad has on the bottom line. This is achieved by incorporating sales margin data for transactions that happen both online and offline, providing deep insight into online advertising campaigns.

The solution goes far beyond simple click tracking. For example, it incorporates comprehensive Attribution Management, enabling profit and revenue credit to be assigned to all ads that contributed to a conversion, rather than just crediting the very last ad. It can also be integrated into back office systems like CRM, Order Entry, HR, and Accounting to tie offline sales and other relevant data back to the ads that produced an online lead, phone call or inquiry.

ClearSaleing's need for live currency rates stem from their customers with a global presence. The integration to StrikeIron enables accurate currency rates for any online search accounts (such as Google's AdSense) being tracked in foreign currencies. Then, media costs and the associated sales revenue associated with that media are accurately calculated using a daily rate and therefore not misleading due to global currency swings, or specific currencies trending up or down over certain periods of time. This helps ensure accurate data for the decision makers analyzing the success and failure of various media targets using ClearSaleing's analytics platform.

The Cloud Will Lead to a Proliferation of Service Components

2009-06-18T14:57:35-04:00

There is a lot of momentum for the "Cloud" these days. Proponents are insisting on the great value of both building new applications, as well as moving some old applications out into the Cloud to leverage the cost and complexity reduction the Cloud promises. Offerings from Amazon, Microsoft, Salesforce.com, Sun, IBM, Rackspace, and countless smaller guys bring a promise of speedier and easier application deployments. These raw IT-resource-on-demand farms are springing up everywhere, and thankfully the deployment tools are getting easier to use. There is no question, as an industry, we are headed in this direction.

While some applications were never meant for the Cloud, the groundswell of new entrepreneurs building new applications within it are leading the charge, primarily because of the lower cost of building complex system architectures with built-in redundancy and load-balancing that before required major hardware requirements and onerous contracts with data center providers. Also, enterprises are beginning to formulate plans for deploying applications to the Cloud where it makes sense to do so, and this is driving some additional innovation and will continue to do so for quite some time.

One of the more exciting things about this trend, aside from cost and ease of deployment benefits, is the new types of cutting edge computing it will spur. Just like the Web itself brought entire new classes of applications and innovation for traditional applications into existence, the Cloud approach is likely to do the same. We should expect to see applications that live in the Cloud leverage other computing resources that also exist in the Cloud. This Cloud-to-Cloud communication is only natural, rather than trying to reach back in to behind-the-firewall and proprietary applications, especially if there is a choice. Because of this, the Cloud ought to help enforce openness and standards out of necessity, which for most of us is a pretty good thing.

The way these applications are likely to communicate and leverage other Cloud applications is via messaging to and between API interfaces. Whether or not these applications and Cloud services exist on the same Cloud, or some distant Cloud won't matter most of the time (except in rare cases where performance makes geographical proximity an imperative.) For example, if an eCommerce application needs to verify the identity of a prospective purchaser, it need only call out to an identity API somewhere out in the Cloud with a set of parameters and then retrieve back a confidence score. This then can enable a decision to be made on whether or not to review a given purchase internally for possible fraud.

Perhaps the same application only needs to verify that an address entered by a buyer is correct and shippable. This too can just be a simple call out to another Cloud service. Thousands of building blocks and service components will be available for use out in the Cloud, and APIs and Web services will be the communication mechanism between these applications. Some of these service components will be public, but many more will be private, especially as architectural decisions are re-considered and more resource are moved out into the Cloud. Generally however, the integration approach will be the same, even if security approaches are not.

So while there is lots of work to do during this build-out period, those of us who have already built applications that leverage external APIs will have a good head start as we move in this direction.

Internet Retailer Boston Show 2009

2009-06-17T09:55:50-04:00

I was impressed with the traffic at the IRCE 2009 show this week in Boston, especially with the vendor turn out. There had to be over 300 vendors here pushing all kinds of eCommerce technology and products with enthusiasm. The eCommerce platforms were out in force with companies such as Zoovy, Broadvision, CommerceV3, GSI, Magento, Novator, Truition, Venda and VCommerce each with a significant booth presence.

In addition, a long list of payment processing firms such as JetPay, 2000Charge, Instabill, PlanetPayment, eBillMe, Verisign, Merchant E-Solutions, Fidelity Payment, DataCash, Check Paymentech, CheckGateway, RBS Worldpay, Trialpay, and Revolution Money (whew!) represent a partial list (apparently business must be good in that niche with transaction skimming models.) Ad analytics companies, fraud detection products, SEO firms, shipping logistics providers, and branding/creative firms were also prevalent. Heavyweights such as Yahoo, Google, Paypal, and Microsoft (showing off their new Bing search engine) also had a significant presence here.

While $200 is a bit steep to walk the floor (and without access to the keynotes), it was good to see all of the innovation still occurring in the eCommerce world, as well as a chance to talk to some of our partners and customers such as ClearSaleing, TicketNetwork, Telesign, and Zoovy. Floor traffic was heavy at times and light at others, and the general feeling I got from the vendors ranged from so-so to happy.

About 30% of StrikeIron's business comes from eCommerce implementations including address verification for shipping, sales tax rates, identity verification, SMS and IVR notifications, business demographics for customer profiling, and live currency rates all get integrated as part of optimizing eCommerce transactions from companies large and small. This enables our customers to focus more on selling their products rather than worrying about technology infrastructure and data maintenance and updates. So the IRCE event is an important one for us to be a part of and keep tabs on. I'll likely plan for next year as well.

Easy Integration of StrikeIron Web Services Into NetBeans Web Applications

2009-06-09T23:30:59-04:00

Sun has done an excellent job integrating StrikeIron Web services directly into the NetBeans IDE, making it easy to integrate the functionality of all StrikeIron Web services into a Java-based Web application. Validating addresses and phone numbers, calculating sales tax rates, sending SMS messages, retrieving D&B data, providing driving directions, or accessing any of the Web services StrikeIron provides can be done in a couple of minutes. Best of all, since StrikeIron handles all of the ongoing data updates within its data center, the developer never has to worry about keeping the external data current. It's all included "out of the box."

Here is an easy step-by-step tutorial showing the integration of the StrikeIron US Address Verification Web service into a Java EE Web application utilizing the NetBeans Visual Web Designer. It's simply a drag and drop exercise with a few lines of code to pass the appropriate parameters.

Here is the link to this easy tutorial: http://www.netbeans.org/kb/60/websvc/strikeiron.html

StrikeIron's Web Services have been integrated into NetBeans with versions 6.0, 6.1, 6.5, and are also part of the 6.7 release candidates now available at www.netbeans.org and can be used with any kind of application, not just Java EE Web applications.

Now for my favorite part.

The NetBeans team included four StrikeIron Web services within the "Web Services" node of the Services window within the NetBeans IDE. However, they have also integrated the StrikeIron Web Services directory service that enables the metadata of all commercially available StrikeIron Web services to be pulled into the IDE, including service descriptions, informational pages, and WSDL locations, so any StrikeIron Web service can be added to and utilized within the IDE.

You can achieve this by right-clicking on the StrikeIron icon in the Services window and selecting "Find StrikeIron Services." You are provided the ability to use a search term to search the StrikeIron directory for whatever service you are looking for. Once one is discovered and "added", the WSDL is then parsed by the IDE, the script compiled, and the class generated and added to the StrikeIron node of available Web services, all in a few seconds. The Web service can then be dragged onto the Visual Web Designer canvas just as in the example above, creating additional, enhanced functionality to your Web application.

Now that's cool.

Cloud Versus Data Center

2009-06-05T14:03:30-04:00

The question often comes up as to what the difference is between a "cloud" and a "data center", especially since there is a nebulous definition of what the cloud is, and even more confusion is generated when you hear people talking about building "cloud data centers."

To me, the primary differences between the two are abstraction and elasticity. There are also contractual and business model differences as well when one chooses a data center approach versus a cloud approach, but I am going to stick to the technical here.

First, abstraction is a key component of the cloud. Within the cloud, one gets access to servers, storage, and applications that exist in a data center (or spanning multiple data centers), but little visibility into where these resources are physically and what the actual specifications of the underlying hardware (and software) happen to be. These underlying physical resources might even change for a given cloud resource since these resources are shared (hence the term "virtual data center.") For a good number of developers, this is ideal because these details are not relevant to what they are building and deploying, and eliminating server configuration steps can help reduce deployment complexity and therefore increase the pace of innovation.

This is analogous to the thousands of developers who have integrated various Web services from StrikeIron into their applications. They don't care about the operating system platform we have chosen or the databases that we store the underlying reference data in. They just care about us delivering a sales tax rate to their ecommerce application in real-time, correcting an address, or sending an SMS message. They are not concerned about our implementation choices. It's the "what" they care about, not the "how."

In a data center scenario, which is still an important choice in some cases, the "how" is very important. Typically, a developer makes choices about the hardware that will be utilized and the software stack sitting on top of the hardware. Once these decisions are made, these resources then need to be managed over time.

For example, no one should ever have to respond to an alert message in the middle of the night to reboot their cloud server. Automated monitoring is typically part of a cloud offering that is again abstracted from the developer. However, in a data center scenario where the resources must be managed, if you don't reboot it, who will? (unless you are paying to have your servers managed). Hard drive failure? No problem in the cloud, as redundancy and failover is automatic. But in the hosted data center approach, unless you have made contingencies yourself, you will experience down time.

Second, elasticity is an important virtue of the cloud as well. A key concept of the cloud is that during very heavy load times, additional resources can be shared from a pool of resources when they are needed to handle that load. In a data center environment, typically idle machines must be ready standing by (and paid for even when not in use) to handle extreme user loads. Otherwise, Web sites and applications can crash under the weight of heavy usage.

There is also considerable cost savings contractually because of the pay-per-use-expand-as-you-go business models around cloud resources worth noting. However for large enterprises, those costs savings will likely be offset by retraining development organizations to leverage these new approaches to application development and deployment, so the savings will be long term in nature for these organizations.

For entrepreneurs starting from scratch however, the cloud-based business models will enable them to accomplish much more for less cost as the typical high level of data center investments traditionally made won't be necessary. This will help more startups come to life sooner, and lessen dependency on outside capital resources, which in the past has prevented some innovation from flourishing.

Finally, The cool thing about the cloud is its potential to take the computing industry into a period of massive new build out (that has already begun), and launch a whole new wave of innovation. This is largely because of the computing power that will be available to entrepreneurs and individual developers who in the past have not had the funds available to access these kinds of capabilities and power. I am certain that down the road we will be in awe of the kinds of companies that the cloud will spawn.

The Sun Behind The Clouds

2009-06-02T02:27:45-04:00

I often attend various conferences to explore new technology, keep abreast of the latest trends in the industry, recruit new partners, and try to discover new innovation that might be useful to StrikeIron, and more importantly of value to our customers.

This week I am at the JavaOne Conference in San Francisco where I am taking a closer look at Sun Microsystems' new cloud offerings announced this past spring and slated for availability later this summer, although it has been available to partners for a couple of months.

The first day was a CommunityOne event aimed at the broader open source community and focused on the cloud generically, but there was still a major focus on Sun's cloud offerings.

The key premise of Sun's cloud approach (and others of course) is that any developer will have the ability to create their own virtual data center and have it up and running in a few minutes. Now, this is simply server machines with electricity at this point and the applications still need to be built, but the machine abstraction and usage-based pricing is much better than negotiating machine types and annual contracts with your local Web hosting company experienced by those of us who have built traditional data centers. Ultimately, when applications are ready for production (or testing), complexity of deployment will be reduced significantly within the Sun cloud.

The first couple of cloud services Sun rolls out will be storage and compute, meaning remote storage (including MySQL virtual machines) and remote execution (no surprise here). All of this of course is built on top of Sun's OpenSolaris operating system and accessible by Sun's open cloud API's, which are RESTful APIs.

On top of this API, Sun has built a nifty virtual data center management application (based on technology obtained from their Q-layer acquisition), where the virtual data center can be built and deployed with a few clicks. This is done by dragging and dropping server and switch icons on to a palette and assigning the operating system to be run in a single click (Ubuntu, OpenSolaris, etc.) Within minutes, an entire Web-scale system architecture can be deployed.

One especially neat thing is the integration of Sun's cloud with their own applications such as OpenOffice. The free alternative to Microsoft Office will have new cloud-related menu items. For example, you will be able to "Save to the Cloud" and "Open from the Cloud" from the File menu, storing and retrieving documents to external resources on the Web rather than on your own desktop.

It will be interesting to see how Sun's offerings compete with Amazon's EC2 and S3 offerings, as well as forthcoming cloud releases from other major storage vendors (those same vendors who were scoffing at S3 a couple years back) in the race for developers' credit cards. Even though Amazon has significant momentum, Sun's offerings will be compelling with the integration that will occur with their OpenSolaris operating system, NetBeans Java development platform, MySQL database and Open Storage platforms, and applications such as OpenOffice. These collective weapons could really be a significant advantage over Amazon for serious enterprise cloud initiatives, as well as entrepreneurs.

Of course, this is all of great interest to StrikeIron. Not only do we leverage cloud resources ourselves with some of our computing activities, but applications that run in the cloud are naturally going to be in need of data services ranging from business demographic data, address, telephone, and email verifications, financial data (such as currency rates), sending of SMS messages, and many more of the APIs that we provide. It is much easier for an application in the cloud to call other APIs in the cloud. Our job is to make this as frictionless as possible with platforms like Sun is unveiling.

And of course, all of these cloud applications are going to need data, and our IronCloud data publishing platform is a great way to publish both public and private data out to the cloud for consumption by cloud (and other) applications, especially when these applications span multiple servers with a requirement to access data from a single point, and access to that data needs be controlled (and metered, maintained, analyzed for metrics...)

So there you have it, it should be a fun week out here in San Francisco, where the summer will certainly be cloudy (I will spare you the Mark Twain quote).

Mapping Web Services Output to Fields in Salesforce.com

2009-05-14T11:34:33-04:00

One of the cool things about our new solutions for Salesforce.com is the ability to map the output from a Web services call to the desired fields within a Salesforce account or contact record. While there are defaults of course, this provides a great deal of flexibility for organizations with custom layouts and fields, enabling them to take advantage of utilizing live external data to enhance contact records with zero integration and no ongoing data maintenance effort. This enables a fast and flexible approach to utilize external Web services directly within Salesforce.com.

To me, this is an example implementation of the proverbial "last mile", where a business user is able to integrate live data from external sources into the business applications that they are already using on a daily basis, completely customizable to fit their specialized needs, and with no programmers necessary.

In the example below, you can see the ability to choose within which fields the output data from our US Address Verification Web Service are stored in Salesforce.com, including correcting existing address fields, as well as providing the ability to store the additional data (such as county, geocodes, zip+4, etc..) that is returned from the address query.

Check it out: http://www2.strikeiron.com/Partners/PartnersSalesforce.com.aspx

Or search for "strikeiron" on the AppExchange.

SaaS Market Continues to Grow, Remains Attractive for Third Party Vendors

2009-05-11T10:39:30-04:00

In a report released last week, the Gartner Group reported they expect worldwide Software-as-a-Service (SaaS) revenue to Grow 22 percent in 2009, becoming a $9.6 billion USD market. SaaS is expected to have a compound annual growth rate (CAGR) of 19.4% through 2013, while the total market CAGR is projected at 5.2%. Clearly, SaaS applications continue to gather steam.

One area that stands out in the report is SaaS "office applications" (such as Google Docs, Zoho, Zimbra, EditGrid, and Microsoft Office Live), with its four-fold projection growth in 2009 from $136 million in 2008 to $512 million. Clearly this is also a major growth area because of its broad applicability, speed of innovation, and potential cost savings, and probably frightening to some well known entities in the traditional software industry.

While companies such as Salesforce.com and NetSuite are poster children of SaaS applications in general, SaaS CRM still only represents 18% of the CRM market. However, because of the high rate of adoption, rapid deployment, and virtually no ongoing maintenance, third party vendors will still find this market very appealing, largely because the first question from Sales and Support teams doesn't have to be "what version are you running?" The decrease in complexity in building on top of and supporting existing markets in the SaaS CRM space versus the traditional CRM space is dramatic.

However, It will still be a long time until on-premise software has any kind of swan song. While 30% of procurement software is expected to go SAAS, only 1% of the ERP market is likely to be penetrated by SAAS applications in 2013 according to the Gartner report. And due to privacy concerns, medical record data for example is a long way off from ever being stored on external systems. Don't rule it out entirely though - there once was a time where the idea of keeping your money in a bank was ridiculed (and perhaps in light of the current economy rightfully so!)

While the SaaS star continues to rise, and those of us on the cutting edge will continue to beat its drum, for a long time to come it will only represent a piece of the software industry. So for most of us, that means we will continue to live in a heterogeneous software world for the foreseeable future.

Force.com Native Integration for Federal Do Not Call Lists

2009-05-01T16:16:36-04:00

If you take a look at my blog entry from March 28th, you will see that I discussed an easy way to avoid federal lawsuits by incorporating Federal Do Not Call lists in to your business processes via an easy-to-integrate Web Services API. Now I am happy to say that it is even easier if you are a Salesforce.com user.

We have now integrated our Do Not Call Web Services API into Salesforce.com, and the resulting application has now been certified as a native Force.com application available within the Salesforce.com AppExchange. Telephone numbers within Salesforce.com contact records are instantly checked against U.S. Federal, State, Direct Marketing Association, and Wireless Do Not Call lists. Colorful, visual indicators within the contact record easily identify records that can be contacted and those who can't without risking an infraction.

It also is very flexible with the ability to map fields graphically from the Do Not Call service to the Salesforce contact record, including custom fields, as input and output parameters. And of course, all of the updating of the source Do Not Call list data is handled by us, so uploading and downloading of contact records for "Do Not Call processing" have now gone the way of legacy CRM systems.

Check it out on the AppExchange here:

http://sites.force.com/appexchange/apex/listingDetail?listingId=a0N300000016wjaEAA