About the Author
James Wood, is the Principal Consultant of
Bowdark Consulting, where his work domain
includes being an architect and technologist in
the enterprise software space. He has expertise
in the development of custom software solutions
using cloud-native, SAP, and Microsoft-based
technologies. James’ extracurricular activities
include blogging, writing, working with the SAP
Mentor Community, and technology research.
James Wood
manage hybrid landscapes which combine on-premise
systems with cloud-based systems. Whether these systems
are provided by SAP or another vendor is largely
immaterial since these systems are built using different
technologies. For SAP developers, it’s not like the old days
where everything was built on ABAP. Plus, when it comes
to cloud-based solutions, developers are usually restricted
from making changes anyway, so whatever programming
language is used underneath the hood doesn’t really matter.
Innovating Around the Edges
More and more, companies are starting to realize that the
safest bet for building new solutions is to move towards a
centralized (and separate) cloud platform like the SAP
Cloud Platform. Here, rather than using proprietary
technologies like ABAP to customize solutions, innovation
takes place around the edges with extension apps that
access application functionality through well-defined
RESTful interfaces (e.g. OData). This design-by-contract
approach to extension app development simplifies the
design and offers lots of long-term flexibility.
To appreciate these differences, consider a typical web app
built on SAP’s SAPUI5 framework (i.e. the toolkit used to
create Fiori apps). If this app was developed on-premise,
the basic component architecture would look something
like what you see on the left-hand side of the figure below.
Here, the front-end server is a standalone instance of SAP
Gateway and the back-end server might be SAP S/4 HANA
or an older SAP Business Suite system.
Now, let’s imagine that the app is so successful that the
business wants to be able to access the app in different
| JULY 2017
ways. Here, there might be a desire to access the app on
mobile devices/tablets. Or, perhaps the business wants to
share this app with business partners via a self-service
portal. In a traditional on-premise scenario, these might be
difficult requirements to address due to a variety of
restrictions around change management, hardware
procurement/installation, and so forth.
The diagram on the right-hand side of the figure above
shows how moving the app to SAP Cloud Platform changes
this scenario quite a bit. In this case, data is still securely
accessed via the SAP Cloud Connector component, but the
app is hosted in an environment that offers all the services
needed to expose the app to mobile devices, self-service
portals, and more. Plus, the IT infrastructure team no longer
has to worry about maintaining the front-end server or
ancillary servers that might be needed.
Outlook
The examples described here barely scratch the surface of
what’s possible with centralized PaaS solutions like SAP
Cloud Platform. The point in all this though is that the only
way to keep pace with digital transformation demands is to
provide developers with an environment that allows them to
focus squarely on solving business problems and get out of
the business of worrying about mundane proprietary details,
environmental/scaling issues, and so forth.
This trend is not unique to SAP; you see it across the
industry with other major vendors moving towards cloud-
native designs. The benefits in terms of scalability and
flexibility are too great to ignore, so we see this as a trend
that’s here to stay. So, the next time you’re thinking about
building a new app, maybe it’s time to see what SAP Cloud
Platform can do to transfor