openSAP

An Enterprise Architect’s View on SAP Business

Technology Platform
Week 3 Unit 1

00:00:05 Welcome to week three, Working with the SAP Business Technology Platform as an
Architect.
00:00:13 In this week, we adopt all we have learned from week one and from week two
00:00:19 in the context of the SAP Business Technology Platform. In unit one, we start with a brief
introduction
00:00:27 to the SAP Business Technology Platform, or BTP for short. Let's start by going back to
week one for a moment.
00:00:38 So in week one, we talked about the basic pillars of every company, like a vision and
operating model,
00:00:45 business capabilities, business processes, application and technology, and data. So the
pillars can be grouped
00:00:55 into the categories "business", shown in blue, and "technology", shown in orange. And we
defined enterprise architecture
00:01:05 as a methodology which is aligning these different pillars, that is to say, a methodology
which is aligning business and IT.
00:01:16 In week two, we explored the lean enterprise architecture toolkit and its work products
00:01:24 to put the Architecture Development Method into action. And again, also the toolkit
addresses the two domains business and technology
00:01:35 with corresponding work products for each domain. And now in week three, we complement
this picture
00:01:44 with the SAP Business Technology Platform, which allows us to put the architecture being
defined with a lean enterprise architecture toolkit into action.
00:01:57 So we can understand the lean architecture toolkit and the Architecture Development
Method
00:02:03 as a structured and organized approach to describe a project that can be implemented with
the SAP Business Technology Platform.
00:02:13 And by this, the Business Technology Platform is also supporting all the corporate pillars,
from vision, to business capabilities,
00:02:23 to business processes, and technology and data. So let's further explore how
00:02:30 the SAP Business Technology Platform contributes to those corporate pillars, and let's start
with the business processes.
00:02:39 For business processes, the SAP Business Technology Platform
00:02:43 offers possibilities of business process integration. By this, different building blocks can be
integrated with each other
00:02:53 to deliver an end-to-end process across the company's value chain. And these processes
can be, for example,
00:03:01 hire to retire, source to pay, or lead to cash. And for realizing these end-to-end processes, it
is required to technically integrate
00:03:13 different solution building blocks with each other on a process level. Now another capability
of the SAP Business Technology Platform
00:03:23 is to extend existing business processes with your company-specific requirements. And last
but not least, you can also implement completely new business processes
00:03:36 with a Business Technology Platform. Okay, so much about the business process support.

00:03:43 Let's continue by looking at data. Also, back in week one,

00:03:49 we said that data turned to one of the most valuable assets for a business. So data can be
used to increase operational excellence by, for example,
00:04:01 making existing processes more efficient with increased insight. But data can also be used
to improve strategic excellence
00:04:11 by offering new services and products on top of data. And for this, the BTP offers different
capabilities and features
00:04:20 to manage data and to analyze data. Looking at the application and technology pillar,
00:04:27 the BTP also offers possibilities to develop and host complete applications. And this is also
used by SAP and its ecosystem, for example,
00:04:38 to build and deliver complete solutions on top of BTP such as SAP Industry Cloud or the
SAP Data Warehouse Cloud, for example.
00:04:48 Now, having seen how the BTP contributes to the corporate pillars, how can we actually
define the SAP Business Technology Platform?
00:04:59 Let's start with the vision of the BTP. The vision is that the Business Technology Platform
00:05:06 will be the foundation for all SAP applications, integration, customer and partner extensions,
as well as new innovations
00:05:16 like the industry cloud, for example, or business networks, for example. So, per definition,
the Business Technology Platform can be seen as
00:05:27 a portfolio of integrated solutions that, abstractly speaking, accelerate the transformation of
data into business value.
00:05:38 And for doing so, the platform provides several capabilities, such as database and data
management, application development, and integration,
00:05:50 analytics, and also other state-of-the-art technologies. You consume these capabilities
primarily as a service through the cloud.
00:06:01 So, simplified it is fair to say that the BTP focuses on the three scenarios we are seeing
here on this slide,
00:06:09 namely data to value, integration, and extension. What do those three capabilities mean?
00:06:17 Let's start with data to value. So data to value enables data to be used meaningfully in a
business context.
00:06:26 The BTP, for example, can be used to merge data from different SAP data sources and
applications,
00:06:33 but also from non-SAP sources and applications. We hear more about this later on.
00:06:41 Looking at the second scenario, integration. So with the BTP, you can refine and improve
your business processes along the value chain
00:06:51 by linking processes and data from SAP and third-party solutions with the help of the BTP.
00:06:59 And last but not least, extensions. Now, with BTP, you can adapt business processes to
new business conditions
00:07:08 or changing customer requirements without destabilizing critical existing processes.
00:07:16 And yeah, let's explore those capabilities and the scenarios by taking a closer look at the
capabilities of the BTP, which are used to implement the mentioned scenarios,
00:07:30 data to value, integration, and extension. By looking at this slide here,
00:07:37 let's start with the gray upper area on this slide. So what you can see here is basically the
BTP's projection area, so its field of activity,
00:07:48 as we have already defined it also through the pillars of the company we have talked about
at the beginning.
00:07:55 So essentially it is all about implementing your business processes in the best possible way,

2
00:08:03 which is consistent, automatic, error-free, and complete. Now, with regards to the pillars of a
company, this is how you realize
00:08:13 the business capabilities and the business processes of the company. For the
implementation of integrated business processes,
00:08:23 business networks have been developed in recent years, and basically this was done, on
the one hand,
00:08:30 to involve partners and customers more closely in the business processes and, on the other
hand, also to include data from areas outside the company,
00:08:40 such as financial markets, transport systems, or weather systems, for example. With a view
on SAP's portfolio, Ariba, Concur, and Fieldglass can be mentioned here.
00:08:54 Now continuing, we also see the intelligent suite here with its extensions for specific
industries,
00:09:01 as well as the industry cloud, as we have already mentioned before. So both also play a
vital role in implementing and realizing business capabilities
00:09:12 and respective business processes. So it is fair to say that
00:09:18 all the things we are seeing here in the gray area are great sources for realizing business
capabilities and business processes for your company.
00:09:29 However, in order to realize the business processes consistently between the required
individual solution components from the gray area,
00:09:40 also taking third-party solution components into account, as well as external data, and also
to make company-specific adjustments to the processes delivered by the gray area,
00:09:53 ensuring completeness of the process, or also to be able to control the process more finely
and more economically
00:10:02 by adding maybe additional data points, or not only to automate the process, but also to
automate decisions along the process,
00:10:12 a further solution component is required. And this is where the SAP Business Technology
Platform enters the stage,
00:10:21 as represented by the blue area here on the slide. Now, what's making up the Business
Technology Platform?
00:10:29 First of all, it has to be pointed out that all features of a Business Technology Platform are
provided on a common technical basis.
00:10:39 The layer shown here on the slide is called Common Foundation and Services. So this
includes, for example, so-called kernel services,
00:10:48 which are the technical foundation used by all other SAP Cloud solutions on top. For
example, we have an identity service here,
00:10:57 an audit log service, business event service, Master Data Integration, or the One Inbox
service, for example.
00:11:08 Now, the services of the BTP relevant from the perspective of business process
optimization and business model optimization
00:11:19 can be grouped into four categories which we see above the foundation services here on
the slide,
00:11:26 namely database and data management, analytics, application development and
integration, and intelligent technologies.
00:11:35 Let's take a closer look at these four capabilities, and let's start with the database and data
management capability.
00:11:44 Generally speaking, you can realize a data fabric with this capability. Now, what is a data
fabric?
00:11:52 A data fabric is basically a data architecture that can orchestrate a variety of distributed data
and also metadata,
00:12:01 while ensuring important things like data quality, data security, and also providing a high
level of automation and speed
00:12:10 to achieve a comprehensive and trusted view on the data. Now, a great added value of such
a data fabric

3
00:12:18 is its ability to provide organizations within your company with a technical foundation to
rapidly implement data-driven use cases
00:12:29 by leveraging different features, like data integration, distributed and multi-cloud
architectures, things like a graph engine or data anonymization,
00:12:41 distributed in-memory and persistent memory platforms, and more. So thereby, the data
fabric focuses on
00:12:49 automating, processing, integrating, transforming, preparing, and managing all data assets,
in order to do one thing,
00:12:59 namely enabling a real-time analysis and insight for successful decision making. Specific
solution building blocks we can think of here
00:13:11 are the SAP HANA Cloud service and SAP Data Intelligence, for example. Let's take a
closer look at the second capability, analytics.
00:13:22 With the analytics capability of BTP, you analyze data to enable better planning and
decision making,
00:13:29 gaining real-time insights into different business areas, and also simulate the effects of
different decision options you have.
00:13:40 Solutions from this area include the Digital Boardroom, SAP Analytics Cloud, and the SAP
Data Warehouse Cloud.
00:13:48 Now, with respect to the data and data management capability we described previously, the
analytics capability is built upon them.
00:13:57 So, for example, the Data Warehouse Cloud uses the SAP HANA Cloud and the SAP Data
Intelligence service.
00:14:04 Let's take a look at the third category here, the application development and integration
capability.
00:14:11 In this area, you basically find all you need for process integration and process extension.
00:14:19 Now, the individual BTP services in this area can furthermore be grouped into the so-called
Integration Suite and the Extension Suite,
00:14:29 whereby the Extension Suite can be further subcategorized into digital experience,
development efficiency, and process automation.
00:14:41 For example, the Extension Suite offers the concept of a so-called extension factory with
which the SAP standard applications can be extended.
00:14:52 The Integration Suite offers everything necessary for process integration across different
SAP and third-party applications,
00:15:01 and also allows efficient implementation with predefined integration content, specifically for
the SAP solutions.
00:15:10 Now the fourth area, labeled intelligent technologies, is an area that is used for both
integration and extension development.
00:15:20 Here you find services such as machine learning or IoT to further optimize the business
processes.
00:15:27 Or you find services like robotic process automation to automate processes across different
end-user tools
00:15:35 from the perspective of a user interaction. Okay, this was a short tour through the different
capabilities making up the BTP.
00:15:46 Besides these capabilities, it is also worth mentioning what is actually driving the
engineering of those capabilities.
00:15:54 So what are actually the architecture principles of the BTP? Now, SAP Engineering is
designing the BTP
00:16:03 based on the three qualities you're seeing here on that slide. Reading from left to right,
00:16:10 business centricity, unified platform, and open architecture. What is meant by those three
qualities?
00:16:18 And let's start with business centricity. Now, SAP's knowledge about industries and
business processes

