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."

SOA and Web 2.0

Economic principles such as network effect and the long tail play a role in how Web 2.0 may impact your business.

Network Effect

• The value of a service in one place depends on the amount of usage elsewhere – the more the better.

• This is especially true of services that offer some form of communication – the value of the service depends partly on the number of other people you can communicate with.

• There is a positive feedback loop – as more people use the service, it may increase in value, thus persuading more people to use the service. This feedback loop may result in a rapid growth curve.

• This leads to the concept of critical mass – the level at which the growth curve becomes self-sustaining.

Long Tail

• The traditional Pareto principle (80% of the value comes from 20% of the cases) assumes a significant proportion of fixed costs. For example, a bricks-and-mortar bookshop must devote shelf space to any book in stock, and there is a cost associated with excess inventory.

• But in a service-based economy, it may be possible to alter the supply-side economics – for example shifting from fixed costs to variable costs – and this means that the rare items (both individually and in aggregate) could be as profitable as the popular items.

• The economic viability of the long tail depends critically on bringing down the fixed costs of servicing the long tail, and shifting to a more flexible variable-cost regime.

Web 2.0 and SOA together can help provide a cost-effective way of accessing these network effects and long-tail benefits.

• Cost reduction – leveraging existing systems through services, helping to cut cost of customization

• Cost mitigation – providing services not solutions, shifting responsibilities to collaborating partners. For example, customer self-service, small communities providing their own solutions. Thus collaboration helps spread the cost.

• Shift from fixed cost to variable cost – for example through “pay-as-you-go” on-demand pricing – thus helping to reduce the risk and the barriers to adoption.

At the same time, IT organizations are also often looking for ways to improve the delivery of solutions to their business users. Web 2.0 technologies and approaches may help reduce developer effort and time to solution, as well as providing more agile solutions that can be rapidly remixed and re-assembled to meet changing demands.

Challenges/concerns

In order to achieve these Web 2.0 benefits, there are some questions that need to be answered:

• What are the implications for IT management? How can I guarantee the continued security of my core systems? How can I provide the necessary quality of service to my existing users as well as the new ones?

• What are the implications for business management? How can I guarantee the continued integrity of my products and services? If third parties are able to mash my services with external services, how can I retain control of my brand and corporate image?

• What are the implications for corporate governance and compliance? Do these external arrangements introduce new risks?

Clearly many organizations will not be prepared to go ahead with Web 2.0 without good answers to questions like these. This is why it will be important to have a well-structured approach to Web 2.0 and SOA.

---

This is an extract from an article Lawrence Wilkes and I wrote in February Extending SOA with Web 2.0. Commissioned by IBM and available free from the CBDI Forum website.

Service Planning 2

Nick Malik asks Should SOA be Top Down or Bottom Up. He suggests that architects need to pay attention to the big pieces and can ignore the small pieces.

"While the architects do not need to know about every moving part, they DO need to be aware of the largest of those parts, and make sure that they are managed well. This is similar to city planning, where the city needs to work with a large employer or a large retailer (like Walmart) to make sure that roads and parking and congestion issues are managed, without having to worry about cafe and card shop that are also employers, but have a minimal impact on the infrastructure."

Some people argue for a "fractal" notion of the service economy. While the word "fractal" isn't always used in its precise mathematical sense, its use seems to imply that the service portfolio should have a good mixture of different sizes / granularities (although not necessarily in the same architectural layer). Such a mix of different sizes is also advocated by Christopher Alexander.

In city planning, small retail outlets such as cafes and card shops may individually have less economic or environmental impact than a major retailer such as Wal-Mart. But collectively, they may have at least as much impact. (This is a "long tail" argument.) One of the challenges for city planning is to achieve a good balance between the large few and the many small. (Of course this raises questions of governance as well as architecture, politics as well as economics.)

If the total weight of the large pieces is greater than the total weight of the small pieces (whatever measure we choose for "weight"), then this is itself an architectural choice, with important implications for project agility and enterprise agility.

Most people in this game think they know what the terms "top-down" and "bottom-up" mean, but these terms are commonly used in different (contrary, confusing) ways. If an architect only worries about fitting the big pieces together, and assumes that the small pieces will somehow look after themselves in the remaining ("negative") space, this sounds like one version of what some people would call "top-down".

What if the architect concentrates on providing "positive space" in which the small pieces can thrive, and prevents the big pieces from encroaching on this space. What if the architect concentrates on the interfaces between the pieces, rather than the pieces themselves. Is this "top-down" or "bottom-up"?

I don't really care what we call this - although it would be good to have a more precise way of talking about it - but I think this is an equally valid strategy.



See also: What does Top-Down mean? (September 2011)

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

Reuse and ROI

