openSAP

An Enterprise Architect’s View on SAP Business

Technology Platform
Week 1 Unit 1

00:00:05 Welcome to the openSAP course An Enterprise Architect's View on SAP Business
Technology Platform.
00:00:13 My name is Holger Seubert, and I'm working as a technical architect in SAP's technology
and innovation team.
00:00:21 So, this first week deals with an introduction to enterprise architecture, and we start the
week by taking a look at the purpose of enterprise architecture.
00:00:34 Let's start with a big picture by taking a look at the basic building blocks of every company.
So every company has some sort of vision
00:00:45 and purpose defining why the company is on the market. And it is worth mentioning that
making money is not a vision,
00:00:55 but instead should be a result of the company's vision and purpose. So, for example, SAP's
purpose is to help the world run better and improve people's lives.
00:01:08 Now, how do you realize the vision? For doing this, every company has a business
operating model
00:01:14 defining required roles and responsibilities and defining how those roles act together to
deliver on the purpose.
00:01:25 And also one very basic building block are the so-called business capabilities of every
company.
00:01:32 What do the business capabilities define? So basically, the business capabilities describe
what a company is capable of doing.
00:01:42 And, of course, there are business capabilities that you find basically in every company,
such as human resources or financing and accounting.
00:01:52 There are also business capabilities that can be considered to be more industry specific,
such as research and development, for example.
00:02:02 But now the big question is how do you bring those business capabilities into action? And
this is where the business processes enter the stage.
00:02:12 So it is the business processes that define how the business capabilities are actually
realized in your company.
00:02:21 And this is also the place where some differentiation between two companies can happen.
00:02:27 So one company might have other HR-related business processes than another company.
How do you realize and implement the business processes?
00:02:37 This is done with the help of applications and technology. And here you might decide to buy
a standard product off the shelf,
00:02:46 or you decide to develop your own business processes by a custom development project, or
as a third option, you'd use a combination of both,
00:02:56 you buy a standard product and then adapt and extend it to your individual needs. Now,
your company obviously does not live in isolation,
00:03:07 so there are constant external factors that might require a change or at least an adaptation
of your company's building blocks.
00:03:17 So, for example, you have constantly new IT trends popping up, machine learning, block
chain, IoT.
00:03:25 And what is the technical potential that those IT trends bring along? Do they improve some
business processes
00:03:33 or can they help you to make your customers even happier than today? Now, on the other
hand, there are also constantly changing market
00:03:42 and economic trends, such as mobility or dematerialization being a result of a continuing
digitalization.
00:03:52 And of course, there are your stakeholders, like customers or employees that have a
diverse and changing set of interests and requirements.
00:04:04 Now, mapping these external forces to the building blocks, it is fair to say that your
company's vision and its business operating model
00:04:15 and also its business capabilities can be considered rather stable. There might be market
disruptions or mergers and acquisitions that require a change here,
00:04:27 but this does typically not happen every year. On the other hand, business processes and
also applications and technology
00:04:36 being used to realize the business processes typically require a more frequent adaptation in
the context of the previously mentioned external factors,
00:04:47 such as changing market conditions or changing stakeholder demands. Now the question
is, how does enterprise architecture fit into this picture?
00:04:58 And the answer is quite easy. It is exactly the practice of enterprise architecture
00:05:03 that tries to align the different building blocks of your organization. And one of the very core
concepts of enterprise architecture
00:05:13 is to look holistically at your company by combining the business side with the technology
side.
00:05:22 It is worth emphasizing that over the past, let's say, two decades, a new capability has
become more and more important.
00:05:30 And this is data. Originally, data was just used for powering stateful
00:05:36 transactional applications in the area of logistics or HR, for example. But the importance of
data has changed.
00:05:46 Data has turned into one of the most valuable assets of your company, and you can
suddenly start thinking about scenarios where you can sell data as a product
00:05:57 or use data to sell complementary services to your existing portfolio. Or you can use data to
include more data points,
00:06:08 optimizing existing business processes along your value chain, or supporting decision
taking along your value chain.
00:06:16 Again, this capability of dealing with data is also something that is in scope of enterprise
architecture.
00:06:26 So, let's quickly summarize the goals of enterprise architecture. What do you want to
achieve by using an enterprise architecture practice?
00:06:35 So first, enterprise architecture helps to align IT investments to your company's business
goals
00:06:44 by taking this holistic view at both business and IT domains. Second, EA helps to manage
the complexity of your IT landscape
00:06:56 by utilizing synergies and executing on an aligned strategy. Third, EA supports the
communication between business and IT
00:07:08 by defining a common vocabulary that can be understood by both business and IT. Fourth,
EA helps with documenting decisions and landscapes
00:07:19 for possible follow up projects and further reference. And last but not least,
00:07:27 EA supports operationalizing innovations and new ideas for improvements by taking your
company's IT strategy and the existing investments into account.
00:07:41 Okay, so much we talked a little bit about the purpose and the goals of enterprise
architecture, but how do you actually do enterprise architecture?
00:07:52 Now, first of all, you always create an architecture for some sort of project. You have
identified a need of action,

2
00:08:02 a need to improve or change something in your existing business and IT landscape. And
now how do you describe the architecture of that specific project you want to deliver?
00:08:16 And basically you do this by a set of well-defined vocabulary, which is used to describe your
project's architecture,
00:08:25 by taking business and technical aspects into consideration. And what you do is that you
typically
00:08:32 describe some sort of current state of your architecture, which is the so-called base
architecture being relevant for your specific project.
00:08:43 And then you also define a future state, the so-called target architecture that is needed to
execute your proposed solution
00:08:53 to the business requirements you have discovered. Also, you're doing a gap analysis
00:08:58 by comparing the base architecture with the target architecture. And as a result of that gap
analysis,
00:09:06 you define some action items that need to be delivered. And then you also lay out those
action
00:09:12 items on a roadmap defining times, sequences, and milestones. Now, the vocabulary you
use for doing all this comes in different so-called work products
00:09:27 that you create when you define your architecture. And these work products basically
describe
00:09:33 your architecture from different viewpoints. And these viewpoints can be easily understood
by business and IT.
00:09:42 So that's important. Now, typical categories of work products are diagrams,
00:09:48 so visual representations, lists, but also catalogues. And we will see more concrete
examples of those work products in later units.
00:10:00 Now, having talked about the goals and how you basically do enterprise architecture, let's
wrap up the definition.
00:10:10 The architecture you define abstractly describes a construction of a solution, such as an
application, for example.
00:10:19 And it is worth emphasizing that one system or one application has exactly one architecture.
And this architecture can be communicated,
00:10:30 presented, and displayed in different views. And these views can have different levels of
detail and different focus areas.
00:10:40 You basically choose a view depending on what you want to communicate and who you are
talking to.
00:10:47 And again, we will discover more examples of those views in later units. Now, creating an
enterprise architecture
00:10:57 from scratch can be really, really time intensive. And this is the reason why so-called
00:11:03 enterprise architecture frameworks were created with the goal to simplify the process of
architecture development and guide you through this process.
00:11:15 Now, what does an enterprise architecture framework typically deliver? So it typically
provides a collection
00:11:21 of best practices, some guidelines and also tools and also templates that help you in order
to create and develop an architecture.
00:11:33 Some examples of enterprise architecture frameworks are the Zachman Enterprise
Framework and The Open Group Architecture Framework.
00:11:42 And also you find some vendor-specific frameworks in the market. Throughout our course,
we will build upon The Open Group Architecture Framework.
00:11:53 And therefore, let's summarize this unit by taking a look at the formal definition of enterprise
architecture as it is being done
00:12:03 by The Open Group Architecture Framework. So, what is the purpose of enterprise
architecture?
00:12:11 With the enterprise architecture, you describe A, the components,

