BUSINESS CAPABILITY and API ECONOMY: beware of a man-trap

The first time published on OCTOBER 28, 2020

A notion of business capability becomes a popular topic in business and technology discussions. An evolution of “capability” interpretation has passed from ‘how we do the work’ through ‘what work we do’ to ‘ what work can we do’. The fundamental meaning of business capability can be explained as an ability to do/build/construct/gain/provide/deliver certain business value in the given business context.

In the Architecture of Business (AoB) concept, the notion of business capability is realised via an innovative loose-coupling between the capability’s functionality and any types of resources needed for the functionality realisation. In other words, Architects of Business define what should be available to the company, when and where, and then, together with operating and technology management, design necessary resources. For example, for the capability A, company needs certain operating skills, location, offices and communication means; for the capability B, company needs particular partnerships, management reserves and information technology (IT) resources for the implementation business tasks.

Yes, corporate technology is one of the resources of one or several business capabilities.

Architects of Business may or may not be well informed about IT capacity in the company. Instead, they are obliged to recognise what should be delivered via technology means and, in the best case, be aware of related technology capabilities. A popular belief that business decision-makers must know what corporate technology has and what it can offer is unrealistic and getting relaxed nowadays due to globalisation of the technology market. That is, first, the business has to understand what is needed and, second, engage internal or external technology resources/specialists depending on their availability.

People who have been in IT for the last 20 years clearly see that many of the same concepts, methods and even patterns are now renamed and re-developed, reset on the internet and offered to the business for money again. In the rally for new money, even such technology giants as  the Cloud Computing  and Microservices neglect certain aspects, which are crucial for business. Particularly,

1. Cloud Computing is a classic implementation of Service-Oriented (SO) Architecture. This means that the work in Cloud should adhere to the service-centric principles instead of traditional object-centric principles that the developers familiar with. Omitting SO principles, costs a lot of money, pain and “developer’s blood” to the businesses
2. Clouds are provided (in the dominant majority of cases) by external companies and do not follow the traditions, standards and policies of internal IT departments. As a service provider, a Cloud provider wants to keep its customer businesses happy, but it cares about its own benefits and revenue first of all
3. Microservice technology speeds up development of software products and systems and can be highly appreciated, but for internal use only. If Microservices, known also as API in modern technical slang, cross divisional or corporate boundaries, this itself immediately raises business risks of different severity.

The last statement requires more explanation.

Imagine a medium-size hotel. It needs to provide its guests with fresh linen every day. The hotel management believes that using professional laundries is more efficient than maintaining the own one. Luckily, a laundry locates across the street – just open the door and problem with linen is resolved. Then why the hotel loads it car every evening and morning and rides over three blocks to another laundry? The answer is simple – a business assessment of the laundry-across-the-street has shown it works with unreliable laundry processor, the quality of the ironing is not the best though cleaning is good (if and if it’s done).

When we talk about IT as a resource of a business capability, we have exactly the same business case as described above. When a business needs certain automation of operations and processes, the IT offers solutions built on Microservices and APIs. In IT, API stands for Application Programme Interface, i.e. an API is just an interface, which, as any other interfaces, does nothing by providing a means for interaction between entities. In our example, the laundry shop’s reception is such interface to the linen processing capability of the laundry service.

The technology buzz associates an API with a business functionality and claims that the external business engagement can be constructed as a programme. In IT mindset, calling an API is the same as requesting certain outcome – product or service – from an external business provider. From IT perspective, it is exactly right; from the business viewpoint, it is not necessarily right.

An idea of Microservices is practically the same, but the focus here is on accelerated development in IT where a Microservice is treated as a fragment of business functionality. In composition with other fragments of similar nature, Microservice can form an IT implementation of a business function or a feature. Each Microservice’s interface is an API. In our example, Microservices can represent the equipment and operations of the laundry shop, on one hand, and the equipment and operations of the linen cleaner shop, on the other.

Altogether, Microservices and API constitute an API Economy.

