BUSINESS AND IS DESIGN

TABLE OF CONTENTS
Lecture 1 : Architecture thinking in digital transformation. .................................... 5
What is an architecture ? ............................................................................................. 5
Stakeholder perspective ............................................................................................................... 5
Systems architecture vs enterprise architecture ............................................................................ 6

Enterprise architecture ............................................................................................... 6

Enterprise architecture vs city architecture ................................................................................... 6
Typical structure and components ................................................................................................ 6

The LEGO Case ........................................................................................................... 7

Lecture 2 : EA Frameworks and Modeling Notations .............................................. 9

Zachman Framework .................................................................................................. 9
Framework Structure .................................................................................................................... 9
Perspectives : Rows ..................................................................................................................... 9
Abstractions : Columns .............................................................................................................. 10
Implementation ......................................................................................................................... 10
Pros & cons ................................................................................................................................ 11

Enterprise Architecture Modeling with ArchiMate ....................................................... 11

ArchiMate Core Model ................................................................................................................ 11
Filling the Zachman Framework with ArchiMate ........................................................................... 12
Archimate Notation .................................................................................................................... 12

Lecture 3 : Enterprise Architecture Modeling with ArchiMate ............................... 13

Examples of elements ................................................................................................................ 14
Archimate Viewpoints ................................................................................................................ 15
Relationships summary .............................................................................................................. 15
Business layer ............................................................................................................................ 17
Application layer ........................................................................................................................ 18
Technology layer ........................................................................................................................ 20
Layered Viewpoint ...................................................................................................................... 22

Additionnal Viewpoints ............................................................................................. 24

Application Usage Viewpoint ...................................................................................................... 24
Application Structure Viewpoint .................................................................................................. 25
Application Co-operation Viewpoint ............................................................................................ 25
Technology Usage Viewpoint ...................................................................................................... 28

Assessing the quality of an EA model ......................................................................... 30

Main requirements ..................................................................................................................... 30
Syntactical correctness (Firmitas) ............................................................................................... 30
Semantic correctness (Utilitas) ................................................................................................... 31
Pragmatic correctness (Venustas) .............................................................................................. 31
Validation by Meta-Model ........................................................................................................... 31
Lecture 6 : TOGAF Framework ............................................................................ 33
Step A : Architecture Vision ....................................................................................... 33
Stakeholders Viewpoint .............................................................................................................. 34
Principles viewpoint ................................................................................................................... 34
Goal Refinement Viewpoint ........................................................................................................ 35
Summary of the new elements .................................................................................................... 35

Step B : Business Architecture ................................................................................... 36

Business Function Viewpoint ...................................................................................................... 36

Step C : Information Systems Architecture................................................................. 36

Application Cooperation Viewpoint ............................................................................................. 37

Step D : Technology Architecture ............................................................................... 37

Requirements Realization viewpoint ........................................................................................... 37

Step F : Migration Planning ........................................................................................ 38

Implementation and Migration Viewpoint .................................................................................... 39

Transition Architecture in Step F ................................................................................ 40

Migration Viewpoint – Transition Architecture .............................................................................. 41

Transition Roadmap in Step F .................................................................................... 41

What Is An Enterprise Architecture Framework? ........................................................ 42

Lecture 7 : Strategic Planning (1) ........................................................................ 44

Introduction ............................................................................................................. 44
EA In practice ........................................................................................................... 44
The three circles ......................................................................................................................... 45

Strategic Planning : Overview and Practices ............................................................... 45

Business architecture ............................................................................................... 46
Which architecture views and artifacts constitute the business architecture?............................... 47
Main Approaches of business architecture .................................................................................. 47

Business Model ........................................................................................................ 48

Value Streams .......................................................................................................... 48
Operating Model ....................................................................................................... 49
Four types of operating models ................................................................................................... 49

Capability Models and Maps...................................................................................... 51

Capability Heat-Map ................................................................................................. 53
Road-mapping and migration planning ....................................................................... 54
Capability road-map example ..................................................................................................... 54

Capability realisation model ..................................................................................... 55

Basic Example ........................................................................................................................... 55

Lecture 8 : From Strategic Planning to Programs & Projects (SP 2) ....................... 57

 How to use a capability map? .................................................................................... 57
How to link Capabilities to Applications and Infrastructure Components .................... 58
Example: Capabilities to applications ......................................................................................... 58

Project Lifecycle ....................................................................................................... 59

Scope & Focus ........................................................................................................................... 59
Architecture-Practices in Programs & Projects............................................................................. 59
Architecture reviews and coaching.............................................................................................. 59

Agile vs Waterfall ...................................................................................................... 60

Scaled Agile Framework (SAFe).................................................................................. 60
Portfolio ..................................................................................................................................... 60
Agile Release Train (ART)............................................................................................................. 61
Agile Teams (Scrum) ................................................................................................................... 61
Mapped in Archimate ................................................................................................................. 61
Emergent Design vs. Intentional Architecture .............................................................................. 61
Architectural runway .................................................................................................................. 62
Scrum ........................................................................................................................................ 63

Lecture 9: LeanIX .............................................................................................. 64

Shadow IT ................................................................................................................. 64
Reasons for Shadow IT ............................................................................................................... 64
Risks of Shadow IT ...................................................................................................................... 64

Simple EA Metamodel ............................................................................................... 64

Data-Driven Enterprise Architecture .......................................................................... 65
Use-Cases ................................................................................................................ 65
SAP S/4HANA Transformation ..................................................................................................... 65
Data Flow analysis ..................................................................................................................... 66

Lecture 10: Portfolio Management & Project Life-Cycle ....................................... 67

Traditional Software Projects .................................................................................... 67
Agile Methods (SCRUM, SAFe) ................................................................................... 67
Product Backlog ......................................................................................................................... 67
Sprint Backlog ............................................................................................................................ 67

User Stories – Product Backlog and Prioritization ....................................................... 68

More on SAFe ............................................................................................................ 68
Breaking down Business Features into User and Enabler Story ..................................................... 68
Role of Architects in SAFe ........................................................................................................... 69

Requirement Analysis ............................................................................................... 69

Requirements vs. Design ............................................................................................................ 69
Not the same requirements everywhere ...................................................................................... 70

Lecture 12: Requirements and Solution Design ................................................... 77

Industry 4.0............................................................................................................... 77
 Requirements ........................................................................................................... 77
How to find requirements ........................................................................................................... 77
Document Analysis & Observations ............................................................................................ 77
Participatory Design / Contextual Design ..................................................................................... 78

Lecture 13: Operations & Monitoring .................................................................. 79

Scope & Focus .......................................................................................................... 79
Architecture-Driven Practices ................................................................................... 79
Architecture Artifacts................................................................................................ 79
The challenge ........................................................................................................... 79
EA in Operation & Monitoring ..................................................................................... 80
Strategic & Operational Changes Differences .............................................................................. 80
Collecting & Tracking Requests for Operational Changes: IT Service Management ........................ 80
Identifying EA-Relevant Operational Changes .............................................................................. 81
EA & IT Service Management Tools Should Be Tightly Integrated ................................................... 81
EA Monitoring: Measuring EA Complexity by Means of the Point Costing Concept.......................... 82

Exercices .......................................................................................................... 83
Open Questions ........................................................................................................ 83
Q1 ............................................................................................................................................. 83
Q2 ............................................................................................................................................. 83
Q3 ............................................................................................................................................. 84
Q4 ............................................................................................................................................. 85

Ressources ....................................................................................................... 86
Default capability map .............................................................................................. 86
LECTURE 1 : ARCHITECTURE THINKING IN DIGITAL TRANSFORMATION.
This is the beginning of the Part I of the course, named Motivation: Architecture Thinking in Digital
Transformation.

WHAT IS AN ARCHITECTURE ?
An architecture is the art and science of designing complex structures.

Every system has an architecture (even a system composed of one component)

Architecture defines the rationale behind the components and the structure

Architecture represents the set of earliest design decisions

• Hardest to change

• Most critical to get righ

STAKEHOLDER PERSPECTIVE

1. Owner: At the top of the hierarchy, the owner is the key

stakeholder who initiates the project and whose interests and
requirements drive the entire construction process.

2. Architect: Directly under the owner, the architect plays a pivotal

role, serving as the visionary who translates the owner's
requirements into a viable design and architectural plan. The
architect is responsible for the overall aesthetics and functionality
of the building.

