01-终版金新明-Model Based Architecture Design -V1Dec 19, 2017  · • First Job: Cobol...

Dec2017

ModelBasedArchitectureDesign基于模型的架构设计

Ming X Jin 金新明 – Chief Risk ArchitectDDD Beijing, 9th Dec 2017

PUBLIC

2

About me …

• Name: Ming X Jin 金新明 Current Role: Chief Risk Architect in HSBC

• Education Background: Automatic Control, Computer Science (Ph.D.)

• PhD topic: Model based business process simulation

• First Job: Cobol programmer for UnionPay POS integration

• Multi Industry Sector experience: Academic, Consultancy, Defense, Manufacturing, Banking

• Multi Architect Roles: – Systems Architect – Thales Group (4 years)– Technology Architect – Infosys (1 year)– Data Architect – RBS ( 6-month)– Process Architect – Barclays Capital (2 years)– Solution Architect – RBS (6-month), Barclays Capital (1 year), Standard

Chartered (14-month)– Enterprise Architect – NOW

PUBLIC

3

Ubiquitous Models

• Model is always there, intentionally or not intentionally;

• Model has a wide context, but a specific purpose;

• There is a right model but no complete model;

• There is no universal model but a suitable model;

• Code alignment with models determines the code quality;

PUBLIC

4

Hierarchical Organisation of Software & Complexity

System or product

Subsystems/Modules

Packages

Classes/Objects

Methods

highest abstraction level

lowest level

Product line (or product family)

Source code

PUBLIC

• Applicationlevelcomplexity– Complexityofallinterfacesthatapplicationuses– Complexityofallinterfacesthatapplication

provides– Complexityofapplicationsourcecodeanddata

• Enterpriselevelcomplexity– Complexityofoverallperformanceoptimisation– Complexityofintegration– Complexityofdatamanagement– Complexityofbusiness/technologyalignment

5

System Decomposition & Domain Driven Design

Why decomposing systems?– Tackle complexity by “divide and conquer”– See if some parts already exist & can be reused– Focus on creative parts and avoid reinventing the wheel– Support flexibility and future evolution by decoupling unrelated parts, so each

can evolve separately (“separation of concerns”)

Why Domain Driven Design?– Disciplined modelling approach– Bounded context– Ubiquitous language for easy communication– Focusing on domain and domain logic instead of interfaces

PUBLIC

6

Project Example: Zachman Framework Based Modelling

6PUBLIC

7

Project Example: Various Model Usage

PUBLIC

8

Project Example: Model Based Code Generation

PUBLIC

9

Platform Specific

Generated Rules

Hand-Built Application

CodeDAS+ BEM jBPM

Project Example: What & How delivered?

Business Domain Model

(BDM)Life Cycle

EventsBusiness

Process Model(BPMN)

Business Analyst 30%

SystemDomain Model

(SDM)System Events

(BEMN)Functional

Process Model(BPMN)

SystemsAnalyst 30%

Business Requirements

System Requirements

Data Object Model

Event Execution Language

(EVEL)

Enriched Business Processes

Solution Architect 15%Formalised

Rules

Platform Specific

Generated Code

Platform Specific

Generated Code

Platform Specific

Generated Code5%

Developer 20%

Model Developer

Business Requirements

(Level 2)

FunctionalRequirements

(Level 3)

Platform Independent

Model(Level 4)

Platform Specific Model

(Level 5)

Code(Level 6)

Data (What) Events (When) Process (How) Drivers (Why) Resource Type % of Overall Effort

PUBLIC

10

Project Example: Defining Context - Business Use Case Meta Model

PUBLIC

11PUBLIC

Project Example: Defining Context - Use Case Interaction Model

12

Project Example: Model Transformation

class BDM Model Structure

Accounting

Common

Reporting

Level 2

Level 3

Level 4

Code

Level 5

Unified BDM

Accounting

BDM

Accounting

BDM

Reporting

BDM

Reporting

BDM

Reporting

BDM/PVO

PIM

Reporting

BDM/PVO

PIM

Java, XML,

DDL

Java, XML,

DDL

C#, Java,

XML, DDL

C#, Java,

XML, DDL

Accounting

Java Object

Model

Accounting

Java Object

Model

Reporting

C# Object

Model

Reporting

C# Object

Model

LDM

Motif BusinessObject Model

Once Only Manual Merge TransformImportedRecreateableCode Generation

Legend

C# Language

Interfaces

C# Language

Interfaces

Java Language

Interfaces

Java Language

Interfaces

Barcap PSM Component

Interfaces

Barcap PSM Component

Interfaces

DAS+

Repository

Interfaces

DAS+

Repository

Interfaces

Accounting

BDM/KVO

PIM

Accounting

BDM/KVO

PIM

Reporting

Java Object

Model

Reporting

Java Object

Model

LDM --> BDM

Mapping

LDM --> BDM

Mapping

Motif Accounting Java PSM

Motif PresentationJava PSM

Motif Presentation C# PSM

Motif PresentationObject Model

Motif Accounting Object Model

PUBLIC

13

Project Example: Model Based Design - Cons Vs. Pros

• Pros: Ø Separate concerns at different levels from different views;Ø Provide a single version of truth for all design artefacts across different

teams and releases in the project life cycle;Ø Ensure a holistic, consistent, and integrated Model;Ø Build traceability between various artefacts of the development process

from high level business requirements to detailed implementation further extend to testing;

Ø Reusable and extensible;Ø Supports all development teams with different artefacts originated from

the same source model.• Cons:

Ø Long release cycle;Ø Model becomes the bottleneck for fast delivery;Ø High front investment on modelling;Ø Need domain experts;Ø Isolation between business and dev teams.

PUBLIC

14Source: http://microservices.io/patterns/decomposition/decompose-by-business-capability.html

Supports

What would I do differently ? - Conway’s Law

PUBLIC

Organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.

Melvin Conway, 1967

OR

If you build huge, monolithic teams, you will end up with huge, monolithic systems, but if you build small, agile teams, you will end up with small, agile systems.

15

What would do differently ? – Move to DevOps Model

PUBLIC

16

What would do differently ? – Move to Microservices (1)

Source: https://www.ibm.com/developerworks/websphere/library/techarticles/1601_clark-trs/1601_clark.html

PUBLIC

17

What would do differently ? – Move to Microservices (2)EnablingPodstodeliverbusinessvalueindependently

Use Case Use Case Use Case Model Model Model

PUBLIC

18

LookingForward– HSBC’sVisionandHowDDDMayHelp

• OurGroupCTOhasgotavisionof100%API,100%Cloudand100%Services;

• ThecomplexityofsystemlandscapeincorporatedwithdomainknowledgeinHSBCneedsafullpictureandunderstandingtoallowfastchanges;

• WeareadoptingDevOpstocompetewithFinTechandInsureTechfirmswhoareconstantlyreleasingnewandgreatproducts.DDDgoeshandbyhandwithDevOps;

• MicroservicesarebestusedinaCloudarchitecture,wheretheycanscalehorizontally.However,weneedstartfromthemodelsinsteadofservices;

PUBLIC

19

Thank you!

PUBLIC