Don’t get into CI before considering these 7 Steps…

Continuous Integration is a software engineering practice aimed at improving the overall quality of products by providing early feedback at every step of the PDLC. It’s anchored by 4 main concepts: standardized code integration, automated build system, repeatable deployment to staging environment, and efficient testing discipline (unit, functional, regression).

However, this is not about the mechanics of implementing CI, there are many sources of detailed information on how to do that…Martin Fowler’s blog is an excellent source, in addition to open source projects such as Jenkins and services like Travis CI and Bamboo.

Sharing the 7 steps to ensure your CI journey delivers on the desired outcomes; they’re based on our own large scale CI transformation journey...We're still learning!

 1. Examine forensics of your technology stack

CI is not a one size fits all implementation…every technology stack has it’s nuances that have to be taken into consideration when designing the right solution. Homogeneous environments allows for better standardization of workflow design. On the other hand, heterogeneous/polyglot environments present different challenges. We designed our solution for a technology stack that includes components in C++, several flavors of Java frameworks, Python, and node.js. Another consideration is the characteristics of monolithic vs componentized application stacks…dependency management and isolation assessment is critical in ensuring visibility into unintended consequences.

 2. Assess organizational readiness

Generally, teams operate at different coding/testing velocities. It’s important to take that into consideration when designing workflows that integrate different components into a CI system. Customers care about the value delivered by solutions. Get a feel for existing engineering practices; engineers are the best source of feedback on pain points, weaknesses in the pipeline, and overall problems to be solved. Teams may be unable to automate their tests because of bad software design, lack of expertise, or unreliable dependencies.  Don’t implement solutions that can’t be adopted.  

3. Get executive buy-in

Getting to efficient CI practice is a journey, and it’s generally a long one. It’s imperative to get executive sponsorship…there will be situations where market demands dictate the pace and practices adopted for developing products…Shortcuts might deliver short term results, but we know that all you're doing is adding to the technical debt that has to be cleaned up at orders of magnitude the cost of sticking to the right practice. This is a call easier made if you have the executive leadership on your side.

4. Prepare the foundation

Getting the organization on the right CI track won't be easy. Telling the story at engineering roadshows and tech-talks on the benefits of CI is crucial to get the engineers excited about the program. In addition, communicating a few immediate activities that engineers can do to start realizing the benefits helps make the CI journey real. Activities such as standardizing the code repository hygiene, standardizing the branching strategy, getting engineer used to testing often, and standardizing code delivery around pull requests (code review is implied).

5. Influence the behavior

Target a few key engineers who are viewed as thought leaders, and who have the credibility in the organization as code ninjas…This group is the core, they would anchor your implementation and rollout strategy. Moreover, they’ll have a huge influence on building the culture of quality that’s very fundamental to a successful CI program. Engage these engineers through partnerships and white glove support to get them up and running, and productive!

6. Establish the governance model

CI governance is not about calling out non-compliant engineers…the carrot approach is much more effective. However, CI is about early feedback, so invest in building the tools, portals, and effective integration to provide the engineers self-governance. Engineers want to do the right thing, so enable them to do so with minimal friction, and clear accountability. Design systemic checkpoints to identify quality issues…it’s hard to argue with that approach. Help your engineers be successful.

 7. Iterate based on engineering experience

CI is a practice by engineers, for engineers. Realize that you won’t get it right the first time, and be ready to iterate as the PDLC ecosystem evolves. Implementing a feedback system will ensure surfacing issues related to scale of the code base, dependency complexities, and engineers operating in different geographies across several time zones with varying levels of skill and training.

Overselling CI without thinking about these 7 steps would jeopardize the desired outcomes…in addition, lacking credibility in implementing the right solution would make your job doubly challenging when you talk about complementing the CI practice with Continuous Delivery (CD)…The journey continues!

Payments: The next 18 months will dictate the next 7 years

If you've been following the payments industry (Electronic Funds Transfer, EFT, to be more precise), it’s clear that there are many players vying for a few critical spots in the processing chain…These players, some of whom are heavy weights, know that securing a spot will keep them relevant for consumers & merchants, and give them unprecedented visibility into the new connected commerce.

Let’s review the critical roles…Consumers need wallets to store their payment methods (Wallet). Merchants need registers to hold the money for goods delivered (merchant accounts), and accept as many payment methods as possible. In addition, a network is needed to transfer the money from the consumer wallet to the merchant register (payment networks). Needless to say, we’re simplifying the picture for the sake of illustration…there are numerous other roles, such as risk, compliance, optimal routing, value add, fraud detection, fx, x-border, etc…

