For this module your assignment is to consider the offerings of each provider, Amazon, Google and Microsoft. Then, in a 4 – 6 pag

Fintech: Choosing a Cloud Services Provider 1

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.

NA0473

For the exclusive use of H. Na, 2017.

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

2 Case Research Journal  Volume 37  Issue 2  Spring 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.

For the exclusive use of H. Na, 2017.

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

Fintech: Choosing a Cloud Services Provider 3

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.

For the exclusive use of H. Na, 2017.

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

4 Case Research Journal  Volume 37  Issue 2  Spring 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

For the exclusive use of H. Na, 2017.

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

Fintech: Choosing a Cloud Services Provider 5

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’

For the exclusive use of H. Na, 2017.

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

6 Case Research Journal  Volume 37  Issue 2  Spring 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,

For the exclusive use of H. Na, 2017.

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

Fintech: Choosing a Cloud Services Provider 7

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

For the exclusive use of H. Na, 2017.

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

8 Case Research Journal  Volume 37  Issue 2  Spring 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.

For the exclusive use of H. Na, 2017.

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

Fintech: Choosing a Cloud Services Provider 9

 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 …