LIACS, Martijn Wiering 23 juni 04

Size: px
Start display at page:

Download "LIACS, Martijn Wiering 23 juni 04"

Transcription

1 An Integrated Approach to Enterprise Architecture LIACS, Martijn Wiering 23 juni 04

2 Context Business and ICT become closer Ever higher demands on ICT: complexity, flexibility Many changes, rapid time-to-market required Management & control difficult Enterprise Architecture as a tool for communication for governance 2

3 ICT Business 3

4 Architecture Architecture = structure(s) of a system in terms of components, their externally visible properties, their relations, and the underlying principles 4

5 What good are architectures? Provide the overview: the most important functions, the most important domains, etc. A means of communication between various stakeholders (architects, managers, customers, engineers, ) A starting point for more detailed designs No description of implementation! Correctness & completeness 5

6 Governance with architecture Architecture is a strategic tool not just high-level design Architecture goes beyond ICT: enterprise architecture Stability & flexibility Seem to be contradictory, but a good architecture facilitates changes! It s no blue-print that will hold forever. Communication with stakeholders architects, managers, customers, engineers Analysis impact-of-change cost & performance 6

7 Enterprise architecture: describing coherence Information architecture? Process architecture Product architecture?? Application architecture?? Technical architecture 7

8 Frameworks Zachman ENTERPRISE ARCHITECTURE - A FRAMEWORK DATA What FUNCTION How NETWORK Where PEOPLE Who When MOTIVATION Why TIME TM Nolan Norton SCOPE (CONTEXTUAL) List of Things Important to the Business List of Processes the Business Performs List of Locations in which the Business Operates List of Organizations Important to the Business List of Events Significant to the Business List of Business Goals/Strat SCOPE (CONTEXTUAL) Planner ENTITY = Class of Business Thing Function = Class of Business Process Node = Major Business Location People = Major Organizations Time = Major Business Event Ends/Means=Major Bus. Goal/ Critical Success Factor Planner TOGAF ENTERPRISE MODEL (CONCEPTUAL) Owner e.g. Semantic Model Ent = Business Entity Reln = Business Relationship e.g. Business Process Model Proc. = Business Process I/O = Business Resources e.g. Logistics Network Node = Business Location Link = Business Linkage e.g. Work Flow Model People = Organization Unit Work = Work Product e.g. Master Schedule Time = Business Event Cycle = Business Cycle e.g. Business Plan End = Business Objective Means = Business Strategy ENTERPRISE MODEL (CONCEPTUAL) Owner Tapscott SYSTEM MODEL (LOGICAL) Designer TECHNOLOGY MODEL (PHYSICAL) Builder DETAILED REPRESEN- TATIONS (OUT-OF- CONTEXT) Sub- Contractor FUNCTIONING ENTERPRISE e.g. Logical Data Model Ent = Data Entity Reln = Data Relationship e.g. Physical Data Model Ent = Segment/Table/etc. Reln = Pointer/Key/etc. e.g. Data Definition Ent = Field Reln = Address e.g. DATA e.g. "Application Architecture" Proc.= Application Function I/O = User Views e.g. "System Design" Proc.= Computer Function I/O = Screen/Device Formats e.g. "Program" Proc.= Language Stmt I/O = Control Block e.g. FUNCTION e.g. "Distributed System Architecture" Node = I/S Function (Processor, Storage, etc) Link = Line Characteristics e.g. "System Architecture" Node = Hardware/System Software Link = Line Specifications e.g. "Network Architecture" Node = Addresses Link = Protocols e.g. NETWORK Zachman Institute for Framework Advancement - (810) e.g. Human Interface People = Role Work = Deliverable e.g. Presentation Architecture People = User Work = Screen Format e.g. Security Architecture People = Identity Work = Job Architecture e.g. ORGANIZATION e.g. Processing Structure Time = System Event Cycle = Processing Cycle e.g. Control Structure Time = Execute Cycle = Component Cycle e.g. Timing Definition Time = Interrupt Cycle = Machine Cycle e.g. SCHEDULE e.g., Business Rule Model End = Structural Assertion Means =Action Assertion e.g. Rule Design End = Condition Means = Action e.g. Rule Specification End = Sub-condition Means = Step e.g. STRATEGY SYSTEM MODEL (LOGICAL) Designer TECHNOLOGY CONSTRAINED MODEL (PHYSICAL) Builder DETAILED REPRESEN- TATIONS (OUT-OF CONTEXT) Sub- Contractor FUNCTIONING ENTERPRISE Copyright - John A. Zachman, Zachman International 8

9 Methods Information planning Information engineering (James Martin) Rational Unified Process TOGAF services standards & rules resources & aids DYA 9 infrastructure

10 Modelling languages (I) Data models (ER diagrams) Business process models(bpml) UML Design diagrams Process diagrams Use case diagrams Component diagrams Deployment diagrams 10

11 Shortcomings Each approach or tool addresses only one or a few aspect architectures Tools lack semantics Consistency has to be checked manually Analysis of architectures is difficult or impossible 11

