Information Systems in the Corporate World: Part 2 — Transaction Processing Systems
Hi, welcome back to the second installment of Information Systems in the Corporate World. The scope of this blog post is to look further into Transaction Processing Systems (TPS) and determine what they are used for and the future of these systems. TPS are essentially what workers and junior employees in large corporations tend to use on a daily basis. This includes Supply Chain Management (SCM) systems, Customer Relationship Management (CRM) systems and Payment Processing Platforms which we will be looking at in more detail in this post. The purpose of these systems is to support the operations through which products are designed, marketed, produced, and delivered (Anon, 2019).
TPS are somewhat ubiquitous. In fact, I think it would be difficult to locate a large cap company in the developed world that does not have some sort of SCM system or payment processing technology. Amazon, Airbnb, Uber. I’m sure I’m not the only person that immediately thinks of the many multinational companies that must implement these systems as well. Given the shear scale of their customer base, it really comes as no surprise. However, did you know that many multinational tech companies are also responsible for designing a lot of the existing TPS? For example, we’ve all heard of Office 365, but did you know Microsoft also has a full suite of products just for business management? Check it out here, it’s called Dynamics 365 and it covers everything from Sales to HR to Inventory Control –if the website is anything to go by, it also transforms the running of a business into a utopian dream. Beyond this, some other big names in the Transaction Processing Systems market include Salesforce for CRM, Stripe for payments and QuickBooks for accounting. These products often come under the umbrella term: Enterprise Computing.
A Closer Look
For this blog, I’m going to use Stripe as a case study of a TPS provider since it’s currently very topical and they provide a service that companies seem to genuinely love. Plus, it was founded by two Irish brothers! For anyone not so familiar with this company, Stripe is essentially an online payment processing platform for companies big and small. At first glance, this does not seem a whole lot different to PayPal or bank wire transfers which were available long before Stripe even existed. That is where I would argue that the real value unlocked by Stripe’s product is the inherent TPS that allows businesses to process and manage payments in a far simpler manner than what their predecessors could offer. Let’s take a closer look at what makes Stripe a great example of a TPS, using the 5 components of an information system as headings:
Hardware
For Stripe to function, the only hardware really required is a device that can connect to the Internet. This is ideal for a TPS as they are generally the largest type of system implemented in organisations. That is, in terms of the amount stakeholders involved. For example, take Amazon, a Stripe customer that facilitates approx. $385 million in sales everyday (Buck, 2020). Do you think this would be possible if each customer was required to own a specific piece of hardware for each transaction? Or, what if the sellers had to record the bank details of each customer and then carry out multiple individual bank transfers? Essentially , the lack of hardware involved is the strength of a modern-day TPS, allowing companies to rapidly reach economies of scale. In Stripe’s case, I think they are a great demonstrator of the power of internet commerce where physical barriers can be bypassed by clever payment processing system engineering.
Software
So, this is where Stripe as well as many other successful enterprise computing platforms shine through. As mentioned, the removal of the hardware barrier for many TPS has resulted in a shifted focus towards the efficient design of software to give TPS companies a winning edge. In Stripe’s case, they have done this is by putting the web developer at the centre of their design. With clean, clear documentation and developer-friendly code, the emphasis on how easy Stripe’s APIs can be implemented clearly resonates with the developer community. This makes complete sense when you think about it, as more and more companies move towards the internet as a selling platform, they will often choose the payment processing system that gets them up and running in the shortest possible time, and evidently the system provider for this is Stripe!
Taking a broader perspective of TPS, I think we will continue to see this trend where companies will choose to implement information systems that are less of a headache for web developer and engineers.
Data
A consistent factor in transaction processing systems is the shear quantity of data involved. Stripe’s payment processing system is no different. In fact, in 2018 it was found that the median Stripe client is operating in more than 100 countries around the world and processes 600,000 online transactions per year that results in annual revenue of $9 million (Jewell, 2018). Obviously this brings a ton of complexities for the engineers at Stripe, and how this service is scaled could be an interesting blog post in itself. But more primitive questions we could ask include: How is this data stored? How do we know it’s secure? Well, the answer to the first question is: The Cloud. Since 2011, Stripe has delivered it’s payment platform entirely on AWS (see this video: https://youtu.be/WmHineJiYqk,the link won’t embed in the article unfortunately) which gives Stripe the benefit of having to spend less time and money on maintaining their own internal servers at the expense of product innovation. At this stage, it’s hard to believe that any large company wouldn’t store TPS data in the cloud given the apparent cost-savings and the added relief of not having to worry too much about the security of internal servers.
On the topic of security, Ciaran has already touched on the pros and cons of regulation such as GDPR, as well as how companies can get around it. However, one point worth noting is how the data can be physically secured, which to me is really fascinating. Google for example, has 6 layers of security at their data centres where certain employees must even scan the retina of their eye to gain access to certain rooms. Microsoft on the other hand are currently experimenting with underwater data centres (!)
People
Hmm, there’s not much I can say for this heading. The beauty of modern-day TPS is that the rapid growth of automation has resulted in less and less people being involved in the operation of information systems. This in itself brings its own issues. Are the robots taking over? Will humans be rendered useless thanks to automation? In a typical use case for Stripe: Take a customer buying a product on Amazon using their iPhone. As they have already linked their bank details in Apple Wallet, and they can authenticate themselves using Face ID, their one task is simply to look at their screen when prompted to buy, and voila, the transaction occurs. Meanwhile on the client side, there’s no need for countless employees and realms of paperwork, the transaction data is indeed packaged in a neat, clean dashboard that can be customised to the client’s taste. In fact, this data can really be sent straight to management, without need for further accounting processes. Pretty cool.
Beyond this, the only other people that could be involved in a TPS like this is the employees! Despite these technical wonders, sometimes software doesn’t do what it’s meant to do and some people can have ill-intentions. So it must be mentioned that humans are still a critical component of TPS nowadays. In fairness to Stripe though, one look at their uptime status from the last 90 days makes this a hard point to prove:
Processes
With regards to Stripe, the main process carried out by the company’s software is the transfer of money and data between accounts. How this happens can really be simplified to this: Stripe designs API’s which are essentially pre-made snippets of code that can be integrated into existing website interfaces. When these API’s are (easily) integrated into the checkout section of a client’s website, it allows Stripe to access the data entered by the customer, typically credit card info, cost of transaction etc., and triggers an online bank transaction. Stripe then goes one step further notifying both parties of the successful (or unsuccessful) transaction, but more importantly, this data is then recorded, aggregated and displayed on a slick dashboard for the convenience of the client so that they can record and analyse the performance of the company in terms of revenue, churn rate, gross sales volume etc. This can then be fed into other information systems further up the hierarchy.
So that’s it for this blog post. Apologies, it was fairly long one. However, I hope it was both interesting and informative. Next time, we take the next step up the pyramid of business information systems: Management Information Systems.
See ya,
Conor K
Wilsons Warriors
References
- Anon (3rd October, 2019) Information Systems and Future, Available at: https://witanworld.com/article/2019/10/03/information-systems-and-future/ (Accessed: 08/03/2021).
- Buck A. (2nd November, 2020) 57 Amazon Statistics Sellers Need To Know, Available at: https://landingcube.com/amazon-statistics/ (Accessed: 10/03/2021).
- Jewell, J. and Marden M. (2018) The Business Value of the Stripe Payments Platform, San Francisco: IDC.
