Business Management Enterprise Architecture (EA) Presentations Process Analysis Process Management Service Oriented Architecture (SOA)

How EA, BPM, SOA and ECM work together

Description

for the BPM mini-conference
https://www.dataforeningen.no/program.316567.no.html

Transcript

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 Architecture
BPM – Business Process Management
SOA – Service Oriented Architecture
ECM – Enterprise Content Management
• 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
Architecting synergy v2 2
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 Architecting synergy v2 3
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 Architecting synergy v2 4
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 Architecting synergy v2 5
Business reality
• Different estimations of the development/maintenance
life-cycle cost ratio
© A. Samarin 2014 Architecting synergy v2 6
Solutions need to be adaptive
2 – Estimated average in the IT
industry
maintenance
development 80 %
20 %
2
40 %
60 %
1
95 %
5 %
3
3 – 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
© A. Samarin 2014 Architecting synergy v2 7
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 Architecting synergy v2 8
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 Architecting synergy v2 9
EA as a systemic coordinator
• 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 Architecting synergy v2 10
Agenda
© A. Samarin 2014 Architecting synergy v2 11
BPM is a tool for improving enterprise
business performance
The theory
BPM as a discipline
(use processes to
manage an
enterprise)
The tools
BPM as software:
BPM suite (BPMS)
The practice
Any 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 Architecting synergy v2 13
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 Architecting synergy v2 14
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
Architecting synergy v2 15
Process templates and instances
Templates
and their
versions
Instances
© A. Samarin 2014
© A. Samarin 2014 Architecting synergy v2 16
Variant 1 – classic (one template is used
for many instances)
© A. Samarin 2014 Architecting synergy v2 17
Variant 2 – tailoring (a template is
adjusted for each instance)
© A. Samarin 2014 Architecting synergy v2 18
Variant 3 – reactive (no initial template
and next activity is selected based on
the current situation)
© A. Samarin 2014 Architecting synergy v2 19
Variant 4 – proactive planning (similar
to variant 3, but a few next activities
[fragment] are executed together)
© A. Samarin 2014 Architecting synergy v2 20
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
Architecting synergy v2 21
BPM reference model:
Improvement loop
1
2
3
4
© A. Samarin 2014
Architecting synergy v2 22
BPM reference model:
Process-based disciplines
© A. Samarin 2014
Architecting synergy v2 23
BPM reference model:
Process-oriented view of an enterprise
(before BPM)
© A. Samarin 2014
Architecting synergy v2 24
BPM reference model:
Process-oriented view of an enterprise
(with BPM)
© A. Samarin 2014
© A. Samarin 2014 Architecting synergy v2 25
BPM reference model:
BPM suite components
© A. Samarin 2014 Architecting synergy v2 26
BPM reference model:
BPM suite components (extended list)
• 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 Architecting synergy v2 27
Agenda
• Events
• Roles
• Data structures
• Documents
• Rules
• Audit trails
• KPIs
• Processes
• Services
© A. Samarin 2014 Architecting synergy v2 28
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 Architecting synergy v2 29
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
Architecting synergy v2 30
Services
© A. Samarin 2014
• Definition
– architectural approach for constructing
software-intensive systems from a set
of universally interconnected and
interdependent services
• Advantages
– use of standard and pre-fabricated
building blocks
– high level of system flexibility
– reducing complexity
– building bigger services from smaller ones
Architecting synergy v2 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
© A. Samarin 2014 Architecting synergy v2 32
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 services
in its implementation
© A. Samarin 2014 Architecting synergy v2 33
Synergy between BPM and SOA (2) –
structuring relationships
• 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
© A. Samarin 2014 Architecting synergy v2 34
Synergy between BPM and SOA (3) –
structuring relationships
service process
© A. Samarin 2014 Architecting synergy v2 35
Synergy between BPM and SOA (4) –
Implementation layers of artefacts
© A. Samarin 2014 Architecting synergy v2 36
Synergy between BPM and SOA (5) –
Relationship with other technologies
© A. Samarin 2014 Architecting synergy v2 37
Synergy between BPM and SOA (6) –
no applications – just coordination of
services
• 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 Architecting synergy v2 38
Agenda
• Align access rights with the work to be done
© A. Samarin 2014 Architecting synergy v2 39
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
© A. Samarin 2014 Architecting synergy v2 40
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 Architecting synergy v2 41
• 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 Architecting synergy v2 42
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 Architecting synergy v2 43
BPM and information security:
Extra relationships between activities (4)
• 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 Architecting synergy v2 44
Agenda
© A. Samarin 2014 Architecting synergy v2 45
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 Architecting synergy v2 46
Platform-based architecture (2)
A2
A1
A3
Platform
S2
…S
1
S3
Functionality
Delivery by solutionsDelivery 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 Architecting synergy v2 47
Overall platform governance
• 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 Architecting synergy v2 48
Agenda
© A. Samarin 2014 Architecting synergy v2 49
Advantages of the corporate
ECM platform
Dev env 1 Dev env 2
Development
environment 3Generic web-
development platforms
D
E
V
E
L
O
P
M
E
N
T
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
© A. Samarin 2014 Architecting synergy v2 50
Financial estimations
N apps.
$$
N≈8
Without
common
platform
With
common
platform
© A. Samarin 2014 Architecting synergy v2 51
Solutions vs components
• 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 Architecting synergy v2 52
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 Architecting synergy v2 53
Example – replacing 23 electronic
publishing applications
• 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
– Process Patterns
• Combined examples
– Shared services, legacy application architecture, e-gov,
healthcare, SIC
© A. Samarin 2014 Architecting synergy v2 54
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 Architecting synergy v2 55
Enterprise as a system of processes (1)
• Various coordination techniques
– decomposition cascade
– assembling cascade
– combine cascade
© A. Samarin 2014 Architecting synergy v2 56
Enterprise as a system of processes (2)
• 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 Architecting synergy v2 57
Enterprise as a system of processes (3)
• Business case: typical “claim processing” process – claim,
repair, control, invoicing, and assurance to pay
© A. Samarin 2014 Architecting synergy v2 58
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
© A. Samarin 2014 Architecting synergy v2 59
Process pattern:
Submission Interface (SI)
© A. Samarin 2014 Architecting synergy v2 60
SI animated diagram
Click for
animation
• Simple event-based (which looks like a state machine)
© A. Samarin 2014 Architecting synergy v2 61
Coordination between processes (1)
© A. Samarin 2014 Architecting synergy v2 62
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 Architecting synergy v2 63
CLuster Of Processes (CLOP)
© A. Samarin 2014 Architecting synergy v2 64
Enabler group, supporting group and
customer group of clusters
© A. Samarin 2014 Architecting synergy v2 65
Is a system of processes like a PCB?
© A. Samarin 2014 Architecting synergy v2 66
Implicit coordination between CLOPs (1)
© A. Samarin 2014 Architecting synergy v2 67
Implicit coordination between CLOPs (2)
© A. Samarin 2014 Architecting synergy v2 68
Implicit coordination between CLOPs (3)
© A. Samarin 2014 Architecting synergy v2 69
Functional view at a system of processes (1)
© A. Samarin 2014 Architecting synergy v2 70
Functional view at a system of processes (2)
© A. Samarin 2014 Architecting synergy v2 71
Functional view at a system of processes (3)
• 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 Architecting synergy v2 72
Agenda
• Many process patterns are available from my book
www.samarin.biz/book
• And from my blog
http://improving-bpm-
systems.blogspot.com/search/label/practical%20process
%20patterns
© A. Samarin 2014 Architecting synergy v2 73
Process patterns
• 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
– Process Patterns
• Combined examples
– Shared services, legacy application architecture, e-gov,
healthcare, SIC
© A. Samarin 2014 Architecting synergy v2 74
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 Architecting synergy v2 75
Anisotropic enterprise and shared
services (1)
BU1 BU2 BU3 Standard
solution
Level of
computerization
© A. Samarin 2014 Architecting synergy v2 76
Anisotropic enterprise and shared
services (2)
BU1 BU2 BU3
Level of
computerization
A CBB BAC
1) Standard
solution is based
on processes and
shared services
2) Each BU is
moving to
platform-based
architecture
• 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
– Process Patterns
• Combined examples
– Shared services, legacy application architecture, e-gov,
healthcare, SIC
© A. Samarin 2014 Architecting synergy v2 77
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 Architecting synergy v2 78
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 Architecting synergy v2 79
Assemble via processes
© A. Samarin 2014 Architecting synergy v2 80
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
Interactive
service 2
Interactive
service 3
Coordination service
Business object
“Partner” persistence
service
Business object
“Competition”
persistence service
Business object
“Event” persistence
service
© A. Samarin 2014 Architecting synergy v2 81
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
• 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
– Process Patterns
• Combined examples
– Shared services, legacy application architecture, e-gov,
healthcare, SIC
© A. Samarin 2014 Architecting synergy v2 82
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 Architecting synergy v2 83
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 law
2. Partner-declaration, e.g. communicating a change of the partner’s address
3. Government-demand, e.g. inviting to pay taxes
4. Partner-demand, e.g. requesting a certificate (fishing license)
© A. Samarin 2014 Architecting synergy v2 84
A partner-initiated-demand may
required several exchanges between the
partner and the government
Government
Time
© A. Samarin 2014 Architecting synergy v2 85
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 Architecting synergy v2 86
Process
+ + + +
E-gov coordinates partner’s interactions
with the government
Government
• control flow (black solid
lines)
• data flow (black dashed
lines)
Ministry A Ministry B Ministry C
Time
Methodologies:
• data modelling
• electronic document
(ED) exchange
+ BPM discipline
+ process modelling
Technologies:
• standard data schemas
• electronic signature
+ BPM suite
© A. Samarin 2014 Architecting synergy v2 87
Process —
E-gov unifies the communication
between the partner and the ministries
Government
Ministry B
Time
2a 2cx
2b
• control flow (black solid
lines)
• data flow (black dashed
lines)
Methodologies:
• data modelling
• electronic document
(ED) exchange
+ BPM discipline
+ process modelling
Technologies:
• standard data schemas
• electronic signature
+ BPM suite
© A. Samarin 2014 Architecting synergy v2 88
… …
Process
+ + + +
E-gov provides a social collaborative
extranet for partners
Government
Ministry A Ministry B Ministry C
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
• control flow (black solid
lines)
• data flow (black dashed
lines)
© A. Samarin 2014 Architecting synergy v2 89
Partner’s view
© A. Samarin 2014 Architecting synergy v2 90
Partners
Existing
application
Coordination and integration backbone
e-Government
© A. Samarin 2014 91
E-gov application architecture view
Social collaborative extranet
e-gov
service
Existing
application
Existing
application
Government
Technologies:
• BPM suite
• SOA orientation
• ECM
e-gov
service
e-gov
service
Architecting synergy v2
Partners
Existing
application
© A. Samarin 2014 92
E-gov traditional application architecture
Portal
Existing
application
Existing
application
Government
Application
Application
Application
Architecting synergy v2
Partners
Existing
application
Coordination and integration backbone
e-Government
© A. Samarin 2014 93
E-gov introductory application
architecture
Social collaborative extranet
e-gov
service
Existing
application
Existing
application
Government
e-gov
service
e-gov
service
Architecting synergy v2
Partners
Existing
application
Coordination and integration backbone
e-Government
© A. Samarin 2014 94
E-gov transitional application
architecture
Social collaborative extranet
e-gov
service
Existing
application
Government
e-gov
service
e-gov
service
Coordination backbone
Service Service
Architecting synergy v2
Existing
application
Partners
Coordination and integration backbone
e-Government
© A. Samarin 2014 95
E-gov target application architecture
Social collaborative extranet
e-gov
service
e-gov
service
e-gov
service
ServiceService Service
Architecting synergy v2
Partners
Coordination and integration backbone
E-social system
© A. Samarin 2014 96
E-social system application architecture
Social collaborative extranet
Public
service
Private
service
Professional
service
Social
service
Voluntary
service
Architecting synergy v2
© A. Samarin 2014 Architecting synergy v2 97
Steps of evolution in application
architecture
Introductory
architecture
Target
architecture
E-Social system
architecture
Portal-centric
architecture
Transitional
architecture
• 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
– Process Patterns
• Combined examples
– Shared services, legacy application architecture, e-gov,
healthcare, SIC
© A. Samarin 2014 Architecting synergy v2 98
Agenda
N
E
E
D
S
R
E
S
U
L
T
S
Enrich
Knowledge
Improve
Operations
acquisition
channels for
external data/
information/
knowledge
dissemination
channels of
internal data/
information/
knowledge
Methods, practices, laws, international regulations, etc.
Knowledge for Healthcare
Processes & Services
… … …
Diagnostic
Preliminary
analysis
Treatment Recovery
PartnerPartnerPartnerPartnerPartners
Coordination
© A. Samarin 2014 Architecting synergy v2 99
Healthcare reference model (1)
Healthcare Platform
acquisition
channels
dissemination
channels
Specialised
Apps.
Specialised
Apps.
Specialised
Apps.
Web
access
Mobile
access
Patient
CRM
Web
access
Mobile
access
Doctor
CRM
Access
EDI
Enrichment
RBAC
Knowledge Mgmt. Procedures
BPMECM
Storage
ECM
Coordination
BPMsBI
PartnerPartnerPartnerPartnerPartners
Healthcare reference model ()
© A. Samarin 2014 Architecting synergy v2 100
Healthcare reference model (3)
Modern Healthcare System (MHS)
Hospitals
Clinics
MHS
Virtual Doctor’s
Offices
MHS
MHS
MHS
Insurance
Social
Patients
MHS WEB
& Cloud
MHS
Labs
© A. Samarin 2014 Architecting synergy v2 101
• 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
– Process Patterns
• Combined examples
– Shared services, legacy application architecture, e-gov,
healthcare, SIC
© A. Samarin 2014 Architecting synergy v2 102
Agenda
• Combining some patterns from other patterns
© A. Samarin 2014 Architecting synergy v2 103
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 Architecting synergy v2 104
Conclusions
• QUESTIONS?
• Personal website: http://www.samarin.biz
• Blog http://improving-bpm-systems.blogspot.com
• LinkedIn: http://www.linkedin.com/in/alexandersamarin
• E-mail: alexandre.samarine@gmail.com
• Twitter: @samarin
• Mobile: +41 76 573 40 61
• Book: www.samarin.biz/book
Architecting synergy v2 105
Thanks
© A. Samarin 2014
• “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 Architecting synergy v2 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 Architecting synergy v2 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 Architecting synergy v2 108
Relationships between artefacts
Different deployment ZONEs
© A. Samarin 2014 Architecting synergy v2 109
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
computing
ORANGE ZONE – within
enterprise private cloud
BLUE ZONE –
outside enterprise
and service-
provider-managed
private cloud
© A. Samarin 2014 Architecting synergy v2 110
Profiling services – example
© A. Samarin 2014 Architecting synergy v2 111
Decision taking – example

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="https://www.businessprocessincubator.com/content/how-ea-bpm-soa-and-ecm-work-together/?feed=html" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples

BPMN.org

XPDL.org

×