Landscape simplification through SAP BTP services

In this blog post, I share my view on how adopting the SAP Business Technology Platform (BTP) can simplify our landscapes, the way we develop software, and focus on what matters most…. delivering solutions that solve business problems. I start by discussing the problem we commonly face, followed by how we can tackle it. 

Thanks to my friends Cesar Rodriguez, who provided feedback and shared an article that influenced this blog post… InfoWorld – Complexity is killing software developers, and Monica Carrero for reviewing and contributing to this blog post.

Simplified landscape using SAP BTP services

Being a software developer is not easy nowadays. Especially when a new business requirement is raised… a new service/application is required and it is time to choose which technologies to use to meet this requirement. As a developer you don’t just have to worry about developing the service, but you also have to think about security, where the data will reside, how to make the data accessible for reporting, the service/application’s maintenance, the hardware that might be needed to deploy the service, among many other aspects required to deliver enterprise-ready software. There is a plethora of options when it comes to the technologies that we can use to develop our services. Be it an integration, a backend service, mobile app, web app… there are many programming languages, databases, frameworks, tools available at the developer’s disposal to achieve it. If there is no proper enterprise architecture practice in place, that can clearly define development guidelines, we can end up with a humongous amount of different technologies used across the enterprise. Adding unnecessary complexity, that ends up increasing the maintenance costs because of the different technology solutions implemented.

In this day and age, it is quite common to follow a microservices architecture and having various development teams across an enterprise. Generally each team is able to select the best technology to tackle the problem in hand. These enables teams to move, develop and scale fast. That can be ok in the short term but what can happen in the long run… especially when there is no guideline? With no architecture guidelines, in the long run we can end up with teams using different types of databases, languages, tools to solve specific problems. The paradox of choice, having way too many technology options can be counterproductive. Also, we can run the risk of teams following a “resume driven development” approach… selecting a technology to work on a project in order to build a nice resume. All these different technologies can lead to a fragmented software ecosystem within the enterprise, therefore increasing the complexity of our landscape, impacting our ability to scale and backfiring the original purpose of such approach.

How can SAP BTP services simplify our landscape and developments?

Now that we know the problems that an enterprise can face when having no guidelines and too many technologies in their landscape… Below, I provide some examples of how various aspects/components of an enterprise landscape can be simplified by leveraging different managed services available in SAP BTP.

Development

The SAP Cloud Application Programming Model (CAP) is a framework of languages, libraries, and tools for building enterprise-grade services and applications. It guides developers along a “golden path” of proven best practices and a great wealth of out-of-the-box solutions to recurring tasks. CAP simplifies how we can create services and applications, as it provides an opinionated way on developing these. We can develop our services using two programming languages, Node.js or Java. For example, following CAP, a developer can easily provide support for SAP Fiori Elements frontends (a Fiori app can be included within a project), create an API (OData), interact with a database (SAP HANA Cloud), other SAP BTP services and deploy this to SAP BTP (Cloud Foundry). We go from selecting between multiple programming languages, API styles, web frameworks to following an approach that helps you get things done. Note: CAP is opinionated but open at the same time. You can always customise it to your needs.

To learn more about the importance and value of OData in the SAP ecosystem, check out this blog post.

Deployment

A continuous integration and continuous delivery practice (CI/CD) is important to ensure reliable deliveries of the services we create/update. Predefined CI/CD pipelines, part of SAP Continuous Integration and Delivery service and/or Project Piper, are available to support the CI/CD process of the application/service(s) that you can deploy in the different SAP BTP runtimes (Cloud Foundry, Kyma, ABAP). It is possible to transition from manual to automated deployments when following a CI/CD practice, increasing the quality and speed of our deliveries.

Databases

If our services use a relational database (PostgreSQL, MySQL, SQLite), document database (MongoDB, CouchDB), or a graph database (Neo4j) as a backend, all these different data models can be consolidated in a single multi-model cloud database service like SAP HANA Cloud. We will go from dealing with multiple database technologies to a single database technology in our landscape. The data will be accessible from a single place, which simplifies the reporting needs that we might have.

Integrations

Integration between applications/systems is critical too many enterprises. Instead of coding point-to-point integrations, we can use an integration platform, e.g. SAP Integration Suite, to develop them. Having an integration platform will speed up how an enterprise develops/runs integrations in their landscape. Also, it can take advantage of pre-packaged content that can be imported in the integration platform to cover common integration scenarios between existing applications in the landscape. To guarantee delivery of these integrations, the integration artifacts can also be part of our CI/CD practices. We can transition from having many integration services running on their own with little governance/monitoring to following best practice enterprise integration patterns to develop and having a central place to develop/manage them.

Monitoring

It is important understand how our applications/services are being used. For this, we need to have proper monitoring/logging of them. By using different SAP BTP services we capture, measure and monitor how applicaitons/services are performing across our landscape. To achieve this we can capture the logs generated by the applications/services deployed by using a service like Application Logging. We can raise alerts when our services are not performing as expected. Also, these data can be used to optimise the resources used by our services. From an integration perspective, an integration platform can provide a central place to monitor how integrations are running within the enterprise.

Reporting

In the development section above I mentioned CAP services. By default, CAP services expose their data via OData. We can report on the data available via an OData service by using a reporting service like SAP Analytics Cloud. Which means that we can automagically report on all the data that we create via the CAP services we develop. We can even report the monitoring KPIs of the platform in SAP Analytics Cloud dashboard available out-of-the-box. Apart from this, we can also connect our single database service, SAP HANA Cloud, to SAP Analytics Cloud and create reports/stories on the data available. We make the data accessible to create reports that can be consumed by the right people at the right time to support the operation that are essential in our enterprise.

User Interfaces

If we expose OData services, it is possible to easily create/generate user interfaces from these services. Following a low-code approach using SAP Business Application Studio, we can create an SAP Fiori Elements app by reading the metadata exposed by the OData service and generate UIs to maintain the data. A no-code tool, such as SAP AppGyver, can communicate with an OData service and create a mobile/web application for it without the need of any code. We can go from having many different UI designs in our applications to having a consistent look and feel across them by following the SAP Fiori design language. Also, they can all be accessible from a single place, e.g. SAP Launchpad service.

I hope this blog post shed some light on how SAP BTP services can simplify an enterprise landscape. Although I’ve only scratched the surface here and don’t cover many of the different services available in SAP BTP, e.g. security, intelligent technologies, that can further enable enterprises to reduce the complexity of how they operate.  When we remove the need to make complex architectural/development decisions every time we need to develop/create a new application/service, we can focus on the solution. We can leverage a managed service to take care of the heavy lifting and focus on delivering business value. This is what we should be striving for as developers.