As com­pa­nies’ process­es and sys­tem land­scapes have become high­ly com­plex in recent years, suc­ceed­ing with busi­ness trans­for­ma­tion has increas­ing­ly required busi­ness and IT lead­ers to seek deep­er vis­i­bil­i­ty into exist­ing busi­ness capa­bil­i­ties and the tech­nol­o­gy archi­tec­ture that will be required to evolve those capa­bil­i­ties in accor­dance with the organization’s strate­gic goals.

Giv­en this, as com­pa­nies seek to align busi­ness strate­gies with IT exe­cu­tion, the role of the enter­prise archi­tect is tak­ing on greater impor­tance across the SAP ecosys­tem. In addi­tion to cre­at­ing the SAP Enter­prise Archi­tec­ture Frame­work — a struc­tured method­ol­o­gy and tools intend­ed to help enter­prise archi­tects to plan, design, and imple­ment an EA prac­tice with­in an SAP envi­ron­ment — SAP is work­ing to embed enter­prise archi­tects with­in the ser­vices it offers to on-premis­es users mov­ing to the cloud, posi­tion­ing them as ded­i­cat­ed CTOs for cus­tomers who are cur­rent­ly pur­su­ing SAP S/4HANA cloud trans­for­ma­tion via RISE with SAP. 

With devel­op­ing mature, suc­cess­ful enter­prise archi­tec­ture func­tions now a grow­ing pri­or­i­ty for orga­ni­za­tions in this ecosys­tem, busi­ness pro­fes­sion­als every­where are keen to explore SAP’s EA tools and frame­work, to inte­grate AI and opti­mize process­es, and to devel­op future-ready prac­tices with SAP solu­tions by expand­ing their knowl­edge of this emerg­ing field. (For more insights into all these top­ics, read ​“Forces of Change: How SAP Enter­prise Archi­tects Can Pre­pare for the Next Gen­er­a­tion.”)

Cur­rent­ly the best­selling pub­li­ca­tion from SAP Press, Enter­prise Archi­tec­ture with SAP: Plan­ning, Man­age­ment, and Transformation sets forth a strate­gic roadmap for enter­prise archi­tects to fol­low, pro­vid­ing prac­ti­cal use cas­es and exam­ples of archi­tec­ture design pat­tern imple­men­ta­tion that can help read­ers estab­lish their own enter­prise archi­tec­ture practices. 

With decades of com­bined expe­ri­ence in the field, co-authors Peter Klee, Anup Das, and Johannes Reichel approached this pub­li­ca­tion as an oppor­tu­ni­ty to illu­mi­nate the cross-orga­ni­za­tion­al col­lab­o­ra­tion that enter­prise archi­tects are unique­ly well-suit­ed to facilitate. 

Das is a chief enter­prise archi­tect and the region­al deliv­ery head for the SAP Trans­for­ma­tion Hub in North Amer­i­ca. Klee leads the SAP Trans­for­ma­tion Hub with­in SAP’s Cus­tomer Ser­vices & Deliv­ery board area, over­see­ing a glob­al group of enter­prise archi­tects who sup­port SAP Max­At­ten­tion cus­tomers with archi­tec­ture plan­ning ser­vices. Reichel is a prin­ci­pal enter­prise archi­tect with­in SAP Trans­for­ma­tion Hub, focus­ing on glob­al trans­for­ma­tion and archi­tec­ture plan­ning for SAP clients.

At the Next Gen­er­a­tion SAP Enter­prise Archi­tect Learn­ing Forum, host­ed at SAP’s North Amer­i­can head­quar­ters in New­town Square, Penn­syl­va­nia, ear­li­er this year, ASUG sat down with all three authors to dis­cuss the evolv­ing role of the enter­prise archi­tect in SAP landscapes.

Respons­es have been edit­ed for length and clarity. 

What was your moti­va­tion for writ­ing this book, and what audi­ence did you have in mind?