3. Specialized Roles (Mason, Carpenter, Electrician, Interior Designer, etc.): These roles are
represented by the descending arrow, indicating their execution of the architect's plans. Each
specialist contributes specific skills.

Architecturing models require aligning different stakeholders’ viewpoints.

Models help people to communicate: A model is more precise than written language.

Models explain and make predictions: A model relates primitive system components to one another
and to complex components, providing explanation and predictions about the behavior of the system.

Models help mediate among multiple viewpoints : Two people frequently won’t agree with what
they want to know about a component; models represent their commonalities while allowing the
differences to be explored.
SYSTEMS ARCHITECTURE VS ENTERPRISE ARCHITECTURE

ENTERPRISE ARCHITECTURE
Video explanation

Enterprise Architecture (EA) is the fundamental structure of an entreprise, of an organization, either as

a whole, or together with partners, suppliers and / or customers (“extended enterprise”), or in part
(e.g. a division, a department, etc.). Describing (Modeling) at an Aggregated Level the essential
components and relationships of an entreprise. As well as the principles governing its design and
evolution.

EA is used to guide the transition from the current state (as-is architecture) to the future state (to-be
architecture) of the organization, aiming to optimize often fragmented legacy processes into an
integrated environment that is responsive to change and supportive of the delivery of the business
strategy.

ENTERPRISE ARCHITECTURE VS CITY ARCHITECTURE

Enterprise architecture applies the same methodology as the “common” architecture. Both need to
understand the foundation of the system that they are creating, and they both are dealing with different
stakeholders that have different interests, needs and requirement for the project. For instance, you
can consider a house from the perspective of his future owner, or from the perspective of the city
planner. The same can be established with the enterprise architecture: the different systems of an
enterprise are described through multiple viewpoints and different kind of relationships.

Also, it develops an AS-IS/TO-BE methodology for documenting and planning purpose.

TYPICAL STRUCTURE AND COMPONENTS

The typical structure with its components of an EA is:

• The strategy (customers, markets, products and services, business goals, capabilities)
• The processes (activities, roles, ...) and organisation (organizational units and hierarchy,...) The
information systems:

The information systems:

• Data (data objects, attributes, database...),

• Applications (software, functionality,...)

• Integration (interfaces, protocols, ...)

• Infrastructure (System software, devices, network, ...)

THE LEGO CASE

Background and Crisis: The LEGO Group, established in 1932, became synonymous with its iconic
LEGO bricks. By 1995, the company faced severe challenges due to increased competition and the
advent of digital entertainment like video games. Efforts to diversify its product line and expand into
theme parks did not yield the expected benefits, leading to a complex and costly operation. By 2003,
LEGO was in a financial crisis, with a significant operating loss.

Initial Transformation and Business Restructuring: In 2004, Jørgen Vig Knudstorp was appointed
CEO, marking the beginning of significant changes at LEGO. His strategy focused on addressing supply
chain inefficiencies and re-centering the business around the LEGO brick. This involved cutting down
the number of unique elements produced and reducing the supplier base, which streamlined
operations and reduced costs.

Building a Core Enterprise Platform: Around 2000, LEGO initiated "LEGO Light" to implement SAP
and standardize processes, which was pivotal in restoring financial health. By 2005, these measures
had turned the company's fortunes around, showing a profit.

Extending the Platform: Post-initial success, LEGO continued to enhance its enterprise platform by
integrating HR systems, developing a global manufacturing platform, and implementing a product
lifecycle management system. These efforts facilitated global expansion and faster product
development, contributing to robust growth during the global recession of 2008-2009.

Digital Strategy and Transformation: By 2015, LEGO no longer viewed digital as a separate strategy
but as an integral part of its business operations. This shift was embodied in the adoption of digital
tools and platforms across the company, enhancing decision-making and operational efficiency.

Digital Engagement and New Products: LEGO ventured into digital-enhanced products like the "Life
of George" and "LEGO Fusion," which combined physical bricks with digital play. They also launched
"LEGO Ideas," a platform allowing customers to propose new LEGO sets, accelerating product
innovation and involving consumers in product development.

Challenges and Future Directions: Despite these successes, LEGO continued to face challenges in
adapting to rapidly changing digital landscapes and consumer behaviors. The company recognized the
need for a digital workforce and more agile, innovative business processes that could leverage digital
technologies effectively.

Conclusion: As of early 2016, LEGO was well on its way to becoming a digital enterprise but
acknowledged that this transformation would be a continuous journey. The leadership was focused on
leveraging digital capabilities to maintain its competitive edge and relevance in the increasingly digital
world.

*Phase 3 : Growing Digital Engagement

LECTURE 2 : EA FRAMEWORKS AND MODELING NOTATIONS
From now on, we are on the Part II of the course, named Foundations: Enterprise Architecture &
Frameworks and Modeling

ZACHMAN FRAMEWORK
It is the first EA framework.

FRAMEWORK STRUCTURE
The Zachman Framework is structured as a matrix comprising six rows (perspectives) and six columns
(abstractions), where each cell represents a specific focus area. All cells need to be filled in order to
define a system architecture.

PERSPECTIVES : ROWS
They represent concern relevant to each stakeholder in the organization.

Each row addresses the architecture from a different perspective, aligning with various roles within the
organization:

1. Executive Perspective (Contextual/Scope): High-level overview focusing on the scope and

boundaries of the enterprise.

2. Business Management Perspective (Conceptual/Enterprise Model): Focuses on the

business concepts and how they interact.
 3. Architect Perspective (Logical/System Model): Details the logical systems and their
relationships, defining what needs to be done.

4. Engineer Perspective (Physical/Technology Model): Converts the theoretical models into

physical systems, detailing implementations.

5. Technician Perspective (Detailed Representations/Out-of-Context): Focuses on specific

details of each system, usually devoid of the broader context.

6. User Perspective (Functioning Enterprise/Operational): Deals with the actual operation

and functioning of the systems.

ABSTRACTIONS : COLUMNS
Each column represents a different aspect of the enterprise, asking key questions:

1. Data (What): What information is relevant to the system?

2. Function (How): How does the system operate?

3. Network (Where): Where are the components located?

4. People (Who): Who are the stakeholders and users?

5. Time (When): When do processes occur?

6. Motivation (Why): Why are decisions and processes executed?

IMPLEMENTATION
Each cell within the matrix is filled with specific artifacts related to both the row's perspective and the
column's abstraction. This comprehensive approach ensures that every aspect of the architecture is
addressed in detail, aiding in decision-making and strategic planning. The goal is to provide a holistic
view of the entire enterprise from abstract concepts to concrete implementations.

In practice, it is challenging to fill the Zachman Framework due to:

• Lack of a methodology covering all aspects of the framework

• Lack of a well-defined respository storing the framework in accordance with integrity rules

• Lack of a popular modeling notation

Basically we don’t really know what to put in those cells !

PROS & CONS
Advantages Disadvantages
Well-organized: Provides structured support Lack of Defined Models and notation: Does
for organizing architectural models, also not specify models or notations, which can lead
covers a wide range of subjects. to ambiguity in implementation.

Intuitive: Easy to understand and apply to No design process: Does not support the design
various types of architectural documentation. process itself, limiting its application in practical
scenarios.

ENTERPRISE ARCHITECTURE MODELING WITH ARCHIMATE

This is why in practice we will use ArchiMate in this course to do Enterprise Business Architecture.

ARCHIMATE CORE MODEL

• The Business layer is about business processes, services, functions and events of business
units. This layer “offers products and services to external customers, which are realized in the
organization by business processes performed by business actors and roles”.

• The Application layer is about software applications that “support the components in the
business with application services”.

• The Technology layer deals with “the hardware and communication infrastructure to support
the Application Layer. This layer offers infrastructural services needed to run applications,
realized by computer and communication hardware and system software”.

ArchiMate full model is enriched by additional layers:

• The Strategy layer helps to incorporate the strategic dimensions and goals.

• The Physical layer is about “physical equipment, materials, and distribution networks”.
FILLING THE ZACHMAN FRAMEWORK WITH ARCHIMATE

ARCHIMATE NOTATION

Those three layers form together the layered view.

LECTURE 3 : ENTERPRISE ARCHITECTURE MODELING WITH
ARCHIMATE
ArchiMate allows to depict several layers and aspects of an enterprise architecture in one diagram.

BUT: Not everyone needs to know everything! As we said, there are different stakeholders in the
modeling process.

In ArchiMate, architects and other stakeholders can define their own views on the enterprise
architecture.