Apparently, it is an economy where businesses interact with each other by the means of programmatic APIs. A simple question – whether we are consistent, in a business sense, when we interact through API – is open and IT prefers to ignore it. A bit later, we’ll explain why the API Economy in its current state is of unsatisfactory to the business. Now, let us demonstrate a use of APIs in a trivial business case. It is not new and known well from the time when a regular telephone was the communication interface.

So, a company that provides APIs to its customers offers an information product, e.g. a list of properties available for leasing or a Lease List. This company is a Letting Agency that deals with potential tenants. The landlords can set certain rules or requirements that people who want to submit applications for the lease should meet by providing some information about themselves.  The Letting Agency has to collect this information and pass it to the landlords chosen by potential tenants. If the landlord decided to contact applicants, s/he does it directly bypassing the Letting Agency. This is a relatively common and straightforward system.

In the realm of business capabilities of the Letting Agency, the described business case requires, at least, following capabilities:

1. Collecting landlords’ proposals via web, phone, e-mail communication channels
2. Offering Lease Lists to the potential tenants via web, phone, e-mail communication channels
3. Collecting personal data of interested people via web, phone, e-mail communication channels
4. Challenging personal data against the landlords’ rules:

• a) Verifying personal data according to Sanctions Checking regulation
• b) Verifying personal credit history
• c) Verifying personal data against police records
• d) Individualising Lease Lists based on provided personal data
• e) Returning individualising Lease Lists to the applicants
• f) Charging landlords and/or applicants for the service
• h) Paying fees for the Sanctions Checking
• g) Paying fees for the credit reviews.

These capabilities are the ones that provide external communications of the Letting Agency. Other capabilities like composing the Lease Lists, storing collected information or matching offers with applications are internal capabilities. We will focus on the capabilities for external communication in this article.

People interested in leasing properties can use interfaces of the b), c) e), f) and g) capabilities; landlords can use interfaces of a) and g) capabilities while the d), h) and i) capabilities are used by the Letting Agency to communicate with the interfaces of the 3rd Parties. The interfaces in this case are different APIs provided by the technology resource that implemented the capabilities. Some of the APIs may be associated with fees, e.g. the ones related to the a), c), d), g), h) and i) capabilities.

For all capabilities, corresponding APIs are the resources that do not have own values other than the means of connectivity. In an ideal technological world, APIs are all what is needed, but, unfortunately, we do not live in such ideal world; the actual reality is harsher, and the business conducted via those APIs should take care of the reality.

Here are a few issues that APIs (technology) is incapable to satisfy. For example, from the API, people do not know:

1. what happens to their data on the Letting Agency side. It is possible that the letting agents do not do anything wrong with the customers’ data, but someone who is visiting the agency’s office might gain access to this data. Even if the personal data is encrypted, the decryption key is still in the Letting Agency and can be stolen to read the data. The only hope that people can get is a legal protection of their data, but the APIs do not incorporate such option
2. whether offered APIs provide any legal liability or information confidentiality within in the Letting Agency
3. whether the Letting Agency controls that some landlords offering the property for leasing are not bogus and not in the Sanctions Lists
4. whether the landlords really have rights to lease the properties out; whether the particular property is vacant/available, and so forth
5. how the Letting Agency resolves the validation of the people’s credit histories and that there is no leakage of information.

Additionally, there is another category of concerns – a use of APIs for intermediary external service providers and support APIs. Since many data processing resources are now deployed in the Clouds, a need for Web interfaces is obvious. The majority of such interfaces are APIs and we do not know whether they are just interfaces or there are real services situate behind them. From the customer perspective, a real service differs from anything else by standardised service description and service contracts (which include all business attributes beside the interfaces, e.g. business operational policies and regulations applied to the service).