4
00:16:26 is to be brought to the technology portfolio as well. So that's basically the idea behind the
business centricity.
00:16:35 So the goal is to provide you, as a BTP user, with reusable business components, such as
also prepackaged business content,
00:16:45 and basically relieve you of any technical complexity as best as possible. Let's look at the
quality unified platform.
00:16:55 So BTP integrates all platform solutions by harmonizing data and processes, also
technologies and functionalities,
00:17:06 and also the user experience. And this overall harmonization will save unnecessary data
movements,
00:17:14 for example, between different technology stacks, and also will reduce the BTP's total cost
of ownership.
00:17:22 Now the open architecture quality. So through an open architecture
00:17:26 and interoperability with open-source and third- party technology, you can easily extend
your existing IT landscape with BTP.
00:17:37 BTP is cloud-first, but also offers flexible deployment solutions
00:17:42 to allow you to move from on-premise to the cloud or hybrid at your own speed. Let's raise
the level of detail a bit
00:17:53 to show the capabilities of the Business Technology Platform via a component diagram, as
we can see it on this slide here.
00:18:02 So in the part in the middle of this slide, you see the four categories, the capabilities we just
mentioned - database and data management, analytics,
00:18:13 application development and integration, and intelligent technologies, with some samples,
some solution building blocks per category.
00:18:23 Actually, you can read this diagram with your knowledge about architecture building blocks
and solution building blocks.
00:18:29 So the capabilities can be translated to architecture building blocks, while the specific
services
00:18:36 can be translated to solution building blocks. We also see highlighted two of the three BTP
scenarios,
00:18:44 namely integration and extension. And the third scenario, data to value,
00:18:50 is represented by the SAP HANA Cloud services component here in the middle. Also, the
previously mentioned foundational services are shown on this slide,
00:19:01 so built on top of this foundation, the BTP provides managed runtimes, making it easy also
to adopt opinionated development approaches,
00:19:12 such as Cloud Foundry and ABAP, for example. And in addition, BTP provides also an
opinionated, container-based runtime,
00:19:20 via Kyma and Gardener, that caters to cloud- native developers who want to have richer
control and want to be closer to the technical foundation.
00:19:31 What else do we see? We also see on the slide that a large part of the BTP capabilities
00:19:36 are provided as services by the four major cloud providers. But there's also a functional
area of BTP
00:19:44 that can be operated via the NetWeaver stack or your own hardware virtualized, or via a
container platform in your own data center.
00:19:54 And in the sense of a hybrid architecture, and with a view to the platform idea,
00:19:59 combinations between the different components are possible, such as BW/4HANA with
Data Warehouse Cloud, for example.
00:20:10 Worth mentioning is also the perspective of partners, like Microsoft Azure, Google, and
Alibaba,
00:20:16 which we see here on the right side of the slide under the keyword Partner Services.
00:20:23 Here, the technical approach of the service broker offers the possibility to include services
from the different areas of the partner portfolio

5
00:20:35 to be used specifically for extension or process optimization use cases. This component
diagram concludes the introduction
00:20:44 to the SAP Business Technology Platform. In the next unit, we obtain an architect's view on
SAP's Business Technology Platform
00:20:53 by taking a more abstract look at its capabilities we have introduced in this unit. Thank you
for listening.

6
Week 3 Unit 2

00:00:05 Welcome to week three, unit two. In this unit, we take an architect's view on SAP's Business
Technology Platform.
00:00:17 Thereby our approach is to combine our knowledge about the Architecture Development
Method
00:00:24 and its two architecture domains with the introduction of the SAP Business Technology
Platform from the previous unit.
00:00:33 The goal of this unit is to obtain a more vendor-neutral and product-neutral view of the SAP
Business Technology Platform.
00:00:43 And this view will help us in executing the Architecture Development Method by mapping
the vendor-neutral architecture building blocks of the solution concept diagram
00:00:56 to a BTP-based solution realization diagram with respective BTP solution building blocks.
00:01:06 So how do we create the architect's view on SAP's Business Technology Platform? For the
creation of the architect's view on the SAP BTP,
00:01:18 we use the previously introduced two types of building blocks - architecture building blocks,
ABBs, and solution building blocks, SBBs.
00:01:29 Let's quickly recap those two building blocks. The architecture building block represents a
functionality
00:01:36 that is provided by the solution, in our case by the Business Technology Platform. We can
understand the ABBs as the BTP's capabilities.
00:01:48 They describe what the BTP is capable of doing. An ABB should always be linkable to a
business need
00:01:56 as required business capabilities translate to ABBs. So this is what we do when we create a
solution concept diagram
00:02:06 based on a solution context. Although the description of the functionality can be technical,
00:02:14 an ABB is vendor-neutral. So the ABB does not call out specific BTP services,
00:02:23 but describes the BTP functionality in a service-neutral but also technical way. Calling out
specific BTP services is done by the solution building blocks.
00:02:36 SBBs define which specific BTP services or components implement the functionality being
described by the ABB.
00:02:47 So the ABB describes what the BTP can do, and the SBB describes how the functionality is
provided.
00:02:57 And also, please remember we use the SBBs for the creation of the solution realization
diagram.
00:03:06 So what we explore in this unit helps us with the transition of the solution concept diagram
to the solution realization diagram.
00:03:18 Okay, let's begin our architect's view on the SAP Business Technology Platform by mapping
the two domains, "business" and "technical", to the BTP capabilities.
00:03:31 So what we see on this slide are five horizontal capability layers that can be mapped to the
previously introduced pillars
00:03:40 being the foundation of every company. Starting from top to bottom,
00:03:47 we see the business capabilities, which are defining what a company is capable of doing in
the layer with a number one.
00:03:58 Examples here are the end-to-end processes we covered a lot so far, like hire to cash, hire
to retire,
00:04:06 lead to cash, design to operate, for example. Now the first layer falls into the category
business architecture
00:04:15 and, mapping it to the SAP product portfolio, you can think of solutions like
00:04:21 SAP S/4HANA, business networks, and the Industry Cloud, for example. These solutions
run either on BTP, like the Industry Cloud,

7
00:04:32 or run with BTP, like SAP S/4HANA, for example, Let's look at the BTP capabilities
represented by the layers two to five.
00:04:45 All those four layers support the previously introduced BTP scenarios, integration,
extension, and data to value.
00:04:55 It is also worth mentioning that the layers are built upon each other, that is, capabilities from
layer two to four
00:05:04 are using capabilities or services from layer five, for example. Now, capability layer two can
be associated to the business domain,
00:05:15 layer three can be associated to both business and technical domain, whereby layers four
and five can be associated to the technical domain.
00:05:27 Let's take a closer look at the layers, starting with layer two. Now, layer two represents
business applications and business services.
00:05:39 Both are capabilities delivered by the BTP, like analytic solutions, planning and warehouse
solutions,
00:05:48 as well as domain-specific business services like tax calculation, variant configuration, or
the calculation of promotional prices, for example.
00:06:00 The ability to improve existing business processes by extension and integration activities
00:06:07 is represented by layer number three. Here you find capabilities in the areas of workflow
management,
00:06:16 process integration, and process visibility, for example. Layer four addresses the
information and knowledge building
00:06:25 with a corresponding data layer. And layer five represents foundational services
00:06:31 like multi-cloud, deployability, security, logging, and others. Let's continue by looking at the
different architecture building blocks
00:06:42 of the SAP Business Technology Platform. And we start by drilling down in layer four, into
the data layer.
00:06:52 Now, the data layer supports the BTP data-to-value scenario,
00:06:58 and serves as a basis for other layers or other building blocks sitting on top. The data layer
or data architecture building block
00:07:09 brings the ability to connect to and store any data, no matter the source, format, location, or
volume.
00:07:17 And based on the connected data, the data layer offers orchestration capabilities among the
data, supporting different features,
00:07:25 such as physical data replication, federation, or pipelining. Based on this, higher-level data
services,
00:07:34 such as preparing, cleaning, transforming, and enriching the data are offered. Important to
mention are also the analytic features of the data layer,
00:07:45 as well as the semantic knowledge, especially about SAP data sources. This all adds up to
the possibility of implementing a data fabric
00:07:57 by making the individual steps previously mentioned reproducible and automatic at scale.
00:08:04 The individual building blocks making up the data layer are consumed as managed services

00:08:13 and implement cloud qualities like elasticity, scale, and high availability. So let's move to the
next architecture building block.
00:08:24 One layer consuming the individual building blocks of the data layer is the application layer.

00:08:32 The application layer is also comprised of different building blocks, and we can name one
subcategory of building blocks in the application layer,
00:08:42 digital process. And building blocks of this digital process subcategory
00:08:49 support the realization and improvement of digital business processes. Now, starting from
left to right, there is a building block that allows you to integrate

