In our lat­est ASUG Asks the Authors fea­ture, we con­tin­ue our con­ver­sa­tion with Gairik Acharya, senior archi­tect at the IBM SAP S/4HANA Cen­ter of Excel­lence group in North Amer­i­ca, and a senior tech­ni­cal archi­tect and asso­ciate part­ner at IBM with 22+ years of IT expe­ri­ence; Govind Bajaj, an SAP busi­ness intel­li­gence solu­tion archi­tect with 15+ years of IT expe­ri­ence; Avi­jit Dhar, a senior con­sul­tant at IBM India with 15+ years of expe­ri­ence lead­ing the design and imple­men­ta­tion of large-scale imple­men­ta­tions, includ­ing in the SAP man­u­fac­tur­ing domain; Dr. Anup Ghosh, an SAP chief tech­nol­o­gy offi­cer at IBM Ser­vices Europe and direc­tor of enter­prise appli­ca­tion for the IBM Cloud Solu­tion Cen­ter; and Asid­hara Lahiri, an enter­prise archi­tect at SAP with 22+ years of expe­ri­ence with SAP technologies.

Acharya, Bajaj, Dhar, Ghosh, and Lahiri are the co-authors of ​“Appli­ca­tion Devel­op­ment with SAP Busi­ness Tech­nol­o­gy Plat­form,” a recent SAP Press book that guides read­ers through build­ing cloud appli­ca­tions on SAP BTP by pre­sent­ing step-by-step exam­ples for devel­op­ing and oper­at­ing appli­ca­tions, detailed code exam­ples, and a big-pic­ture per­spec­tive on the pace of change for SAP BTP’s devel­op­ment environments. 

In this sec­ond part of our con­ver­sa­tion, we dis­cuss the book’s four sec­tions and the impor­tance of craft­ing an acces­si­ble intro­duc­tion to a com­plex tech­nol­o­gy landscape.

Q: Writ­ing about a uni­fied busi­ness tech­nol­o­gy plat­form gives you plen­ty of ground to cov­er. What was your approach to orga­niz­ing this explo­ration of SAP BTP and its devel­op­ment environments? 

Dhar: The book we wrote last time was on SAP Cloud Plat­form, now SAP BTP. One of the main chal­lenges with writ­ing this type of book is that the offer­ing changes quick­ly; you have short­er time peri­ods between updates, with fea­tures and func­tion­al­i­ties chang­ing every quar­ter or every six months. First, we had to iden­ti­fy all the areas we did not cov­er before but are becom­ing pop­u­lar: work­flow man­age­ment, robot­ic process automa­tion, the SAP Fiori area, Kyma run­time, and low code/​no code. 

SAP BTP cur­rent­ly offers 90+ ser­vices, so we dis­trib­uted it into cat­e­gories like UX, inte­gra­tion, AI, intel­li­gent automa­tion, and so on. Gairik focused on the Fiori part and the SAP Cloud Appli­ca­tion Pro­gram­ming Mod­el. I focused on AI, SAP Build Apps, and the Inter­net of Things (IoT). Asid­hara focused on the work­flow man­age­ment part. This book cov­ers the the­o­ret­i­cal side of appli­ca­tion devel­op­ment with SAP BTP, but we also did a lot of solu­tion devel­op­ment and proofs of con­cept so that read­ers will not only under­stand the con­cept but will be able to have a foun­da­tion set for them, so they can build intel­li­gent solu­tions on their own sides.

Lahiri: To cre­ate the table of con­tents was chal­leng­ing because even though it was sup­posed to be the sec­ond edi­tion of ​“SAP Cloud Plat­form: Cloud-Native Devel­op­ment,” we could not use that table of con­tents at all. BTP has dif­fer­ent pil­lars, so we struc­tured our thoughts around that. We need­ed devel­op­ment and oper­a­tions aspects. We tried to include archi­tec­ture and design prin­ci­ples because, out­side of all the tuto­ri­als, you need to know how it ties togeth­er. We want­ed to pro­vide that big pic­ture for the archi­tects, devel­op­ers, and project managers. 

Q: In the book’s first part, ​“Get­ting Start­ed,” you dis­cuss options for devel­op­ing cus­tom exten­sions, microser­vice archi­tec­tures, and the dif­fer­ent exten­si­bil­i­ty capa­bil­i­ties pro­vid­ed by SAP BTP. Its sec­ond part, ​“Back­end and Fron­tend Cloud Appli­ca­tion Devel­op­ment,” cov­ers SAP Busi­ness Appli­ca­tion Stu­dio, SAP Cloud Appli­ca­tion Pro­gram­ming mod­el, Node.js, Java, ABAP, server­less tech­nol­o­gy, and SAP Fiori. Can you dis­cuss the deci­sion to open your book with these sections?

