Archive for February, 2017

Thriving On Chaos Of SMAC Architecture

Friday, February 24th, 2017

If you follow this blog, you know that I mostly write about fintech, marketing, product management and customer experience. IT architecture is a new topic. I was prompted to write about it after witnessing a series of chaotic happenings with modern SMAC architecture during the last few months.

For the uninitiated, SMAC stands for Social-Mobile-Analytics-Cloud. SMAC applications are typically built using cloud hosting, app stores, web services and APIs.

This is how I encounter the building blocks of SMAC in my everyday life:

Cloud Hosting: My company’s website, including this blog that you’re reading, are hosted by HostGator, a leading hosting services provider.

App Stores: GTM360’s mobile apps are published on Google Play Store.

Web Service: Every time I publish a new blog post, a web service called Twitter Feed automatically tweets a link of the post to my Twitter feed along with the first 100 characters. Every time somebody likes, retweets or replies to my tweets, another web service called IFTTT adds them to a Twitter List called skr-engagers.

Third Party APIs: This blog is published using WordPress. The world’s leading blogging platform uses an array of APIs to perform various functions like validating the blog to third party plugins like Disqus (comments) and Akismet (spam protection).

SMAC architecture helps non-technical people do stuff they otherwise can’t dream about. For instance:

SMAC architecture also helps technical people cut down time-to-market of new applications by letting them deliver new functionality readily using preexisting web services (and open source code) instead of developing them from scratch. As Fortune says:

Fewer companies are releasing bloated, monolithic apps that take months or even years to revise. Instead, they are breaking them up into individual components or “microservices” that handle specific processes. For example, a bank might create one authentication system for creating accounts or for verifying a person’s identity that is used across all of its systems and apps. In theory, this lets organizations update software more quickly.

With that out of the way, let me describe the kind of chaos I witnessed with SMAC systems in the recent past.

#1. Failure of ‘Set and Forget’

Most SMAC services are designed to work on the “set and forget” principle. Most of the time, they deliver on that promise.

The chaos begins when they break that promise.

Like Twitter Feed did.  I recently noticed that the tweets posted by Twitter Feed didn’t contain the link to the post (although they did display the 100-character text). Because the web service had been working on “set and forget” mode ever since I installed it over five years ago, I’d totally forgotten how to configure it! I’d been wondering how to fix this problem. But, lo and behold, while I was trying to take a screengrab of one of the problematic tweets to use in this post, I noticed that the last three tweets do have a link!

Problem solved. Without me doing anything about it.

Unfortunately, not all problems get solved automatically.

#2. Premature Death

So many web services are developed without a business model. Some of them acquire huge distribution by word-of-mouth. Then, they suddenly die. Like the aforementioned Twitter Feed and IFTTT recipe. Leaving thousands of applications built on top of them in the lurch. Now, I need to look for another auto-tweeting service for my blog and find some other way to update ‘skr-engagers’ whenever someone likes, retweets or replies to my tweets.

#3. Frequent UI Changes

We’ve all been through perplexing moments when familiar software suddenly looks strange, with screens, links and buttons vanishing into thin air. This happened with Windows Vista a few years ago. It happens with virtually every SAAS software nowadays. It’s easy to spout philosophical statements like “change is the only constant” and all that, but the chaos caused by frequent changes to user interfaces shouldn’t be underestimated, especially if the software is used by large teams and / or time-poor executives.

#4. Too Many Moving Parts

SMAC applications tend to use open source code, third-party APIs, and so on. This has introduced a lot of moving parts in software. As a result, companies are dependent on app store passwords, API keys and more. Since wide circulation of this critical information leaves the system open to attack from multiple threat vectors, the security best practice is to restrict its circulation. But the people who do know this information needn’t be permanent employees in today’s world of distributed development teams – they could be contractors or supplier employees as well. As a result, it has become quite hard and time-consuming to recover from a defect or attack, whether they’re caused by a poorly trained employee or disgruntled team member. As the aforementioned Fortune article notes:

The downside is that a company’s chief information officer might not have a centralized view into all of these different projects. If an app falls down on the job, it’s tough to pinpoint the cause.

I can testify to this from first hand experience:

An ecommerce customer’s employee consciously deleted a few duplicate records in the database without knowing that this piece of housekeeping would cripple the open source search function used by the software. As a result, the website came crashing down. Had the system been developed and hosted internally, it would have only taken a few minutes to troubleshoot the problem and restore the website. However, the website had used many building blocks of SMAC architecture and the only person who knew all the passwords and keys was no longer working for the company. Luckily, the present development team was able to locate him and secure his help to fix the problem. All’s well that ends well but it took four days to resolve a five minute issue. Needless to say, the company suffered a significant loss of revenues and severe damage to its reputation as a result of this outage.

The last, and perhaps the most serious, source of chaos is caused because SMAC hype has overtaken reality by leaps and bounds.

#5. Excessive Hype

Hype is no stranger to the IT industry. However, in the case of SMAC architecture, it’s gone a bit too far and is causing a lot of operational chaos.

I got a glimpse of this when I recently visited a healthcare center in my neighborhood. I was asked to fill a registration form. I told the receptionist that I’d already registered with them during my previous visit. He told me that they’d lost all customer data when their server crashed two months before without any backups. But he assured me that they won’t have any problem from now onwards because they’d “shifted everything the cloud”. Obviously, he assumed that the cloud service provider would take care of backups and make the data available 24/7/364.

Big mistake.

I hope the CIO of this company knows better. But I strongly doubt it. Because it’s not just this random healthcare center.

Australian ATM networks recently went down because their cloud service provider suffered an outage. According to Finextra, there was no backup. Apparently, the leading banks to whom the ATM network belonged thought it was the responsibility of the cloud service provider to take the backup. And the cloud service provider countered by saying the banks’ hosting plan didn’t include a backup.

When such things happen even to seasoned technology users like banks, you know that the “cloud gets rid of all infrastructure worries” hype has gone a bit too far.


Just to be clear, it’s not my intention to discourage enterprises from implementing new SMAC systems or migrating their legacy systems to SMAC architectures. I’ve highlighted the topic of chaos only to underscore the need to plan for measures to manage it while embarking upon SMAC implementations and migrations.

And I’m not alone. Yvette Cameron, Gartner Research Director, offers similar advice on the right!

Innovative Fintechs Don’t Need No Open Banking Regulation

Friday, February 17th, 2017

Pink Floyd fans won’t need any explanation for this post’s title*. 

The recent buzz around Artificial Intelligence and Machine Learning has spawned the next generation of Personal Finance Management applications. While the forerunners in the cateogory like Mint (now part of Intuit, Inc.) are still available on the web, most of the new players are mobile-only. Going by monickers such as Mobile Money Management App and Money Management Bot – herewith termed MoMMA for the sake of convenience – they all require access to their users’ bank account information.

This has become a bone of contention of late with banks reminding their customers that their TOS forbid them from handing over their online banking credentials to third parties (I don’t know what took all but a handful of banks so long to assert an old clause in their terms of service – actually, I think I know, but that’s a blog post for another day).

As a result, MoMMAs have been looking to “Open Banking” regulations like PSD2 to give them a leg up. For the uninitiated, PSD2 mandates banks to allow fintechs to access banking data of customers.

But banks are not taking this lying down. According to Financial Times, big banks are lobbying to reduce access to customer data envisaged by PSD2, which would substantially dilute the original provisions of “open banking”. According to Sebastian Siemiatkowski, chief executive of Swedish online payments company Klarna, quoted by FT, “If it (PSD2) goes ahead as currently written it will not create open banking as the law originally envisaged.”

Fearing an existential crisis, fintechs are fighting back.

They shouldn’t.

