Alexander SAMARIN, profile picture
Uploaded byAlexander SAMARIN
PPTX, PDF6,126 views

How EA, BPM, SOA and ECM work together

This document discusses how enterprise architecture (EA), business process management (BPM), service-oriented architecture (SOA), and enterprise content management (ECM) work together. It provides an overview of each approach and how they are related. BPM provides context for defining services in SOA. BPM and SOA work together, with processes and services able to replace each other at different levels. ECM and electronic publishing are discussed as examples of platform-based architectures.

Embed presentation

Downloaded 485 times
1 / 111
2 / 111
3 / 111
4 / 111
5 / 111
6 / 111
7 / 111
8 / 111
9 / 111
10 / 111
11 / 111
12 / 111
13 / 111
14 / 111
15 / 111
16 / 111
17 / 111
18 / 111
19 / 111
20 / 111
21 / 111
22 / 111
23 / 111
24 / 111
25 / 111
26 / 111
27 / 111
28 / 111
29 / 111
30 / 111
31 / 111
32 / 111
33 / 111
34 / 111
35 / 111
36 / 111
37 / 111
38 / 111
39 / 111
40 / 111
41 / 111
42 / 111
43 / 111
44 / 111
45 / 111
46 / 111
47 / 111
48 / 111
49 / 111
50 / 111
51 / 111
52 / 111
53 / 111
54 / 111
55 / 111
56 / 111
57 / 111
58 / 111
59 / 111
60 / 111
61 / 111
62 / 111
63 / 111
64 / 111
65 / 111
66 / 111
67 / 111
68 / 111
69 / 111
70 / 111
71 / 111
72 / 111
73 / 111
74 / 111
75 / 111
76 / 111
77 / 111
78 / 111
79 / 111
80 / 111
81 / 111
82 / 111
83 / 111
84 / 111
85 / 111
86 / 111
87 / 111
88 / 111
89 / 111
90 / 111
91 / 111
92 / 111
93 / 111
94 / 111
95 / 111
96 / 111
97 / 111
98 / 111
99 / 111
100 / 111
101 / 111
102 / 111
103 / 111
104 / 111
105 / 111
106 / 111
107 / 111
108 / 111
109 / 111
110 / 111
111 / 111
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

More Related Content

PPT
Achieving synergy between BPM, SOA and EA
byAlexander SAMARIN
 
PPTX
BPM for developers
byAlexander SAMARIN
 
PPTX
Addressing security concerns through BPM
byAlexander SAMARIN
 
PDF
IBM BPM Updates - BPM 8.5.7 and BPM 8.6
byAllen Chan
 
PPT
Examples of BPM + SOA joint work
byAlexander SAMARIN
 
PPTX
Better application architecture with #microservices and #BPM (as APaaS)
byAlexander SAMARIN
 
PPTX
Process Analytics with Oracle BPM Suite 12c and BAM - OGh SIG SOA & BPM, 1st ...
byLucas Jellema
 
PPTX
IBM BPM On Cloud demo Sept 4 2015
byLogan Vadivelu
 
Achieving synergy between BPM, SOA and EA
byAlexander SAMARIN
 
BPM for developers
byAlexander SAMARIN
 
Addressing security concerns through BPM
byAlexander SAMARIN
 
IBM BPM Updates - BPM 8.5.7 and BPM 8.6
byAllen Chan
 
Examples of BPM + SOA joint work
byAlexander SAMARIN
 
Better application architecture with #microservices and #BPM (as APaaS)
byAlexander SAMARIN
 
Process Analytics with Oracle BPM Suite 12c and BAM - OGh SIG SOA & BPM, 1st ...
byLucas Jellema
 
IBM BPM On Cloud demo Sept 4 2015
byLogan Vadivelu
 

What's hot

PPTX
BPM for developers, extended
byAlexander SAMARIN
 
PDF
Aligning BPM and EA
bySandy Kemsley
 
PDF
IBM BPM Overview
bySura Gonzalez
 
