Register now to attend the enterprise-architecture pre-conference seminar at this year's SAP Sapphire & ASUG Annual Conference. ASUG members can enjoy 15% off any SAP Press titles with the discount code 15ASUG.
As companies’ processes and system landscapes have become highly complex in recent years, succeeding with business transformation has increasingly required business and IT leaders to seek deeper visibility into existing business capabilities and the technology architecture that will be required to evolve those capabilities in accordance with the organization’s strategic goals.
Given this, as companies seek to align business strategies with IT execution, the role of the enterprise architect is taking on greater importance across the SAP ecosystem. In addition to creating the SAP Enterprise Architecture Framework—a structured methodology and tools intended to help enterprise architects to plan, design, and implement an EA practice within an SAP environment—SAP is working to embed enterprise architects within the services it offers to on-premises users moving to the cloud, positioning them as dedicated CTOs for customers who are currently pursuing SAP S/4HANA cloud transformation via RISE with SAP.
With developing mature, successful enterprise architecture functions now a growing priority for organizations in this ecosystem, business professionals everywhere are keen to explore SAP’s EA tools and framework, to integrate AI and optimize processes, and to develop future-ready practices with SAP solutions by expanding their knowledge of this emerging field. (For more in-person insights into all these topics, register to attend ASUG’s upcoming pre-conference seminar at SAP Sapphire & ASUG Annual Conference, “The Evolving Role of the Enterprise Architects: Unlocking SAP’s Potential.”)
Currently the bestselling publication from SAP Press, Enterprise Architecture with SAP: Planning, Management, and Transformation sets forth a strategic roadmap for enterprise architects to follow, providing practical use cases and examples of architecture design pattern implementation that can help readers establish their own enterprise architecture practices.
With decades of combined experience in the field, co-authors Peter Klee, Anup Das, and Johannes Reichel approached this publication as an opportunity to illuminate the cross-organizational collaboration that enterprise architects are uniquely well-suited to facilitate.
Das is a chief enterprise architect and the regional delivery head for the SAP Transformation Hub in North America. Klee leads the SAP Transformation Hub within SAP’s Customer Services & Delivery board area, overseeing a global group of enterprise architects who support SAP MaxAttention customers with architecture planning services. Reichel is a principal enterprise architect within SAP Transformation Hub, focusing on global transformation and architecture planning for SAP clients.
At the Next Generation SAP Enterprise Architect Learning Forum, hosted at SAP’s North American headquarters in Newtown Square, Pennsylvania, earlier this year, ASUG sat down with all three authors to discuss the evolving role of the enterprise architect in SAP landscapes.
Responses have been edited for length and clarity.
What was your motivation for writing this book, and what audience did you have in mind?
Peter Klee: Technology is transforming, evolving, and growing more complex. In the past, frameworks like The Open Group Architecture Framework (TOGAF) have been perceived as static, and we believe that enterprise architecture amid transformation should be more flexible, so we had ideas around that to explore. With the tools available to EAs also evolving, we wanted to place those in context of a larger framework.
Most importantly, though, we wanted to provide guidance on how to set up an enterprise architecture practice, so that’s an element of our framework, to overcome those isolated EA groups that still exist apart from the separated SAP islands. In the end, it’s about demystifying enterprise architecture. The subtitle of our book identifies three stages of an architecture practice: planning, management, and transformation. It’s not just about how you plan a singular target architecture; you want to manage enterprise architecture in your enterprise in an ongoing way, and transformation involves prediction of future needs and a comparison of different options of enterprise architecture. Instead of having one target drawing, you need reasoning around different transition options; that is what transformation entails.
Who is the book for? It’s not only for enterprise architects but also for SAP professionals who want to understand enterprise architecture better, to see how different areas of a business can work together. It’s for the C-suite – those individuals who grew through the ranks and are more technical these days than in the past. Enterprise architecture is a topic of interest for project managers, data management practitioners, process owners, procurement professionals, up to finance or corporate strategy leads. The ecosystem is broad. As an enterprise architect, you must be aware of that fact and work across it.
Anup Das: Enterprise architect roles and responsibilities are fairly well-defined, and SAP has particularly established standards and frameworks to provide for organizations approaching enterprise architecture. And yet, there’s still uncertainty around the definition of the term or the role of the EA, so we wanted to demystify the topic from our own experience.
ASUG: EAs can act as a bridge between business and IT departments, and this is a role rather than a job title in many instances. Tell me about striking that balance between establishing methodologies and frameworks that add structure and definition to the role of the EA while helping business professionals to see the ways in which they might be already facilitating EA functions at their companies.
Johannes Reichel: The reality we see in many companies is that they don’t have a so-called enterprise architecture practice. Large corporations usually have them, and those employees will call themselves enterprise architects. But, for many customers, it’s an ‘in-between’ role. Sometimes, they approach the role more from a solution-architect perspective, where someone oversees the whole landscape. They call themselves solution architects, but they do—more or less—the jobs of enterprise architects.
I think the book can be a great help for someone in that role who has not yet established standards and methodologies and is not using tooling to establish a more structured way to complete their work.
Klee: It’s also not a single practice. When one says the ‘holy grail’ involves bridging the gap between IT and all business units, business functions, and program and strategy offices, there are many dimensions to link. This is also not done overnight. Some enterprise architecture functions are much more technical. We see different scopes of enterprise-architecture teams at our customers.
Our approach is holistic, and it involves bridging in concepts such as business capabilities and strategies. It’s an evolution in step by step advancing the maturity. But to adopt the same processes and same approach in-house, that’s a harder process, because then it’s also about rearranging certain alignment processes and accountabilities. This works best if there’s top-down support.
Reichel: You have to prove that enterprise architecture is helpful to the organization, then you can further grow the disciplinary practice in your organization. You want to avoid the connotation of the “ivory tower” of people who draw nice diagrams but without any impact. But if you start with the minimum viable product, the MVP, of looking at one domain and linking its technology to strategy, then presenting that to business and IT stakeholders, it’s easier to demonstrate the advantage of establishing such a practice. Without spending hundreds of days of effort, instead dedicating a couple of weeks, you can show two stakeholders the results, and they’ll see the value that will allow you to roll it out further.
With one of my customers, we ran an exercise to link strategy to the business and solution architecture, and as part of this we connected the customer’s enterprise-architect team with the strategy department. That was the first time that those two teams talked to each other, and they were amazed by the results. They never had a way to link what we would define as a corporate strategy with their architecture planning; now, they’ve adopted one of those strategy-mapping and business-capability-mapping modules that we demonstrate in the book. They are using that in their practice now, but we gave them the stimulus to do so from outside.
Das: When a customer’s transformation project is in an execution phase, there are so many players: the customer team, the partner and SAP, and then the army of teams marching towards the larger goal. But they don’t know where they will land. They don’t know the north star of the whole project, because these individuals were not involved in the planning of the target architecture. That’s why it’s very important that they have this picture of where they’re moving toward and how their project will meet the strategic priorities of the organization.
ASUG: As SAP seeks to recruit more enterprise architects to support RISE customers, where do you see those EAs coming from? Are they technical practitioners gaining more insight into the business, or business stakeholders gaining IT expertise?
Klee: Both are needed. Because if you only get people from the business background, then you would have failures when technical scalability questions come up, and they have no clue about that. What also helps is that the SAP EA Methodology builds on what we call artifacts, which are also often visual. The strategy map is not a bullet-point list with text, but a simple hierarchy diagram. I think these maps can help— as supported by tools like SAP LeanIX —to convey a message more easily, whatever your ability as a storyteller. When you explain it to the C-level, visuals also help to make it more approachable for both sides, be that the technical folks talking with businesspeople or the businesspeople talking with the technical folks.
Das: It’s not one person’s job. We have to see who is coming from which background, and what their strength is. I come from a functional background, so I can speak more about business and application architecture than about technical architecture. But that doesn’t mean that I should be completely off the case for technical tasks. I can go to a technical architect, and he will guide me on certain cases.
When you are connecting the dots, understanding business requirements, architecture requirements, and decisions that need to be made, you will always need help from the respective experts. As an enterprise architect, if you start from the strategy perspective, it becomes more top-down, but many customers approach tasks from the bottom up. It depends on which stakeholder you’re talking to.
Reichel: The enterprise architect must come up with the approach, right? How do we try to solve the problem that we are facing? Then they have to define who’s doing what, and what approach needs to be defined. For that, you need to understand the problem. You face a lot of complexity as an enterprise architect. First of all, you need to dive into the underlying issue, and then you can simplify it and then come up with the best approach.
ASUG: We’ve been hearing a lot at the Next-Generation Enterprise Architect Learning Forum about SAP’s embrace of AI. What do you make of the recent generative-AI focus and development from SAP? What impact will that have on the future of the enterprise architect role?
Reichel: AI will have a huge impact on the daily job of an enterprise architect. There are different ways to look at that: AI for enterprise architects, or enterprise architecture for AI. I think AI will play a huge role in the future, more than we now think. We talked about complexity, and AI is effective at completing multi-dimensional analysis faster than the human brain.
If you think about huge landscapes in which you’re making any change, that change will have an impact on the other components of the landscape; between our experience and our methodology, we have a way to tackle that. But leveraging generative AI to connect the dots and assess what potential impact a change will have can only help; this will not make the job of the enterprise architect obsolete but rather accelerate our work.
Klee: AI could serve to evolve our roles into that of a professional-services delivery arm for the enterprise architecture function, I think. What steps should we take, and where can we use what type of technology? We will always work with mappings, and coming up with scalability models that fit our reference models is the perfect type of task for AI. AI can also be used to assess the competing business needs and to optimize business architecture. Nevertheless, when it comes to decision-making, enterprise architects are better-suited to help with value realization and to oversee the development of more concrete, rule-based models. Ultimately, generative AI is a tool, and enterprise architects use all types of different mechanisms and tool sets—whatever fits best for the job.
Das: It’s a fascinating and overwhelming topic, because changes are coming so fast, but when we’re designing the target architecture and roadmap for customers, this question will keep coming up. I do think that, as CEOs are discussing generative AI and agentic AI, perhaps these types of technologies could form another layer outside the application, data, and platform layers. An agentic-AI architecture layer could be intriguing.