Model Driven Business

Architecture

Pete Rivett
CTO, Adaptive
[email protected]

Copyright Adaptive Ltd. 2001

 Outline

• What is business architecture?

• User needs
• Information needs (metamodels)
• Use of standard metamodels
• Suitability of UML
• Future
• Summary

Copyright Adaptive Ltd. 2001 13/02/2002 2

 Adaptive Experience

• 10+ blue-chip Enterprise Architecture

projects
• Addressing real ‘business pain’
– usually across the ‘IT-business’ gap
• Implemented using Adaptive’s repository-
based software product set
• Time-boxed short iterations
• Common models evolved from projects
• Provide sound starting point
– (And a product)

Copyright Adaptive Ltd. 2001 13/02/2002 3

 Why Business Level Architecture?

• Separation of concerns
• Outside vs inside
• Longer-lived structures
• Reference models and patterns
• Manage complexity, change and danger
• Esp. for B2B, outsourcing, mergers
• Applies to processes, people, objectives,
business relationships/contracts…
• “Component Based Organizations”

Copyright Adaptive Ltd. 2001 13/02/2002 4

 Why Link Business and Software
Architectures?

• Traceability to business goals

• Prioritisation
• Impact analysis
• Dependencies
• Basis for configurations
• Two-way communication
• Cut redundancy/duplication
• Regulatory governance

Copyright Adaptive Ltd. 2001 13/02/2002 5

 Business Architecture Scope
What
Benefits & Quantify it.........
Measurements
Objectives
With
Which means that we need the
We need to do this ..... ability to do these things .....
Capabilities Assessments
New / Modified

Principles
These are the detailed
things impacted ... Business
Analysis
Change Propsals
(Gap Analysis) Architectures
Produce

Business & IT IS
Architectures Architectures
Produce
(Current) It would look like this .....
Business & IT
Process
Architectures
High-level Architectures
(Target)
Dependancy Plan

This is how it can be achieved .... Programmes

How
(Change Proposals) Goverance

Make it so and keep me

Should we do it ?/ what priority? / max benefits ......... Programmes
posted....

Copyright Adaptive Ltd. 2001 13/02/2002 6

 TM
ENTERPRISE ARCHITECTURE - A FRAMEWORK
DATA What FUNCTION How NETWORK Where PEOPLE Who TIME When MOTIVATION Why

SCOPE List of Things Important List of Processes the List of Locations in which List of Organizations List of Events Significant List of Business Goals/Strat SCOPE
to the Business Business Performs the Business Operates Important to the Business to the Business
(CONTEXTUAL) (CONTEXTUAL)

Planner ENTITY = Class of Function = Class of Node = Major Business Ends/Means=Major Bus. Goal/ Planner
Business Thing Business Process Location People = Major Organizations Time = Major Business Event Critical Success Factor
e.g. Semantic Model e.g. Business Process Model e.g. Business Logistics e.g. Work Flow Model e.g. Master Schedule e.g. Business Plan ENTERPRISE
ENTERPRISE System
MODEL MODEL
(CONCEPTUAL) (CONCEPTUAL)

Owner Ent = Business Entity Proc. = Business Process Node = Business Location People = Organization Unit Time = Business Event End = Business Objective Owner
Reln = Business Relationship I/O = Business Resources Link = Business Linkage Work = Work Product Cycle = Business Cycle Means = Business Strategy
e.g. Logical Data Model e.g. Application Architecture e.g. Distributed System e.g. Human Interface e.g. Processing Structure e.g., Business Rule Model
SYSTEM
SYSTEM Architecture Architecture
MODEL
MODEL (LOGICAL)
(LOGICAL)

Node = I/S Function

Ent = Data Entity Proc .= Application Function (Processor, Storage, etc) People = Role Time = System Event End = Structural Assertion
Designer Reln = Data Relationship Cycle = Processing Cycle
Designer
I/O = User Views Link = Line Characteristics Work = Deliverable Means =Action Assertion
e.g. Physical Data Model e.g. System Design e.g. Technology Architecture e.g. Presentation Architecture e.g. Control Structure e.g. Rule Design TECHNOLOGY
TECHNOLOGY
MODEL MODEL
(PHYSICAL) (PHYSICAL)

Node = Hardware/System Builder

Builder Ent = Segment/Table/etc. Proc.= Computer Function Software People = User Time = Execute End = Condition
Reln = Pointer/Key/etc. I/O = Data Elements/Sets Link = Line Specifications Work = Screen Format Cycle = Component Cycle Means = Action

DETAILED e.g. Data Definition e.g. Program e.g. Network Architecture e.g. Security Architecture e.g. Timing Definition e.g. Rule Specification DETAILED
REPRESEN- REPRESEN-
TATIONS TATIONS
(OUT-OF- (OUT-OF
CONTEXT) CONTEXT)

Sub-
End = Sub-condition Sub-
Contractor Ent = Field Proc.= Language Stmt Node = Addresses People = Identity Time = Interrupt
Reln = Address I/O = Control Block Link = Protocols Work = Job Cycle = Machine Cycle Means = Step Contractor

FUNCTIONING FUNCTIONING
e.g. DATA e.g. FUNCTION e.g. NETWORK e.g. ORGANIZATION e.g. SCHEDULE e.g. STRATEGY
ENTERPRISE ENTERPRISE

John A. Zachman, Zachman International (810) 231-0531

 Users

• Wide variety of roles

– Many not technical
– Many with only casual use
• Focus on relationships
• Different levels of abstraction
• Need for visualization
• Legacy of representation style and
layout

Copyright Adaptive Ltd. 2001 13/02/2002 8

 Simple Business Context Diagram
