Does a Services-Oriented Internet Make Sense?
By Bill Bittner, President, BWH Consulting
We have all had the experience, whether with the plumber who just can’t seem to fix the leak, the roofer who creates new leaks or the appliance guy whose only answer is “replace the unit.” The result is the same – either you continue to live with the problem, go to someone else, or fix it yourself.
Now the new paradigm for the internet is the “services-oriented architecture.” The concept is simple. Software packages that address specific problems will be catalogued on the internet and, by using standard interfaces, be accessible by processes designed to meet the user’s requirements.
For example, instead of each transportation application maintaining a database of highways and construction projects, they will be able to link to a “service provider” who will provide the latest information. The transportation application will be geared to the particular user’s requirements, but the status of the roads will be a generic service. Instead of being monolithic solutions developed by a single vendor, computer applications will become a combination of services provided by multiple vendors. This is where things become interesting.
I recently had my own real world experience trying to deal with multiple “service providers.” When I went to a broadband cable connection from dial-up, the improvement in speed was significant, but recently I began having problems accessing my email. The players in all this became: my browser and e-mail clients (Internet Explorer and Outlook); my security software (anti-virus and anti-spyware vendors); my hardware providers (switch and router); my cable company; my e-mail service provider (who was not my cable company); and of course myself and whatever options I had chosen for these various services when I installed them or signed up for them.
In the end, it appears my email problem was due to a bad cable modem, but the challenges I went through over the past three weeks to get to that conclusion would fill a book. Each vendor had a very logical explanation why the other guy had to be the problem.
A while back, I remember installing a new store polling application when, after several days of confusion, the operations manager literally locked the computer vendor, the polling hardware vendor, and the phone company representative in the computer room and refused to let them out until the thing was working.
The basic question is whether there is a risk that real time problems in a service oriented environment will become “unsolvable.” Could it reach a point where there are so many individual providers that when the “rubber band breaks” no one has the global perspective necessary to solve the problem?
As the internet opens up more options for services and the reliability of those services becomes critical, there is going to have to evolve some kind of rating system. Almost like the eBay rating system for sellers, service users are going to need a way to identify the “good” services from the “bad.” Maybe this can be a new role for the Better Business Bureau or the various standards bodies that define product requirements. The goal would be to prevent the failures or, if they occur, to at least have the individual services document the failure sufficiently so that all involved have access to the data needed to resolve it.
Moderator’s Comment: What do you see as the pros and cons for “services-oriented architecture,” as described by the author, in a business setting? Is
there a significant risk that real time problems will become “unsolvable” in a service-oriented environment? –
Bill Bittner – Moderator
I have to agree with Jeff Weitzman and Lincoln Evans. The problem described by Bill Bittner is not a “SaaS” example. It is a scenario which exemplifies the problems that self integrators (aka: DIY) have with multiple vendors and insufficient in-house IT skills to address a problem.
Focusing in on the software alone, the benefits and risk of SaaS are easier to see. The software was a particular browser, a particular e-mail client, and a security application. With software provided as a service, you would not have to have all these applications on your machine. Drop out the email client and it’s one less piece of software to manage. You could also get rid of the email filtering software. Use what the email service provider offers. It’s a solution. The software for a logically discrete function has been outsourced as a service. The benefits are, you spend less on software license, you have less IT education needs, you place more responsibility on the vendor, you have fewer throats to choke when it does not work. You can diagnose the problem easier. The SaaS market looks like it will be a very hot spend area in 2006 for retail, but it is still a small spend area for now. I suspect it will be limited to carefully selected point solutions and perhaps a few logical groupings of applications. This is where SaaS can excel near term.
Down the road, the hassle happens when a self integrator/DIY-type attempts to vend out a long string of different applications to different SaaS providers, rather than outsource the whole IT division. Then you still have an integration and management problem when something goes wrong. If you don’t have the IT skills in-house, you are going to feel the pain.
Suppose you want your purchasing application provided as a service. Good. It saves cost and runs reliably. You are brave! Next you get your inventory management application provided as a service. Still good. Then you need your forecasting application provided as a service… then transportation… then it goes on and on due to cost pressure until you discover you have a major stock out problem. Now what?
An even more interesting question would be: What happens when the SaaS market begins to consolidate and a vendor you don’t like or trust is now one of your vendors? Or better yet, a competitor buys one of your providers and now has your data?
SaaS looks like it has a long way to go.
I think it’s a matter of degree where you might find the services. I concur there will be inherent benefits and risks subscribing to externally designed web services. However, there certainly are success stories for internally developed SOA strategies. Take for example a multi-channel retailer who has multiple systems in place to handle customer orders. They tend to have parallel systems in place for the store system, web and call center. This brings with it inefficiencies, difficult data integration and associated costs for maintenance and changes that could be remedied with an SOA implementation.
Closer to home for most of us, Microsoft has for some time been floating the idea of hosting all new versions of their popular software applications online. Then we would not purchase Word, Excel, PowerPoint, Explorer, Outlook, etc. but rather “subscribe” to them and always access them through the internet. The theory is that MS can better protect their applications from viruses and other nasty stuff in this way, and update them whenever they want. Further, “bugs” would be flushed out into the light more quickly and efficiently.
I think we’re missing the mark here; the “services” concept described initially is not exemplified by Bill’s cable-modem horror story. Nor is this a description of “software as a service” of the hosted application variety, a la Corio (hardly vaporware, it was acquired by IBM for $182 million early this year, and is now part of a portfolio with $1 billion in revenue).
Rather, I think the reference is to breaking internet services into more efficient chunks so that each vendor focuses on their core competency. The network allows for far more efficient, on-demand integration of software and services that once had to be monolithic. Take for example, online maps. Most of the online services use the data from just a couple of vendors. They each have their own interfaces and add value to the service by adding things like local advertisers, other types of data like satellite images, etc.
Another good example is the Amazon API. Amazon has an open API to access metadata about a huge database of products. You can write an application that accesses album cover art, book info, product pricing, etc. from Amazon, and use that data in your own application or service. Nearly every little program that adds art to songs in iTunes pulls the images from Amazon. Similarly, the ID3 tags (metadata about songs) in iTunes are pulled from the Gracenote database, same as most other music jukebox programs.
Whatever you call this type of integration, it is NOT the same as having to use a bunch of different vendors for your services. This is not really new, it’s just becoming easier and easier to do.
If you are having a service-interoperability problem, you are probably not purchasing your service at the solution level, but at the component level and taking on the risk of integration yourself.
Most companies buy solutions, not components, as it is not their core competence. If the company is looking for a CRM system, then the solution should be at that level integrating all of the components need and giving the company a single vendor to point the finger at when something goes wrong. A generic interface to a CRM system greatly simplifies the cost of testing out several in order to see which one works best for that company, but also serves as risk mitigation in that, should something go wrong, there is little cost to switching to another vendor.
On the other hand, if the company already has a CRM system but is looking to upgrade the analytics behind the CRM system, the CRM system should utilize its analytics through similar generic interfaces. This would allow for products to be upgraded after the fact, but is a rarely-found feature because the vendor would want to capture revenues from any downstream upgrades. These lower-level interfaces allow companies who have a core competency at the higher level to still farm out the lower level details when they begin to fall outside of their core competence. For example, many companies, like Intel and AMD who use outside math libraries in their chips, utilize outside libraries to solve analytical tasks, like math, stats, financial calculations, and data mining tasks.
The simple solution in the scenario Bill describes is that third party vendors will spring up – and they have – to independently solve these problems.
However, I find this circumstance to be unique to situations where multiple suppliers own only one piece of any situation. The push for all these suppliers is to control each of the elements, i.e., both my phone and my cable company want to provide my phone, TV, and internet access. When they do, most of the equipment and software issues will more clearly be theirs to solve.
In my opinion, in simpler, one-vendor situations, I generally find internet providers to deliver superior customer service to “live” suppliers.
Most software is buggy, most hardware fails from time to time, and most networks have problems, too, at least occasionally. Whether the architecture is internet-centric or standalone, or whether it comes from 1 supplier or many, perfection is unlikely. If Microsoft had to pay simple consequential damages based on hours of work lost due to their bugs, Bill Gates would be a very poor man. At 2 different companies, I outsourced the systems to a single supplier. It was nice to have 1 number to call when there were problems, with no finger pointing. But it didn’t eliminate bugs.
Couple of issues buried in this article – application development, application reliability, cross-network quality assurance, rating systems. Too much to address… but, in the end, there’s an emerging trend around open source applications, such as Wikis (http://en.wikipedia.org/wiki/Main_Page) or Widgets (http://www.apple.com/downloads/dashboard/) allowing larger organizations to develop and customize applications without starting from scratch or customizing existing code. Essentially, these new applications are playing the role of ASP software providers of yesteryear. The USInternetworkings, the Corios, the Interliants… companies that customized and resold large software packages attempting to achieve scale. Of course, their businesses turned into vaporware. The difference here is that open source applications are already permeating online. For large retailers, it’s frightening to think they could swap out large pieces of code and huge software installations for free software based upon Linux. But one very large consumer products/retailer has already done so – Apple. iTunes is based upon the concept and done reasonably well (sic).