8
00:09:00 different processes, based on events, messaging, and APIs, for example. Also, you find a
building block supporting process automation
00:09:10 via rules, workflow management, and bots, for example. A third building block offers analytic
functionality,
00:09:18 such as simulation, planning, and the creation of dashboards and reports, for example. And
another building block provides you with domain-specific services
00:09:30 for lines of business or industry-specific scenarios. And there is a building block offering the
functionality
00:09:38 to deploy your custom applications or your custom business processes following different
programming paradigms.
00:09:49 Now, within the application layer, we can add a second subcategory of building blocks,
named digital experience.
00:09:58 This subcategory includes all building blocks about a digital user experience. And, for
example, you find building blocks that offer a central user entry
00:10:09 to connect people, users, with the required business processes. Moreover, the BTP offers a
building block to realize a digital workplace
00:10:21 based on collaboration, personalized and role-based sites, which offer access to business
applications and content.
00:10:31 Now, in addition to the data layer and to the application layer, the BTP also has a layer
delivering components
00:10:39 that are reused within the data layer and the application layer. And this cross layer delivers
building blocks supporting developer productivity,
00:10:49 such as tools and programming models of frameworks, for example. Another building block
within the cross layer deals with security,
00:10:59 offering services like identity authentication, as well as authorization and trust management,
for example.
00:11:09 Now, based on these BTP building blocks, you realize the previously mentioned scenarios,

00:11:16 data to value, integration, and extension. And by the implementation of use cases in these
scenario categories,
00:11:25 you transition from the technology domain into the business domain by implementing
business solutions
00:11:33 in the form of applications or business process extensions. Thereby you build on business
content being provided via the BTP,
00:11:44 such as you are ready to use integration content packages or semantic models, for
example. Looking holistically at the BP building blocks,
00:11:55 you can also think of grouping them into the model-view-controller paradigm, whereby the
data layer is a model,
00:12:02 the digital process building blocks within the application layer, the controller, and the digital
experience building blocks within the application layer, the view.
00:12:14 Now this concludes our architect's view on the SAP Business Technology Platform by
abstracting its capabilities via several building blocks.
00:12:25 And these architecture building blocks, and this architecture building block-oriented view
00:12:31 actually helps us to transition our solution concept diagram to the solution realization
diagram.
00:12:40 In the next unit, we look at different enterprise architecture use cases
00:12:45 that can be realized with the SAP Business Technology Platform. Thanks for listening.

9
Week 3 Unit 3

00:00:05 Welcome to unit three, week three, Mapping the SAP Business Technology Platform to
Enterprise Architecture Use Cases.
00:00:16 In this unit, we map the enterprise architecture use cases that we have introduced in week
one, units three and unit four,
00:00:26 to the SAP Business Technology Platform. So let's start with a brief repetition of the
enterprise architecture use cases
00:00:36 we talked about in week one. So back in week one, we talked about the concept of your
playground
00:00:43 as an enterprise architect, and this playground can basically be described by different areas
you are acting in,
00:00:51 as we see them on the top of the slide here, like strategy, business development, IT
management,
00:00:58 and the alignment of business and IT. Of course, you can define your own playgrounds as
an enterprise architect.
00:01:06 And the playgrounds we've previously mentioned are the four sample playgrounds we
consider now
00:01:13 and continue working with. And please remember, it is likely that your use case,
00:01:20 and the corresponding solution to your use case, relates to more than one of the mentioned
playgrounds simultaneously.
00:01:30 Now, acting on a playground is defined via a tactic. And you can understand the tactic as
the delivery of an enterprise architect use case
00:01:41 via a project. And it is exactly this project for which you are developing an architecture,
00:01:49 whereby the development process of the architecture is again done with the help of an
architecture framework
00:01:57 and a toolkit like the lean enterprise architecture toolkit we discovered in week two.
00:02:05 So furthermore, you can think of categorizing the use cases in categories like technology
management for the standardization of the IT landscape,
00:02:16 or business process optimization, or business capability management, or the fourth sample
we're seeing here, innovation management.
00:02:27 Now, remembering the two vectors, or drivers, that can initiate your architectural work, that
is business and IT,
00:02:35 we can color the previously mentioned use cases accordingly. So a business optimization
and a business capability use case
00:02:45 will likely be triggered by a business department, whereby innovation management and
technology management use cases
00:02:54 are more likely triggered by an IT department. Now, looking at the tactic that is the four use
cases here on this slide,
00:03:04 you notice that each use case contributes to more than one playground, and this is
indicated on the slide with the circles having different sizes.
00:03:16 And the bigger the circle, obviously, the higher the contribution of the use case to the
associated playground.
00:03:25 And also, please notice that the sizes you're seeing here on that slide are just samples, so
you shouldn't take them as absolute values.
00:03:34 And depending on your concrete use case, the sizes of the circles obviously might differ.
00:03:43 Now, for executing your tactic on the playground, you need players. And this is where the
previously introduced architecture building blocks
00:03:51 of the SAP Business Technology Platform enter the stage. And these building blocks now
can help to address the use cases

10
00:04:00 and realize the corresponding project accordingly. So let's continue by looking closer at
those four sample use cases,
00:04:08 and discover how the SAP Business Technology Platform and its architecture building
blocks can be mapped to those use cases.
00:04:19 So let's start with the business capability management use case, which is triggered by a line
of business,
00:04:25 like a corporate strategy department, for example. So in this context, it is fair to say that the
use case
00:04:31 is mainly playing in the areas of strategy and business development, as indicated by the
circles here on that slide.
00:04:40 Now, what is the goal of this use case? So basically, you want to define or refine the target
picture of your company
00:04:49 by describing what your company should be capable of doing in the context of the current or
concrete market situation.
00:04:58 And the target picture with its capabilities is obviously in alliance with the corporate goals,
and this definition of what your company should be able to do
00:05:10 basically also serves as a common language between business and IT. So business can
relate the capabilities to their daily work and corporate goals,
00:05:22 and IT gets an understanding about what is needed. Now, how do you deliver a business
capability management use case?
00:05:31 So typically, you create a heat map of skills, a heat map of capabilities,
00:05:38 that your company requires today and in the future.
00:05:42 And as a next step, you correlate those prioritized capabilities of the heat map to the
company's operating model and also the required business processes.
00:05:54 And your goal is basically to identify necessary changes to existing business processes and
their related IT landscape,
00:06:04 or to identify new business processes that have to be introduced in the company. And you
can think of creating or updating some sort of functional reference model
00:06:18 of your company based on the language of capabilities. And thereby, the capabilities are
typically grouped into different domains,
00:06:27 like finance or sales, for example. But you can also think about grouping the capabilities
00:06:33 from a more business process perspective, like lead to cash, source to pay, and so on.
00:06:40 Now let's continue and take a look at what SAP Business Technology Platform building
blocks can actually support the implementation and realization
00:06:50 of a business capability management use case. From the level of architecture building
blocks,
00:06:57 BTP delivers ready-to-use business applications that can be directly consumed via a
Software-as-a-Service model, for example.
00:07:06 So these business solutions are provided either by SAP or by the partner ecosystem.
00:07:12 And we can think of concrete solution building blocks like the SAP Industry Cloud, or LoB
applications like the SAP Analytics Cloud or Data Warehouse Cloud, for example.
00:07:24 And also with the prepackaged semantic models and domain-specific dashboards, for
example,
00:07:32 and also the ability to plan and simulate those building blocks are supporting specific
capabilities like finance, for example.
00:07:43 Moreover, BTP’s domain-related business services also support the realization of a
capability management use case.
00:07:52 And for example, you can think of business services like omnichannel promotion pricing,
variant configuration and pricing, or the tax service,
00:08:02 which can be mentioned as samples for concrete business service solution building blocks
here.

11
00:08:10 Now, a third architecture building block worth mentioning in the context of capability
management
00:08:15 is process integration. And here, the SAP BTP delivers ready-to-use business content
00:08:22 for integrating different SAP solutions for exchanging information, also with government
authorities, and more.
00:08:32 Okay, so let's continue with the second use case triggered by business, which is business
optimization in the context of data and processes.
00:08:41 And the goal of this use case is to improve the day-to-day business tasks with the help of
technology enhancements.
00:08:50 For example, you can think of the automation of specific tasks or the integration of
additional data points
00:08:57 improving decision making or reducing the complexity by a more context-aware user
interface, for example.
00:09:06 Now to discover and better understand areas of business optimization, you can use design
thinking as a suitable methodology.
00:09:15 And especially by looking at the problem domain, you discover optimization potential by, for
example,
00:09:22 discovering process redundancies or inconsistencies within the process. Or maybe there
are gaps in coverage
00:09:31 and system breaks throughout the process execution. So with this use case, you analyze
the current data and process architecture
00:09:42 within an identified problem domain, and you continue by describing a target architecture
00:09:49 that is improving the day-to-day business by, as mentioned, reducing redundancies,
inconsistencies,
00:09:56 reducing manual steps, reducing the lack of data, system and media breaks, for example.
Okay, so let's look at BTP’s building blocks that can support this use case.
00:10:12 Now, again, starting with the architecture building blocks, you can think of functions like data
and process integration of SAP and non-SAP systems
00:10:22 to help reduce media and system breaks, and also lay the foundation for further automation
and reduced complexity.
00:10:33 And solution building blocks like the Integration Suite, which is offering different technical
approaches to integrate processes,
00:10:43 can be mentioned as an example here. But you can also think of services like Data
Intelligence, SAP HANA,
00:10:49 and SAP IoT that support this use case, especially when it comes to the necessity of data
orchestration and data integration.
00:11:00 And furthermore, the BTP process extension capability also supports the business
optimization use case.
00:11:09 And especially based on the previously mentioned ability to integrate, the Extension Suite
now offers more flexibility and functionality
00:11:21 to adapt and enhance a business process to company-specific requirements, which are
typically rooted in concrete market situations or stakeholder demands in general.
00:11:34 So, for example, think of a hire-to-retire business process, and hiring new talents during a
period of lockdown due to a pandemic is different.
00:11:45 So, for example, new equipment such as a laptop or a mobile phone is not shipped to the
office location anymore,
00:11:53 but to the home address of the new employee. And this new situation might require some
changes to the existing business process,
00:12:01 which should be lightweight and not too intrusive. And in the context of the BTP process
management and automation building block,
00:12:14 it is also worth mentioning that with this building block, you can improve existing processes

