Classic case

A project ran to build a system for capturing customer details, soon after the delivery another project build the customer update system.

Now, this is just one of many ways of building technical debt, but really the culprit is the organisational thinking behind this phenomenon. What has happened?

The analysis

Ignorance is NOT a bliss – as it would turn out during the acceptance test, when customer details were captured, but they could not be modified or updated later. However, the project was coming to a close (it was already in acceptance test) and budget was running short as well. So what does one do to fix this situation? Run another project to build another system to update customer records.

Why not extend the current system on the next project, why build a new one? There could be many reasons for this. One possible reason stems from how IT projects are accounted for. New build becomes an asset (capital expense), but updates don’t (operational expense). However, this is not entirely correct. Updates that deliver new capability or functionality can become assets, but that’s too complicated to understand or to split project costs accordingly, so it is easier to launch new project for a new build and new asset.

So there you go, the organisation ended up with two systems instead of one; although it probably could have spared that single one too if the first project took the effort to look around the rest of the organisation for an existing solution.

Who cares?

Surely it is not such a big deal, it happens all the time.

Sarcasm aside, in fairness, it the big scheme to things projects are these are only a small drop. Even if the costs are doubled (two projects) and the duration has doubled (worst case) it won’t break the organisation, however this is where the spiralling starts pulled by two forces:

1. Projects running late – especially in IT – is almost the norm, so projects do not even bother with much upfront planning and preparation (called the pragmatic approach) and trying to keep scope to absolute minimum. These poorly conceived projects deliver poor systems even if execution was perfect.
2. Exceeding project costs are not a problem either because the business will “sweat” the assets anyway to recoup the loss and to squeeze as much out of it as possible. This is how those poor systems survive and stay around for long.

The result: technical debt.

Let’s hope they do not find that they need to delete customer records one day…

Nothing,

Absolutely nothing.

It is a gadget thing, it is a Google’s advertising thing – they know a bit or two about ads. And the value proposition is: now you (customer) can touch instead of swipe, and don’t have to carry around all that plastic in your wallet.

Admittedly, NFC enabled mobile (as in mobile phone) payment could be a convenient way to pay. Convenience, however, does not make a business case unless you can charge for it, and there is no word about charging for NFC facilitated payments.

What has not been tackled by NFC based innovations – see all the related news and announcements – is the business case and how it fits into the payments value chain.

Is it going to remove the plastic and the card vendors (the likes of Gemalto) from the equation? Is there a saving on plastic and chip and all the supply chain and stocking baggage that comes with that? Or is the plastic problem now replaced with a mobile and NFC chip baggage?

The fact is, NFC still requires a terminal (signal receiver), until that is removed or replaced with some commodity kit, there is nothing interesting about NFC and the likes. For example, consider the following where the actual POS device is replaced by the customer’s device (smartphone).

Could this scenario use NFC for the technical implementation? Maybe. However, until there is a business case for NFC in mobile payment, it will remain a hype, an attempt to carve out a buck or two from the payments value chain.

In the meantime, the really interesting developments are happening at Square and ISISPOS POS and the likes.

I have been researching the mobile applications space looking for a good (it is subjective, I know) technology stack that meets the following wish-list:

• Future proof (to some extent) – shifting in device types, geometry and OS-es will not render the stack unusable in over the next couple of months, maybe a year or two. This point also includes support for a variety of devices based on their use and market share.
• Does not require a steep learning curve for most development shops – existing skills available (in abundance) in the IT industry today would be able to match the proposed stack without much skills update, preferably only learning new APIs and not a whole new language and programming paradigm.
• Does not cost an arm and a leg – at least it is free to start developing and testing (simulator and device) and remains low cost (subjective again) going forward
• Plays nicely with current technology stacks – depending on the technology stack available in the environment where the mobile applications will be deployed – in my case this would be Java/Spring/Adobe Flex.
• Fast and Easy prototyping and demo – in other words a single person in a few weeks (weekends) can produce a working prototype or demo to sell the idea of the application.
• The end result is top-notch – it takes advantage (perhaps not fully) of the device specifics and features that make an application pleasant and usable from an end user experience point of view.

There are many good articles about the comparison of native and Web applications, like this one: Mobile apps choices: Native Apps vs Web Apps.

During my researches however, I came to like the technologies that are somewhere in between native and Web applications. It is a blurry, gray area for applications. They are developed like Web applications, but look and behave like a fully featured mobile application.

Two of these favored technologies are PhoneGap and Appcelerator/Titanium. Another good article on these two are here: A deeper look at appcelerator and phonegap.

Another intriguing technology is from the Mono team – MonoTouch and Mono for Android. It is also an inbetweener type, although more on the native application side, reusing a great deal of C# .NET skills for development. Still thinking through the future-proof valuation of this stack.

In the meantime, the search for the best technology stack for mobile applications continues…

Tokenization

• storage,
• capture/transmission,
• and back office administration.

Drawbacks to Tokenization

