For the exclusive use of H. Na, 2017.

NA0473

Fintech:
Choosing a Cloud Services Provider
Clinton Daniel, University of South Florida
Janis Gogan, Bentley University

In June 2016 Joe Kwo, Fintech Chief Information Officer (CIO) and Executive Vice
President (EVP), needed to choose a cloud services provider for a new service, which
would deliver analytical data to Fintech’s customers – alcohol wholesalers and retailers.
In January, Kwo had discussed with fellow executives the idea of developing this cloud-
based service. His colleagues encouraged him to move forward, and now it was time
to select a provider for the company’s first move into the cloud.
Fintech, a Tampa-based privately owned company, processed electronic payments
and reported relevant data to U.S. wholesale distributors and retailers of alcoholic
beverages. Its website (Exhibit 1) characterized the company as a pioneer in electronic
payments; CEO Scott Riley proclaimed:
Cheers to everyone that navigated this company into the revolutionary alcohol
solution it’s become and to all who continue to carry the torch.
As EVP, Kwo saw the cloud as an opportunity to continue to exert technology
leadership by offering a service that would make it easier for Fintech customers to
derive valuable insights from their data. In turn, this would strengthen Fintech’s
relationship with its customers. As CIO, Kwo also saw challenges. He had previously
considered other proposals to migrate systems to the cloud, but felt that the risks at
the time outweighed potential benefits. In summer 2016 Kwo was still not ready to
commit Fintech’s entire set of transaction-processing systems to the cloud, but he did
want to move carefully into the cloud with a controlled test of a new service.
Kwo and his team had narrowed the feasible options to three providers: Amazon
Web Services (AWS), Google Cloud Platform, and Microsoft Azure. Once a provider
was chosen, Kwo would also need to consider how to launch, run and manage the new
service in a way that would strengthen Fintech’s relationships with its customers and
minimize cloud computing risks.

FINTECH AND THE US ALCOHOLIC BEVERAGES INDUSTRY

Alcohol sales were prohibited in the United States from 1920 (when the Eighteenth
Amendment to the US Constitution went into effect) until 1933 (when passage of the
-----------------------------
Copyright © 2017 by the Case Research Journal and by Clinton Daniel and Janis Gogan. This case was
prepared as a basis for classroom discussion, not to illustrate either effective or ineffective handling
of an administrative situation. The authors wish to thank the CRJ Editor and anonymous reviewers
for extensive comments and insightful suggestions, and Joe Kwo for his assistance in preparing this
case. An earlier version of the case was presented at the 2016 Annual Meeting of the North
American Case Research Association in Las Vegas, Nevada, USA.

Fintech: Choosing a Cloud Services Provider 1

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

Twenty-first Amendment repealed the Eighteenth Amendment). During Prohibition,

organized crime created a shadow economy based on “bootleg” alcohol. With
Prohibition’s repeal, each state was granted authority over alcohol distribution, and
many states imposed complicated regulations which (presumably) aimed to drive
organized crime out of the business. Most states mandated a “Three-Tier” system that
separated the roles of manufacturer, wholesale distributor, and retailer:
Manufacturers provide alcoholic products to wholesalers, who distribute the
products to retailers, who sell to the consumers. No one entity can be involved
in more than one tier under most state models and each tier is regulated and
licensed separately.1
For purposes of tax auditing, wholesalers were required to report alcohol sales
within specified timeframes. For example, the Texas Comptroller of Public Accounts
required reports to be submitted by the 25th of each month. Non-compliance could
result in suspended or cancelled permits, administrative action by a state Alcohol and
Beverage Commission, and other civil or criminal penalties.2
US alcohol beverage sales grew from about $177 billion in 2006 to almost $220
billion in 20153.
Fintech was founded in 1991 with the launch of its Electronic Fund Transfer
Payment System (EFTPS). As of 2016 Fintech, with 80 employees, (Exhibits 2 and 3)
supported more than $24 billion in payments per year. Whenever a participating
wholesaler delivered alcohol to a retailer, a transaction was recorded in EFTPS.
Fintech guaranteed to process payments on time and in compliance with applicable
state and federal regulations. EFTPS processed about 1.5 million alcohol transactions
per day. A typical EFTPS-supported transaction process included the following steps:
1. Wholesaler delivers alcohol to retailer.
2. (Using EFTPS) Wholesaler creates and delivers invoice to retailer.
3. Retailer receives invoice and authorizes payment.
4. Fintech withdraws funds from retailer account and electronically transfers
payment to wholesaler within the required time period. If there are insufficient
funds in the retailer account, Fintech pays the amount due wholesaler (and
retailer subsequently pays Fintech).
5. Wholesaler reports this Sale of Alcohol to Retailer by required date.
Data integration was an important challenge that Fintech had to address early on.
Data was defined and stored variously by producers, wholesalers, and retailers. A
hypothetical producer of “Kwo’s Beer” might label it “KBeer” in its product database,
within a “BRAND” attribute. A wholesaler database might store it as “Kwos Beer”
within a “BEER-BRAND” attribute, and a retailer might list “Kwo’s Beer” within a
“B-BRAND” attribute. To resolve such data integration problems, Fintech used a
“cleansing” process to match data transacted across the three tiers. This made the data
more useful for analysis and reporting.
Data were first captured in a “transactions” database system; it collected all
invoiced information from customers as they used EFTPS. To support analysis and
reporting, the transaction data were copied to a data “warehouse” --- a separate read-
only system used specifically for analysis. Maintaining separate copies of data for
operational and analytical purposes made it possible to optimize transaction processing
times, helped ensure backup and recovery in the event of a system failure or a power
outage, and ensured that business analysts could safely “slice and dice” transaction data.

