Showrooming in the Knowledge Economy

In the knowledge economy, service providers often give away selected portions of their intellectual property, in the form of webinars, white papers, blogposts, free downloads or whatever. They then hope to generate revenue from other products and services. So the free IP acts as a kind of showroom.

Many knowledge consumers regard this as an open invitation to a kind of knowledge showrooming, surfing the web and mopping up enough pieces of knowledge to avoid ever having to pay for knowledge products and services. Meanwhile, most large employers have clamped down on all expenditure, so it is often easier for well-paid staff to spend several hours fruitlessly browsing the internet than to get approval for $100 to buy a report or a subscription.

(Meanwhile, many people have even given up reading real books, and some kids seem to expect to go through college without ever opening a book, hoping that they can make do with the garbled summaries they can find on Wikipedia and elsewhere. Unfortunately, this tendency is reinforced by the fact that an increasing number of real books seem to have been researched in the same way.)

I confess that I have avoided paying for things sometimes. For example, if I can find a working draft of a paper online, I am generally reluctant to pay to read the final version, especially as (a) it may be almost indistinguishable from the draft version and (b) the author is unlikely to see any of the money.

Here's an example of knowledge showrooming. Supposing you want a method and a tool and some templates and some training and some support. If you get them all from the same company, you should expect to pay for at least some of that. But if you can find one company that lets you download a free software tool, and a second company that publishes its method on its website, and a third company that is offering free training events (probably funded by companies that are trying to sell tools and methods), this seems to offer a tempting solution.

Of course, having spent several hours finding this stuff, it may take you a lot longer to get all these disparate pieces to work together; and even if you succeed, your productivity using this mashed-up solution may leave a lot to be desired. However, time is generally valued less than money, so many knowledge consumers and their bosses may be quite satisfied.

On the supply side, given that there is absolutely no prospect of any agreement between knowledge providers as to which elements should be free and which should be charged-for, knowledge providers are effectively undercutting each other.

