Enterprise Modeling for Digital transformation

Agenda ⤔Enterprise Architecture Challenges ⤔Architecture Repositories Ecosystem ⤔Architecture Model Taxonomies ⤔Model structures & building blocks

Page

EA Scope (TOGAF) ⤔

Initially focused on providing guidance for system design, Enterprise Architecture has gained acceptance as an approach to manage change and foster IT/business alignment by : (a) propagating strategy and process changes to the software and infrastructure level, (b) supporting consistent business transformation enabled by technology innovations, and by (c) decoupling business-oriented and technology-oriented architectures

⤔

Besides supporting strategy execution, a large number of other EA application scenarios exist, e. g. business continuity planning, security management, compliance management and sourcing management [Bu06; RB06]. EA is the primary tool for impact assessment and tradeoff analysis in these scenarios.

Page

Architecture description challenges ⤔ Enhancements of architecture descriptions

Be able to build architecture alternatives. Be able to manage catalogs/libraries of reusable building blocks. Be able to compare alternative architectures Add planning dimension to static architecture descriptions

⤔ Work in a collaborative manner.

Page

Agenda ⤔Enterprise Architecture Challenges ⤔Architecture Repositories Ecosystem ⤔Architecture Model Taxonomies ⤔Model structures & building blocks

Page

EA Repository requirements ⤔In order to support EA functions, EA repositories must cover the following scope: Support EA descriptions (Content Model) Support EA activities (Management & Governance) Support relationships with operational enterprise data sources. Page

Enterprise Repositories Ecosystem EA Repository

External References

Operational Repositories

Tailored EA Framework EA Function & Process Definition uses

EA Functions Definitions

TOGAF, … EA Skills

Governance Frameworks

1

Enterprise Meta-Model Definition

Guidelines

Architecture Work Product Definitions & Templates

Techniques

Diagrams, Matrix, Tables, …

uses

defines the structure of

EA Frameworks, including EA Governance

EA Content Definition

Architecture Development Method Other Processes

COSO: corporate, COBIT: IT…

EA Content EA Governance Repository EA Organization Assessments

Ability Models

EA Stakeholders

provides uses

Reference Material

uses

uses

Standards

Resource Capabilities

ABB

SBB

Architecture Building Block

Solution Building Block

fulfills Organization

provides follows

Business Operating Model

Operation Building Block

realizes

Operating Models

Reference implementation

Digital OBB

meets

meets

Standard Patterns

Enterprise Governance Repository

Enterprise Requirement

Business Capabilities

Architecture Projects Enterprise Concerns & Drivers

Governance Definition

Produced by ‘regular’ ADMs

Decision Log

Workflows

Portfolio of Initiatives

Architecture work products

Standards

Standard References

Planning Information

Software

realizes

CMDBs; BI, …

Non-digital OBB Operation Building Block person, machine, building…

Hardware

Page

Agenda ⤔Enterprise Architecture Challenges ⤔Architecture Repositories Ecosystem ⤔Architecture Model Taxonomies ⤔Model structures & building blocks

Page

Architecture Models Taxonomy ⤔ Architecture meta-models are organized according to three main dimensions: Models which describe finalities, purposes of enterprise & enabling systems: capabilities. Models which describe how enterprises & enabling systems shall operate to fulfill expected capabilities. Models which describe when things are expected (capabilities or systems): they are used for roadmappings.

Capability Models

Describe what is expected from enterprises and from their enabling systems: • Capabilities

Operating Models

Describe how enterprises and their enabling systems shall operate.

Roadmaping Models

PS: an enterprise is a system of systems.

Describe when things are expected • Expected capabilities • Expected system supporting capabilities

Page

Enterprise Capabilities & Operating Models Operating Models

Capability Models

What is expected

What is produced

Who is in charge

What shall be remembered

How things are done

How things are exposed

Ability

Effect

Performer

Information

Process

Services

has desired effects

Model Kind exhibits

⤔ Abilities express expectation of desired Effects under a set of environmental constraints and expected measurable qualities. ⤔ Performers (aka systems) conduct and participate to processes in order to produce deliverables made available through exposed services, thereby responding to expected abilities. Page

Enterprise Capabilities & Operating Models Operating Models

Capability Models

What is expected

What is produced

Who is in charge

What shall be remembered

How things are done

How things are exposed

Ability

Effect

Performer

Information

Process

Services

exposes

has desired effects delivers

Model Kind exhibits