12 Experiences Internal inconsistencies at the model level at the concept level at the instance level Processes and functions not well separated Tension between different architecture methods Many relations between models, hard to determine Document and version management difficult 12

13 Overview ArchiMate. The ArchiMate metamodel. Mapping to UML. The ArchiSurance Case. 13

14 ArchiMate What is ArchiMate? A Research initiative that aims to provide concepts and techniques to support enterprise architects in the visualization, analysis and communication of integrated enterprise architectures. Idea: Use enterprise architecture (business & ICT) as a basis for stability in changing organizations. Should give a better insight in the dependencies and correspondences between company domains and the impact of making changes in one of the domains. 14

15 The ArchiMate Project 2½ years, July December 2004 approx. 35 man-years, 4 million euro Consortium of companies and knowledge institutes Telematica Instituut leads the project Ideas also originated from Ordina ABN AMRO, Belastingdienst, ABP KU Nijmegen, CWI, Universiteit Leiden 15

16 Goals To describe architectures and their relations Communicate enterprise architectures with all stakeholders Judge the impact of changes Realise architecture by relating to existing standards, techniques and tools 16

17 The ArchiMate language High-level modelling within a domain ArchiMate language Basis for visualisations Modelling relations between domains Basis for analyses 17

18 more generic more specific Abstraction levels Object Relation Generic concepts Application Process Enterprise architecture concepts Company-specific concepts, standards 18

19 Scope Views & visualisation Analysis 19 Integrated architecture descriptions

20 Integration An architecture might encompass for example: products organisation business processes applications systems This requires concepts for domains and relations, linked with existing techniques 20

21 Integrated Architecture Roles and actors Client Insurant ArchiSurance Insurer External business services Claim registration service Damage claiming process Registration Customer information service Acceptance Valuation Claims payment service Payment Services as central notion for linking business & IT, but also business & External application services environment Claims administration service Customer administration service Risk assessment service Payment service Services do not exist in UML Application components and services Customer administration Risk assessment 21 Claims administration Claim files service Financial system

22 Integration of Languages b Roles and actors c Client Insurant ArchiSurance Insurer a External business services Process 1 Claim registration service Customer information service Claims payment service Testbed Damage claiming process Registration Acceptance Valuation Payment UML External application services UML Claims administration service Customer administration service Application components and services Risk assessment service Payment service Customer administration Risk assessment Claims administration Claim files service Financial system 22 ArchiMate architecture model relates to other models

23 Visualisation Architecture in the eyes of the manager the engineer the customer This requires techniques to create views on architectures for different stakeholders 23

24 Analysis I want to introduce a new product, what does that mean? for our business processes for our security for our workforce This requires techniques for analysis of interrelated architectures 24

25 Overview ArchiMate. The ArchiMate metamodel. Mapping to UML. The ArchiSurance Case. 25

26 The ArchiMate metamodel Product Value Contract Organisational service Organisational interface Event Business object Business process/function Role Actor Business Application Objects Application service Application interface Components/Resources Data object Application function Application component Application Infrastructure Representation Infrastructure service Infrastructure interface Behavior Artifact Node Communication path System software Device Network 26

27 Overview ArchiMate. The ArchiMate metamodel. Mapping to UML. The ArchiSurance Case. 27

28 Introduction Detail of UML makes UML difficult to understand for business managers and other persons involved with business architecture. ArchiMate keeps diagrams global instead of detailed, like UML. ArchiMate builds on existing standards (UML). Examples taken from a case, displaying mapping of ArchiMate to UML. 28

29 ArchiMate to UML Focus only on the domain integration ArchiMate interesting since it: Gives relations and consistency between diagrams. Makes UML accessibly to less experienced users by applying a simplification to UML. Mapping to UML (2.0) makes it possible to map ArchiMate models to UML models. In the future, use UML tools to verify models. Domain integration makes it possible to verify models concerning different domains. 29

30 Overview ArchiMate. The ArchiMate metamodel. Mapping to UML. The ArchiSurance Case. 30

31 The ArchiSurance Case A Business Case, concerning an Insurance Company with a Intermediary and a Customer. Here restricted to four operations. Used to verify and explain ArchiMate. Three models from the case will be discussed: Business Structure, Business Process and Application Structure. 31

32 ArchiSurance business structure intermediary Collaboration Class Class negotiation premium collection contracting Role customer insurance company claim handling 32

33 Business Structure, Class diagram 33

34 ArchiSurance Business Process Interaction formal request Class policy (contract) Sequence Event Diagram Object request for insurance investigate formalize request create contract check contract sign contract register policy Process Activity or Sequence diagram customer negotiation insurance company contracting 34 Class Class + Collaboration

35 Business Process, Interaction Overview Diagram 35

36 Business Process, Interaction Overview Diagram 36

37 ArchiSurance Application structure print contracts view requests create & edit policies view policies print bills PrintWise ArchiSure Operation Service Collaboration printing Actor Class or Role Interface Class 37

38 Application Structure, class diagram 38

39 39 Questions?