• A viewpoint in ArchiMate is a relevant subset of the ArchiMate concepts and their relationships:

• It is aimed at a particular type of stakeholder and addressing a particular set of concerns.

• It can be used to view certain aspects in isolation, and to relate two or more aspects.

• For each viewpoint one kind of model exists.

• A view is (a set of) models:

• It represents a part of an architecture.

• It is specified by viewpoints.

So the viewpoint is essentially a template of specification to construct a view. The view is the actual
represantation of the viewpoints in archimate.
An architecture description comprises multiple views, each addressing specific stakeholder concerns
according to certain viewpoints. Each viewpoint frames stakeholder concerns and sets conventions
for views, such as notations and modeling methods. A view, governed by its viewpoint, consists of
architecture models that use these conventions to address relevant concerns effectively.

EXAMPLES OF ELEMENTS
What are business interfaces to communicate with the customer?

• Website and Mobile App: Digital platforms where customers can browse products, place
orders, and manage their accounts.

• Customer Service Desk: A physical or virtual interface for addressing customer inquiries,
complaints, or service requests.

• Email and Social Media Platforms: Used for marketing communications, customer support,
and engagement.

• Point of Sale (POS) Systems: In physical stores, interfaces such as checkout counters where
transactions are processed.

What business services does the business process offer/provide to the customer?

• Order Management: Processing customer orders, including order receipt, validation, and
confirmation.

• Delivery Services: Ensuring the physical or digital delivery of products to the customer.

• Customer Support and Service: Offering post-purchase support, handling returns, and
resolving issues.

• Payment Processing: Services to handle transactions securely, including credit, debit, and
digital payments.

Which business events trigger the O2C process?

• Order Placement: A customer places an order through one of the business interfaces.

• Payment Authorization: The customer’s payment method is authorized and confirmed.

 • Stock Level Changes: Availability of stock triggers actions in the order fulfillment.

• Delivery Initiation: Commencement of the logistics process to deliver the product.

What are business objects used or produced by the O2C process?

• Customer Order: Document or digital record detailing the customer’s purchase.

• Invoice: Billing document issued to the customer.

• Shipping Notice: Documentation that accompanies the goods shipped to the customer.

• Payment Receipt: Confirmation of the payment received from the customer.

How would you distinguish business role and business actor?

• Business Role: Defines a set of behaviors or responsibilities within a business process. For
example, a "Sales Representative" role entails promoting and selling products.

• Business Actor: Refers to a specific entity (person or system) that performs roles in the
business process. For example, "John Doe" as a Sales Representative or "CRM System" as a
sales processing actor.

ARCHIMATE VIEWPOINTS

RELATIONSHIPS SUMMARY
Sharp corners: structure

Rounded corners: behaviour

BUSINESS LAYER
Target: operational managers and process architect
Concerns: the structure of business processes, consistency and completeness, responsibilities

Definitions

Examples
APPLICATION LAYER
Target: Enterprise, process, application, and domain architects
Concerns: Application structure, consistency and completeness, reduction of complexity

Note: in the Application Layer, Data and Applications are not represented as computer system but as
logical group of capabilities that manage data objects.

There is no reference to a specific technology!

Definitions

Examples
TECHNOLOGY LAYER
Target: Infrastructure architects, operational managers
Concerns: Stability, security, dependencies, costs of the infrastructure

Definitions

Examples
Note: the latter example shows how to integrate the pechnology layer with the application layer.
Integrating those applications need things like a network (example: Internet, TCP/IP) and
communication path (example: SSL) that connect the nodes (servers, devices, etc.)

+ See on the slides for on premise/IaaS/PaaS/SaaS

LAYERED VIEWPOINT
The Layered Viewpoint is designed to show the dependencies and relationships across different layers
of an organization’s architecture. It helps in identifying how applications are supported by underlying
technologies and how these applications enable business processes.

You basically stack the business, application and technology viewpoints and you highlight the relations
they have with eachother, while placing the relevant services between them.

Target: It is relevant for a wide range of stakeholders including CIOs, IT Managers, System Architects,
Business Process Managers, and anyone involved in overseeing, planning, or implementing strategic
business initiatives and IT infrastructure.

Example
ADDITIONNAL VIEWPOINTS

APPLICATION USAGE VIEWPOINT

The application usage viewpoint explains how applications are utilized to support one or more
business processes and how they interact with other applications. This viewpoint can aid in designing
an application by identifying the necessary services for business processes and other applications.
Additionally, it can help in designing business processes by detailing the available services.
Furthermore, because it identifies the dependencies of business processes on applications, it can be
beneficial for operational managers overseeing these processes.

• Purpose: Aimed at showing how applications support specific business processes.

• Focus: It connects application functionalities directly to business processes and user

interactions, illustrating how users interact with various applications to perform their daily
tasks.

• Target Users: Business analysts, user experience designers, and application developers who
are involved in designing applications that are user-friendly and effectively support business
operations.
APPLICATION STRUCTURE VIEWPOINT
The application structure viewpoint provides an overview of the architecture of one or more
applications or components, along with their associated data. This perspective is instrumental for
designers and developers who need to deconstruct the architecture of a system under development or
identify parts of legacy systems that are suitable for migration or integration.

• Purpose: Shows the struture of a typical application in terms of its constituents.

• Focus: It covers the architecture of applications including components, modules, functions,

and data relationships within those applications.

• Target Users: Enterprise architects, process architects, application architects, and domain
architects who need to design or modify the application architecture.

• Scope: Single layer/multiple aspects

Basically, it is a very detailled application layer.

APPLICATION CO-OPERATION VIEWPOINT

The Application Cooperation viewpoint describes the relationships between application components
in terms of the information flows between them, or in terms of the services they offer and use. This
viewpoint is typically used to create an overview of the application landscape of an organization. This
viewpoint is also used to express the (internal) co-operation or orchestration of services that together
support the execution of a business process.
 • Purpose: This viewpoint is used to provide an overview of how different applications within an
organization interact and cooperate with each other.

• Focus: It highlights the interfaces and integrations between various applications, showing how
data and control flow between them to support business processes.

• Target Users: Architects who need to understand or improve the interactions between
different applications to enhance process efficiencies or integration.

• Scope: Application layer/multiple aspects

Challenges
• Applications that are being built independently differ in programming languages, operating
platforms, data models and formats.

• An integration solution needs to be able to interface with all these different applications and
transform information from source to consumer applications.

• Integration solutions have to transport data from one computer to another across networks (LAN
segments, routers, switches, public networks, and satellite links).

• Each of these steps can cause delays or interruptions.

• Applications change over time. An integration solution has to keep pace with changes in the
applications it connects.

• An integration solution needs to minimize the dependencies from one system to another by using
loose coupling between applications.

Application integration styles

File transfer
Each application produces files of shared data for others to consume and consumes files that others
have produced. The applications need to agree on the filename and location, the format of the file
(syntax and semantics), the timing of when it will be written and read.

Shared database
Multiple applications share the same database schema, located in a single physical database.
Because there is no duplicate data storage, no data has to be transferred from one application to the
other.

API’s (Application Programming Interfaces)

One application exposes some of its functionality as Application Programming Interface (API) so that it
can be accessed remotely by other applications.
Messaging
One application publishes a message to a common message channel. Other applications can read the
message from the channel at a later time. The applications must agree on a channel as well as the
format of the message.

TECHNOLOGY USAGE VIEWPOINT

• Purpose: Shows how technology is used by the applications

• Focus: This viewpoint shows the underlying software and hardware components, such as
servers, databases, network devices, and operating systems that are necessary to deploy and
run the applications.
• Target Users: Infrastructure architects, IT operations managers, and technical support teams
who manage and optimize the hardware and software resources needed to ensure the smooth
operation of applications.
ASSESSING THE QUALITY OF AN EA MODEL
The quality of models can be evaluated along three dimensions

MAIN REQUIREMENTS
1. Firmitas (firmness, structural soundness). That means that the architecture should be “strong”
and consistent.
2. Utilitas (commodity, usefulness). Means that what has been modelled is useful/relevant for the
business.
3. Venustas (grace, elegance). Means that it is more or less readable.

SYNTACTICAL CORRECTNESS (FIRMITAS)

This refers to ensuring that the model follows the rules and syntax of the modeling language used.
Think of it like grammar in a language—your sentences need to be structured correctly to make sense.
In modeling:

Example: Ensure that all statements in your model conform to the syntax rules of the modeling
language (like ArchiMate). For instance, "Application services are realized by application functions, not
by components."