3
00:12:16 B, the interrelationship between the components, and C, the principles and guidelines that
are governing the component design
00:12:27 and their evolution over time. So thank you for listening.
00:12:33 In the next unit, we will hear about a methodology to develop your architecture.

4
Week 1 Unit 2

00:00:05 Welcome to week one unit two, Architecture Development Method.

00:00:12 In this unit, we focus on how architectural work is done and focus on how you create an
architecture.
00:00:21 And therefore, we take a closer look at a methodology being defined by The Open Group
Architecture Framework.
00:00:30 And this methodology is called Architecture Development Method, or ADM for short. In our
previous unit one,
00:00:40 we briefly touched on The Open Group Architecture Framework and learned that it is one of
many different frameworks helping you to develop an architecture.
00:00:52 And we will continue consulting this architecture framework from The Open Group to better
get an understanding of how we are actually
00:01:01 creating such an enterprise architecture. Now, before we go into the details of the
Architecture Development Method,
00:01:10 let's take a quick look at the background of TOGAF. So, the development of TOGAF started
back in 1995, and the framework itself is
00:01:22 governed by an organization that is called The Open Group. Now, the goal of the
organization is
00:01:29 to develop an open and also vendor-neutral technology standard and also certifications for
developing an enterprise architecture.
00:01:41 The open group consists of a global consortium, that is to say, a diverse membership of
different
00:01:47 customers, vendors, suppliers from different industries, but also academics. Now, with the
evolution over the past decades, TOGAF got pretty comprehensive.
00:02:01 So you can easily attend a one-week course to obtain more details about the complete
framework.
00:02:09 We will only take a small sip of the framework, with a focus on the Architecture
Development Method, ADM for short.
00:02:20 Now, as we have defined enterprise architecture in the previous unit and the way that it
covers both business and IT,
00:02:29 it is not surprising that also the architecture development method picks up this concept and
reflects the necessity of addressing both business and IT.
00:02:44 And this is actually being reflected by the so- called architecture domains that somehow
describe and make the content of the architecture development method.
00:02:55 So we use these architecture domains to basically group or cluster the architecture work
products we create
00:03:05 with the help of the Architecture Development Method. Now, what are those four domains?
00:03:11 They are called business, data, application, and technology. So actually, it was not by
accident
00:03:20 that we also talked about exactly these aspects in our previous unit when we took a look at
the basic building blocks of every company.
00:03:31 Okay, so let's take a closer look at the Architecture Development Method. So we said that
you use the Architecture Development Method
00:03:42 for creating an architecture, and that architecture describes a specific project such as an IT
solution you want to deliver.
00:03:52 And obviously, this IT solution finds at least some motivation in a specific business need.
00:04:00 Now, what exactly is the ADM? In what steps do you exactly develop your architecture?
00:04:08 So let's take a look at the visualization you see here on that slide. The ADM can be divided
into different so-called faces and you see those faces

5
00:04:19 being represented by the different circles here in the visualization. Now, each of those faces
has a very specific focus.
00:04:30 And that focus is actually also being expressed by the name of the phase, business,
technology, for example.
00:04:39 Now, what are you doing within each phase? So within each phase,
00:04:43 you create either complete new architectural work products or you pick up work products
from the previous phase and add further details.
00:04:55 Now, bearing this in mind, you can understand the ADM to be a kind of sequential method.

00:05:03 So you really walk through the different phases step by step and exactly in the sequence as
it is being defined by the ADM.
00:05:13 However, it is worth emphasizing that you can also iterate between different phases or you
can even iterate within one individual phase.
00:05:25 And this is called an architecture development iteration. Now for the creation of work
products within the different phases,
00:05:36 TOGAF also provides guidelines and best practices. And these guidelines are defined by
the so-called Architecture Content Framework.
00:05:48 And you can understand the Architecture Content Framework as a kind of library of work
products, as a kind of guideline
00:05:57 defining how and what work products you can create within each individual phase. And we
will take a look at this architecture content framework later in this course.
00:06:10 Now, looking at the different phases, we will not cover all of the ADM phases in our course,
but instead we focused on the architecture vision, the business architecture,
00:06:23 the information systems architecture, and also the technology architecture phases. So let's
continue and take a closer look at those four phases.
00:06:36 Sticking to the sequence within the ADM, let's start with phase A, the architecture vision.
00:06:45 What is the goal of the architecture vision phase? Within this phase, you actually
understand and describe
00:06:53 the problem you want to solve with your architecture. You also start thinking about the value
your architecture adds to your company,
00:07:02 a so-called high-level aspirational vision of the business value you want to deliver by your
architecture.
00:07:13 Now, by defining the business value of your architecture, you also often pick up the strategic
goals
00:07:20 and take a look at the market drivers, as we have previously discussed, as some sort of
guideline for your architecture development.
00:07:30 And a central work product of the architecture vision phase is the so-called statement of
architecture work,
00:07:39 and maybe you can compare the statement of architecture work a little bit to a project
charter, because it is exactly this statement of architecture work where you describe
00:07:50 the reason, the scope, and also the expectations of your architecture work. Now, the second
phase we deal with is the so- called business architecture.
00:08:03 And in this phase, you create work products with a focus on the business aspects and the
business capabilities of your company.
00:08:12 Typically, you revisit business goals, objectives, as well as strategic drivers in your
respective market.
00:08:21 So, typical questions you answer are what is the business motivation behind your
architecture?
00:08:28 And how can you support your company's business goals with your architecture? You also
take a look at organizational aspects
00:08:38 such as stakeholders having an interest in your architecture work and you decide how to
deal with these stakeholder interests.