2 Case Research Journal  Volume 37  Issue 2  Spring 2017

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

FINTECH’S IT DEPARTMENT
As CIO, Kwo managed an IT department comprised of employees with varied
technical backgrounds and skill sets. Kwo had earned a computer engineering degree
from the University of Michigan, an information systems degree from University of
Florida and an MBA from the University of South Florida. He was often heard to say
“Technologically, almost anything is possible … Use business sense and common
sense while looking at it quantitatively as well as qualitatively.” He was confident his
staff had the skill and expertise to support a fully functional IT infrastructure, and
capable of administering a variety of IT solutions for Fintech. Specific capabilities
included network administration, security, database management, custom application
programming, hardware support, project management, analytical report development,
and software support. Kwo’s IT staff were accustomed to working with and supporting
both established and new technologies.
At Fintech, both proprietary software and locally customized packaged software
were used, including many Microsoft products (such as Excel, SQL Server
Management Studio, SQL Server Data Tools, and Visual Studio). Several employees
had extensive relational database experience and used Microsoft SQL Server and
Oracle database.
Fintech developers used an Integrated Development Environment (IDE) based
on Visual Studio for some projects, and the open-source Eclipse IDE for Java
applications. Sometime a developer’s choice of IDE was from necessity (a task not well
supported by Visual Studio was well-supported by Eclipse). Other times, a particular
developer just felt more comfortable developing on one IDE versus the other.
Whether developing or purchasing software or services, Kwo considered himself
“conservative yet flexible” in his financial management. Before committing to a
development project, he required his staff to identify both short- and long-term costs
(throughout the project life cycle). Recognizing that unanticipated costs nevertheless
sometimes arose, he planned accordingly.
Occasionally Fintech hired outside consultants with specialized expertise. Kwo
carefully chose each consultant based on demonstrated character, commitment, and
experience. Any consultant utilized for a cloud-based solution would need to
demonstrate a solid ability to develop, implement, and manage cloud-based services
and data. Kwo considered consultants long-term “partners;” he wanted to use their
services not only for a particular current project but for future IT initiatives.
Kwo’s IT organization already coordinated with Richard Verrecchia, Fintech VP
of Analytics (with primary responsibility for bringing analytical solutions to Fintech's
current customers and for expanding its current client base for analytics). To identify
specific data analysis requirements for the cloud computing initiative, Verrechhia
worked closely with Kwo and his IT group. Most of the technical work-- such as
creating a specific report or developing a dashboard -- was done by local IT staff. Kwo
wanted Verrecchia to become familiar with the chosen cloud provider so he could
continue to deliver strong analytical solutions to Fintech’s customers. Verrecchia
described what customers typically requested:
Our customers usually prefer to work with Fintech data in one of two formats.
They may want to access the data directly, using some type of data access tool to
consume into their own local databases for analysis. Or, they may want the data
in the format of a comma-separated value (csv) file, so they can consume the data
into Microsoft Excel for analysis.

Fintech: Choosing a Cloud Services Provider 3

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

THE CLOUD
Along with social, mobile and analytics, cloud technologies and models have
earned a place as one of the core disruptors of the digital age. And while the cloud
market has matured over the years, its interaction with the rapidly growing data
and analytics landscape suggests there are plenty more disruptive opportunities
for cloud in 2016. – Thor Olavsrud, CIO, 1/26/20164
The National Institute of Standards and Technology ( www.nist.gov ) defined “Cloud
Computing” as:
a model for enabling ubiquitous, convenient, on-demand network access to a
shared pool of configurable computing resources (e.g., networks, servers, storage,
applications, and services) that can be rapidly provisioned and released with
minimal management effort or service provider interaction.5
End users interacted with cloud computing services in Software-as-a-Service mode
(Saas), when using applications such as Dropbox, Gmail, Skype, Twitter, and YouTube.
Many SaaS applications, such as Salesforce.com, evolved from an earlier Application
Service Provider (ASP) model. When working with an ASP a customer needed to
download some client software to their machine before it was possible to work with
that software online. In SaaS, a customer only needed a standard Internet browser (e.g.,
Chrome, Internet Explorer, Safari) and user credentials (e.g., username and password).
While most ASPs managed and hosted third-party software, many SaaS providers
developed and managed the software that they delivered online. In the original ASP
model, a separate instance of an application was dedicated to each particular corporate
customer, whereas SaaS providers used a “multi-tenant” architecture designed to serve
many clients (whether consumers or organizations). Many SaaS products worked
equally well via desktop or laptop computers, tablets or smart phones.
Less visible to end users were two other forms of cloud computing: PaaS, and
IaaS6. A Platform as a Service (PaaS) provider, such as Amazon, owned and operated
server farms/data centers and also provided useful tools -- such as automatically-
updated operating systems, development tools and middleware. A company that
purchased PaaS could focus on its unique software, since the PaaS provider would
manage and deliver both the infrastructure and behind-the-scenes software.
An Infrastructure-as-a-Service (IaaS) provider owned and operated the server
farms/data centers, but its clients’ IT staff would choose, install, and maintain their
own middleware, developer tools and so on.
By 2016 the distinction between IaaS and PaaS was blurring. For example, Google
advertised cloud services that blended “the best of PaaS and IaaS.” A company that
delivered IaaS, PaaS or Saas could be called a “cloud services provider,” but that label
was rarely applied to SaaS providers.
From a managerial perspective, a key attraction of cloud computing was that an
organization could rent a cloud service instead of making heavy up-front investments
in computers and software. In this sense, a cloud service was seen as a utility, similar
to electricity or water. Cloud computing also transferred the work associated with
updating infrastructure and ensuring high reliability to providers who were able to
capitalize on their extensive experience and scale.
While recognizing these benefits, Kwo knew that a move to the cloud was not
without challenges, including security concerns. A late 2015 presentation had stated
that many companies were storing data in the cloud in order to “protect against security