In fact, they should stay away from regulation. As I’d highlighted in Fintechs Need Marketers And Lobbyists – Not Lawyers and Fintechs Need Guts More Than Lawyers!, many successful startups have flourished by leveraging “regulatory gaps” rather than regulation.

Instead, MoMMAs should become truly innovative and enhance their value proposition.

Intuitively, everyone knows that “earn more, spend less” is all the money management mantra they need. To get people to use a MoMMA to practice this principle is a tough sell, made even tougher by what the current crop of MoMMAs currently do:

  1. Transform the customer banking experience by enabling consumers to compare and save on current accounts, … look for mortgages more easily and access better terms for loans (Source: Finextra article titled Consumers unaware of Open Banking – Equifax)
  2. Answer questions like “How much have I spent on Uber this month?” and “Can I afford to go for dinner?” (Source: Finextra article titled Personal Finance bot Cleo)
  3. Protect customers from bankruptcy by telling them not to buy that $4.50 coffee. Okay, I’m joking about the bankruptcy but the part about the coffee is true.

IMHO, these existing features are quite lame because:

  • MoneySuperMarket, Which? etc. have been letting us do comparison shopping for current accounts and mortgages for ages without needing any access to our banking info.
  • What can we do about the money we’ve already spent on Uber?
  • If we can’t go for dinner, do we starve?
  • We don’t need a fancy MoMMA to tell us that a coffee costing $4.50 is a big rip-off that’s worth avoiding even if we’ll stay within our budget by buying it.

Okay then, how can a MoMMA use innovation to offer true value to its users?

A few ways of doing that would be for a MoMMA to:

  1. Give truly useful money management tips e.g. Earn $$$ more by sweeping X amount from a checking account to a savings product.
  2. Indemnify customers from losses caused by data breach arising out of third party access to customers’ banking info.
  3. Access only the info customers permit them to access – nothing more, nothing less. Screen-scraping via online banking password, which is currently the most widely used technology, fails this test because, once they’ve given away their online banking passwords to these apps, customers have very little control over what info the app can and cannot access.
  4. Make data sharing activity frictionless. OFX is one prevailing technology that lets the user download only the info they explicitly want to supply to the money management app or bot. However, most apps and bots require frequent updates of transaction info, which means users have to log in to their online banking portals frequently to download the latest version of their transactions. This can be painful.

#1 is related to consumer behavior and product management. #2 has a legal angle.  They’re both within the control of the fintech.

#3 and #4 are related to technology. As I’d highlighted in P2FM Services Walk The Tightrope Between Convenience and Security and How Many More PFMs Do We Need?, data access modalities have posed major challenges to the viability of the first generation of PFMs 8-10 years ago. But, all that’s history now. OFX-API seems to have cracked the Holy Grail of data access, going by the gung-ho views expressed by executives of JPMorgan Chase and Intuit when they recently announced their data partnership agreement based on this technology (Source: American Banker).

As a result, fintechs are closer than ever before to being able to leverage their innovativeness to develop a compelling value proposition for PFMs. If they achieve that, they can kick off their ‘open banking’, PSD2 and other regulatory crutches.

In return for the ability to make frictionless payments, tens of millions of otherwise security-conscious customers make payments with India’s largest mobile wallet app PayTM without entering a single password or PIN.

If MoMMAs give them a similarly compelling value proposition, people won’t care about sharing their online banking credentials with them – with or without PSD2.

I’m not alone in holding this view. As Steve Ellis of Metia says on Finextra, “…the question on sharing personal data is the wrong way round. No-one agrees to share personal data without being offered some kind of fair value exchange for it. Show the consumer a compelling value proposition and they will do it in the blink of an eye.”

Let me conclude by paraphrasing another Pink Floyd line:

Hey! Fintechs! Leave Them PSD2 Regs Alone

*: As for the others… well, it’s never too late to become Pink Floyd fans!

Figuring Out What Will Sell Where

