Enterprise Architecture (#EntArch) as a #systemsapproach applied management discipline

Enterprise Architecture (#EntArch) as a systems-approach applied

management discipline

Alexander SAMARIN

#entarch as a systems-approach applied management discipline

2

• An enterprise architect– from a programmer to a systems architect (systems of various

sizes: company, corporate, canton, country, continent)– have created production systems which work without me

• Some of my professional roles– “cleaning lady” (usually in an IT department)– “peacemaker” (between the IT and business)– “swiss knife” (for solving any problem)– “patterns detective” (seeing commonalities in “unique” cases)– “assembler” (making unique things from commodities)– “barriers breaker” (there is always a bigger system)– “coordinator” (without any formal authority over components)

About me

2016-07-03


3

• The goal of this talk show how the use of the systems approach to address typical enterprise challenges– an algorithm to generate an enterprise’s blueprint– different people in similar situations come

to similar solutions and possibly bring innovations– an algorithm to build a bigger enterprise from smaller ones

• Management discipline is a coherent set of governing rules for the better management of the enterprise functioning in support of the enterprise goals

• Applied means that existing scientific knowledge is used to develop more practical applications, like technology or inventions

#EntArch as a systems-approach applied management discipline

2016-07-03


4

• system– set of interacting discrete parts organised as a whole which

exhibits (as the result of interaction between the parts) some emergent characteristics indispensable to achieve one or more stated purposes

• systems approach– holistic approach to understanding a system and its discrete parts

in the context of their behaviour and their relationships to one another and to their environment

– Note: Use of the systems approach makes explicit the structure of a system and the rules governing the behaviour and evolution of the system

• Any enterprise is a socio-technical system

2016-07-03

Systems architecting (1)


5

• Architecting is about– making essential decisions about the system-in-focus to enable

the achievement of its desired emergent characteristics– understanding the relationship between structure and behaviour,

between design and outcomes • An architect is a person who

a) translates a customer’s requirements into a viable plan and b) guides others in its execution


2016-07-03


6

• Ideal (happy) path– Formalise your artefacts – syntax and semantic– Define their lifecycles– All artefacts must be versionable throughout their lifecycle– All artefacts must evolve to become externalised, virtual and

cloudable– Assemble some artefacts into other artefacts– All relationships between artefacts must be modelled explicitly –

thus the system’s structure is explicit– All models must be made to be machine-assisted executable –

thus the system’s behaviors can be simulated in advance– Adjust the artefacts and models to achieve the optimal behaviors

for emergent characteristics 2016-07-03



7

• My digital manifesto– Business artefacts are available in digital formats (explicit, formal

and machine-executable)– Digital is the master media for business artefacts

• In systems architecting the focus is changing– FROM the thing (or the artefact)– TO how the thing changes – HOW things change together

• With the required speed and scale, there is no time for human intervention and errors

• “In the digital age innovation depends on process automation”

Effect of digital

2016-07-03


8

• #EntArch must coordinate people, processes, projects and products in many dimensions:1. scope span (device, activity, …, country, market)2. value-stream span (domain-dependent)3. interoperability layer (business, information,

apps, etc.)4. time span (project life-cycle, solution

life-cycle, etc.)5. sector span (various industries)6. problem space (situation-specific)7. solution space (context, conception, …, operations - ZF rows)…

Architecting enterprises as social-technical systems (1)

2016-07-03


9

• #EntArch must coordinate people, processes, projects and products in many dimensions:…8. social space (gender equality, consensus building, conflict

resolution)9. cultural space (multi-lingual communication, national mentality,

regional mentality, corporate mentality)10. media span (physical vs analogue vs digital vs bionic)11. authority span (top management, …, workers)12. person span (individual, house, personal cars, public places, etc.)13. financial span14. CX span (touch point, journey, storytelling, lifecycle)

Architecting enterprises as social-technical systems (2)

2016-07-03


10

• Customers• Shareholders• Corporate board• Top management• Line management• Super users• Normal users• Project managers• IT architects• Developers• Operators• … and all of them must be comfortable with the system

Lots of stakeholders — many concerns and views

2016-07-03


11

• Geometrical viewpoints of buildings are viewed side by side — as a composition

From ISO/IEC/IEEE 42010• View (system-in-focus dependent) vs