12
00:12:22 by adding additional steps and functionalities, or even implement completely new
processes.
00:12:29 And corresponding sample building blocks of this area are the workflow management,
process visibility,
00:12:38 business rules, and robotic process automation. And the previously mentioned domain-
specific business services
00:12:45 also support your optimization of the business. And further examples of those ready-to-use,
domain-specific services,
00:12:55 which are offered via solution building blocks, for example, the business entity recognition,
00:13:01 master data for business partner, blockchain, compliance reporting, document classification,

00:13:09 and service ticket intelligence, and many more. And as this is quite an important use case,

00:13:17 we have a second slide listing some building blocks that support this use case, specifically
with a focus on digital experience.
00:13:28 And corresponding solution building blocks addressing the digital experience are
conversational AI, document management,
00:13:37 forms by Adobe, the launchpad, and also the previously mentioned SAP Analytics Cloud
embedded edition, for example.
00:13:47 And yeah, as you are implementing additional functionality based on the different BTP
solution building blocks,
00:13:55 the development productivity block needs also to be mentioned here. And you can think of
tools like the Business Application Studio
00:14:04 or frameworks like the cloud application programming frameworks, services like the
Translation Hub or Transport Management
00:14:12 supporting your development productivity in this context. So this concludes our two sample
enterprise architecture use cases triggered by business.
00:14:25 And let's continue by looking at two use cases that are triggered by technology, and
continue exploring which BTP building blocks
00:14:33 support those two technology use cases. And the first use case we start with is technology
management,
00:14:42 with a focus on standardization and homogenization. What is the goal of this use case?
00:14:49 So the goal of this use case is basically cost reduction in your basic IT operations, and this
is being done by reducing complexity of your existing IT landscape.
00:15:02 But you can think of the reduction of technical depth, for example. This can be achieved by
standardizing elements within your IT landscape
00:15:12 that have the same business or technical purpose. And also the definition of technical
standards and process standards
00:15:21 plays a role in this use case as well. Now playing this use case mainly contributes to the IT
management area
00:15:29 and the alignment between business and IT, as it is indicated by the circles here on this
slide.
00:15:36 Now, how can the SAP Business Technology Platform contribute to this use case? Let's
look at the building blocks.
00:15:43 So for standardizing IT and reducing the complexity of the existing landscape, we basically
search for building blocks that can serve as a central and reusable building block
00:15:56 for several business purposes. And this is, for example, true for the business application
building block of the SAP BTP.
00:16:05 And here, solutions like the previously managed SAP Analytics Cloud and also the Data
Warehouse Cloud
00:16:11 can serve as central solutions for different lines of business. And also the complete data
layer of the BTP supports this use case,

13
00:16:21 as this layer helps to implement a corporate data fabric based on solution building blocks
like SAP HANA and Data Intelligence, for example.
00:16:34 And in terms of standardizing the process integration and standardizing the process
extension,
00:16:41 the corresponding BTP process integration and extension building block, with its predefined
content packages and adapters,
00:16:51 can also be used to implement a corporate standard for integrating and extending business
processes.
00:16:58 And especially concepts like the extension factory, including curated programming
frameworks,
00:17:05 SDKs, adapters, and Integration Advisor, integration packages, and so on,
00:17:12 support this use case. Okay, so much for the first technology use case,
00:17:18 let's continue to the second use case triggered by technology. And this second use case
deals with innovation management,
00:17:28 which you can also associate to concepts like a digital lab, for example. So this use case
supports primarily your corporate strategy,
00:17:38 business development, and also IT management, as again indicated by the circles here on
this slide.
00:17:45 And the goal of this use case is basically to make sure that the corporate IT is strategically
positioned
00:17:52 and powerful enough to support the corporate goals. And within this use case, you evaluate
current and future technical trends
00:18:02 and relate them to your business, typically by an impact analysis. And in this context, it is
also important
00:18:11 that you do not only scout new trends in a kind of theoretical way, but you are also able to
evaluate and assess their potential impact on your business.
00:18:23 And this assessment also includes your ability to introduce and support such a new
technology, skill-wise and also in terms of infrastructure readiness, for example.
00:18:37 So let's continue and explore how the SAP BTP supports this use case. So maybe your
unique character of this use case
00:18:47 is that there are not only concrete building blocks that support this use case, but also the
three BTP qualities we previously introduced in unit one
00:18:59 are supporting this use case, namely open architecture, business centricity, and a unified
platform.
00:19:07 And especially with the qualities open architecture and business centricity, you can support
this use case of innovation management.
00:19:16 So, for example, open architecture means that the BTP allows for interoperability
00:19:23 with open-source and third-party technology providers, which is widening the technology
space
00:19:30 from which you can evaluate new technologies. And also BTP’s multi-cloud ability
00:19:36 to be deployed and combined with other cloud provider infrastructures like AWS, Azure,
GCP, and Alibaba
00:19:45 is worth mentioning in this context. And additionally, also the freedom to choose different
development tools
00:19:52 like MS Visual Studio, for example, is also worth mentioning here.
00:19:58 And the business centricity quality supports you by putting now the new technologies into
the context of your business,
00:20:07 that is to say, existing business processes, transactions, or data, for example. And
evaluating a new technology
00:20:14 without understanding and showing the impact on the business might obviously satisfy the
tech nerd in us,

14
00:20:22 but it doesn't justify investments. Now as the evaluation of new technologies in the context
of your business
00:20:30 happens on the basis of data or business processes, the corresponding BTP building blocks

00:20:38 like process integration, process extension, and also the data layer support this use case.
00:20:44 So with the process integration and extension building block, you include the new
technology into existing business processes
00:20:53 and assess the results together with the respective business department. And the data layer
building block
00:21:00 supports you by orchestrating and integrating data from diverse sources that might be
needed to put a new technology into action,
00:21:08 like machine learning, for example. Here you are training your machine learning algorithm
00:21:14 with a vast amount of sample data, and it is critical to get and prepare that data,
00:21:20 having the right context accordingly. Okay, so this concludes the introduction of four sample
enterprise architecture use cases
00:21:30 and shows which SAP Business Technology Platform building blocks can be used to realize
such a use case.
00:21:38 In the next unit, we start applying the lean enterprise architecture toolkit for developing an
architecture for one of the sample use cases here
00:21:48 delivered on top of BTP. Thanks for listening.

15
Week 3 Unit 4

00:00:05 Welcome to week three, unit four, Applying the Lean Enterprise Architecture Toolkit with
SAP Business Technology Platform.
00:00:16 So, based on our knowledge of categorizing use cases, this unit introduces a sample use
case, which we use to develop
00:00:25 an architecture for the SAP Business Technology Platform using the lean enterprise
architecture toolkit.
00:00:33 So what we see on this slide here is our fictitious sample scenario. We work for a company
called Rocket Chips.
00:00:42 So Rocket Chips is designing and producing semiconductors and their silicon is actually
optimized to run machine learning algorithms.
00:00:52 The company was founded back in 2013 and is operating globally with research and
development locations in North America, Europe, and Asia.
00:01:05 Now researching a little bit about the structure of the semiconductor industry, we learn that
a unique feature of the industry is a continuous growth, but with high volatility.
00:01:18 Now, because of the volatility of the market, a high degree of flexibility and innovation is
required
00:01:25 to constantly adjust to the change in the market, as many products embedding
semiconductor devices
00:01:34 often have a rather short product lifecycle. Let's take a look at what is driving Rocket Chips.

00:01:42 So Rocket Chips want to become the global market leader for machine learning optimized
silicon.
00:01:49 Rocket Chips wants to achieve this goal by not only selling the silicon as OEM, but also
opening up direct B2C channels by offering additional services.
00:02:04 Let's look at the goals. As Rocket Chips recently went public to the stock market,
00:02:10 they want to grow fast and globally to satisfy their shareholders and the financial market. To
support a fast and global growth,
00:02:20 Rocket Chips wants a fast and effective deployment of the fresh IPO capital to support
business initiatives as well as R and D.
00:02:33 And generally, Rocket Chips considers innovation and adaptability as their sources of
competitive advantage.
00:02:44 Before we can start with our Architecture Development Method, using the lean enterprise
architecture toolkit,
00:02:52 we need to identify a use case, a request for architecture work. For a brainstorming activity,

00:03:00 we can use the previously introduced cheat sheet we're seeing on this slide. And starting
from business, we can decide to focus on one or several focus areas
00:03:13 and think about improvements supporting our business goals. Now reading from left to right,

00:03:20 once we have identified the focus area, we think about the type of value we would like to
achieve.
00:03:28 Are employees, for example, lacking necessary details and transparency for decision
support?
00:03:36 Or is Rocket Chips lacking capabilities that can be introduced via extension and integration
of different business processes?
00:03:46 Now, with a focus area and the type of value in mind, we continue thinking about the
approach we would take to deliver the identified value.
00:03:59 Do we need, for example, to integrate new data to support decision taking? Or do we need
to refactor an existing business process,