It is quite likely that the intermediary external APIs are the ones from Amazon – AWS. This is one of the most solid, competent and biggest API provider. Let’s, however, look at its Terms and Conditions (an analogue of service contracts, though non-standardised). We will use a few quotes from Amazon’s documentation for the contextual references, the full texts of related causes are provided in the Appendix. Thus, in the Amazon’s “AWS Service Terms”, October 16, 2017, we can read (bold selection is mine):

• “26.2. In providing AWS Support… for all properly submitted cases [M.P.: errors or claims]… We do not represent, warrant or guarantee that (i) we will always be able to resolve a case fully, (ii) you will no longer experience a problem, (iii) we will provide a bug fix, patch or other workaround in connection with the identified problem, or (iv) any support or advice will result in any performance efficiency or improvement.” Regarding a compensation for the damage caused by such absence of guarantee, see our further quotes.
• “32.2 We do not represent, warrant or guarantee the quality of any files you create through your use of Amazon Elastic Transcoder or that the files will be of a certain fidelity or error free.”

This means to us that the service provider denies real support. Also, all problems with the data files are always claimed on the API-customer even if the errors might be the results of mistakes in the Amazon Elastic Transcoder implementation. Do you like this? This is not the end yet. In AWS Customer Agreement document, the “11. Limitations of Liability” section states (separation of the text, bold selection and bullet-points are added by me for the easier understanding):

“We and our affiliates and licensors will not be liable to you for any direct, indirect, incidental, special, consequential or exemplary damages (including damages for loss of profits, revenues, customers, opportunities, goodwill, use, or data), even if a party has been advised of the possibility of such damages.

Further, neither we nor any of our affiliates or licensors will be responsiblefor for any compensation, reimbursement, or damages arising in connection with:

(a) your inability to use the services, including as a result of any

(i) termination or suspension of this agreement or your use of or access to the service offerings,

(ii) our discontinuation of any or all of the service offerings, or,

(iii) without limiting any obligations under the service level agreements, any unanticipated or unscheduled downtime of all or a portion of the services for any reason;

(b) the cost of procurement of substitute goods or services;

(c) any investments, expenditures, or commitments by you in connection with this agreement or your use of or access to the service offerings; or

(d) any unauthorized access to, alteration of, or the deletion, destruction, damage, loss or failure to store any of your content or other data.”

Summarising: when a company’s developer uses AWS, Amazon declares no liability (and reimbursement/compensation) for the damages AWS can cause to your customers and for the losses of your data, for the Amazon’s downtime (jeopardising your business continuity) and for “any unauthorized access to, alteration of, or the deletion, destruction, damage, loss or failure to store any of your content or other data.” That is, Amazon is not responsible for any cases when on their side someone gains “any unauthorized access to, alteration of, or the deletion, destruction, damage, loss … of your content or other data.” If Amazon’s resources go down or become unavailable for the customers due to any reasons including the Amazon’s fault, Amazon is not responsible. Nice!

You work with Amazon on your own risk – this OK and business used to take risks. However, now the business is unaware of such risks and its IT places mission critical applications and data into one basket controlled by Amazon.

Please, by the God sake, tell us what else a business management might need to get shocked and to prohibit its developers from any use of AWS (for now)?! And this is the best world-wide API provider… Or maybe it is too good to be used?

Can we – people or businesses – trust API as a realisation means of our business capabilities at all?

Are the APIs in the form they are now represent an adequate instrument for business relationships?

Is there a real API Economy or this is only a marketing bluff?

Are the API benefits worth the risks of the API consumers or this have been just a rosy world of naive developers and a great opportunity for the fraud and the Klondike for not that good people?

Currently, the API Economy emerges as a herd of wild mustangs – they are too risky for a household until you can saddle and harness him. We can conclude that modern API Economy has to go a long way from a “kindergarten” to, at least, “high school” until it would be suitable for a public use in serious business. Reckless enthusiasts are always welcome to lose some grease over violated APIs (by the API owners or other enthusiasts).