⤔ Abilities express expectation of desired Effects under a set of environmental constraints and expected measurable qualities. ⤔ Performers (aka systems) conduct and participate to processes in order to produce deliverables made available through exposed services, thereby responding to expected abilities. Page

Enterprise Capabilities & Operating Models Operating Models

Capability Models

What is expected

What is produced

Who is in charge

What shall be remembered

How things are done

How things are exposed

Ability

Effect

Performer

Information

Process

Services

exposes

has desired effects delivers

Model Kind exhibits

conducts involves

activates

⤔ Abilities express expectation of desired Effects under a set of environmental constraints and expected measurable qualities. ⤔ Performers (aka systems) conduct and participate to processes in order to produce deliverables made available through exposed services, thereby responding to expected abilities. Page

Enterprise Capabilities & Operating Models Operating Models

Capability Models

What is expected

What is produced

Who is in charge

What shall be remembered

How things are done

How things are exposed

Ability

Effect

Performer

Information

Process

Services

exposes

has desired effects delivers

Model Kind exhibits

conducts involves

stores

activates produces & consumes

⤔ Abilities express expectation of desired Effects under a set of environmental constraints and expected measurable qualities. ⤔ Performers (aka systems) conduct and participate to processes in order to produce deliverables made available through exposed services, thereby responding to expected abilities. Page

Enterprise Capabilities & Operating Models Capability Models

Model Kind →

Operating Models

What is expected

What is produced

Who is in charge

What shall be remembered

How things are done

How things are exposed

Ability

Effect

Performer

Information

Process

Services

exposes

has desired effects delivers conducts

exhibits

involves

↓ EA Layer stores

activates produces & consumes

Business Layer

Business Capability

Content

Business Function

Business Concept

Functional Process

Exchange Contract

Organization Layer

Skill

Content

Org-Unit

Data

Organizational Process

Exchange Contract

Application layer

Functionality

Content

Application System Application

Data

System Process

Exchange Contract

Hardware layer

Functionality

Content

Artifact

Technical Data

System Process

Exchange Contract

Resource Configuration layer

Business Capability Functionality

Content

Resource Architecture

Data & Technical Data

System Process

Exchange Contract

Page

Capability planning ⤔ Capabilities are expected over period of time represented as desired phases of the enterprise (enterprise = undertaking). ⤔ Each enterprise phase expresses a disposition to delivery of a set of capabilities, under particular quantified qualities. Capability Map Capability 2

Capability 1

Capability 1

Desired effect

Desired effect

Desired effect

exhibits

Enterprise state 1 Vision

Capability 3 Capability 2

Capability 1

• Quality 1 • Quality 2

Capability Plan

Capability 2

• Quality a = 5 • Quality • Quality 1 = xb = 6 • Quality 2 = y

• Quality 1 • Quality 2

• Quality 1 • Quality 2

exhibits

Enterprise state 2 • Quality a = 5 • Quality • Quality 1 = xb = 6 • Quality 2 = y

exhibits

Enterprise Phase 2 • Quality 1 = x • Quality a = 5 • Quality • Quality 1 =bx =26= y • Quality • Quality 2 = y

Page

Enterprise Planning & Architecture Models ⤔ Enterprise planning adds a time dimension to enterprise architecture in order to:

Plan what is expected, why and how much. Specify accordingly which architecture should apply for each phase. Ensure that enterprise assets (deployed assets on the ground) are delivered or decommissioned accordingly. EA abstraction layers

Operating architecture of enterprise phases

Time

Phase 1

Needss

Operating Models

Ability Models

Business Model

Conceptual blueprint

Phase 2 Objectives

Enterprise physical assets

exhibited capabilities

architecture of assets

Business Capability

Business Operating Model

Organization

Software

Hardware

Functionality

Resource blueprint

Logical view

Resource Configuration

ICT Capability Outcomes

Performers

Processes

Operating Aspects

Physical view Services

Page

Agenda ⤔Enterprise Architecture Challenges ⤔Architecture Repositories Ecosystem ⤔Architecture Model Taxonomies ⤔Model structures & building blocks State of the art d Page

Composition pattern : what is the problem ? ⤔ We need to address the following concerns for architecture descriptions: Be able to build architecture alternatives. Be able to manage catalogs/libraries of reusable building blocks. Be able to compare alternative architectures. Be prepared for enterprise transformation.

⤔ Problem:

The two common modeling syntax used for architecture descriptions hierarchies and flat models - prevent from creating effective scope for building blocks, thereby denying the notion of building block itself.

Page

Problem 1 : hierarchal models & interconnections ⤔ Benefits of hierarchical models.

