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.

Complexity-Based Pricing

In this post, prompted by Gordon's Notes on Complexity and Mobile Phone Plans, I want to talk about Complexity as a Weapon.

The term "Complexity as a Weapon" only occurs a few times on the Internet. Ten years ago, Scott Bradner wrote a column for ComputerWorld called Complexity as a Weapon. He was referring mainly to large software organizations resisting simple standards, as a tactic for achieving an advantage over smaller organizations with fewer resources. In a discussion with Russell Ackoff on Why few organizations adopt systems thinking, Jim Leemann talks about complexity as a tactic for resisting any kind of positive change. And an organization called Focus on the Global South accused oil companies of using complex accounting solely in order to reduce tax liability (Destroy and Profit, pdf).

---

But Gordon's Notes discusses Complexity-as-a-Weapon in the context of service pricing, where complexity is designed to prevent service consumers optimizing their service costs (so-called ninja shopping), as I indicated in my review of the Support Economy.

"Providers retaliate with an increasingly impenetrable array of extras, excesses and surcharges, which aim to recoup profit margins while making accurate price comparison near-impossible."

In Manufactured Uncertainty, the Farnam Street blog tracks how the practice of unbundling (for the purpose of making it harder for consumers to compare prices) has spread from mobile phone companies to airlines.

Excessive complexity of this kind is ultimately self-defeating: it adds to everyone's transaction costs, and erodes the value and viability of the service itself.

See also Billing Blunders

The Economics of Search

One of the things I like doing on this blog, as regular readers may have observed, is constructing mental mashups - creating new material by uncovering hidden relationships between old material from different sources. I am often stimulated by the diversity of material that comes into my newsreader.

Today's mental mashup puts together Alex Bosworth on Google: In your business, taking your money, and Masood Mortazavi on Transaction Costs and Search.

As Alex points out, there is clearly a difference between the following search outcomes:

• finding the best (cheapest, fastest, highest quality) supplier - from a complete and perfect search

• finding a good enough supplier from an incomplete and imperfect search

• finding the supplier that has the highest advertising budget - in other words, the one that is paying Google the most money

Meanwhile, Masood's post questions the assumption (found in neoclassical economics) that transaction costs can be understood as search costs, and also questions the assumption that internet search engines reduce search-related transaction costs. For my part, I'd like to know how does transaction cost theory address the trade-off between the perfect (and infinitely expensive) search and the imperfect search - where you don't get quite what you wanted, and get ripped off into the bargain?

These are questions that economists should understand. But what about the following outcomes?

• finding the supplier that meets your preconceptions of the requirement

• finding the supplier that meets Google's preconceptions of the requirement

• finding a supplier than can meet the requirement

As the difference between these outcomes indicates, search is a semantic/cognitive problem as well as an economic one. Google makes Herculean attempts to match content with advertising, or even content with content, and the consequent juxtapositions range from the helpful or serendipitous to the absurd or positively misleading. Earlier this week I relayed a story about such a juxtaposition - Cross Purposes.

In service-oriented world, as Rocky Lhotka pointed out recently, the transaction costs are dominated by questions of semantics. See my post on Semantic Coupling.

I should very much like to see an economic analysis of these semantic questions, but I somehow doubt whether this analysis is going to come from neoclassical economics.

Open Sauce 2

Following my earlier post on Open Sauce, Sandy Kemsley points out the link between SaaS and shared services:

"your older brother owns all the bottles of hot sauce, and your mom makes you buy from him rather than the kid in the next block ... if you don't like his taste and choose not to have hot sauce, then he still justifies his existence because he's still the household standard"

So why does your mom grant a monopoly to your brother?

• Because it improves your brother's supply-side economics. (He needs a critical mass of customers to be economically viable. She doesn't think he is ready for the harsh realities of the open market.)
  