16
00:04:08 modernize the process with the higher usability and efficiency, for example? And last but not
least,
00:04:15 we might already think about the technical capabilities that are required to execute the
approach and deliver the value on the respective focus area.
00:04:27 It is worth mentioning that the cheat sheet we're seeing here is actually aligned to the
Architecture Development Method.
00:04:34 So we have the distinction between the business domain in blue and the technical domain
in orange.
00:04:40 And the content described in the column labelled Approach can be somewhat compared to
the solution concept,
00:04:49 generally describing what you want to do without mentioning technical details. The technical
details are actually mentioned
00:04:58 in the column labelled Required Technical Capabilities, which in turn can be compared to
the solution realization diagram,
00:05:07 which is mentioning product-aware solution, building blocks. The focus area and value
translates to activities you are doing
00:05:17 in the business domain of the Architecture Development Method. So, for example, the focus
area and the value are also
00:05:24 described in the statement of architecture work. The value is also expressed in the solution
context,
00:05:33 showing the main business capabilities of your aspired solution as well as the users and
roles interacting with it.
00:05:43 Now, throughout the course, we have always started our value discovery from the business
domain as it somehow feels more natural.
00:05:51 However, you might also start with the technology as a driver for your project, and in this
case you read the cheat sheet from right to left.
00:06:02 Maybe you have privately had the experience that a chatbot on a support site for your e-
bike was quite helpful
00:06:09 and you wonder if and how a bot can benefit your organization. Coming from the technology
side,
00:06:16 you continue researching the approach and requirements for implementing a chatbot and
maybe start playing around with your own chatbot.
00:06:26 So with the experience you had, you start to further explore a potential benefit and value in
the context of a focus area.
00:06:37 And by comparing the value with the technical requirements you have discovered earlier
while playing around with a chatbot,
00:06:45 you can already evaluate the feasibility of a chat bot to a certain extent. So this is how you
read the cheat sheet to find a request for architectural work.
00:06:58 Also, as I mentioned earlier, you can think of design thinking as a viable method to define
and understand your business problem as well.
00:07:07 Now for our sample use case, we consider that we already discovered that the budget and
request approval process
00:07:15 is a bottleneck for executing on our growth strategy. It takes way too long to evaluate,
00:07:22 approve, and release money to business development and R and D initiatives that actually
need to strengthen our innovation and adaptability.
00:07:34 And as previously mentioned, innovation and adaptability are actually two sources of
competitive advantage.
00:07:41 So we need to support them. Okay, so this is our request of architecture work,
00:07:47 improve the existing process for budget request and approval. This falls into the business
optimization process
00:07:57 and data enterprise architecture use case category we discovered in the last unit. Now,
projecting the concrete request of architecture work to the four playgrounds,

17
00:08:10 it is fair to say that this specific use case supports all areas quite equally. The use case
implementation is essential
00:08:19 to support our growth strategy at Rocket Chips. It also enables agility and business
innovation
00:08:25 and also supports the business development playground as well. And as the use case is
also reducing
00:08:33 the complexity of the existing process, it helps to manage complexity. And finally, the use
case also optimizes the daily business by improving the way
00:08:45 budget for new ideas is requested and reviewed and approved. Now bearing the BTP
architecture building blocks
00:08:55 and also solution building blocks in mind that we have mapped to this use case in unit three
will help us during the creation
00:09:05 of the solution concept and the solution realization diagram in later stages. So this is
important to remember.
00:09:14 So before we actually start our architecture development for the identified use case, we
decide which work products
00:09:23 from the lean enterprise architecture toolkit we would like to use. And this clearly depends
on our goal, time, and also official mandate to drive this project.
00:09:34 The mandate might get quite important as you need to consult and interview other teams to
get required input for your work products.
00:09:43 And also the availability of budget for investing into this project is also driving the decision of
work products.
00:09:53 And considering the case where no budget is approved for the project yet, and the results of
our architectural work,
00:10:02 is considered to be a basis for making this decision, you might want to create essential work
products helping to validate
00:10:11 the feasibility and viability of the proposed solution. And you can think of the concept of a
fast lane
00:10:22 and the concept of minimum viable architecture we have previously discussed. So this
concludes the introduction of our use case.
00:10:33 In the next unit, we look at sample work products for this use case, starting with the
business architecture domain.
00:10:42 Thanks for listening.

18
Week 3 Unit 5

00:00:05 Welcome to week three, unit five, Sample EA Artifacts for the Business Architecture
Domain.
00:00:14 In this unit, we look at sample work products from the business architecture domain that
describe our previously identified use case of improving the budget request
00:00:25 and approval business process for Rocket Chips. Looking at the list of 15 work products that
make up the lean enterprise architecture toolkit,
00:00:37 we decide to create the four work products, strategy map, stakeholder matrix, statement of
architecture work, and the solution context from the business domain.
00:00:50 As budget is not approved yet for our request and approval project, we decide to work on
the architecture principles, risk analysis and use-case blueprint diagram,
00:01:02 once we have approval and we'll start the implementation. So let's get started with the
strategy map.
00:01:10 The purpose of the strategy map is to have the ability of putting our budget request and
approval project into the context of Rocket Chips' corporate strategy.
00:01:23 How do we start creating the strategy map and what are good sources for information? Let's
stay here for a moment and consider
00:01:32 two scenarios influencing our sources of information. In Scenario A,
00:01:38 we are an employee of Rocket Chips and have access to all internal resources. In Scenario
B, we are external to Rocket Chips
00:01:48 and need to rely on publicly available resources or our network within Rocket Chips.
Sources in scenario A are strategy papers that are usually communicated actively
00:02:02 to us as an employee, or which we find in internal content repositories. Also the corporate
strategy department is a good internal source we might consult.
00:02:15 Now sources for scenario B are the Rocket Chips Web site, its annual report, or white
papers on strategic initiatives like a digital agenda, for example.
00:02:27 Those white papers are usually used for communicating to external stakeholders like
investors and partners for example.
00:02:36 Let's consider we run in scenario B, and we also will use all the insights we've learned about
Rocket Chips in the previous unit,
00:02:46 as well as publicly available information for creating the strategy map. Now, for creating the
strategy map, we use the template introduced in week two.
00:03:00 We find Rocket Chips' vision on their Web site. It is to create a world-changing technology
that enriches people's lives.
00:03:11 Continuing browsing the company profile on the public Web site, we learn about the
motivation of Rocket Chips and its drivers.
00:03:21 Rocket Chips wants to unleash the potential of artificial intelligence by reliable, scalable,
trusted data processing inspired by quantum computing.
00:03:34 And their corporate goal is to become the global market leader in technology optimized for
machine learning algorithms.
00:03:44 Now, what are the strategic goals that help to operationalize the corporate goal, the drivers,
and the vision?
00:03:53 While the vision, drivers, and corporate goals are often published on the external Web site,
information about
00:04:02 specific, operationalized, strategic goals are harder to find. We find some further information
in publicly available white papers
00:04:12 published by Rocket Chips for informing investors and stakeholders. And one white paper
addresses the so-called Global Growth Initiative 2025,
00:04:23 which was signed by the board. So in this white paper,
00:04:27 we learn that Rocket Chips' management defined a strategic goal for a fast and effective
approval of business initiatives,

19
00:04:36 as well as research and development projects to support their two sources of competitive
advantage, innovation, and adaptability.
00:04:47 This strategic goal is supported or is supporting the corporate goal we have previously
learned about,
00:04:55 namely to constantly grow and become the market leader for AI-optimized silicon. And the
objectives of this strategic goal are
00:05:07 to reduce the average approval time from 25 days to 2 days and to automate the processing
of the requests with confidence of at least 25% of the requests.
00:05:21 And the AI algorithms for this should run on Rocket Chips silicon. Okay, so much about the
strategy map.
00:05:30 Let's continue by looking at the stakeholders of our solution. Our main purpose for creating
00:05:38 the stakeholder matrix is to define and execute a communication plan. And by
understanding who has what type of interest in our solution
00:05:50 helps setting communication priorities and corresponding channels. The goal of actively
involving key stakeholders
00:05:59 is to get the support we need for a successful architecture development. So in the first step,
we identify our stakeholders by looking
00:06:09 closer at the business problem to improve the budget request and approval process. And for
this, again,
00:06:16 let's pick up the template for the stakeholder matrix previously introduced. So we start by
capturing all relevant players
00:06:26 that are affected or have an interest in our use case. For identifying stakeholders, let's think
about which business users are
00:06:36 affected by the budget request and approval solution. Also, who is influencing the solution
and who is interested in the success
00:06:45 of an improved budget request and approval process. For each stakeholder we have
discovered,
00:06:52 we continue by briefly describing their concerns and their motivation. And based on this, we
decide how to engage with them.
00:07:02 And hereby we use the previously introduced engagement types, key player, keep satisfied,
keep informed, and minimal effort.
00:07:12 Based on the engagement type, we then define the communication plan, also including the
work products
00:07:17 of the lean enterprise architecture toolkit that we want to share with the stakeholders. And
thereby, a stakeholder can be a contributor to the work product,
00:07:27 an approver of the work product, or just a consumer of the work product, for example.
00:07:33 So let's look at our use case. For the budget request and approval solution,
00:07:39 we identify Paul Jung being the CEO of Rocket Chips as a stakeholder. Paul wants to
understand how IT helps to advance business
00:07:50 by supporting the company's goals and objectives. As Paul doesn't have an active part in
our architecture development
00:07:59 but is an important stakeholder to convince, we keep him satisfied by aligning the statement
of architecture work and showing
00:08:08 how our architecture supports corporate strategy with the help of the strategy map. Julie is
the CFO and An is director of business development,
00:08:21 and both are key players that need to be actively involved in the architecture development.
Julie has a strong interest in the success of our project.
00:08:31 And by talking to Julie, we also learn that she's concerned by an enterprise-level adoption of
automation, leveraging analytics,
00:08:40 and connecting to other business units as well. An, as director of business development, is
interested in identifying and successfully

20
00:08:50 delivering projects that implement growth opportunities. She's also a key player and critical
for the success of our solution.
00:09:00 As Julie has a business background, we communicate our architecture via the solution
context.
00:09:06 As An has a technical background, we decide to communicate our architecture via the
solution concept.
00:09:15 Okay, having identified our stakeholders and defined a corresponding communication plan,
00:09:21 we continue with the statement of architecture work. And with a statement of architecture
work,
00:09:27 we describe the reason and the scope of the budget request and approval architecture
development project.
00:09:35 And here we remain rather high level and have in mind that this work product belongs to the
business domain.
00:09:42 So we are not mentioning any technical requirements or implementation-specific details yet.