Are services assets?

If you can double the use of a service, while reducing the cost of provision, then surely this represents an economic improvement. 

Roughly speaking, the economic efficiency of an asset may be calculated as a ratio between the economic output (e.g. average use-value multiplied by usage volume) and the economic input (cost of making and maintaining the asset). 

Does this mean that it is a good thing (from an economic perspective) to produce services with a decent reuse rating? Should we reward software engineers for producing such services? Should we invest software production resources in services? Not necessarily.

Economic productivity and ROI

Factory thinking calls for factory-style cost accounting. There is some dispute in the manufacturing sector about the DuPont ROI model, in which inventory (work in progress) is valued in cash terms. In lean manufacturing (at least under certain interpretations - see The Ghost of Sloan), inventory represents not asset but waste. 

So shouldn't we reward software engineers for not producing services? Should we perhaps invest resources in the destruction of redundant and wasteful and non-SOA-compliant services? 

And how should we calculate the ROI of a service? How should we calculate the ROI for a service factory? The conventional cost accounting methods don't seem to work very well here. 

There's a particular problem with calculating the value of off-chance and long-tail services - services with a marginal value for a large and uncertain user community. ROI calculations might be expected to guide service factories to producing rival versions of existing commodity services, rather than innovate into unknown areas.

SOA governance

How should service engineers measure (and account for) their activities? How do we make service engineering more accountable and transparent to its various stakeholders? 

Within a single enterprise, competition between near-equivalent services may often be suppressed, and developers may be obliged to use a single corporate service. Meanwhile, across a service economy, the emergence of alternative services may be a sign of a healthy SOA ecosystem. But pointless competition of proprietary services may be unhealthy. 

SOA governance must maintain the health of the SOA ecosystem, and this includes making the distinction between healthy innovation and unnecessary conflict and waste between rival services. This cannot be done by decree or regulation, but calls for a collaborative / emergent governance process. 

So what happens to a service that attracts rivals, loses its market share, and ceases to be economically viable? Should anyone invest in a new (and hopefully more reused) version of the service? If the ROI calculations are to be of any help in making such investment decisions, then we probably need to write off sunk costs, and concentrate only on the incremental costs. 

Inventory (legacy) starts to look like liability rather than asset. Thus SOA thinking is pretty close to lean manufacturing.

Self-Service

In my previous post, I talked about the difference between SOA 1.0 and SOA 2.0. In this post, I want to explore how the difference works by looking at Self-Service.

Here is the SOA 1.0 approach to customer self-service.

• A simple standard "one size fits all" service for all but the best customers.
• Use self-service to strip cost, risk and complexity from customer-facing aspects of service provision.
• Exploit economics of scale in back-office service provision.
  
• Outsourced or offshore provision is adopted for cost reasons alone, regardless of its effect on the quality of service.
  
• Low trust - reliance on simple security technologies, used mainly to protect the service-provider from expense and liability
  
• Customers treated as if they were stupid, lazy and/or dishonest.
  

But SOA 2.0 offers a much more attractive alternative - mass customization for the service economy. For example:

• Each customer can compose services according to the context of use.
• Each customer can customize processes and policies.
• Customer groups can self-organize and develop composite services for their members.
• Rich and productive service-based interactions result in higher levels of trust.
• Deep support for the long tail.
  

There can be little doubt that the quality of service we experience as consumers is seriously lacking. One of the most eloquent books I have read on this subject is Support Economy by Zuboff and Maxmin. Here's an extract from my review in this blog.

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.

Roman Rytov offers a simple example of what deep support might mean, when he comments that his favourite grocery store has the ability to analyse his purchasing behaviour, so he'd like access to the data as well.

Wouldn't it be a great idea to provide me detail statistics on what I've bought, how much I've spent on certain categories, what was my price deviation during a certain period, how I could plan my food budget, and so on, and so forth. ... For me this service would be a meaningful differentiator.

Here's another example. If the banks trusted the honesty and intelligence of their customers, they could allow the customers to help define the transaction policies governing their bank accounts. At present, my bank only offers me two options for online banking - Yes or No. Suppose I want the convenience of online banking - but only for small payments to known recipients. For large payments to unknown or foreign recipients, I am happy to incur the inconvenience of a personal visit to my branch, to eliminate (or at least greatly reduce) the possibility of impersonation. I should like to be able to write my own transaction security policy, in a standard policy language. which would be automatically executed by the bank software in addition to its own security policies for all attempted transactions on my account. Note that if lots of customers take advantage of such a facility, the consequent diversity would make fraudulent attacks very much more difficult, and this in turn makes everyone (except the fraudsters) safer.