6
00:08:49 The third phase of the architecture development method we deal with is the so-called
information systems architecture phase.
00:08:58 And in fact, this phase combines two of the previously mentioned domains, namely the data
and application domains.
00:09:09 So in this phase, you describe your architecture's IT landscape from a data and also from
an application perspective.
00:09:18 And some typical work products you create are a solution concept diagram outlining the
basic building blocks of your proposed architecture.
00:09:30 You also continue describing the information being processed with the help of a so-called
conceptual data diagram,
00:09:39 just to mention two example work products. Now, especially when describing your
architecture
00:09:46 from an applications domain perspective, you also take a look at your existing IT landscape.

00:09:53 So you describe this existing IT landscape in the form of a base architecture, and then,
picking up the ideas of your statement of architecture work,
00:10:04 taking those into consideration, you start defining a target architecture that is supposed to
meet the required business needs.
00:10:14 A fourth phase we deal with is the technology architecture phase. So in this phase, you
describe your architecture
00:10:23 from a deployment perspective, considering hardware and also software components. The
data and application-specific description of the previous phase is being picked up here
00:10:36 and mapped to corresponding technology components like runtime environments or
hardware components.
00:10:44 So, for example, you might consider using some services of an infrastructure-as-a-service
provider or a platform-as-a-service provider
00:10:53 and start mapping and using those technical components here. Now, a typical work product
you create in this phase
00:11:01 is the so-called environment and location diagram. And in this diagram, you map your
architecture building blocks
00:11:09 to specific solution components like runtime or deployment components, also depicting
specific locations of data centers, for example.
00:11:20 Okay, so much about some of the key phases of the architecture development method we
focus on during this course.
00:11:30 The other phases of the ADM, which we will not cover, mostly address the implementation
of your architecture with respect to project planning,
00:11:41 governance, change management, and also requirements management. So for the full
lifecycle of a project, these are also very important phases.
00:11:52 But however, as we are focusing on obtaining an enterprise architect's view on SAP's
Business Technology Platform,
00:12:01 we will put those phases out of scope for this course. If you want to learn more about those
phases,
00:12:09 I recommend taking one of the TOGAF trainings. Okay, up to now we looked at the ADM
phases
00:12:17 that actually support and focus on the creation of an architecture. We also said that The
Open Group Architecture Framework divides
00:12:28 the creation of an architecture into the four domains as we can see them here, business,
data, application, and technology, BDAT for short.
00:12:40 Throughout the ADM phases, as we have learned about them, you create respective work
products and those respective work products,
00:12:50 describe your architecture in the context of those four domains. And by doing this, you
create a holistic description of your architecture

7
00:13:00 by, again, taking both business and technical aspects into consideration. Please remember
that we consider
00:13:09 the identification of a respective IT project as done. So we already know the area of
improvement and what we want to achieve.
00:13:20 We have described this in the statement of architecture work and we now use the ADM to
adequately describe how we want
00:13:30 to realize the improvements using technology. So the work products we create throughout
the ADM support the communication
00:13:39 between business and IT, they support decision taking, and lay the foundation for a
successful implementation and also operation of our proposed architecture.
00:13:52 So, let's summarize those four perspectives, those four domains. In the business
architecture,
00:13:59 you focus on your company's objectives, goals, and understand business capabilities and
business processes, implementing those business capabilities.
00:14:10 Also, you deal with organizational structures and respective stakeholders. In the application
architecture, you further describe the business processes
00:14:21 and describe individual services and applications supporting or implementing the business
processes.
00:14:29 Also, you describe the interaction and dependencies between these services and
applications.
00:14:37 In the data architecture domain, you focus on information and corresponding data your
architecture needs to deal with in order to support your company's goal.
00:14:48 You deal with the definition of information entities and describe how those information
entities flow between
00:14:56 the different architecture components, like application components, for example. Last but
not least in, the technology architecture domain,
00:15:05 you take a closer look at technology, infrastructure components, hardware, maybe also
specific software components
00:15:14 that are needed to support the data and application architecture domain. So all four
domains relate to each other
00:15:24 and deliver a complete enterprise picture of your architecture. In the next unit,
00:15:31 you will learn about your playground as an enterprise architect and see how you can use
the architecture development method in this playground.
00:15:43 Thank you for listening.

8
Week 1 Unit 3

00:00:05 Welcome to week one, unit three, Your Playground as an Enterprise Architect. In this unit,
we take a look at different impulses
00:00:17 that initiate your architectural work and push you on a playground. Furthermore, we start
exploring different areas
00:00:26 and use cases where those impulses can take you to. Let's quickly repeat the scope of your
architectural work.
00:00:35 As we've seen in unit one, you as an enterprise architect are the hinge between business
and technology.
00:00:45 On one side, represented by the color blue on this slide, you deal with requirements that are
rooted in business demands,
00:00:56 such as enhancements to existing business capabilities, maybe based on new data points,
or opening up additional revenue streams
00:01:07 by offering additional digital services to your products. On the other side, represented by the
color orange,
00:01:16 you deal with ideas that are motivated by technology, such as machine learning maybe to
improve the automation of existing business processes
00:01:28 or the use of IoT to obtain additional data points, improving process execution or decision
taking.
00:01:39 This can be summarized in two basic impulses that can initiate your architectural work,
business as a driver in blue, and technology as a driver in orange.
00:01:54 now motivated by changing customer expectations or the desire to improve internal
business processes, or the intention to grow in additional
00:02:08 product categories or market segments, the line of business typically formulates
requirements that need to be translated to technology.
00:02:19 So business is one typical driver for initiating your architectural work. Motivated by
evaluating and adopting
00:02:31 emerging technologies and also the new possibilities this technology offers, technology can
also be a driver for initiating your architectural work
00:02:44 and basically leading to the question of how a specific technology can add value to your
business.
00:02:53 Taking a look at the market conditions or stakeholder demands, you can find different
impulses.
00:03:02 So those two basic impulses originating from different areas in your organization can be
summarized typical triggers for your architectural work.
00:03:16 Now, where do those two impulses, business and technology, push you to? Let's take a
closer look at the two impulses and start defining your playground
00:03:30 as an enterprise architect by picking your CIO as the sample stakeholder. What are typical
questions and concerns your CIO might have?
00:03:43 Again, following the color coding, blue for business and orange for technology, concerns
and questions are rooted in those two basic categories.
00:03:56 Let's take a look at some business-related questions of your CIO. Where can technology
add more business value so that our technology departments
00:04:08 add more strategic value and turn into a business enablement? Or, looking at technology
related questions of your CIO,
00:04:20 how do I avoid shadow IT? And what type of best practices and standards do help here?
00:04:29 Generally, it is fair to say that all those concerns and questions can be mapped to two
categories.
00:04:38 Your CIO wants to improve A, strategic excellence and B, operational excellence. We
consider these two categories as basic cornerstones

