How EA, BPM, SOA and ECM work together

How EA, BPM, SOA and ECM work together

Alexander Samarin for the BPM mini-conference

https://www.dataforeningen.no/program.316567.no.html

EA – Enterprise ArchitectureBPM – Business Process ManagementSOA – Service Oriented ArchitectureECM – Enterprise Content Management

https://www.dataforeningen.no/program.316567.no.html

Architecting synergy v2 2

• A digital enterprise architect– from a programmer to a systems architect – have created systems which work without me

• WHY I do what I do– I believe that many improvements (“sooner, better, cheaper, more

flexible”) in operational excellence and strategy execution are achievable with reasonable efforts and commodity tools

• HOW I do what I do– architecting synergy between strategies, technologies, tools and

best practices for client’s unique case and transfer the knowledge

• WHAT is the result of my work for clients

– less routine work, less stress, higher performance, higher security, less risk, higher predictability of results, better operations, and liberating the business potentials

About me

© A. Samarin 2014


• Context – manage complexity in the digital age

• BPM reference model

– BPM and SOA

– BPM and information security

• Platform-based architecture

– ECM, Electronic Publishing

• Enterprise as a system of processes

– Patterns

• Combined examples

– Shared services, legacy application architecture, e-gov, healthcare, SIC

© A. Samarin 2014

Agenda


– It is not about “just the website”, “online services” or “transactions”

– Everything becomes digital: products, information, content, documents, records, processes, money, rights, communications

– If digital then intangible thus news tools and new execution speed “immediately”

– Digital things are at new scale – petabytes and exabytes

– With this new speed and scale, there is no time for human intervention and errors in routine operations and at interfaces

© A. Samarin 2014

Digital age


• Experience shows that business wants separate requests for change to be implemented quickly in existing IT solutions and systems

• These changes are typically small (from the point of view of the business) and unpredictable (from the point of view of the IT)

• To carry out these changes easily and in a managed way, business systems must be properly architected / designed / engineered

© A. Samarin 2014

Business reality

Architecting synergy v2

• Different estimations of the development/maintenance life-cycle cost ratio

© A. Samarin 2014 6

Solutions need to be adaptive

2 – Estimated average in the IT industry

maintenance

development 80 %

20 %

2

40 %

60 %

1

95 %

5 %

33 – A real scenario (governmental client)

1 – Estimated by an IT staff member


• Co-existence of many artefacts

– vision, plans, processes, capabilities, services, etc.

• Dynamic and interrelated

• Not all relationships between artefacts are explicit

• Not all relationships between artefacts are interpreted consistently by different staff members and systems

• Small changes can be very destructive


Complexity


• There are two different sources of complexity:

– natural as we use more and more complex products produced by more and more interlinked companies and

– undesired as we do things with inadequate tools, without using the best available knowledge, via communicating in not the “same” language, by reinventing the wheel, following contradictory recommendations from consultants, drawing a process and executing something else, etc.

• The purpose of enterprise architecture

– guide solution architecture to follow the natural complexity to avoid adding undesired complexity

– promote the use explicit and executable techniques to reduce the natural complexity

– “liberate” resources to better handle the natural complexity© A. Samarin 2014

Managing complexity


• EA coordinates people, process and technologies in 4D

1. Business domain span (organisational unit, segment, enterprise, …)

2. Architecture span (business, data, application, technology, …)

3. Time span (solution life-cycle, technology life-cycle, tool life-cycle, project life-cycle, …)

4. Sector span (common patterns in unique processes from different sectors)

© A. Samarin 2014

EA as a systemic coordinator




– BPM and SOA





– Patterns



© A. Samarin 2014

Agenda

Architecting synergy v2© A. Samarin 2014 11

BPM is a tool for improving enterprise business performance

The theoryBPM as a discipline (use processes to manage an enterprise)

The toolsBPM as software:BPM suite (BPMS)

The practiceAny process-centric enterprise has some BPM (as discipline and tool), but how can we industrialise this BPM?

A natural evolution of BPR, Lean, ISO 9001, 6 Sigma

