Pay as you drive 3

Couple of posts from the Smart 421 people on usage-based car insurance.

• Telematics and retail insurance (aka “PAYD”)
• Usage based car insurance… why bother?

Their conclusion: it isn't going to save anyone enough money to justify the cost and inconvenience and to overcome the concern for privacy. Adoption only becomes viable when the devices become a commodity (multiple providers, standard interface, routinely fitted to new cars), with a strong carrot/stick from the government (e..g legislation or road charging).

This is pretty close to what I said when the Norwich Union experiment was abandoned last year (Pay as you drive 2). 

The Smart 421 bloggers also have some comparisons with Pay-As-You-Go models for other utilities, including domestic energy and water, and telecoms. Telecoms is clearly more complex than energy and water consumption, and has much more complicated pricing schemes. What are the lessons for software pricing - e.g. Anything-as-a-Service?

SaaS for the Pessimists

One of the critical success factors of SaaS is the paradox of confidence.

As I've pointed out here before, SaaS (Software-as-a-Service) helps you to manage your Service-Oriented Cashflow. By shifting from fixed costs upfront to variable costs later, you may be getting a cashflow advantage even if you end up paying more in total.

Now here's the thing about confidence. Optimists prefer fixed costs because they expect to get economies of scale; pessimists prefer variable costs because they fear they might not. So in an economic downturn, it makes sense for pessimists to shift a lot of expenditure to Pay-As-You-Go.

Some analysts are comparing SaaS (Software-as-a-Service) with ASP (application service provision). Although ASP had some notable successes, it wasn't anything like as commercially successful as its champions hoped. However, in times of credit crunch and pessimism, the cashflow arguments may be much more telling this time around.

Now here's the second thing about confidence. Pay-As-You-Go may improve the cashflow for the service consumer, but it typically causes cashflow problems for the service provider. So maybe only the most confident service providers - with the best technology and the most confident investors - can afford to offer services on a Pay-As-You-Go basis.

And here's the third thing about confidence. The consumer needs to be confident that the service provider is going to stick around. That means financial stability as well as technical stability. Does this mean it's the big companies who are going to make all the money from SaaS?

Microsoft certainly hopes that "Customers will write us bigger checks". See comment by Ed Brill (IBM), via Esther Schindler. But Microsoft can probably afford to wait for the cheques to roll in. Smaller companies will somehow have to find a way to finesse the cashflow.

Service-Orientation and Bureaucracy

A lot of business services are difficult to value. Take HR for example.

During an economic crisis, HR performs some pretty unpopular services. On the one hand, they may be the bearer of bad news to the redundant employee. On the other hand, they may restrict the authority of the line manager to dismiss employees without following the proper procedure. Does HR bureaucracy get in your way? asks Michael D Haberman. Newest despised role, suggests Dana Gardner, they are in no-win situation given economic climate.

However, the unpopularity of HR is nothing new. I fished out an old article called Taking on the Last Bureaucracy (Fortune Magazine, January 1996) and showed it to a few people, including Annrai O'Toole.

As ESB afficionados may recall, Annrai was the boss of Cape Clear Software, which was acquired by SaaS company Workday last year. Workday offers HR-as-a-Service plus Payroll, Worker Spend Management, Financials: ERP-as-a-Service, with a strong focus on human capital management.

Annrai agreed that the article was (sadly) still relevant, and made three further points

• HR must be strategic (not paper pushing) ...
• performance measurement must be automated and linked to business performance, not just subjective objectives - better BI (on hard business metrics) is the way to go.
• HR tooling must breakdown the barrier between the workers it serves and the environment they work in

Okay, let's suppose that most of the paper-pushing can be delegated to automated services (whether inhouse or SaaS). And let's suppose that performance measurement and policy compliance can be automated and made available for business intelligence services. And let's suppose that we have a decent set of communication and social networking tools.

But what is the business model for HR? What value does HR provide at the business level, and how can we design a portfolio of services to maintain and enhance this business value? If HR is strategic, does this mean that each enterprise has different requirements for HR services?

Bureaucracies are relatively easy to automate, if that's what you want to do. You can make a bureaucracy faster and more efficient, and you can move a lot of clerical processing onto an online self-service portal. But making a system more efficient doesn't necessarily make it more effective. So good design requires system thinking at the business level, before you dive into computer systems architectures, service-oriented or otherwise.

Maybe I'm being old-fashioned, but I can't see that it makes much sense to invest in an SOA or SaaS project to reduce the headcount of the HR department by (say) 25% if you still don't have much idea what value the remaining 75% are going to provide, and how you are going to make them more effective.

Market Predictions - CEP

What lies in store?

Complex Event Processing (CEP) guru David Luckham asks What are your predictions for 2009?

What challenges?

Prediction is hard, especially for experts. What is easier is to identify some of the challenges that have to be addressed. For example:

• Detection (Tim Bass)
  
• Interoperability (Opher Etzion, Tim Bass)
• Scope and Terminology (Opher Etzion, Paul Vincent)
  

CEP Products or Services?

David's starting point was a Forrester estimate of the market for CEP software and services. But what kind of services are these? Is Forrester just talking about conventional systems integration services - e.g. paying consultants to build and install your CEP systems? Or are we starting to see a genuine service economy based around the trading and collaborative processing of events?

A certain amount of this kind of thing goes on in the security world, with specialist firms performing what is essentially collective event processing for a number of customers (Monitoring-as-a-Service). But apart from that, I haven't seen much evidence of a distributed economy of complex events.

But why might this kind of thing be particularly interesting in 2009? Because the prevailing economic environment may make it harder to justify people going it alone, building large and complex event-processing applications for their own use.

Shortening the lead

Most people are expecting 2009 to be a tough year. In such circumstances, there is a widespread reluctance to invest scarce resources on remote gains; any vendors trying to sell solutions to business will need to find innovative ways of shortening and tightening the lead between investment and return.

For example, instead of vendors offering an elaborate set of CEP products, together with consultants skilled in wiring them together, there may be demand for out-of-the-box hosted solutions.

Shared Event Semantics

But in order to share events and event processing, firms will need to have a common event model. Which brings us back to some of the challenges identified by Opher, Paul and Tim ...

And Not Just Complex Event Processing ...

These arguments don't just apply to complex event processing, but to many areas of new technology. I'll look at some other areas in subsequent posts ...

Business Value from SOA - Longtail Optimization

Someone who hides behind the sobriquet "Mr Web Service" has posted an interesting idea: that software-as-a-service permits small firms to optimize fine details of their business operations, where this would previously have required the acquisition and installation of expensive software.[Software as a Service (SaaS) & UK/US Credit Crunch]

The (self-interested) example he posts is route-optimization-as-a-service, which is provided by German firm DNA Evolutions as well as his own company PostcodeAnywhere.

"Who can benefit from this? SMEs in the haulage industry who can’t afford the $90,000+ price-tag on traditional software that does the job. So far they’ve got by without it… all the SMEs have got by without it. This is an extreme example, of course, because route opt can reduce journey times by 30%. A lot of SaaS apps make less obvious savings or increases in efficiency. ... Now we’re facing a recession (sorry … credit crunch…) everybody is going to be forced to tighten their belts. In short, business will have to adopt SaaS in order to remain competitive."

This argument is making a fundamental point about the economics of scale. Whereas in the past this kind of capability only made economic sense for relatively large operations, SaaS makes this optimization capability available to small operations as well. So we are replacing the economics of scale with the economics of scope.

As Mr WebService admits, there may be some resistance to changing business practices in times of trouble (speaking words of wisdom: "Let It Be"). The total cost of deploying this kind of service is not just the cost of the software, but also needs to include the time and effort to get all the bits of the business process to work efficiently and effectively together - process design, testing and management.

So this raises the question how easy is it to use this kind of service - not just calling it in isolation but building it into an idiot-proof business process. How straightforward are the interfaces, how does this route optimization plug together with driver scheduling and vehicle refuelling and all the other capabilities? Do the different service providers have a common protocol, so I can switch easily from using the PostcodeAnywhere service in the UK and the DNA Evolution service in Germany? If I have to ship goods from Newcastle to Neuschwanstein, or from Evenburg to Edinburgh, how do I mix the two services?

Mr Webservice is probably right to identify some potential business value here, but there may be some more work to do to make this a genuine proposition for small companies.

"And when the software's cloudy,
There is still a web service for me.
Optimize tomorrow, let it be."

Laundry as Intelligence

During the "troubles" in Northern Ireland, the British Army operated a laundry - an apparently innocent laundry with some additional hidden functionality - checking dirty clothes for traces of explosive. [Washington Post via Bruce Schneier]

In my earlier post Services Like Laundry I said "I do not expect the laundryman to draw any inferences from the state of my clothes, or to pass these inferences to anyone". Clearly the actions of the British Army would count as a breach of this kind of expectation, but this would be justified by its effectiveness as a clever counter-terrorism measure. However, laundries might well test for various other substances, or test the DNA of any stains on the clothing, for a broad range of purposes other than counter-terrorism.

So what's the lesson from this? Basically, if you have any illicit substances or just embarrassing stains on your clothing, you can't trust the laundry service not to notice. And you certainly can't specify this not-noticing as part of the service contract - what are you going to do, draw the laundryman's attention to the thing he isn't supposed to notice?

And what if the laundryman noticed your shirts were getting a little frayed about the collar, and sold your address, together with details of your designer-label preferences, to a mail order shirt supplier? You might think this was unreasonable if you knew about it, but you would probably never find out. You might receive a mailshot from the shirt supplier, but you probably wouldn't connect it with the laundryman. (One possible mechanism for tracing abuse of your name and address is to give slightly variant names and addresses to every supplier, but lots of organizations nowadays have clever data cleansing software that wipes out these variations.)