Acharya: We want­ed to high­light the ​“open­ness” of BTP in that first sec­tion. BTP is not only SAP-cen­tric. It’s more open, and it’s more API-dri­ven. That’s one of the key cri­te­ria. And the sec­ond part is that peo­ple need to under­stand the archi­tec­ture first, with­in BTP and its indi­vid­ual pieces. I con­sid­er BTP a plat­form with many mov­ing pieces, but if I focus on Cloud Appli­ca­tion Pro­gram­ming or ABAP, these pieces have their own archi­tec­tures. If we do not start from the basic foun­da­tion, read­ers will be lost when we detail those in the next sec­tions. We want­ed to start with the con­cept of archi­tec­ture and pro­vide the options SAP is now open to pro­vid­ing — the microser­vice archi­tec­tures and the dif­fer­ent tools that come with them. 

Lahiri: The world is made up of devel­op­ers and non-devel­op­ers. Today, so many peo­ple do not have an ABAP back­ground or come from a Java back­ground, and they’re try­ing to get into the SAP space. We need them to under­stand BTP because all these dif­fer­ent con­tainer­iza­tions are not easy to grasp. The way we’ve struc­tured it, both devel­op­ers and non-devel­op­ers will understand.

Q: Part III dives into ​“Oper­at­ing Appli­ca­tions,” explor­ing the impor­tance of end-to-end ALM, IT secu­ri­ty, and con­tin­u­ous mon­i­tor­ing of cus­tom func­tion­al­i­ties. I appre­ci­at­ed this atten­tion to the impor­tance of ongo­ing inno­va­tion and engage­ment after imple­men­ta­tion. How did you approach writ­ing this section?

Lahiri: It is com­plete­ly an agile world now. We can­not say, ​“OK, I have cre­at­ed this appli­ca­tion, and that’s it.” We have to con­tin­u­ous­ly say, ​“OK, this is the first ver­sion of it. Try it out, and then we will add on fea­tures.” Oth­er com­pa­nies are also fol­low­ing this method. If you do this iter­a­tive fea­ture inclu­sion, you have to under­stand that ​“design, devel­op, deploy” is not enough. You also have to ensure that this can hap­pen fast, that the oper­a­tion is seam­less because what­ev­er I’m addi­tion­al­ly devel­op­ing is impact­ing a live appli­ca­tion. It’s much more chal­leng­ing, and that’s why we brought in the DevOps con­cept. This con­cept has been in the SAP ecosys­tem since 2017 when some of us tried to deter­mine how to do DevOps in an SAP envi­ron­ment for the first time. When we talk about DevOps strat­e­gy for an SAP-cen­tric client, it’s still a chal­lenge because it’s a hybrid envi­ron­ment and so many tools are still missing. 

From an oper­a­tions point of view, we’ve tried to show our read­ers what needs to be done. Per­haps you don’t have all the tools in place, or not all the tools are inte­grat­ed togeth­er, but here is the­o­ret­i­cal­ly what you need to do when those tools do come in. A mul­ti­tude of tools will assist you with DevOps, but you can plan for it when you are doing the imple­men­ta­tion, not lat­er on. Sim­i­lar­ly, proac­tive work is required for addi­tion­al fea­ture devel­op­ment. It’s all con­tin­u­ous, and to pur­sue con­tin­u­ous improve­ment, you have to enable those tools as well.

Ghosh: This is a great exam­ple of those less tran­sient prin­ci­ples behind appli­ca­tion devel­op­ment remain­ing con­stant. We defined all of the char­ac­ter­is­tics of a DevOps across the dif­fer­ent six Cs — con­tin­u­ous busi­ness plan­ning, col­lab­o­ra­tive devel­op­ment, con­tin­u­ous test­ing, con­tin­u­ous release and deploy­ment, con­tin­u­ous mon­i­tor­ing, and col­lab­o­ra­tive cus­tomer feed­back and opti­miza­tion — and those of us in the SAP envi­ron­ment found that even the way the ABAP devel­op­ment envi­ron­ment had been set up decades ear­li­er already checked off many of the DevOps require­ments. It had inte­grat­ed con­tin­u­ous inte­gra­tion and con­tin­u­ous deploy­ment (CI/CD) in a form that was not being used in the cus­tom world at that point in time. 

As we stepped into 2017 and did DevOps at SAP, we were try­ing to see if we could imple­ment the same approach, lever­ag­ing the oth­er prod­ucts avail­able in the out­side world to bring SAP and non-SAP sto­ries togeth­er. That’s where we faced chal­lenges. Con­cep­tu­al­ly, it was there. Some vari­a­tions came in, and the way it got instan­ti­at­ed changed, and we’ll con­tin­ue to see change there. But the prin­ci­ples are less tran­sient than the implementations. 

Lahiri: Not all the prod­ucts are ready today. If you think of Cloud ALM, it still has to com­plete that jour­ney. SAP Solu­tion Man­ag­er is much more mature, though it will still go through addi­tion­al improve­ments, and Cloud ALM will have its own jour­ney toward matu­ri­ty and support.

