StrikeIron Blog

StrikeIron Worldwide - Global Address Verification

While many of our Web services APIs at StrikeIron are geared towards North America and North American data sources, we also have several with global appeal in use by many customers around the world, including six of the seven continents (unfortunately there are no customers wired into StrikeIron and our data centers from Anarctica yet).

As an example, we have a Global Address Verification Web Service that helps to provide shipping accuracy, fraud reduction, identity verification, and better overall global data for customer support for over 240 countries. This is achieved by utilizing many different country-specific postal data sources. Behind the scenes, all of this reference data is constantly updated so our customers don't have to worry about maintaining the most current address and postal information. This provides for significantly reduced complexity for our customers who are managing their own global customer or prospect data, and allows them to focus resources on their core business rather than managing address data.

This easy-to-integrate Web Service works simply by providing an international address as input parameters. Verification information, including additional data about the address, is returned by the service from our data center instantaneously over the Web in the form of an XML-based SOAP or REST Web service API call. This enables the resultant data from the service to be integrated into applications, Web sites, Web forms, third-party products, and business processes, typically (depending on the development environment) with just a couple of lines of code.

Many of the supported countries include over 98% street level coverage as part of the Web service. This applies to most of Europe including the UK, Ireland, Germany, France, Spain, Italy, Sweden, Poland, Portugal, the Netherlands, the Czech Republic, and several others.  This same level of coverage also applies to many other major countries around the world including Hong Kong, Mexico, Argentina, and Japan. Also, localized place names are utilized if desired.

In some countries where postal systems are less developed and there isn't the same level of street-level reference data detail available, you can still get city and postal code verification level data. This can aid in partial data validation that is still of significant value in many different usage scenarios. Some examples of countries that fall into this category include Nigeria, Syria, Montenegro, Vietnam, and Panama. More detailed information on the 240 countries supported can be found here.

Google's Strategy and Where StrikeIron Can Thrive

Google wrapped up its third annual I/O conference last week in San Francisco. There is still a tremendous amount of community excitement around Google and its products as the event had sold out two-and-a-half months earlier.

I think it's fair to say that Google TV and its latest Android 2.2 operating system seemed to get the most fanfare. In other words, there was not a great deal of mention of search innovation, Google's foundation, at the event. This of course is interesting as it gives us much more insight into the future of Google.

For example, take a look at the list of some of Google's major products:

- Search (including voice, and image search/Google Goggles)
- Google Chrome Browser
- Google Maps/Google Earth
- Google Docs/Google Apps
- Google Talk
- Google Buzz
- Google Analytics
- Google App Engine
- Android
- Google TV
- Gmail
- YouTube
- Google Translate
- Google Public DNS
- Fiber/Broadband

And of course there are several more, including those in embryonic stage at www.googlelabs.com.

So it seems that Google is competing in just about every space these days (and in the process creating a lot of competitors), causing one to wonder what their long-term strategy is. Clearly they are trying to have a major presence in the entire application stack of the Web (and also the fiber and broadband focus is interesting in this respect). And so just why is that?

Are they really just trying to make all of our lives better through technology as they often state?

Are they truly the self-appointed protectors of the Web, preventing any one person or company from owning the most important platform of our generation (seemingly the mantra in their battle versus the iPhone and iPad)?

Is there some kind of secret, world-dominating long-term strategy discussed in Google's basement with candles and robe-adorned chiefs Larry, Eric, and Sergey as the high priests, executing a pact sworn to in blood?

Is it just the usual Wall Street pressure of growing 20% per year requiring them to go after every related market they can get their hands on?

Or is it just a couple of multi-billionaire technophiles having some fun?

Whatever the case may be, the company has extended themselves way beyond search, and as the next couple of years unfold, we will learn more and more as to why if they can keep it all held together. They are definitely at a crossroads in terms of a corporate identity, so it ought to be an interesting story to follow.