viewpoint (system-in-focus dependent)

• Multiple viewpoints are mandatory

• Architectural viewpoints are often originated by different people — thus they must be aligned to be used together

2016-07-03


12

• concept system or terminology or “common taxonomy”• business motivation• business outline• capability-as-discrete-unit-of-purpose• operating outline• process map & service map• capability-as-performance• events (triggers) nomenclature• macro-planning & project portfolio • application architecture • data / information architecture • technology architecture

2016-07-03

Many viewpoints


13

1. Creating from scratch2. Changing business outline3. Changing operating outline4. Building bigger systems via incorporation of smaller ones

2016-07-03

For scenarios for systems transformation


14

• Slide 6 from http://www.slideshare.net/TheDesignOfBusiness/introducing-the-open-group-it4it-standard

• https://www.salesforce.com/blog/2016/04/how-salesforce-does-enterprise-architecture-.html

• https://www.linkedin.com/pulse/design-direct-monitor-enterprise-digital-using-sarath-chandran

2016-07-03

Examples from various sources

http://www.slideshare.net/TheDesignOfBusiness/introducing-the-open-group-it4it-standard

https://www.salesforce.com/blog/2016/04/how-salesforce-does-enterprise-architecture-.html

https://www.salesforce.com/blog/2016/04/how-salesforce-does-enterprise-architecture-.html

https://www.linkedin.com/pulse/design-direct-monitor-enterprise-digital-using-sarath-chandran




15

• Synonyms for “creating company”– greenfield project– top-down project– design of business

• Examples– sports events– military mission– start-up

• The challenge– an algorithm for creating a company by business people– everything is digital by default– automate as much as possible (80 % automatic and 20 % agile

fine tuning)

Scenario 1 “Creating any company from scratch”

2016-07-03


16

– Creation every 4 years of an ad-hoc company with a 5-year lifecycle

– Contracting key partners (venues, national associations, broadcasters)

– Defining the services to be delivered (VIP, broadcast rights, ticketing, etc.)

– Developing the organisational structure including one team per venue

– Contracting people (including volunteers) and training them– Organising travel, accommodation, logistics, uniforms, etc.

for staff and VIPs– Setting-up venues – Operating, i.e. executing, the event (many activities each day)– Dismantling of venues– Post-event placement of volunteers– Liquidation of the ad-hoc company

Example — a sports event company

2016-07-03


17

• Think football – a lot people can play football, but only some of them can play football at the level required to win EURO 2016

• A business capability is a concept that captures – “what” an enterprise must do to achieve its mission and – “how well” an enterprise must doing that “what” to achieve its

mission • Capability is independent from “how” do we do it, “where”

we do it, “who” does it, “which tools” are used • There are two major extensions of the concept ‘capability’:

– capability as a discrete-unit-of-purpose– capability as a measure-of-performance

2016-07-03