The aim is to have a single description of business processes:- model in design- input for project planning and execution- executable program for coordination of work- documentation for all staff members- basis for management decisions

An enterprise portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio

A multitude of tools “handle” processes

© A. Samarin 2014 Architecting synergy v2 12

Be ready for common (mis-)understanding


• Enterprise functioning can be considered as business activity flows spanning the applications, employees, customers and partners within and beyond the boundaries of the enterprise

• Business activity is a unit of work

• A business process is an explicitly-defined coordination for guiding the purposeful enactment of business activities

• Process-based disciplines (TQM/QMS, BPR, TPS, 6Sigma, BPM, etc.) exploit the concept of business processes for the better management of the enterprise functioning in support of the enterprise goals

© A. Samarin 2014

BPM definitions (1)


• Business Process Management (BPM) is a process-based discipline involving any combination of modeling, automation/implementation, execution, control, measurement and optimization of business processes

© A. Samarin 2014

BPM definitions (2)


• Process template – a formal description of the process

• Process instance – enactment of a process template

• Different variations of relationship between template and instance

Process templates and instances

Templates and their versions

Instances

© A. Samarin 2014

Architecting synergy v2 16© A. Samarin 2014

Variant 1 – classic (one template is used for many instances)


Variant 2 – tailoring (a template is adjusted for each instance)


Variant 3 – reactive (no initial template and next activity is selected based on

the current situation)


Variant 4 – proactive planning (similar to variant 3, but a few next activities [fragment] are executed together)


Variant 5 – scenario-based (similar to variant 4, but a few scenarios are

considered)

Process fragments are used; those may be patterns


• An enterprise is a complex, dynamic and adaptive system; one can improve it by:

– measuring

– observing

– deciding

– implementing

BPM reference model:Improvement loop

1

2

3

4

© A. Samarin 2014


BPM reference model:Process-based disciplines

© A. Samarin 2014


BPM reference model:Process-oriented view of an enterprise

(before BPM)

© A. Samarin 2014


BPM reference model:Process-oriented view of an enterprise

(with BPM)

© A. Samarin 2014


BPM reference model:BPM suite components


BPM reference model:BPM suite components (extended list)




– BPM and SOA





– Patterns



© A. Samarin 2014

Agenda


• Events

• Roles

• Data structures

• Documents

• Rules

• Audit trails

• KPIs

• Processes

• Services

© A. Samarin 2014

BPM artifacts

KPIs

Processes Services

Events

Roles Data structures

Documents

Rules

Human “workflow”

Audit trails


• Who (roles) is doing What (business objects), When (coordination of activities), Why (business rules), How (business activities) and with Which Results (performance indicators)

• Make these relationships explicit and executable

What you model is what you execute

“The map is the app”

© A. Samarin 2014

Business processes are complex relationships between artefacts


• Services are considered to be explicitly-defined and operationally-independent units of functionality

– Formal description

– Operational independence

– Invisible implementation

Services

© A. Samarin 2014


• Definition

– architectural approach for constructingsoftware-intensive systems from a setof universally interconnected and interdependent services

• Advantages

– use of standard and pre-fabricatedbuilding blocks

– high level of system flexibility

– reducing complexity

– building bigger services from smaller ones

31

Service-Oriented Architecture (SOA)

© A. Samarin 2014


• BPM, by revealing the artefacts and the relationships between them, provides the necessary context (e.g. granularity) for the definition of services

• SOA provides recommendations for the implementation, execution and governance of services

• BPM provides a mechanism for the explicit and executable assembling of bigger services from smaller ones


Synergy between BPM and SOA (1) – structuring relationships


• The relationship between services and processes is “recursive”

– All processes are services

– Some operations of a service can be implemented as a process

– A process includes servicesin its implementation




• Each enterprise is a complex, dynamic, unique and “recursive” relationship between services and processes

– Services can be replaced by processes

– Processes can be replaced by services

– Some of them are moved to clouds



service process


Synergy between BPM and SOA (4) – Implementation layers of artefacts


Synergy between BPM and SOA (5) – Relationship with other technologies


Synergy between BPM and SOA (6) –no applications – just coordination of

services