Friday, February 10th, 2017

A Quoran recently asked me where he could sell his email list in India.

Normally, my Quora answers are quite concise. And, after seeing the following reply by Quora’s Founder Adam D. Angelo, I stopped worrying if I was too terse:

But the said question about email list gave me a chance to throw light on the differences in buying behaviors in different countries. Therefore, I wrote a rather long answer and, because these differences can shape the GTM strategies of B2B technology providers, I thought of repurposing it into this blog post.

Where can I sell an email list in India?

Short answer: Nowhere.

Long answer:

I’m assuming your list is targeted at a B2B company (e.g. CRM product vendor or ERP implementation service provider) rather than at a B2C company (say, retailer).

With that preamble in place, let me explain my answer with a personal example.

My company offers an email list that can be used for business development by SAP ISVs and Services Providers all over the world. This product has been selling briskly in USA ever since we launched it seven years ago. During the same period, we’ve received countless leads for this product from companies India. However, not a single one of them has converted into a deal so far.

Seven years is a long enough period. Why is there such a drastic difference in sales of the same product that’s prima facie valuable for both markets?

I tend to believe it’s because there’s a fundamental difference in the way technology companies do business in these two markets.

When they first look at this list, both American and Indian companies believe they can compile it by themselves. They’re right – we say so ourselves on our website.

Companies planning to launch campaigns to existing SAP sites can always build a lead list internally. However, there’s no single – free or paid – source of contact information regarding SAP installed base. As a result, they need to spend a lot of time and money to gather company names from one source, identify decision makers from another source and buy contact information from a third source. By the time their lead list is ready, their sales team’s enthusiasm might start waning, their window of opportunity might pass, or both.

However, from here, their approach diverges. At the risk of taking a major leap of faith, I think the former is driven primarily by revenue whereas the latter is driven primarily by cost.

Revenue-driven approach: Wow, now that I can buy it, I don’t need to spend the next 2-3 months to compile the list inhouse. By buying this list, I can launch an outreach campaign immediately and win a few deals within a couple of months. Therefore, I can earn revenues even before I’d finish compiling the list internally. Therefore, I’ll buy this list. Ergo, we bagged tens of deals for SAP Mailing List.

Cost-driven approach: Why should I incur a cost when I can put my people on the job to compile it inhouse? Therefore, I won’t buy this list. This approach ignores the opportunity cost of not earning revenues earlier caused by the delayed launch of the outreach campaign. Ergo, we bagged zero deals for SAP Mailing List.

Nothing right, nothing wrong, each to his own way and all that but that’s why our email list sells in USA and doesn’t sell in India.

I tend to believe that this is a deep-rooted reason that will influence the purchase behavior of all technology products and services in every market. IT product and services vendors might want to use it to figure out what will sell where while navigating the uncharted waters of formulating their market entry plans. While Confucius won’t think highly of them, it will help them allocate their marketing budgets in such a way that they will get the maximum bang for their buck.

Like we did – we stopped advertising for SAP Mailing List in India and increased the ad spend in USA.

Why Social Media Has Become My First Port Of Call For Customer Service

Friday, February 3rd, 2017

On a recent tweetchat about social media customer service, many tweeples felt that the channel was only suitable for escalation.

Not me.

I admit that it was for escalation that I first used social media a few years ago – it was to get my malfunctioning printer fixed.

But nowadays, social media has become my first port of call. That’s because I find it more frictionless and faster than telephone, website, mobile and the other traditional customer service channels:

  • Telephone means having to listen to hold music and navigate through convoluted phone trees. This is painful and time-consuming.
  • Website means trying – mostly in vain – to fit my problem to the list of options available on the site.
  • On Twitter, I just need to find the brand’s handle and fire away my query, request or complaint.
  • Maybe because no one likes their dirty laundry to be aired in public, brands respond to social media complaints quite fast. My problem is often solved on Twitter by the time I navigate a phone tree or select an option from a dropdown box to log a ticket via phone / website.