00:09:50 Our audience for this work product is business people. So for this, we take our learnings
from the previously created strategy map as input
00:10:01 and we further reuse the stakeholder matrix and also what we have learned about the
business problem via the request for architectural work.
00:10:12 So looking at the template for the statement of architecture work, we can actually divide it
into two parts.
00:10:20 The first part, consisting of rows numbered one to four, describes our aspired solution or
use case that was previously identified
00:10:32 and communicated to us via the request for architecture work? The second part of the
statement of architecture work,
00:10:39 consisting of rows five to seven, has more a project management characteristic.
00:10:46 Now for our budget request and approval solution, we describe under row number two the
architecture project request and background.
00:10:56 With our project, we want to support the Global Growth Initiative twenty 2025 identified in
the strategy map,
00:11:04 namely by the design, the development, and operation of a solution that supports the
financing of projects
00:11:13 of more than 2,000 business development and R and D employees worldwide. Next, under
point three, we describe the scope of our architecture development project.
00:11:26 And in our case, the implementation of the solution is out of scope. Therefore, the scope of
our architecture development project is to plan
00:11:36 for the development of a finance request and approval workflow application that is
integrated with the existing financing system.
00:11:47 With our architectural work, we want to prepare required information for the budget approval
for our project
00:11:54 and lay the foundation for its implementation. In row four, we draw a simple high-level
picture that is visualizing the scope of our architecture.
00:12:06 The blue box we're seeing here labeled Budget Request and Approval Solution is in scope
of our architecture development.
00:12:13 And we already know that we have to integrate with the existing financing system.
Moreover, we can outline general users of the aspired solution,
00:12:23 such as a budget requester from the business development department or the R and D
department.
00:12:30 As well we have a reviewer and an approver. Now we get the required input for rows one to
four
00:12:38 mainly from the strategy map and the previously identified business challenge or use case
that is communicated to us via the request of architecture work.

21
00:12:50 Now in row five, we continue to name required project team members, roles, and their
responsibilities.
00:12:59 And for this we use our stakeholder map to find suitable candidates. But we also might
come up with new rows here.
00:13:08 In our sample case, we identify An as the director of business development at Rocket Chips

00:13:14 and a financial analyst from the finance department for supporting the creation and
validation of the work products from the business architecture domain.
00:13:24 For creating and validating the work products from the technical domain, we identify the
head of Rocket Chips IT and the lead developer,
00:13:35 as well as a technical architect from the vendors we choose for realizing the architecture
building blocks as support.
00:13:44 So we continue to describe and create the lean enterprise architecture work products that
we want to use for describing the budget request and approval solution,
00:13:57 and we state that we're using PowerPoint and MURAL for creating those work products.
Moreover, we decide to not create the risk analysis work product,
00:14:08 the architecture principles work product, and the use-case blueprint diagram. And the
reason for this is that the risk assessment is done
00:14:16 by a separate team due to compliance reasons, and we have decided to consider
architecture principles and user journeys
00:14:25 once the project has budget approval. Furthermore, we state in row six that An and Julie
must approve the business architecture
00:14:35 and the head of IT has to approve the technical architecture. For this, we need to define
concrete acceptance criteria for our architecture,
00:14:45 together with the director of business development, the CFO, and the head of IT. As the
scope of our project is to plan for the development,
00:14:55 acceptance criteria are rooted in the proposed license and implementation effort and
expected business process improvements in terms of reduced IT system complexity
00:15:08 and improved duration of working on a request. We skip this detailed description of these
acceptance criteria at this point.
00:15:19 And last but not least, in row seven, we state that the architecture project plan and schedule
will be delivered by the architecture roadmap work product
00:15:30 from the toolkit, and we will create a proposal for license and implementation costs based
on the solution realization diagram and the solution building blocks we have chosen.
00:15:43 So let's continue the development of our architecture by creating the solution context. The
goal of the solution context is to provide a high-level overview of our
00:15:55 budget request and approval solution that can be easily understood by business. And
please remember with a solution context,
00:16:04 we are still operating in the business architecture domain. Input for creating our solution
context is the previously created
00:16:13 statement of architecture work as well as the stakeholder matrix. Now in the first step, we
translate what we have learned so far about the required solution
00:16:25 into business capabilities that are describing what our solution can do. And these are some
sort of main functions
00:16:35 of the solution but expressed in business terminology. And this list doesn't need to be
exhaustive, so we can think of five to 10 main capabilities.
00:16:48 We take the title of our solution from the statement of architecture work and label the box
representing our solution accordingly,
00:16:56 Budget Request and Approval Solution. And then we think about the problem we would like
to solve,
00:17:03 stakeholder concerns from the stakeholder matrix, and our project request and background,
as well as the scope from the statement of architecture work,

22
00:17:14 to derive corresponding business capabilities that are describing our budget request and
approval solution.
00:17:24 We write these capabilities inside the box, which is representing the solution, and in our
sample, capabilities provided by our solution
00:17:35 are request project budget, get status of budget request, review and approve request,
00:17:43 obtain financial insights to assess, request, and trigger money release in financing system.

00:17:52 In a second step, we identify the different user groups and roles that are interacting and
using our request and approval solution.
00:18:01 Think about who is using the different capabilities we've previously described. For our
solution, we can group users to a reviewer group and approver group.
00:18:14 And there is the business analyst and accounting role who are reviewing the request. The
director of business development, the CFO, and the head of corporate strategy
00:18:25 are approving the request. Also, there are the requesters for project budget
00:18:32 from the Rocket Chips business development department and R and D. and we have
colleagues from the IT department
00:18:39 administering and operating the request and approval solution. From the statement of
architecture work,
00:18:46 we also know that the integration to the existing financing system is in scope to
automatically release the approved budget to the team.
00:18:55 As the financing system itself is actually not in scope of our project, we put it into a box with
a dash line.
00:19:05 Also, we can think of other aspects being part of the context of our solution, such as
corporate policies and rules for approving capital at Rocket Chips,
00:19:15 which are owned by the financing and regulatory compliance business unit. Like the existing
financing system, the definition of these roles is not in scope of our project
00:19:27 and is therefore put in a box with a dashed line. This concludes the work products and the
business architecture domain
00:19:37 with a strategy map, the stakeholder matrix, the statement of architecture work, and the
solution context,
00:19:44 we have a set of work products helping to communicate and validate our architecture
proposal with stakeholders from the business domain.
00:19:54 In the next unit, we start working on the technical architecture for Rocket Chips' budget
request and approval solution.
00:20:02 Thanks for listening.

23
Week 3 Unit 6

00:00:05 Welcome to week three, unit six, Sample EA Artifacts for the Technology Architecture
Domain - Part 1.
00:00:15 In this unit, we take a look at sample work products from the technical architecture domain

00:00:20 that describe our budget request and approval solution for Rocket Chips. So looking at the
content of the lean EA toolkit,
00:00:30 this unit focuses on the four work products, baseline solution architecture, solution
realization diagram,
00:00:39 solution concept, and the conceptual data diagram. And please remember,
00:00:45 when we create the solution concept and the solution realization diagram, we use our
architects view on SAP’s Business Technology Platform from unit two
00:00:58 for identifying suitable architecture building blocks and solution building blocks. Also, it is
important to point out that the solution context from the business domain,
00:01:10 the solution concept, and the solution realization diagram can all three be considered to be
a sequence of refinements.
00:01:21 So the solution context diagram defines our solution with the help of business capabilities.
And these business capabilities are then translated to architectural building blocks
00:01:34 in the solution concept. And now the solution realization diagram
00:01:40 shows how the architectural building blocks from the solution concept are realized by
corresponding solution building blocks.
00:01:51 And also all three diagrams highlight users and roles interacting with our solution and its
corresponding building blocks.
00:02:01 Okay, so much for a quick reminder. Let's get started with a baseline solution architecture
00:02:07 for the budget request and approval use case. So the baseline solution architecture
considers the current IT landscape components
00:02:16 that are relevant for the realization of our budget request and approval solution. And in our
case, we get all the relevant details
00:02:26 for the creation of the baseline solution architecture from the head of IT and the process
owner of the current process
00:02:34 for requesting budget and approving budget. So looking at the baseline solution architecture
for our solution,
00:02:42 we see that the requester sends an e-mail to a reviewer in its current process. So a
reviewer sends an e-mail to another reviewer, or finally to an approver,
00:02:54 optionally also storing the original request with some additional information on a file share
like SharePoint.
00:03:03 Now, the approver looks through the e-mails and also picks up additional information added
by the previous reviewers
00:03:11 from the file share or via documents attached to the e-mail. Now, both the reviewer and
approver consult SAP Analytics Cloud for assessing the request,
00:03:23 either by checking financial data or maybe also running a simulation. The data for the
analysis is provided via a data warehouse component,
00:03:33 and the data warehouse solution itself contains data from the Rocket Chips financing
system. So once the request is approved,
00:03:42 the approver releases the money via a corresponding application through the Fiori
launchpad.
00:03:50 The approval or rejection of the request is communicated via e-mail back to the requester,
either by the approver or by a reviewer.
00:04:01 Now, based on this understanding of the current IT components being involved in the
process implementation,