4 Case Research Journal  Volume 37  Issue 2  Spring 2017

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

threats,” yet “security will continue to be a top concern…7” A January 2016 article8
quoted Amit Pandey, CIO of Avi Networks:
So far, no major security breaches or significant availability challenges have
affected the cloud … However, as more and more businesses adopt the cloud
and a greater share of confidential data and apps are put in the cloud by users,
security challenges (DDoS or other cyberattacks), data loss, and potential outages
can increase.
In spring 2016 one article still expressed concern about security:
Enterprises are no longer sitting on their hands, wondering if they should risk
migrating applications and data to the cloud. They're doing it -- but security
remains a serious concern.9
That article, reporting on a conference presentation by the Cloud Security Alliance
(CSA10), described twelve specific security concerns in the cloud:
1. Data breaches
2. Compromised credentials and broken authentication
3. Hacked interfaces and API’s
4. Exploited system vulnerabilities
5. Account hijacking
6. Malicious insiders
7. The APT (Advanced Persistent Threats) “parasite”
8. Permanent data loss
9. Inadequate diligence
10. Cloud service abuses
11. DoS (Denial of Service) attacks
12. Shared technology, shared dangers
While many of these threats were well known, two were relatively new. The article
explained:
(regarding number 7): APTs infiltrate systems to establish a foothold, then
stealthily exfiltrate data and intellectual property over an extended period of time.
APTs typically move laterally through the network and blend in with normal
traffic, so they're difficult to detect.
(regarding number 12): Cloud service providers share infrastructure, platforms,
and applications, and if a vulnerability arises in any of these layers, it affects
everyone.
Gartner (www.gartner.com), an influential IT research and advisory company,
published reports describing how media publications viewed a new technology over
time. These “Hype Cycle” reports described a technology’s path, from first mention in
the trade or popular press to a “Peak of Inflated Expectations” (many “glowing”
articles praising the new technology). According to Gartner, a Peak was inevitably
followed by a “Trough of Disillusionment” (many articles describing problems with
the new technology), but usually would stabilize at a “Plateau of Productivity” (Exhibit
4). The 2015 Hype Cycle for Cloud Computing showed SaaS approaching the Plateau
of Productivity. IaaS was at the Slope of Enlightenment (many articles describing how
cloud computing can benefit organizations), while PaaS was on its way down the
Trough of Disillusionment. The umbrella term “Cloud Computing” was at the bottom
of the Trough of Disillusionment. Reports such as these made many CIOs – including
Joe Kwo -- approach the cloud with careful consideration; all wanted to avoid others’

Fintech: Choosing a Cloud Services Provider 5

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

mistakes and lead their organizations up the Slope of Enlightenment to the Plateau of
Productivity.

EVALUATING POTENTIAL CLOUD PROVIDERS

