How to change someone’s mind?

Based on my personal experiences, primarily in sales roles, I have synthesized four techniques that will enable you to persuade other person to change their mind.

Conduct an interview

People often assert a position and then dig in.   Asking open-ended questions with the notion of understanding the underlying sentiments behind a position will often lead to mutually agreeable situation.  For instance, you and your spouse disagree on vacation plans:  One wants to go camping and other prefers a nicer hotel.   Asking questions as, what’s important about camping? What do you love about it? Will you rather have separate camping trip with friends?  This might lead to a good compromise solution with vacation split between camping and hotels

Re-frame the debate

Find a way to recast the subject at hand so that the person is prompted to think about things differently.  Most people sometimes get lost in proverbial trees and loose the vision of the forest.   Down at the tree-level, the dominant psyche is driven by fear or scarcity.   Re-framing and painting a holistic vision, often leads to new ways of the thinking about a problem that will likely make a long-term impact.

Point holes in your own argument

If you are up-front about drawbacks in your argument, it sends a signal to other person that you understand different facets and complexity of the argument and that you are honest.  This helps you gain trust and credibility, which is crucial in having other person be patient and listen to your argument with all sincerity.

Make it their idea

The goal is to make the other person believe that it was his idea. It’s much easier said than done. The process involves planting clues, so that the other person can reach the conclusion you want them to reach (your idea) without you explicitly laying it out to them and hence, make them believe that it was their idea.

The key is to be patient, because if you rush through your “clues” it will be obvious. If you take it slow, the idea will form naturally in their mind all by itself.  It’s akin to surfing, where you patiently wait for the wave, and once you are into the wave, keep on paddling and the wave will automatically carry you.  Or, as in Soccer, patiently building an attack by keeping the ball rolling around the defense and wait for that break.

A Brief History of SAP NetWeaver

With Sybase integration into SAP, I have met several of my colleagues who are not aware of the history behind  Netweaver.   And recently, googling led me to chapter in George Anderson’s “Teach Yourself SAP in 24 hours” in which he articulates the history of Netweaver in succint and lucid manner.  I have reproduced the content below (without George’s permission, hope he doesn’t mind) with the intent that this knowledge might interest the broader “sapanese” community.

A Brief History of SAP NetWeaver

Prior to the introduction of SAP NetWeaver in 2004, a large part of the SAP technology stack was synonymous with the SAP computing platform. We often referred to this stack simply as the SAP Basis layer. And despite seeming complex at the time, the stack was indeed simple by today’s standards. SAP supported a handful of operating systems and databases, all systems were built on Advanced Business Application Programming (ABAP), and the systems could be extended a bit (to include tax bolt-ons, faxing systems, printing solutions, and the occasional other system or two) but were generally part of a somewhat isolated SAP-only landscape.

Today, we still use the term Basis, and it still conjures up images of a technology stack that needs to be administered, maintained, and monitored. But things are much different. Sure, system administration tasks such as performance monitoring, tuning, and security need to be performed. We need to monitor and support internal and external systems, make sure our email systems are connected, and so on. And we still need to manage the development repository of SAP’s ABAP programming language and database objects. However, the relative simplicity of the client/server era that gave birth to SAP R/3 is long gone, and the complexities of the post-client/server era are all around us. Basis has grown up and raised a family, but none of the offspring left for college or struck out on their own. And we’re faced with managing and maintaining the whole lot. A quick trip back to the crazy days of the late 1990s is in order.

Back to the Future

With the Internet boom of the 1990s, the demand for applications to adapt to the Web was vital, and SAP was particularly keen to get a jump in this area. As a result, SAP introduced its Web Application Server (WebAS). WebAS essentially extended the Basis technology stack to the Web by integrating SAP’s Internet Transaction Server (ITS), formerly a separate product, into SAP’s core technology stack. SAP then introduced SAP Java to provide a platform-independent model for web development, followed by connectivity and support for Microsoft .NET (consistent with the company’s vision to adopt open standards while providing customers with a choice of development options).

WebAS was SAP’s initial move to offer a standalone technology product that could be installed independently from the SAP business modules as either a traditional ABAP technology stack, as a Java technology stack, or as both. The goal was to separate the technical layer from the business layer so that companies could perform more modular upgrades rather than being forced to upgrade the technical and application stacks at the same time—a process that consumed a lot of time (including hard-to-arrange business application downtime) and money. This more componentized model paved the way for the release of SAP’s next wave of innovation: NetWeaver.