About the concept `capability’


18

Algorithm (1) — purpose of the company

Purpose Business motivation viewpoint: vision, mission, stakeholders

2016-07-03


19

Algorithm (2) — capability as discrete unit of purpose

PurposeBusiness motivation viewpoint: vision, mission

Capability A2Capability A1

Capability B1 Capability B2 Capability B3 Capability B4

Business outline viewpoint

2016-07-03


20

Algorithm (3) — implementations of capabilities


Capability A2Function A2


Capability B1Commodity

Capability B2B2B service

Capability B3Process B3

Capability B4COTS

Business outline viewpoint- B2C for customers- B2B with key partners- shared capabilitiesB2C

2016-07-03


21

Algorithm (4) — operating model







Capability B4COTS


Operating outline viewpoint

2016-07-03


22

Algorithm (5) — machine-executable







Capability B4COTS



Microservices viewpoint- stateless or stateful- idempotent

Composite microservice

APIBPM-suite formSpecific development

2016-07-03

COTS B2B service


23

• Various industry reference models– value streams– capabilities

Generating capabilities

2016-07-03


24

Matching business functions and tools

Business Functions

Tools

Concrete business capabilities

Specific technical capabilities

GeneralisedTechnical capabilities

Uniform Business capabilities

Tools

Implicit Implementation

Business Functions

Magic

• Various patterns and good business practices

2016-07-03


25

Modelling of processes on demand

L1 Value-steam

s

L2 Clusters-of-processes

L3 Coordination of fragments

L4 Coordination of activities

L5 Automation of activities and processes

Departmental projects to implement the processes of a particular business domain with a BPM-suite tool

Quick enterprise-wide “landscape” project to develop L1 and L2 processes and to establish common practices (modelling procedures, patterns, etc.)

2016-07-03


26

Addressing B2C concerns about customer experience

2016-07-03


27

• There are two major interpretations of the concept ‘capability’:– capability as a discrete unit-of-purpose

(WHAT, “do the right things” or functional requirements)

– capability as a measure-of-performance (HOW WELL, “do things right” or non-functional requirements)

• Without explicit and machine-executable processes any performance estimations are qualitative

• With explicit and machine-executable processes any performance estimations can be quantitative

• Explicit and machine-executable processes are models to be used for predictive analytics (next best action, next best improvement, etc.)

From qualitative to quantitative

2016-07-03


28

• How can you manage efficiently many contracts?

• Consider each contract is a process-centric solution (who is doing what, when, how well, etc.)

• But such a contract must be “immutable”:– open-source BPMs tool – standardised and certified execution semantic– contract process definition is immutable (save it in a blockchain!)– all the audit-trails and collected data are immutable – potentially, BPM-suite tool is operated by a certified third-party– potentially, my “digital” lawyer is one of the miners in this blockchain

B2B and commodities — many contracts to manage

2016-07-03


29

• Scenario 2 “Changing operating outline”– Synonyms

• modernizing, optimizing, refactoring, restructuring, rationalisation, standardisation, etc.

– Examples• BPR, CPI, TQM, etc.

• Scenario 3 “Changing business outline”– Synonyms

• rethinking, reimagining, reinventing, innovations, etc.– Examples

• disruptive strategy

2016-07-03

Two variants of “Creating from scratch”


30

• Synonyms– bottom-up– integration

• Examples – silos removal– M & A – system of systems, i.e. no control

over constituting systems – supply-chain – smart-city– smart-energy– healthcare– e-government

2016-07-03

Scenario 4 “Building bigger systems via incorporation of smaller ones”


31

• Question: What should be done to say “all the interacting discrete parts of the system-in-focus work as a whole”?

• Answer: all the interacting discrete parts of the system-in-focus must be incorporated structurally and behaviorally to guarantee the desired emergent characteristics

• Question: What are the system-forming factors for a particular system-in-focus?

• Answer: – Determine “dimensions” which are most

import for the system-in-focus– Start with “dimensions” as integration pillars– Align between “dimensions”

2016-07-03

General considerations for this scenario


32

• Energy stream or “domains” (energy generation, energy transmission, energy delivery, energy consumption)

• Operating span or “zones” (process, field, station, operation, enterprise, market)

• Interoperability layers (business, functions, information, communication, components)

2016-07-03

Example of dimensions from IEC SyC “Smart Energy”


33

• Interoperability layers business, functions, information, communication, components

• Operating span or “Hierarchy Levels” (product, field device, control device, station, work-centre, enterprise, connected-world)

• Value stream

2016-07-03

Example of dimensions from Germany, Industry 4.0


34

• Proximity (aura/body, home, personal vehicle, public building, global)

• Enablers (monitoring, audio-visual interaction, assistance systems, data acquisition, mechatronics and control, data aggregation and storage, defined function control and support, complex cross-function service control and support, integral service programs)

• Interoperability layers (business, functions, information, communication, components)

2016-07-03

Example of dimensions from IEC SyC “Ambient Assisted Living”


35

• Potential partners form a common governance body• A reference model (including ontology) must be created• Practically all capabilities are implemented by B2B• Capabilities of each business partners (their B2C) must be

made available in a standardise form• Coordination must be use to assemble some capabilities

from existing capabilities• Trust and traceability are very important – use blockchain

2016-07-03

Bigger systems are system-of-systems


36

• Think football – a lot people can play football, but only some of them can play football at the level required to win EURO 2016

• A business capability is a concept that captures – “what” an enterprise must do to achieve its mission and – “how well” an enterprise must doing that “what” to achieve its

mission • Capability is independent from “how” do we do it, “where”

we do it, “who” does it, “which tools” are used • There are two major extensions of the concept ‘capability’:

– capability as a discrete-unit-of-purpose– capability as a measure-of-performance

2016-07-03

About the concept `capability’