PDF
Introduction to Oracle BPM Suite
byRevelation Technologies
 
PPTX
Business Process Management Meets Enterprise 2 0
bySandy Kemsley
 
PDF
IBM Business Process Management
byAsif Hussain
 
PDF
IBM Cloud University 2017-IDPA009-IBM BPM Upgrade and Migration Made Easy
byBrian Petrini
 
PDF
InterConnect 2015 1930 - Top practices to ensure a successful IBM Business Pr...
byBrian Petrini
 
PDF
Business process analysis and design – importance of having a common language...
byAlan McSweeney
 
PDF
Oracle BPM 11g Lesson 1
byRakesh Gujjarlapudi
 
PDF
BPM Benefits
byBrian Petrini
 
PDF
Oracle SOA and BPM
bykumar gaurav
 
PDF
Oracle bpm-suite-11g-overview-slide
byAericon
 
PPT
IBM BPM off prem options
bysflynn073
 
PPSX
Oracle BPM 11G
byVijay Reddy
 
PPT
The Role of Standards in BPM
bySandy Kemsley
 
PDF
Impact 2011 2667 - Developing effective services for use in critical business...
byBrian Petrini
 
PDF
What’s new in IBM BPM 8.5.7 CF2016.06 - CF2017.03
byDennis Parrott
 
PPTX
Ladder of business process practices
byAlexander SAMARIN
 
PDF
Impact 2013 2963 - IBM Business Process Manager Top Practices
byBrian Petrini
 
BPM for developers, extended
byAlexander SAMARIN
 
Aligning BPM and EA
bySandy Kemsley
 
IBM BPM Overview
bySura Gonzalez
 
Introduction to Oracle BPM Suite
byRevelation Technologies
 
Business Process Management Meets Enterprise 2 0
bySandy Kemsley
 
IBM Business Process Management
byAsif Hussain
 
IBM Cloud University 2017-IDPA009-IBM BPM Upgrade and Migration Made Easy
byBrian Petrini
 
InterConnect 2015 1930 - Top practices to ensure a successful IBM Business Pr...
byBrian Petrini
 
Business process analysis and design – importance of having a common language...
byAlan McSweeney
 
Oracle BPM 11g Lesson 1
byRakesh Gujjarlapudi
 
BPM Benefits
byBrian Petrini
 
Oracle SOA and BPM
bykumar gaurav
 
Oracle bpm-suite-11g-overview-slide
byAericon
 
IBM BPM off prem options
bysflynn073
 
Oracle BPM 11G
byVijay Reddy
 
The Role of Standards in BPM
bySandy Kemsley
 
Impact 2011 2667 - Developing effective services for use in critical business...
byBrian Petrini
 
What’s new in IBM BPM 8.5.7 CF2016.06 - CF2017.03
byDennis Parrott
 
Ladder of business process practices
byAlexander SAMARIN
 
Impact 2013 2963 - IBM Business Process Manager Top Practices
byBrian Petrini
 

Viewers also liked

PDF
Webcast: How To Create a Compelling Business Case For Your Product Ideas
byAIPMM Administration
 
PDF
How do you build an innovation culture in your team? – An 8-Step Guide
byPinkesh Shah
 
PPT
Top 5 project management tips for product managers.
byPinkesh Shah
 
PDF
What every Enterprise Architect needs to know about BPM and Workflow
byMichael zur Muehlen
 
PDF
Connecting lean to planning and strategy
byAIPMM Administration
 
PDF
Business case for having Product Managers in India: Hosted by Adaptive Market...
byPinkesh Shah
 
PDF
Process architecture - Part II
byMarcello La Rosa
 
PDF
Understanding Business Process Architecture to Enable Operational Efficiency
byNathaniel Palmer
 
Webcast: How To Create a Compelling Business Case For Your Product Ideas
byAIPMM Administration
 
How do you build an innovation culture in your team? – An 8-Step Guide
byPinkesh Shah
 
Top 5 project management tips for product managers.
byPinkesh Shah
 