Introducing NetWeaver

In 2004, SAP introduced SAP NetWeaver and broadened the technology stack concept into a complete integration platform. Finally conceding to the idea that large-scale businesses ran more than just SAP, the idea was to simplify how SAP connected with other business systems and applications. The earliest NetWeaver foundation included WebAS ABAP and Java components. SAP’s mature Business Warehouse and Enterprise Portal products were tucked into NetWeaver, as well; the former enabled underlying reporting and basic business intelligence, whereas the latter extended the SAP user interface in a new way to the Web. A hub-and-spoke integration technology called Exchange Infrastructure (the precursor to today’s SAP NetWeaver Process Integration) allowed SAP and non-SAP systems to connect more easily. And SAP worked to develop and share a methodology around people, information, and processes to bring these first NetWeaver components together.

As each Business Suite component was updated, SAP took the opportunity to NetWeaver-enable them, In this way, SAP R/3 Enterprise eventually morphed into SAP ERP Central Component (ECC). Applications like SAP SRM soon followed, while brand new components like SAP Product Lifestyle Management (PLM) benefited developmentally from a clean slate. Other SAP NetWeaver products followed and through valuable additions to SAP’s application portfolio, quickly complicated what was once a fairly crisp vision.

The SAP NetWeaver Umbrella: Six Areas

SAP NetWeaver provides the foundation for Business Suite. But many specific products fall under the label of NetWeaver, too. The NetWeaver umbrella has become so crowded in the past few years that SAP finally organized this portfolio of applications, utilities, and tools around six areas (sometimes called domains or themes):

  • Foundation management
  • Middleware
  • Information management
  • Team productivity
  • Composition
  • Business process management

SAP Customers

SAP Customers 

fly more than 1.1 billion of the world’s passengers

produce more than 9 million tons of the world’s cheese

produce more than 65% of the world’s televisions

produce more than 50% of the world’s brand-name jeans

reach more than 5.2 billion mobile subscribers across the globe

can reach more than 74% of the world’s population via text messaging

produce more than 52% of the world’s movies

represent 80% of the companies on the Dow Jones Sustainability Index

courier more than 50% of the world’s packages

manufacture more than 77,000 automobiles per day

produce more than 70% of the world’s chocolate

Re-visting “Theory of Comparative Advantage”

Way back in 2010, I had written a brief post around Theory of Comparative Advantage.  

Recent, NYT article – “In Wooing of Nissan, a Job Lesson for the Tech Industry?” –  uses Nissan and Apple case-studies to peel the layers on this issues.  On one hand, we have the theortical economical model and on the other, we have the messy realities of politics and emotions like patriotism.

It’s a fascinating discussion.



Privacy, a Wicked Problem?

Recently, over dinner, I was explaining the benefits of Geo-fencing to a family friend Katie, who is a mother to two young kids.

Geo-fence, for the uninitiated, is a virtual boundary surrounding a geographic region. When a person with a mobile phone crosses a geo-fence boundary, a notification is automatically issued to that mobile phone.  And that notification can very well be a relevant targeted locational context-sensitive ad or a promotional coupon.  Note, the consumer needs to opt-in and install an app on the mobile phone for this scenario to work.

I was explaining Katie that if she is willing to opt-in, the next-time she is shopping at Target for her kids, she will get a relevant ad/coupon for items on her shopping list.  All she has to do is to agree that her location will be tracked, if and only if, she is within the geo-fence.  Outside, the geo-fence, she will not be tracked.

In my mind, it was good trade-off between Katie sacrificing some of her personal data including location (aka sensitive personal data or SPD) and getting goods at discounted price.  However, Katie had strong reservations about being tracked.  What if they don’t stop tracking outside the geo-fence? What if some criminal elements hack into the system and track her all the time engendering harm on her young family?  And she brought up examples of recent break-ins into yahoo email, identity theft, etc.

The same evening, after reaching home, I started reading Atul Gawande’s fascinating essay about health-care reform in US.   In this essay, Atul introduced me to the notion of “wicked problems”.   Paraphrasing Atul –

In 1973, two social scientists, Horst Rittel and Melvin Webber, defined a class of problems they called “wicked problems.”  Wicked problems are messy, ill-defined, more complex than we fully grasp, and open to multiple interpretations based on one’s point of view. They are problems such as poverty, obesity, where to put a new highway—or how to make sure that people have adequate health care.