Correspondence between model and language

All statements in the model are according to the syntax of the language (specified by the meta model)

Examples:

• A business/application/infrastructure is used by.. (not assigned)

• Application services are realized by application functions (not by components)

• Application interface is used by an application component or composes an application

component

• Communication paths are realized by a network (and not associated with)

Network is associated with a device or a node and realizes a communication path.
System software is not a standalone component. It has to be assigned to a node.
Do not confuses artifacts (=files that are deployed on infrastructure components) with data objects

More generally, the syntactic quality focus on the correctness of the function that you use to
modelize.

SEMANTIC CORRECTNESS (UTILITAS)

This ensures that the model accurately represents the real-world domain it is supposed to depict. It's
about the meaning behind the model elements.

Example: Your model should contain all relevant and correct statements about the problem domain.
For example, if you are modeling an e-commerce system, the model should correctly represent how
orders, customers, and products interact.

Degree of correspondence between model and domain

• Validity: all statements made by the model are correct and relevant to the problem

• Completeness: model contains all the statements which would be correct and relevant about the
problem domain

PRAGMATIC CORRECTNESS (VENUSTAS)

This relates to how well the model is understood by its intended audience. It focuses on the
communication aspect—how effectively the model conveys the intended information to stakeholders.

Example: Consider the audience's perspective—use clear hierarchies, relevant viewpoints, and well-
organized elements to ensure the model is easy to understand. For instance, creating model
hierarchies and views that aren't overloaded and choosing viewpoints relevant to the audience.

Correspondence between the model and the audience’s interpretation of it.

The degree to which the model has been understood by the audience.

Focus on the way you present the modelization of the business:

1. Is it too overloaded? → Create model hierarchies and views

2. Are the viewpoint chosen relevant to the audience ? → Choose correct viewpoint for the
stakeholder
3. Is your model well organized ? → Group similar elements

VALIDATION BY META-MODEL
Another method of validating a model is using a meta-model. A meta model (MM) is an explicit
description (constructs and rules) of how a domain specific model is built:

• Describes the basic model elements and the relationships between the model elements as well
as their semantics;

• Defines rules for the use and specialization of model elements and relationships;
• Might be expressed using one or more modeling techniques.

If a language is defined by a meta model, it can be used for model validation.

LECTURE 6 : TOGAF FRAMEWORK
TOGAF Architecture Development Method (ADM). The ADM is the code of the framework. Archimate
corresponds to the phases B, C and D of the TOGAF.

STEP A : ARCHITECTURE VISION

• Identify Stakeholders, Concerns, and Business Requirements

• Confirm and elaborate architecture principles:

Qualitative statement of intent that should be met by the architecture. Has at least a supporting
rationale and a measure of importance.

• Define architecture vision:

First, very high-level definitions of the baseline and target environments, from a business,
information systems, and technology perspective.

• Develop Statement of Architecture Work; Secure Approval

We do it by using the Stakeholders, Goal Refinement and Principles Viewpoints.

STAKEHOLDERS VIEWPOINT
The Stakeholder viewpoint allows the analyst to model the stakeholders, their concerns, and the
assessments (in terms of strengths, weaknesses, opportunities, and threats) of these concerns. Also,
the links to the initial high-level goals that address these concerns and assessments may be
described.

PRINCIPLES VIEWPOINT
The Principles viewpoint allows the analyst or designer to model the principles that are relevant to
the design problem at hand, including the goals that motivate these principles. In addition,
relationships between principles, and their goals, can be modeled. For example, principles may
influence each other positively or negatively.

So basically we have some principles but we need the goals that motivate them otherwise they might
be useless principles.
GOAL REFINEMENT VIEWPOINT
The Goal Refinement viewpoint allows a designer to model the refinement of high-level goals into
more concrete goals, and the refinement of concrete goals into requirements or constraints that
describe the properties that are needed to realize the goals. The refinement of goals into sub-goals is
modeled using the aggregation relationship. The refinement of goals into requirements is modeled
using the realization relationship.

SUMMARY OF THE NEW ELEMENTS

The motivation of an organization or individual toachieve certain results is represented by goals,
principles, requirements, and constraints.

• Goals represent that a stakeholder wants to realize

• The end results realized by capabilities that realize these goals are outcomes

• Principles and requirements represent desired properties of solutions – or means – to realize

the goals

• Constraints impose restrictions on the way a system operates or may be realized

STEP B : BUSINESS ARCHITECTURE
• Develop the Baseline Business Architecture Description: If an enterprise has existing architecture
descriptions, they should be re-used (as in Step A). Where no such descriptions exist, information
will have to be gathered in whatever format comes to hand.

• Develop Target Business Architecture Description: Develop a Target Description for the Business
Architecture, to the extent necessary to support the Architecture Vision.

• Perform Gap Analysis

• Define Candidate Roadmap Components

BUSINESS FUNCTION VIEWPOINT

The Business Function viewpoint shows the main business functions of an organization and their
relationships in terms of the flows of information, value, or goods between them.

STEP C : INFORMATION SYSTEMS ARCHITECTURE

Phase C involves some combination of Data and Application Architecture, in either order.

• Develop the Baseline and Target Application Architecture Description: define the major kinds of
application system necessary to process the data and support the business.

• The applications are not described as computer systems, but as logical groups of
capabilities that manage the data objects (Data Architecture) and support the business
functions (Business Architecture).

• The applications and their capabilities are defined without reference to particular
technologies. -> This will come in the next step (Technology Architecture)

• Develop the Baseline and Target Data Architecture Description

• Perform Gap Analysis

• Define Candidate Roadmap Components

APPLICATION COOPERATION VIEWPOINT
In Archimate, we will typically use the Application Cooperation viewpoint.

STEP D : TECHNOLOGY ARCHITECTURE

Phase D maps application components defined in the Application Architecture phase into a set of
technology components, which represent software and hardware components.

• Develop the Baseline and Target Technology Architecture Description:

• A key process in the creation of a broad architectural model of the target system is the
conceptualization of building blocks.

• Architecture Building Blocks (ABBs) describe the functionality and how they may be
implemented without the detail introduced by configuration or detailed design.

• Perform Gap Analysis

• Define Candidate Roadmap Components

REQUIREMENTS REALIZATION VIEWPOINT

The Requirements Realization viewpoint allows the designer to model the realization of
requirements by the core elements, such as business actors, business services, business
processes, application services, application components, etc. Typically, these requirements result
from the Goal Realization viewpoint.
STEP F : MIGRATION PLANNING
(Step E is skipped in the course)

Objective: Creation of a viable Implementation and Migration Plan in cooperation with the portfolio and
project managers

The step F in the TOGAF Migration Planning process involves creating a structured approach to
transitioning from an existing architecture to a desired future architecture. Here’s a breakdown of what
each bullet point involves:

1. Creation of a viable Implementation and Migration Plan in cooperation with the portfolio
and project managers: This step is about developing a realistic and detailed plan to move
from the current architecture to the new one, ensuring it aligns with overall business strategies
and objectives. This includes deciding on the projects and activities needed for the transition.

2. Assign a Business Value to Each Work Package: This involves quantifying the expected
benefits (such as cost savings, improved efficiency, or enhanced capabilities) each project or
work package will bring. This helps prioritize efforts based on their potential business impact.

3. Estimate resource requirements, project timings, and availability/delivery vehicle: Here,

the resources (time, budget, personnel) required for each project are estimated. This helps in
scheduling and resource allocation to ensure projects are feasible and can be delivered as
planned.

4. Prioritize the migration projects through the conduct of a cost/benefit assessment and
risk validation: This step involves evaluating each project to balance the benefits against the
costs and risks. Projects with a favorable balance are prioritized.

5. Confirm Transition Architecture increments/phases: This is about detailing the steps or

phases in which the transition will occur, often breaking down the migration into manageable,
incremental changes that deliver value progressively.
 6. Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan:
This final step is about creating a detailed timeline that maps out when and how each part of
the migration will be implemented. This roadmap is critical for coordinating efforts and
tracking progress against strategic objectives.

IMPLEMENTATION AND MIGRATION VIEWPOINT

TRANSITION ARCHITECTURE IN STEP F
1. Transition Architecture:

o Describes the enterprise at various incremental stages which occur between the
current (Baseline) and the desired future (Target) architectures. This means breaking
down the entire transformation into smaller, more manageable stages or states that
the organization transitions through.

2. Purpose of Transition Architectures:

o These architectures are used to organize and manage work across different projects
or programs, helping to map out and track the changes needed to reach the target
architecture. This structured approach helps in assessing and demonstrating the
business value and progress at each stage of the transformation.

3. Contents of Transition Architectures:

o Milestones and Milestone Transition Architectures: These are specific targets or

checkpoints within the transition that help to gauge progress.

o Definition of transition states: Each state or phase in the transition process is clearly
defined, often with goals or outcomes that need to be achieved before moving to the
next phase.

o Business Architecture for each transition state: Details how business operations,
processes, and organizational structures will change or be configured in each phase.

o Data Architecture for each transition state: Outlines how data assets will be
managed and structured through the transition, ensuring that data remains consistent,
secure, and fit for purpose.

o Application Architecture for each transition state: Describes the applications and
software solutions that will be used or need to be developed to support business
functions in each transition phase.
 o Technology Architecture for each transition state: Specifies the hardware,
networks, and technological infrastructure required to support the transition at each
stage.

MIGRATION VIEWPOINT – TRANSITION ARCHITECTURE

TRANSITION ROADMAP IN STEP F

• Architecture Roadmap lists individual increments of change and lays them out on a timeline to
show progression from the Baseline Architecture to the Target Architecture.

• Typical contents of an Architecture Roadmap are:

• Project list: Name, description, and objectives of each impacted project

• Time-oriented migration plan

• Implementation recommendations: Criteria measures of effectiveness of projects, risks

and issues, Solution Building Blocks (SBBs)
• The Architecture Roadmap is incrementally developed throughout Phases B, C, D, E, and F within
the ADM.

WHAT IS AN ENTERPRISE ARCHITECTURE FRAMEWORK?

In theory:

• A framework is a basic conceptual structure used to solve or address complex issues.

• A method is a series of steps to achieve a goal.

A framework defines what you should do but does not define how or with which tools you should do it.
And it should be vendor-neutral.

In reality – A mixture:

• Frameworks with guidelines (methods) to assess existing enterprise architectures and build
new models

• Generic approach to build optimized enterprise structures

An Architecture Framework establishes a common practice for creating, interpreting, analyzing and
using architecture descriptions within a particular domain of application or stakeholder community.

Enterprise architecture frameworks mostly have the following components:

LECTURE 7 : STRATEGIC PLANNING (1)
INTRODUCTION
We are now beginnng the Part III of the course, named Business and IS Design in Digital
Transformation. At the end of part II, we learned how to create/correct archimate models. In this part
of the course, we will learn how enterprise architecture concepts and methods support the
development of an enterprise and its IT landscape.

We do it through three parts:

• Strategic planning (analyze business strategy and requirements using capability maps,
assess situation and plan architecture accordingly)

• Programs and projects (connect architecture with agile practices using the SAFe Scaled Agile
Framework; analyze requirements, evaluate and design solution architectures)

• Operation and monitoring (monitor operational changes on EA components and establish

feedback processes)

EA IN PRACTICE
TOGAF is the most used EA framework but is rarely applied as-is. Indeed there are practical
challenges such as the entry barriers and lack of speed, the ivory tower (Architects work is
disconnected from the activities that change the EA (investment planning, program and portfolio
management, project delivery, etc.)) and the implementation gap (where the target EA is never
realized).

There is an analogy between city planning and IT systems management, highlighting the importance of
architectural thinking in the lifecycle of IT systems, which includes:

1. Planning: Similar to city planners designing urban layouts, IT planners design the architecture
of systems.

2. Construction Plan: Detailed blueprints are developed, akin to construction plans in urban
development.

3. Building: The actual construction of IT infrastructure occurs, mirroring the building of city
infrastructure.
 4. Operating and Further Development: Once built, the IT system is operated and continually
improved, paralleling the ongoing development and maintenance of a city.

This analogy emphasizes that, just like in urban planning where plans are realized, inhabited, and
evolved, IT systems require thoughtful planning, careful building, and continuous improvement to
serve their intended functions effectively.

THE THREE CIRCLES

STRATEGIC PLANNING : OVERVIEW AND PRACTICES

 1. Scope and Focus:

o The strategic planning process operates at the enterprise level, often likened to "city
planning" for its comprehensive and foundational role.

o It sets the strategic goals and priorities for the organization.

o Budget and investment planning occur typically on a yearly basis, underpinning the
financial commitment needed to support the architectural vision and projects.

2. Architecture Practices in Strategic Planning:

o Use of EA Models: Simple EA models, such as capability maps, are employed to

assess the current (as-is) situation of the enterprise, identify gaps, and determine
priorities for action.

o Translation of Business Strategy: The process involves translating business

strategies into clear strategic options and a feasible architectural vision, which
reflects the desired future state (to-be architecture).

o Roadmap Development: Roadmaps are defined to guide the transition from the
current state to the desired future state, creating a shared understanding of and
commitment to the strategic plan.

3. Architecture Artifacts:

o Maps: Various types of maps (e.g., capability, process, application maps) are used as
tools to visualize and manage the complexity of enterprise architecture.

o Detailed Models: These are created for selected aspects of the architecture to
provide detailed guidance and specifications where necessary.

o Architecture Principles: Foundational guidelines that govern the architecture across

the enterprise to ensure consistency and alignment with the business strategy.

BUSINESS ARCHITECTURE
The business architecture is:

• A prerequisite for architecture work in any other domain (Data, Application, Technology)

• The first architecture activity that needs to be undertaken, if not catered for already in other
organizational processes (enterprise planning, strategic business planning, business process
re-engineering, etc.)

So, this means that the business architecture is the first thing that must be done.
WHICH ARCHITECTURE VIEWS AND ARTIFACTS CONSTITUTE THE BUSINESS ARCHITECTURE?
Zachman
Planner and Owner View (e.g. business goals, business processes, information objects, locations,
people and stakeholders, events)

ArchiMate
Business service, business object, business process, business role (IT-driven) EA approaches use the
term business architecture to describe business processes, locations and data objects.

However, strategy-led EA literature link up business architecture with strategic planning and higher
level concepts. In this broader sense, it comprises also the business strategy’s core elements, such
as:

• Business models

• Business capabilities

• Operating models

MAIN APPROACHES OF BUSINESS ARCHITECTURE

Business model
Describes the rationale of how an organization creates, delivers, and captures economic, social, or
other forms of value.

-> Logic of value creation

Business Process Model / Value Stream

Defines the way a firm transforms inputs into outputs

-> Value generating activities

Capability Map
Describes a company’s capacity to perform specific tasks arising from a combination of physical,
human and technological resources
-> Alignment of resources with business strategy

Operating Model
It is the abstract representation of how an organization operates across process, organization,
technology domains in order to deliver value defined by the organization in scope.
-> Operations strategy
BUSINESS MODEL
As said earlier, it focuses on the value creation logic for the enterprise.

VALUE STREAMS
A value stream is a sequence of value-adding activities that achieve a specific result that is of
value to a stakeholder.

Value stream may seem very similar to an end-to-end business process

• A value stream focuses on the overall value-creating behavior from the perspective of the
importance, worth, or usefulness of what is produced, and is not a description of time-ordered
tasks for individual cases.

• A business process describes the (time-ordered) sequence of behaviors required to create

some result for an individual case, and

It may describe alternative paths and decision points (modeled with junctions).

Link between value streams and capabilities: Capabilities can serve (i.e., enable) a value stream.

It always finishes with an outcome, which is a specific result for a stakeholder.

OPERATING MODEL
An Operating Model is the abstract representation of how an organization operates across process,
organization, technology domains in order to deliver value.

The Center of Information Systems Research at MIT Sloan School of Management has defined an
operating model as the desired level of process standardization and process integration.

1. Process standardization:
• Defining exactly how a business process will be executed regardless of who is performing the
business process or where it is completed
• Tradeoff between reductions in variability, efficiency, predictability vs local innovation

2. Process integration:

• Linking the efforts of organizational units through shared data

• Between processes to enable end-to-end transaction processing across processes to allow the
company to present a single face to the customer

FOUR TYPES OF OPERATING MODELS

Coordination
This model is used by companies with multiple business units that operate independently but need
to share information seamlessly. The emphasis is on enabling these units to access and exchange
data efficiently without merging their operations entirely. It helps manage complex interdependencies
within the company.
Unification
In this model, a single company operates globally with uniform processes and data access across all
locations. The focus is on having consistent and standardized procedures everywhere, supported by
centralized IT systems. This model is efficient for organizations wanting a coherent brand and service
quality worldwide.