Many of the technologies to support SOA 2.0 already exist. For example. rules engines that govern service execution dynamically, according to policy and context. For example, business intelligence tools that allow complex enquiries to be rendered as web services. And of course many of the same technologies that support Web 2.0.

But many service providers are still reluctant to grant customers access to these tools. Perhaps they will not act until some "killer demand" emerges that will force them to respond to the real needs of the customers. In the meantime, how long are we consumers going to have to put up with poor service, poor security, poor value?

SOA 2.0

There has been renewed discussion of Web 2.0 around the blogosphere this week. Tim O'Reilly posted a schematic diagram Web2MemeMap onto Flickr, and published a long article What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software on his website. Several of the blogs I read have linked to either or both of these, and some of them have copied the diagram.

Many of the elements of Web 2.0 are highly relevant to service-oriented architecture and the service economy. In this post, I want to extract two sets in particular.

Loosely coupled systems of systems	Small pieces loosely joined - web as components Granular addressability of content Software above the level of a single device Radical decentralization
User-centric	Users control their own data Rich user experience Trust your users Emergent - user behaviour not predetermined Customer self-service - enabling the long tail

If we apply this kind of thinking to SOA, a distinction emerges between SOA 1.0 and SOA 2.0.

SOA 1.0	SOA 2.0
Supply-side oriented	Supply-demand collaboration
Straight-through processing	Complex systems of systems
Aggregating otherwise inert systems and providing some new communication channels	Frameworks, applications, agents and communication channels understanding each other more deeply. Building a smarter stack and designing applications to take advantage of new constructs that (we hope) promote agility and simplicity.	Erik Johnson via Dion Hinchcliffe
Single directing mind	Collaborative composition
Controlled reuse	Uncontrolled reuse	See my earlier posts on Controlling Content and Shrinkwrap or Secondhand
Endo-interoperability (within single enterprise or closed collaborative system)	Exo-interoperability	I am currently preparing a longer paper on interoperability and risk. See my recent posts on Efficiency and Robustness.
Cost savings	Improved user experience	This is one of the areas where SOA starts to get interesting for the business and not just for the technologists.
	An emerging network-centric platform to support distributed, collaborative and cumulative creation by its users	John Hagel

There are some other elements of SOA 2.0 that I intend to discuss in subsequent posts.

Shuffle

In his blog Not Bad for a Cubicle, Chandler Howell analyses How does the music industry not get it?, arguing that piracy is a natural consumer response to the service-oriented strategy of the music industry.

• The recording industry [... has adopted] a self-destructive strategy of eschewing the long-term development of artists, preferring instead the quick buck of one-hit wonders ... If an artist is only going to have one CD worth buying and that one CD only has one or two songs worth listening to, then “schoolyard copying” is going to have a material impact on sales of that CD.

• There’s no point in paying for a CD because the consumer has been trained by the music industry itself to not value that CD. Recorded music has become a disposable commodity.

There are several complex issues here.

The one I want to focus on here is not the morality of piracy and DRM but on the structural changes that emerge from the conflicts of interest between different parties on the supply side - composers, performers, recording industry, music distribution channels/technologies (e.g. radio broadcast, iTunes/iPod). Among other things, these conflicts of interest have had an effect on the different granularity with which recorded music is supposed to be consumed.

Whole CD versus single song? 3-minute song versus extended medley? Concept album versus collection of greatest hits?

One of the consumer issues about moving from vinyl to CD was the apparent need to repurchase all your favourite music. But there was another important change, which altered the balance of power against the musician - the shuffle function. You no longer needed to listen to your favourite Beatles album in the fixed sequence provided by John, Paul, George H, Ringo and George M; you could break a coherent sequence of songs (often with carefully considered changes of key and mood) into a random series of fragments - every time a new experience.

