Quo Vadis Business Technology Platform?

Few Thoughts on Technology Platforms in General

Every now and then I witness discussions on platforms. Now depending on whom you talk to, a platform could mean a different thing and one would need to precede the discussion with a definition of a platform, just in order to avoid misunderstandings. Hardware and infrastructure specialists have a slightly different conception of a platform than an application developer. I guess I personally use the term platform mostly as an application developer. If I were to provide a definition, it would come close to something one could summarize under the term of a computing platform – sloppily speaking being an environment to run software programs.

I don’t intend to start a general discussion on platforms here, since I generally think that those discussions are of somewhat academic nature. But to my observation, another dimension of complexity was added just recently to this discussion by the emergence of the term Business Technology Platform coined by SAP. The Business Technology Platform – by SAP’s definition – stands for an integrated offer comprised by (four) technology portfolios powering the (or an) intelligent enterprise. Those technology portfolios boil down to 1) Database and Data Management, 2) Analytics, 3) Application Development & Integration and 4) Intelligent Technologies – to quote the solution brief. And according to this very solution brief, the BTP shall give users SAP technologies at hand in order to become an intelligent enterprise and that is to turn data into a business value! Great so far.

For example, what are the SAP technologies behind those technology portfolios of BTP? Behind Application Development & Integration I clearly think of something like (even though not exclusively) the SAP Cloud Platform. This is where my thinking starts, e.g. if I were an Independent Software Vendor wanting to provide my own intelligent solution integrated with a modern SAP solution. Why is BTP my platform of choice?

What is my Platform of Choice?

If I were a software solution provider and had to make the call on a development and runtime platform for my solution, I would carefully place my bets. Alongside all the business and strategic discussions, at some point I need to consider operational constraints, since they may have significant impact on my business model (investment and especially return on investment, etc.). Many of these operational constraints concern technology and/or are technology related – to the pure technology or the platform itself. And here I don’t necessarily mean the set of capabilities of the platform (the “what”). I would personally be more concerned about the “how” of the platform – e.g. how flexible can the platform react to changes of requirements by the market or by my solution? I as a solution provider know that there are situations where I trade off my freedom of choice against a tempting but proprietary feature of the platform, but I will always try to avoid heavy lock-ins.

And there is something called DNA of a company. I shall only play in my domain, i.e. provide solutions within my domain of expertise. I normally also only have limited profile and skill sets within my company and this often presets even the programming model I will be using.

But at some point I will be making the choice of a platform, even though I may even decide to support more than one – in order to increase my potential market and if I can afford to.

What ever will it be, I personally would prefer an open, integrated platform with rich sets of services to choose from. Flexibility of deployment and operational excellence shall conclude the offering – so far my expectations.

Few Thoughts on the Technology Stack

Companies generally exist because they have a business model they believe in. Software or technology companies try to sell software or technology. There is nothing wrong with that; at the opposite – some business models turn out to be quite successful. And sometimes the appetite rises with the success. Some companies extend and enhance their business model led by the believe that they could serve all the needs a user/customer has. This urge has many manifestations. One of them is the attempt to own the whole technology stack – like being a general store. One can say that those companies are trying to get the users in every domain: You need a database? We have the right product for you. You need hardware for your data center? We’ve got the best! And by the way, we have the best integrated business solutions for your needs – no need to look anywhere else!

I personally never believed in strategies based on owning the entire technology stack, which translated in the language of economics would mean something like owning the entire supply and value chain – for example in a certain industry. And we know that this would correspond to a monopoly situation; a situation we as society are trying to avoid and the legislators are fighting, because it means the suppression and stagnation of innovation and healthy competition in the market. And though we have seen such attempts in the past. Once innovative companies expanded their business (models) possibly by acquiring other companies and thus completing the own product and service portfolio and finally becoming a large player in the market. In this role they become unignorable and could serve their customer’s needs in every domain. They become very and even system relevant and their business model changes from providing software to solve a certain business problem to providing software for solving all business problems. I believe that those days are definitely over. In today’s world we see an increase of complexity and level of system heterogeneity to an extent which would overwhelm even the attempt to control the systems by a single instance. This in conclusion and to my firm belief means that we as a software industry are going back to business models based on core competencies enhanced by 3rd party services. At least I hope, this is where we are heading at. And the main reason for this is not a sudden mind shift in the software industry, but a new development happening in the overall ecosystem and driven by user’s behavior: a switch from data center centric deployment and operational model for software solutions to provisioning of software as cloud-based services. The last sentence doesn’t impose anything new and terribly enlightening – I know. I am also aware of the fact that this shift has many implications; but one I want to emphasize here is in my opinion not that obvious. That is that while consuming software services, users (occasionally called customers) tend to go away from a frequently seen behavior in the past of consuming software from a preferred vendor, to consuming best of breed software services – simply because they only interact with a public service interface and don’t care about the “packaging” behind the scenes. The brand awareness stops at the public service interface level. This behavior is often seen with SaaS solutions.

Few Thoughts on the Business Technology Platform

Now one can translate what I just said to SAP’s Business Technology Platform. You have the business applications as the core competencies of SAP; providing software for solving a certain business problem. Now even though the set of those business applications is rather large and covers many aspects of today’s businesses, there are many white spaces to be filled with solutions from partners or custom built applications. All those solutions than run on a common application platform (Business Technology Platform), which in turn runs on infrastructure platform provided by hyper scalers (Google Cloud Platform, AWS, Azure etc.). The hyper scalers are the ones providing services of various granularity and scale. Take for example a component such as a transactional database – once being a crucial component and part of the software solution is nowadays yet another platform service. The hyper scalers platforms take care of the elasticity, scale, high availability and alike, since those capabilities are traditionally a responsibility of the underlying infrastructure.

So there is a clean separation of the concerns: the application platform supports the application programming models, the hyper scalers support the application platform with infrastructure services. There are only a few intersection points, where application logic developers could write or provide infrastructure specific code (think about AWS lambda or provisioning of application specific docker containers). I personally favorize this clear separation, since it is in the spirit of the concept of everybody doing the thing, they can do the best; the application developers developing applications and not necessarily wanting to become infrastructure experts and vice versa – no matter how tempted they may be by the promise of high profit in terms of monetization.

An application platform that is open for innovation and collaboration eventually and inevitably gains attraction, given that it provides a rich set of functionalities and services for the implementation of the use cases. But the point I am trying to make here is that with such a separation, both parties – the application platform and the hyper scaler – have sustainable business cases of their own. They are not disrupted by conflicts of interests (as they would be, if they would try to own the entire stack) but fruitfully complemented. And I am happy to see that the BTP has chosen to pursue this strategy.

My $0.02.