Divresification
Companies operating under this model have various business units that function independently and
focus on different markets or products. The central entity provides support and may achieve
economies of scale, but each unit operates autonomously to best serve its specific market.

Replication
This model involves independent businesses under the same umbrella following a standard set of
processes. Each unit operates independently but uses a common framework and practices optimized
from one another, aiming to replicate success across multiple scenarios.

Summary
CAPABILITY MODELS AND MAPS
What are capabilities?

Capabilities describe the firm’s capacities (What?). They provide a high-level view, and are more
stable over time.

Capabilities are realized by people, processes, technology (and data). They can be linked to
resources

Capabilities are often used for capability-based (strategic) planning.

Business capabilities:

• Are the building block of the business

• Represent stable business functions

• Are unique and independent from each other

• Are abstracted from the organization

• Arise from the combination of physical, human and

• Technological resources and can be mapped to them.

How to create capability models

Capability Maps:

• Describe logical groupings and dependencies between capabilities

• Visualization: network or tree structures

• At a high level comprise the 5-9 generic capabilities of the firm

• Could be the same as high-level process model

• Could in part coincide with high-level product groups

 1. Capabilities define what a business does, not how a business does something.

2. Capabilities are nouns, not verbs.

3. Capabilities are defined in business terms, not technical terms.

4. Capabilities are stable, not volatile.

5. Capabilities are not redundant (they must not overlap).

6. There is one capability map for a business.

7. Capabilities map to, but are not the same as, an LOB, business unit, business process, or
value stream.

8. Capabilities have relationships to IT deployments and future-state IT architecture.

9. Automated capabilities are still business capabilities – not IT capabilities.

10. Capabilities are of most value when incorporated into a larger view of an enterprise's
ecosystem.

Capabilities can be classified in

• Core vs. non-core

• Strategic vs. operational vs. supporting

• Customer-facing vs. internal

• Innovating vs. differentiating vs. commodity

Such a classification scheme helps in investment and sourcing decisions:

• Differentiating, customer facing capabilities are core and are seldom outsourced
• Strategic, innovating capabilities are important for the long-term future of an enterprise and are
often assigned
a separate budget, to avoid the “innovation squeeze”, where the core, operational capabilities eat
up all the budget

• Non-core, commodity or supporting capabilities are good candidates for outsourcing to partners
that have these as their core, differentiating capabilities

CAPABILITY HEAT-MAP
Creating a heat-map is useful to depict the gaps between the as-is and the to-be in our capabilities.
ROAD-MAPPING AND MIGRATION PLANNING

CAPABILITY ROAD-MAP EXAMPLE

Roadmap with the programs/work packages linked to the capabilities it improves

CAPABILITY REALISATION MODEL
A capability realization model is a framework that maps an organization's business capabilities to the
underlying resources, processes, and technologies required to enable and support those capabilities.
It provides a structured approach to understanding how an organization's capabilities are realized and
delivered.

The core purpose of a capability realization model is to link an organization's business capabilities (the
"what" it can do) to the resources, processes, and technologies (the "how") that enable those
capabilities.

BASIC EXAMPLE
LECTURE 8 : FROM STRATEGIC PLANNING TO PROGRAMS &
PROJECTS (SP 2)
This is where we are at in our strategic planning.

HOW TO USE A CAPABILITY MAP?

Capability maps are used to identify redundancies and overlaps in the current application landscape.

McKinsey estimates the saving potential from uncovering IT redundancies to be 15 - 20%.

HOW TO LINK CAPABILITIES TO APPLICATIONS AND INFRASTRUCTURE COMPONENTS

EXAMPLE: CAPABILITIES TO APPLICATIONS

PROJECT LIFECYCLE
We are now at the second part of the three circles, the project lifecycle one.

SCOPE & FOCUS

Program / portfolio planning: High-level target architecture and roadmap

Project / solution level: Requirements analysis and solution design

ARCHITECTURE-PRACTICES IN PROGRAMS & PROJECTS

Assess project proposals with regards to their architecture impact and conformance with architecture
principles, roadmap and target architecture Analyze dependencies between projects based on
enterprise architecture models

Define solution design using architecture viewpoints / models

ARCHITECTURE REVIEWS AND COACHING

Architecture Artifacts

Architecture principles, target architecture and roadmap

Detailed models for requirements analysis and solution design

AGILE VS WATERFALL

The problem with Agile is that is mostly fits small, co-located teams developing non-life-critical
projects.

SCALED AGILE FRAMEWORK (SAFE)

IT projects are now using Agile way more than waterfall. SAFe is a framework that helps organizations
implement agile practices at enterprise scale, beyond just a single team.

Here is a short video about it

Scaled Agile Framework (SAFe) is a framework for applying Lean and Agile practices at enterprise
scale. It Synchronizes alignment, collaboration and delivery for large numbers of teams.

It builds on three pillars: Team, Program, and Portfolio.

PORTFOLIO
Themes with a life span of 6-12 months

Epic: “An Epic is a container for a Solution development initiative large enough to require analysis, the
definition of a Minimum Viable Product (MVP), and financial approval before implementation.”
AGILE RELEASE TRAIN (ART)
5-10 teams, potentially shippable increment (PSI) every 10 weeks (5 iterations)

Feature: “A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit
hypothesis and acceptance criteria and is sized or split as necessary to be delivered by a single Agile
Release Train (ART) in a Program Increment (PI).”

AGILE TEAMS (SCRUM)

Increments every 2 weeks

User Story: “Stories are short descriptions of a small piece of desired functionality, written in the
user’s language ... User stories deliver functionality directly to the end user. Enabler stories bring
visibility to the work items needed to support exploration, architecture, infrastructure, and
compliance.”

MAPPED IN ARCHIMATE

EMERGENT DESIGN VS. INTENTIONAL ARCHITECTURE

Agile development avoids big design up-front (BDUF) with a simple belief that “the best architectures,
requirements, and designs emerge from self-organizing teams”.

Emergent design is defining and extending the architecture only as necessary to deliver the next
increment of functionality.

At scale, relying solely on emergent design leads to the following problems:

• Lack of standards increases delivery costs and delays

• One-off solutions become difficult to change and maintain

• Systems become vulnerable to security and stability issues

 • Quality becomes dependent on tribal knowledge

• Solution components have poor interoperability and reusability

Organizations overcome these problems by balancing emergent design with intentional architecture,
which requires some centralized planning and cross-team coordination.

ARCHITECTURAL RUNWAY

The term "architectural runway" in the context of the Scaled Agile Framework (SAFe) refers to the
existing code, components, and technical infrastructure needed to implement near-term features
without excessive redesign and delay.

Example:

Imagine you're developing an e-commerce application. If you foresee the need to handle many
different types of payments in the future:

• Without an architectural runway: You might develop the payment system to handle only
credit cards. Later, adding support for digital wallets or bank transfers could require major
changes to how payments are processed, possibly even redesigning the whole payment
module.

• With an architectural runway: You would design the payment system from the start to easily
accommodate multiple types of payments. This means when it’s time to add a new payment
method, the system is already prepared for this expansion, making it quicker and easier to
implement.
SCRUM
Short video explaining it
LECTURE 9: LEANIX
One of the goals of LeanIX is not to make it only accessible for experts but for everyone in the
organisation to input what they think of it, they do that to have a better data-driven enterprise
architecture.

SHADOW IT
LeanIX wants to stop Shadow IT and make it more Business-Managed IT.

Shadow IT refers to any software, hardware, applications, or IT resources used by employees or

teams within an organization without the knowledge or approval of the IT department.

REASONS FOR SHADOW IT

1. Employees find unauthorized tools more convenient or productive

2. Desire for immediate access without waiting for IT approval

3. Teams want to quickly adopt new cloud services or apps

4. Bring Your Own Device (BYOD) policies enable personal device usage

RISKS OF SHADOW IT
1. Loss of visibility and control for IT over vulnerabilities and security

2. Data exposure risks from unsecured apps/devices storing sensitive data

3. Potential compliance violations by processing data insecurely

4. Integration issues between shadow IT and approved resources

5. Redundant spending on duplicate unauthorized solutions

SIMPLE EA METAMODEL
DATA-DRIVEN ENTERPRISE ARCHITECTURE
Data-driven enterprise architecture (EA) is an approach that leverages data and analytics to drive
decision-making and optimize the alignment between business and IT within an organization. Some
key points about data-driven EA:

Data as a Foundation

• Data is treated as a critical asset and foundation for EA activities