Follow the usual breakdown practice (Cartesian approach). Provide scopes for building blocks. This sometimes represented by naming conventions, such as, “X.1.1” and “X.1.2” are in “X.1”. IDEF notations are a good example.

⤔ Problem: hierarchical structures hardwire building blocks together:

Blocks can only be part of a single hierarchy : the single parent syndrome. If multiple parentship are allowed, inter-connections become undefined : the (*,*) relationship syndrome (see next slide). Hierarchy 1

Hierarchy 2

X.1

X.1.1

Y?

X.1.2

X.1.2.1

X.1.1.1

Y.1

X.1.2

Y.1.1

X.1.2.2

X.1.2.2.1

Y.1.2

Y.1.2.1 Y.1.1.1

Y.1.1.2

Y.1.2.2

Page Y.1.2.1.1

Illustration : hierarchal models & interconnections

⤔Let’s consider two application hierarchies: “APP 1..” (on the left below) and “APPX X..”. (on the right below) APP 1

APP 1.1

Msg flow 1

APP 1.2.1

APP 1.1.1

APP 1.1.2

APP X

Inter-hierarchy Msg Flow

APP 1.2

APP XY

Msg flow 2

APP 1.2.2

APP XZY

APP Y

APP XYA

APP XZ

APP XZZ

APP XYB APP Page XZZA

Illustration : hierarchal models & interconnections ⤔ When Sub-Application “APP XY” is composed of “APP 1.2” does this implies that:

The “Msg flow 1” message flow becomes part of the “APP X” application tree ? The “Msg flow 1” message flow becomes part of the definition of the “APP 1.2” application ?

⤔ Similar issues occur for sequence between processes, flows between processes, etc. They prevent from having autonomous building blocks. APP 1

APP 1.1

Msg flow 1

APP 1.2.1

APP 1.1.1

APP 1.1.2

APP X

Inter-hierarchy Msg Flow

APP 1.2

APP XY

Msg flow 2

APP 1.2.2

APP XZY

APP Y

APP XYA

APP XZ

APP XZZ

APP XYB APP Page XZZA

Problem 2 : flat models ⤔ Benefits of flat models:

Avoid the single parent syndrome of hierarchal models. Enable a natural discovery of building blocks and general dependencies.

⤔ Problem:

Architecture scopes have been lost (is eCommerce in HR system?): there is a single global graph. Diagrams are used for pseudo scoping while they have no semantic value (environment diagrams) => back to Visio. Adding a connector at one end of the graph has undefined effect on the rest of the graph, hence building blocks do not have autonomous definitions. Graph Diagram 1 Graph Diagram 2 Retail System

Payment

eCommerce

X.1.2.1

X.1.1.1

X.1.2

What is the impact of adding this connector ? • Is Recruitment changed ? • Is Training changed ? • both ?

HR System

Payroll

X.1.2.2

X.1.2.2.1

recruitment

Y.1.2.1 Y.1.1.1

Y.1.1.2

training

Where is the change impact scope ? Recruitment, HR System, … the entire graph ?

Y.1.2.1.1

Page

Archimate Flat Models ⤔ "Car insurance" is composed of "Change conditions", "Policy" and "Submit Claim”. ⤔ Independently of Car Insurance", "Change Conditions", "Policy" et "Submit Claim" are connected by dependency relationships

Aggregation relationships

Collapsed diagram view Dependency relationships

Page

Archimate Flat Models ⤔ A second model "Car Insurance 2” involves a "Policy 2" object which replace the initial "Policy » object. ⤔ "Change conditions" and "Submit claim“ keep their initial relationships with the initial "Policy” object. Car insurance 2 Car insurance 2 Policy 2

Policy 2

These links are graphically hidden in the collapsed diagram.  We are back to Visio. Page

Decomposition/Composition principles ⤔ Design principles

Autonomy : decomposition is always designed at two levels of depth only. •

The building block and its direct components.

•

building block -> block use -> building block (process -> calling activity -> process).

The complete block structure is obtain through recursive analysis of the following triple :

⤔ Benefits

Reduce block structure complexity (the unresolvable question : how many level of depth ?) Homogeneity of building blocks. Block use enables better requirement design: • •

Requirements are set at the level of bloc usage : what is expected from a block in a specific context (usage). Each block indicates what it is able to achieve independently of how it is used.

 Bad

Building blocks are not autonomous

 Good

use

use

Page Building blocks catalog