How does this apply to other kinds of service? If I use CRM-as-a-service, how can I prevent my service provider picking up information about my customers? If I use a third-party delivery service, how can I prevent the service provider selling details of my customers and their purchasing habits to my competitors? How can I even specify this as part of the service level agreement?

WS Security standards cover some aspects of confidentiality and trust, but this merely relates to the security of a message in transit (at the technology level), and not to the broader questions of confidentiality and trust between two parties (at the enterprise level).

According to legend, the automatic telephone exchange was invented by an undertaker (Almon Strowger) who believed his business was being redirected to his competitors by corrupt telephone operators. (See Call Forwarding.) So this suggests a possible answer to this difficulty is to redesign the service architecture to reduce the enterprise vulnerability, supported by more sophisticated technology. For example, does your CRM provider really need unencrypted names and addresses, or can you pass your customer data through an encryption module?

So what's the lesson from this? You need an enterprise view of trust and security that is supported by (aligned with) a technology view of trust and security. The relationship between these two views is tough.

Service-Oriented CashFlow

In difficult economic times, the most important business measure for many firms is not profit or revenue growth or cost-saving but cashflow. Which means that the business case for SOA shifts away from relatively boring arguments about cost-saving (economics of scale), and strategic but highly imprecise arguments about flexibility (economics of scope), towards careful comparison of the dynamic economic viability of different business models (economics of governance alignment).

There aren't yet many SOA case studies that talk about cashflow. When I search for "service-oriented" and "cashflow", I keep finding references to a healthcare distribution company Owens & Minor, based in Mechanicsville VA, which started an 4-year SOA project sometime in 2005. (Speed Wins at Owens & Minor, Feb 2005) So nearly finished yet, chaps?

As I've explained in previous posts, the Pay-As-You-Go model has two advantages for the service consumer - better cashflow (because there is less financial latency between expenditure and return) and reduced risk (because you only spend as much as you need). As economic conditions become more volatile, and credit becomes more expensive, both of these advantages become more valuable.

Valuable for the consumer that is. The SaaS vendors (cheerleader Phil Wainewright) quite rightly see this as an opportunity for SaaS. But of course the challenge for the SaaS vendors is how to provide these benefits without themselves incurring excess cost and risk.

Billing and credit control are obviously key elements of the SaaS infrastructure, and some of Phil's clients offer useful services in this space. So are we moving towards a stratified SaaS world: (service-as-a-service)-as-a-service? And what are the economics of that?

---

Phil Wainewright on CashFlow: A Few Financial Home Truths. For mechanisms for handling billing see Phil Wainewright on Easing the SaaS-to-cash cycle and Marco Seiriö (RuleCore) on More CEP SaaS Pain.

Note: for various reasons, we now prefer the term Economics of Alignment. 

Updated 25 October 2013

Clouds and Clocks 4

An interesting debate on SaaS and Control

• Cloudy Future for the Enterprise and most likely for ISVs too (Gianpaolo Carraro, Microsoft)
• Tradeoffs in SaaS (Charlie Bass, EDS)

Gianpaolo starts out by suggesting a simple trade-off between user control and the economics of scale. With SaaS, the user forgoes some control, in order to benefit from (some share of) the economics of scale achieved by the service provider. Gianpaolo divides control into two aspects: Control of Features and Control of SLA.

Charlie thinks it comes down to a perspective of what is "control". He suggests a different notion of control, whereby a contract with a service provider would give you more legal control than doing the work in-house.

But as far as I can see, both of them are talking about Command (setting the target conditions) rather than Control (regulating the system to satisfy the target conditions). See Alberts and Hayes, Understanding Command and Control (pdf).

Gianpaolo associates the Control of Features with who builds the service (Implementation) and the Control of SLA with who runs the service (Deployment). (This is a bit of a simplification; I shall ignore that for the moment.) But in Service-Oriented Architecture, there is a third and perhaps the most important role: who specifies the service. It is possible for the user (or a community of users, or an independent regulatory body) to provide the specification, and for the provider merely to deliver an acceptable implementation and deployment. Returning to the distinction between Command and Control, we may associate the Command of both Features and SLA with who specifies the service.

But what kind of service are we talking about here? The economics of scale are most obviously associated with simple one-size-fits-all services that are symmetric and replicable - what Philip Boxer calls r-type services. In most cases such services are unilaterally specified by the service provider, offer little if any contextual variety to the service user, and control tends to focus on quality control and cost control.

With more complex types of service, the service user typically demands a much greater fit to a specific use-context, and the question of control expands to include requisite variety and the economics of governance. But does this mean that the economics of scale go out of the window? The challenge for very large and complex service-based systems is to combine the economics of scale AND scope AND governance.