Q: Final­ly, Part IV, ​“Intel­li­gent Tech­nolo­gies,” brings the book full cir­cle, focus­ing on easy low-code orches­tra­tion and vis­i­bil­i­ty of work via SAP Work­flow Man­age­ment, rule-based vari­a­tions in process­es, IoT, automa­tion via SAP Intel­li­gent RPA, SAP Con­ver­sa­tion­al AI, and SAP Data Intel­li­gence. What can you share about the research that went into craft­ing this sec­tion of the book, and what major take­aways do you want read­ers to have relat­ed to intel­li­gent technologies? 

Dhar: ​“Intel­li­gent Tech­nolo­gies” is one of my favorite sec­tions. It will make the read­ers more inter­est­ed in the book because we have writ­ten it in such a way that we are not only tar­get­ing the pro-code devel­op­ers or full-stack devel­op­ers. We are also focus­ing on cit­i­zen devel­op­ers. When you are talk­ing about a cloud plat­form, you can­not address a spe­cif­ic seg­ment of read­ers who are only work­ing on spe­cif­ic tech­nolo­gies. Com­pa­nies are try­ing to trans­form their work­forces. They had been focus­ing on the func­tion­al parts of their jobs. Now, they are also will­ing to lever­age the work­force in build­ing intel­li­gent applications. 

A com­bi­na­tion of these intel­li­gent tech­nolo­gies, such as RPA and IoT, offers the flex­i­bil­i­ty to build intel­li­gent enter­prise solu­tions in a way where cit­i­zen devel­op­ers, as well as pro-code devel­op­ers, can con­tribute sig­nif­i­cant­ly and build appli­ca­tions with­in a short peri­od of time. Work­flow man­age­ment is now a more pop­u­lar top­ic across enter­pris­es, and oper­a­tion automa­tion is a key focus. Using SAP Work­flow Man­age­ment (and a com­bi­na­tion of RPA or SAP Build Process Automa­tion), you can quick­ly cre­ate intel­li­gent automa­tion or intro­duce automa­tion across your busi­ness operations. 

Read­ers can not only learn about this but lever­age it to build real use cas­es. In each of these chap­ters, we have promi­nent­ly explained the con­cepts by giv­ing real exam­ples, which I think is not only going to help them to under­stand the con­cepts but will also help them learn how to do the cod­ing or how to build solu­tions with­out even writ­ing code. 

Ghosh: The shape of cus­tom devel­op­ment, as we defined it in the past, has changed. It is not always about devel­op­ing. It could be com­pos­ing things using what­ev­er is avail­able out there. Out­side of these prod­ucts, you want tech­nolo­gies that facil­i­tate not only human inter­ac­tions but inter­ac­tions with things. Intel­li­gent tech­nolo­gies real­ly are about bring­ing dif­fer­en­ti­a­tion and meet­ing indi­vid­ual busi­ness needs. We want­ed to cov­er intel­li­gent tech­nolo­gies because any­thing you are devel­op­ing or com­pos­ing to pro­vide dif­fer­en­ti­a­tion to the cus­tomer is part of what we want­ed to include.

Dhar: And the use cas­es we include are enter­prise-dri­ven or based on use cas­es we have addressed in many past imple­men­ta­tions where clients have expressed busi­ness prob­lems, and we’ve addressed them by lever­ag­ing BTP. Out of these use cas­es, read­ers will be able to relate them to chal­lenges they have in their domains and deter­mine how they can lever­age BTP to address those challenges. 

Q: Any part­ing thoughts for ASUG mem­bers to consider?

Acharya: SAP cus­tomers are going to use BTP, one way or anoth­er. It’s not just about a plat­form. SAP will build its own solu­tions on top of BTP. Even if some cus­tomers may not use BTP as a plat­form, they are going to use the ser­vices run­ning on BTP. That’s for sure. In the future, we are going to see that more. There will be more native inte­gra­tions with the hyper­scaler clouds. 

For exam­ple, we have API-lev­el or appli­ca­tion-lev­el inte­gra­tions, but what about infra­struc­ture-lev­el inte­gra­tions? The ques­tion came from a cus­tomer who run­ning all oth­er ser­vices on Ama­zon Web Ser­vices (AWS) and that their BTP was also run­ning on AWS, but these were two dif­fer­ent accounts. How can they native­ly inte­grate that so that they can mon­i­tor them togeth­er as an admin­is­tra­tor? There is a vir­tu­al link from SAP, which makes it pos­si­ble to inte­grate BTP and AWS or Azure.

What we have writ­ten will get read­ers to think in a dif­fer­ent way. They can think about it with a top-down or bot­tom-up approach. If they have a spe­cif­ic use case or exten­sion sce­nario, they can think about how dif­fer­ent BTP com­po­nents will play and inter­act with each oth­er, which is a top-down approach. Or they can think of a sim­ple use case that is not real and then add addi­tion­al ser­vices on top of it to enrich it, which is a bot­tom-up analy­sis. This book talks about so many options and cus­tomer use cas­es, and so this book will also help read­ers to derive and define the deci­sion cri­te­ria, met­rics, and trees need­ed for their live projects.

“Appli­ca­tion Devel­op­ment with SAP Busi­ness Tech­nol­o­gy Plat­form” is now avail­able from SAP Press.