Many companies looked to the cloud for scalability; Fintech was no exception. EFTPS
had successfully handled increased payment transactions in the past several years, as
Fintech’s customer base grew. Kwo explained to others on the executive team that
more transactions meant dramatically increased data volume. A cloud-based solution
should easily and cost-effectively scale as needed. He added:
In this first cloud initiative, we will not move the EFTPS system to the cloud; just
a copy of the data that EFTS generates. This will be an excellent test of a cloud
service, and we can run it in a controlled way, rolling it out a few clients at a time.
Kwo asked David Nolte (Director of IT and Enterprise Data) to identify the top
three cloud services providers. Nolte assigned this task to a consultant who had worked
on several Fintech projects. “We have a good relationship with him, and he has a strong
background in projects working with the cloud,” Nolte explained. A few days later,
Nolte briefed Kwo on what he learned from the consultant:
Based on his professional experience, customer success stories, and industry
reports, our consultant says the three industry-leading cloud providers are
Amazon, Google, and Microsoft. He cited reports by well-respected research
groups. Gartner compared 15 different cloud providers against eight critical
capabilities in four use cases11. Amazon, Microsoft and Google scored in the top
3 for two critical capabilities for Fintech: batch computing and cloud-native
applications. Forrester indicates Amazon and Microsoft are Leaders in the public
cloud platform category,12 while Google is a Strong Performer.
In order to guide the provider evaluation, Nolte defined a Use Case (Exhibit 5) as
follows:
Extract: Each day’s transaction data (captured in EFTPS transaction
databases) would be copied to an Oracle Data Warehouse, which would also
contain relevant master data (such as product name, ID, and attributes, and
wholesaler or retailer name, ID, and location).
Load, Stage, Process: For a particular Fintech client, specific data would
then be loaded into the cloud-based solution for staging and further
processing. Processing required some custom programming, because of a
proprietary Fintech algorithm in the EFTPS system. The processed data
would be transformed to a format compatible with the client company’s
database.
Release: The processed data would then be made available to the client,
subject to secure and specific user access controls.
Monthly price estimates for each provider included cost of a single cloud-based
database instance, high performance computing power, at least 1024 GB of storage,
and customer support.
Amazon, Google and Microsoft had good reputations for offering strong cloud
services and support. Now it was necessary to look more closely at each provider,
taking into account economic factors (initial price, complementary investments, total
cost of ownership, etc.); technical factors (programmability, database support,

6 Case Research Journal  Volume 37  Issue 2  Spring 2017

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

scalability, etc.) human factors (availability and skills of local, provider, and consultant
IT staff and analytics staff), and other aspects, such as security.
Nolte’s team was undertaking an evaluation of the cloud providers’ offerings from
several perspectives:
 Training: Aiming to expand his IT staff’s cloud-related expertise, Kwo
had instructed Nolte’s team to find out what training each provider
offered, and whether trainers were locally available.
 System Administration Support – Fintech IT staff would administer
and maintain the cloud-based solution. How would each provider help to
ensure this important capability?
 Customer Support –Customer support would be supplied either by local
IT staff or a service provider. Either way, customer support needed to be
timely and at the highest professional standard.
 Data and System Availability – Ease of clients’ access to their
authorized data (subject to confidentiality restrictions) and high system
availability (“up-time”) were key requirements.
 Security – Fintech had a solid history of providing secure access to its
proprietary data, and Kwo did not want to jeopardize that good
reputation. Fintech needed to be able to control and provision the data,
based on each client’s needs and requirements.
 Programmability - Fintech would apply proprietary algorithms to the
data as it was processed in the cloud. Testing and implementing these
algorithms – whether by local IT staff or consultants –needed to adhere
to very detailed specifications.
The team gathered data from each provider’s website to learn about their basic
offering (Exhibit 6) and technical aspects of each service (Exhibit 7). There was a lot
to consider. Kwo was pleased to see that all three providers offered extensive
development support on multiple operating systems and devices, and Software
Development Kits (SDK) that supported multiple programming languages. Each cloud
platform integrated with an IDE (Integrated Development Environment) and a Source
Control System.
All three providers had trained many consultants on their products; certified
professionals were available around the world. Amazon Web Services (AWS) had a
network of Premier Consulting Partners in North America, Asia Pacific, Europe,
Middle East, Africa, Japan, and Latin America.13 Google used Platform Qualification
Exams to certify members of its Partner Community, comprised of Registered
Companies, Authorized Partners, and Premier Partners.14 Microsoft’s web site listed
consulting services that offered Azure training and/or support in about 30 countries15
and Microsoft’s Partner Marketplace group could support Azure Marketplace
customers. Thus, multiple training vendors supported each option, and each provider
also offered its own online training resources and exams.
All three providers offered a pricing calculator to help customers estimate monthly
or yearly costs. Google’s Total Cost of Ownership (TCO) calculator offered three
scenarios (Mature App, New Startup, or Static Enterprise), and considered various
other factors.16 Amazon’s TCO calculator let customers estimate based on On-Premise
versus Co-Located environments in particular countries with specific computing and

Fintech: Choosing a Cloud Services Provider 7

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

storage configurations17. Microsoft’s calculator was product-based (pricing

configurations specific to each product18). Kwo asked the team to compare providers’
pricing for the Use Case. To do this, the team worked with information provided in
each provider’s calculator (Exhibit 8).

DISCUSSING THE OPTIONS

In June 2016, Joe Kwo met with David Nolte and his IT staff. Nolte briefly
summarized the evaluation process the staff had undertaken: reviewing information on
each provider’s website and running a test of each service based on the Use Case. Kwo
thanked the team, then kicked off the discussion:
Is one cloud provider clearly a better choice for us than the others? I noticed a
lot of similarities across the options, so let’s focus on the major differences.
STEP 1 of the Use Case was the same for each cloud services provider: Visual
Studio and SQL Server Data Tools were used to create a SQL Server Integration
Services Package (SSIS). Nolte added: “The SSIS Package would be scheduled daily,
using SQL Server Agent Scheduler.” Data was extracted from the local Fintech Oracle
Data Warehouse using an Oracle ODBC (Open Database Connectivity) driver.
Nolte asked one member of the team to discuss what they learned about Microsoft
Azure. This individual first reviewed how the Use Case was mapped to the Microsoft
calculator:
 STEP 2: Use SSIS with MS OBDC Driver to load, stage, and process data