24
00:04:09 we will do a fit-gap analysis when we create the solution realization diagram. And with this,
we evaluate how we can evolve this baseline architecture
00:04:21 to a target architecture, which is addressing our statement of architecture work
00:04:27 by reusing existing IT components. And please remember,
00:04:32 in case your request for architecture doesn't address an existing process, you still want to
create a baseline architecture
00:04:41 to assess if there are existing solution building blocks in place that you can reuse. Okay, so
let's continue and take a look at the solution concept.
00:04:53 For the creation of the solution concept, we take the previously created baseline solution
architecture
00:05:00 as well as the solution context as inputs. And the goal of the solution concept is to describe
a high-level view of our solution.
00:05:11 We can understand the solution concept as a transition step between the solution context
and the solution realization diagram.
00:05:20 And for the creation of the concept, we translate the business-oriented capabilities,
00:05:26 describing our solution in the context to respective architecture building blocks.
00:05:33 And as previously mentioned, for this translation task, we use our architects view on SAP
Business Technology Platform from unit two.
00:05:44 So let's look at our budget request and approval scenario. So remembering our solution
context,
00:05:52 we said that our solution should be capable of requesting project budget. Furthermore, it
should be capable of reviewing and approving a budget request,
00:06:02 and also obtaining financial insights to assess the budget request. And finally, our solution
should also have the capability
00:06:12 to analyze and provide a central reporting for the requests and approvals. So for the
creation of the solution concept,
00:06:21 we translate these capabilities from the solution context to respective building blocks, and
also outline the relationships between those building blocks.
00:06:33 And please remember, relationships can be of type "request response", or the relationships
can also highlight the information flow
00:06:41 between the different building blocks. And also for creating the solution concept diagram,
00:06:48 we use icons that we introduced with a corresponding palette back in week two. Now, by
mapping the capabilities to architecture building blocks,
00:07:00 it might be the case that one business capability directly translates to one architecture
building block.
00:07:06 But on the other hand, it can also be possible that one business capability might translate to
two or more architecture building blocks
00:07:14 that relate to each other. So looking at the example here,
00:07:19 we see that the two capabilities of requesting project budget and obtaining the status of the
request
00:07:26 are translated to one ABB labeled “request status application”. And this ABB has a
relationship to a second ABB
00:07:36 labeled “review and approval application”, which relates to the business capability review
and approve budget request
00:07:45 from the solution context. And both previously mentioned ABBs also relate to a central
repository ABB,
00:07:54 which was not explicitly mentioned in the solution context, but we consider this a required
building block for managing all the information about a request.
00:08:04 Furthermore, we add a building block labeled “policies for budget approval”. As we know
from the statement of architecture work and the strategy map
00:08:14 that automation of budget requests is a goal, we introduce a building block that addresses
the respective corporate approval policies

25
00:08:24 by a rules framework, and is able to model and execute these rules via a workflow engine.
00:08:32 Now the two business capabilities to obtain financial insights to assess a budget request,
00:08:39 and also to have an analysis and central reporting in place are addressed by the dashboard
for analysis ABB.
00:08:48 We also see a relationship between the dashboard to the existing financing system, and
also the review approval application ABB
00:08:57 has a relationship to the financing system as well. Now, by thinking about the solution
concept,
00:09:04 we also add an ABB labeled “authentication/authorization” to our solution, as the users of
the solution have to authenticate for usage,
00:09:16 and depending on their role, like reviewer or requestor, have different privileges while using
our solution.
00:09:24 And last but not least, we take the roles requestor, approver, and reviewer from the context
without modification -
00:09:35 we just update their relationships to the respective building blocks those users are
interacting with.
00:09:42 Okay, so much about the solution concept. A good quality check for the concept
00:09:49 is actually to check if we have addressed all required business functions with corresponding
ABBs.
00:09:56 So now we have a good understanding of which ABBs are needed to realize the business
capabilities,
00:10:02 let's continue and think about how we are actually realizing these ABBs. And this is the task
of the solution realization diagram.
00:10:13 In the solution realization diagram, we take the high-level, ABB-based view of our solution
00:10:20 and translate the ABBs to respective solution building blocks, SBBs. And during this
translation step,
00:10:30 we basically do two things. The first thing we're doing is a fit-gap analysis
00:10:38 with the baseline solution architecture to see if we can reuse some of the existing
components
00:10:45 and map them to our solution. And the second step we're doing
00:10:49 is that we are then mapping all the ABBs from the solution concept to respective SBBs.
Now, in the first step of the fit-gap analysis,
00:11:01 we look at the previously created baseline solution architecture and identify components
that we want to reuse,
00:11:08 that are fitting our requirements. And in the second step, actually,
00:11:14 we have to make sure that we meet one prerequisite, namely, we need to define the
sources of suitable solution building blocks
00:11:23 we want to use in our architecture. Now, in our example,
00:11:28 this source is all the services provided by the SAP Business Technology Platform. And we
briefly explored some of those services back in unit two.
00:11:41 Now, further details about the BTP solution building blocks can be obtained via the SAP
Discovery Center,
00:11:49 and we will see a link to the Discovery Center on the next slide. So in step two, we think
about how we realized the ABBs
00:11:59 with SAP BTP solution building blocks and services. And also, please bear in mind that you
also have the option to implement your own SBBs.
00:12:11 And this custom development of SBBs can also be done with the help of other SBBs,
00:12:18 maybe those coming from the BTP SBB portfolio. Okay, so let's continue and look at our
sample scenario.
00:12:29 Now at first sight, the solution realization diagram really looks busy. So let's start step by
step.

26
00:12:38 Basically, what is worth mentioning in the beginning is that for drawing the solution
realization diagram,
00:12:43 we also pick up the icons we introduced back in week two. Now let's start by looking at the
legend on this slide.
00:12:53 And by looking at the legend, we notice that some SBBs will be implemented by ourselves.
And especially for those SBBs
00:13:02 we were not able to identify a suitable building block out of BTP's services catalog. So those
building blocks we are implementing by ourselves are highlighted in green color.
00:13:16 Now, furthermore, existing building blocks or existing components that we identified from
the baseline solution architecture
00:13:24 via a fit-gap analysis are highlighted with an asterisk.
00:13:28 So those are the components we are reusing and not introducing with our architecture.
Okay, so what do we see in the solution realization diagram here?
00:13:38 So first we are looking at the top. We see that all SBBs are realized via the SAP Business
Technology Platform.
00:13:46 You also see the link to the previously mentioned SAP Discovery Center, which provides
you with more details about the individual building blocks.
00:13:56 We see a building block representing the request and approval solution in green color here,

00:14:02 indicating that this is a custom-built building block. And within the request and approval
solution building block,
00:14:10 we see ABBs from our previous solution concept diagram, which is the request and status
application,
00:14:18 as well as the review and approve application. Now the other ABBs from the concept aren't
explicitly mentioned in this diagram.
00:14:27 However, the central repository ABB is translated to the SAP HANA Cloud SBB, and the
policies for budget approval ABB
00:14:40 translates to the two SBBs, workflow and business rules.
00:14:45 So we have a mapping here. Now, looking at the request and status application,
00:14:50 we see that this is a custom-built application implemented with SAPUI5 and Java.
00:14:57 The same is true for the review and approval application. And we also see that the review
and approval application
00:15:04 also includes the SAP Analytics Cloud, embedded edition for decision support. And as the
SAP Analytics Cloud is already part of the baseline solution architecture,
00:15:16 we consider this to be a reused component, as indicated by the asterisk.
00:15:22 It is also worth mentioning that the review and approve application integrates with SAP
S/4HANA
00:15:28 for triggering the money release once upon budget approval. So the request and review and
approval applications
00:15:39 are centrally accessed via the SAP Fiori launchpad, which is also part of the baseline
solution architecture,
00:15:47 as we can see it, as indicated with the asterisk here. And looking at the components within
the Rocket Chips data center now,
00:15:55 we see systems identified during the creation of the baseline solution architecture. So we
see SAP S/4HANA,
00:16:04 which is being accessed from the review and approve application. And we also see
BW/4HANA
00:16:10 providing insights being consumed via the Analytics Cloud building block. And finally we see
the identity authentication SBB,
00:16:21 which correlates to the authentication ABB from the solution concept. Again, we can check
the solution realization diagram for completeness
00:16:31 by verifying that each ABB from the solution concept is addressed by respective SBBs.

27
00:16:40 Now, looking at the information flow here between the SBBs, we see that SAP HANA Cloud
serves as a central repository
00:16:48 for storing all project information and also status information. And now to better understand
the information being processed by our solution,
00:16:59 we continue to look at our next work product, the conceptual data diagram.
00:17:05 Now for creating the conceptual data diagram, we think about the information that is being
required and/or processed
00:17:13 by our solution and its individual SBBs. And also thinking about how the individual users,
like a budget requestor,
00:17:24 interact with the solution helps to identify and to create the conceptual data diagram.
00:17:31 Please remember, if we created the use case blueprint diagram from the business domain,
we could have used this work product as input for this exercise.
00:17:42 So maybe it is worth considering creating the use case blueprint diagram in our next project.
Okay, let's look at a sample conceptual data diagram
00:17:53 for our budget request and approval solution. So what we want to visualize with the
conceptual data diagram
00:18:01 is the information being processed by our solution. And please keep in mind that we do not
take into account
00:18:09 which individual SBBs are now processing what part of the data diagram. Instead, we want
to create an overview of all the information
00:18:19 and how all the information or its individual parts relate to each other. So as our budget
request and approval application is a custom application,
00:18:31 we basically need to create most parts of the data model from scratch. Maybe it is worth
looking at the workflow building block
00:18:40 because this building block might also have some predefined data for describing and storing
workflow-relevant information.
00:18:49 So let's look at the sample here on this slide. We can maybe think of a central entity which
we name Project.
00:18:57 The central entity has several attributes, like a name, a description, and the amount of
requested budget.
00:19:05 And as we need to provide business goals and a purpose for project requests, we also have
a corresponding entity for this information.
00:19:14 And as we can see from the relationships here, one project can have many business goals,

00:19:20 and we define that a business goal must support exactly one purpose, whereby one
purpose can be supported by many business goals.
00:19:29 So this is shown by the multiplicities here on that slide. Okay, so much about the conceptual
data diagram for our use case.
00:19:39 And please note that the sample we are seeing here is not complete and serves as a
sample here.
00:19:48 Okay, so this concludes our first part of work products from the technical domain. In the next
unit, we cover the remaining work products
00:19:56 for describing our use case with artifacts or work products from the technical architecture
domain. Thank you very much for listening.

