Blogger: Richard Watson
The Economist published an article recently on a cognitive bias called The Endowment Effect. Put simply, this effect means that we place a higher value on something we own than we did before we acquired it. The article details many experiments that bear this out. We see students preferring to keep coffee mugs rather than exchange for chocolate which they would prefer in a straight choice. Chimpanzees endowed with peanut butter keep it in 20% more cases than when faced with a straight choice of peanut butter or orange juice. Similar effects are observed in financial portfolio management, despite the transaction costs for professional traders approaching zero.
This got me thinking about application portfolio management and how service-oriented architecture (SOA) can reduce the negative consequences of the Endowment effect.
What does the Endowment effect mean for IT?
Is creating and delivering invoices one of your organization’s core capabilities? Probably not, however creating and selling insurance policies or designing and manufacturing cars might be.
There are service providers that just create and deliver invoices. Let’s say you meet with Jim, the VP of business development of SpeedyBills. Jim encourages you and your Enterprise Architects to measure the cost of sending an invoice across each line of business. Let’s say you manage to calculate this – no mean feat in itself – as X cents. Jim assures you SpeedyBills can do it for X/4 cents. Oh, and you can send it whenever you like, not on a random day in the five days after the monthly batch. And you can change the formatting or content whenever you like, not when the developers decide to upgrade the templating package.
That sounds great, but you know what Jim, we’ll stick with what we’ve got, thanks. That’s the Endowment effect kicking in, corporate IT style. You probably have 3 systems for creating and delivering invoices that are each integrated in an arts and crafts way with 5 other systems. This complexity keeps the cost of change very high, as each minor change causes a costly domino effect. The changes required to expose enough data and process to use SpeedyBills are mind bending.
To be fair to most CIOs, they’re not choosing to hold onto these systems because they prefer their spaghetti to the SOA bento box. One endowment effect driver is transaction cost. Satisfying similar requirements with a different system will often require significant switching cost. How we got here is another day’s post, but poor architecture is at the root of this cost. Monolithic applications, point-to-point integration, myopic project scope and funding, the “I’m special” business unit attitude and constraints imposed by proprietary and legacy technologies all contribute to IT system complexity.
Resistance to change is a fundamental that underpins the endowment effect. Behavioral economist Pete Lunn refers to resistance to change and its relationship to familiarity:
"Of course there is something conservative about a bias towards what is familiar, because it also implies that we are instinctively biased against change. Results back this up. When opinion surveys ask people to state preferences between alternative spending plans (say for governments, local authorities companies, or individuals), if the accompanying description reveals which option is the current one, many more people choose it. This “status quo” bias is also found in experimental economic games, in which people are given scenarios and must select strategies to win or lose money. People are often slow to abandon their current strategy and switch to a more profitable one. Status quo bias is part of our common understanding, summarized by “better the devil you know”.
Pete Lunn. Basic Instincts: Human Nature and the New Economics. London: Marshall Cavendish, 2008.
How does SOA enable this?
IT portfolio management’s endowment effect is caused by financial and psychological fear of change. Adopting SOA helps in two ways: reducing the cost of change and moving the mindset of an organization from resisting change to expecting it.
SOA loose-coupling principles will connect systems in a manner whereby changes to dynamic systems remain as isolated as possible. Business processes composed from reusable, loosely-coupled, policy-driven services are more flexible than applications with arbitrary boundaries and integration. Flexibility will enable IT to substitute a different provider of a discrete business capability at predictable low cost. You can take advantage of SpeedyBills and other lower cost and flexible providers. For example, obtaining new sourcees of financial reference data or a healthcare provider that offers better choice of health plan benefits to your employees.
Change is the underlying driver for SOA. If system requirements don’t change, or the services are not reused, then the business case for applying service-oriented principles won’t stack up. Change is baked into the whole deal, and adopting SOA means accepting change as business-as-usual.
How to get there?
We can’t move from techie-spaghetti to lean-n-mean, warm-pluggable business capabilities overnight. But we can think big and take small steps. Getting to the SOA bento box requires a deep commitment to application portfolio management and business architecture as Mike Rollings has identified.
Funding for transformational initiatives can be hard to come by; I’ve blogged previously on the paradoxes inherent in securing funding for SOA. Nevertheless, businesses are always interested in funding medicine for their pain points. Delivering analgesic to the business pain, while working on the root cause is the way to go. The patient will start to listen to the get-well plan once you’ve cured the immediate pain, so focus on manageable, but visible projects and measure the outcomes.
Exercise for the reader
By the way, there’s no shortage of other cognitive biases to choose from in corporate IT departments – I leave it as an exercise for the reader to spot some more in the wild. For a start, look out for bandwagon effect (“if everyone’s doing REST this year, it must be a winner”), confirmation bias (“I’ve gathered the metrics that show my software development process is top class”) and post-purchase rationalization (“of course buying that ESB to kick start our SOA initiative was a sensible thing to do”).
