Enterprise Modeling for Digital transformation · Digital transformation. ... EA Frameworks,...
Transcript of 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
⤔Enterprise Architecture Challenges
⤔Architecture Repositories Ecosystem
⤔Architecture Model Taxonomies
⤔Model structures & building blocks
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
⤔Enterprise Architecture Challenges
⤔Architecture Repositories Ecosystem
⤔Architecture Model Taxonomies
⤔Model structures & building blocks
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
Capability Models Operating Models
Enterprise Capabilities & Operating Models
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 exposes
Capability Models Operating Models
Enterprise Capabilities & Operating Models
delivers
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 conducts
has desired effects exposes
Capability Models Operating Models
involvesactivates
Enterprise Capabilities & Operating Models
delivers
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 conducts
has desired effects exposes
produces & consumesstores
Capability Models Operating Models
involvesactivates
Enterprise Capabilities & Operating Models
delivers
P a g e
Model Kind →
↓ EA Layer
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
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
Capability Models Operating Models
Enterprise Capabilities & Operating Models
exhibits conducts
has desired effects exposes
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
• Quality 1• Quality 2
Capability 3Capability 2
Capability 1
Desired effect
• Quality 1• Quality 2
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
⤔Enterprise Architecture Challenges
⤔Architecture Repositories Ecosystem
⤔Architecture Model Taxonomies
⤔Model structures & building blocks
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
Artifact 2 Org-Resource 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 System 1
Application 3
Application 2 Org-Resource 2
Software process 2
Logical Application System
Logical Application
Logical Application
Application System 1
Application System 2
Application System 3
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
Artifact 1 Artifact 2 Artifact 3
A Resource Architecture
Org-Resource 1
Artifact 1
Artifact 2 Org-Resource 2
Resource process 1
Another Resource Architecture
Org-Resource 1
Artifact 3
Artifact 2 Org-Resource 3
Resource process 2
From 1 to 2
P a g eP a g e
Replacement(from BF2)
Replacement(from BF1)
Composition & comparison: changes
30
⤔ Using a reference model as an invariant source for comparison enables to move from difference analysis to change analysis.
Business Architecture
Business Function 1
Business Function 2
A Resource Architecture
Org-Resource 1
Artifact 1
Artifact 2 Org-Resource 2
Resource process
Another Resource Architecture
Org-Resource 1
Artifact 3
Artifact 2 Org-Resource 3
Resource process
Resource catalog/library
Org-Resource 1
Org-Resource 2
Org-Resource 3
Artifact 1 Artifact 2 Artifact 3
From 1 to 2
P a g eP a g e
Replacement(from BF2)
Replacement(from BF1)
A Resource Architecture
Org-Resource 1
Artifact 1
Artifact 2 Org-Resource 2
Resource process
Another Resource Architecture
Org-Resource 1
Artifact 3
Artifact 2 Org-Resource 3
Resource process
Business Architecture
Business Function 1
Business Function 2
Resource catalog/library
Org-Resource 1
Org-Resource 2
Org-Resource 3
Artifact 1 Artifact 2 Artifact 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.