Background
Software Engineering Visualization
Business Process
Management
Enterprise Architecture
Knowledge Management
Interoperability
Model-Driven Applications
Domain Specific Metamodels
Collaboration
Product design
• Modelers like• Structure• Agreement• Certainty• Clarity• Precision
• Enterprise modeling• Complex problems• Multiple views• Uncertainty • Fuzzy, incomplete
understanding• Ambiguous
Bias towards Agreement
• Agreement by abstraction• Agreement by concretization
Agree about the
details
Agree about the full picture
Enterprise Architecture
Objectives
Components Standards
Functions
Enterprise Model Content
Industry standards
Discipline standards
Company standards
Project standards
Project design
Team
Individual
Contextual
Same precise meaning everywhere
Continuously evolving
Reasonably stable
Well-structured
Complex connectivity, multi-facetted structures
Bottom up
Top down
Middle-out
Management control
Freedom to innovate
Well-structured
Focus of Enterprise Modeling
• Don't reduce enterprise architecture to IT architecture• “What can we automate” is not always the right question• Don't frame business problems as IT problems• Beware of bias towards the tangible
Modeling
• Don't confuse analysis and design
• Keep models and languages as simple as possible
• Beware of leaving important things out at the boundaries
• Don’t confuse views with the underlying elements
Analysis - Where and How to Start?
• Simple, concrete
• Whitespace• No links• Intensionally
vague structure
• Flexible
Relationships Often Reflect Processes
Send Receive
Application
Presentation
Session
Transport
Network
Data link
Physical
Boundaries, Relationsips, Roles
Project
Work package
Task
Task
Company
Department
Group
Person
Person
Multiple Views – Two Model ElementsWhat they refer to
What they say about them
Area
System
Procurement package
Structure stress system
Procurement class
Material class
Safety class
Maintenanceclass
Fabrication Unit Mech-
anics
Piping
Support
Process
Operations
Yard
Procure-ment
HSE
Materialstechnology
Telecom and control system
Instru-mentation
Planning
Equipment
Beware of hierarchies, they are often local to a viewpoint and not shared by everyone
Processes
• Product models are often more important and fundamental than process models
• Processes are better understood by focusing on the core• the decisions to make • the issues to solve• the results to produce
than on the administrative ordering of steps
Business Process Modeling
Product Dependencies CauseProcess Dependencies
21PA001ACrude Oil Booster Pump
PS-R152-0029
PS-R152-0010
Area line number21-1001-R152
16” Ball valve BL030
Pipe area line• 3D Layout
Equipment and instruments• Modelled in 3D• General
arrangement drawing from supplier
• Process datasheet
Process line (input)• System engineering• Pipe dimension,
material, insulation etc.
Pipe supports• Connecting to
structure elements
Products over Processes
Mech-anics
Piping
Support
Process
Process Line
Area
System
Process systems
engineering
3D layout modeling -
piping
Procurement GA drawing
from supplier
Iso stress analysis
Procurement data sheets
from supplier
Area Line Equip-ment
Instru-ment
Pipe Support
Structure Element
3D layout modeling -
support PlanningYard
Procure-ment
Manufacturing & assembly
Procurement package
Process
Org.
Product
Process Hierarchy – Work Breakdown
Time
Organization
Process
Product Information,documents
Beware of matrices and streamlined frameworks, often you need to “break the system”
Don't let the language be a straight-jacket
• Process model in UML
• Organization model in UML
Step 1 Step 2 Step 3
Depart-ment 1
Depart-ment 2
Company
Aspects
• Multi-dimensional analysis, combining e.g. processes with the data it manipulates and the organizational roles responsible, is superior to single-dimensional data modeling and business process modeling
• During decomposition, don’t expect to “go all the way down” using a single modeling language • Another language is likely to be a better match for detailed
models than the one used for high-level overviews• Aspects that can be separated on one level of detail may be
inherently woven together on another level • Products, processes and organization models do for instance
become thoroughly intertwined in work execution
Weaving Aspects Together
Task
Process structure Product structure
Organizational structure
System Infrastructure
Layers
Product
ProcessSystem
Organization
Info.
TaskView
Role
Modeling Constructs
• Relationships over objects• Instances over classes• Templates over classes• Properties over types
• Metadata is data• My metadata can be your data
Too High Level: Holistic Relationships
Service orientation
Interoperability
Security
Scalability
Flexibility
Availability
Openness
Too Low-Level: Linear Relationships
3D layout of Riser area Riser
3D layout of R152
3D layout of R153 Area R153Area R152
Pipe 21-152-P001
Pipe 73-152-P011
3D layout of 21-152-P001
3D layout of 73-152-P011
Multiple Viewpoints on Products
Requirements
Assembly modules
Systems
Configurable components
Technical constraints
PropertiesParametersValue sets
Geometry
Legal constraints
Cost
Price
Markets Functions
Concepts
Environmental constraints
Health, Safety
Product Families
Product Lines
Materials
Form, Aesthetics
Parts
Plant
Competitors
Lifecycle maintenance
Customers
Business
Technology
Soc
iety
, G
over
nmen
t
Instances over Classes
Semantic holism - the meaning of any model element may depend on any other element
Conduct
• Be open, humble, and willing to expose your mistakes
• Take charge, set directions
• Don't just listen to management
• Discuss purpose, scope and level of ambition throughout the
architecture’s lifecycle
• An architecture that is not actively used will die. Motivating
stakeholders to participate, is an ongoing challenge.
Design time modelling
Runtime execution
Programming platform
SOA platform
Business process management system
EM platform
Code
Web services
Custom applications
& COTS
Enterprisemodel
Businessprocess model
Platform specificmodel
Model-driven applications
BPM development
MDA development
Model-Driven Applications
Towards Model-Driven Applications
• Business process management (BPM) becomes more user-oriented, cf. BPEL4People, case management
• Service oriented architectures (SOA) enable application composition, component reuse and new business models• Increased focus on visual user interaction, cf. XAML, Web 2.0• Semantics of content
• Model-driven architectures (MDA) for software development • Becoming more agile, focus on requirements analysis
• Enterprise architectures (EA) and ITIL for IT planning, management, cost cutting, alignment etc.• Putting business in charge of IT, towards actionable architectures
• Still dominated by computer-oriented modeling languages, rather than user-oriented, industrial domain languages• Lack integrating methodologies for executable enterprise models
activeknowledgemodeling.com
• 12 different ways to model business processes• Flexible BPM: From case management to active project execution• BPM for knowledge-intensive processes• How product models determine business process models
• What is active knowledge modeling?• Methodologies for active knowledge architectures
• Why data modeling is the wrong tool for integrating data models• A knowledge architecture methodology for integrating data models
• Investigation of Microsoft Oslo – from Intellipad to the repository to Visio• Microsoft Oslo Quadrant – first impressions
• The future of product design and life-cycle management?• Property modeling – the blind spot of object orientation
Recommended
