Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
On-demand has become a buzzword in the last months/years. Some people interpret on-demand by “modern” and on-premise by “old-fashioned”. That’s basically wrong. This blog is to present considerations and/or questions that shall help you to justify which operational model to use for new applications no matter if they are built or bought. The migration of applications from one operational model to another, however, is a completely different game. We don’t touch this topic in this blog.
Definition: Hybrid
If some applications are run on-premise whereas  other applications are run on-demand then we call this operational model “hybrid”. This definition is perfectly aligned with article #15 on the meaning of “hybrid”.
This definition should not be mistaken with the one of “mixed” applications where the same applications run partially on-premise and partially on-demand.
The purpose of this blog is to provide considerations of a very general kind. We don’t want to cope only with SAP applications or solutions. The situations we describe in this blog are valid for basically all customers who think about utilizing on-demand as a new operational model. We are targeting decision makers and middle management as readers of this blog.
Now, let us start by looking at two initial examples:
Example: Long-established Company
Setting: You are leading a long-established company. Your IT is up and running for quite a while; not the latest hardware/software, but it is sufficient. All applications are built on-premise
New applications should definitely be built on-premise as all applications before because infrastructure and skills are available for on-premise.
This example is typical for companies following a conservative approach with regards to adopting new technologies.
But, let us now look at a diametrically different example:
Example: Start-up Company
Setting: You are a new business application startup. As newly established software company you leverage most modern IaaS or PaaS platforms to provide your solution as on-demand SaaS application to your customers.
The on-demand operational model is obviously the right solution, at least for the first period of time as it produces lowest costs.
These two examples lead us to the introduction of a concept that we want to call “dynamics“. It is definitely relevant for this decision finding process with regards to the operational model to use.
Definition: Dynamics
In general, dynamics means alteration from what has been and what will be. The more need or wish for alteration, the more dynamics. In this interpretation dynamics can be seen as a driving force for alteration.
The bigger the system landscape of a company is (no matter whether on-premise or on-demand), the more expensive is each single alteration if it is of a general kind. Hence, the desire for change becomes smaller and smaller. So is the dynamics. This conception is surely not valid for all kinds of alterations, but for many of them.
The example of the long-established company underlines this thesis. So, it sticks to the up-to-now operational model (on-premise in this case).
The example of the start-up company on the other side is characterized by extreme dynamics which doesn’t mean that you have to change your operational model. It just means you have the freedom to decide. So, you should think carefully about all the boundary conditions to find the right decision.
Dynamics is a very important criterion for the decision of the right operational model, especially as its meaning is twofold: On one hand the dynamics of the company is meant (see examples 1 and 2), on the other hand the dynamics of the business demands are meant (see upcoming example 3).
Possibly there are even more aspects of dynamics that are relevant for our considerations. And all of them tend to the freedom of choice. In many cases they tend to the on-demand model.
Example: DZ Bank AG (see 1)
Setting: For more than 15 years, DZ Bank uses an integrated technology solution based on SAP ERP HCM for its human resources (HR) tasks. Now, initiated by the expansion of DZ Bank, the HR processes were to be tightened up and data were to be provided more reliably and transparently.
For complementing its existing on-premise HR systems DZ Bank decided to add SAP’s cloud applications by SuccessFactors for performance & goal management.
Besides dynamics as a driving force, there must be other criteria, more rational ones that are of relevance. Let us look at an (incomplete) selection of them.
Criteria Table

Criterion

“On-demand”

“On-premise”

Backend Connectivity

To be compensated by a peer-to-peer communication technology from on-demand to on-premise (see 13) and possibly further infrastructures built on top of this basis

Datacenter Local Area Network and internal local application middleware.

Control

100% trust in your SaaS-provider (see 3, 4)

100% internal control (see 3, 4, 7, 9)

Costs

Pay as you go, per user, per month, etc (see 4, 7)

Up-front costs for hardware, maintenance, software licensing, datacenter facility, etc.

Customization

Limited (see 3)

Possible in wide ranges (see 9)

Infrastructure: Sizing, Updates, Add-ons

Provided by the cloud offering, priced-in, limited capabilities (see 4)

Rather complex and expensive

Integration with existing or 3rd party software

Only loosely coupled (see 3, 4, 7)

Loosely and tightly coupled are both effective (see 3, 9)

Mobile access

Authorizations are taken care of effortlessly (see 7)

Most companies have “build-your-own“ mobile connectivity infrastructure (see 3, 7)

Network Costs

Very high because of increased investment needs in WAN communication reliability, security and performance investments

Very low costs: Local Area Network

Reliability

Central back-up systems are available in case a server crashes or power goes out. Duplicate or redundant systems replace in case of serious failures
(see
4)

Usually, there are no back-up or duplicate/redundant servers available except you are dealing with very sensitive data (e.g. banking sector)

Security

A2A data transfer via internet creating security risks; compensated by high security efforts of the provider (see 14)

A2A data transfer via internal datacenter environment creating lower risks (see 9)

Support of proprietary software processes

Only standard API’s and scenarios are supported by a SaaS  provider. But through the APIs you can build custom extensions and support them on your own.