They are the opposite of “tame problems,” which can be crisply defined, completely understood, and fixed through technical solutions. Tame problems are not necessarily simple—they include putting a man on the moon or devising a cure for diabetes. They are, however, solvable. Solutions to tame problems either work or they don’t.

Solutions to wicked problems, by contrast, are only better or worse. Trade-offs are unavoidable. Unanticipated complications and benefits are both common. And opportunities to learn by trial and error are limited. You can’t try a new highway over here and over there; you put it where you put it. But new issues will arise. Adjustments will be required. No solution to a wicked problem is ever permanent or wholly satisfying, which leaves every solution open to easy polemical attack

The question is – Do we believe that privacy issue is a wicked or a tame problem?

Irfan Khan, CTO of Sybase, in his excellent blog entry argues that –

I believe that consumers are very concerned about their SPD. But I’d argue they’re more concerned about it falling into unintended hands. That is, people who have good relationships with businesses are happy to share SPD with them because the services and goods they receive are improved in the process. But they want those companies to keep a tight lid on that information. They want bullet-proof security of their SPD. When security fails, that’s when their privacy concerns are heightened. If companies could protect their data 100 percent of the time, that is, if they never suffered a security breach, I’d wager privacy issues would all but disappear among the vast majority of consumers.

Or, in other words, technology comes to rescue and this becomes a solvable and a “tame” problem.

Given that a significant portion security breaches happen within inside an organization as opposed to outside, reaching the 100 percent goal seems like an elusive target.  Apart from protecting the data, there are other fundamental issues with how the company uses the data to make business decisions; for instance, if one where to share their private genetic data with your HMO (like Kaiser) with the goal to improve quality of care and the HMO determines that you are genetically pre-disposed to any chronic diseases (e.g., diabetes), would they increase your medical insurance premium? Perhaps, this might be regulated by the law.  What if this data is shared with your life insurance company? Will they drop your coverage or increase your premium?

In conclusion, user privacy (or SPD) issue is messy, ill-defined and more complex than we can fully grasp. Trade-offs are unavoidable, when it comes to solutions. Unanticipated complications and benefits are both common. No solution is ever permanent or wholly satisfying, which leaves every solution open to easy polemical attack.  Or, in other words, it’s a wicked problem.

Jevon’s Paradox and “Bigger” Data

In 1865, a twenty-nine-year old English economist named William Stanley Jevons published a book, “The Coal Question,” in which he made the argument that coal reserves were rapidly depleting, threatening Britain’s affluence. More importantly, he made the observation that increasing efficiency in coal usage will not to reverse this process and reduce consumption, but it will further increase the coal consumption.

Economist call this “Jevons Paradox” – the proposition that technological progress that increases the efficiency with which a resource is used tends to increase (rather than decrease) the rate of consumption of that resource.

I believe similar paradox applies to what we call “Big Data” technologies today.  Big Data tools like Hadoop, NoSQL, NewSQL and other next-generation Data Management technologies have been created to address the explosion of data and increase the economic efficiency of data management.   Economic efficiency boils down to ability to use commodity hardware with lower power consumption characteristics, storage compression and opportunity cost  of gaining insight faster (in real-time).

Once organizations become adept at handling terabytes and petabytes in economically efficient way, per Jevon’s paradox, there will be increased consumption of “Big Data” technologies and soon the need to handle Exabyte’s and Zettabytes.  Or, even Bigger Data.

Update:  Empirical evidence of this paradox in the graphic (below) sourced from Cloudyn


Several years ago, I had seen a movie called “Brazil“.  The most striking visual element of the movie for me was the use of ducts.  There were flexible ducts running everywhere.   And that got me thinking what if we have network of flexible ducts running across the entire city connecting centralized distribution centers with homes.   Imagine a scenario, you wake up in the morning and order a cup of cappuccino, using internet, from Starbucks.  The Barista at Starbucks will brew a fresh cup of your cappuccino enclose it in spill-proof capsule and then put it in one of the ducts with your home address encoded. Within few minutes, the capsule travels to your home, you open the duct and nice cup of cappuccino is waiting for here.   Similarly, you can order groceries,  cameras, clothes, etc..

I always  wondered whether it was possible to economically build such network of ducts as a distribution network for goods with direct reach to your home with latency of few minutes.  Well, as it turns out, I am not the only guy thinking about the same.   Franco Cotana, an engineering physicist at the University of Perugia, in Italy, has actually designed a system called “Pipenet” as a goods-distribution network.

The economist article – Put that in your pipe and poke it – provides more details on Pipenet.  I certainly look forward to Pipenet in my town.