Pay As You Go

In a recent post, Dave Linthicum talked about the Pay As You Go Challenge, and describes the benefits of Pay-As-You-Go in terms of shifting the risk from the user to the provider. Instead of the user paying for something upfront, before even knowing whether something works (generally, or in that particular use-context), the user pays only if and when it works, and can cancel at any time.

This pay-as-you-go model applies to software-as-a-service of course, and Dave urges that SOA vendors should adopt this model for SOA platforms as well, in other words, something like platform-as-a-service.

But there is a more fundamental economic basis for the pay-as-you-go model, which Dave doesn't mention. As well as shifting risk, the model shifts the balance of costs for the user - from fixed costs to variable costs.

Put very simply, the user's total cost equals fixed cost plus variable cost. Variable cost increases with volume, while fixed costs stay the same. (If you want a more sophisticated explanation, ask a friendly accountant.) Now fixed costs are subject to the economics of scale. If the user has a business process with a significant proportion of fixed costs, then the average cost will go down as the volumes go up. In some cases, a fixed-cost business process may only be economically viable if a constantly high volume can be maintained. But with a variable-cost business process, the average cost is much less affected by volume, and it is possible for the process to remain economically viable across a much wider and perhaps fluctuating range. In other words, a variable-cost process is much more adaptable to changing levels of demand than a fixed-cost process.

And this is where SOA comes in. Under certain circumstances, SOA can support the shift from fixed-cost to variable cost, and therefore can release a whole set of benefits related to adaptability and economic viability - the so-called On-Demand Business.

But only under certain circumstances. The problem isn't with the technology; the problem is with the traditional structures of funding and cross-charging within a typical enterprise or ecosystem or marketplace, which can make it rather difficult to establish adequate pay-as-you-go mechanisms, especially if noone else is doing it yet.

Thus pay-as-you-go is generally more difficult than traditional funding and charging mechanisms. If you are just starting out on your SOA journey, it might make sense for you to defer these difficulties until you have developed some experience and capability in other areas.

And this is where an SOA Adoption Roadmap or Maturity Model comes in. The purpose of one of these is to help you work out which capabilities you need in order to achieve which classes of benefit, and to help you tackle the difficulties in an organized fashion.

Does Multi-Tenancy Matter?

Multi-tenancy basically means that the service provider is supporting several customers with the same resources. (There is some ambiguity about exactly which resources we are talking about - hence the embarrassingly public disagreement between Oracle and one of its reference SaaS users described by Phil Wainewright in Many degrees of multi-tenancy.)

Gianpaolo Carraro previously made the point that if I'm a service consumer, I shouldn't care about multi-tenancy - The multi-tenant emperor has not clothes (August 2006), and now adds I can't believe we're still talking about this (June 2008).

With services like laundry, I really shouldn't care if my dirty clothes are put into the same load as everyone else's, as long as the service provider can reliably sort them all out and return them correctly. Some providers may think that the cost savings from multi-tenancy of the washing machine doesn't justify the hassle of labelling and sorting the clothes, but that's surely their problem not mine.

But if I have doubts about their competence and reliability, and if I have to double-check everything (= increased transaction cost) because I feel there is an increased risk of error on his part, then it becomes my problem as well.

Gianpaolo uses the example of a restaurant kitchen. If someone on the next table orders the same dish at the same time, surely I don't care if the chef puts two slices of meat together into the same pan. Well I do care if it means that the chef is tempted to compromise, or pays insufficient attention to my special requirements. As a service consumer, I may have some theory about the likely behaviour and incentives of the service provider (Gianpaolo talks about people wanting to show off their architectural capacities). But this only matters to the extent that it affects what I end up with, or when.

SaaS inherits from SOA the principle of encapsulation - the idea of separating the specification (WHAT) from the implementation (HOW). But a lack of trust between service consumer and service provider, as well as possible incentive incompatibility, leads to a breach in encapsulation. For SOA and SaaS to work properly, you need a good line on managing quality and risk. But that's a story for another post.

User-Based Pricing

One of the problems with user-based pricing for services is that it generally relies on an inflexible notion of the user.

In some cases, user-based pricing is fixed to a particular device (such as a laptop) or a physical channel (such as a telephone line). A user who wishes to switch device or channel must incur some inconvenience or cost. Conversely, two or more people using the same device or channel can use the service for the price of one.