(Why do we do this to music? I've never seen a shuffle function on a DVD player.)

With MP3 players, consumers can now hang a tiny juke-box around their necks, and listen to a constant shuffle of their favourite tunes. But why bother, when there are so many specialist digital radio stations that provide almost exactly the same service without the hassle of downloading and selecting the songs?

But some people are arguing that the internet restores the power of the musician, who can record and release a single song very quickly, without needing big record companies or fancy CD production. It is also technically possible to subscribe to vast quantities of live music from your favourite band. (Imagine having a virtual seat in every single concert in next year's tour.)

What are the general lessons of this for the service-based business?

• Technology can alter the preferred granularity of the basic service - how it's paid for, how it's delivered, how it's consumed, how it's combined into composite services.

• New business opportunities can be opened up by thinking about alternative levels of granularity.

• Flexible systems (both demand-side and supply-side) must be able to handle many different levels of granularity - preferably at the same time.

[Update] After I posted this, Chris Anderson made a similar point in the Long Tail blog, with a post called Shorter, Faster, Smaller, referring in turn to Seth Godin's Small is the New Big. Chris writes:

Note that this increased range of distribution options can allow for longer content, too, with the rise of TV shows on DVD (where you can watch much of a season at a single sitting) as a prime example. But the overall trend is toward shorter, faster, smaller everything. We're increasingly fine-slicing both the time we give media and the media itself.

Quite.

---

Another update: The Anti-Shuffle Brigade [BBC News 18 January 2011]

See also Adorno's concept of Atomized Listening, part of his deeper critique of the commodification of music.

Value of Emptiness

One of the perceived benefits of SOA is business agility and system adaptability. In this post, I am going to discuss some aspects of this.

---

There is a lot of vague and woolly talk about business agility - especially from the software world, where a wide variety of software products, platforms and paradigms are optimistically supposed to have some magical effect on flexibility. But try selling flexibility to the CFO of a large company. ("Excuse me sir, would you like to buy some flexibility? It will only cost you ten million dollars." "Exactly how much flexibility do I get for ten million dollars?" "Ooo, loads and loads, honest. Look, here's a graph we've just made up. And a 2x2 matrix.")

---

Among other things, business agility means keeping your options open.

• Options are worth more when conditions are uncertain.
• In financial circles, the value of options is calculated using the Brook-Scholes formula. Stock options increase in value with the volatility of the underlying stock. This encourages risk-taking by executives.
• Real-Option theory applies the same financial logic to management options. See book Real Options by Amram and Kulatilaka.

In the "plug-and-play" service economy, the business may gain option-value in several ways:

1. the ability to replace specific partners
2. the ability to flex the boundary - moving specific services inwards or outwards across the organization boundary
3. the ability to access heterogeneous domains
   
4. the ability to change the configuration (geometry)
   

To go beyond bland optimism, we need to think rigorously about the business value of openness and extensibility, and how this value can be achieved by suitable configurations of organizational and technical systems - including SOA.

---

Technical artefacts (such as computers) often have empty expansion slots. Ben Hyde discusses the option value of empty slots - who benefits from this unused real-estate?

When the vendor creates a slot he’s relinquishing control over some amount of value-creating energy implicit in his offering.

If there is anything consistent about how they get filled in - for example they all start sporting graphics cards - that’s not stable. The industry will absorb any consistent slot usage into the core.

The space of empty slots [... appears to be ...] a long tail [... which ...] actually has negative value. Since the majority of buyers don’t use the slots they are getting no value from them. The hardware makers are including them not because of buyer demand but because the dominant players in the market want them. The dominant players in the market want them because they tap into the value created by the generative process that all that empty real estate creates.

In other words, the expansion slots provide some temporary free space for innovation. But the big players monitor how this free space is used, and will seek to recapture any rich pickings.

Martin Geddes discusses a number of other technologies (past and present) that have added value by providing options. Many of these were initially dismissed as inefficient. Martin's list includes relational databases and XML - we might add web services.

---

Compare this with the adaptability of buildings.

Lots of old houses were built with outside toilets and no bathroom. Most of those that survive today have had inside toilets and bathrooms added. Many people convert loftspace to make extra rooms, or add an extension into the back garden. Old houses are often relatively easy to alter or extend, subject to planning regulations.

Construction companies build new houses on tight estates with shallow roofs - so there is insufficient space for expansion. Bathrooms are attached to so-called master bedrooms, thus constraining alternative ways of using the space. It is as if the construction companies deliberately set out to build houses that are pre-adapted to a specific domestic norm, thus forcing people to move house every time their domestic requirements changed.

See Stewart Brand: How Buildings Learn.

---

The human being is a highly inefficient machine, with few natural advantages over other species and practically no innate skills. It takes many years before it can find its own food, or run half as fast as an animal. It has a large brain, consuming vast amounts of energy and other nutrients. The exceptionally long period of dependence, together with its feeble skills in relation to other animals, represents a considerable biological burden.

How on earth does this gross inefficiency survive? In complex and dynamic environments, there is a compensating evolutionary advantage - the human has lots of expansion slots - can learn new skills, including collective skills. It can develop new languages - both natural languages and problem-specific vocabularies. (DSL anybody?)

---

So what are the expansion slots of a business? Obviously new products, new suppliers, new business partners, new channels. But more importantly, new responses to changing demand. With a stratified model of the demand-side, and with appropriate supply-side platforms, we should be able to (re)design a business to deliver requisite levels of agility. And this will naturally include space for innovation.

---

Update: Stewart Brand has now introduced the term pace layering for the principle that stratification should be based on the differential rate of change. The term shearing layers refers to what happens when this principle is not followed.

See also Andrew K Johnston, Business Flexibility - An Analogy (2005)