CHOOSING A CLOUD SERVICES PROVIDER

CHOOSING A CLOUD SERVICES PROVIDER

 

INTRODUCTION

In June 2016 Joe Kwo, Fintech, Inc. 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, he also saw challenges. Kwo 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 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 also needed to consider: How to maximize this cloud opportunity? And, how to minimize the 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 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.”[footnoteRef:1] [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 ]

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.[footnoteRef:2] [2: Information related to “Due Date” and “Penalties” retrieved May 17, 2016, from http://comptroller.texas.gov/taxinfo/alcohol/ ]

US alcohol beverage sales grew from about $177 billion in 2006 to almost $220 billion in 2015[footnoteRef:3]. [3: https://www.statista.com/statistics/207936/us-total-alcoholic-beverages-sales-since-1990/ ]

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.

a. If insufficient funds in Retailer account, Fintech pays the amount due Wholesaler (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.

FINTECH’S IT DEPARTMENT

As CIO, Kwo managed an IT department comprised of employees with varied technical backgrounds and skill sets. Kwo had a computer engineering degree from the University of Michigan, a decision information systems degree from University of Florida and also earned an MBA from the University of South Florida in Tampa. 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 analytical 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 for their data analytics:

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.”

 

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/2016[footnoteRef:4] [4: http://www.cio.com/article/3026527/cloud-computing/11-cloud-trends-that-will-dominate-2016.html ]

 

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.”[footnoteRef:5] [5: P Mell, T Grance. The NIST Definition of Cloud Computing, US Department of Commerce, Special Publication 800-145, Sept 2011. ]

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 IaaS[footnoteRef:6]. 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. [6: A. McAfee. What Every CEO Needs to Know about the Cloud. Harvard Business Review, Nov 2011, HBS R1111J, 11/2011 ]

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 threats,” yet “security will continue to be a top concern…[footnoteRef:7]” A January 2016 article[footnoteRef:8] quoted Amit Pandey, CIO of Avi Networks: [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 ]

“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.[footnoteRef:9]” [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 ]

That article, reporting on a conference presentation by the Cloud Security Alliance (CSA[footnoteRef:10]), described twelve specific security concerns in the cloud: [10: https://cloudsecurityalliance.org/ ]

 

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 seven): “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 twelve): “Cloud service providers share infrastructure, platforms, and applications, and if a vulnerability arises in any of these layers, it affects everyone.”

Gartner Group (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’ mistakes and lead their orgaizations up the Slope of Englightenment 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 Group compared 15 different cloud providers against eight critical capabilities in four use cases[footnoteRef:11]. 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,[footnoteRef:12] while Google is a Strong Performer.” [11: L. Leong. “Critical Capabilities for Public Cloud Infrastructure as a Service, Worldwide”. Gartner Group 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%20Platforms,%20Q4%202014.pdf ]

In order to guide the provider evaluation, Nolte defined a Use Case, as follows (Exhibit 5):

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, 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.[footnoteRef:13] Google used Platform Qualification Exams to certify members of its Partner Community, comprised of Registered Companies, Authorized Partners, and Premier Partners.[footnoteRef:14] Microsoft’s web site listed consulting services that offered Azure training and/or support in about 30 countries[footnoteRef:15] 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. [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/ ]

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.[footnoteRef:16] Amazon’s TCO calculator let customers estimate based on On-Premise versus Co-Located environments in particular countries with specific computing and storage configurations[footnoteRef:17]. Microsoft’s calculator was product-based (pricing configurations specific to each product[footnoteRef:18]). 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). [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/ ]

 

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.[footnoteRef:19] This may improve the performance of our proprietary algorithms.” [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 ]

 

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.

· 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 Nokia[footnoteRef:20], Coinbase[footnoteRef:21], FINRA[footnoteRef:22], and NTT Docomo[footnoteRef:23]. 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.” [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/ ]

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?

 

Glossary of Technical Terms

CPU Central Processing Unit; electronic component of a computer system that executes instructions.
Data warehouse A database to support analysis and business decision making. Data is set 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”[footnoteRef:24]. [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 ]
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.
SLA Service Level Agreement; a contractual obligation to guarantee hardware or software customers specific system functionality and availability.
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.

 

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.

 

Exhibit 2 Fintech’s Relationships with Retailers

Sample of National Retailers using Fintech

Convenience Stores

 

Chevron Corp

Circle K

Cumberland Farms

Pantry

Sheetz

Valero Energy

Wawa, Inc.

 

Drug Stores

 

CVS / Revco Pharmacy

Kinney Drugs

OscoDrug

Rite Aid

Sav-Mor Super Drugs

Sav-on Drugs

Walgreens

Hotels

 

Hilton Worldwide

Hyatt Corporation

InterContinental Hotels

Marriott International

Omni Hotels

Ritz Carlton Hotel

White Lodging

Supermarkets

 

Giant Eagle

Harris Teeter

Kroger

Trader Joe’s

Whole Foods

Winn-Dixie Stores

 

Institutional

 

Aramark

Centerplate

Compass Group

Delaware North

HMS Host

Levy Restaurants

Sodexo

 

Mass Merchants

 

BJ’s Wholesale Club

Cost Plus

COSTCO

K-mart

Sam’s Club

Target

Walmart

Restaurants

 

Applebee’s

Buffalo Wild Wings

Chili’s

Outback Steakhouse

Ruby Tuesday

TGI Friday’s

Texas Roadhouse

 

Source: Based on information provided on www.fintech.net/corp

Fintech Nationwide Retailer Customer Relationships in 2015

retailer-map1

 

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

Exhibit 3 Fintech’s Relationships with Wholesale Alcohol Distributors

 

Sample list of Nationwide Alcohol Distributors using Fintech

Alliance Beverage Distributing, LLC

City Beverage

Coastal Beverage Co.

Columbia Distributing

Crescent Crown Distributing

Doll Distributing

Empire Distributors, Inc.

Glazers Wholesale

Gold Coast Beverage Distributors

Great Lakes Wine & Spirits

Griffin Beverage

Heidelberg Distributing

Hohensteins, Inc.

Imperial Beverage Co. – Elite Brands

Indiana Beverage, Inc.

JJ Taylor

L. Knife & Son

National Distributing Co.

Olympic Eagle Distributing

Quality Brands

Reyes Holdings, LLC

Southern Wine & Spirits

Sterling Distributing

Superior Beverage Group

Virginia Eagle Distributing Co.

 

Source: Based on information provided on www.fintech.net/corp

 

Fintech’s Nationwide Regulated Distributors

retailer-map

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

 

Exhibit 4 Gartner Group Generic Hype Cycle Concept

Source: Gartner Group

Gartner Group Hype Cycle for Cloud Computing in 2015

Exhibit 5 Fintech Architecture Diagram

 

/Users/clintondaniel/Documents/DBA/CRJ/Fintech-Architecture-Diagram_V2.jpg

Exhibit 6 Comparison of Cloud Services Providers: Basic Service Features

 

  Amazon Web Services Google Cloud Platform Microsoft Azure
Pricing      
  Pay-as-you-go:

“Pay only for services you need for as long as you need, with no long-term contracts”

Per minute billing Per minute billing.

“No upfront costs, no termination fees, pay only 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

usage price/year

yes, monthly cost “based on 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?

Service credit for downtime?

yes

yes

yes

yes

yes

yes

 

Resource availability      
Local IT staff? yes yes yes
Local analytics staff? yes yes yes
Provider-certified consultants? yes:

Premier Consulting Partners

Partner Community:

Registered Companies

Authorized Partners

Premier Partners

yes:

Technology & Service partners Partner Marketplace.

Training      
Provided by multiple vendors? yes yes yes
Certifications AWS Solutions Architect Associate AWS Developer Associate

AWS Administrator Associate

AWS Architect Professional

AWS DevOps Engineer

Professional

Google Cloud Platform Qualification Exams:

App Engine

Cloud Storage

Cloud SQL

Big Query

Compute Engine

Online programs:

Solutions Associate (MCSA) Solutions Developer (MCSD)

Customer Support      
Technical Support Developer Support

Enterprise Support

Knowledge Center

AWS Support Center

AWS Support Documentation

AWS Whitepapers

AWS Support FAQs

 

yes

System Status Dashboard Console Help

 

yes
Billing support Business Support

Enterprise Support

 

yes yes

 

Online communities AWS Forums Developer Communities @AzureSupport

Online Forums

 

 

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

Exhibit 7 Comparison of Cloud Services Providers: Technical Considerations

 

  Amazon Web Services Google Cloud Platform Microsoft Azure
Sys Admin      
  AWS Management Console

AWS Console mobile app

for iOS or Android

Google Cloud Platform Console Google Cloud Console mobile app

for Android

Microsoft Azure Portal

Mobile Cloud Manager mobile app

for iOS, Android, Windows

Security      
  Cloud Security

Professional Services

Penetration Testing

Vulnerability Reporting

Security Bulletins

Resources

Compliance

Partners

Information Security Team

Data Center Physical Security

Server and Software Stack Security Data Access

Data Disposal

Platform Security Features

Cloud Platform Project Security

Design and Operational Security

Security Development Lifecycle

Encryption

Identity and Access Management

Programmability      
Platforms /

Languages

 

 

 

 

SDK

 

IDE Toolkit

 

Source control

multiple platforms

multiple programming languages

 

 

 

 

AWS language-specific

 

Eclipse, Visual Studio

 

AWS CodeCommit

Development tools & Environments

Logging & Monitoring

Deploy Systems Automatically

 

 

 

Google Cloud-specific.

 

Android Studio, Eclipse

 

Can use GIT

multiple programming languages

multiple browsers

multiple clients

multiple mobile devices

Windows or Linux OS.

 

language-specific.

 

Visual Studio

 

Can use GIT

 

Scalability yes yes yes

 

Database      
Relational SQL Server

Amazon Aurora

Amazon RDS

Oracle

PostgreSQL

Cloud SQL SQL Server
NoSQL Amazon DynoD Cloud BigTable

Cloud DataStore

 

DocumentDB
Data Warehouse Amazon Redshift ? SQL Data Warehouse

 

Fintech

Test Use Case

Achievable with

Third Party Tool.

Achievable with

MySQL ODBC Driver

Achievable with

Microsoft ODBC Driver

 

 

 

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

 

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
Database AWS database

(relational or data warehouse type)

 

Google Cloud 2nd Generation

 

 

SQL Database

(relational or data warehouse 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
RAM 120 GB 104 GB In-Memory OLTP

(online transaction processing)

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 $1,284 per Month $7,001 per Month
Support Plan Business Support Gold Support Standard Support
Support Cost $150 per Month

(approx. 10% of monthly usage)

$400.00 per Month $300.00 per Month
Total Cost per Month $1,638.00 $1,684.13 $7,301.04

 

 

 

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

 

ClClCLLlCcccccccc

 

2

NO TIME TO WRITE YOUR ASSIGNMENT? . WE HAVE HAD A GOOD SUCCESS RATE ON THIS ASSIGBNMENT. PLACE AN ORDER WITH FOCAL WRITERS AND GET 100% ORIGINAL PAPERS

 

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>