(I have unhappy experience of this myself. In the late 1990s, I developed a detailed methodology and associated training for developing component-based business solutions. Although I did sell some training, the software vendors started giving their methodologies away for nothing, in order to sell greater volumes of software. Even though I thought my methodology was better, I just couldn't compete with free.)

Universities are now struggling with the implications of publishing lecture notes and other course materials online. Does this undercut the value of a real degree? Or can they construct some kind of remote/online learning experience and expect to charge serious money to distance learning students?  @RogerShank is sceptical, and so am I.

---

Roger Shank, Why are universities so afraid of on line education? (November 2012)

See also my post Showrooming and Multi-Sided Markets (December 2012)

SOA as Multi-Sided Platform

One of the ways to think about the complexity of SOA is as a multi-sided platform.

Some of the pioneering work on multi-sided platforms has been published by Andrei Hagiu at the Harvard Business School.  (Follow links from his homepage to some of his recent papers.)

In November 2006, I posted a brief commentary on Two-Sided Markets, referencing his work, and indicating its relevance to a service-oriented business strategy.

As yet, relatively few people have made the connection between multi-sided markets and SOA. In June 2007, Richard Friedman posted something useful on Multi-sided Platforms for Business or Software, and I found a paper entitled Optimizing the Supplier Selection and Service Portfolio of a SOA Service Integrator presented to a 2008 conference by a group of German researchers.

One of the attractions of SOA is that it should allow people and organizations to collaborate more effectively and cost-effectively. From the supply-side perspective, this means collaboration between the users of your platform. Your platform may or may not support a rich and open variety of collaborations, including mashups and other third-party initiatives, and this richness and openness significantly affects the demand-side value of your SOA platform.

The critical economic question here is not the economics of scale on the supply-side but the economics of scope and agility on the demand-side. Thus the critical question for platform design is how open/closed these platforms are, and the extent to which they constrain (overdetermine) or enable (underdetermine) demand-side activity.

Credit Crunch SOA - Restructuring

One of a series of posts exploring how the current economic conditions are affecting the SOA world. What are the implications for organizations and individuals?

---

Restructuring

A recent Gartner survey identifies restructuring as the top concern for CEOs in 2009 (SearchCIO.com, 15 October 2008).

• organizational restructuring - layoffs
• financial restructuring - de-leveraging to operate more on a cash basis
• corporate restructurings - spinning off units, preparing to acquire troubled companies or preparing to be acquired
• industry restructuring - who will survive the current economic shakedown

Restructuring has always been a major theme of the SOA world. In his article on the Business Case for Service-Oriented Architecture (November 2004, CBDI subscribers only), David Sprott wrote

"SOA is a structural approach in which business level services are published as atomic units of capability separating and formalizing the concerns of provision and use. ... The restructuring of systems capabilities into services presents a much broader opportunity for restructuring of business responsibilities and processes around the service concept."

But if the credit crunch is putting a new emphasis on structure and restructuring, this creates new opportunities for SOA - provided SOA can be positioned as a more cost-effective way of achieving the necessary restructuring. So let's look at the types of restructuring identified by Gartner.

Organization Restructuring

Organizational restructuring often targets areas that are considered of marginal short-term value to the firm. Vulnerable areas may include marketing, R&D, and (dare I say) enterprise architecture. I worked for a company once that sacked the entire marketing department during an economic downturn.

Let us assume that these areas are all needed for the longer-term survival and viability of the firm. So the challenge here is to keep going with significantly reduced resources, to maintain a minimum level of capability and visible contribution, and to be ready to scale up when conditions improve.

One of the key survival factors is closed-loop management - the ability to link specific activities (such as a given marketing campaign or architectural policy) with specific outcomes (such as sales growth or increased system quality). This allows the individuals working in this area not only to justify their continued presence but also to select those activities where they can make the greatest difference, and it allows senior management to see the wider consequences of a given level of resourcing. The faster and more finely grained the feedback loop, the more useful it is for management.

SOA may be able to help here. Depending on the current state of information systems, you may be able to create quick and dirty management tools, via mashups and other ultra-cheap technologies, to provide a detailed view of the effectiveness of your organization unit. You may also be able to devolve some of the less critical responsibilities to automated procedures and checks, in order to concentrate resources on the most critical responsibilities.

Financial Restructuring

As recently as June 2008, Richard Watson of the Burton Group was worrying about the paradox of too much SOA funding, and the need for financial restructuring. (2 Paradoxes of SOA Funding See also Joe McKendrick SOA funding paradox: pay today, restructure tomorrow?)

"At the peak of the cycle CIOs and CTOs can add some value implementing portfolio management and enterprise architecture. At the trough, CIOs look like mere demand aggregators with little influence to mediate the demand and supply of IT funding. ... An organization’s incentives need to be shaped to promote service provision, service reuse and support for shared infrastructure. Often achieving this means fundamentally restructuring a business into horizontal capabilities."

I don't know of any organizations today that have "too much" SOA funding. As Richard himself says: The paradox of too much funding for SOA has resolved itself. But this exposes a new paradox: it is precisely at the bottom of the trough, when the demands for restructuring are greatest, that CIOs have the least capability to respond to these restructuring demands.

But when Gartner talks about "de-leveraging", I guess this is just a fancy word for "thrift". Not doling out money up-front, not acquiring parcels of dodgy assets, but shifting to a cash economy - in other words, pay-as-you-go. So there is a strong case for SOA here.

Corporate / Industry Restructuring

In good times there were lots of leveraged buy-outs - in other words, mergers and acquisitions whose justification was often more financial juggling than genuine synergy. In bad times there is no leverage, so the emphasis has shifted towards mergers only where this makes operational sense, and a renewed interest in demerger and spin-off.

SOA has a role here - not just in unbundling and in reintegrating the business - but also in finding new ways to connect the organization with its ecosystem, through service-based collaboration.

Overall, the challenge for SOA is to communicate its relevance to business by addressing real business concerns. I'm not saying IT is history, but that's not where business people are going to be investing their attention or their spare cash right now.

Public Sector SOA

The UK Government has identified four primary opportunities for using SOA in eGovernment:

• Syndication
• Rule Engine
• Joining up internal architecture
• Hand-shaking between agencies

For each of these opportunities, I shall quote a brief description from the GovTalk website, and then add some commmentary of my own.

Syndication

"This is where the services of a single Agency are to be aggregated with that of others and delivered by a third-party. This approach is supported by the introduction of common vocabularies and category lists such as the Integrated Public Sector Vocabulary (IPSV). A potential example would be DirectGov."

This is essentially a call for public-private mashups - in other words, joined-up services. There are some interesting opportunities for voluntary agencies and community groups to create customized "added value" services for particular target groups. This kind of thing can help to extend the reach of government services into otherwise disadvantaged groups, and thereby supports an "inclusivity" agenda.

This can also support an agenda of autonomy and decentralization, including alternative notions of identity (e.g. Identity 2.o).

Rules Engine

"Where a number of Agencies are dependant upon the rules set by another agency, and where those rules are complex and likely to change. A Web Services ‘call’ can be embedded into an application to perform calculations and return results into local data."

Among other things, this supports an agenda of "joined-up policy making", because it helps with the coordination, monitoring and maintenance of a broad range of policies across a broad portfolio of government systems and services. Ideally, government should be working towards closed-loop policy management, in which (i) policies can be directly associated with the sum of their outcomes, using service-oriented business intelligence and analytics, and (ii) policies can be adjusted in a coordinated manner to improve outcomes.

Joining Up Internal Architecture

"Where an Agency operates enterprise technologies, such as Workflow, Records Management, Middleware, Content Management. This approach avoids embedding API(s) from one component into another. The potential to create Web Services wrappers around proprietary technologies leads to the ‘swapability’ promoted by the e-GIF."

In other words, joined-up infrastructure. At the infrastructure level government requirements are pretty similar to those of any other large organization, except that governments often put greater emphasis on open standards, multi-vendor support and interoperability.

Handshaking with other Agencies

"Where an Agency wishes to interact with another Agency (G2G). This may be in terms of: Creating Workflow Instances, Making Appointments, Shared CRM facilities. Access to Data."

Finally we come to joined up business processes - orchestration and workflow, choreography and collaboration. This is perhaps the most obvious type of joined-up government, but not (as we have seen above) the only type.

So who does the joined-up thinking? Apparently, the joining-up initiative isn't imposed by any centralized planning body, but merely stems from "an agency wishing to interact with another agency". (So no arm-twisting from the Prime Minister then?)

Final remarks

Joined-up government is not just about joined-up processes - it also includes joined-up services, joined-up policy and joined-up platforms. There are some interesting initiatives underway in the UK government, and I look forward to seeing some practical results soon.

Sources

UK GovTalk e-GIF FAQ

[update] For a description of current initiatives in Canada, see John Gøtze: Aligning the Ducks.

Teenager's SOA

Following my previous post on Grandpa's SOA, JJ responded with another post on SOA misconceptions. I think we are broadly in agreement - SOA may have some traces in the past, but industrial-strength SOA was not possible thirty years ago.

JJ also criticizes the notion that services are like LegoTM. This analogy has been overused since the early days of component-based software engineering, and it has just enough plausibility to survive as a vague approximation, but as JJ points out it leads (as analogies often do) to gross simplifications and misconceptions.

Similar to the belief that smart kids can build enterprise solutions using Ajax and Google Maps. Again, there may be a few exceptional examples of this, but it is not a sufficiently sound basis for industrial-strength SOA.

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.

World Cup Arbitrage

According to the BBC [June 8th, 2006], UK bookmakers are heavily exposed to the risk of England's winning the world cup. I find this hard to believe.

Not surprisingly, there are national distortions in betting. In the UK, England is the second favourite after Brazil. Someone on the radio said you can get much better odds on England if you bet in Germany. Can this really be true?

If UK punters are willing to bet on England at only 6/1, and bookmakers in other countries are willing to offer much longer odds, then there is an opportunity to make big money trading between these two positions. This is called arbitrage.

So who is going to cash in?

1. British punters pretending to be domiciled elsewhere, in order to place bets elsewhere.
2. British punters collaborating with German punters (perhaps via Web 2.0 social networking)
3. Some clever programmers creating a Web 2.0-style betting mashup.
4. The bookmakers trading between themselves.

Much as I'd love to see private individuals profiting from this situation, my money is on the last of these possibilities.

[Update] Werner Vogels reports what are the odds available in Las Vegas. Comparison available at OddsChecker.


Technorati Tags: arbitrage gambling FIFA SOA service-oriented

Lightweight Enterprise

One of the interesting divisions of opinion at the SPARK workshop (and surfacing afterwards in the blogs of some of the participants) was about something we might call the weight of the enterprise.

Dare Obasanjo asserts My Website is Bigger Than Your Enterprise. And Jeff Schneider retorts My Enterprise Makes Your Silly Product Look Like A Grain of Sand. So who is right?

The basic issue here seems to be the relative amounts of complex engineering required to produce enterprise-grade software versus web-grade software. Dare (and some other participants at the SPARK workshop, including the guys from mySpace) are producing web software with staggering user volumes - much greater than most enterprises have to deal with.

Dare is scornful of enterprise architects, who (he says) "tend to seek complex solutions to relatively simple problems". He and David Heinemeier Hansson are particularly rude about James McGovern.

But as Jeff points out, "most people who have never seen a large enterprise architecture have no concept of what it is". CIOs and enterprise architects generally regard enterprise software (their own realm) as much more challenging than web software, involving much higher levels of complexity, and much stricter "non-functional" requirements (security, robustness, and so on). Are they right, or is this just narrow self-interest?

Size, complexity, weight - these are basic architectural concepts. Part of the difficulty with this debate is that we simply don't have an agreed language for discussing architecture properly. In my opinon, IT education is very deficient in this area. (See Footnote 1.)

Enterprise Mashup

One way of thinking about enterprise mashups is that they provide a way of achieving enterprise-grade systems without enterprise-heavy engineering. Let me give an example of something I regard as a business mashup. My example doesn't involve Ruby, it doesn't involve web services, and many people might say it doesn't even count as SOA. But it has always been my favourite example of the "plug-and-play" business that I describe in my book on the Component-Based Business.

Tesco Personal Finance (TPF) is an example of what I would now regard as a business mashup. It combines (mashes together) banking services (provided by the Royal Bank of Scotland) with retail services (provided by Tesco).

From Tesco's perspective, this mashup provides an extremely lightweight way of entering the banking business. In the old days, if you wanted to open a bank, you had to collect a large amount of gold, which you had to deposit with the banking regulators to satisfy them of your financial stability. Then you had to open a number of branches, and employ a small army of clerks and managers. This represented a considerable investment and risk - which meant that the existing banks could earn high profits behind high entry barriers.

In contrast, TPF represented for Tesco a low-cost, low-risk way of entering the banking industry. Simply plug in some external banking services (which already satisfy all the necessary banking regulations), and a humble retailer can become a bank overnight.

SOA

Although the Tesco Personal Finance initiative predated the SOA and Web 2.0 technologies we have today, we can now interpret it as a precursor or harbinger of these technologies - almost a non-technical proof-of-concept. (See Footnote 2.)

SOA enables the lightweight enterprise. It does this not through services but through architecture. (That, in my view, was the primary justification of SPARK.)

The challenge of architecture is to deconflict the enterprise software space - to create a genuine separation of concerns. This is easier said than done, and it requires some complex architectural thinking. One of the products of this thinking may be platforms on which developers may use small-scale and simple development techniques to produce large-scale and complex solutions.

See my recent posts on the Business Stack (SPARK Workshop 2) and Enterprise Mashups and Situated Software.

---

Footnote 1 - I have always been critical of university IT courses that teach students to write small programs, and fail to teach them the differences between small stand-alone programs and large interconnected suites of programs. If you go to architecture school, you may never build anything larger than a garden shed with your own hands. But you will have looked at skyscrapers and understood the relevant design and construction principles. You won't qualify as an architect without understanding the scale differences between garden sheds and skyscrapers. But in IT there is no such educational requirement. Vast numbers of people get university degrees in IT-related subjects, and even fancy job titles including the word "architect", without having a clue about effects of scale on software.

Footnote 2 - Sometimes technology seems to make new things possible. But we often find that these things were possible all along, they were just too difficult or expensive or risky. In the 1950s, Stockhausen was producing music that predated the modern synthesizer - and it took him months to produce music that later composers would produce with a few quick knob-twiddles. Some might argue that Stockhausen's achievement was all the greater because of his lack of tools. Similarly, many Renaissance painters might have been able to produce their pictures more efficiently if they had had digital cameras. But perhaps their paintings (and their artistic innovations) were all the greater for being done without modern technology. See my post on Art and the Enterprise.

---

News Update

Am currently in Amsterdam to teach a class on Business Modelling for SOA. (Classes coming up in Washington DC and London - see CBDI website.) I am also working on a Business Strategy for SOA class, which will run in London on March 22nd.

Later this month, I shall be in Las Vegas at the Microsoft Architecture summit (SPARK). I think I am supposed to write a position statement, so I shall post that here.

My second article with Philip Boxer has been published in the Microsoft Architecture Journal., and we have some further discussion on the Asymmetric Design blog. Philip has just produced an interesting visualization of the interoperability landscapes of Web 2.0 mashups, which I think will generate a lot of interest.

By the way, if you subscribe to the Feedburner feed for this blog, http://feeds.feedburner.com/soapbox, you will get notice of my writings for the CBDI Journal and elsewhere, spliced in with the normal blog postings. This can also be delivered into your email inbox via Feedblitz. (See Feedblitz box in the blog margin.) I hope that subscribers find this useful.

Technorati Tags: SOA service-oriented