37

Algorithm (1) — existing systems

2016-07-03system 1 Existing systemssystem 2


38

Algorithm (2) — existing services

2016-07-03service 1.1 service 2.1 service 2.2 Existing servicesservice 1.2


39

Algorithm (3) — purpose of the system

Purpose

2016-07-03service 1.1 service 2.1 service 2.2 Existing services

Business motivation viewpoint: vision, mission, stakeholders, etc.

service 1.2


40

Algorithm (4) — capability as discrete unit of purpose

Purpose


Capability B1 Capability B2 Capability B3 Capability B4

Reference model viewpoint



service 1.2


41

Algorithm (5) — reference implementation

Purpose


Capability B1 Capability B2 Capability B3Process B3

Capability B4COTS

Reference model viewpoint with reference implementation


Gap Gap


service 1.2


42

Algorithm (6) — operating model

Purpose



Capability B4COTS




Gap Gap


service 1.2


43

Algorithm (7) — composition of services via API

Purpose



Capability B4COTS



Implementation viewpoint- Existing services- Commodities- etc.

Composite microservice

2016-07-03

Commodity

API API API

service 1.1

service 1.2 service 2.1

service 2.2 Existing services

Gap Gap

GapAPI



44

• Align terminology or, even better, make an ontology– concept system

• Understand concerns of all people involved– stakeholders analysis

• Develop common syntax, semantic and lifecycles for all assets– data / information nomenclature

• List external and internal (change lifecycle phases) events– event nomenclature

• Analyse all existing parts to decompose them into services– use-cases

2016-07-03

As much as possible common definitions


45

• Various industry reference models– value streams– capabilities

Generating capabilities

2016-07-03


46

Matching business functions and tools

Business functions

Tools

Concrete business capabilities

Specific technical capabilities

Generalisedtechnical capabilities

Uniform business capabilities

Tools

Implicit implementation

Business functions

Magic

• Various patterns and good business practices

2016-07-03

Business function B1

Business function C3

• Implementation of business function B1 comprises business function C3 which is “smaller” than B1) and tools T1, T2, T3 & T9

2016-07-03 #entarch as a systems-approach applied management discipline

47

Step 1

Tool T1 Tool T2 Tool T3 Tool T9


• Implementation of B1 requires (in addition to C3) some concrete business capabilities (as requirements described by the owners of B1)

Business function B1Concrete business capability B1Z Business function C3


48

Step 2


Concrete business capability B1B

Concrete business capability B1A


• Concrete business capabilities can be implemented by various specific technical capabilities

Business function B1Concrete business capability B1Z

Specific technical capability T9A


Specific technical capability T9B






49

Step 3





• The concrete business capability B1A was agreed to match the common good-business-practice business BC10








Uniform business capability BC10

Good business practices and business patterns

Uniformbusiness capability BC11



50

Step 4





• Specific technical capabilities T1B and T2A are the same generalized technical capability TC30

Business Function B1Concrete business capability B1Z








Generalised technical capability TC10



Standardized or generalised functionality“de-facto” or “de-jure”

Business Function C3


51

Step 5




• Thus tool T2 can be eliminated









Generalised technical capability TC10



Standardized or generalised functionality“de-facto” or “de-jure”



52

Step 6





54

• How can you manage efficiently many contracts?

• Consider each contract is a process-centric solution (who is doing what, when, how well, etc.)

• But such a contract must be “immutable”:– open-source BPMs tool – standardised and certified execution semantic– contract process definition is immutable (save it in a blockchain!)– all the audit-trails and collected data are immutable – potentially, BPM-suite tool is operated by a certified third-party– potentially, my “digital” lawyer is one of the miners in this blockchain

B2B and commodities — many contracts to manage

2016-07-03


55

Modelling of processes on demand

L1 Value-steam

s

L2 Clusters-of-processes

L3 Coordination of fragments

L4 Coordination of activities

L5 Automation of activities and processes

Departmental projects to implement the processes of a particular business domain with a BPM-suite tool

Quick enterprise-wide “landscape” project to develop L1 and L2 processes and to establish common practices (modelling procedures, patterns, etc.)

2016-07-03


56