• EA models, processes, and artifacts are driven by actual data rather than assumptions or
static documentation

• Continuous data collection and integration across the enterprise enables up-to-date visibility

Benefits

• Enables data-informed decision making for strategic planning and investments

• Improves transparency and cross-functional collaboration through shared data

• Allows EA to be more agile and responsive to changes by leveraging real-time data

• Aligns data governance and analytics initiatives with the overall enterprise architecture

The TOGAF Architecture Development Method (ADM) can support data-driven EA practices,
especially in phases like Data Architecture, Application Architecture, and Technology Architecture
definition. Overall, data-driven EA empowers organizations to make better decisions and optimize
business/IT alignment through data-driven insights and modeling capabilities.

USE-CASES

SAP S/4HANA TRANSFORMATION

Essentially, it’s about figuring out the best way to switch from the old system to this new, snazzy one
while making sure everything meshes well. They're planning the move in steps, assessing what they
currently have, deciding what the future setup should look like, and then making it happen. This way,
they ensure the IT changes support the company’s needs and keep everything running smoothly during
the transition.
DATA FLOW ANALYSIS

This tool helps companies see how data moves around in their system. It’s like a map showing where
information starts, where it goes, and how it gets there. For example, it tracks data from an employee's
entry in the HR system all the way to how it's used for payroll and time tracking. This transparency is
super useful because it helps companies:

• Keep track of data: They can see all the types of data they have, where each piece is used,
and how it flows through different parts of the company.

• Boost data use: By understanding data paths, companies can find new ways to use data more
effectively, especially with modern tech like big data analytics.

• Visualize with heatmaps: These are like thermal images showing which parts of the data flow
are 'hot' (used a lot) or 'cold' (not used much), helping to focus on important areas.

• Stay compliant: With laws like GDPR in Europe that protect personal data, this tool helps
ensure that data handling is up to legal standards, avoiding fines and other issues.

• Find and fix data silos: Sometimes data gets stuck in one part of a company, unknown or
unused by others. This tool helps spot those silos, making sure valuable data isn’t wasted.

In essence, it’s like giving companies x-ray vision to see their data’s journey, helping them make
smarter decisions, stay legal, and get the most out of the info they have.
LECTURE 10: PORTFOLIO MANAGEMENT & PROJECT LIFE-CYCLE

TRADITIONAL SOFTWARE PROJECTS

They used to have pages long specification documents.

AGILE METHODS (SCRUM, SAFE)

PRODUCT BACKLOG
• Contains a prioritized list of all items relevant to a specific product.

• The list of items correspond to solution requirements. It is comparable to the traditional

requirements specification artifacts.

SPRINT BACKLOG
• Is fed by the product backlog with items that have been fully
specified.

• Every requirement is decomposed into several tasks or actionable development items, which are
then assigned to specific team-members to be implemented in a sprint.
USER STORIES – PRODUCT BACKLOG AND PRIORITIZATION

MORE ON SAFE

BREAKING DOWN BUSINESS FEATURES INTO USER AND ENABLER STORY

User Stories
These are short, simple descriptions of a feature told from the perspective of the
user or customer. They focus on articulating what the user needs and why, which
guides the development process toward creating value for the user. User stories
typically follow a simple template: "As a [type of user], I want [some goal] so that
[some reason]."

Enabler Stories
These provide the necessary technical groundwork that supports the implementation of user stories.
They can include activities such as research, architecture, infrastructure, and any efforts that address
technical challenges or enhancements required to support functional features. Enabler stories are
essential for advancing the architectural runway and may not directly deliver user-visible functionality
but are crucial for enabling future user stories to be implemented effectively.

ROLE OF ARCHITECTS IN SAFE

Contribute to definition of strategic themes and portfolio

Provide transparency: Document portfolio and projects with regards to architecture impact and
amendments

Establish guardrails: Check epics for conformity with the architecture vision and adherence to
architecture principles and any guidelines.

Initiate enabler epics: Propose epics to create reusable solutions or improve architecture

Review and coach teams

Solution Architecture
“Solution architects define and communicate a shared technical and architectural vision to help
ensure the system or solution under development is fit for its intended purpose.”

Typical tasks
• Describe the solution context and solution intent

• Determine the primary components and subsystems

• Identify the interfaces and collaborations between them

• Analyze technical choices and trade-offs

• Cloud initiatives typically are delivered using agile methods, such as Scrum.

• Challenge: Functional requirements that are of high value to cloud LOB (= line-of-business)
applications are typically dependent on non-functional requirements and architecture.

REQUIREMENT ANALYSIS

REQUIREMENTS VS. DESIGN

NOT THE SAME REQUIREMENTS EVERYWHERE
Requirements are not uniform, but are expressed at different Levels.

Business Requirements
Statements of goals, objectives, and outcomes that describe why a change has been initiated

ArchiMate: Goals, Requirements & Constraints

Let’s remember, in Archimate we have viewpoints such as the one in the Architecture vision step in
TOGAF (STEP A).

Stakeholder Requirements
Needs of stakeholders that must be met in order to achieve the business requirements.

User Stories
User stories are used for an informal, natural language description of features of a software system. In
agile methods, a user Story is a small (actually, the smallest) piece of work that represents some value
to an end user and can be delivered during a sprint. See this earlier paragraph for more info.

Rules of user stories

1. One action per Story.
2. Describe an intention, not a feature. For example, instead of “I want to manage my profile” create
a few Stories like “I want to be able to register”
3. Keep it short.

Writing a User Story Using Cards

Writing a User Story – Acceptance Criteria

INVEST criteria’s

User stories examples

User Story 1 (User)
Title: Add Items to Cart

• As a customer,

• I want to easily add items to my shopping cart,

• So that I can manage my purchases before checkout.

Acceptance Criteria:

• Given I am viewing a product,

• When I click on the "Add to Cart" button,

• Then the item is added to my shopping cart, and I see a confirmation message.

User Story 2 (User)

Title: Receive Order Updates
 • As a customer,

• I want to receive updates about my order status,

• So that I can track my purchase until delivery.

Acceptance Criteria:

• Given I have completed a purchase,

• When the status of my order changes (e.g., shipped, delivered),

• Then I receive an email notification detailing the current status.

User Story 3 (Administrator)

Title: Manage User Accounts

• As an administrator,

• I want to have the ability to manage user accounts,

• So that I can deactivate accounts, reset passwords, or update user roles as needed.

Acceptance Criteria:

• Given I am logged into the admin dashboard,

• When I select an account to edit and make changes,

• Then the changes are saved, and the affected user is notified of these changes if applicable.

User Story 4 (Administrator)

Title: View Sales Reports

• As an administrator,

• I want to view daily, weekly, and monthly sales reports,

• So that I can make informed business decisions based on sales data.

Acceptance Criteria:

• Given I select a reporting period,

• When I request the sales report from the dashboard,

• Then the sales report for the selected period is generated and viewable.

User Story 5 (Support Staff)

Title: Respond to User Queries

• As a support staff member,

• I want to access user queries through a centralized system,

 • So that I can respond promptly and efficiently to support tickets.

Acceptance Criteria:

• Given a user has submitted a support ticket,

• When I access the ticket from the support dashboard,

• Then I can view the details, respond to the user, and mark the ticket as resolved.

User Story 6 (External Partner)

Title: Access Inventory Data

• As an external supplier,

• I want to access inventory data,

• So that I can adjust supply based on current stock levels.

Acceptance Criteria:

• Given I have proper credentials,

• When I log into the partner portal and request current inventory levels,

• Then I can view real-time inventory data, which aids in managing my supply chain.
Story Map
A story map organizes user stories according to a narrative flow that presents the big picture of the
product.

Solution Requirements
A statement of what the system must do and what characteristics the system must have in order to
satisfy user needs.

Solution Requirements change as the project moves from analysis to design and then to
implementation. The focus is on business needs during analysis phase, and over time refinement and
extension of requirements.

Capabilities and qualities of a solution that meet the stakeholder requirements.

Provide the appropriate level of detail to allow for the development and specification of a solution.

Solution requirements may be classified in functional and non-functional requirements.

Functional Requirements
• A process or activity the system has to do or support

• Information the system must contain

Example
Non-functional Requirements
Behavioral properties or qualities the system must have (performance, scalability, etc.)

Example

The 7 Qualities Of Wildly Desirable Software

The common requirements that all software applications must satisfy to be successful. All seven
qualities are important, but if you get the user experience (UX) wrong, nothing else matters.

