enterprise modeling for digital transformation · digital transformation. ... ea frameworks,...

Enterprise Modeling for Digital transformation

P a g eP a g e

Agenda

⤔Enterprise Architecture Challenges

⤔Architecture Repositories Ecosystem

⤔Architecture Model Taxonomies

⤔Model structures & building blocks

P a g eP a g e

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 applicationscenarios exist, e. g. business continuity planning, security management, compliancemanagement and sourcing management [Bu06; RB06].

EA is the primary tool for impact assessment and tradeoff analysis in these scenarios.

P a g eP a g e

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.

P a g eP a g e

Agenda





P a g eP a g e

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.

P a g eP a g e

Enterprise Repositories EcosystemExternal References EA Repository

EA Content

Ability Models

Assessments

Decision Log

EA Frameworks, including

EA Governance

TOGAF, …

Governance Frameworks

COSO: corporate, COBIT: IT…

Tailored EA Framework

Operational

Repositories

Governance Definition

Enterprise Governance Repository

Business Capabilities

Planning Information

Digital OBB Operation Building Block

CMDBs; BI, …

Portfolio of Initiatives

Enterprise Requirement

EA Function & Process Definition

EA Functions Definitions

Architecture Development Method

Other Processes

Guidelines

Techniques

EA Content Definition

Enterprise Meta-Model Definition

Architecture Work Product Definitions & Templates

Diagrams, Matrix, Tables, …

Non-digital OBB Operation

Building Block

person, machine, building…

realizes

uses

uses

Reference

Material

Standards

Referenceimplementation

uses

uses

meets

1

de

fine

s th

e s

tructu

re o

f

EA Organization

EA Skills

Resource Capabilities

EA Governance Repository Architecture work productsProduced by ‘regular’ ADMs

Workflows

Standards

meets

Operating Models

SBBSolution Building Block

fulfills

Organization

Software

Hardware

ABBArchitecture Building

Block

Business Operating Model

Standard References

providesfollows

providesuses

Standard Patterns

EA Stakeholders

Enterprise Concerns & Drivers

Architecture Projects

realizes

P a g eP a g e

Agenda





P a g eP a g e

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 road-mappings.

PS: an enterprise is a system of systems.

Capability Models Operating Models

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

Describe how enterprises and their enabling systems shall operate.

Roadmaping Models

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

P a g eP a g e

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

Model Kind

What is expected What is produced Who is in chargeWhat shall be remembered

How things are done

How things are exposed

Ability Effect Performer Information Process Services

exhibits

has desired effects


Enterprise Capabilities & Operating Models

P a g eP a g e



Model Kind


How things are done



exhibits

has desired effects exposes



delivers

P a g eP a g e



Model Kind


How things are done



exhibits conducts



involvesactivates


delivers

P a g eP a g e



Model Kind


How things are done



exhibits conducts


produces & consumesstores


involvesactivates


delivers

P a g e

Model Kind →

↓ EA Layer


How things are done



Business Layer Business Capability Content Business Function Business Concept Functional Process Exchange Contract

Organization Layer Skill Content Org-Unit DataOrganizational

ProcessExchange Contract

Application layer Functionality ContentApplication System

ApplicationData System Process Exchange Contract

Hardware layer Functionality Content Artifact Technical Data System Process Exchange Contract

Resource Configuration layer

Business Capability Functionality

ContentResource

ArchitectureData &

Technical DataSystem Process Exchange Contract



exhibits conducts


produces & consumesstores

involvesactivates

delivers

P a g eP a g e

Capability MapCapability 2

Capability Plan

Enterprise state 1 Enterprise state 2

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 1

Desired effect

• Quality 1• Quality 2

Enterprise Phase 2

• Quality a = 5• Quality b = 6

exhibits exhibits

Capability 2

Capability 1

Desired effect


Capability 3Capability 2

Capability 1

Desired effect


exhibits

Vision• Quality a = 5• Quality b = 6

• Quality 1 = x• Quality 2 = y

• Quality a = 5• Quality b = 6• Quality 1 = x

• Quality 2 = y• Quality 1 = x• Quality 2 = y

• Quality 1 = x• Quality 2 = y

P a g eP a g e

Time

Business Model Operating 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 abstractionlayers

Ability Models

Resourceblueprint

Organization Software Hardware

Resource Configuration

ConceptualblueprintBusiness Operating Model

Functionality

Business Capability

Outcomes Performers Processes Services

Operating Aspects

ICT Capability

Logical view

Physical view

Operating architecture of enterprise phases

Enterprise physical assets architecture

of assets

Enterprise Planning & Architecture Models

Phase 1 Phase 2

Needss Objectives exhibited capabilities

P a g eP a g e

Agenda





State of the art

d

P a g eP a g e

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.

