Business Capability Model SOA/BPM level · BPM/SOA design questions Critical to use the same model...

AGILITY BY DESIGN “The best way to predict your future is to invent it” - Frank Herbert

Business Capability ModelSOA/BPM level

Glenn SmythFounder & CE

Fragile to Agile

Cassandra

Creative Commons

www.fragiletoagile.com.auAGILITY BY DESIGN 217/11/2016

Business Capability Model Explained - Recap

• A logical model of what the business does, not how (business process model) or who does it (organisational structure)

• Models the business as a set of services (service providers), including internally and externally sourced services

• Models all services, manual or automated

• Is static, only changes if an organisation enters/exits a business or adds a new technical channel but not when implementing new products

• Benefits flow from the deeper understanding of the business it yields


Business Capability Model Views – Recap

Executive View• Decomposes capabilities to two levels of abstraction only• Less rigour applied due to its high level nature• Consulting artefact• Used to manage up e.g. heat maps, investment and prioritisation

Architecture View• Decomposes capabilities to four or five levels, where necessary• Design artefact – must be developed with rigour to achieve the detail required and

to be useable for deep design – e.g. Data Affinity Analysis• Used for deep technical design e.g. overlays, Current State, Target State• Used to drive project level design as Executive view not detailed enough to support

this

BPM/SOA View• Adds service containers - defines process and data boundaries and answers key

BPM/SOA design questions

Critical to use the same model for all the above, just elaborated in each step/view


Business Capability Model – Executive Level CAUDIT/EA Australia version


Business Capability Model – Executive LevelDeakin University


Business Capability Model – Architecture levelDeakin – Partial


BPM and SOA


SOA – Introduction

• A way of designing and delivering solutions in a more modular fashion

• Definition: Service Oriented Architecture (SOA) is the policies, practices and frameworks that enable functionality to be provided and requested as sets of services published at a granularity relevant to the business, which are abstracted away from the implementation using a single, standards based form of interface

• Is an evolution, not a revolution, and has it’s origins in Component Based Development (90s) and Modular Systems Design (80s)


BPM – Overview

Business Process Management (BPM) is a design approach and discipline covering initial process design, process implementation, process control/monitoring etc., process analytics and process improvement

Business Process Management Suite (BPMS) is a technology solution that drives work through the organisation, enabling real time visibility, monitoring, optimisation and tracking/traceability, basically supporting BPM.• Weaves services into end to end processes• Seamless integration of systems orchestration and human workflow steps• Supports simulation/what if testing of process changes• The pianola for SOA notes, process diagrams using BPMN (Business Process

Modelling Notation) automatically generate the play sheet (Business Process Execution Language)


Business Capability Model – BPM/SOA level

Some key design issues for BPM/SOA:

• Unclear where the boundary between processes and services should be drawn• Unclear where top down process reengineering stops (BPR) and bottom up continuous

improvement (lean manufacturing) starts• Unclear what the correct granularity for services is• Unclear where and at what level organisational wide control is enforced and where local

autonomy is required• Unclear what is a process orchestration and what is a service orchestration (what should

be implemented on a BPMS and what on an ESB/Message Bus/Integration Layer?)• Might be building the services right but are the right services being built

The solution to these issues is a concept called Service Containers


Service Containers - Introduction

• Service Containers are a grouping of business capabilities – from the BCM - that define an organisation’s business service offering

• They are the foundation for a services based, or composable business

• While they have a technical impact, they are a business concept

• They cannot be done on “any BCM” – require Architecture level BCM developed with required rigour – in particular Data Affinity Analysis

• Some industry context:• Similar to software fortresses, but capability not application based• Similar to service domains (BIAN)• Can be technically instantiated as microservices, which use the concept of

bounded contexts• Should not be confused with application containers used in platform-as-a-service

offerings such as Cloud Foundry


Service Containers - Uses

• Map business design to technical design

• Define the business boundaries for process, service and data responsibility

• Identify where service level agreements and service contracts are needed

• Define the boundaries between top down and bottom up process improvement i.e. re-engineering vs. Kaizen

• Cornerstone for determining SOA service or microservice granularity

• Define the scope and size for process/sub-process steps


Business Capability Model – BPM/SOA ViewDeakin - Partial


Service Container Boundaries – Inputs

Example business considerations:• Ability to in-source/out-source a capability• Capabilities that are not going to be shared (diversified/coordinated)

Example technical input:• Channel Independence – support for omni/multi channel, enable

emerging channels

They will occasionally clash – where they do, business design considerations win. This provides early identification of areas where technical complexity and cost exist.


Example Business Input - Sharing


Technical Input – Channel Independence


BCM - Service Container Overlay


Integration Reference Architecture (Sample)


Integration Architecture Principle (Sample)


Software Containers

• As-designed service container boundaries are ideal state that rarely exist

• COTS applications are usually prevalent in most organisations

• Boundaries implemented may differ from design, typically forming a superset of service containers known as a software container

• Software container boundaries are determined by mapping application footprints to the Business Capability Model

• Services within a software container communicate with each other using the methods built into the application software

• Where a process orchestration crosses software containers, services from the containers must be integrated via SOA techniques


Service Containers vs. Software Containers


Questions?

Business Capability Model SOA/BPM level · BPM/SOA design questions Critical to use the same model...

Documents

Transcript of Business Capability Model SOA/BPM level · BPM/SOA design questions Critical to use the same model...