• Find dependencies between functions and events (e.g. function is invoked because of an event) and express them via different coordination techniques (flow-chart, schedule, decision, etc.)– various model kinds for coordination

• Find implicit processes and make them explicit– process map

• Find various gaps – integration points– coordination points– touch points– missing parts

2016-07-03

Coordination is very important


57

• Orchestration-centric– temporal-based – flow-chat-based– pattern-based

• State-centric– life-cycle-based

• Decision-centric– rule-based– behaviour-based– managerial – instinct-based

2016-07-03

About coordination techniques (1)


58

• Various– resource-based – goal-based – event-based

2016-07-03

About coordination techniques (2)


59

Coordination technique

Level of coordination

Type of coordination

Nature of coordination

Horizon of coordination

Intensity of coordination

Scope of coordination

Flexibility of coordination

Orchestration strong imperative explicit future high group low

State strong imperative explicit now low individual low

Decision weak declarative both now low individual low

Event weak declarative implicit now various individual++ high

2016-07-03

Comparison of coordination techniques

– level: weak (crowd) or strong (army)– type: imperative (working instruction) or declarative (a set of constrains)– nature: explicit (as state laws or directives) or implicit (tacit, social)– horizon: now or future– intensity: low or high or various– scope: individual or group (set)– flexibility: low or high


60

• BPM-suite tool viewpoint• Microservices application viewpoint• Microservices execution viewpoint• Platform viewpoint• Security viewpoint• Governance viewpoint• Project management viewpoint

2016-07-03

Some transversal viewpoint


61

BPM-suite + SOA + ESB viewpoint

2016-07-03


62

Application microservice architecture viewpoint

The microservices way:- the speed of change- the safety of change- at scale- in harmony

2016-07-03


63

Microservices execution viewpoints

Error-recovery process design

Microservices as scripts for universal robots

Queueing jobs for robots

2016-07-03


64

• Because of the coherent design, many components will be common and thus constitute a Corporate Uniformed Business Execution (CUBE) platform

Platform viewpoint (1)

2016-07-03


65

Platform viewpoint (2)

Platforms combine:- diversity - uniformity

Potential platforms:- e-government- smart-city- e-health

2016-07-03


66

Security viewpoint — dynamic security

2016-07-03


67

• If the “Activity_B” validates the results of “Activity_A” then no actor should be simultaneously in “Role_1” and “Role_2”

Security viewpoint — process-based access control

2016-07-03


68

Governance viewpoint — follow artefacts’ lifecycles

2016-07-03


69

• To check that your set of processes / functions / capabilities is complete:map functions vs primary artefacts

• An IT framework with “holes”

• A set of typical IT value streams

Governance viewpoint — is our model complete?

2016-07-03


70

• Top-down architecting to reduce the complexity, then start agile implementations

Project management — mixture of top-down & agile

2016-07-03

• There are several viewpoints and model kinds which are mandatory for enterprise-as-a-system

• Certainly, some viewpoints can be derived from other viewpoints

• There is still lack of patterns for various viewpoints and model kinds

• There is still lack of techniques to transform some models to other models (thus views to views)

• Conventional EA tools offer little help


71

Conclusions


72

• Personal website: http://www.samarin.biz• Blog http://improving-bpm-systems.blogspot.com• LinkedIn: http://www.linkedin.com/in/alexandersamarin• E-mail: [email protected]• Twitter: @samarin • Mobile: +41 76 573 40 61• Book: www.samarin.biz/book

Thank you

2016-07-03

http://www.samarin.biz/

http://improving-bpm-systems.blogspot.com/

http://improving-bpm-systems.blogspot.com/

http://www.linkedin.com/in/alexandersamarin

http://www.linkedin.com/in/alexandersamarin

mailto:[email protected]

http://www.twitter.com/samarin

http://www.samarin.biz/book


73

• Add capability slides• Re-draw capability boxes• add 0 slide for bottom-up• add “eclipse” patterns to the bottom-up• Measurable, Repeatable and Predictable• Requirements are simply a projection of the descriptive

system model into the problem domain, not a separate model themselves.

2016-07-03

to do

Enterprise Architecture (#EntArch) as a #systemsapproach applied management discipline

Technology

Transcript of Enterprise Architecture (#EntArch) as a #systemsapproach applied management discipline