Better application architecture with #microservices and #BPM

Alexander SAMARIN

Better application architecture 2

• Typical concerns– Time-to-market for new solutions and new versions of existing

solutions (IT agility)– Ownership of governance and management of applications– Healthy eco-system of partners and providers– Transparent cost structure and other good business practices

• How to address those concerns– Develop solutions as a suite of independently deployable, small,

modular services known as microservices (like a football team is assembled from individual players)

– Refactor, modernise and decompose existing monoliths into microservices

– Start new solutions with microservices– Better manage changes in software application

2016-09-01

Better application architecture

Better application architecture 3

• I like microservices• How to define granularity of microservices?• Let us buy API gateway• We must have an APaaS• Let us decompose our in-house monolith ERP into

microservices• Where can I deploy my microservices?• I can keep some local data in my microservices, but how

to use some corporate data?• We need DevOps, CI, etc.• What is our target application architecture?2016-09-01

Typical IT concerns

Better application architecture 4

• Unit-of-functionality is a computing component implementing a particular capability– examples: function, method, package

• Unit-of-deployment is a computing component which can be individually and independently deployed into a runtime computing environment– Note: unit-of-deployment may be a composition of

units-of-functionality (i.e. monolith) – Note: unit-of-deployment may be an aggregation of

other units-of-deployment (i.e. assembly)

2016-09-01

Application architecture key concepts (1)

Better application architecture 5

• Interface is a shared boundary between two units-of-functionality, defined by functional characteristics, signal characteristics, or other characteristics as appropriate

• Service is a unit-of-functionality which is available from (usually separate from its consumer) unit-of-deployment via an explicitly-defined interface and provides some added-value being consumed – Note: Interface to software services is called

Application Programmer Interface (API)• Service agreement is an agreement between

the service consumer and the service provider on performance, measurement and conditions of service delivery

2016-09-01

Application architecture key concepts (2)

Service consumer

Service provider

Better application architecture 6

• Microservice is functionally-minimalistic and deployment-independent service– functionally-minimalistic, i.e. follow the Single Responsibility Principle– deployment-independent i.e. unit-of-functionality equals to unit-of-

deployment thus autonomous in some extent• Assembly of microservices may

be a microservice as well

• Solutions which are assembledfrom microservices may havemany microservice-to-microservicedynamic connections N * (N-1) / 2

2016-09-01

Application architecture key concepts (3)

Better application architecture 7

• API gateway is a proxy between a service consumer and a service provider – Gateways are necessary to improve various “abilities” (flexibility,

measurability, availability, etc.) of those dynamic connections because service providers and services consumers may be spread over network nodes, computing environments and clouds

2016-09-01

Application architecture key concepts (4)

API gateway

Better application architecture 8

• Microservices are dependent at the design-time – because they are for Service Oriented Development

• Microservices are independent at the deployment-time– because they are autonomous (at some extent)

• Microservices are interdependent at the run-time– because they invoke each others

2016-09-01

Microservices in application lifecycle

Better application architecture 92016-09-01

Various development lifecycles

monolith applications

process-basedsolutions

microservice assembles

Existing application Change something New applicationTest everything

Easy Difficult

Existing assembly Change something New assemblyTest relationships

Average (granularity?)

Average (too many links!)

Easy and safe(lesser links)

Existing process

Easy (granularity comes

from business)

New process

CI

CI

SA

Dev Ops

Dev Ops

SA

SA

CI Dev Ops

Change something Test relationships

SA – Solution ArchitectureCI – Continuous Integration

Better application architecture 10

• Single-responsibility building blocks are microservice-ready– Human activities (as UI)– Data structures (from various repositories)– Documents (from various repositories)– Events– Business rules– Roles– Automated activities– Explicit-assemblies via DSLs (orchestration and choreography)– Reports

• Single-responsibility building blocks – Dashboards– Portals (as a navigator over some human activities)– Implicit-aggregators via events and reactive programming

2016-09-01

Application building blocks which BPM-suite tool as APaaS can manage

Better application architecture 11

• Each process, case and activity is a single responsibility• Human activities are designed for single responsibility • Data structure design is actually Domain-Driven Design

because a process or a group of related processes define a domain

• Granularity of business rules is defined by their consumers (i.e. activities)

• Automated activities primarily augment (enrich) related human activates thus their granularity

• Roles are related to processes, cases and activities

2016-09-01

BPM-suite tool helps to determine “right” granularity for microservices

Better application architecture 122016-09-01

Frequency of changes in various building blocks

Types of building block

Prototyping Implementation Production

Human activities High Medium Low

Data structures Low Medium Low

Documents Low Low Low

Roles Low Low Low

Business rules Medium Medium Low

Automated activities Low High Medium*)

Reports Low Medium Low

Records Low Low Low

Dashboards Low Medium Low

Portal Low Medium Low

Explicit-assembles Medium Low Low

*) It is mandatory to be ready for quick changes in automated activities for error recovery of instances

Better application architecture 132016-09-01

Scenarios for implementation of process-centric solutions

Types of building block

Prototyping Pragmatic combination Extreme microservices (BPM-Suite tool defines API)

Human activities iBPMS iBPMS iBPMS

Data structures New: iBPMS, existing: ext. tools μService from external tools μService from corporate tool

Documents New: iBPMS, existing: ext. tools μService from external tools μService with corporate tool ECM

Roles New: iBPMS, existing: ext. tools New: iBPMS, existing: ext. tool Corporate tool IAM

Business rules New: iBPMS, existing: ext. tools New: iBPMS, existing: μService iBPMS and μService (exposing iBPMS)

Automated activities New: iBPMS, existing: ext. tools Generic: iBPMS, specific: μService Generic: iBPMS, specific: μService

Reports New: iBPMS, existing: corp. tool New: iBPMS, existing: corp. tool μService with corporate tool

Records New: iBPMS, existing: corp. tool New: iBPMS, existing: corp. tool μService with corporate tool

Dashboards New: iBPMS, existing: corp. tool New: iBPMS, existing: corp. tool μService with corporate tool

Portal iBPMS or corporate tool iBPMS or corporate tool Corporate tool role-based portal

Explicit-assembles iBPMS iBPMS iBPMS

Better application architecture 14

• Determine business domains and the kernel• Select a particular domain for be “eclipsed”• Model a group processes (activities, events, roles and

data) for this domain• Separate back office and front office• Find candidates for the kernel• Define data model for this domain• Implement domain and kernel data as services• Implement kernel’s services• Apply eclipse pattern (also known as stranger pattern)• Refactor what matter with processes• Keep the monolith in the box 2016-09-01

Decomposing of monoliths

Better application architecture 15

• The combination of BPM and microservices also naturally incorporate agile development into application architecture

• Agile development is the best way to implement microservices

• Related blogposts– http://improving-bpm-systems.blogspot.ch/search/label/%23microservices

– http://improving-bpm-systems.blogspot.ch/search/label/%23apparch

– http://improving-bpm-systems.blogspot.ch/2014/06/different-coordination-techniques-in.html

– http://improving-bpm-systems.blogspot.ch/2014/04/ideas-for-bpmshift-delenda-est-vendor_27.html

– http://improving-bpm-systems.blogspot.ch/2013/04/enterprise-patterns-strategy.html

2016-09-01

Bonus – agile development

Better application architecture 16

• 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

Thank you

2016-09-01

Better application architecture 172016-09-01

Better application architecture 18

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

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

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

About me

2016-09-01