– BPM and SOA





– Patterns



© A. Samarin 2014

Agenda

• Align access rights with the work to be done


BPM and information security: dynamic access control

Do something

Grant necessary rights to a person who will carry out this activity to access involved business objects

Revoke previously granted rights


BPM and information security:Extra relationships between activities (1)

Mandatory: different actors because of the separation of duties

Potentially: different actors because of performance impact – avoid assigning mechanical (low-qualified “red”) activities and added-value (“green”) activities to the same actors


Responsible Accountable

Consulted Informed

BPM and information security:Extra relationships between activities (2)

© A. Samarin 2014


• There are security-related relationships between activities

• Example

– “Activitiy_B” relates to Activity_A as “Validating the work”

– These activities may be in different processes

– No actors must be assigned to both “Role_1” and “Role_2”

© A. Samarin 2014

BPM and information security: Extra relationships between activities (3)

Activity_A

Activity_B

Carry out the work

Carry out the work Validating the work

Role_1

Role_2


• Doing the work

– To which ROLES the work can be delegated

– To which ROLES the work can be send for review

• Assuring the work

– other ACTIVITIES to audit (1st, 2nd and 3rd party auditing)

– other ACTIVITIES to evaluate the risk (before the work is started)

– other ACTIVITIES to evaluate the risk (after the work is completed)

• Validating the work

– Other ACTIVITIES to check the output (errors and fraud prevention)

• Some ACTIVITIES must be carried out by the same actor, some ACTIVITIES must not

© A. Samarin 2014

BPM and information security: Extra relationships between activities (4)




– BPM and SOA





– Patterns



© A. Samarin 2014

Agenda


Platform-based architecture (1)

• Business concern: How to deliver many similar applications for various highly-diverse clients; define everything up-front is not possible (typical BPM or ECM project)

• Logic

– Developing individual applications will bring a lot of duplications

– The provisioning of solutions should be carried out incrementally with the pace of the target client

– Consider a platform

1. must standardise and simplify core elements of future enterprise-wide system

2. for any elements outside the platform, new opportunities should be explored using agile principles


• Principles

– The platform frees up resource to focus on new opportunities

– Successful agile innovations are rapidly scaled up when incorporated into the platform

– An agile approach requires coordination at a system level

– To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives

– Existing elements of the platform also need periodic challenge

© A. Samarin 2014

Platform-based architecture (2)

A2A1

A3Platform

S2…S

1S3

Functionality

Delivery by solutions Delivery by applications

Scope


• There are two primary types of activity.

– On-going and centralised platform evolution

– Rapid implementation of solutions as mini-projects

• Platform evolution is carried out by an inter-organisational-units coordination committee

• The roles within mini-projects

– A stakeholder

– The team lead for administrative coordination

– The product owner for functional coordination

– The solution architect for technical coordination

– The team member

© A. Samarin 2014

Overall platform governance




– BPM and SOA





– Patterns



© A. Samarin 2014

Agenda


Advantages of the corporate ECM platform

Dev env 1 Dev env 2

Development environment 3Generic web-

development platforms

DEVELOPMENT

Functionality

Basic features of a common ECM platform

Advanced features of a common ECM platform

Company-specific features

Process-centric integration

• Current development cost & time for a collaborative application

– Cost: 40 – 200 K $

– Time: 0,5 – 2 years

• Corporate platform program cost & time

– Cost: 600 K $

– Time: 1 year

• Expected development cost & time for a collaborative application within the corporate platform

– Cost: 20 - 60 K $

– Time: 1 - 3 months


Financial estimations

N apps.

$$

N≈8

Without common platform

With common platform


Solutions vs components




– BPM and SOA





– Patterns



© A. Samarin 2014

Agenda


• The users told us that their processes are unique thus they need different applications

• We modelled their processes with the same modelling procedure

• We found the same services and very similar processes

© A. Samarin 2014

Example – replacing 23 electronic publishing applications




– BPM and SOA





– Process Patterns



© A. Samarin 2014

Agenda


• In the context of enterprise functioning, business activities must be coordinated