The right wallet solution increases consumer stickiness…Meaning, once a consumer sets up a wallet in the cloud with a trusted provider, with ubiquity of venues to use the wallet, that consumer will generally not setup another wallet (at least consciously) anywhere else. This resonates with me personally as a sample of one, I've setup my bill pay with Bank of America 15 years ago, and even though I've moved to other financial institutions, all of whom offer bill pay solutions, I’m still using my BofA account ONLY for bill pay.

Merchant payment acceptance (POS, NFC, Check-in) has a direct impact on how they manage revenues, cash flow, merchandising & inventory, marketing, incentives, and consumer foot traffic (both online, offline, and mobile). Merchants are first and foremost interested in managing their business…getting paid is super important too, but it’s an expectation…just as you expect an ATM machine to dispense the exact amount you requested, and reflect it correctly on your account. That’s where the ISO (independent sales organization) becomes a critical link in merchant EFT engagement. ISOs are good for packaging (customized) solutions, in-depth understanding of merchant segments, providing contextual support, and enabling mass reach for service providers.

The networks are the plumbing that carries these transactions. The (debit, credit) networks are distributed, secure, global, and highly available. They’re federated by design, no one player owns the whole echo system…much like the internet. It’s a very valuable component of the equation, and as such, players owning networks have a very loud voice in driving & influencing the EFT industry.

The networks realize that transaction processing is commodity business…and competition is driving costs in a race to the bottom to acquire more business. There’s no money is processing credit cards. So they engage in value add services…fx fees & arbitrage, risk & fraud metrics, business intelligence, and direct consumer services. So it’s no surprise that when tokenization bubbled up as a technology that enhances consumer security, the networks are fighting hard to act as TSP (token service providers). Paypal is the original TSP; Paypal enables payments via email address. The opportunity for Paypal is to partner with a network to become the standard in tokenization. Make no mistake, this is a huge battle for position and dominance, with major players coming out with guns blazing…

When you control the token, you know the consumer, you know their spending habits, demographic, preferences, and you have access to their wallets in the cloud, and that’s pure gold. More importantly, merchants, marketers, card brands, and channels would be very interested in big data insights to target offerings to their consumer segments. Those insights bring tremendous value, hence, they are worth a lot of money. Keep in mind that data insights and privacy go hand in hand, it’s not about sharing/selling consumer data, it’s about general market insights to help personalize the experience.

ApplePay is assembling the puzzle expertly. They drive consumers to build their wallets (in context of setting up their Iphone) using their iTunes payment method as seed. They target issuers to encourage consumers to add all payments methods. Think of ads displaying wells Fargo + ApplePay, BofA + ApplePay, Capital One + ApplePay. Google just announced releasing the Pony Express, gmail based bill pay…Google is driving consumers to create a Google Wallet, using gmail and BillPay to drive stickiness.

Mind you, one of the best wallets out there is the Paypal wallet. It’s the most diversified, containing a lucrative funding mix (credit/debit cards, bank accounts, credit lines, gift cards). It’s the most global, 167 million active users, transacting globally (CBT). And it’s the most aligned with the company brand…when you think Paypal, you think payments…can you say the same for Apple, Google, or Amazon?

Payments systems are inherently open. Amex learned that the hard way; they chose to be the issuer and acquirer for the batter part of the 30 years…Amex wisely realized that the Visa/MC open model is much more powerful for penetration, and brand ubiquity. Fast forward to the hot mobile payment space: In order to transact using ApplePay, consumers have to own/use at least an Apple iphone6 generation & have an Apple wallet that only Apple accesses…not an open system. Android, on the other hand, is an open OS; installed on many devices from different manufacturers. What android is missing is a wallet.

The catalyst that’s driving the inflection point of wallets, networks, and merchant acceptance is EMV mandate that starting in October 2015, POS terminals must support EMV standard, including chip cards. Merchants that don't support the standard will be liable for fraudulent, lost, or stolen card transactions. It’s projected that 90% of cards  and 87% of terminals will be EMV compliant by 2017, with the majority of that adoption in the first 18 months.

The writing is on the wall, The next 18 months will dictate the next 7 years of payments industry leadership. Major players are staking their claim in the new and exciting payments space…the winner is a partnership that builds a compelling experience using a Wallet from a trusted brand, enabling ubiquitous Merchant Acceptance, powered by a secure, highly available, and global payments network.