What every Enterprise Architect needs to know about BPM and Workflow
byMichael zur Muehlen
 
Connecting lean to planning and strategy
byAIPMM Administration
 
Business case for having Product Managers in India: Hosted by Adaptive Market...
byPinkesh Shah
 
Process architecture - Part II
byMarcello La Rosa
 
Understanding Business Process Architecture to Enable Operational Efficiency
byNathaniel Palmer
 

Similar to How EA, BPM, SOA and ECM work together

PPT
Architecting enterprise BPM systems for optimal agility
byAlexander SAMARIN
 
PPT
Architecting Enterprise BPM Systems for Optimal Agility
byNathaniel Palmer
 
PDF
BPM BA
byLeonardo Arguedas Rodríguez
 
PPT
Creating synergy between BPM and EA in an e-government environment
byAlexander SAMARIN
 
PPTX
BA World Presentation - Melb June 2011
byioctanegroup
 
PDF
Mohan k. bavirisetty introduction to semantic soa & bpm sept 14 2010 v 1.0
byDr. Mohan K. Bavirisetty
 
PPTX
Business solution delivery capability v4.0
byEtienne Venter
 
PPSX
Aligning The Business Model to Technology Landscapes Enterprise Systems Arch...
byDaljit Banger
 
PPTX
ECM BPM Strategy With Enterprise Architecture Maturity Model
byDavid Champeau
 
PDF
Strategic Portfolio Management for IT
byiasaglobal
 
PPT
Costandopportunitycostofarchitecturalinitiatives 090311132631-phpapp01
byTim Vibbert
 
PPTX
Architecting modern informaiton systems M3 application architecture
byAlexander SAMARIN
 
PPT
Business/IT alignment engineering
byYves Pigneur
 
PDF
Iasa Five Pillars Presentation
byiasaglobal
 
PPTX
Iasa5 pillars
byDamaris Bode
 
PDF
20090901 London Enterprise Session V3 Colour
byRogerBurlton
 
PDF
MBIT Graduate Project Presentation
byDimitris Kosmidis
 
PPT
From agile development to agile evolution of enterprise systems
byAlexander SAMARIN
 
PDF
Maximizing EA Impact: Using Business Architecture to Achieve Alignment
byDavid Baker
 
PPTX
Next Generation Enterprise Architecture
byRichard Veryard
 
Architecting enterprise BPM systems for optimal agility
byAlexander SAMARIN
 
Architecting Enterprise BPM Systems for Optimal Agility
byNathaniel Palmer
 
BPM BA
byLeonardo Arguedas Rodríguez
 
Creating synergy between BPM and EA in an e-government environment
byAlexander SAMARIN
 
BA World Presentation - Melb June 2011
byioctanegroup
 
Mohan k. bavirisetty introduction to semantic soa & bpm sept 14 2010 v 1.0
byDr. Mohan K. Bavirisetty
 
Business solution delivery capability v4.0
byEtienne Venter
 
Aligning The Business Model to Technology Landscapes Enterprise Systems Arch...
byDaljit Banger
 
ECM BPM Strategy With Enterprise Architecture Maturity Model
byDavid Champeau
 
Strategic Portfolio Management for IT
byiasaglobal
 
Costandopportunitycostofarchitecturalinitiatives 090311132631-phpapp01
byTim Vibbert
 
Architecting modern informaiton systems M3 application architecture
byAlexander SAMARIN
 
Business/IT alignment engineering
byYves Pigneur
 
Iasa Five Pillars Presentation
byiasaglobal
 
Iasa5 pillars
byDamaris Bode
 
20090901 London Enterprise Session V3 Colour
byRogerBurlton
 
MBIT Graduate Project Presentation
byDimitris Kosmidis
 
From agile development to agile evolution of enterprise systems
byAlexander SAMARIN
 
Maximizing EA Impact: Using Business Architecture to Achieve Alignment
byDavid Baker
 
Next Generation Enterprise Architecture
byRichard Veryard
 

More from Alexander SAMARIN