One area that is of particular interest to StrikeIron and is quite exciting is the Google App Engine, a platform for developing and hosting scalable Web applications. In Google's version of the Cloud, application deployment considerations such as server redundancy, load-balancing, data center synchronization, and virtualization are all abstracted (and therefore handled) by the App Engine. While there are some obvious performance-related questions for heavy duty systems in the short-term (and likely solved in the long-term) as well as some currently limited capabilities (it doesn't support database joins for example), this will likely enable a broad level of application development to occur outside the firewall and out on the Cloud as time marches on.

This will in turn make it incredibly simple to make use of the various Web Services APIs for different functions that a company such as StrikeIron provides, including address, telephone, and email verification, sending SMS messages, calculating tax and foreign currency rates, and many more, as we abstract all of the details of these processes and data sources also. Therefore a developer doesn't have to worry about these details, especially ongoing data management and data updating. A single line of Python or Java code within the App Engine and the necessary (and most recent) external data is retrieved with all updates and daily data maintenance performed by StrikeIron and its operations team. This kind of expanded, abstracted functionality is what the promise of the Cloud is all about.

This expansion of capabilities of course speeds innovation and application development, and does so while significantly reducing complexity and cost and all while increasing application usefulness. This is a recipe for some exciting things to come, for Google, for StrikeIron, and for everyone else. Go Google go!

The Advantages of Web Services APIs

If an organization is utilizing external data sources to improve business processes, make operations more efficient, provide better customer service, or just to improve the accuracy and comprehensiveness of internal data on which a business runs, there are a couple of different approaches that can be taken.

Both of these approaches are fairly consistent regardless of the external data source. Whether you are utilizing outside data to ensure customer address accuracy (for shipping products for example), utilizing foreign exchange rates (for localized pricing on e-commerce sites), computing sales tax rates to complete online transactions, or anything else on which an external data source must be depended on, the process in both cases is generally the same.

The first option is to acquire, update, and maintain these external data sources yourself. This means you must acquire these datasets from vendors in their entirety since in most cases, you don't know which individual records of the data you will need. You will then need to store and maintain this data, build the data access for the applications will get the data, and perform ongoing data updates to keep it fresh and timely.

The other option is to "plug in" to these data sources over the Internet that exist out in the Cloud, typically via a Web services API using a protocol such as XML-based SOAP or REST.

Here is a breakdown of what is required in both cases:

#1) Using traditional in-house managed datasets you must

- obtain/purchase the necessary data set
- extract it from its medium (CDs, reel tapes, ftp download)
- create a load/data mapping process
- create a data access mechanism to get the data into applications, a Web site, or a business process
- regularly update the data - daily, weekly, monthly, quarterly
- store the data within a database system
- Obtain hardware resources for storing data
- take any production system offline to refresh data when the updates occur (or else create a sophisticated data synchronization method)
- perform testing after a data refresh to make sure the data reload was done properly
- typically have a "data steward" to manage and perform these various tasks

or

#2) Using a Web Services API you must

- integrate the API once into an application, Web site or business process with a couple of lines of code. This can often take a minute or two for sophisticated programmers, but might require referring to some code examples and some assistance for less experienced programmers, which might take a few hours, or even a day.

It should be clear which of the two approaches is much less complex, and also more time and cost-effective. Considering that the second Web Services API approach is generally transaction-oriented, you will also pay only for what you use rather than for entire datasets as in the first case, providing the ability to "grow into" the use of external data sources rather than placing big, costly bets.

There are always scenarios where it does make sense to manage the data yourself, but these are generally few and far between. What I have found in conversation with organizations that still do this self-data management is because of the arduous requirements of maintaining and managing external data sources, the data just doesn't get maintained, or at least is not updated as much as it should be. For example, I have had discussions with organizations that only update currency rate tables once a year. That becomes inaccurate quite quickly, especially these days, and could have serious repercussions.

Beyond the obvious cost and complexity analysis, it is really the difference in outsourcing a task that is not part of your core business and freeing up those resources to focus on your core business, versus trying to do everything yourself and not focusing on what is core.

The Creation of StrikeIron