• Various coordination techniques– template-based– state-based – event-based– role-based – rule-based or decision-based or intelligence-based – managerial (tacit knowledge)– community-based– instance-based or inter-process– resource-based or life-cycle-based– goal-based

© A. Samarin 2014

Enterprise as a system of processes (1)


• Various coordination techniques

– decomposition cascade

– assembling cascade

– combine cascade

© A. Samarin 2014


http://2.bp.blogspot.com/-TQTdWWMQ7oQ/Ux2_2yrV0iI/AAAAAAAABnI/4T1UqaBo6xI/s1600/download.jpg

http://2.bp.blogspot.com/-teI2n23w62k/Ux2_2-KGbmI/AAAAAAAABnE/MVewY3CXtpw/s1600/images+(1).jpg

http://1.bp.blogspot.com/-0GXK39F1Dj8/Ux2_2zDakoI/AAAAAAAABnY/PXrScFYmT1g/s1600/images-1.jpg


• Coordination maybe strong (e.g. as in the army) or weak (e.g. as in an amateurs football team)

• Coordination maybe implicit or explicit

• Coordination maybe declarative (laws) and imperative (orders)

• Based on coordination, let us think about “levels of cohesion” between activities and thus find out coordination constructs (in addition to activities)

1. process patterns (coordination within processes)

2. processes

3. cluster of processes (coordination between processes)

4. system of processes (coordination between clusters of processes)

© A. Samarin 2014



• Business case: typical “claim processing” process – claim, repair, control, invoicing, and assurance to pay

© A. Samarin 2014

Process fragments – patterns

SI

PAR

SI

IPS

Click for animation

• Business concern: Interactions between two independent parties – public administration and partner (citizen, local business, etc.)

• Logic

– partner submits some documents (including forms) to administration

– administration checks those documents

– administration may request partner to provide more documents or to carry out some corrections

– administration checks those documents again

– and so on


Process pattern:Submission Interface (SI)


SI animated diagram

Click for animation


• Simple event-based (which looks like a state machine)

© A. Samarin 2014

Coordination between processes (1)


Coordination between processes (2)

1. state-machine

2. synchronous invocation

3. asynchronous invocation

4. fire and forget

5. parallel processes

6. co-processes (pattern SI)


• CLOPs are usually functional processes which are implemented a particular business function, e.g. Field Services

• And a “halo” of extra processes

1. monitoring

2. operating

3. governance

© A. Samarin 2014

CLuster Of Processes (CLOP)


Enabler group, supporting group and customer group of clusters


Is a system of processes like a PCB?


Implicit coordination between CLOPs (1)






Functional view at a system of processes (1)








– BPM and SOA





– Patterns



© A. Samarin 2014

Agenda


• Many process patterns are available from my bookwww.samarin.biz/book

• And from my blog http://improving-bpm-systems.blogspot.com/search/label/practical%20process%20patterns

© A. Samarin 2014

Process patterns

http://www.samarin.biz/book

http://improving-bpm-systems.blogspot.com/search/label/practical%20process%20patterns







– BPM and SOA








© A. Samarin 2014

Agenda


• Situation

– a company (3rd world-wide biggest in its sector) has about 800 semi-independent business units (BU); 130+ ERPs; 5 000 apps

– the strategy of the company has two contradictory objectives 1) “Make the diversity efficient” and 2) “Standardize wherever it bring value”

– several company-wide IT initiatives to bring standard solutions to all BUs have failed

– as all BUs have different level of computerization, a standard solution from the IT department is not good for everyone

© A. Samarin 2014

Anisotropic enterprise and shared services (1)

BU1 BU2 BU3 Standardsolution

Level of computerization


Anisotropic enterprise and shared services (2)

BU1 BU2 BU3

Level of computerization

A CBB BAC

1) Standardsolution is based on processes and shared services

2) Each BU is moving to platform-based architecture




– BPM and SOA








© A. Samarin 2014

Agenda


• From disparate IT applications to a business execution platform which will “liberate” people for business innovations

• Agile (with the pace of business) provisioning of solutions

• Step-by-step technical transformation in two interrelated and intermixed streams:

1. Disassemble into services