Tokenization providers act as a middle-man between the merchant and the processor. When a merchant performs a credit card transaction, the request goes through the tokenization provider before proceeding to the processor. When a credit card number is used for the first time, the tokenization provider creates a token that represents that number and only the token is stored by the merchant’s software. In future transactions with that card, the software simply provides the token in lieu of the credit card number and the tokenization provider replaces the token with the real card number when it communicates with the processor. While allowing the merchant to avoid storing credit card numbers and placing themselves in-scope for PCI-compliance, most tokenization schemes have several drawbacks.
First, most providers charge per-transaction fees for use of their service. These fees can quickly eat away at any savings provided by avoiding PCI-compliance.
In addition, most tokenization providers do not provide support for authorization reversals, preventing payment software from adjusting authorization amounts in response to backorders or freight amount adjustments. This causes downgrades and higher processing fees.
Most importantly, however, using traditional tokenization results in “provider lock-in”. Provider lock-in occurs when a merchant has been using tokenization and wants to switch providers. The original provider has all of the merchant’s customer credit card data stored in their system and leaving that provider means abandoning all that data and starting fresh. This can have highly negative consequences for merchants who use recurring billing, have auto-billed subscription services, or are simply used to the convenience of having customer credit cards on file.

Account Updating

According to MasterCard, on any billing cycle, the average merchant experiences a 25 to 30 percent decline rate on recurring payments – dramatically more than the average of 5 percent for card present transactions. Many of these declines result from invalid expiration dates or card numbers. As a result, merchants must spend time contacting the customer for alternative payment forms, which is not only a costly administrative expense, but also presents the cardholder with the opportunity to cancel service.

Subscription Billing’s Opposing Forces

When going to market using subscription billing there are three diametrically opposed forces fighting you, the person who owns the active subscriber count as you try to acquire and retain the most customers possible. These forces are PCI, Account Updater, and customer data ownership. I want to focus on the balancing act between the first two.
These days, one of the primary mechanisms to lowering the compliance burden and the actual risk of card disclosures is to use tokenization of those cards from your merchant acquirer, or gateway. Tokenization is simply an infrastructure at, for example, your gateway that will take the card you obtain from your customer on your checkout page, encrypt it for storage in their database, and hand you back a ‘handle’ to that card for future use. It doesn’t remove much of the compliance burden as credit cards still flow through your webserver and thus you still have to fully comply with PCI, but it does lower the risks of actual disclosure and shrinks the scope of your compliance efforts.
A surprising number of merchants are unaware of or don’t implement Account Updater, which is available from Visa and Mastercard in North America and some of Europe. Account Updater functions in two ways. The primary way will automatically send card changes for customers that you’ve billed in the last six months to you so that you can seamlessly update their card before a billing event. The alternative way is for you to either proactively or after a billing failure ask if there has been an update on any given card. We’ve found that the absolute best result is to run Account Updater in both modes and spend time optimizing the latter mode for specific billing plan frequencies.
Unfortunately, the requirements of Account Updater and its impact on customer retention are at odds with the requirements of tokenization in support of PCI. Most of the tokenization projects at the various vendors do not take the product requirements of Account Updater into consideration. How does one query the Account Updater service for the new card that may have replaced the one that failed when all you have is a handle to the old card? Unless your vendor has specifically added this to their tokenization implementation you are hostage to their product roadmap to save some significant percentage of subscriber churn. When you recall that few vendors are focused on the challenges of digital content and services with subscriptions, and instead get the bulk of their revenue from one time purchase physical goods merchants it makes sense that these tokenization projects have usually not addressed Account Updater functionality.

Using Previous Transaction ID as a token

…process a $1.00 auth on the card so that you verify the card is valid. Then when you are ready to charge the buyer, you would just perform a reference transaction API call where you reference the previous successful transaction and we will use the credit card information that was used on the prior transaction.  You would just pass over the new amount you want to charge.  So you would just have to know the transaction id of the previous transaction for that buyer so that you could reference it.  You could either look it up in your account, or store the id on your end.

The book I have just finished reading – Where Good Ideas Come From by Steven Johnson – had an interesting chapter on The Slow Hunch innovation pattern.

The part in there that really caught my attention was about the common-place-book. The following historical quote from John Mason in 1745 makes the case for organised (retrievable) thoughts:

Think is not enough to furnish this Store-house of the Mind good Thoughts, but lay them up there in Order, digested or ranged under proper Subjects or Classes. That whatever Subject you have Occasion to think or talk upon you may have recourse immediately to a good Thought, which you heretofore laid up there under that Subject. So that the very Mention of the Subject may bring the Thought to hand; by which means you will carry a regular Common Place-Book in your Memory.

In the same chapter, the historian Robert Darnton is quoted on re-organising texts into fragments and removing the linearity of the text:

Unlike modern readers, who follow the flow of narrative from beginning to end, early modern Englishmen read in fits and starts and jumped from book to book. They broke texts into fragments and assembled them into new patterns by transcribing them in different sections of their notebooks. Then they reread the copies and rearranged the patterns while adding more excerpts. Reading and writing were therefore inseparable activities. They belonged to a continuous effort to make sense of things, for the world was full of signs: you could read your way through it; and by keeping an account of your readings, you made a book of your own, one stamped with your personality.

Later in the Serendipity chapter – another pattern involving accidental connections – the author mentions DEVONthink, a tool to manage and organize all those disparate pieces of information. DEVONthink features a clever algorithm that detects a subtle semantic connections between distinct passages of text.

And this is where I would make the connection with my previous post about Enterprise Architecture: A Slightly Different Approach – making the case for capturing and managing enterprise knowledge in a Semantic Wiki.