into MS Azure SQL.
 STEP 3: Client, using MS Azure User and Host access controls, accesses
data via secure MS ODBC connection.
He then explained key observations from the Microsoft Azure evaluation:
We can use Azure’s SQL database to migrate data for many existing applications
to the cloud. It is more expensive than Amazon and Google, but less expensive
than our current on-premise licensing cost for Microsoft SQL Server. Azure SQL
database might also be cheaper in terms of application re-development cost. We
chose the Premium Tier instance type configuration in order to meet our
computing and storage requirements. It was difficult to customize the
configuration, so we relied on Microsoft’s pre-configured options.
One more thing: Microsoft calculates computing performance based on Data
Throughput Units (DTUs), which was a bit confusing. Azure SQL uses an in-
memory database, which executes computations really fast. In-memory database
is a fairly new technology. After reading articles published by Microsoft
Developer Network, we learned that an in-memory database optimizes a data
table representation stored in active memory, and stores a copy on the hard disk.19
This may improve the performance of our proprietary algorithms.
Another team member described mapping the Use Case to Google’s Cloud
Platform calculator:
 STEP 2: Use SSIS with MySQL ODBC Driver to load, stage, and process
data into Google Cloud SQL Relational Database.

8 Case Research Journal  Volume 37  Issue 2  Spring 2017

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

 STEP 3: Client, using Google User and Host access controls, accesses
data on Google Cloud SQL via secure MySQL JDBC or ODBC
connection.
He offered his observations about Google:
To meet our computing and storage requirements, we had to increase the Google
Cloud SQL database instance to 16 virtual CPUs. Despite this, the cost was lower
than Microsoft Azure and about the same as AWS. Google’s database instance
configuration was flexible and easy to customize. Their pricing is extremely
flexible; they offer a volume discount as we increase the number of customers
using the service. However, until we actually learn how our customers use this
service, we cannot accurately calculate long term cost savings.
A third staff member described the Amazon Web Services exercise:
 STEP 2: Use SSIS with third party tool to load data into AWS S3 for
staging. Use third party tool to extract data from AWS S3 and load and
process into AWS Relational Database or Data Warehouse.
 STEP 3: Client, using AWS User and Host access controls accesses data
on AWS via a secure AWS JDBC or ODBC connection.
This team member explained:
Redshift is a database specialized for data warehousing. AWS offers persuasive
evidence of Redshift’s value in case studies on Nokia20, Coinbase21, FINRA22, and
NTT Docomo23. We did have to expand the database instance to 16 virtual CPUs
(similar to Google). Instances are organized as nodes, which allows us to easily
expand or contract our configuration. We had to purchase a third party tool to
load test data into AWS, but it integrated nicely with our existing extraction
packages. AWS offers a lower support cost than Google and Microsoft. They all
offer similar support, so we’re really not sure why Amazon’s support is
significantly cheaper.
Nolte and Kwo thanked the three presenters, and Kwo added: “You provided me
with a lot of helpful information on each provider.”

READY TO MOVE FORWARD?

Kwo’s peers trusted his judgement to make the best decision for Fintech. The
leadership team agreed that if the new system worked well, it would strengthen
Fintech’s relationship with its customers. However, Kwo was well aware that if it failed
to meet customer expectations for data quality and system reliability, customer
satisfaction could dissipate rapidly. He felt the analysis based on the Use Case had been
helpful, and his IT staff had done a good job of briefing him on key differences
between each provider’s cloud-based database service. The investigation had revealed
that Amazon, Google and Microsoft each provided some level of support for every
factor on Kwo’s list, yet differences were coming into focus.
Kwo felt ready to choose a provider. Back in his office, his thoughts turned to next
steps: “What can we do to ensure that this cloud provider meets or exceeds our
customers’ expectations?”

Fintech: Choosing a Cloud Services Provider 9

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

Glossary of Technical Terms