Peter Klee: Tech­nol­o­gy is trans­form­ing, evolv­ing, and grow­ing more com­plex. In the past, frame­works like The Open Group Archi­tec­ture Frame­work (TOGAF) have been per­ceived as sta­t­ic, and we believe that enter­prise archi­tec­ture amid trans­for­ma­tion should be more flex­i­ble, so we had ideas around that to explore. With the tools avail­able to EAs also evolv­ing, we want­ed to place those in con­text of a larg­er framework.

Most impor­tant­ly, though, we want­ed to pro­vide guid­ance on how to set up an enter­prise archi­tec­ture prac­tice, so that’s an ele­ment of our frame­work, to over­come those iso­lat­ed EA groups that still exist apart from the sep­a­rat­ed SAP islands. In the end, it’s about demys­ti­fy­ing enter­prise archi­tec­ture. The sub­ti­tle of our book iden­ti­fies three stages of an archi­tec­ture prac­tice: plan­ning, man­age­ment, and trans­for­ma­tion. It’s not just about how you plan a sin­gu­lar tar­get archi­tec­ture; you want to man­age enter­prise archi­tec­ture in your enter­prise in an ongo­ing way, and trans­for­ma­tion involves pre­dic­tion of future needs and a com­par­i­son of dif­fer­ent options of enter­prise archi­tec­ture. Instead of hav­ing one tar­get draw­ing, you need rea­son­ing around dif­fer­ent tran­si­tion options; that is what trans­for­ma­tion entails.

Who is the book for? It’s not only for enter­prise archi­tects but also for SAP pro­fes­sion­als who want to under­stand enter­prise archi­tec­ture bet­ter, to see how dif­fer­ent areas of a busi­ness can work togeth­er. It’s for the C‑suite – those indi­vid­u­als who grew through the ranks and are more tech­ni­cal these days than in the past. Enter­prise archi­tec­ture is a top­ic of inter­est for project man­agers, data man­age­ment prac­ti­tion­ers, process own­ers, pro­cure­ment pro­fes­sion­als, up to finance or cor­po­rate strat­e­gy leads. The ecosys­tem is broad. As an enter­prise archi­tect, you must be aware of that fact and work across it.

Anup Das: Enter­prise archi­tect roles and respon­si­bil­i­ties are fair­ly well-defined, and SAP has par­tic­u­lar­ly estab­lished stan­dards and frame­works to pro­vide for orga­ni­za­tions approach­ing enter­prise archi­tec­ture. And yet, there’s still uncer­tain­ty around the def­i­n­i­tion of the term or the role of the EA, so we want­ed to demys­ti­fy the top­ic from our own experience.

ASUG: EAs can act as a bridge between busi­ness and IT depart­ments, and this is a role rather than a job title in many instances. Tell me about strik­ing that bal­ance between estab­lish­ing method­olo­gies and frame­works that add struc­ture and def­i­n­i­tion to the role of the EA while help­ing busi­ness pro­fes­sion­als to see the ways in which they might be already facil­i­tat­ing EA func­tions at their companies. 

Johannes Reichel: The real­i­ty we see in many com­pa­nies is that they don’t have a so-called enter­prise archi­tec­ture prac­tice. Large cor­po­ra­tions usu­al­ly have them, and those employ­ees will call them­selves enter­prise archi­tects. But, for many cus­tomers, it’s an ​‘in-between’ role. Some­times, they approach the role more from a solu­tion-archi­tect per­spec­tive, where some­one over­sees the whole land­scape. They call them­selves solu­tion archi­tects, but they do — more or less — the jobs of enter­prise architects. 

I think the book can be a great help for some­one in that role who has not yet estab­lished stan­dards and method­olo­gies and is not using tool­ing to estab­lish a more struc­tured way to com­plete their work.

