Skip to Content
Personal Insights

APIs: our flawed legacy from 1960’s thinking

Object-Oriented Programming and Design principals have now existed for over 50 years, so it seems odd that apparently no-one has noticed the massive flaw in Object-Oriented Design that has existed since the very beginning. We are instead told Object-Oriented (OO) Design principals have won the day, as they provide a programmatic mirror image of the real-world scenarios they are intended to reflect. If we look a little deeper, OO Design is in fact completely detached from the world that it is intended to model. Whilst it is obviously true that the world consists of objects – known and unknown, real and abstract – the unimaginable flaw in OO Design fundamentals that apparently remains undetected until this day, is that calling objects can never have complete mastery (of the interfaces) of the objects that they call: objects can only ever be masters of their own Interface; of themselves.

Let’s imagine a Customer Object in negotiations with a SalesContact Object, in any given IT Landscape. OO Design asks us to pretend that the Customer Object has perfect mastery of the SalesContact Object Interface, and therefore knows exactly how to call the relevant RequestQuotation method of the SalesContact Object: having miraculously guessed at the name of that method, its latest publicly-available version, and based upon the false hope that the definition of the RequestQuotation method will not change over time. The obvious reality is that the Customer Object can only guess at the Interface of the SalesContact Object, and hope that this Interface does not change in the short-term (e.g. as the product range offered by the SalesContact becomes more developed, and therefore more complex). Add to this the fact that the the very same Customer Object may need to negotiate with several different SalesContact Objects in several different departments, not all using the same Interface Version or even the same Interface – the same API – and we must consider that the OO Design philosophy, as it stands today, is massively flawed.

What is a particularly troubling, given this knowledge, is that SAP is now working towards the “API-fication of SAP applications … to turn the Intelligence Suite into a modular suite”. By implication, should we wish to make use of this next-generation ‘modular suite’, we are expected by SAP to maintain perfect mastery of the Interfaces of each of its rapidly-evolving modules, and to regularly adapt API calls to those Object Interfaces as they evolve over time. And what if various distinct SAP systems are running in parallel within the same IT Landscape, as is often the case within large corporations? No problems, you simply need to adapt your API calls to the corresponding Object Interfaces n-times (e.g. 4 distinct SAP Backends = 4 separately maintained API streams): multiplied by the number of callers.

And what if we considered the same example of a Customer Object in negotiations with a SalesContact Object, using the real-world principals of Event Driven Architecture (EDA)? Under the EDA philosophy, the Customer Object would raise an event called ‘QuotationRequested’ using the Event Payload format and version of its choice – for the Customer Object is master only of itself – and any SalesContact Object(s) that chose to subscribe to the corresponding event channel – regardless of the internal or external network in which it resides – will receive this Event Payload from the Event Broker, and will act – irrespective of the technology or version upon which it is based – in the manner of its choosing: the SalesContact Object is master only of itself, as per the real-world.

If we continue with the scenario that was given earlier of 4 distinct SAP Backends – with up to 4 distinct API versions – we could therefore imagine in the example just given that the first 3 SalesContact Objects choose to completely ignore the latest ‘QuotationRequested’ Event, having decided that their department (host system) is not concerned, and that the 4th SalesContact Object might conversely choose to create a Quotation upon the basis of the received ‘QuotationRequested’ Event Payload and once completed, to trigger a ‘QuotationCreated’ Event containing all of the corresponding data. The Customer Object would then be immediately informed by the same Event Broker, at which point in time, it would process this latest ‘QuotationCreated’ Event exactly as it chooses (perhaps another quotation has already been accepted in between times, as the underlying 4th SalesContact Object system was unavailable during several hours, as per the real world).

As another point of contrast, what if the point is made that the ‘QuotationCreated’ Event Payload triggered by the 4th SalesContact Object could be packaged – at very little cost – in as many as 10 distinct (JSON) Payload Formats/Versions, within a single Event Payload? Well, given that the triggering SalesContact Object does not and cannot possibly have complete mastery of the Interface(s) of all subscribed Customer Object(s), it is in reality for each individual Customer Object to decide which embedded version of the Event Payload it is capable of processing (simply ignoring the others). And what if the underlying host system of this 4th SalesContact Object was upgraded by the relevant sales department (e.g. from SAP ECC6 to SAP Sales Cloud), what would be the corresponding impact on the unchanged Customer Object (host system)? There would be no impact whatsoever! It would process any received ‘QuotationCreated’ Events to which it has subscribed exactly as it did before, ignoring the newest Event Payload versions and formats. The Customer Object would no longer be asked to have perfect knowledge of the interface of each and every SalesContact Object with which it interacts – and to align its evolution with the completely unrelated upgrade schedules of foreign entities – but instead to focus only upon the evolution of its own inner workings: now that’s the real world.

SAP should abandon its recently announced “API-first strategy”, and instead develop its products to mimic the world that they are expected to support. Instead of an API-first strategy, SAP should be working towards an Event Driven Architecture that genuinely mirrors the real world, and corrects the flaws found in our inherited 1960’s thinking.

ANNEX

For those wondering why I failed to mention the Microservices Software Architecture Pattern, we learn from Mark Richards’ 2015 Software Architecture Patterns that, “While there are literally dozens of ways to implement a microservices architecture pattern, … The centralized messaging topology is typically found in larger business applications… [It] uses a lightweight centralized message broker … [with] advanced queuing mechanisms, asynchronous messaging, monitoring, error handling, and better overall load balancing and scalability”; just like an EDA Event Broker. We also learn that “since the microservices architecture pattern is a distributed architecture, it shares some of the same complex issues found in the event-driven architecture pattern, including contract creation, maintenance, and government, remote system availability, and remote access authentication and authorization”.

As you might have already guessed, this is quite simply because the Event-Driven Architecture Pattern is a fully fledged member of the “dozens of ways to implement a microservices architecture pattern”. The key distinction in this context being that unlike event-driven microservice implementations, message-based implementations demand that each and every microservice client has perfect knowledge of the ever-evolving interface of the called microservice(s).

Be the first to leave a comment
You must be Logged on to comment or reply to a post.