CPU Central Processing Unit; electronic component of a computer system that
executes instructions.
Data A database to support analysis and business decision making. Data is set
warehouse to read-only status, since its purpose is simply for read analysis with no
active connection to a live transaction system.
DTU Microsoft defines a Data Transfer Unit (DTU) as “a unit of measure of
the resources that are guaranteed to be available to a standalone Azure
SQL database at a specific performance level within a standalone database
service tier”24.
EFTPS Electronic Fund Transfer Payment System; proprietary system used by
Fintech to process payments electronically from customers throughout the
Alcohol industry.
GB Gigabyte; a measurable unit of storage. Can be interpreted as 1024 bytes
of data.
IDE Integrated Development Environment; software that programmers use to
develop applications
IMDB In-Memory DataBase; uses main memory (directly communicating with
the CPU) instead of disk storage, for much faster query times than
traditional databases. Used for high-intensity applications such as
telecommunications networks, and computational-intensive analysis of
very large data sets.
iOS mobile operating system developed by Apple, Inc.
JDBC Java Database Connectivity; an application programming interface (API)
for Java-based applications to connect to various data sources.
MySQL an open source relational database management system.
NoSQL sometimes called “non SQL”, “non-relational”, or “not only SQL”;
NoSQL stores data in a file format that is architected differently from
traditional relational database management systems.
ODBC Open Database Connectivity; a standard API used to connect databases
to various data sources.
RAM Random Access Memory; used to temporarily store data during
processing. High system RAM equates to high capacity to temporarily
store data.
SDK Software Development Kit; a set of software tools developers use to create
applications.
SSIS SQL Server Integration Services; Microsoft product that includes tools
that make it easy for database developers to work with and manage data.
SQL Structured Query Language; the common programming language used to
query data stored in a relational database.
Use Case A formal scenario for specific software functionality applied to a real-
world process.

10 Case Research Journal  Volume 37  Issue 2  Spring 2017

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

Exhibit 1: Fintech’s Description on its Web Site

Source: http://www.fintech.net/corp/company/about

Cheers to everyone that navigated this company into the revolutionary alcohol
solution it’s become and to all who continue to carry the torch.
- Scott Riley, Fintech CEO
About Fintech
Fintech, a U.S. Chamber of Commerce Best Business of the Year winner located in
Tampa, Florida, is the OneSource®solution for your beverage alcohol business.
Working with over 2,800 distributors, our business processes alcohol invoices for more
than 430,000 relationships nationwide and over $24 billion in payments annually.
Since receiving our first state approval in 1991 to use electronic funds transfer (EFT)
as a cash equivalent for the payment of beer, wine, and spirits, the Fintech system has
reinvented the alcohol data and payment process for customers across the country.
However, in the beginning, it had to overcome the fact that an electronic payment
option was not as widely accepted in the '90s as it is today. Besides, alcohol payments
by cash, check, or money order had withstood the test of time since 1933 – if it wasn't
broken, why fix it?
Fintech, nonetheless, very clearly saw the problems we could address for the alcohol
industry. With electronic payments and data reporting Fintech could increase security,
ensure compliance with all alcohol regulations, and most importantly – make alcohol
payments universally more convenient.
The challenge was persuading not only customers to transition to electronic payments,
but also each state to declare EFT a cash equivalent. With Fintech’s home state of
Florida being the first to pioneer this approval in 1990, our founders journeyed to each
state to prove that EFT was consistent with the principles behind each states’ alcohol
regulations.
It took years of perseverance, but Fintech’s electronic data and payment program is
now approved by all 50 states as a cash equivalent for alcohol payments – an
achievement that solidifies Fintech as an instrumental asset to the modernization of
the alcohol world.

Fintech: Choosing a Cloud Services Provider 11

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

Exhibit 2: Fintech’s Relationships with Retailers

Sample of National Retailers using Fintech

Convenience
Stores Drug Stores Hotels Supermarkets
Chevron Corp CVS/Revco Pharmacy Hilton Worldwide Giant Eagle
Circle K Kinney Drugs Hyatt Corporation Harris Teeter
Cumberland Farms OscoDrug InterContinental Hotels Kroger
Pantry Rite Aid Marriott International Trader Joe’s
Sheetz Sav-Mor Super Drugs Omni Hotels Whole Foods
Valero Energy Sav-on Drugs Ritz Carlton Hotel Winn-Dixie Stores
Wawa, Inc. Walgreens White Lodging

Institutional Mass Merchants Restaurants

Aramark BJ's Wholesale Club Applebee's
Centerplate Cost Plus Buffalo Wild Wings
Compass Group COSTCO Chili's
Delaware North K-mart Outback Steakhouse
HMS Host Sam's Club Ruby Tuesday
Levy Restaurants Target TGI Friday's
Sodexo Walmart Texas Roadhouse

Source: Based on information provided on www.fintech.net/corp, used with permission.

Fintech Nationwide Retailer Customer Relationships in 2015

Source: Fintech Website, Retrieved May 17, 2016, from http://www.fintech.net/corp/solutions/retailers,

used with permission

12 Case Research Journal  Volume 37  Issue 2  Spring 2017

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

Exhibit 3: Fintech’s Relationships with Wholesale Alcohol Distributors

Sample list of Nationwide Alcohol Distributors using Fintech

Alliance Beverage Distributing, LLC Imperial Beverage Co. - Elite Brands
City Beverage Indiana Beverage, Inc.
Coastal Beverage Co. JJ Taylor
Columbia Distributing L. Knife & Son
Crescent Crown Distributing National Distributing Co.
Doll Distributing Olympic Eagle Distributing
Empire Distributors, Inc. Quality Brands
Glazers Wholesale Reyes Holdings, LLC
Gold Coast Beverage Distributors Southern Wine & Spirits
Great Lakes Wine & Spirits Sterling Distributing
Griffin Beverage Superior Beverage Group
Heidelberg Distributing Virginia Eagle Distributing Co.
Hohensteins, Inc.

