The document discusses using microservices and business process management (BPM) to improve application architecture. It addresses typical IT concerns like time-to-market, governance, and costs. The document recommends developing solutions as independently deployable microservices and refactoring existing systems into microservices. It also discusses challenges like defining microservice granularity and target application architectures when using microservices and BPM.

1. Better application architecture with
#microservices and #BPM
Alexander SAMARIN

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 2
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 Better application architecture 3
Typical IT concerns

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 Better application architecture 4
Application architecture key concepts (1)

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 Better application architecture 5
Application architecture key concepts (2)
Service consumer
Service provider

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 assembled
from microservices may have
many microservice-to-microservice
dynamic connections N * (N-1) / 2
2016-09-01 Better application architecture 6
Application architecture key concepts (3)

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 Better application architecture 7
Application architecture key concepts (4)
API gateway

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 Better application architecture 8
Microservices in application lifecycle

9. 2016-09-01 Better application architecture 9
Various development lifecycles
monolith
applications
process-based
solutions
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 Architecture
CI – Continuous Integration

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 Better application architecture 10
Application building blocks which
BPM-suite tool as APaaS can manage

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 Better application architecture 11
BPM-suite tool helps to determine
“right” granularity for microservices

12. 2016-09-01 Better application architecture 12
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

13. 2016-09-01 Better application architecture 13
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

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 Better application architecture 14
Decomposing of monoliths

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 Better application architecture 15
Bonus – agile development

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
Better application architecture 16
Thank you
2016-09-01

17. 2016-09-01 Better application architecture 17

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 Better application architecture 18