Composition & Architecture alternatives Models are organized as elementary blocks, for instance Business Functions. Various assemblies enable the building of alternatives architectures in regard to common reference model (capability below). Business Capability Map Capability 1

Capability 2 realizes

realizes

A Business Architecture Core Business Function 1

Core Business Function 2

Support Business Function 1

Support Business Function 2

Catalog/Library Core Business Function 1

Core Business Function 2

Core Business Function 3

Support Business Function 1

Support Business Function 2

Support Business Function 3

Another Business Architecture Core Business Function 1

Core Business Function 3

Support Business Function 2

Support Business Function 3

Value stream 2

Value stream 1

realizes

Organization 1

realizes

Organization 2

realizes

Organization 3

realizes

Organization 4

Page

26

Composition & Alternatives – Infra level ⤔ The same approach applies at any layer, for instance at the physical layer, building blocks are Artifacts and Org-Units. ⤔ Various assemblies (resource architectures) enable the building of alternatives solutions for a common reference business architecture. Business Architecture

Business Function 1

Business Function 2 realizes

realizes

A Resource Architecture OrgResource 1 Artifact 2

Artifact 1

OrgResource 2

Resource process 1

Physical resource catalog OrgResource 1

OrgResource 2

OrgResource 3

Artifact 1

Artifact 2

Artifact 3

Another Resource Architecture Org-Resource 1

Artifact 3

Artifact 2

Org-Resource 3

Resource process 2 Page

Composition & Alternatives – Software level ⤔ The same approach applies at any layer. For instance, at the application layer, building blocks are Application Systems and Applications. ⤔ Various assemblies (Application Systems) enable the building of alternatives solutions for a common reference logical application architecture. Logical Application System Logical Application

Logical Application realizes

realizes

Another Application System

Application System Application System 1

Application 1 1

Software catalog Application System 1

Application System 2

Application System 3

Application 1

Application 2

Application 3

Application System 1

Application 3 1 3

2 Application 2

Application 2

Org-Resource 1 IT Service 1

Software process 1

Org-Resource 2

IT Service 2

Software process 2 Page

Composition & comparison : differences ⤔ The building block approach allows to detect what has been added and removed from one source structure to another target structure. ⤔ However, this type of comparison doesn’t tell whether these adds and removals are replacements or effective adds and removals. A Resource Architecture

Another Resource Architecture

From 1 to 2

Org-Resource 1

Artifact 1

Org-Resource 1

Artifact 3

Artifact 2

Org-Resource 2

Artifact 2

Org-Resource 3

Resource process 1

Org-Resource 1 Artifact 1

Org-Resource Org-Resource 2 3 Artifact 2

Resource process 2

Artifact 3

Resource catalog

29

Page

Composition & comparison: changes ⤔ Using a reference model as an invariant source for comparison enables to move from difference analysis to change analysis. Business Architecture Business Function 2

Business Function 1

Another Resource Architecture

A Resource Architecture Org-Resource 1

Artifact 1

From 1 to 2 Replacement (from BF1)

Artifact 2

Replacement (from BF2)

Org-Resource 2

Resource process

OrgResource 1

OrgResource 2

OrgResource 3

Artifact 1

Artifact 2

Artifact 3

Org-Resource 1

Artifact 3

Artifact 2

Org-Resource 3

Resource process

Resource catalog/library

Page

30

Composition & comparison & Time: transformation ⤔ Architecture Block assemblies are TIMELESS. ⤔ Adding a time layer, ON TOP OF, block assemblies, enable to address transformation .

Entreprise Plan Enterprise in Phase 1

Enterprise in Phase 2

selected business architecture

Business Architecture selected business architecture

Business Function 1

selected solution architecture

Business Function 2

Another Resource Architecture

A Resource Architecture Artifact 1

Artifact 2

OrgResource 2

Resource process

selected solution architecture

realizes

realizes

OrgResource 1

Enterprise in Phase 3

Replacement (from BF1)

Replacement (from BF2)

OrgResource 1

OrgResource 2

OrgResource 3

Artifact 1

Artifact 2

Artifact 3

Resource catalog/library

OrgResource 1

Artifact 3

Artifact 2

OrgResource 3

Resource process Page

Composite structure benefit summary ⤔ Provide catalogs/libraries of autonomous architecture building blocks.

⤔ Provide alternative assemblies of these building blocks. ⤔ Provide comparison of alternative assemblies. ⤔ Pave the way for enterprise transformation. ⤔ Enable effective multi-layered approaches for enterprise modeling.

See Herbert Simon : Parable of the two watchmakers. Page