Alternatively, user-based pricing can be controlled by login and password. (Sharing your login is a criminal offence, says Phil Wainewright, but of course that doesn't stop people doing it.) This is why single sign-on is so popular with service providers - because it inhibits sharing. (You might be willing to let me borrow the login for an online research library, but not if the same login gave me access to your bank account.)

But instead of trying to protect revenue by suppressing sharing, service providers should be thinking about better ways of charging in the first place. Office workers use paid-for services (Phil's examples include Dun & Bradstreet and WebEx) in order to perform some business process. If an office were organized as a traditional production line (sometimes called Fordism), then there might be a single clerk doing nothing but Dun & Bradstreet service calls. But of course most modern offices are organized in a more fluid way, which means that a single process step is passed around between colleagues. The notion of "user" is associated with a role within the business process, rather than with a named person; this makes perfect sense to the consuming organization, but of course the service provider will regard this as cheating.

If you are a service provider, you need to understand the business processes (within your customers) that trigger consumption of your services, and design a flexible charging scheme that is aligned to the value of these services in that context. Then your customers should be happy to pay a fair price for these services, and won't have the same incentive (or opportunity) to cheat.

Services Like Laundry

Just over a year ago, fed up with the over-use of the Lego brick metaphor, my colleague David Sprott proposed the laundry model of SOA (Explaining SOA to the Business). Antony Reynolds of Oracle quoted this in his blog today (The Laundry Model of SOA), which is what reminded me.

Both David and Antony talk about the contract basis of the laundry model.

• I delegate something (in this case cleaning) to the laundry service.
• Officially I don't care how it's done (although the term "dry cleaning" seems to indicate a preferred implementation).
• The laundry service accepts some (limited) liability for any failure.

These are typical characteristics of pretty much any kind of service, more or less. But there is a particular characteristic of the laundry service I want to talk about.

• I entrust the service with something (an asset) that belongs to me.
• I expect the laundryman to be discrete. I do not want my dirty linen washed in public - in other words, I do not expect the laundryman to draw any inferences from the state of my clothes, or to pass these inferences to inquisitive journalists.
• If something goes wrong with the service, then my asset is damaged. The potential liability is linked to the value of the asset, not to the value of the service. (If my dress suit is ruined, I am not going to be happy if I just get the cost of the cleaning reimbursed.)
• I do not authorize the service provider to use the asset for his own purposes. (I do not expect the laundryman to borrow my suit for his daughter's wedding.)

These characteristics are common to many services. I do not expect my CRM provider to try and sell things to my customers, nor to allow identity thieves to access their information. (Indeed, the customer information may not belong to me either; it arguably belongs to the customers themselves, who have entrusted me with their information according to the same pattern.) I do not expect my ISP to read my email, or interpret my search history. (Perhaps I'm being naive about that.)

However, there are many services where this is not clearly agreed. Perhaps I get some cut-price service, and this is only economically viable because the service provider expects to be able to broadcast some advertising to me or my customers. But if I am careless with the small print on the contract, I may not have understood this aspect of the deal.

And there are many services where this simply doesn't apply. For example, information services often simply involve transferring information from the service provider to the consumer, while Software-as-a-Service may simply involve transferring functionality. Obviously there are trust issues here as well - I trust the BBC to provide accurate and balanced news, I trust my internet security provider to protect me from viruses, I trust Microsoft Excel to calculate my profits correctly - but these are not linked in quite the same way to specific assets.

So I think the laundry metaphor is a very useful one, but like any metaphor we must be careful not to push it too far. All services are a bit like laundry, and some services are very much like laundry, but few services are totally like laundry.

---

See also

Services Not All Like Laundry (July 2008)
Laundry as Intelligence (Oct 2008)
Understanding Business Services (November 2012)

Ray Ozzie

Ray Ozzie doesn't do many interviews, so lots of people are finding interesting snippets from his interview with Om Malik last week [GigaOM Interview, March 10, 2008]. Jesper Joergensen (BEA) notes that Ray Ozzie plugs Amazon Web Services. Phil Wainewright interprets the entire interview as a signal of Microsoft's surrender to the cloud. Recently Ray has been a strong advocate of Microsoft's Software+Services strategy, which Phil has criticized as bunkum. But Ray has been a strong advocate of collaborative computing, dating back long before he joined Microsoft. In April 2003, when Ray was the Chief Executive of Groove Networks, he wrote this article: Perspective: A mosaic of new opportunities, which I have quoted before on this blog. (In my post Internet Service Disruption (November 2005), I called out a key difference between Ray's thinking and Bill's - a very early signal that Ray might lead Microsoft into new areas.) So I thought it would be interesting to see whether Ray's thinking has changed in five years.

Loose Coupling

"The next 10 years will find us moving decidedly from an era of personal productivity to one of joint productivity and social software. That will involve a move from tightly coupled systems to more loosely coupled interconnections." (2003) "If you look at the innards of a Yahoo or a Microsoft, an MSN, or a Google, you will see the people who have designed the systems and have taken a number of the things we’ve learned in the enterprise space. We have to throw them them away, because the way that we did it in the enterprise space was more tightly coupled. We need to be more loosely coupled." (2008)

A consistent appeal to loose coupling, but a somewhat different emphasis. The 2008 quote was prompted by a question about reliability, and he is invoking loose coupling from the supply side perspective - presumably motivated by his current supply-side responsibilities. In 2003, he was talking about loose coupling in relation to the end-user experience - in other words, the demand side.

Synchronization

"These changes will transform the personal computer into an interpersonal computer. This will be a rich, self-synchronized and readily interchangeable device focused specifically on people and what they do with one another online." (2003) "The Internet is this resource in the back end that you can design things to take advantage of. You can use it to synchronize stuff, and communicate stuff amongst these devices at the edge." (2008)

In his post Ray Ozzie bringing ’syncromesh’ to the Web, Larry Dignam points out that this has always been a consistent theme of Ozzie's work going back to Lotus Notes.

Power to the Edge

"What programming models can I give these folks that they can extend that functionality out to the edge? In the cases where they want mobility, where they want a rich dynamic experience as a piece of their solution." (2008)

Ray didn't actually talk about the Edge in his April 2003 article, but by September 2003 he was writing an enthusiastic review of a book called Power to the Edge. I'd really like to find out what he thinks about this now.

 

 

Links updated 14 April 2022

Software + Services

This week I visited Microsoft campus in Reading, to hear some presentations on their Software-and-Service (S+S) strategy, and have a chat with Gianpaolo Carraro.

Phil Wainewright recently described Microsoft's S+S strategy as bunkum, and accused Gianpaolo of drinking too much Kool-Aid. Phil's point was that people didn't want to worry about buying software AND buying services.

However, Gianpaolo isn't really focusing on the commercial side of the equation. He spends most of his time talking about deployment. From this viewpoint, it makes sense in many situations to have a combination of stuff running on your own machines (called software) and stuff running on other people's machines (called services). Actually that's what most users have anyway - both corporate users and domestic consumers.

But isn't it all software anyway? And who cares where the stuff is being run? Perhaps all of the people care some of the time, and some of the people care all of the time. I care when it affects my service level. For example, there are some places where broadband is unavailable, or at least very expensive. So if I want to work on an aeroplane, I may need to make sure the relevant documents are physically loaded onto my laptop beforehand.

The original vision of open distributed processing (ODP) included not only location transparency but other forms of transparency including migration and relocation. This means I don't notice when stuff moves around. Suppose I'm working on a bunch of documents that are currently on the server. Imagine my laptop knows my travel plans, knows that I'm going to be on an airplane this afternoon, works out which documents I'm going to need, and quietly and efficiently moves them while I'm in mid-edit, without dropping a comma.

I presume that Ray Ozzie, founder of Groove Networks and now Microsoft Chief Architect, understands these kind of requirements. He is pushing the S+S story hard.

But there is a conceptual problem with this semi-transparency - the fact that sometimes these aspects are visible and sometimes they aren't. ODP handles this by mandating several parallel viewpoints of a distributed system.

The CBDI method for service architecture and engineering (SAE) inherits this principle, although our viewpoints are not identical to the ODP ones. Meanwhile Microsoft has four perspectives, but these are defined in terms of process: Build, Run, Consume and Monetize.

When you want to think about deployment and location, you use one viewpoint; when you want to think about functionality and semantics, you use a different viewpoint; and when you want to think about commercial terms, costs and liabilities, you use a different one again.

I think this helps to explain the apparent disagreement between Gianpaolo and Phil. The S+S world looks very different from a commercial/organizational viewpoint and a deployment viewpoint. When I raised this with Gianpaolo, he made the valid point that these viewpoints cannot be totally isolated from one another. What happens from a deployment viewpoint inevitably has an impact upon the commercial viewpoint, and vice versa. Technological progress may help us reduce this impact, but it isn't going to disappear altogether any time soon.

But that doesn't mean the viewpoints simply merge into one unmanageable mess. The viewpoints are important precisely because they help us understand how things in one viewpoint relate to things in another viewpoint. And this in turn raises another important challenge. How are architects supposed to manage all this complexity? If you try to optimize the commercial/organizational arrangements alone, you may get unsatisfactory performance or service levels; if you try to optimize the physical deployment alone, you may not get the best commercial deal or organization structure; and if you try to optimize everything simultaneously, your head will explode. Gianpaolo's best advice at present is to do things at a very coarse level of granularity, which reduces the number of permutations to consider. But that's clearly not ideal.

The industry currently lacks decent tools to support this kind of architectural reasoning. We don't even have decent notations - you aren't going to get very far with colour-coded UML diagrams.

But what about enterprise SOA? Some people are working towards a world where all software is rendered as services - whether it is running on an enterprise server safely inside the firewall, or on a third-party server farm in Mumbai or Kiev. (By Day In Bollywood, By Night In The Ukraine.) Some of the same technical and conceptual issues here, but the terminology is different. S+S suggests that it only counts as a service if it is remote - this clashes with the enterprise SOA terminology.

Software-and-Services? The name may well generate some misunderstanding, especially if it is taken too literally, but that's probably true of any jargon. Not the name I'd have chosen, but then I'm not in charge of Microsoft's marketing strategy. Gianpaolo and his team have been working hard, producing some interesting material and examples, and the tools and techniques and future challenges coming out of this kind of work will undoubtedly be relevant to Enterprise SOA as well.


References

Gianpaolo Carraro: S+S: Real or have I drunk too much Kool-Aid? :) (Feb 2008)
Phil Wainewright: Microsoft Kool-Aid and the cloud
Gianpaolo Carraro: I think Phil drank the Kool-Aid too but he has not realized it yet :) (Feb 2008)
Ray Ozzie: MIX07 keynote, interview
Broadway Musical: "By day in Hollywood, by night in the Ukraine"
Reference Model for Open Distributed Processing (RM-ODP): Wikipedia, specification

Why Buy The Cow?

Webex (along with Unyte and a few others) provides a facility for meeting over the internet. Since Cisco acquired Webex, it has saved nearly a third of its travel and expense budget.

SaaS specialist Phil Wainewright describes this saving as a direct benefit of the acquisition. But of course companies can exploit web meeting as an external service, without acquiring the capability in-house. Indeed, this is one of the main advantages of SaaS - the ability to exploit external capability.

A recent book on Software-as-a-Service makes this very point in the title: "Why Buy The Cow?" In other words, if you are lucky enough to live near a dairy supplier, you can buy milk when you need it, you don't need to buy a cow to get a regular supply of milk.

No doubt Cisco has gained other benefits from owning Webex, but the savings from web meetings shouldn't be included. If Cisco and Webex executives are claiming otherwise, perhaps they should carefully read the book, which was written by, er, Subrah S. Iyar, co-founder of WebEx.

Is there ever a good reason to buy the cow? If you own the cow, you don't have to worry Who Moved My Cheese. In other words, there are certain types of change (sudden unavailability of cheese, uncontrolled increases in price) you can protect yourself against. But of course if you own a cow, there are now a lot of new things to worry about instead: Who Moved My Grass?

Link: Why Buy The Cow

... as a Service

It seems everything can be packaged as a service these days. Here are a few examples.

Application-as-a-Service

• Eltima Network
  

Data-as-a-Service / Master-Data-as-a-Service

• BEA
• Myers-Holum
  
• StrikeIron
  

Identity-as-a-Service

• Derick Cassidy (Oracle)
  

Knowledge-as-a-Service

• University of Texas
  

Security-as-a-Service

• McAfee
• NetSecurity
• ScanSafe
• WatchFire
  

and of course

Software-as-a-Service

(too many vendors to list - see Phil Wainewright's blog).

and finally

Solution-as-a-Service

• eProject
  

See also Edward Vielmetti's blog Service-as-a-Service

Service Escrow - Iron Mountain

Last month I riffed with Gianpaolo Carraro about Service Escrow. A few days later, a company called Iron Mountain launched an SaaS escrow service, covering the source code, system documentation and data.

• Iron Mountain press release
• Link to ThinkStrategies white paper (written by Jeff Kaplan, commissioned by Iron Mountain)

Gianpaolo (who is one of Microsoft's SaaS experts) refers to companies providing this service as SaaS undertakers. But it might be better to call them SaaS support. By acting as a safety net for SaaS providers and their customers, they may reduce the risk associated with SaaS and contribute indirectly to SaaS market growth.

I phoned Iron Mountain to find out more about their SaaS Escrow service, and the extent to which it differed from the traditional software escrow service. Here are some of the main points of our conversation.

Storage Model

Iron Mountain stores both the software (source code, object code and documentation - all of which belongs to the SaaS provider) and the data (which belongs to the SaaS user). Whereas traditional software escrow can often operate on a fairly slow cycle, with new software versions deposited in a fairly leisurely manner, SaaS escrow generally calls for live data backup.

If the escrow conditions are triggered, Iron Mountain will release the software and data to the SaaS user. To avoid any perceived conflict of interest, Iron Mountain does not operate the software - even on an emergency basis. But this means that the SaaS developers (or some appointed third party) must install and test the software on a new server, load and test the data, and then restore the service.

This is probably not something that can or should be done overnight - so it is not going to provide much protection against a sudden and unexpected failure of a business critical service. A more likely scenario is a gradual worsening of the relationship between the SaaS provider and the SaaS user, and a growing dissatisfaction with service levels and support arrangements, approaching the point where the SaaS provider is in breach of contract. SaaS escrow means that the SaaS user has a reasonable exit from an unsatisfactory relationship, and cannot be held to ransom because the SaaS provider controls a key business asset.

The economic benefits of escrow therefore fall under the economics of governance - making sure the SaaS user has proper control of the relationship.

Charging Model

Although the SaaS provider may benefit from the existence of SaaS escrow, the prime beneficiary is the SaaS user. Historically, it has always been the user who has negotiated and paid for escrow. However, Iron Mountain is increasingly seeing more complex arrangements whereby the software provider pays for the escrow and passes these charges onto the sofware user.

In the case of SaaS escrow, a typical arrangement would be that the SaaS provider pays for the deposit of the software, while the SaaS user pays for the deposit of the data (depending on the data volumes).

It is in the interests of the SaaS user that Iron Mountain always holds the latest version of the software. Iron Mountain therefore encourages the SaaS provider to deposit software upgrades as frequently as necessary - preferably online - and does not charge on the basis of frequency. (Remember that SaaS software may undergo a faster improvement cycle than traditional software packages.)

Management Process

SaaS escrow only works if the SaaS provider has adequate software configuration management and data management, so that it becomes a matter of routine to send controlled copies to Iron Mountain. There is a certain amount of ongoing verification and audit that needs to be carried out, involving all the parties to the escrow arrangement, and Iron Mountain sees this as an important aspect of its own role.

Remember that the SaaS user does not see the software unless and until the escrow conditions are triggered - so it isn't possible to test the escrow arrangements in a trial run exercise. Instead, it is necessary to test the process at a higher level of abstraction, to provide some reassurance to the SaaS user that the escrow would work adequately.

Future

This is early days for the SaaS escrow market, and I shall be interested to see how the market develops ...

Service Escrow

A small SaaS company bites the dust, reports Gianpaolo Carraro, Director of SaaS Architecture at Microsoft.


Obviously this is not just an SaaS problem. Companies fold all the time. If you are dependent on some external capability, you'd better have a plan for business continuity. And if you have entrusted your supplier with important assets (e.g. data) you'd better be able to get your assets back quick.

A pessimist might regard this risk as a reason to avoid SaaS altogether. But I don't think Microsoft employs many pessimists. For his part Gianpaolo sees this risk as an opportunity for some enterprising SaaS undertaker - selling services to those whose beloved supplier has gone to the great SaaS graveyard.

I prefer to see this as an architectural challenge:

• How can we design a robust network of services, one not affected by a single point of failure? (This is of course a classic problem of distributed systems.)
• Are there patterns of collaborative networks that will stand up to the loss of any single organization in the network?
• What are the appropriate SLAs to support these patterns?
• And what are the interoperability requirements to make this work?

Structural problems call for structural solutions. That's what architects are for.

Update

Gianpaolo's initial response here: SaaS Undertaker (April 2007). Shortly after my exchange with Gianpaolo, a company called Iron Mountain launched an escrow service. See my post Service Escrow - Iron Mountain (May 2007).

SaaS Continuum

Fred Chong of Microsoft has just posted something on his blog Defining the Software-as-a-Service Continuum. He defines what he calls "the (high-rise) elevator pitch of the 3-Ls" - and here's his picture.

Fred Chong, SaaS Continuum

I like the 3L framework, and would like to extend it to a 4L framework by including Liability.

Software liability is already a difficult topic (see for example Whose fault is it anyway? and Taking on software liability by the BBC technology analyst Bill Thompson). But Software-as-a-Service is more complex, because the liability potentially works both ways. Service providers try to avoid being made responsible for breaches of copyright or data protection, for libel and defamation, or other bad behaviour taking place on its systems.

Fred has mentioned some aspects of liability previously

"hosters ... hosting business need to worry about the risks and liability of hosting third party code" (Enabling the long tail of SaaS providers)

but I think it needs a much more systematic treatment. Perhaps some of the leading SaaS bloggers would like to join in?


Image restored 5 June 2018

Business Case for SaaS

Gianpaolo Carraro (Microsoft) has produced an interesting diagram laying out the benefits of Software-as-a-Service (SaaS) to various actors.

SaaS stakeholder concerns (Gianpaolo Carraro)

This makes clear that different actors have different motivations to get involved in SaaS - and for that matter SOA. Each actor may have several parallel motivations, with different perceived urgency levels. In his blog, Gianpaolo discusses the typical short-term and longer-term interests for each of the types of enterprise he identifies. This is useful material, and helps us to see different adoption paths for SOA and SaaS within different organizations.

But there is a common pattern here as well. The potential benefits of SaaS indicated here are mostly architectural ones (Gianpaolo is an architect himself, after all) - changing the configuration of the stack, changing your own position within the stack - delivering not just economies of scale but also economies of scope and economies of governance.

So I'm not just interested in the content of Gianpaolo's picture, but the underlying process. This is the kind of business case that depends more on PowerPoint than on Excel. The trouble with this, of course, is that PowerPoint lacks rigour. Ideally, we need to develop better ways of producing architectural models that support reasoning about business benefits.