Source: Based on information provided on www.fintech.net/corp, used with permission

Fintech’s Nationwide Regulated Distributors

Source: Fintech Website, Retrieved May 17, 2016, from http://www.fintech.net/corp/solutions/distributors,

used with permission.

Fintech: Choosing a Cloud Services Provider 13

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

Exhibit 4: Gartner Hype Cycle

Gartner Generic Hype Cycle Concept

Gartner Hype Cycle for Cloud Computing in 2015

Source: Gartner Inc., used with permission

14 Case Research Journal  Volume 37  Issue 2  Spring 2017

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

Exhibit 5: Fintech Architecture Diagram

Fintech: Choosing a Cloud Services Provider 15

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

Exhibit 6: Comparison of Cloud Services Providers: Basic Service Features

Amazon Web Services Google Cloud Platform Microsoft Azure

Pricing
Pay-as-you-go: Per minute billing Per minute billing.
“Pay only for services you need for “No upfront costs, no
as long as you need, with no long- termination fees, pay only
term contracts” for what you use.”
Upfront costs? ? ? no
Termination fees? ? no long-term contracts ? no
Pay-as-you-go? yes; billing basis unclear yes, per minute billing yes; per minute billing
TCO Pricing Calculator? yes yes, calculates compute yes, monthly cost “based on
usage price/year one or more products
added to your Azure
account.”
Other pricing options? Option to pay in local currency. Automatic discount with increased
usage. Custom Machine Types to
match “whatever machine you want for
your workload”.
Service Level Agreement
> 99% avail? yes yes yes
Service credit for downtime? yes yes yes
Resource availability
Local IT staff? yes yes yes
Local analytics staff? yes yes yes
Provider-certified consultants? yes: Partner Community: yes:
Premier Consulting Partners Registered Companies Technology & Service
Authorized Partners partners, Partner
Premier Partners Marketplace.
Training
Provided by multiple vendors? yes yes yes
Certifications AWS Solutions Architect Associate Google Cloud Platform Qualification Online programs:
AWS Developer Associate Exams: Solutions Associate (MCSA)
AWS Administrator Associate App Engine Solutions Developer
AWS Architect Professional Cloud Storage (MCSD)
AWS DevOps Engineer Cloud SQL
Professional Big Query
Compute Engine
Customer Support
Technical Support Developer Support yes yes
Enterprise Support System Status Dashboard Console
Knowledge Center Help
AWS Support Center
AWS Support Documentation
AWS Whitepapers
AWS Support FAQs

Billing support Business Support yes yes

Enterprise Support
Online communities AWS Forums Developer Communities @AzureSupport
Online Forums

Source: Fintech documents, adapted for readability and used with permission.

16 Case Research Journal  Volume 37  Issue 2  Spring 2017

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

Exhibit 7: Comparison of Cloud Services Providers: Technical Considerations

Amazon Web Services Google Cloud Platform Microsoft Azure

System Admin
AWS Management Console Google Cloud Platform Console Microsoft Azure Portal
AWS Console mobile app Google Cloud Console mobile app Mobile Cloud Manager mobile app
for iOS or Android for Android for iOS, Android, Windows
Security
Cloud Security Information Security Team Design and Operational Security
Professional Services Data Center Physical Security Security Development Lifecycle
Penetration Testing Server and Software Stack Security Encryption
Vulnerability Reporting Data Access Identity and Access Management
Security Bulletins Data Disposal
Resources Platform Security Features
Compliance Cloud Platform Project Security
Partners
Programmability
Platforms / multiple platforms Development tools & Environments multiple programming languages
Languages multiple programming languages Logging & Monitoring multiple browsers
Deploy Systems Automatically multiple clients
multiple mobile devices
Windows or Linux OS.

SDK AWS language-specific Google Cloud-specific. language-specific.

IDE Toolkit Eclipse, Visual Studio Android Studio, Eclipse Visual Studio

Source control AWS CodeCommit Can use GIT Can use GIT
Scalability yes yes yes
Database
Relational SQL Server Cloud SQL SQL Server
Amazon Aurora
Amazon RDS
Oracle
PostgreSQL
NoSQL Amazon DynoD Cloud BigTable DocumentDB
Cloud DataStore

Data Warehouse Amazon Redshift ? SQL Data Warehouse

Fintech Achievable with Achievable with Achievable with
Test Use Case Third Party Tool. MySQL ODBC Driver Microsoft ODBC Driver

Source: Fintech documents, adapted for readability and used with permission.

Fintech: Choosing a Cloud Services Provider 17

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

Exhibit 8: Monthly Price Estimates for Use Case

(Price estimates calculated applying each vendor’s calculator to the Use Case).

Estimates below only include Database and Support. Other service prices not considered for this example.

Amazon Web Services Google Cloud Platform Microsoft Azure

AWS database SQL Database

Database (relational or data (relational or data warehouse
warehouse type) Google Cloud 2nd Generation type)

