A Consistent Business Model Across Many Different Web Services

One of the things I always like to point out is the advantage of having a consistent business model across many different SOAP and REST-based Web services and Web-based APIs when integrating external functionality or data into an application, Web site, or business process from the cloud.

For example, one area where StrikeIron makes many different useful Web services available is in the area of e-commerce. These services include things like United States, Canada, and even a broader global address verification and correction capability that is easy to integrate into any Web form where customers and potential customers' addresses are collected.

Also, we provide sales tax rate services, foreign currency exchange rate services (for showing local pricing), telephone number verification and lookup services, business demographic services (for customer profiling) and even services such as SMS text messaging and IVR text-to-voice for several different purposes, including shipment notification, as part of an e-commerce transaction.

We have found success because many organizations would rather outsource the ongoing data management and data updating process of these services rather than undertake the cost and complexity of doing it themselves. This is the ideal data-as-a-service model.

Rather than building out more non-core IT processes, an organization can then focus its efforts on its primary business and specific business processes related to it. This approach also ensures that all data sources are as current as possible, and a lot of functionality and detail is abstracted from the development group.

All of these various services combine for the occurrence of an optimized, enhanced, and substantially less complex e-commerce transaction with significantly less IT resources (and cost) required.

Now, the key point: one major advantage of incorporating multiple services like this through StrikeIron is that in each case, the business model behind the usage of these services is the same. This makes it dramatically easier to incorporate these services into an e-commerce Web site because you don't have to worry about business model differences from service to service, and adhering to many different business models dreamed up by many different vendors.

Otherwise, if functionally is cobbled together from many different sources, code will have to be written on a per-service basis to account for the different business models that might exist from each vendor, and this in turn introduces a good deal of complexity into an e-commerce site. In some scenarios the grim details of these differences will not arise until periods of heavy usage occur and you find yourself in a scenario dealing with several different vendors and their business models, a potentially stressful scenario indeed.

A few examples of simple variations of these Web service and Web API business models found across the Internet include monthly subscriptions, annual subscriptions, per-transaction fees, daily usage limits, ip-address level fees, developer key usage allotments, "credits" used in multiple ways, flat rates plus additional usage, and several more.

Providing business logic for adhering to multiple business models such as these and their various contingencies as part of business processes can be a tall order, and some of the simplicity sought in this model in the first place is then canceled out.

This is why we think our approach is simplest: many services and capabilities + one business model = dramatically less complexity. As people build more and more of the cloud into applications and Web sites, I think you will see this approach, which is practically a form of cloud business middleware, emerge.

Of course, it is true that you have more reliance on a single vendor in this scenario, and depending on the vendor this can be both good and bad. Now of course no one is 100% perfect, but I definitely have faith in our engineering and customer support teams, and we have a long list of customer references that will attest to the strength of our offerings and the system we have built and improved over the years. However, certainly do your due diligence on any vendor in any scenario when considering a consolidated approach such as this.

Comments

[Scott]

Interesting piece thanks Bob. Of the business models you referenced are there any predominant ones that seem to be emerging? If you don't mind sharing which one(s) does Strikeiron use the most?

[Bob Brauer]

Monthly and annual subscriptions seem to be the easiest and most predominant, largely because of the predictability in cost for customers. These are the two we use.