In our latest ASUG Asks the Authors feature, we continue our conversation with Gairik Acharya, senior architect at the IBM SAP S/4HANA Center of Excellence group in North America, and a senior technical architect and associate partner at IBM with 22+ years of IT experience; Govind Bajaj, an SAP business intelligence solution architect with 15+ years of IT experience; Avijit Dhar, a senior consultant at IBM India with 15+ years of experience leading the design and implementation of large-scale implementations, including in the SAP manufacturing domain; Dr. Anup Ghosh, an SAP chief technology officer at IBM Services Europe and director of enterprise application for the IBM Cloud Solution Center; and Asidhara Lahiri, an enterprise architect at SAP with 22+ years of experience with SAP technologies.
Acharya, Bajaj, Dhar, Ghosh, and Lahiri are the co-authors of “Application Development with SAP Business Technology Platform,” a recent SAP Press book that guides readers through building cloud applications on SAP BTP by presenting step-by-step examples for developing and operating applications, detailed code examples, and a big-picture perspective on the pace of change for SAP BTP’s development environments.
In this second part of our conversation, we discuss the book’s four sections and the importance of crafting an accessible introduction to a complex technology landscape.
Q: Writing about a unified business technology platform gives you plenty of ground to cover. What was your approach to organizing this exploration of SAP BTP and its development environments?
Dhar: The book we wrote last time was on SAP Cloud Platform, now SAP BTP. One of the main challenges with writing this type of book is that the offering changes quickly; you have shorter time periods between updates, with features and functionalities changing every quarter or every six months. First, we had to identify all the areas we did not cover before but are becoming popular: workflow management, robotic process automation, the SAP Fiori area, Kyma runtime, and low code/no code.
SAP BTP currently offers 90+ services, so we distributed it into categories like UX, integration, AI, intelligent automation, and so on. Gairik focused on the Fiori part and the SAP Cloud Application Programming Model. I focused on AI, SAP Build Apps, and the Internet of Things (IoT). Asidhara focused on the workflow management part. This book covers the theoretical side of application development with SAP BTP, but we also did a lot of solution development and proofs of concept so that readers will not only understand the concept but will be able to have a foundation set for them, so they can build intelligent solutions on their own sides.
Lahiri: To create the table of contents was challenging because even though it was supposed to be the second edition of “SAP Cloud Platform: Cloud-Native Development,” we could not use that table of contents at all. BTP has different pillars, so we structured our thoughts around that. We needed development and operations aspects. We tried to include architecture and design principles because, outside of all the tutorials, you need to know how it ties together. We wanted to provide that big picture for the architects, developers, and project managers.
Q: In the book’s first part, “Getting Started,” you discuss options for developing custom extensions, microservice architectures, and the different extensibility capabilities provided by SAP BTP. Its second part, “Backend and Frontend Cloud Application Development,” covers SAP Business Application Studio, SAP Cloud Application Programming model, Node.js, Java, ABAP, serverless technology, and SAP Fiori. Can you discuss the decision to open your book with these sections?
Acharya: We wanted to highlight the “openness” of BTP in that first section. BTP is not only SAP-centric. It’s more open, and it’s more API-driven. That’s one of the key criteria. And the second part is that people need to understand the architecture first, within BTP and its individual pieces. I consider BTP a platform with many moving pieces, but if I focus on Cloud Application Programming or ABAP, these pieces have their own architectures. If we do not start from the basic foundation, readers will be lost when we detail those in the next sections. We wanted to start with the concept of architecture and provide the options SAP is now open to providing—the microservice architectures and the different tools that come with them.
Lahiri: The world is made up of developers and non-developers. Today, so many people do not have an ABAP background or come from a Java background, and they’re trying to get into the SAP space. We need them to understand BTP because all these different containerizations are not easy to grasp. The way we’ve structured it, both developers and non-developers will understand.
Q: Part III dives into “Operating Applications,” exploring the importance of end-to-end ALM, IT security, and continuous monitoring of custom functionalities. I appreciated this attention to the importance of ongoing innovation and engagement after implementation. How did you approach writing this section?
Lahiri: It is completely an agile world now. We cannot say, “OK, I have created this application, and that’s it.” We have to continuously say, “OK, this is the first version of it. Try it out, and then we will add on features.” Other companies are also following this method. If you do this iterative feature inclusion, you have to understand that “design, develop, deploy” is not enough. You also have to ensure that this can happen fast, that the operation is seamless because whatever I’m additionally developing is impacting a live application. It’s much more challenging, and that’s why we brought in the DevOps concept. This concept has been in the SAP ecosystem since 2017 when some of us tried to determine how to do DevOps in an SAP environment for the first time. When we talk about DevOps strategy for an SAP-centric client, it’s still a challenge because it’s a hybrid environment and so many tools are still missing.
From an operations point of view, we’ve tried to show our readers what needs to be done. Perhaps you don't have all the tools in place, or not all the tools are integrated together, but here is theoretically what you need to do when those tools do come in. A multitude of tools will assist you with DevOps, but you can plan for it when you are doing the implementation, not later on. Similarly, proactive work is required for additional feature development. It’s all continuous, and to pursue continuous improvement, you have to enable those tools as well.
Ghosh: This is a great example of those less transient principles behind application development remaining constant. We defined all of the characteristics of a DevOps across the different six Cs—continuous business planning, collaborative development, continuous testing, continuous release and deployment, continuous monitoring, and collaborative customer feedback and optimization—and those of us in the SAP environment found that even the way the ABAP development environment had been set up decades earlier already checked off many of the DevOps requirements. It had integrated continuous integration and continuous deployment (CI/CD) in a form that was not being used in the custom world at that point in time.
As we stepped into 2017 and did DevOps at SAP, we were trying to see if we could implement the same approach, leveraging the other products available in the outside world to bring SAP and non-SAP stories together. That’s where we faced challenges. Conceptually, it was there. Some variations came in, and the way it got instantiated changed, and we’ll continue to see change there. But the principles are less transient than the implementations.
Lahiri: Not all the products are ready today. If you think of Cloud ALM, it still has to complete that journey. SAP Solution Manager is much more mature, though it will still go through additional improvements, and Cloud ALM will have its own journey toward maturity and support.
Q: Finally, Part IV, “Intelligent Technologies,” brings the book full circle, focusing on easy low-code orchestration and visibility of work via SAP Workflow Management, rule-based variations in processes, IoT, automation via SAP Intelligent RPA, SAP Conversational AI, and SAP Data Intelligence. What can you share about the research that went into crafting this section of the book, and what major takeaways do you want readers to have related to intelligent technologies?
Dhar: “Intelligent Technologies” is one of my favorite sections. It will make the readers more interested in the book because we have written it in such a way that we are not only targeting the pro-code developers or full-stack developers. We are also focusing on citizen developers. When you are talking about a cloud platform, you cannot address a specific segment of readers who are only working on specific technologies. Companies are trying to transform their workforces. They had been focusing on the functional parts of their jobs. Now, they are also willing to leverage the workforce in building intelligent applications.
A combination of these intelligent technologies, such as RPA and IoT, offers the flexibility to build intelligent enterprise solutions in a way where citizen developers, as well as pro-code developers, can contribute significantly and build applications within a short period of time. Workflow management is now a more popular topic across enterprises, and operation automation is a key focus. Using SAP Workflow Management (and a combination of RPA or SAP Build Process Automation), you can quickly create intelligent automation or introduce automation across your business operations.
Readers can not only learn about this but leverage it to build real use cases. In each of these chapters, we have prominently explained the concepts by giving real examples, which I think is not only going to help them to understand the concepts but will also help them learn how to do the coding or how to build solutions without even writing code.
Ghosh: The shape of custom development, as we defined it in the past, has changed. It is not always about developing. It could be composing things using whatever is available out there. Outside of these products, you want technologies that facilitate not only human interactions but interactions with things. Intelligent technologies really are about bringing differentiation and meeting individual business needs. We wanted to cover intelligent technologies because anything you are developing or composing to provide differentiation to the customer is part of what we wanted to include.
Dhar: And the use cases we include are enterprise-driven or based on use cases we have addressed in many past implementations where clients have expressed business problems, and we’ve addressed them by leveraging BTP. Out of these use cases, readers will be able to relate them to challenges they have in their domains and determine how they can leverage BTP to address those challenges.
Q: Any parting thoughts for ASUG members to consider?
Acharya: SAP customers are going to use BTP, one way or another. It’s not just about a platform. SAP will build its own solutions on top of BTP. Even if some customers may not use BTP as a platform, they are going to use the services running on BTP. That’s for sure. In the future, we are going to see that more. There will be more native integrations with the hyperscaler clouds.
For example, we have API-level or application-level integrations, but what about infrastructure-level integrations? The question came from a customer who running all other services on Amazon Web Services (AWS) and that their BTP was also running on AWS, but these were two different accounts. How can they natively integrate that so that they can monitor them together as an administrator? There is a virtual link from SAP, which makes it possible to integrate BTP and AWS or Azure.
What we have written will get readers to think in a different way. They can think about it with a top-down or bottom-up approach. If they have a specific use case or extension scenario, they can think about how different BTP components will play and interact with each other, which is a top-down approach. Or they can think of a simple use case that is not real and then add additional services on top of it to enrich it, which is a bottom-up analysis. This book talks about so many options and customer use cases, and so this book will also help readers to derive and define the decision criteria, metrics, and trees needed for their live projects.