Klee: It’s also not a sin­gle prac­tice. When one says the ​‘holy grail’ involves bridg­ing the gap between IT and all busi­ness units, busi­ness func­tions, and pro­gram and strat­e­gy offices, there are many dimen­sions to link. This is also not done overnight. Some enter­prise archi­tec­ture func­tions are much more tech­ni­cal. We see dif­fer­ent scopes of enter­prise-archi­tec­ture teams at our customers. 

Our approach is holis­tic, and it involves bridg­ing in con­cepts such as busi­ness capa­bil­i­ties and strate­gies. It’s an evo­lu­tion in step by step advanc­ing the matu­ri­ty. But to adopt the same process­es and same approach in-house, that’s a hard­er process, because then it’s also about rear­rang­ing cer­tain align­ment process­es and account­abil­i­ties. This works best if there’s top-down support. 

Reichel: You have to prove that enter­prise archi­tec­ture is help­ful to the orga­ni­za­tion, then you can fur­ther grow the dis­ci­pli­nary prac­tice in your orga­ni­za­tion. You want to avoid the con­no­ta­tion of the ​“ivory tow­er” of peo­ple who draw nice dia­grams but with­out any impact. But if you start with the min­i­mum viable prod­uct, the MVP, of look­ing at one domain and link­ing its tech­nol­o­gy to strat­e­gy, then pre­sent­ing that to busi­ness and IT stake­hold­ers, it’s eas­i­er to demon­strate the advan­tage of estab­lish­ing such a prac­tice. With­out spend­ing hun­dreds of days of effort, instead ded­i­cat­ing a cou­ple of weeks, you can show two stake­hold­ers the results, and they’ll see the val­ue that will allow you to roll it out further.

With one of my cus­tomers, we ran an exer­cise to link strat­e­gy to the busi­ness and solu­tion archi­tec­ture, and as part of this we con­nect­ed the customer’s enter­prise-archi­tect team with the strat­e­gy depart­ment. That was the first time that those two teams talked to each oth­er, and they were amazed by the results. They nev­er had a way to link what we would define as a cor­po­rate strat­e­gy with their archi­tec­ture plan­ning; now, they’ve adopt­ed one of those strat­e­gy-map­ping and busi­ness-capa­bil­i­ty-map­ping mod­ules that we demon­strate in the book. They are using that in their prac­tice now, but we gave them the stim­u­lus to do so from outside. 

Das: When a customer’s trans­for­ma­tion project is in an exe­cu­tion phase, there are so many play­ers: the cus­tomer team, the part­ner and SAP, and then the army of teams march­ing towards the larg­er goal. But they don’t know where they will land. They don’t know the north star of the whole project, because these indi­vid­u­als were not involved in the plan­ning of the tar­get archi­tec­ture. That’s why it’s very impor­tant that they have this pic­ture of where they’re mov­ing toward and how their project will meet the strate­gic pri­or­i­ties of the organization.

ASUG: As SAP seeks to recruit more enter­prise archi­tects to sup­port RISE cus­tomers, where do you see those EAs com­ing from? Are they tech­ni­cal prac­ti­tion­ers gain­ing more insight into the busi­ness, or busi­ness stake­hold­ers gain­ing IT expertise? 

Klee: Both are need­ed. Because if you only get peo­ple from the busi­ness back­ground, then you would have fail­ures when tech­ni­cal scal­a­bil­i­ty ques­tions come up, and they have no clue about that. What also helps is that the SAP EA Method­ol­o­gy builds on what we call arti­facts, which are also often visu­al. The strat­e­gy map is not a bul­let-point list with text, but a sim­ple hier­ar­chy dia­gram. I think these maps can help— as sup­port­ed by tools like SAP LeanIX —to con­vey a mes­sage more eas­i­ly, what­ev­er your abil­i­ty as a sto­ry­teller. When you explain it to the C‑level, visu­als also help to make it more approach­able for both sides, be that the tech­ni­cal folks talk­ing with busi­ness­peo­ple or the busi­ness­peo­ple talk­ing with the tech­ni­cal folks.