2. Assemble via processes

• Business evolution to drive technical transformation

• Combine various tactics: assemble, rent, buy, build, outsource, centralised vs. kept locally, standardised, re-engineered or automated

© A. Samarin 2014

Legacy application architecture modernisation


• Business processes make richer functionality from smaller functions (like an orchestra)

• Who (roles) is doing What (business objects), When (coordination of activities), Why (business rules), How (business activities) and with Which Results (performance indicators)

© A. Samarin 2014

Assemble via processes


Disassemble a legacy application into services

Monolithic application

GUI screen 2

GUI screen 1

GUI screen 3

Business logic

Business object “Partner”

persistence

Business object “Competition”

persistence

Business object “Event”

persistence

BPM/SOA modular solution

Business logic service

Interactive service 1



Coordination service

Business object “Partner” persistence

service

Business object “Competition”

persistence service

Business object “Event” persistence

service


Disassemble a legacy ERP into services

Legacy ERP functionality

DM service B

DM service A

DM service C

Industrial ECMIndustrial ERP

HR

Fin

Procurement

Business logic suite (BRM)

Coordination suite (BPM)

Specific service 1

Specific service 2

Specific service 3

In-house development

10-15 % 10-15 %20-40 %10-20 %

Industrial generic suites Industrial specific tools

Event management

…

20-30 %

Note: Specified values are just estimations




– BPM and SOA








© A. Samarin 2014

Agenda


• Majority of the governmental entities (federal, provincial/cantonal, regional/district, communal) provide the same governmental services but via slightly different processes, by various tools and with different results

• We, the people, are paying many times for the “same”

• How to implement this “same”:

– not 100+ times (with different quality)

– but 1 time (with superior quality) via cooperation among 100+ contributors?

© A. Samarin 2014

E-government and e-governance


Four communication patterns for exchanges between a partner and the

government

Government

2. Patrner-declaration

1. Government-announce

4. Partner-demand

Spread in time

3. Government-demand

Spread in time

Partners (citizen, business, and other organisations)

1. Government-announcement, e.g. broadcasting changes in a law2. Partner-declaration, e.g. communicating a change of the partner’s address3. Government-demand, e.g. inviting to pay taxes4. Partner-demand, e.g. requesting a certificate (fishing license)

© A. Samarin 2014


A partner-initiated-demand may required several exchanges between the

partner and the government

Government

Time© A. Samarin 2014

1 2 3 4


The partner may need to deal with some ministries

Government

Ministry A Ministry B Ministry C

Time

Methodologies:+ data modelling+ electronic document exchange

Tools:+ standard data schemas+ electronic signature

• data flow (black dashed lines)

© A. Samarin 2014


Process

+ + + +

E-gov coordinates partner’s interactions with the government

Government

• control flow (black solid lines)



Time

1 2 3 4

Methodologies:• data modelling• electronic document

(ED) exchange+ BPM discipline+ process modelling

Technologies:• standard data schemas• electronic signature+ BPM suite

1

2 3

4

5

6

7

8

© A. Samarin 2014


Process --

E-gov unifies the communication between the partner and the ministries

Government

Ministry B

Time

1

2

3

45

2

2a 2cx

2b



Methodologies:• data modelling• electronic document

(ED) exchange+ BPM discipline+ process modelling

Technologies:• standard data schemas• electronic signature+ BPM suite

© A. Samarin 2014

… …


Process

+ + + +

E-gov provides a social collaborative extranet for partners

Government


Time

Methodologies:• data modelling• ED exchange• BPM discipline• process modelling+ ED management+ records management+ collaboration+ social

Technologies:• standard data schemas• electronic signature• BPM suite+ ECM

Social collaborative extranet



© A. Samarin 2014


Partner’s view

© A. Samarin 2014


Partners

Existing application

Coordination and integration backbone

e-Government


E-gov application architecture view


e-gov service



Government

Technologies:• BPM suite• SOA orientation• ECM

e-gov service

e-gov service


Partners



E-gov traditional application architecture

Portal



Government

Appl

icati

on

Appl

icati

on

Appl

icati

on


Partners