I often get asked about the inspiration for the founding of StrikeIron, so I thought it might be a good idea to tell the story again. It helps people better understand the value and benefits of the company and our technology that we are delivering to a long list of customers today.

As one of the co-founders of a company called DataFlux, I was part of a team that built a company around the concept of data cleansing. This meant that we heuristically standardized data permutations that existed within data tables (for example: "IBM", "International Business Machines", "I.B.M."), eliminated duplicate records ("Bob Smith", "Robert E. Smith"), and made it easier to match data across different data sources when there wasn't a 100% match using these same heuristics. We did all of this through nice graphical user interfaces and utilizing novel database technology available at the time such as ODBC. Ultimately, the company was acquired by SAS Institute while it was growing and still continues to have a successful track record of growth today.

As part of this data cleansing industry at time, we also found ourselves in the business of reference-based address cleansing. This meant taking an address (100 Main St., Anytown, USA), standardizing it to make it easier to match, and then checking the 400 megabyte United States Postal Service master address database to ensure that the address indeed physically existed, the zip code was correct, and any additional known information about that address could be enhanced with a host of other data fields such as county name, congressional district, latitude & longitude coordinates, and more.

As everyone knows, new zip codes and addresses are continuously being added, so in order to maintain the highest possible accuracy rates for address cleansing, we had to ship new CDs every month from the USPS to all of our customers. These data updates then had to be added to the existing implementation, tested, and then moved to production environments. Depending on the customer, this often arduous and potentially error-prone process had to be performed every month, required resources and contributed to I.T. complexity.

Several years ago, when XML-based Web services began to emerge, it occurred to me that this technology and the Internet in general had the potential to solve this resource-consuming, costly-to-maintain address verification process. It was clear that the data updates could be performed at a master data center and then accessed as a function call over the Web whenever ”address verification" was required, simply plugging into the "great address verification machine in the sky" via the Internet. No more data updates and all of the associated ongoing complexity!

And then it occurred to the founders of StrikeIron that if it could be done for address verification, then there was a long list of external data sources and external functionality that could utilize the same approach. This of course could reduce all of the resources and cost required to maintain this data in-house, not to mention the accuracy degradation of internally maintained external data.

Today, the original address verification service has evolved into an entire Web-based data and business functionality delivery platform with several data products available, making this solution a reality for not only address cleansing, but demographic data, financial data, government data, telephone data, and other data sources. Also, programmatic access to functions such as SMS and email verification (with standardized business models) is now a part of the comprehensive offering as well.

The end-game for StrikeIron is the same now as it was when we released our very first Web service: greatly reduce the cost and complexity associated with integrating external data sources into internal applications, Web sites, mobile devices, third-party software applications, and any other entity that has the ability to consume SOAP or REST-based Web services. And of course do all of this in a reliable, bullet-proof 24x7 operating environment that our customers can depend on (we have deliver "five 9's" for years now).

We think we are delivering well, but please let us know if you have any good suggestions.

Still Web 2.0?

I've spent a couple of great days at the Web 2.0 Expo in San Francisco this week. It has been a decade now since the term "Web 2.0" was coined, and six years since the first O'Reilly Web 2.0 conference in 2004. I don't know though how long we will still be living in the confines of Web 2.0. You would think by now we would at least be at 2.1, but I guess the industry is stuck at 2.0 until it is no longer a useful marketing term, which is really all it has ever been. It is much like a "What's new in the Web" rather than a particular set of technologies being tracked over time and appealing to a certain subset of the Internet nation - the Web 2.0 Crowd.

For example, the earlier Web 2.0 conferences discussed concepts such as the open Web as a platform, rich Internet applications (RIAs), social networks (in their infancy at the time), platforms (YouTube, Wikipedia, Jigsaw, etc.), Mashups, emerging SAAS companies (Salesforce et al), APIs, and architectures of participation. Many of the exhibiting companies with offerings based on these concepts at the earlier conferences are still going strong, but many have also long since been acquired or are resting peacefully in Startup Cemetary, and many more than had been hoped of the latter.