Easily possible (see 9)

Time-to-market

Joint development of software, infrastructure and operational processes (see 4, 7, 9)

Separation of software development and infrastructure / operations yielding a TCO disadvantage

Legend
·  means to be the better solution for the according criterion
·  means to be an equivalent or almost equivalent solution in regards to the better one
·  means to be the disadvantaged solution for the according criterion
Comments for the Criteria table:
For each of these criteria you have to judge how relevant they are for the situation of your company. A weighting factor can probably help representing this relevancy, formally.
Instruction for use to make an operational model decision for new applications:
1.   Rational Part.
You walk through all the criteria of the table and for each of them you weight its relevancy for your company and, hence, get an indicator for one of the operational models. By taking all criteria into account you achieve a direction towards one of the operational models.
2.   Case distinction Part.
If you are using a hybrid operational model landscape, already, then it’s just perfect.
If you are running applications on one operational model only (usually on-premise) and if this one is the one you retrieved by the criteria table, then it’s perfect, too.
But, if it’s the other one and you want to follow this recommendation, then you have to invest additional money to build up knowledge, train employees and to build up infrastructure to operate on two different operational models. These costs may be very high depending on the situation of the company / number of IT employees and other related factors. A lot of these costs are one-time start-up costs. They pay off best if a company sets a long term strategy to embrace cloud solutions, so that these startup cost are amortized by many cloud solution usage.
Only in this case the upcoming part (balancing part) in the decision process is applicable.
3.   Balancing Part.
These additional costs (see case distinction part, last option) have to be balanced against the dynamics of the company, of business demands and other aspects (see section “Dynamics” above).
To illustrate these considerations better, let’s revisit the example of the DZ Bank AG above: It shows that additional costs for the second operational model (although maybe high) are not as significant as the dynamics of the company (“expanding”) and the dynamics of the business demands (“tightening processes” and “data to be more reliable and transparent”).
The situation looks very different in the example of the long-established company.
The rational part evaluates the criteria table as a lot of other articles in the net do in a similar way, before.
That’s not new!
The case distinction part then compares the operational model the company uses right now with the one the criteria table yielded in the rational part. If it’s the same or the company uses a hybrid operational model, then everything’s perfect. But if not, then and only then the balancing part becomes relevant. As the name suggests it eventually balances the imminent costs with the dynamics of the company, business demands and so on. So, the decision is made. And this is the part of the process that is new. The consideration of different aspects of dynamics influences the result retrieved by the criteria table significantly.
Summary
Operating on hybrid operational models seems to increase TCD/TCO in many scenarios depending on use case, business case and other criteria. Nevertheless, these costs have to be balanced against the dynamics of the company, the business demands and similar aspects of dynamics.
In the near future the hybrid operational model will probably be just reality.
This histogram shows us where the distribution of operational model may evolve between 2012 and 2016 even though the specification of concrete years should better be exchanged by intervals in order not to pretend a precision that is just not there.
The most important operational model of the next years will be the hybrid one because many companies that rely today on on-premise will change to the hybrid operational model in the same way as our DZ Bank in example 3 did. The percentage increases heavily from 2012 (40%) to 2014 (63%). But, the peak of this process will be reached in 2014 if the prognosis is right. After that, the number of companies favoring a hybrid operational model will decrease, again. This red curve most probably has to be stretched into the future for all companies, but especially for big companies.
There will be quite some companies sticking to their on-premise model. Our example of the long-established company also belongs to this fraction. But the number of these companies constantly decreases from 50% in 2012 to 13% in 2016. One might ask whether the on-premise operational model will really decrease that much and that early.
More and more companies, however, will rely solely on the on-demand model. Among them many start-ups may exist as our example start-up company.
Resources:
  1. Watch the wave Blog: DZ Bank using the hybrid cloud and on-premise solution
  2. SAP Community Network: What is a cloud and on-premise hybrid solution by SAP?
  3. SearchCloudApplications: On-premises vs SaaS: Making the choice
  4. CrownPeak Whitepaper: On-premise versus cloud
  5. TechRepublic Blog: Comparing cloud to on-premise CRM: Choosing a solution
  6. E3 magazine: Cloud Services und Mobility
  7. ERP Software Blog: Cloud vs. On-Premise ERP – Iighing the Pros and Cons
  8. SAP Community Network: OnDemand to OnPremise Connectivity for SAP Cloud Solution Integration
  9. Nitman Software Whitepaper: SaaS vs. On-Premise Deployment
  10. HarrisData Blog: Reliability of Cloud vs On-Premises Software
  11. HarrisData Blog: Cloud Reliability Stumbles
  12. SoftwareAdvice: The Downtime Dilemma: Reliability in the Cloud
  13. SAP Developer Network: SAP NetWeaver Cloud Connectivity Service - Security Whitepaper
  14. SAP Community Network: What is a cloud and on-premise hybrid solution by SAP?
  15. Saugatuck Technology, 2012 Cloud Business Solution Survey, Global, N-228 (Feb 2012)
  • SAP Managed Tags:
9 Comments