e-Government


E-gov introductory application architecture


e-gov service



Government

e-gov service

e-gov service


Partners



e-Government


E-gov transitional application architecture


e-gov service


Government

e-gov service

e-gov service

Coordination backbone

Service Service



Partners


e-Government


E-gov target application architecture


e-gov service

e-gov service

e-gov service

ServiceService Service


Partners


E-social system


E-social system application architecture


Public service

Private service

Professionalservice

Social service

Voluntary service


Steps of evolution in application architecture

Introductory architecture

Target architecture

E-Social system architecture

Portal-centric architecture

Transitional architecture




– BPM and SOA








© A. Samarin 2014

Agenda


NEEDS

RESULTS

Enrich Knowledge

Improve Operations

acquisition channels for external data/information/ knowledge

disseminationchannels of internal data/information/ knowledge

Methods, practices, laws, international regulations, etc.

Knowledge for Healthcare

Processes & Services

… … …

DiagnosticPreliminary

analysis Treatment Recovery

PartnerPartnerPartnerPartnerPartners

Coordination

© A. Samarin 2014

Healthcare reference model (1)


Healthcare Platform

acquisition channels

disseminationchannels

Specialised Apps.

Specialised Apps.

Specialised Apps.

Web access

Mobile access

PatientCRM

Web acces

s

Mobile access

DoctorCRM

Access

EDI

Enrichment

RBACKnowledge Mgmt. Procedures

BPMECM

StorageECM

Coordination

BPMsBI

PartnerPartnerPartnerPartnerPartners

Healthcare reference model ()

© A. Samarin 2014


Healthcare reference model (3)Modern Healthcare System (MHS)

Hospitals Clinics

MHS

Virtual Doctor’s Offices

MHS

MHS

MHS

Insurance Social

PatientsMHS WEB & Cloud

MHS

Labs

© A. Samarin 2014




– BPM and SOA








© A. Samarin 2014

Agenda


• Combining some patterns from other patterns

© A. Samarin 2014

Strategy Implementation Chain (SIC)


• Unfortunately, IT and IS are internally-focused areas of human activities

• Unfortunately, in other departments, abstract and conceptual thinking is very rare (no skills, no time)

• Fortunately, EA is more than IT and IS

• EA is capable to break this situation and bring systems thinking at the enterprise level

• EA is considering an organisation as a whole and what composition of parts (business capabilities) would best position the organisation to achieve its goals

© A. Samarin 2014

Conclusions


• QUESTIONS?

• 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

Thanks

© A. Samarin 2014

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


• “Enterprise genotype” (a full nomenclature of enterprise artefacts) – classic EA

• “Enterprise phenotype” (a set of observable characteristics such as performance)

• Formal link between them via “enterprise executable model” – EA enhanced by BPM and SOA

© A. Samarin 2014 106

Enterprise executable model


• Capturing artefacts and relationships is not sufficient – actionable models are necessary

– all artefacts are versionable throughout their life-cycle

– all artefacts are evolved to become digital, externalised, virtual and components of clouds

– all relationships between these artefacts are modelled explicitly

– all models are made to be executable

• Since many models are designed for people, these models should not be very formal

• Enable changes at the pace of the business

© A. Samarin 2014 107

Main architecting principles


• Reveal all hidden relationships and structure them – examples:

– static (in design phase)

– dynamic (in execution phase)

– composition (from atomic artefacts to a composite artefact)

– instantiation (from a template to instances)

– compatibility (between different versions)

• If possible, model relationships as formal, explicit, traceable, testable, secure, SLA aware and executable

© A. Samarin 2014

Relationships between artefacts


Different deployment ZONEs

© A. Samarin 2014

HQ

VIOLET ZONE - outside enterprise and service-provider-managed public cloud

GREEN ZONE - outside enterprise and enterprise-managed private cloudYELLOW

GOLD

GOLD ZONE - classic within enterprise computingORANGE ZONE - within enterprise private cloud

BLUE ZONE - outside enterprise and service-provider-managed private cloud


Profiling services - example


Decision taking - example

Technology

How EA, BPM, SOA and ECM work together