However, at this year's conference, very little mention of these terms were made. Instead, the conversation was dominated by the looming browser wars (Chrome, Safari, IE, Firefox, Opera), HTML standards (HTML5), the fear of what I call the Wal-Martization of the Web, where a few dominant players recreate the concept of the Web to suite their specific purposes that all of us will eventually have no choice but to live within (evidenced by the ongoing Apple vs Adobe mud-slinging), iPads and iPhone demos, Google versus the traditional media, and of course APIs. It was at times almost a conversation of fear of the future rather than one of a new Spring of innovation, and I hope this is just a blip.

Now of course I am happy about the steadiness of APIs that they are still a significant part of the conversation given that the 40+ API's we deliver are at the core of our business, but it's really no surprise as APIs have actually been around for decades, so the usefulness and value of an API is not in doubt. StrikeIron has just helped bring them to the Web and out of one's own data center and enterprise software stack.

So it is more and more clear, and what many of us all really knew years ago, that for the most part the term Web 2.0 is meaningless, and instead is just a catch-all for the gradual evolution (and fortunately some may argue de-evolution) of the Internet as we know it and experience every day, with little daily changes that over the long haul appear to be significant.

But since I suppose Web 2.0 does not hold a whole lot of meaning, I guess we are not in any hurry then to get to Web 3.0, because it would likely be more of the same anyway. So why not leave the term the same for awhile since we all get it. The NFL team here is still the "49ers" after all.

Using Sample Code to Assist with Consuming StrikeIron Web Services

One of the key benefits of the various StrikeIron Web services products we make available is the ability to integrate a call to the Web service from within an enterprise application, a business process, a Web site or Web application, a mobile device, or with anything that has the ability to consume a SOAP or REST-based Web service (which is just about everything these days in the world of I.T.)

As a result of doing the simple integration to one of the services, all of the ongoing data updating, data maintenance and complexity of managing external data sources internally goes away as we take care of it from within our data centers. Depending on the data source and how often it changes, we do monthly, nightly, and sometimes real-time updates, and then provide access to those data sources via APIs that can be integrated into all sorts of applications supporting thousands of use cases.

For example, sales and use tax rates, the Do Not Call list, address verification, email verification, and even a global SMS service are all examples of some of these data sources and Web services we make available for easy integration.

For first-timers however, this is not always a matter of a few minutes like it is with experienced developers who can integrate all kinds of Web services and data sources in their sleep. The primary type of technical support inquiries we receive tend to be "How do I consume a StrikeIron Web service using [insert programming language here]?", or "How do we integrate StrikeIron within [insert development environment here]?" This is usually a result of a developer not having consumed any Web service in that particular language or environment before, not just a StrikeIron Web service, and he or she just needs a little help to get going.

To help overcome the learning curve, on each of our individual Web service pages we make sample code available (under "Technical Resources") with examples of consuming the given Web service from various programming languages. Also, I think you will find our technical support group (support@strikeiron.com) very knowledgeable and helpful if you need assistance beyond the sample code.

Taking a look at one of our Web services pages, you can see that for our US Address Verification Web Service that utilizes reference data from the United States Postal Service, we provide PHP5, C#, Java (Axis), and VB.NET sample code for the integration step.

Our online sales tax example also includes a Cold Fusion example. You can even find Ruby, Perl, Python, PHP4, and Flex examples on our site as well if you search the site using Google, Bing, or any other search engine using site only searches, such as "site:strikeiron.com perl" within Google.

Because of the consistency across all of our services (same interfaces, same authentication, same response codes, etc.) and the free trials we make available, it is very easy to interchange our various Web services within the sample code for a given programming language, especially since it is usually the passing of parameters that causes some difficulty in a language the first time out, regardless of what the parameters actually are.

Then we find that once a customer gets it going for the first service, rarely do they need help again. And that's the idea - we just work in the background while you go about focusing on your core business and not worrying about the time, cost, and energy associated with ongoing data updates.