• Because it improves your own demand-side transaction costs. (Your mom doesn't want you traipsing around the neighbourhood trying out alternative sauces when you should be getting on with your homework. Your mom thinks - argue with her if you dare - that homework is a core activity whereas sauce-procurement is non-core.)

• Because it reduces the overall complexity of the household, reduces risk and increases accountability. (If you get sick, she knows exactly who to blame.)

All these arguments can be used to justify standard shared services in an enterprise. But they always have to be balanced against the loss of opportunity and choice.

• Who gets to choose the flavour of sauce? Does the casting vote always go to the loudest or most awkward member of the family?

• Do some members of the family go without sauce altogether, rather than use the majority choice?

• Does trading sauce with the neighbours have any positive side-effects - for example relationship-building (trust) or learning new recipes (innovation)?

• And shouldn't your brother be getting on with his homework as well, instead of wasting his time on a venture that is only viable with Mom's intervention?
  

Sandy spells out some of the enterprise implications of this in a comment to James Governor's post on Shared Services and SOA. One of her main concerns is captivity versus choice - a factor where external services seem to have the advantage over internal services. I think this is generally correct. However, as I argued in my post on Service Competition, external services aren't always going to give you a decent choice either.

Job Bid Market

In his latest blog posting, The Service Repository Concept is Incomplete, Nick Malik suggests the creation of an exchange site, onto which service consumers could post a specification of the services they want. Similar demand-led exercises were also proposed for component-based software engineering. I wrote something in the CBDI Journal back in October 2000 about the Job Bid Market. More recently (April 2004), Lawrence wrote a review of TopCoder, which has an effective Job Bid Market, and a very precise specification process.

This is a very attractive idea, for many reasons. However, one of the problems with the Job Bid Market - whether for components or services - is the lack of precision and richness in specification. Without machine-readable precise specifications, the transaction costs are likely to be prohibitive.
Specifications need to include semantics as well as commercial considerations. Some of the characteristics of Web 2.0 may be relevant here, including user-defined semantics.

Pricing is also interesting. Nick suggests that consumers can indicate how much they would pay. But does this result in everyone using a service paying a different amount - like passengers on an airplane? Or is there some complex auction system where every consumer willing to pay more than X ends up paying the same X? There are some Web 2.0 possibilities here as well.

Support Economy

Review of The Support Economy, by Shoshana Zuboff and James Maxmin
Viking Penguin, 2002.

---

This book is a detailed and persuasive account of the distributed service economy, which the authors call Distributed Capitalism. The background is familiar. An ever-greater share of Western economy is occupied with services rather than products. And yet our experience of service is generally bad - and getting worse. Service providers are trying to achieve economies of scale and cost-savings, while maintaining or increasing revenues. Service staff are under increasing pressure and scrutiny, and "empowerment" is eroded by targets and other narrow initiatives. Consumers are subjected to the indignities of call centres, the persistent nuisance of "courtesy calls", and the inflexibility of business processes that have been tailored to fit an internal corporate agenda.
The promise of eCommerce was that it would offer a genuine alternative for business and consumer relationships. With some honourable exceptions, this promise has failed. Many early eCommerce efforts were coloured by naivety and amateurism ("if we can get a small cut from every purchase made by every large manufacturer, we'll be rich, rich, rich"), or by cynicism ("if we can persuade our customers to do their own admin online, we can get rid of half our staff"). General consumer experience of eCommerce is poor - often because the service details (good logistics, prompt and effective troubleshooting, and so on) have been neglected. And what has happened to all those B2B portals?

What Internet shopping encourages is something the authors call ninja shopping. If a consumer can easily compare prices for flights or car insurance (but cannot so easily compare other characteristics, including service quality), then selection will be based on price, and prices will be driven downwards. Initially this seems to work to the consumer's advantage. But the providers retaliate with an increasingly impenetrable array of extras, excesses and surcharges, which aim to recoup profit margins while making accurate price comparison near-impossible. (I call this Complexity-Based Pricing.)

Consuming services becomes an incredibly time-wasting activity. You have to wait in line to hire a car, because the clerk is obliged to try and sell an array of options to every customer. You have to check-in hours before a flight, and you still may miss the connection. You have to review all service bills carefully for unexpected charges and other errors. You have to wait for everything. (This waiting is an almost inevitable consequence of traditional process thinking: if a customer ever gets immediate attention for anything, this rings alarm bells in the process office, indicating that the relevant function is over-resourced.)

The authors argue that there is a huge potential wasted value locked up in these dysfunctional service relationships. They advocate a form of deep support, that will release/realise what they call relationship value, and they paint an attractive and detailed picture of the way it might work. They go on to argue that the realization of relationship value calls for a new enterprise logic: distributed, federated, dynamic, infinitely configurable; technologically supported by digital media and infrastructure convergence. From an SOA perspective, this sounds very familiar.

The book is not just an eloquent argument for the service-based business, but also a powerful vision of how it can and must be done properly. Recommended reading for everyone interested in the service economy.

Review first published in the CBDI Journal, July/August 2004.

---

The Support Economy Website

See also Shoshana Zuboff, Creating value in the age of distributed capitalism (McKinsey Quarterly, September 2010)

Related Post: Heartbeat Economy (January 2005)

Updated 14 May 2014

Labelling as Service

In the old days, when you bought a pie from a shop, or ate it in a canteen, you didn't really know what it contained. If there wasn't any beef or it tasted bad, you complained or took your custom elsewhere. If lots of people got ill after eating the pies, the place might be closed down. Otherwise, the recipe was private – if you asked for the recipe, you were politely told it was none of your business. In SOA speak, this is a form of encapsulation.

Nowadays, food products have to be labelled to death. I can demand to know where the beef was reared, whether the carrots were organically produced, and whether the pastry contains nuts. I want fair trade and dolphin-friendly. I want to know how much sugar, salt and hydrogenated fat, and does it contain enough food colour to make kids go berserk?

For food production, publishing this information adds to the suppliers' transaction costs in two ways: compliance and flexibility. If you claim something is organic, you may have to be inspected by the Soil Association or equivalent body. (The costs of proving you are operating organically are over and above those of operating organically.) If you identify your beef as Scottish, you can't switch to Irish beef without reprinting all the labels. Therefore suppliers generally try to get away with non-specific information, unless there is some marketing advantage in being specific. (E.g. you can charge more for organic.)

But there is a more general reluctance to provide information. With music CDs, the booklet often costs more to produce than the CD itself. Dan Hill complains about the paucity of music information (which he calls metadata) provided by iTunes. Bad MetaData Is Killing Music

This is a form of information asymmetry, which reflects an asymmetry of demand. Different consumers have different levels of information need, and suppliers like iTunes provide the minimum.

more on asymmetry
asymmetry@technorati

One way out is to separate the provision of information from the provision of the base service. We buy meat pies from one site, and pie recipes from another site. There are countless websites where we can get information about films or music, and these are logically separate from the websites where we can buy copies of these products, although of course there may be commercial links. This may be okay as long as there is some guarantee of version dependency – this pie was produced using this version of this pie recipe, this recording of this jazz piece was the version recorded in September 1957, with Joe Smith on drums.

---

Additional Comment

There are issues of trust: is the information service pointing at legal or pirate versions, how do commercial interests influence the selection or sequence of information, who (if anyone) cares about the accuracy or timeliness of the information. Finally, there is the question of granularity/composition: if the user's notion of a whole service is the proper combination of information service with base service (neither having much value without the other), then the whole service (including its total cost and QoS) needs to be managed somehow.

---

Update

Labelling as service 2 (October 20th, 2004)

Finance Industry View of Security

The financial sector generally has a one-sided view of security. There are procedural obsessions to protect a company from certain risks, but there is often a blindness to the ways a company creates or amplifies other risks. Here are some examples.

1. Many companies encourage their customers to use publicly available data (such as date of birth and mother’s maiden name) as if they were secure passwords. Whereas many security procedures advise changing one’s passwords regularly, there is no mechanism for changing date of birth or mother’s maiden name. (Try ringing your bank and asking to change these details on your record.)

2. When I ring my bank, I have to provide lots of data to prove that I’m who I say I am. But when my bank rings me, they do not offer any data to prove they are who they say they are; and they produce a rather weak response when I demand proof.

3. My bank rings me with a “courtesy call”. But before they can get into the courtesies, they demand that I provide my security data. This behaviour could easily be replicated by a phishing gang.

4. My credit card company sends me credit card cheques, perhaps hoping to trick me into using them to pay my gas bill. These cheques are sent as part of a direct marketing campaign (aka junk mail). No doubt many people throw them in the trash without inspecting them properly, where they can be retrieved by criminals.

5. My online broker accidently broadcasts an email to a large number of customers, without properly concealing the email addresses of the recipients. Soon afterwards, I receive a load of spurious emails demonstrating that the list has got into the wrong hands.

The overall result of this lot is that the security of my financial affairs is reduced. Unless I am alert and savvy, I may be victim to a range of social attacks.

When I have complained to banks about these examples, the general attitude has been uncomprehending. The bank reassures me that if I can prove that someone has been dipping into my account without my consent, or that a credit card check has gone astray, then the bank will compensate me. But that’s not the point. There is an increased burden (transaction cost) on me. I have to detect and prove any fraud (Some bank customers have been themselves accused of fraud when they have complained of spurious ATM transactions.) Because of the increased complexity of the security risks, I am forced to devote more time and attention to the security and integrity of my financial affairs – for example checking my account more rigorously, carefully shredding my junk mail.

Many customers may be led into adopting less secure patterns of behaviour. A marketing phone call may catch us offguard, and we are overwhelmed with mail (junk and otherwise). Many people may start to think it okay to divulge their security information to casual callers, if they sound sufficiently efficient and plausible.

As the world gets more complex, there are many new security risks, and we cannot blame the finance sector for all of this. However, we might reasonably expect a financial service provider to understand these risks better than most of its customers, and to take some responsibility for managing these risks. The behaviour of many companies, and the response when challenged, indicates either that they don’t understand, or that they don’t care.

More on Asymmetric Trust.

---

News Update October 2004

Banks launch Bank Safe Online website. See Financial Times story by Josephine Cumbo, Personal banking e-fraud on increase (October 2nd, 2004)

Full banking details

I had a printed slip from my bank last week, attempting to inform me about their new terms and conditions for international payments.

If someone sends me money from overseas, using electronic funds transfer (EFT), a surcharge will be imposed on me if the sender fails to provide "full banking details". But this kind of completeness rule is dependent on the bank's notion of completeness, not mine. Although I could probably make a reasonable guess, the bank might always say "Aha you forgot to include the XYZ code, so we will apply the surcharge, nyah, nyah".

As it happens, I was talking to the call centre on another matter and the woman asked if there was anything else, so I asked what "full banking details" meant. She wasn't sure, so she logged a request for someone else to call me and explain.

A few days later, someone did call. Full banking details means the IBAN number and the SWIFT code, plus Bank Name and Address. IBAN number is printed on my bank statement, together with a Branch Identifier Code, which is apparently equivalent to the SWIFT code (how was I supposed to know that?). Four items of data. Oh no, make that five, because she added the Account Name as an afterthought. Good thing I asked.

Of course, the person sending me money now has to find a way to insert these banking details into a local banking form, which doubtless has entirely different fields. (That must be why the ten million dollars from Nigeria hasn't arrived in my account yet.)

Think of the system implications of extending a completeness rule. Imagine a transaction that was complete last week, but is no longer complete, because we have changed some code from optional to mandatory. The transaction is still valid at the point of entry, but it is now incomplete relative to some downstream context. The transaction still works, but is no longer cost-efficient. (Perhaps we can make a lot of money from small surcharges before anyone notices.)

Think of the asymmetry involved when the bank fails to publish a specification of "full banking details". The bank can alter the way it handles some class of transaction without notifying its customers, perhaps even without working out the likely effect in advance, and we end up being surcharged. This may be a cynical ploy by the bank; but it may simply be that they do not suffer the consequences of their own incompetence, so they have no incentive to do things properly.

See also Finance Industry View of Security