Enterprise Modeling – What We Have Learned , and What We Have Not

1. Enterprise Modeling – WhatWe Have Learned, and WhatWe Have Not Håvard D. Jørgensen havard.jorgensen@commitment.no

2. Background Software Engineering Visualization BusinessProcess Management Collaboration Knowledge Management Model-DrivenApplications EnterpriseArchitecture Product design Interoperability DomainSpecificMetamodels

3. Enterprise modeling • Complex problems • Multiple views • Uncertainty • Fuzzy, incomplete understanding • Ambiguous • Modelers like • Structure • Agreement • Certainty • Clarity • Precision

4. Bias towards Agreement Agreeaboutthe full picture EnterpriseArchitecture Objectives Functions Agreeaboutthedetails Components Standards Agreement by abstraction Agreement by concretization

5. Enterprise ModelContent Freedom to innovate Contextual Continuously evolving Individual Team Bottom up Well-structured Project design Complex connectivity, multi-facetted structures Middle-out Project standards Company standards Top down Well-structured Discipline standards Same precise meaning everywhere Management control Reasonably stable Industry standards

6. Focusof 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 Bewareof bias towardsthetangible

7. 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

8. Analysis - Where and How to Start? Simple, concrete Whitespace No links Intensionallyvaguestructure Flexible

9. RelationshipsOftenReflectProcesses Send Receive Application Presentation Session Transport Network Data link Physical

11. Boundaries, Relationsips, Roles Project Company Workpackage Department Group Task Person Person Task

12. Multiple Views – Two Model Elements Whattheyrefer to Whattheysayaboutthem

13. Beware of hierarchies, they are often local to a viewpoint and not shared by everyone Process Yard HSE Mech-anics Safety class System FabricationUnit Telecom and control system Procurementclass Instru- mentation Equipment Piping Area Procurement package Procure-ment Maintenance class Material class Structure stress system Planning Materialstechnology Support Operations

14. 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

15. Business ProcessModeling

16. 21PA001A Crude Oil Booster Pump ProductDependenciesCauseProcessDependencies • Equipment and instruments • Modelled in 3D • General arrangement drawing from supplier • Process datasheet • Pipe area line • 3D Layout Area line number 21-1001-R152 16” Ball valve BL030 • Process line (input) • System engineering • Pipe dimension, material, insulation etc. PS-R152-0029 • Pipe supports • Connecting to structure elements PS-R152-0010

17. Products over Processes Product Process Process Process systems engineering Org. Procurement data sheets from supplier System Process Line Instru-ment Procure-ment Procurement package Mech-anics Area Area Line Equip-ment Procurement GA drawing from supplier Pipe Support Structure Element 3D layout modeling - piping Planning Manufacturing & assembly Piping Yard 3D layout modeling - support Iso stress analysis Support

18. ProcessHierarchy – Work Breakdown Time Organization Process Product Information, documents

19. Beware of matrices and streamlined frameworks, often you need to “break the system”

20. Don't let the language be a straight-jacket Step 1 Step 2 Step 3 Company Depart-ment 1 Depart-ment 2 Processmodel in UML Organization model in UML

21. 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

22. WeavingAspectsTogether Process structure Product structure Task Organizational structure System Infrastructure

23. Layers Product Organization Info. Role View Task System Process

24. ModelingConstructs • Relationships over objects • Instancesover classes • Templates over classes • Properties over types • Metadata is data • My metadatacan be your data

25. TooHighLevel: HolisticRelationships Service orientation Interoperability Openness Security Flexibility Scalability Availability

26. TooLow-Level: Linear Relationships 3D layoutof Riser area Riser 3D layoutof R153 3D layoutof R152 Area R152 Area R153 3D layoutof21-152-P001 Pipe 21-152-P001 3D layoutof73-152-P011 Pipe 73-152-P011

27. Multiple ViewpointsonProducts Customers Competitors Form, Aesthetics Requirements Product Families Markets Functions Business Society, Government Legal constraints Price Properties Parameters Valuesets Concepts Health, Safety Cost Materials Environmental constraints Parts Lifecycle maintenance Configurable components Geometry Systems Plant Technical constraints Assembly modules Product Lines Technology

28. Instances over Classes • Semanticholism - themeaningofanymodel element maydependonanyother element

29. 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.

30. Model-DrivenApplications MDA development BPM development Model-driven applications Enterprise model EM platform Business process model Business process management system Platform specific model Web services SOA platform Customapplications & COTS Code Programming platform Runtime execution Design time modelling

31. 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 • Semanticsofcontent • Model-driven architectures (MDA) for software development • Becoming more agile, focus onrequirementsanalysis • 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 integratingmethodologies for executable enterprise models

32. 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