9
00:04:53 for categorizing our architectural work that is helping us to understand our playground as an
enterprise architect.
00:05:03 What business relevance do these two categories have? Now, if your architectural work
improves strategic excellence,
00:05:12 your work is increasing the top line growth of your company. By opening up new revenue
channels, for example,
00:05:20 you are increasing the top-line growth. So you spend money to earn more money.
00:05:27 When your architectural work improves operational excellence, you spend money to save
money.
00:05:35 So here your work improves existing processes, powering existing revenue streams.
00:05:44 It is important to emphasize that your architectural work is not digital in a way that you either
improve strategic excellence or you improve operational excellence.
00:05:58 Typically, your enterprise architect use cases support both areas in parallel, but with a
slightly different weighting.
00:06:09 Now, let's continue to further define your playground as an enterprise architect. Besides the
cornerstones of strategic and operational excellence,
00:06:21 there is the dimension of the different architecture domains, defining some best practices,
and giving you guidance on how to act on the playground.
00:06:34 And we learned about those architecture domains in the previous unit. Again, what we see
on the slide are the two impulses, business and technology,
00:06:44 pushing you on the playground and initiating architectural work. So these are the
cornerstones of your playground
00:06:54 before architecture domains and areas of business improvement initiated by business
and/or technology, strategic excellence, and operational excellence.
00:07:08 Okay, let's continue by better understanding how you move and act on this playground. For
acting and moving on the playground,
00:07:19 you basically have two notions, exploration and exploitation. When you are exploring, your
architectural work
00:07:30 supports new business models, for example, with a focus on strategic excellence. This can
also be associated to a disruptive innovation, for example.
00:07:43 When you exploit, on the other hand, your architectural work improves existing business
models with a focus on operational excellence.
00:07:55 And this can be associated with an incremental innovation, for example. Let's further
describe your playground
00:08:04 by adding four typical areas of engagement within your company. One area of engagement
is strategic work.
00:08:15 Here, you are planning your organization's strategy, defining a tactic for execution of the
strategy,
00:08:22 and finally operationalizing the strategy within your organization. A second area of
engagement as business development.
00:08:33 Generally, here you look for areas of business innovation or business transformation. The
third area is IT management, focusing on operation, cost reduction,
00:08:47 and managing the complexity of the IT landscape. And the fourth area is optimizing the
alignment between business and IT
00:08:58 in a way of improving the daily business. Now, areas of engagement can be associated
00:09:07 with the two cornerstones, strategic excellence and operational excellence. When your
architectural work supports strategy and business development-related goals,
00:09:19 your architecture can be considered as an explorational architecture, supporting strategic
excellence.
00:09:27 On the other side, when your architectural work improves the alignment between business
and IT or IT management in general, your architecture can be considered to be

10
00:09:39 an exploitation architecture supporting operational excellence. So, what do you further need
to actually move and play on this playground?
00:09:53 So, far we have defined the cornerstones and four typical areas of engagement. As a good
player, you also need a tactic.
00:10:05 And for executing a tactic, you actually need players. We can understand an actual tactic to
move and act on the described playground
00:10:17 as different enterprise architecture use cases, and we will further explore those use cases in
later units with more details.
00:10:27 So generally you deliver the use cases that are defining your tactic via projects.
00:10:36 And those projects are actually executed with the help of the Architecture Development
Method we learned about in the last unit.
00:10:46 In order to play your tactic, you can get help from different players. Those players, in a form
of, for example, building blocks,
00:10:57 like solution building blocks or architecture building blocks help you to realize your
architecture supporting a specific use case.
00:11:07 Okay, so much about the definition of your playground as an enterprise architect. Let's wrap
up this unit by taking a look at four sample enterprise architecture use cases
00:11:22 that can be linked to the areas of engagement and also their contribution to strategic and
operational excellence, respectively.
00:11:33 Please remember, your EA use cases are not digital in a way that they support exactly one
area of engagement or are either contributing
00:11:43 to the strategic excellence or operational excellence. The spectrum of results is denoted
00:11:50 by the different circles here on that slide, having different sizes. So your architectural work
results in a mix of different levels of improvements.
00:12:01 Let's take the first use case on the slide, technology management: standardization and
homogenization.
00:12:09 Again, the color coding denotes the origin of the impulse for this use case. And again, blue
is for business and orange is for technology as a driver.
00:12:23 So, the technology management use case is triggered by technology and has a clear focus
in the areas of IT management
00:12:32 and optimizing the daily business between IT and business in a certain way with a better
alignment.
00:12:42 Now, however, when standardizing on specific technology, you might also support strategic
directions,
00:12:50 such as cloud computing or improving business agility by making software easier and faster
accessible for the lines of business, for example.
00:13:01 So this is, again, a spectrum of results delivered by this first enterprise architecture use
case. Let's take a second example and take the business capability management use case.

00:13:15 Here indicated by the color coding, this use case is motivated by business.
00:13:22 And looking at the circles, we see a focus on strategy and business development because
we improve what our company is capable of doing.
00:13:33 For example, by introducing a completely new business capability, like experience
management, for example, we help operationalizing our company's strategy
00:13:44 by quantifying brand, product, and customer experience, for example. Also, we support
business development
00:13:52 by these additional insights to product and brand experience. Now, in our next unit, we pick
up one of these four sample use cases
00:14:04 and take a closer look at how to actually develop a respective architecture using different
types of building blocks.
00:14:14 Thanks for listening to this unit.

11
Week 1 Unit 4

00:00:06 Welcome to week one, unit four, Sample Enterprise Architecture Use Case.
00:00:14 In this unit, we take a look at a specific enterprise architecture use case
00:00:19 to better understand the work you are doing as an enterprise architect. We also start looking
at some typical work products
00:00:29 you create while doing architectural work, that is to say, while using the Architecture
Development Method.
00:00:37 Now, the sample enterprise architecture use case we look at is business optimization and
here we focus on business processes and data processing.
00:00:52 Picking up the definition of your playground from the previous unit, this use case contributes
mainly
00:01:00 to optimizing the daily business, but also delivers improvements in the areas of IT
management and business development,
00:01:10 as can be seen by the different circles on the slide here. So a use case supports both
operational excellence and strategic excellence.
00:01:22 Now, what are potential triggers for initiating the use case business optimization
00:01:29 with a focus on processes and data? Again, the color coding indicates the direction
00:01:36 from which a potential impulse for starting your use case can come. Business-motivated
triggers, indicated by the color blue, can be unclear
00:01:49 responsibilities or redundancies along the business process, or inconsistencies when
executing the process, or coverage gaps,
00:02:00 simplification potential, or organizational fractures, for example. Technology might motivate
improvements by adding automation, or by reducing media
00:02:14 and system breaks along the process execution. One methodology to explore and discover