Prospects

Competitors Competitive Customers

Products

Pr
In M od

Order
uc
igence

vo o n
ing

Selling
ice ey t
ertis
ntell

Adv
Market I

Sales Finance Manufacturing

Order Suppliers
Materials

ic ing
Pr
Marketing Product Spec

Executive Tax

ct ion
Dire et
Budg Company X
Re
gu
la
tio
ns

Government

Copyright Adaptive Ltd. 2001 13/02/2002 9

 Diagrams and Navigations

Copyright Adaptive Ltd. 2001 13/02/2002 10

 “A model can tell a thousand pictures”

Copyright Adaptive Ltd. 2001 13/02/2002 11

 UML for Business Architecture Users

• Tools perceived as:

– Too technical
– Hard to learn
– Expensive (usually)
• Metamodel perceived as too complex
and abstract
• Profiles give neither simplicity of
model nor fitness for purpose

Copyright Adaptive Ltd. 2001 13/02/2002 12

 Approach

• Complex metamodels (e.g. UML) for

technical areas where existing data
and tool integrations exist
• Simpler metamodels for new areas
• Views and navigations to simplify
complex models
– User/role specific
• Generic Visio-template mapping
technology

Copyright Adaptive Ltd. 2001 13/02/2002 13

 Business Architecture Metamodels

Business Strategy
Organization
Business Context
Process Components
Information Operational

…linked with relevant technical metamodels e.g. UML, CWM

Copyright Adaptive Ltd. 2001 13/02/2002 14

 Standards - MOF

• Pros
– Essential for metamodel-driven approach
– Up to the job, simple and flexible
– Federation and combining metamodels good
– XMI ‘out of the box’
• Cons
– Need extra properties on the UML
– Unclear implications of some choices
– 1-way navigations a pain
– Physical considerations get in the way
– Missing some basics like versioning, views,
queries
Copyright Adaptive Ltd. 2001 13/02/2002 15
 Standards - EDOC

• Choice of profile or metamodel (with

notation)
• Starts from (business view of)
systems not ‘real’ business
• Only just adopted so little experience
• CCA part quite mature
– Commonality with EAI, ebXML
– Used successfully for inter-application
architecture

Copyright Adaptive Ltd. 2001 13/02/2002 16

 Standards - EAI

• Choice of profile or metamodel

• Extends EDOC with detail for inter-application
integration, e.g.
– Events
– Flows
– Adapters/Connectors
– Messages (detailed format)
• Just adopted (in final throes)
• Needs clearer positioning with EDOC, CWM
• For business architecture EDOC probably OK

Copyright Adaptive Ltd. 2001 13/02/2002 17

 Standards - CWM

• Mature and at second revision

• To support warehousing covers many
areas including information resources,
transformations etc
• Modular and extensible
• Good basis for:
– Information architecture
– Glossary/nomenclature
– Software deployment (needs extending)

Copyright Adaptive Ltd. 2001 13/02/2002 18

 Visio Templates vs UML Profiles

• Visio shapes mapped to metamodel

– Custom appearance
• 2d and 3d shapes
• Connectors
– Custom behavior
• drill-down
• editing form
– Help/process
– Some degree of checking (must be
programmed)
• UML Profiles just have a shape and a set
of tags (displayed in a generic form). This
cannot compete for business users.
Copyright Adaptive Ltd. 2001 13/02/2002 19
 UML Suitability (1)

• Class diagrams
– OK
• Instance diagrams
– Vital but shamefully neglected in common tools
• Use case diagrams
– OK as far as they go
– Diagrams say too little – all devolved to the
documents
– Useful if extended to show links to data

Copyright Adaptive Ltd. 2001 13/02/2002 20

 UML Suitability (2)

• Activity diagrams
– OKish: fit with common process
notations
– UML tool support not
– Metamodel a complete nightmare
• Collaboration diagrams
– Useful at system level
– Generally need more richness as in
EDOC/CCA

Copyright Adaptive Ltd. 2001 13/02/2002 21

 UML Suitability (3)

• Sequence diagrams
– Too low level in general
– In some cases useful for processes (cf activity
diagrams with swim lanes)
– Useful for establishing system dependencies
• State diagrams
– Not of interest in general
• Deployment diagrams
– Far too limited

Copyright Adaptive Ltd. 2001 13/02/2002 22

 Other UML Issues

• Mapping notation to metamodel

• Too many inherited features
• Cannot create views
• Cannot support refinement
– e.g. an analysis model – copy as the start of a
design model and keep 2-way traceability
• Poor package management
• No global object identity
• No diagram interchange
• No control over rigor (when to check)

Copyright Adaptive Ltd. 2001 13/02/2002 23

 UML2 Vision

• Core common to MOF2 and UML2

– Build ‘families’ of languages
– So can use UML tool as a default with
less hassle
– So can use purpose-specific tools on
same data
– Selectable constraint checking
• Formal mapping to diagrams
– Could drive more generic drawing

Copyright Adaptive Ltd. 2001 13/02/2002 24

 The Future?

• Will UML2 remain an analysis and

design language?
• Or a panacea for everything
(Universal Modeling Language)?
• Will it have specifiable notations?
• Most talk about applying it to business
does not understand the issues

Copyright Adaptive Ltd. 2001 13/02/2002 25

 Summary

• Business architecture has a different set of

users and needs
• Puts modeling at the start of the process
• Requires integrating standard technical
and business metamodels
• OMG has several relevant technical
standards in addition to UML
• UML has limited applicability for business
aspects
• UML2/MOF2 should improve this
depending on notation flexibility
Copyright Adaptive Ltd. 2001 13/02/2002 26