Instance Type dc1.large Instance db-n1-highmem-16 Instance Premium (Tier): P11 (Level)
Performance Level 16 Virtual CPUs (8 nodes) 16 Virtual CPUs 1750 DTUs
In-Memory OLTP
(online transaction processing)
RAM 120 GB 104 GB
stores up to14 GB of data in
memory
# of Databases 1 1 1
Uptime per month 744 hours 730 hours 744 hours
Storage 1280 GB 1024 GB 1024 GB
Database Cost $1488 per Month $1284 per Month $7001 per Month
Support Plan Business Support Gold Support Standard Support
$150 per Month
Support Cost (approx. 10% of monthly $400.00 per Month $300.00 per Month
usage)
Total Cost per
$1,638 $1,684 $7,301
Month
Source: Fintech documents, adapted for readability and used with permission.

18 Case Research Journal  Volume 37  Issue 2  Spring 2017

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

NOTES
1 National Alcohol Beverage Control Association (NABCA), “The Three-Tier System:
A Modern View”, March 2015 by NABCA Research, Retrieved May 17, 2016, from
http://www.nabca.org/assets/Docs/Research/ThreeTierSystem_Mar2015.pdf
2 Information related to “Due Date” and “Penalties” retrieved May 17, 2016, from

http://comptroller.texas.gov/taxinfo/alcohol/
3 https://www.statista.com/statistics/207936/us-total-alcoholic-beverages-sales-

since-1990/
4 http://www.cio.com/article/3026527/cloud-computing/11-cloud-trends-that-will-

dominate-2016.html
5 P Mell, T Grance. The NIST Definition of Cloud Computing, US Department of

Commerce, Special Publication 800-145, Sept 2011.

6 A. McAfee. What Every CEO Needs to Know about the Cloud. Harvard Business

Review, Nov 2011, HBS R1111J, 11/2011

7 A. Froehlich. “Eight Cloud Computing Predictions for 2016.” InformationWeek

12/23/2015). http://www.informationweek.com/cloud/infrastructure-as-a-
service/8-cloud-computing-predictions-for-2016/d/d-
id/1323598?image_number=1
8 T. Olavsrud, “Eleven Cloud Trends that will Dominate 2016” CIO, Jan 2016.

http://www.cio.com/article/3026527/cloud-computing/11-cloud-trends-that-will-
dominate-2016.html
9 FY Rashid. The dirty dozen: 12 cloud security threats. InfoWorld 3/11/2016.

http://www.infoworld.com/article/3041078/security/the-dirty-dozen-12-cloud-security-
threats.html
10 https://cloudsecurityalliance.org/

11 L. Leong. “Critical Capabilities for Public Cloud Infrastructure as a Service,

Worldwide”. Gartner Report G00270178, 26 Oct 2015.

https://www.gartner.com/doc/reprints?id=1-2QQX6UM&ct=151027&st=sb
12 JR Rymer and J Staten. “The Forrester WaveTM: Enterprise Public Cloud

Platforms”, Q4 2014. Dec 29,2014 https://d0.awsstatic.com/analyst-

reports/The%20Forrester%20Wave%20Enterprise%20Public%20Cloud%20Platfo
rms,%20Q4%202014.pdf
13 AWS Partner Network, Retrieved May 20, 2016, from

https://aws.amazon.com/partners/
14 Google Cloud Platform Partner Program, Retrieved May 20, 2016, from

https://cloud.google.com/partners/program-guide/
15 Microsoft Azure Partners, Retrieved May 20, 2016, from

https://azure.microsoft.com/en-us/partners/
16 Google Cloud Platform TCO Calculator, Retrieved May 20, 206, from

https://cloud.google.com/pricing/tco/
17 AWS TCO Calculator, Retrieved May 20, 2016, from

https://awstcocalculator.com/
18 Microsoft Azure Pricing Calculator, Retrieved May 20, 2016, from

https://azure.microsoft.com/en-us/pricing/calculator/

Fintech: Choosing a Cloud Services Provider 19

This document is authorized for use only by Hyunho Na in 2017.

 For the exclusive use of H. Na, 2017.

19 Quick Start 1: In-Memory OLTP Technologies for Faster Transact-SQL

Performance: Microsoft Developer Network, Retrieved on 6/10/2016, from
https://msdn.microsoft.com/en-us/library/mt694156.aspx
20 AWS Case Study: Nokia, Retrieved on 6/10/2016, from

http://aws.amazon.com/solutions/case-studies/nokia/
21 AWS Case Study: Coinbase, Retrieved on 6/10/2016, from

https://aws.amazon.com/solutions/case-studies/coinbase/
22 AWS Case Study: FINRA, Retrieved on 6/10/2016, from

https://aws.amazon.com/solutions/case-studies/finra/
23 AWS Case Study: NTT Docomo, Retrieved on 6/10/2016, from

https://aws.amazon.com/solutions/case-studies/ntt-docomo/
24 Explaining Database Transaction Units (DTUs) and elastic Database Transaction

Units (eDTUs), Retrieved on 6/11/2016, from https://docs.microsoft.com/en-

us/azure/sql-database/sql-database-what-is-a-dtu

20 Case Research Journal  Volume 37  Issue 2  Spring 2017

This document is authorized for use only by Hyunho Na in 2017.