00:02:21 potential areas of improvements for a business process is design thinking, for example.
00:02:29 Picking up our previously defined two impulses, business and technology, which can trigger
architectural work,
00:02:38 we can overlay these impulses with four dimensions that can guide the value discovery
process.
00:02:47 Starting from left to right, that is taking business as a driver, you can start thinking about the
focus area of your business process improvement.
00:03:00 Do you want to deliver customer-focused, product-focused, employee-focused, ecosystem-
focused, or maybe capability-focused improvements?
00:03:12 Next, you can think about the type of value your improvement should deliver. Do you want
to improve the digital experience,
00:03:21 or do you want to improve automation, support the decision taking along the business
process,
00:03:28 or do you want to enhance the process by adding additional steps and increase its end-to-
end reach?
00:03:36 Having identified the focus areas and value, you can start thinking about the approach to
deliver the value.
00:03:45 Do you want to modernize the existing process by refactoring? Do you want to extend the
process by adding new functionality?
00:03:55 Do you want to reduce data silos? Or do you want to improve the self-service ability of
specific aspects of the process?
00:04:06 Last but not least, you start mapping your approach to technical capabilities that are
required to deliver the approach and associated value
00:04:17 in that respective focus area you have identified. And these technical capabilities can range
from chatbots, machine learning,

12
00:04:27 robotic process automation, workflow management and many other capabilities, maybe also
in the area of integration, analytics, and so on.
00:04:39 Now, what do we want to do? Which business process do we want to improve
00:04:45 and how do we want to improve the process? Let's take a look at a fictitious company,
Rocket Chips.
00:04:54 Rocket Chips is a global semiconductor company, designing and producing units that are
specialized to run machine learning algorithms.
00:05:07 Now, what are the drivers for Rocket Chips? First, they want to become the global market
leader
00:05:15 for these special semiconductors that can run machine learning algorithms.
00:05:21 To become a global market leader, they want to grow into new market segments, that is,
00:05:28 address additional customer segments by new digital services. Their goals are to grow fast
and to grow globally, and to do so,
00:05:39 one strategic goal, which is supported by the CEO, is to offer a fast and also effective
deployment of capital
00:05:49 for new business initiatives and research and development projects. Rocket Chips wants to
innovate organically
00:05:58 instead of founding an incubation or innovation lab. They want to keep their new ideas as
close to business as possible.
00:06:09 So one of the first exercises to understand the current process of requesting and releasing
money
00:06:17 for new business initiatives and R and D projects is to understand this current process.
00:06:26 And this is what we see here on this slide in the form of a baseline process flow diagram.
00:06:33 Such a process flow diagram is one example of an architectural work product you can
create throughout the usage
00:06:42 of the Architecture Development Method. As we can see in this example, the process flow
diagram shows
00:06:52 the sequential flow of control between activities and typically uses swim lanes
00:06:59 to represent ownership and realization of individual process steps. In addition, the process
flow also shows information about events
00:07:11 that trigger or result from the completion of a process step. Our example shows a process
flow that seems to have a high technical depth.
00:07:23 Different systems are involved and these systems are siloed along the organizations that
participate in the process.
00:07:31 It appears that additional systems and applications need to be consulted to make decisions
along the process.
00:07:39 Also, it looks like data is duplicated between the siloed systems. And yeah, generally there
is a lack
00:07:47 of transparency for the budget requester about the current status of the request. Now,
because of the necessity of involving different organizations,
00:07:59 such as business development, corporate strategy, and finance all using their own way to
review and process the request,
00:08:11 the process duration is rather long and has high associated process costs. Having analyzed
and understood the current process, in the first step,
00:08:24 you continue thinking about how to improve the process. So let's take a look at the value
discovery cheat sheet
00:08:33 we discovered before. Can we identify already some areas of possible improvements?
00:08:40 Again, starting from the business side, we can categorize our business process of
requesting and releasing money
00:08:49 to be quite employee centric and also business capability centric. Our focus is to improve
the way employees request money.

13
00:09:01 And we want to improve our company's ability to release money for strategic projects
supporting the overall growth strategy.
00:09:12 From a capability perspective, we are touching R and D and financing, for example.
00:09:18 From a value perspective, we intend to improve the usability by enhancing transparency
and reducing technical depth.
00:09:28 Maybe there is automation potential and clearly improvements on decision support along
the approval process.
00:09:37 Potential technical capabilities can be more intuitive user interfaces, a rules engine
supporting the automation,
00:09:46 and also the integration of different systems to improve the decision support and also the
automation.
00:09:56 Now, with this in mind, we can start working on our target architecture
00:10:01 by thinking about a pencil sketch, a high-level vision of our proposed solution.
00:10:10 One outcome of our thoughts can be a desired target process flow for requesting, reviewing,
and releasing the budget for those new business cases.
00:10:21 Now, what do we see? To eliminate inefficiencies in communication
00:10:26 and also to increase transparency and to decrease wait times, all the silos are replaced by a
central
00:10:35 capital request and approval solution, which also integrates the financing system to
automatically release the money once it is approved.
00:10:46 Due to the integration of the financing system, organizational breaks can be reduced from
five to four.
00:10:55 And due to the corporate guidelines, further improvements is not possible here. So all the
remaining organizations need to be kept involved in the approval process.
00:11:06 However, by realizing a central request and approval solution, we can reduce the switch
between IT systems to one.
00:11:16 Now, another very common work product you can create to describe your architecture is a
so-called solution concept diagram.
00:11:26 And the solution concept diagram can be considered as a very rough idea of your
envisioned solution to the business problem.
00:11:36 And in that diagram, you outline basically the high-level building blocks that are making up
your proposed solution.
00:11:46 You also show the relationship and the dependencies between the different building blocks.

