Published on April 16, 2017
Opening business eyes on some aspects of Technology Revolution
IT was and is isolated… by Business. This is, probably, the reason for intent in IT Departments to disrupt everything around – to be noticed, at least. This includes a wave of innovations in technology as well. I have this guess because disruptions and innovations become a self-sufficient trend in technology regardless whether the business parts of the companies are disturbed by the market already or not yet. As we all know, innovations for the sake of innovations is a “double-edged sword”. Nevertheless, this is a part of the current digital revolution and, as a part of any revolution, ‘banks have to be taken the first’. The ‘banks’, in this case, are the means by which the profit is gained in the business organisations and who controls it. IT (in its isolation in the role of supplemental function) has missed this point.
Technology talks about new ways of doing thing. Why? People would say – ‘because of progress’. Indeed, but the progress needs investments that I does not have on its own. So, IT has to draw business values – if a company would implement Cloud or IoT, it will get a competitive advantage in the market. This is a technology view. A business view is this: if a company van sage significant amount of money or the company’s customers would be happy to pay more for the product/service, then the technical innovation does generate value; otherwise it generates a noise of words.
For example, if we have a system of street-lights that can adjust/adapt itself to the transport load, I think that everyone would appreciate this. If at the same time, using practically the same technology, my refrigerator, oven and dishwasher start creating a local network, which I cannot control at home, and this network start “optimise” operations of my devices in the way it understands optimisation, I will become not only unhappy but furious. Recently I’ve bought a new washing machine with multiple washing programmes and expected I would be able to combine them as I need. Nothing of the mind – they disallow me any combinations, which I had with the previous generation of this machine. I could not imagine that some engineers would dare to revoke my right to make decisions for me… I will not buy from that business anymore; technology innovation set up its own business. I want my rights back and I want technology to serve me, not itself.
In essence, I am going to demonstrate that the “good” things for IT are not necessary “good” for the business that owns the IT functions. I am afraid, I am ready to say that some technology capabilities are also not good to people – consumers of the businesses – and Information Technology must take its part of responsibilities for potential harms to people.
Let’s review an emerging business case where a customer interacts with a bank in the presence of such regulations as GDPR and PSD2 and the bank utilises such technologies as Cloud Computing, AWS-API/Microservices and Big Data- the major components of the digital revolution. Here are three business sub-cases.
Sub-case 1: GDPR and Big Data.
This is only one of possibly several sub-cases related to this matter. When we say “Big Data”, three values come to mind:
- Mathematical analysis of data that can result in uncovering unknown before internal inter-dependencies and connections between different data related to the same subject
- Use of Clouds of the IaaS type for storing collections of data
- Company’s financial saving on the technology infrastructure outsourced to IaaS.
We review mentioned values in the backward order. When we talk about company saving with regard to Big Data we, actually, assume that the data is outsourced into Cloud infrastructure/storage. That saving caused not by Big Data per se, but particular technology – IaaS – currently used for the data accumulation and processing. At the same time, this saving is not guaranteed: the real cost of ownership of the Cloud outsourcing has to include
a) a disaster recovery – procedure, technology and business operations that provide for “business continuity”. In many cases, the cost of disaster recovery can significantly reduce the customer saving raising a question about business feasibility
b) using IaaS/Cloud is a ‘hot’ marketing point for the IT and even for the business organisation, and relates to a populistic reputation of the company. The hidden part, unfortunately, is that the company places its data in the hands of another business with its own preferences, priorities, risks and interests. Such kind of outsourcing is principally different from the well know outsourcing where the contracted organisation executes particular function using your data. Particularly, you can hire one or another outsourcing provider as you want while the data is yours; here you send your data away and if one day you want to process this data by yourself, you do not have the data. Returning this data back to your organisation and/or hiring another IaaS storage can take you months. Have you ever thought about this risk? Now, try to add a cost of mitigation of this risk and see if you still have any savings… Moreover, the Cloud provider has only paper/contract-based obligations to your business while, de facto, can do anything with your data without informing you. Does enterprise business understand this simple situation? Altogether, this leads to a new risk of dependency for your business on an external independent company. Not only your reputation is at stake, but your real assets – the data – you pay for. According to GDPR, if your Cloud provider loses or disclose the customer data (in the Big Data set), you will be legally liable. Do you still want this Cloud-related saving?
c) the EU GDPR has been positioned in the way that can derail the major business value of Big Data. The regulation demands a company to obtain an explicit consent from each customer on what can be done with the customer’s data and how it can be used. Note, all internal dependencies and relationships hidden in the customer’s data are also customer data (I omit an adjective “private” because GDPR states that the combination of some customer data that can be used to identify of the customer are private customer data). How a company can ask for the explicit consent on unknown potential discovery, which can come out of the mathematical analysis of customer data? Even worse, consider the scenario that is fully in line with GDPR: today a customer has given the consent; the company has obtained important marketing information from the Big Data analysis and plans to use it next week. Tomorrow, the customer revokes the consent and the company may not use this information next week. The company loses opportunity and investments. Can you imagine the complexity and cost of managing the GDPR application to Big Data? Will the business really benefit from investing in Big Data for this particular case? Thus, before building Big Data infrastructure – on premises or in the Cloud – a company has to evaluate risks and their mitigation, i.e. conduct business, not technology, feasibility study if Big Data worth the investments at all.
Sub-case 2: PSD2 and Moneys
According to Wikipedia (14/04/2017), “… the European Commission proposal to create safer and more innovative European payments (PSD2). The new rules aim to better protect consumers when they pay online, promote the development and use of innovative online and mobile payments, and make cross-border European payment services safer”. We can ask as classic investigation question – who benefits from this regulation the most?
The Regulation opens access to the private accounts to all those who can use the bank’s API, i.e. it creates a strong competition to banks from the non-banking institutions. Why this became possible now? Right, because technology provided the capability of interaction via APIs. So, it is not beneficial for the banks while customers might gain some reduction of the bank service cost. Yes, might gain. Is it for benefits of those alternative non-banking institutions? Apparently, yes. Is it for EU financial bureaucrats (“…make cross-border European payment services safer”)? Yes, again.
However, there are no evidences so far that the payments standardised on the API, as regulated by PSD2, will be safer rather than riskier because many would be able to access customer’s accounts. For example, a hacker from Greece can easier break into an account of a German burger because the mechanism of access is already known. Even if I am not right here, the European Commission has made an unjustified populistic statement here.
What is the foundation of the relationship between a bank and a consumer? Yes, it is trust. Why does consumer trust bank? – Because there are a) written consumer-bank contract; b) government hedges consumer up to a certain amount of money against the bank default; c) the bank protects of consumer account from uncontrolled unauthorised access.
Assume, we are not that stupid to listen to propaganda and consider a following case. A bank, in line with PSD2, issues the API for accessing the customer accounts held by the bank. In this scenario, a bank consumer has to provide an explicit consent to the bank for opening a consumer’s account via API. If the programmatic APIs related to your account become publicly accessible, what an idiot would permit an unknown party to access his or her account? Assume, you are in a store and the cashier asks your permission to access your account directly to charge you (like many donation-collectors ask us in London to do because they are not trusted by their companies to collect the donations in a monetary form). Will you give your permission to the cashier together with your account attributes? Even if this particular guy is honest and only charges your account, what would guarantee you that no one else ever accesses your information and starts using it in unauthorised way? We have a lot of evidences that companies lose our data in mass in cases where we believe the data is safe. Actually, at the till, we are asked to give-up our money to anyone who wants them because technology can work with the API.
So, a very progressive (?) innovative regulation, such as PSD2 based on advanced technology capabilities leave us, consumers, in the terribly risky situation. Does this risk worth a small decrease of the account fees? I do appreciate the creation of more competition between financial providers, but, sorry, not on my charge. Before this technology innovation may be pushed forward and applied, we, the consumers, must be protected from the majority of bad cases.
In the next sub-case I’ll point onto the solutions of this problem, but technology will need to go back to its laboratories and work more on the implementation.
Sub-case 3: API/AWS/Microservices and doing business
Using the API is a modern and, possibly, the ‘hottest’ buzzword in technology and even in business. I understand that new generations of technologists need their ‘star hour’, but businesses who survived Dot-com should remember what happened that time beside wasting money. That was the time when Web became the buzzword and thousands companies pressed on opening their IT and proprietary business data for a public observation via the Web. Very few survived this dress-down being motivated only by a desire to be the first in that technology innovation and forgetting about the business reasoning.
Let’s return to our days. I talked with several well-known companies that create environments for Microservices. All of them concluded that at the modern level of maturity the Microservice-based applications should be oriented on internal API providers. This technology is not ready for business world because it does not have mechanisms to address business risks. Ignoring this would be equal to a suicide – not for technology, but for the business that owns such application. Do developers know this? Also, do they care? I do doubt this.
Instead, one of the most popular trends today is to use external APIs including AWS from Amazon. It is cool and cheap, and opens almost unlimited abilities to quickly build applications for almost any business needs. Well, let me remind you an old story about “Three Little Pigs”: the youngest Pig quickly built a house of straw. Great, the job is done! You remember the rest of this story and what happened with that Pig. In the context of our case, this story sounds as developers quickly contract Amazon’s APIs – AWS as well as any other “functional” APIs and, vous à la, a bank or other enterprise can use the new Microservice application and start making revenue. Yes, it is true if we could forget that Amazon has broken and sets down its AWS a few times a year and, as it happened in March, several hundred thousand companies went down as well, at once.
Stop, this is not the end of a story with Pig. In our story should be a Wolf and here you are. The Wolf is on the other side of an API call, behind the API. The Wolf is the API provider. Why I say so? – Because API technology allows so. Using an API, we do not know what an API provider can do with our call and accompanied data; we do not have a mechanism to set any legal agreement with the provider. This is why we are shooting to our business when we calling any external API.
These situations occurred thousands times with externally exposed Web Services resulted in dramatic consequences for the consumers, but people were not in favour to loudly report such silly failures. A fact that the API provided by any person or organisation with no or not-controlled obligations to the consumer (and this can relate to Amazon as well) is classified in business language as a counterfeit risk – as taking a business without a due diligence. Only very small business can take such risk because they have very little to lose; nobody would work with an unknown provider of a service. Even if this provider supplies the service well, it can be at the edge of default and your application will break when the provider fails. Also, the provider can be under control of a 3rd Party that you’d prefer to never deal with. Well, IT does not think about this because IT does not have primary business responsibilities; at the end of the day, what do you want from a supplementary function…
This rise of the API has been just an evolution of traditional programmatic API known for decades now put on the Web communication protocol. As before, the nature of the API is to connect the consumer to the provider that can calculate 2 +2 or a temperature in Kenya – no risks, no obligations. Now we are under a force that requires us to degrade our sophisticated world to the level of primitive connectivity with everything regardless our wishes. All this takes place when we have a very strong and standardised way of controlling API and making them safe for the business use, but it is not an IT way.
Five years ago, OASIS has issued a standardised specification known as Reference Architecture Foundation for SOA (SOA RAF), which returned API into a norm of business relationships. The standardised solution removes the API from the front-line and sets it only as a means of connectivity between decision makers, i.e. returns APIs into its natural and right place. Since API itself only connects A and B and has responsibilities neither for A nor for B, it is embedded in the mandatory document – Service Contract – to be agreed between the consumer and provider before an API is executed. Yes, legally agreed, though the agreement may be explicit or implicit. The Service Contract not only protects the consumer from unauthorised activities of the provider (the Service Contract includes all agreed policies related to business and technology), but also allows the provider to ignore requests from consumers without such a Service Contract. Apparently, SOA RAF and its Service Contract can form a framework for implementing PSD2: the bank’s API can access not anyone who has access to the Web, but only those who agreed/signed the Service Contract of the bank.
It is not a secret that banks stream into Clouds and API nowadays. Without a legal protection and means like a Service Contract, we all (consumers) can lose our money in banks as one of the possible results of these innovations. So far, there is nothing that can prevent such companies like Amazon, Google, and other providers of popular APIs to take the banks “by the APIs” and start dictating them the terms. Why not? API providers have no obligations to the API consumers other than to provide an API. Yes, Amazon includes a bit more in its standardised contracts, but have you seen any liability of the company for a sudden cancellation of contract? What the providers do with your information passed via APIs neither you nor anybody else know. All this brainless movement of IT into API sucks related business in a hole, but it can appear not a rabbit, but a black hole of the market.
HOW to ARCHITECT for DEVELOPERS 