Das: It’s not one person’s job. We have to see who is com­ing from which back­ground, and what their strength is. I come from a func­tion­al back­ground, so I can speak more about busi­ness and appli­ca­tion archi­tec­ture than about tech­ni­cal archi­tec­ture. But that doesn’t mean that I should be com­plete­ly off the case for tech­ni­cal tasks. I can go to a tech­ni­cal archi­tect, and he will guide me on cer­tain cases. 

When you are con­nect­ing the dots, under­stand­ing busi­ness require­ments, archi­tec­ture require­ments, and deci­sions that need to be made, you will always need help from the respec­tive experts. As an enter­prise archi­tect, if you start from the strat­e­gy per­spec­tive, it becomes more top-down, but many cus­tomers approach tasks from the bot­tom up. It depends on which stake­hold­er you’re talk­ing to. 

Reichel: The enter­prise archi­tect must come up with the approach, right? How do we try to solve the prob­lem that we are fac­ing? Then they have to define who’s doing what, and what approach needs to be defined. For that, you need to under­stand the prob­lem. You face a lot of com­plex­i­ty as an enter­prise archi­tect. First of all, you need to dive into the under­ly­ing issue, and then you can sim­pli­fy it and then come up with the best approach.

ASUG: We’ve been hear­ing a lot at the Next-Gen­er­a­tion Enter­prise Archi­tect Learn­ing Forum about SAP’s embrace of AI. What do you make of the recent gen­er­a­tive-AI focus and devel­op­ment from SAP? What impact will that have on the future of the enter­prise archi­tect role?

Reichel: AI will have a huge impact on the dai­ly job of an enter­prise archi­tect. There are dif­fer­ent ways to look at that: AI for enter­prise archi­tects, or enter­prise archi­tec­ture for AI. I think AI will play a huge role in the future, more than we now think. We talked about com­plex­i­ty, and AI is effec­tive at com­plet­ing mul­ti-dimen­sion­al analy­sis faster than the human brain. 

If you think about huge land­scapes in which you’re mak­ing any change, that change will have an impact on the oth­er com­po­nents of the land­scape; between our expe­ri­ence and our method­ol­o­gy, we have a way to tack­le that. But lever­ag­ing gen­er­a­tive AI to con­nect the dots and assess what poten­tial impact a change will have can only help; this will not make the job of the enter­prise archi­tect obso­lete but rather accel­er­ate our work. 

Klee: AI could serve to evolve our roles into that of a pro­fes­sion­al-ser­vices deliv­ery arm for the enter­prise archi­tec­ture func­tion, I think. What steps should we take, and where can we use what type of tech­nol­o­gy? We will always work with map­pings, and com­ing up with scal­a­bil­i­ty mod­els that fit our ref­er­ence mod­els is the per­fect type of task for AI. AI can also be used to assess the com­pet­ing busi­ness needs and to opti­mize busi­ness archi­tec­ture. Nev­er­the­less, when it comes to deci­sion-mak­ing, enter­prise archi­tects are bet­ter-suit­ed to help with val­ue real­iza­tion and to over­see the devel­op­ment of more con­crete, rule-based mod­els. Ulti­mate­ly, gen­er­a­tive AI is a tool, and enter­prise archi­tects use all types of dif­fer­ent mech­a­nisms and tool sets — what­ev­er fits best for the job.

Das: It’s a fas­ci­nat­ing and over­whelm­ing top­ic, because changes are com­ing so fast, but when we’re design­ing the tar­get archi­tec­ture and roadmap for cus­tomers, this ques­tion will keep com­ing up. I do think that, as CEOs are dis­cussing gen­er­a­tive AI and agen­tic AI, per­haps these types of tech­nolo­gies could form anoth­er lay­er out­side the appli­ca­tion, data, and plat­form lay­ers. An agen­tic-AI archi­tec­ture lay­er could be intriguing.