You can find more details in Customers Of The World Unite, You Have Nothing To Lose But The Call Center Hold Music.

I recently discovered another facet of social media customer service that has made me even more determined to choose it as my go to channel than before. This happened during a train journey from Pune to Renigunta / Tirupati last year. For the uninitiated, Pune is a city in West India and Tirupati is a temple town in South India.

Soon after boarding the train, I found out that there was no water in the toilet. Passengers inside the coach were complaining to the Train Ticket Examiner (TTE). For the uninitiated, the TTE is the seniormost-ranking railway official on an Indian train, with powers to check tickets, levy fines and accommodate passengers without reservation. Flaunting his authority, the TTE pushed back with the excuse that he’d requested for filling water in the toilet at the previous station (Surat) but it didn’t happen. He tried to shoo off the passengers saying he couldn’t do anything more. In turn, the few bold ones among the passengers pointed out that it was his responsibility to get things done for passengers. To which the TTE shot back saying they had no right to tell him how to do his job.

I realized that this was going nowhere and returned to my seat.

I vaguely recalled reading somewhere that Indian Railways provided support on Twitter. I Googled for the handle on my smartphone – luckily the train was passing through a place with good network coverage – and sent out the following tweet:

A few minutes I got a reply:

An hour or so later, the TTE came to me to explain the action he’d taken and assured me that watering would definitely happen at next stop (Solapur). (It did).

End of complaint.

But it was the start of my realization that there was another angle to social media customer service that hadn’t caught my attention before.

I had my ephiphany moment when I read about the details of Indian Railways’ Twitter customer support on Economic Times. According to this article, the @RailMinIndia Twitter account is monitored at a central war room at the Rail Bhawan in New Delhi. As soon as it receives a tweet from a passenger, the team goes into action. From the PNR number, it identifies the train, finds out where it is, maps its location to the railway division responsible for managing the train on that stretch and forwards the tweet to the Divisional Railway Manager (DRM) of that division. In parallel, someone from the team calls up the TTE and the DRM to follow through on the tweet and tweets an acknowledgment back to the complaining passenger.

In my case, this happened in four minutes. This is amazing, given the size of Indian Railways’ network and the federated manner in which the organization is run.

According to Wikipedia, Indian Railways runs 12617 passenger trains and 7421 freight trains daily across one of the world’s largest railway networks comprising 115000 km of track and 7112 stations. It’s administratively divided into 16 Zones, which are subdivided into 70 Divisions. Each Division is headed by a Divisional Railway Manager (DRM) (Source: Wikipedia). During its journey, a train traverses one or more zones and divisions. Depending upon where exactly it is at a given point in time, it comes under the administrative control of the Divisional Headquarters that has jurisdiction over the given stretch of track. For example, during its 960 kms journey, my train went through two zones (Central Railway and South Central Railway) and three divisions (Pune, Solapur and Guntakal).

But I digress.

After reading this article, it was clear that my tweet to @RailMinIndia had set off a sequence of events in the background that included a nudge to the TTE from his superbosses at Rail Bhawan.

Not surprisingly, the same guy who was flexing his muscles with the other passengers took a very conciliatory approach with me.

It was no longer the case of a hapless passenger trying to get heard by a supercillious government authority.

I realized from this experience that social media empowers customers to upend traditional power equations and change the basic paradigm of customer service. This is easily visible during social media interactions with public sector companies like my specific instance with Indian Railways. But, going by my first ever experience of using the channel to get my printer repaired a few years ago, social media empowers customers in a similar manner even with private sector brands, just that it does its job behind the scene.

On a related note, any communication medium that becomes popular tends to get abused. Social media is no exception. However, unlike other channels, social media is open and this basic trait can be used to control its frivolous use.

Whether or not companies leverage social media to publicly name and shame offenders, the channel does have the built-in capability to curb abuse.