00:11:51 And you can also add organizational information, such as user types or roles, for example,
00:11:59 For our example, we can think of the central capital request and approval solution
00:12:05 to be comprised of different building blocks, such as an application for requesting budget
and obtaining status information about the request.
00:12:16 And then there is the necessity to offer functionality for reviewing and approving a request.
00:12:23 And this is also represented by an individual building block here in our diagram.
00:12:28 Corporate rules and guidelines for the review process can be expressed via a workflow
engine,
00:12:35 and rules for automating the review can be represented via a rules engine. Again, two
additional building blocks making up our solution architecture.
00:12:48 Yeah, we also need analytics capabilities to actually evaluate the budget request in terms
of,
00:12:55 yeah, the overall financial situation, opportunities, market potential, and more. And this is
represented by a dashboard building block
00:13:05 called Project Budget and Analysis. Last but not least,
00:13:11 we also include the financing system in our solution concept diagram. Now, the different
types of arrows you see

14
00:13:19 indicate the relationship between the building blocks. We can distinguish between
information flow, represented by a dashed line,
00:13:29 as it can be seen between the financing system and the dashboard, or the Review/Approval
building block, for example.
00:13:38 A second type of relationship, which is expressed by a solid line, is a request and response
relationship between the building blocks.
00:13:49 And so user groups, for example, interacting with specific building blocks can be associated
to those building blocks
00:13:57 with such a request and response type of relationship. So to summarize, we can use this
solution concept diagram to discuss and share our
00:14:10 initial thoughts on solving the business problem. And the diagram can be considered to be
one specific view on our architecture.
00:14:22 And the previously seen business flow diagram is a second view on the same architecture
or solution,
00:14:29 depicting different focus areas and a different angle on the solution proposal. Okay, let's
quickly summarize.
00:14:39 We looked at a sample enterprise architecture use case for requesting and reviewing
budget requests for our fictitious company, Rocket Chips.
00:14:51 And the use case we have touched on falls into the category of business process
optimization,
00:14:59 with the intention to increase the operational excellence by improving an existing process.
00:15:07 And for doing so, we analyzed the current process, and with the requirements to speed
things up and give more transparency
00:15:16 for the requester, and also better decision support for the reviewer, we came up with a
solution concept and a target process flow diagram.
00:15:27 So we basically did our job. We understood our stakeholder's pains,
00:15:32 did a root cause analysis, and used problem solving techniques, such as value discovery to
directly respond to our stakeholder's concerns.
00:15:42 So we pretty much did everything described, what we see here in the red box on that slide.

00:15:48 However, when designing your architecture, it is worth looking at additional opportunities
00:15:56 that can also be addressed with your architecture as well. So are there any related
unarticulated needs,
00:16:04 and what does your architecture look like when taking these unarticulated needs into
account?
00:16:12 In our example, there are additional request and approval type workflows within Rocket
Chips,
00:16:20 and all of those request workflows have a high technical depth due to the fast growth during
the past years of the company.
00:16:29 And therefore, there might be future evolutions of our architecture, also taking maybe travel
approvals into account, for example.
00:16:40 So you can think of extending your architecture vision by also taking these potential future
projects into account.
00:16:49 In our example, our solution concept describes a central request and approval solution,
00:16:56 also integrating further transactional back-end systems, such as a travel management
system or a procurement system, for example.
00:17:07 Now, by looking at this sample EA use case, you've got a brief overview of what you are
basically doing when developing an architecture.
00:17:17 We also introduced two architecture work products that you can use to describe your
architecture,
00:17:24 the process flow diagram and the solution concept diagram. In the next unit, we start taking
a closer look at more architectural work products

15
00:17:35 you create during the Architecture Development Method. Thank you very much for listening.

16
Week 1 Unit 5

00:00:05 Welcome to week one, unit five, Architectural Work Products. Creating architecture work
products is one of your primary tasks
00:00:16 when developing an architecture. You use these work products to describe, document, and
discuss your thoughts.
00:00:25 In this unit, we explore a content framework for creating architectural work products.
00:00:32 This content framework is based on TOGAF and should serve as an orientation when we
create work products in later units.
00:00:42 Now, what is the value of a content framework? The idea behind a content framework is
00:00:49 to enable the consistent creation of architecture work products. The framework also gives
you some guidance
00:00:57 on what type of architecture work products can be created. And this is done by the so-called
content metamodel, as can be seen on this slide.
00:01:09 As the name implies, the content metamodel describes how you can create architectural
content.
00:01:19 Now, looking at the color coding of the metamodel, you discover the previously introduced
00:01:25 phases of the TOGAF Architecture Development Method, and also the four domains,
00:01:32 business, data, application, and technology. So the content metamodel gives you some
ideas
00:01:41 about different architectural work products you can create for defining your architecture.
00:01:48 One thing to remember is that the framework and its content metamodel do not describe the
exact layout and visualization of the work products.
00:02:00 The metamodel defines core ingredients, but the rest is actually up to you. Also, you are
free to choose which work products you consider as helpful.
00:02:13 TOGAF does not mandate to use all the described work products you're seeing here.
00:02:19 It is more a guidance you tailor to your individual needs and desires. Now, clearly in the
beginning, you don't know what architectural work products
00:02:31 can actually be useful for your architecture development. So this is something we will
continue discovering in this course.
00:02:39 So at the end, you have a handful of work products you can start with, and can continue to
extend over time.
00:02:49 Let's revisit the Architecture Development Method introduced in unit two. In unit two, we
saw that the ADM
00:02:58 consists of different phases. Within each phase,
00:03:03 you either create new work products or update existing work products from the previous
phases.
00:03:12 In our course, we focus on phases A to D. These are also the phases where most
architectural work products are created,
00:03:22 the following phases being out of scope for our course, focusing on implementation and
governance-related tasks.
00:03:32 What type of architectural work products now can you distinguish? Again, we're referring to
the definitions
00:03:40 by the TOGAF framework and its content metamodel, as previously mentioned.
00:03:46 There you find work products that are called deliverables, and you can view a deliverable as

00:03:53 a container or a folder including other work products. Deliverables are used during review
cycles
00:04:03 and are officially signed off by the stakeholders. Typically, deliverables are living documents