The Solution requirements should be:

• Unambiguous

• Testable (verifiable)

• Clear (concise, terse, simple, precise)

• Correct
 • Understandable

• Feasible (realistic, possible)

• Independent

• Atomic

• Necessary

• Implementation-free (abstract)

Transition Requirements
Address topics, such as data conversion, training or business continuity.
LECTURE 12: REQUIREMENTS AND SOLUTION DESIGN
INDUSTRY 4.0
Industry 4.0, also known as the Fourth Industrial Revolution, refers to the integration of
intelligent digital technologies into manufacturing and industrial processes. Itencompasses a set of
technologies that include:

• Industrial Internet of Things (IIoT)

• Artificial Intelligence (AI)

• Big Data Analytics

• Robotics

• Automation

REQUIREMENTS

HOW TO FIND REQUIREMENTS

1. Identifying the product’s expected user classes and other stakeholders
2. Understanding user tasks and goals and the business objectives with which those tasks align
3. Learning about the environment in which the new product will be used
4. Working with individuals who represent each user class to understand their functionality needs
and their quality expectations

You can also make interviews and workshops with employees and experts to create as-is and to-be
models.

DOCUMENT ANALYSIS & OBSERVATIONS

You can also observe documents, it is a powerful tool to gain insight into the as-is system

Example
PARTICIPATORY DESIGN / CONTEXTUAL DESIGN
LECTURE 13: OPERATIONS & MONITORING
We’ve now arrived at the third and final cycle: Operations and monitoring.

SCOPE & FOCUS

Enterprise-wide

Operations and IT service management

ARCHITECTURE-DRIVEN PRACTICES
Collect and assess changes for their EA relevance

Monitor EA status and evolution (for instance, incident reporting on EA components)

Establish feedback loops (input for strategic planning)

ARCHITECTURE ARTIFACTS
EA components linked to IT assets (CMDB) and incidents/problems/change/service requests

KPIs for EA

THE CHALLENGE
EA models are always outdated. Why?

• Thousands to tens of thousands small changes in a IT landscapes per year

• Most of these changes are triggered by users and treated by (local) service desks and operations

But while most of those changes don’t affect the EA at all, but 1-10% of them have significant impact
on an EA component by modifying its characteristics or entail significant side-effects on other
components.

So, this leaves the question:

• How should operational changes be managed?

• How should the EA be monitored?

• How can feedback loops be established?

EA IN OPERATION & MONITORING

STRATEGIC & OPERATIONAL CHANGES DIFFERENCES

As we can see, they are rather different and strategic changes are for the long term for a new business
idea while operational changes are for the stability of the current affairs.

COLLECTING & TRACKING REQUESTS FOR OPERATIONAL CHANGES: IT SERVICE

MANAGEMENT
IDENTIFYING EA-RELEVANT OPERATIONAL CHANGES
Changes are architecturally relevant if they:

• Alter business-critical EA components (for instance, a product or service offering, key customers
or distribution channels, core business processes or applications)

• Impact (existing) interfaces between two EA components (for instance, two applications)

• Bear high risks (for instance, high costs, volatile requirements or doubtful investments) and
impact business continuity

• Change the main IS/IT security features (for instance, communication with external parties)

• Impact external factors and ressources (for instance, supplier structure change)

• Violate regulatory guidelines (for instance, Basel III in banking, SOX, or FDA in pharma), company
standards or working models (for instance, architecture principles and standards)

Checklist
At the end, we can use this check-list to assess EA relevance of the following changes in a CRM
(Customer Relationship Management) system.

EA & IT SERVICE MANAGEMENT TOOLS SHOULD BE TIGHTLY INTEGRATED

EA MONITORING: MEASURING EA COMPLEXITY BY MEANS OF THE POINT COSTING CONCEPT
EA component point costing concept (Analogy to function point analysis in algorithms)

• Assesses EA complexity in terms of ratings for EA components

• Defines EA components characteristics that drive complexity and assigns them a weight

• Overall objective is to minimize the ratings and thereby the complexity

EXERCICES
OPEN QUESTIONS

Q1
Architecture is rigid and not compatible with today’s agile methods and ways of working.

Do you agree with this statement: yes/no? Explain and justify your answer.

I do not agree with this statement. Indeed, today’s EA is compatible with Agile methods. We can see
that with the widely used SAFe framework that advocates to use intentional architecture with
emergent design.

Indeed, planifying everything in advance and being very ridig is absolutely against Agile’s principles, but
using only emergent design means defining and extending the architecture only as necessary to deliver
the next increment of functionality. Doing this can lead to inconsistencies and vulnerabilities. This is
why it is very important to couple it with some intentional architecture in order for it to be more robust.

Furthermore, in the context of SAFe, having a good architecture is a good enabler for architectural
runway. Indeed, without intentionnal architecture it would be way harder for example to have a good
and scabeable design that is robust and capable of implementing new features when needed. This
shows that we need to have both emmergent design and planned architecture and that they are widely
used together.

This is why I do not see architecture and agile methods being incompatible.

Q2
In a manufacturing company, various functions have implemented their own isolated systems to
support their specific business requirements, leading to the emergence of shadow IT.

• What are three typical challenges that result from shadow IT from an architecture
perspective?

First, you might have unwated costs if multiple employees or teams have purchased the same license
and didn’t tell it to the company, whereas the company could have bought a company wide license
you would probably have been way cheaper than a mulititude of employees having a personnal
subscription.

Then, we have a compliance problem, indeed, since the apps bought in shadowIT are not always (and
most frequently) not approved by the company, this can lead to non-compliance to some regulatory
norms.

Finally, the firm could have Loss of visibility and control for IT over vulnerabilities and security.

• How could an enterprise architecture team support the company in dealing with shadow
IT?
An entreprise architecture team using tools like LeanIX could help dealing with ShadowIT. Indeed, they
first provide surveys for employees to write what apps they use, this could lead to uncovering shadow
IT. They also provide SAM (Software Asset Management) which could reveal usage of Shadow IT. You
could then try to eradicate it or to use it as a learning opportunity about what your IT department likes
and is the most productive with.

Q3
Industry 4.0 @ Roasteria
1. Document three business requirements for the new solution

(in terms of business goals and outcomes). Can you quantify them?

1: Reduce unexpected downtime

2: Improve maintenance time

3: Efficiently produce production schedules

2. Who are the stakeholders of the new solution?

We have the board, and the warehouse opeators and the engineers.

3. Pick 2 stakeholders and define 2 user stories per stakeholder for the new monitoring system.

Board

As the Board, we want to see a real-time dashboard with key performance indicators (KPIs) of the
production line, such as overall equipment effectiveness (OEE) and machine downtime, so that we
can assess the impact of Industry 4.0 on operating efficiency and make data-driven decisions.

Acceptance criteria

Given that a machine is not performing as intenden

When I see a KPI getting lower

Then I need to be sure of why this is and have indications on how to handle the issue

Warehouse operator

As a warehouse operator, I want to see clear and actionable instructions on the monitoring system
interface whenever a machine malfunction is detected so that I can troubleshoot and resolve the issue
quickly.

Acceptance criteria

Given that a machine malfunction is detected

When I receive a notification

Then I need this notificatio to be very clear and precise so I can troubleshoot accordingly.

4. Of the user story you created, pick one and translate it into 2-3 functional and non-functional
requirements.

I picked: As a warehouse operator, I want to see clear and actionable instructions on the monitoring
system interface whenever a machine malfunction is detected so that I can troubleshoot and resolve
the issue quickly.

Functional requirement

The system must be able to recognize a disfunction in the 5 minutes it occured

Non-functional requirement

Since a lot of IoT devices are very vulnerable to attacks, our system must implement increased
security in all the IoT sensors.

Q4
Which viewpoint to select for the following situation?

Select the most appropriate viewpoint (from ArchiMate viewpoints)

As part of GDPR compliance checks, the CIO asks to identify all applications that comprise sensitive
personal information.

A business analyst aims to analyze how employees in the HR department work and which applications
they use. Application usage viewpoint

For the upgrade to a new version of the ERP system, the project manager needs to identify all other
applications that exchange data with the ERP system. Application cooperation viewpoint

A business analyst aims to obtain an overview of the different products and services delivered to the
customers and how they are created. Business funciton viewpoint

A developer wants to understand Mailchimp’s programmatic access to data and functionality in order
to build custom features. Technology usage viewpoint
RESSOURCES
DEFAULT CAPABILITY MAP