28
Week 3 Unit 7

00:00:05 Welcome to week three, unit seven, Sample EA Artifacts for the Technology Architecture
Domain - Part 2.
00:00:16 In this unit, we cover the remaining artifacts for our budget request and approval solution
from the technology domain.
00:00:24 And these work products, as we can see them on the slide here, are the software
distribution diagram, the environments and location diagram,
00:00:33 and the architecture roadmap. So both the software distribution and the environments and
location diagram
00:00:41 complement our architecture with a deployment view on the identified solution building
blocks and the architecture roadmap prepares further project planning
00:00:52 for the implementation of our use case. And it also helps to derive an estimation of the
implementation effort
00:01:00 and shows what business value is being delivered when. So let's start with a software
distribution diagram.
00:01:09 The purpose of the software distribution diagram is to show how our identified solution
building blocks are deployed on the Rocket Chips IT infrastructure.
00:01:19 And please remember, we understand our IT infrastructure, not just with what is inside the
four walls of the Rocket Chips data center,
00:01:29 but we think of a hybrid architecture in our case. So what do we need to create
00:01:35 or what do we need to do to create the software distribution diagram? So basically we take
our previously created solution realization diagram as input
00:01:46 and think about how the identified solution building blocks and especially also where those
solution building blocks are deployed.
00:01:55 So let's pick up the sample template from week two and use it in the context of our request
and approval solution for Rocket Chips.
00:02:07 Now, the template proposes a distinction between a cloud and an on-premise landing zone.

00:02:12 So this is our previously mentioned hybrid landscape. And during the creation of the
baseline solution architecture,
00:02:21 we have explored that the existing IT systems at Rocket Chips that are relevant for our
solution, which are S/4HANA and BW/4HANA, are deployed in our Rocket Chips data
center.
00:02:34 And therefore we place those two IT components into the on-premise landing zone on the
right-hand side on that slide.
00:02:43 Moreover, during the creation of the solution realization diagram, we have learned about a
required component called cloud connector for establishing
00:02:52 a trusted relationship between on-premise building blocks and cloud building blocks. And
this cloud connector component is also to be placed in the on-premise landing zone.
00:03:05 As a next step, we look at the solution building blocks and our solution realization diagram
that we have identified for realizing our budget request and approval solution.
00:03:16 And here in our scenario, all solution building blocks are either provided by SAP Business
Technology Platform or are custom developed.
00:03:27 Knowing that the SAP BTP solution building blocks are provided via hyperscaler
infrastructures,
00:03:35 we decide for one specific provider. Now typically, this information about which kind of
provider we want to use
00:03:44 is part of our architecture principles work product. And as we have decided not to create this
work product in our architecture development project,
00:03:55 we make an assumption at this point. Also, we want to make sure that all identified SAP
BTP solution building blocks

29
00:04:05 are provided by one provider in one data center. And in order to find out, we revisit the
previously mentioned
00:04:14 SAP Discovery Center and check on the details for the respective solution building blocks
and get an understanding of what kind of provider
00:04:23 and what data center those solution building blocks can be deployed to. Now, in our
scenario, all identified solution building blocks are provided
00:04:33 by our hyperscaler of choice and our hyperscaler of choice also provides
00:04:38 those solution building blocks out of the same data center. So that's good.
00:04:42 Now, looking at the cloud landing zone on this slide, we placed the respective solution
building blocks there,
00:04:50 and we also group the identified solution building blocks by an ABB, which we labeled
budget request and approval solution.
00:04:59 So now looking at this software distribution diagram for our solution, we see its hybrid
character and we have an understanding of how the different SBBs
00:05:09 of our solution are deployed across the hybrid IT infrastructure and landscape. Now, in our
next work product,
00:05:18 the environments and location diagram, we build upon this view here from the software
distribution diagram and add more detail.
00:05:28 So let's have a look here. So while the previously created software distribution diagram
focuses on showing
00:05:35 which SBBs are being deployed in which landing zone and basically outlining the hybrid
character of our solution,
00:05:45 the environments and location diagram adds further details with respect to the geographic
location of the individual building blocks
00:05:54 and also some network-related details in case we consider them relevant. And also, we
might add additional runtime- specific details to the individual building blocks
00:06:07 if we have them and if we also consider them to be relevant here for our solution. Now, with
the help of the environments and location diagram,
00:06:18 we better understand the interaction between the different building blocks, making up our
solution across different geographical locations.
00:06:27 And also what we are doing is that we are adding users or user locations to our
environments and location diagram
00:06:37 users that are interacting with our budget request and approval solution. So let's take a look
at our sample environments and location diagram for Rocket Chips.
00:06:47 Now, looking at the slide here, looking at the sample, we see the previously identified
landing zones that we have on the left-hand side,
00:06:56 the hyperscaler data center shown in gray, and on the right-hand side in orange, we're
seeing the Rocket Chips data center.
00:07:05 Now we add location-specific information to those two landing zones. So we have decided
to use the hyperscaler data center in Frankfurt
00:07:14 as it is geographically close to our Rocket Chips data center in Berlin that is running the
back-end components our solution is interacting with.
00:07:25 We also add the information that the hyperscaler data center is connected to the Rocket
Chips data center via public Internet.
00:07:34 And the connection to the existing IT components is done via the cloud connector
component, specifically connecting to S/4HANA.
00:07:43 And we also have added to more details by adding a Web despatcher component for
accessing BW/4HANA.
00:07:50 So these are some network-related and setup- specific information. So we consider the
connection via the public Internet strong enough for our solution,
00:08:01 and for now we assume that we have investigated this decision and concluded that the
public Internet is good enough.

30
00:08:09 And just a quick reminder here, such a decision is a good candidate for our architecture
decisions work product.
00:08:17 Also, we have decided to not create this work product here for our architecture project.
00:08:23 But again, this might be something we consider in our next project, documenting the
architecture decisions.
00:08:31 Now, looking back at the slide here, the green box on the slide shows the different office
locations from where
00:08:37 our budget request and approval solution is used. And as already indicated in the statement
of architecture work,
00:08:45 our solution supports employees worldwide at different research and business development
departments.
00:08:53 And we have also added some network details here in a way that the office locations have
an MPLS connectivity
00:09:00 to the back-end systems running in the Berlin data center. And this might be good to know
as the planned live connectivity of our analytics cloud, SBB,
00:09:11 might make use of this MPLS connectivity. Okay, so much about the environments and
location diagram,
00:09:20 we created thereby an overview about the different geographical locations of the users and
also of the solution building blocks making up our request and approval solution.
00:09:37 Okay, so let's continue with our last work product, the architecture roadmap. Now, with the
architecture roadmap, we enter the area of project management.
00:09:48 And with a roadmap, we basically create an overview of specific actions that need to be
done
00:09:55 in order to realize our request and approval solution. Now, for the creation of the roadmap,
we combine basically everything we have
00:10:05 learned so far about our architecture and about our solutions. So insights from all the
previous work products are basically combined and mixed up
00:10:15 while creating the architecture roadmap. So let's look at the sample roadmap for our Rocket
Chips solution here.
00:10:24 Now for the definition of suitable work products, which you're seeing here in the blue color,
for example,
00:10:33 we think about what steps need to be done to implement the previously identified
architecture building blocks and solution building blocks.
00:10:42 And also, we think about prerequisites that need to be in place. So, for example,
considering the access to the existing IT components
00:10:51 or the possibility of reusing existing IT components as we have identified them during the fit-
gap analysis might require some prerequisites we need to do.
00:11:03 Now, looking at the timeline of our sample roadmap, we have identified four phases. In
phase zero, we take care of all the identified prerequisites,
00:11:14 such as setting up the development environment, ensuring access to the existing S/4HANA
system
00:11:21 that is required also for releasing the money, also making sure that we can access the BW
system, and so on.
00:11:29 So this phase actually doesn't create business value yet. In the next phase, the phase one,
we build the foundation,
00:11:39 and again, we see that this phase doesn't create any business value yet, as foundational
work packages such as connection setup
00:11:48 and workflow definition must be done first. However, the implementation of the request and
status application
00:11:56 and the review and approve application will already start in this phase one. Now with phase
two, which is after four months,
00:12:07 we will create business value actually with the roll out of the MVP. And the scope of the
MVP is to manually review and approve the budget requests.

31
00:12:18 And with phase two, we also plan to provide the capability of an integrated money release
and we use the inbox application of the workflow service to work on the requests.
00:12:31 Also, the My Inbox app shall be accessible via the Fiori launchpad in this phase two and for
reviewing the requests,
00:12:40 analytic capabilities are already provided by respective reports and dashboards. However,
in phase two,
00:12:48 those reports are accessed separately and are not integrated into one solution yet. Now, in
phase three, we plan to increase the business value
00:12:58 by adding the automation capability for budget review and approval and also planning and
simulation capabilities for supporting the review of the requests.
00:13:10 And also all the functionality now in this phase is integrated into one solution being
accessible via the launchpad.
00:13:19 So after six months, we plan to have our solution live. So this last work product concludes
our unit and our architectural work
00:13:30 for the budget request and approval solution for Rocket Chips. And, as indicated in our
statement of architecture work,
00:13:38 a next step is to create a proposal for license and implementation efforts. And with this and
our set of created work products,
00:13:49 we finalize our architecture engagement and seek approval for the project. Once the project
is approved, we continue its implementation
00:13:59 and will reuse several of the work products we have created. So at this point, we hand over
to the implementation team
00:14:08 and use especially the work products from the technology domain for a quick ramp up of the
implementation team so the journey can go on.
00:14:19 Thank you very much for listening.

32
www.sap.com/contactsap

© 2021 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and serv ices are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possibl e future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this do cument is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/trademark for additional trademark information and notices.