17
00:04:10 like all the other work products as well, and have multiple versions and evolve while you are
developing your architecture.
00:04:19 Now, what is the actual content of such a deliverable? These are the so-called artifacts or
work products, as we also name them.
00:04:29 Artifacts or work products are basically the core ingredients of your architecture.
00:04:37 And this is actually what you will develop most of the time. And artifacts can come now in
different forms.
00:04:46 There are lists or catalogs of different applications, for example.
00:04:52 We also distinguish matrices or have matrices showing, for example, the version
deployment status and location of applications,
00:05:02 and we also have diagrams that are visually showing, for example, the data flow between
two or more application components.
00:05:12 And there is a third architectural work product, which is called building block.
00:05:18 A building block is generally a component that can be reused and also combined with other
building blocks.
00:05:27 Basically, your architecture consists of different building blocks that are abstracting certain
functionality
00:05:35 that is required to meet the identified business need. Most of the time, we will focus on
creating artifacts or work products,
00:05:45 and most of the work products we create are actually diagrams. Now, while creating
diagrams,
00:05:52 we will also make use of the previously mentioned building blocks. So on this slide, we see
a visual representation
00:06:01 of the relationship between the different architectural work products. Often you create a so-
called architecture definition document,
00:06:11 a deliverable which describes your complete architecture with all its views. As mentioned,
the architecture definition document is a deliverable.
00:06:22 It is a container and contains all the artifacts that are actually describing your architecture.
00:06:29 And these artifacts, describing your architecture now can be, for example, a process flow
diagram,
00:06:36 as we have seen in the previous example in unit four, or a so-called solution realization
diagram,
00:06:44 which we will cover also in more detail in later units. And also the combination of two and
more artifacts can describe one and the same
00:06:56 building block from different viewpoints, as we can see on this slide as well. Now focusing a
little bit more on the idea of building blocks, it is worth mentioning
00:07:10 that TOGAF defines two categories of building blocks: A, architecture building blocks, ABBs,

00:07:18 and B, solution building blocks, SBBs. Now, generally, a building block is a package
00:07:27 of functionality that addresses a specific business need. The solution your architecture
describes
00:07:36 is built up from several of those building blocks that interoperate with each other.
00:07:43 And obviously building blocks can also be assembled by other building blocks. Now, what is
the difference between
00:07:52 architecture building blocks and solution building blocks? Architecture building blocks
represent and describe a functionality that is
00:08:02 required to realize a specific business capability. You can map ABBs to business units or
organizational units.
00:08:13 We will create ABBs in the context of a specific work product, the so-called solution concept
diagram,
00:08:22 also later in this course. And ABBs direct and guide also the development and choice of
SBBs.

18
00:08:31 That's how both relate to each other. Solution building blocks
00:08:36 now define what products and components will implement the functionality, and SBBs are
therefore typically product and vendor aware.
00:08:49 And you can either develop a solution building block on your own or you can procure a
solution building block from a specific vendor.
00:09:00 And yeah, usually there is a relationship between ABBs and SBBs, and looking at our
example of the central request and approval solution,
00:09:11 we have identified several ABBs, such as a review and approval application ABB, for
example,
00:09:19 which addresses the business requirements to review and decide on specific budget
requests for new projects.
00:09:29 Now this ABB can be associated to SBBs that describe vendor or product-specific
components needed for implementing the ABB.
00:09:41 In our example, this could be a workflow management service SBB offered by a specific
vendor, for example.
00:09:51 While you are creating different architectural work products, you are creating different views
on the architecture of your solution,
00:10:01 and by this, you create a holistic picture of your solution, and describe actually what you
want to do.
00:10:10 And these different views on your architecture also help express different aspects that need
to be considered when
00:10:18 implementing, deploying, and operating your solution. And you can choose views that
describe more aesthetic and structural aspects
00:10:29 of your architecture, such as the runtime environments or deployment locations of your
architecture, building blocks, for example.
00:10:38 And also looking at this slide here, you can use more dynamic views for describing the
architecture of your solution, by using, for example,
00:10:49 a process flow diagram or a software collaboration diagram. Important to remember is that
you always
00:10:58 describe exactly one architecture, one system, one solution, using different views, showing
different aspects and details.
00:11:10 Let's look at some sample work products to make the idea of artifacts or work products a
little bit more tangible
00:11:18 at this point. And we have seen a work product called
00:11:24 solution concept diagram already in unit three. So this is a typical work product you create
quite early in your architecture
00:11:34 development process, namely in the architecture vision phase of the TOGAF Architecture
Development Method.
00:11:43 As the name implies, this is a conceptual idea of what the architecture of your solution
00:11:52 to the business problem actually can look like, or looks like. The solution concept diagram
00:11:59 shows the architecture building blocks making up your solution. You might want to use a
separate document describing these building blocks
00:12:08 with respect to their interfaces, further features, and information about maybe scalability,
manageability, and other details.
00:12:18 So the solution concept diagram is an example of a diagram artifact. Another example of an
artifact is
00:12:28 a so-called architecture principles catalog. As the name implies, this artifact is of type
"catalog".
00:12:36 The architecture principle catalog lists all the constraints and guidelines you should consider
when developing your architecture.
00:12:46 Typically, these guidelines, such as technology or engineering guidelines, are centrally
managed

19
00:12:53 and governed in your company, and reflect strategy and corporate culture. In case you don't
have principles defined yet,
00:13:02 you might want to choose to skip these guidelines or take a look at some of the sample
principles in the TOGAF documentation,
00:13:13 following the link you see on that slide here. Now, generally, the definition of principles is
good practice
00:13:22 as it helps you to validate your architecture. Now, what are typical examples of such
principles?
00:13:29 Let's pick some samples from the TOGAF framework. So here you find, for example,
00:13:35 a principle which is called "data is an asset", which basically means that data is treated like
a valuable asset in your enterprise
00:13:45 and it is shared across your enterprise, for example.
00:13:51 Now, another sample artifact is the stakeholder map, which we see here, which is of type
"matrix".
00:14:00 As a good stakeholder management is really vital to make your architecture a success, you
use the stakeholder map to better understand all the stakeholders
00:14:11 of a solution and your architecture, respectively. On the one hand, you classify the
stakeholder position
00:14:20 in terms of ability to disrupt your architecture, the required understanding, current and
required commitment,
00:14:28 and things like required support, for example. Now, based on this classification,
00:14:35 you can derive an appropriate stakeholder management approach for each of the
stakeholders you have identified.
00:14:43 So set up some sort of communication plan, maybe, set up meetings, identify how you want
to stay in touch with the stakeholders.
00:14:51 Now, if the stakeholder has a high level of interest and has high power, let's treat this
stakeholder as a key player.
00:15:00 If the stakeholder has, on the other hand, a low level of interest and a low ability to disrupt
your architecture, keep the efforts on a minimum level.
00:15:11 Okay, so in this unit, we learned some fundamentals about architectural work products
00:15:18 and how TOGAF helps with the content metamodel to create architecture work products
00:15:25 describing your architecture. In the next unit, we discuss some challenges of enterprise
architecture.
00:15:33 Thank you for listening.

20
Week 1 Unit 6