When an organisation deals with its business capabilities, the Architects of Business focus on the business values first of all. If any resources such as API indicate risks, the capability usually incorporates risk mitigations that may be complex and expensive. This is the point where unjustified hopes on the API easiness and cheapness have to face a reality check of business revenue and reputation – what is more efficient for your business: paying for the API risk mitigation or not using such APIs (as they are today) at all? At the same time, there is the IT standard from OASIS that prescribes development of real services with the APIs free from aforementioned business problems; unfortunately, it is not ease to developers and, thus, is not in the API Economy mainstream.

Mathematics are familiar with a concept of conditions such as “necessary, but not enough”. The API based connectivity is necessary, indeed, but it is not enough to constitute an economy and to be taken as an unconditional implementation means for the business capabilities yet. We think that compliance with the emerging EU GDPR will clarify many confusing grey-spots in the API Economy for its advantage or disadvantage.

Appendix – Extracts

AWS Service Terms

Last updated: October 16, 2017

26.2. In providing AWS Support, AWS will use commercially reasonable efforts to (a) respond within the “Response Times” set forth in the Guidelines for all properly submitted cases… Cases may be submitted as specified in the Guidelines. We do not represent, warrant or guarantee that (i) we will always be able to resolve a case fully, (ii) you will no longer experience a problem, (iii) we will provide a bug fix, patch or other workaround in connection with the identified problem, or (iv) any support or advice will result in any performance efficiency or improvement. You are solely responsible for the implementation and results of any suggestions or advice received. [if at all]

32.2 We do not represent, warrant or guarantee the quality of any files you create through your use of Amazon Elastic Transcoder or that the files will be of a certain fidelity or error free.

AWS Customer Agreement

 11. Limitations of Liability.

WE AND OUR AFFILIATES AND LICENSORS WILL NOT BE LIABLE TO YOU FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL OR EXEMPLARY DAMAGES (INCLUDING DAMAGES FOR LOSS OF PROFITS, REVENUES, CUSTOMERS, OPPORTUNITIES, GOODWILL, USE, OR DATA), EVEN IF A PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. FURTHER, NEITHER WE NOR ANY OF OUR AFFILIATES OR LICENSORS WILL BE RESPONSIBLE FOR ANY COMPENSATION, REIMBURSEMENT, OR DAMAGES ARISING IN CONNECTION WITH: (A) YOUR INABILITY TO USE THE SERVICES, INCLUDING AS A RESULT OF ANY (I) TERMINATION OR SUSPENSION OF THIS AGREEMENT OR YOUR USE OF OR ACCESS TO THE SERVICE OFFERINGS, (II) OUR DISCONTINUATION OF ANY OR ALL OF THE SERVICE OFFERINGS, OR, (III) WITHOUT LIMITING ANY OBLIGATIONS UNDER THE SERVICE LEVEL AGREEMENTS, ANY UNANTICIPATED OR UNSCHEDULED DOWNTIME OF ALL OR A PORTION OF THE SERVICES FOR ANY REASON; (B) THE COST OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; (C) ANY INVESTMENTS, EXPENDITURES, OR COMMITMENTS BY YOU IN CONNECTION WITH THIS AGREEMENT OR YOUR USE OF OR ACCESS TO THE SERVICE OFFERINGS; OR (D) ANY UNAUTHORIZED ACCESS TO, ALTERATION OF, OR THE DELETION, DESTRUCTION, DAMAGE, LOSS OR FAILURE TO STORE ANY OF YOUR CONTENT OR OTHER DATA. IN ANY CASE, EXCEPT FOR PAYMENT OBLIGATIONS UNDER SECTION 9.2, OUR AND OUR AFFILIATES’ AND LICENSORS’ AGGREGATE LIABILITY UNDER THIS AGREEMENT WILL NOT EXCEED THE AMOUNT YOU ACTUALLY PAY US UNDER THIS AGREEMENT FOR THE SERVICE THAT GAVE RISE TO THE CLAIM DURING THE 12 MONTHS BEFORE THE LIABILITY AROSE.

Return to AoB