PPTX
Digital Architecture Methodology for Systemic Digital Transformation (Smart C...
byAlexander SAMARIN
 
PPTX
Building large-scale digital repeatable systems
byAlexander SAMARIN
 
PPTX
Smart Cities Reference Architecture
byAlexander SAMARIN
 
PPTX
Building large-scale digital repeatable systems e.g Smart Cities
byAlexander SAMARIN
 
PPTX
Mini-course at VFU - Architecting modern digital systems - 0
byAlexander SAMARIN
 
PPTX
Mini-course at VFU - Architecting modern digital systems - 5
byAlexander SAMARIN
 
PPTX
Mini-course at VFU - Architecting modern digital systems - 4
byAlexander SAMARIN
 
PPTX
Mini-course at VFU - Architecting modern digital systems - 3
byAlexander SAMARIN
 
PPTX
Mini-course at VFU - Architecting modern digital systems - 2
byAlexander SAMARIN
 
PPTX
Mini-course at VFU - Architecting modern digital systems - 1
byAlexander SAMARIN
 
PPTX
Towards software-defined organisations
byAlexander SAMARIN
 
PPTX
Smart Cities from the systems point of view
byAlexander SAMARIN
 
PPTX
Systems architecting experience
byAlexander SAMARIN
 
PPTX
Enterprise Architecture (#EntArch) as a #systemsapproach applied management d...
byAlexander SAMARIN
 
PPTX
#bizarch from the #entarch point of view
byAlexander SAMARIN
 
PPTX
Help #SME becoming #digital
byAlexander SAMARIN
 
PPTX
Architecting digital transformation v1
byAlexander SAMARIN
 
PPTX
Incremental transformation to #digital (explicit and executable) processes
byAlexander SAMARIN
 
PDF
Technology-enabled healthcare transformation: concept paper
byAlexander SAMARIN
 
PPTX
BPM for SOA+ESB+API and cloud
byAlexander SAMARIN
 
Digital Architecture Methodology for Systemic Digital Transformation (Smart C...
byAlexander SAMARIN
 
Building large-scale digital repeatable systems
byAlexander SAMARIN
 
Smart Cities Reference Architecture
byAlexander SAMARIN
 
Building large-scale digital repeatable systems e.g Smart Cities
byAlexander SAMARIN
 
Mini-course at VFU - Architecting modern digital systems - 0
byAlexander SAMARIN
 
Mini-course at VFU - Architecting modern digital systems - 5
byAlexander SAMARIN
 
Mini-course at VFU - Architecting modern digital systems - 4
byAlexander SAMARIN
 
Mini-course at VFU - Architecting modern digital systems - 3
byAlexander SAMARIN
 
Mini-course at VFU - Architecting modern digital systems - 2
byAlexander SAMARIN
 
Mini-course at VFU - Architecting modern digital systems - 1
byAlexander SAMARIN
 
Towards software-defined organisations
byAlexander SAMARIN
 
Smart Cities from the systems point of view
byAlexander SAMARIN
 
Systems architecting experience
byAlexander SAMARIN
 
Enterprise Architecture (#EntArch) as a #systemsapproach applied management d...
byAlexander SAMARIN
 
#bizarch from the #entarch point of view
byAlexander SAMARIN
 
Help #SME becoming #digital
byAlexander SAMARIN
 
Architecting digital transformation v1
byAlexander SAMARIN
 
Incremental transformation to #digital (explicit and executable) processes
byAlexander SAMARIN
 
Technology-enabled healthcare transformation: concept paper
byAlexander SAMARIN
 
BPM for SOA+ESB+API and cloud
byAlexander SAMARIN
 

Recently uploaded

PDF
Oracle Cloud Infrastructure 2025 Architect Professional (1Z0-1127-25) Master ...
byExamCert App
 
PDF
The new book “Marketing in the Metaverse” spotlights Scott M. Graffius’ research
byScott M. Graffius
 
PPTX
Automation Without Apprentices: How AI Challenges the Open Source Way
byIcinga
 
PDF
GenerationAI Paris 2025 | How Agentic AI is Reinventing Organizations
byapidays
 
PDF
Spec-Driven Development with Kiro: Elevating Software Quality, Traceability, ...
byHaim Michael
 
PDF
Constraint Collapse and Fidelity Decay in Scaled Language Models
bySemantic Fidelity Lab | A. Jacobs
 
PDF
GTM-and-Sales-Plan for a cyber security product
byAshish Jangir
 
PDF
20260212 Security-JAWS activity results for 2025 and activity goals for 2026
byTyphon 666
 
PDF
Session 1/5: Enhancing Automation with Screenplay & Business Rules
bysuhanisingh58689
 
PDF
Poročilo odbora CIS (CH08873) za leto 2025 na letni skupščini IEEE Slovenija ...
byUniversity of Maribor
 
PDF
TrustArc Webinar - From Trends to Action: Fitting AI Governance into Privacy Ops
byTrustArc
 
PDF
Founder & Tech Lead | Web Development & Digital Growth Consultant | Helping B...
byShyamal Das
 
PPTX
TravelTech Paris 2025 | Beyond the pipes: Why Channel Management isn’t really...
byapidays
 
PDF
Transcript: Escape from the Forbidden Zone: Smuggling green and inclusive tec...
byBookNet Canada
 
PDF
Traditional-Security-Models-No-Longer-Work.pptx (1).pdf
byOhhproJunction
 
PDF
GDG Cloud Southlake #49: Pradeep R Kumar: Implications of Agentic AI for Iden...
byJames Anderson
 
PDF
UiPath Automation Developer Associate Training Series 2026 - Session 3
byDianaGray10
 
PDF
Automated Governance for FME Flow: Smarter Admin at Scale
bySafe Software
 
PDF
The Manifesto for AI-enabled Governance !
byYannis Charalabidis
 
PDF
AI Vector Search Best Practices Multicloud Feb 2026
bySandesh Rao
 
Oracle Cloud Infrastructure 2025 Architect Professional (1Z0-1127-25) Master ...
byExamCert App
 
The new book “Marketing in the Metaverse” spotlights Scott M. Graffius’ research
byScott M. Graffius
 
Automation Without Apprentices: How AI Challenges the Open Source Way
byIcinga
 
GenerationAI Paris 2025 | How Agentic AI is Reinventing Organizations
byapidays
 
Spec-Driven Development with Kiro: Elevating Software Quality, Traceability, ...
byHaim Michael
 
Constraint Collapse and Fidelity Decay in Scaled Language Models
bySemantic Fidelity Lab | A. Jacobs
 
GTM-and-Sales-Plan for a cyber security product
byAshish Jangir
 
20260212 Security-JAWS activity results for 2025 and activity goals for 2026
byTyphon 666
 
Session 1/5: Enhancing Automation with Screenplay & Business Rules
bysuhanisingh58689
 
Poročilo odbora CIS (CH08873) za leto 2025 na letni skupščini IEEE Slovenija ...
byUniversity of Maribor
 
TrustArc Webinar - From Trends to Action: Fitting AI Governance into Privacy Ops
byTrustArc
 
Founder & Tech Lead | Web Development & Digital Growth Consultant | Helping B...
byShyamal Das
 
TravelTech Paris 2025 | Beyond the pipes: Why Channel Management isn’t really...
byapidays
 
Transcript: Escape from the Forbidden Zone: Smuggling green and inclusive tec...
byBookNet Canada
 
Traditional-Security-Models-No-Longer-Work.pptx (1).pdf
byOhhproJunction
 
GDG Cloud Southlake #49: Pradeep R Kumar: Implications of Agentic AI for Iden...
byJames Anderson
 
UiPath Automation Developer Associate Training Series 2026 - Session 3
byDianaGray10
 
Automated Governance for FME Flow: Smarter Admin at Scale
bySafe Software
 
The Manifesto for AI-enabled Governance !
byYannis Charalabidis
 
AI Vector Search Best Practices Multicloud Feb 2026
bySandesh Rao
 

How EA, BPM, SOA and ECM work together

  • 1.
    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
  • 2.
    • A digitalenterprise 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
  • 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 3 Agenda
  • 4.
    – It isnot 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
  • 5.
    • Experience showsthat 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
  • 6.
    • Different estimationsof 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
  • 7.
    • Co-existence ofmany 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
  • 8.
    • There aretwo 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
  • 9.
    • EA coordinatespeople, 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
  • 10.
    • 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
  • 11.
    © A. Samarin2014 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
  • 12.
    © A. Samarin2014 Architecting synergy v2 12 Be ready for common (mis-)understanding
  • 13.
    • Enterprise functioningcan 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)
  • 14.
    • Business ProcessManagement (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)
  • 15.
    • 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
  • 16.
    © A. Samarin2014 Architecting synergy v2 16 Variant 1 – classic (one template is used for many instances)
  • 17.
    © A. Samarin2014 Architecting synergy v2 17 Variant 2 – tailoring (a template is adjusted for each instance)
  • 18.
    © A. Samarin2014 Architecting synergy v2 18 Variant 3 – reactive (no initial template and next activity is selected based on the current situation)
  • 19.
    © A. Samarin2014 Architecting synergy v2 19 Variant 4 – proactive planning (similar to variant 3, but a few next activities [fragment] are executed together)
  • 20.
    © A. Samarin2014 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
  • 21.
    • An enterpriseis 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
  • 22.
    Architecting synergy v222 BPM reference model: Process-based disciplines © A. Samarin 2014
  • 23.
    Architecting synergy v223 BPM reference model: Process-oriented view of an enterprise (before BPM) © A. Samarin 2014
  • 24.
    Architecting synergy v224 BPM reference model: Process-oriented view of an enterprise (with BPM) © A. Samarin 2014
  • 25.
    © A. Samarin2014 Architecting synergy v2 25 BPM reference model: BPM suite components
  • 26.
    © A. Samarin2014 Architecting synergy v2 26 BPM reference model: BPM suite components (extended list)
  • 27.
    • 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
  • 28.
    • 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
  • 29.
    • 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
  • 30.
    • Services areconsidered to be explicitly-defined and operationally-independent units of functionality – Formal description – Operational independence – Invisible implementation Architecting synergy v2 30 Services © A. Samarin 2014
  • 31.
    • Definition – architecturalapproach 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
  • 32.
    • BPM, byrevealing 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
  • 33.
    • The relationshipbetween 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
  • 34.
    • Each enterpriseis 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
  • 35.
    © A. Samarin2014 Architecting synergy v2 35 Synergy between BPM and SOA (4) – Implementation layers of artefacts
  • 36.
    © A. Samarin2014 Architecting synergy v2 36 Synergy between BPM and SOA (5) – Relationship with other technologies
  • 37.
    © A. Samarin2014 Architecting synergy v2 37 Synergy between BPM and SOA (6) – no applications – just coordination of services
  • 38.
    • 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
  • 39.
    • Align accessrights 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
  • 40.
    © A. Samarin2014 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
  • 41.
    Responsible Accountable Consulted Informed BPMand information security: Extra relationships between activities (2) © A. Samarin 2014 Architecting synergy v2 41
  • 42.
    • There aresecurity-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
  • 43.
    • Doing thework – 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)
  • 44.
    • 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
  • 45.
    © A. Samarin2014 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
  • 46.
    • Principles – Theplatform 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
  • 47.
    • There aretwo 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
  • 48.
    • 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
  • 49.
    © A. Samarin2014 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
  • 50.
    • Current developmentcost & 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
  • 51.
    © A. Samarin2014 Architecting synergy v2 51 Solutions vs components
  • 52.
    • 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
  • 53.
    • The userstold 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
  • 54.
    • 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
  • 55.
    • In thecontext 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)
  • 56.
    • Various coordinationtechniques – decomposition cascade – assembling cascade – combine cascade © A. Samarin 2014 Architecting synergy v2 56 Enterprise as a system of processes (2)
  • 57.
    • Coordination maybestrong (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)
  • 58.
    • 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
  • 59.
    • 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)
  • 60.
    © A. Samarin2014 Architecting synergy v2 60 SI animated diagram Click for animation
  • 61.
    • Simple event-based(which looks like a state machine) © A. Samarin 2014 Architecting synergy v2 61 Coordination between processes (1)
  • 62.
    © A. Samarin2014 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)
  • 63.
    • CLOPs areusually 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)
  • 64.
    © A. Samarin2014 Architecting synergy v2 64 Enabler group, supporting group and customer group of clusters
  • 65.
    © A. Samarin2014 Architecting synergy v2 65 Is a system of processes like a PCB?
  • 66.
    © A. Samarin2014 Architecting synergy v2 66 Implicit coordination between CLOPs (1)
  • 67.
    © A. Samarin2014 Architecting synergy v2 67 Implicit coordination between CLOPs (2)
  • 68.
    © A. Samarin2014 Architecting synergy v2 68 Implicit coordination between CLOPs (3)
  • 69.
    © A. Samarin2014 Architecting synergy v2 69 Functional view at a system of processes (1)
  • 70.
    © A. Samarin2014 Architecting synergy v2 70 Functional view at a system of processes (2)
  • 71.
    © A. Samarin2014 Architecting synergy v2 71 Functional view at a system of processes (3)
  • 72.
    • 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
  • 73.
    • Many processpatterns 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
  • 74.
    • 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
  • 75.
    • Situation – acompany (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
  • 76.
    © A. Samarin2014 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
  • 77.
    • 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
  • 78.
    • From disparateIT 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
  • 79.
    • Business processesmake 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
  • 80.
    © A. Samarin2014 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
  • 81.
    © A. Samarin2014 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
  • 82.
    • 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
  • 83.
    • Majority ofthe 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
  • 84.
    Four communication patternsfor 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
  • 85.
    A partner-initiated-demand may requiredseveral exchanges between the partner and the government Government Time © A. Samarin 2014 Architecting synergy v2 85
  • 86.
    The partner mayneed 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
  • 87.
    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
  • 88.
    Process -- E-gov unifiesthe 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 … …
  • 89.
    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
  • 90.
    Partner’s view © A.Samarin 2014 Architecting synergy v2 90
  • 91.
    Partners Existing application Coordination and integrationbackbone 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
  • 92.
    Partners Existing application © A. Samarin2014 92 E-gov traditional application architecture Portal Existing application Existing application Government Application Application Application Architecting synergy v2
  • 93.
    Partners Existing application Coordination and integrationbackbone 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
  • 94.
    Partners Existing application Coordination and integrationbackbone 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
  • 95.
    Partners Coordination and integrationbackbone 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
  • 96.
    Partners Coordination and integrationbackbone 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
  • 97.
    © A. Samarin2014 Architecting synergy v2 97 Steps of evolution in application architecture Introductory architecture Target architecture E-Social system architecture Portal-centric architecture Transitional architecture
  • 98.
    • 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
  • 99.
    N E E D S R E S U L T S Enrich Knowledge Improve Operations acquisition channels for external data/ information/ knowledge dissemination channelsof 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)
  • 100.
    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
  • 101.
    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
  • 102.
    • 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
  • 103.
    • Combining somepatterns from other patterns © A. Samarin 2014 Architecting synergy v2 103 Strategy Implementation Chain (SIC)
  • 104.
    • Unfortunately, ITand 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
  • 105.
    • QUESTIONS? • Personalwebsite: 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
  • 106.
    • “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
  • 107.
    • Capturing artefactsand 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
  • 108.
    • Reveal allhidden 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
  • 109.
    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
  • 110.
    © A. Samarin2014 Architecting synergy v2 110 Profiling services - example
  • 111.
    © A. Samarin2014 Architecting synergy v2 111 Decision taking - example