00:00:05 Welcome to week one, unit six, The Challenges of Enterprise Architecture. As usual, there
is no methodology that fits all situations.
00:00:19 There are always exceptions or the need to adjust the original idea. And this is also true for
the Architecture Development Method we have discovered so far.
00:00:32 So in this unit, we take a more critical look at the ADM to understand possible pitfalls. Now,
during the last years,
00:00:43 we used several different ways to describe the challenges of IT by taking a look at how the
world is changing.
00:00:52 And for this, trendy terms like volatility, uncertainty, complexity, and ambiguity were
introduced, for example.
00:01:02 And basically, these are characteristics describing some of our external factors we
previously defined,
00:01:10 external factors that require a change of some of the building blocks making up our
company.
00:01:19 Now, a fifth characteristic we can add is speed. Often associated with digitalization in
general,
00:01:28 the speed of how markets evolve, stakeholder requirements change, customer segments
change has increased a lot.
00:01:38 Now, considering IT-powered business processes as a vital part of the central nervous
system of your company,
00:01:48 these business processes need the ability to react to these external factors. The way they
react is defined and governed by enterprise architecture.
00:02:01 That's why we are here. So it is fair to say that the qualities of enterprise architecture
00:02:08 or the way you are developing an architecture also need to adapt to the changing conditions
around your company.
00:02:18 And this leads to a picture of a bimodal IT, introduced also several years ago, leading to
different speed layers
00:02:28 within your corporate IT landscape. An agile layer, speed layer one,
00:02:35 designed to react quickly to the changing market conditions of a volatile, uncertain,
complex, and ambiguous world,
00:02:44 and a speed layer two, focusing on qualities like stability, governance, reliability, control,
and standardization.
00:02:56 Typically, agile methodologies are associated with speed layer one, whereas enterprise
architecture methodologies, with a focus on operational excellence,
00:03:08 are associated with speed layer two. So this picture of two speed layers describes some
sort of transition phase
00:03:18 in which existing best practices are complemented with new best practices.
Organizationally, this often leads to different departments, or even new spin offs,
00:03:32 focused purely on speed layer one and getting rid of most of the operational aspects
associated with speed layer two that need to be considered by, let's say,
00:03:44 bigger grown companies, but might slow down project execution. Now, one challenge in this
setup is to make sure that
00:03:55 the ideas and projects in speed layer one do not lead to fundamentally different IT sub-
landscapes within your company
00:04:06 that cannot be operated and maintained economically, or one-off projects that have,
obviously, a high degree of innovation
00:04:17 but lack the integration into the existing business processes of your company. Now on the
other hand, looking at the speed layer two,
00:04:28 a challenge is also that you do not just focus on operational excellence, but also embrace
new ideas being incubated by speed layer one.

21
00:04:40 So the conclusion is to ideally have a methodology for developing an architecture that can
deal with both speed layers,
00:04:50 a methodology that allows you to shift gears in between your architecture development
process. If we try to visualize such a methodology, we can reuse the visualization of
00:05:05 a lean development process shown on this slide. As usual, you start with an idea,
00:05:12 a trigger to improve something motivated by business or maybe a new technology, maybe
you want to improve an existing business process
00:05:22 or want to improve an existing product with a complementary new digital service. You start
exploring and validating your idea.
00:05:32 Does the idea have potential? Is it viable, is it feasible, and is it realizable?
00:05:40 The goal is to test a solution problem fit. And here you are operating clearly in speed layer
one, creating a minimum viable product.
00:05:52 Now, picking up our previous thoughts, it would be ideal to also develop a minimum viable
architecture,
00:06:00 ensuring that our minimum viable product does not only fit the problem, but is also sort of
compatible to the operating and development and deployment environment
00:06:13 where it should grow after a successful validation. And this minimum viable architecture
00:06:21 can be considered as the entry ticket to speed layer two, which takes care to constantly
improve the idea by taking enterprise requirements
00:06:32 such as the existing IT landscape, security, and more into consideration. Following this
approach,
00:06:41 you address the previously described attributes, volatility, uncertainty, complexity, and
ambiguity by the corresponding antipodes,
00:06:52 as we can see them on the slide, vision, understanding, clarity, and agility. Mapping this
approach to our previous picture,
00:07:03 we can conclude that we need different IT strategies to deal with requirements motivated by
external factors.
00:07:13 What we need is a pioneer mode, where we explore new business models and ideas, and
this is the area of strategic excellence
00:07:22 we also defined as a part of our playground as an enterprise architect. Characteristics of
this mode are speed and agility,
00:07:32 creativity, and also an innovation culture. And we also need an enterprise mode,
00:07:39 where we execute our proven business models with excellence. Again, this is also an area
00:07:46 that we have previously identified as a playground for an enterprise architect.
Characteristics of this enterprise mode are stability, sustainability, compliance,
00:07:59 standardization, regulatory and also security demands. And obviously, there is a friction
between these two modes.
00:08:08 The friction between the pioneering mode and an enterprise mode and making sure that
your pioneering idea
00:08:15 is not burned by this friction or gets stuck on its way from pioneering to enterprise operation,
we consider architectural thinking or architecture development method
00:08:28 as a helping methodology to pull your idea over from speed layer one to speed layer two.
Now, this pull over mechanism, realized with the help of enterprise architecture,
00:08:44 is something that can be considered as a characteristic of enterprise architecture that is not
traditionally there,
00:08:53 but needs to be added to the practice. If we think from the direction of speed layer one,
00:09:00 we can say that this characteristic helps us to operationalize innovation. And the other way
around,
00:09:09 if we think from the direction of speed layer two, we can say that this characteristic realizes
a broader approach of enterprise architecture.
00:09:20 The way we look at the required characteristics of enterprise architecture in our course is by
a combination of creative thinking and architectural thinking.

22
00:09:32 The SAP AppHaus, for example, has defined a methodology called human-centered
innovation approach,
00:09:38 supporting creative thinking for developing new ideas, to derive new business models, or
also to derive optimized business processes.
00:09:50 So, while enterprise architecture and its architecture development method builds a bridge
between business and IT,
00:09:59 the human-centered innovation approach builds a bridge between users and business. And
now, with a combination of both methodologies, we extend the reach of our
00:10:12 architecture development method we have described so far. The goal of this combination is
to extend the architecture development method
00:10:21 with additional services specifically tailored for speed layer one. And, vice versa, we can say
that
00:10:30 we also enhance the human-centered innovation approach methodology with additional
services, specifically for speed layer two.
00:10:40 This extended view on enterprise architecture and architectural thinking concludes our first
week.
00:10:48 In the next week, we continue elaborating on the idea to combine architectural thinking with
design thinking.
00:10:56 And we also learn more about concrete architectural work products that you create for
describing your architecture.
00:11:05 Thank you for listening.

23
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.