P a g eP a g e

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 1X.1

X.1.2.2

X.1.1

X.1.2.1

X.1.1.1

X.1.2

X.1.2X.1.2.2.1

Hierarchy 2

Y.1

Y.1.2.2

Y.1.1

Y.1.2.1

Y.1.1.1

Y.1.2

Y.1.1.2Y.1.2.1.1

Y ?

P a g eP a g e

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

APP 1.1

APP 1.2.1

APP 1.1.1

APP 1.2

APP 1.1.2 APP Y

APP X

APP XZZ

APP XY

APP XZY

APP XYA

APP XZ

APP XYB

APP XZZA

Msg flow 1 Msg flow 2Inter-hierarchy Msg Flow

P a g eP a g e

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

APP 1.1

APP 1.2.1

APP 1.1.1

APP 1.2

APP 1.1.2 APP Y

APP X

APP XZZ

APP XY

APP XZY

APP XYA

APP XZ

APP XYB

APP XZZA

Msg flow 1 Msg flow 2Inter-hierarchy Msg Flow

P a g eP a g e

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 1Retail System

X.1.2.2

eCommerce

X.1.2.1

X.1.1.1

Payment

X.1.2X.1.2.2.1

Graph Diagram 2

HR System

training

Payroll

Y.1.2.1

Y.1.1.1

recruitment

Y.1.1.2 Y.1.2.1.1

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

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

P a g eP a g e

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

Dependency relationships

Collapsed diagram view

P a g eP a g e

⤔ 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 2Car insurance 2

Policy 2

Policy 2

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

Archimate Flat Models

P a g eP a g eBuilding blocks catalog

Decomposition/Composition principles⤔ Design principles

Autonomy : decomposition is always designed at two levels of depth only.• The building block and its direct components.

The complete block structure is obtain through recursive analysis of the following triple : • building block -> block use -> building block (process -> calling activity -> process).

⤔ BenefitsReduce 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.

Good Bad use use

Building blocks are not autonomous

P a g eP a g e

Catalog/Library

26

A Business Architecture

Core Business

Function 1

Core Business

Function 2

Support Business

Function 1

Support Business

Function 2

Value stream 1

Another Business Architecture

Core Business

Function 1

Core Business

Function 3

Support Business

Function 2

Support Business

Function 3

Value stream 2

Organization 1 Organization 2 Organization 3 Organization 4

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

Composition & Architecture alternatives

Business Capability Map

Capability 1 Capability 2

Core Business

Function 1

Core Business

Function 2

Core Business

Function 3

Support Business

Function 1

Support Business

Function 2

Support Business

Function 3

realizesrealizes

realizesrealizesrealizes realizes

P a g eP a g e

Physical resource catalog

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.

A Resource Architecture

Org-Resource 1

Artifact 1

Artifact 2 Org-Resource 2

Resource process 1

Another Resource Architecture

Org-Resource 1

Artifact 3


Resource process 2

Business Architecture

Business Function 1

Business Function 2

Org-Resource 1

Org-Resource 2

Org-Resource 3

Artifact 1 Artifact 2 Artifact 3

realizes realizes

P a g eP a g e

Software catalog

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.

Application System

Application System 1

Application 1

Application 2 Org-Resource 1

Software process 1

Another Application System


Application 3

Application 2 Org-Resource 2

Software process 2

Logical Application System

Logical Application

Logical Application




Application 1 Application 2 Application 3

12

13

realizes realizes

IT Service 1 IT Service 2

P a g eP a g e

Resource catalog

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.

29

Org-Resource 1

Org-Resource 2

Org-Resource 3



Org-Resource 1

Artifact 1


Resource process 1


Org-Resource 1

Artifact 3


Resource process 2

From 1 to 2

P a g eP a g e

Replacement(from BF2)


Composition & comparison: changes

30

⤔ Using a reference model as an invariant source for comparison enables to move from difference analysis to change analysis.


Business Function 1

Business Function 2


Org-Resource 1

Artifact 1


Resource process


Org-Resource 1

Artifact 3


Resource process

Resource catalog/library

Org-Resource 1

Org-Resource 2

Org-Resource 3


From 1 to 2

P a g eP a g e




Org-Resource 1

Artifact 1


Resource process


Org-Resource 1

Artifact 3


Resource process


Business Function 1

Business Function 2

Resource catalog/library

Org-Resource 1

Org-Resource 2

Org-Resource 3


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 2 Enterprise in Phase 3Enterprise in Phase 1

selected solution architecture

selected business architecture

selected business architecture

selected solution architecture

realizes realizes

P a g eP a g e

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.

http://www.mech.kuleuven.be/goa/hms-int/parable.html

enterprise modeling for digital transformation · digital transformation. ... ea frameworks,...

Documents