+ All Categories
Home > Documents > Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA,...

Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA,...

Date post: 31-Mar-2015
Category:
Upload: alexis-watler
View: 212 times
Download: 0 times
Share this document with a friend
43
Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst [email protected] 1
Transcript
Page 1: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Using TOGAF as a pragmatic approach to architecture

15 april 2009Jaarbeurs, UtrechtKIVI NIRIA, afd. Informatica

Danny Greefhorst

[email protected]

1

Page 2: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Contents

• Introducing ArchiXL• Introducing architecture • Introducing TOGAF• Principles for pragmatic architecture• Essential TOGAF viewpoints

2

Page 3: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

ArchiXL

• IT-architecture consulting firm, founded in 2008

• Based in Amersfoort, the Netherlands

• Focus on financial and public sector

• Knowledge areas:– IT architecture (BPM,

EAI/SOA, ECM, IDM, BI, Portals)

– Enterprise architecture methods and techniques (TOGAF, ArchiMate)

– Sector knowledge (insurance, municipalities, education)

3

Page 4: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

What is architecture?

“The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution”

IEEE 1471

4

Page 5: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Why practice architecture?

• Architecture helps in optimising the service portfolio of an organisation, aligning IT supply to business demand

• Architecture contributes to a healthy project portfolio, ensuring that projects that contibute most to the long term vision will be realised

• Architecture improves the quality of individual solutions, simplifying their development and maintenance en prolonging their life time

5

Page 6: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

What does an organisation without architecture look like?

6

Down-loadfile

Down-loadfile

Down-loadfile

Screenscrape

Screenscrape

Browser

HTTP/XML

Trans-action

file

Trans-action

file

Trans-action

file

Trans-action

file

Messagequeue

Messagequeue

Messagequeue

FTP

Sockets

E-mail

Message

XML/HTTP

Gateway RPC

CICS gateway

APPC

SMTP

CICS gateway

ORB

Applications From Mergers and Acquisitions

Legacy Applications

Purchased Packages

Applications in Trading Partners

E-Marketplaces

End-User Development

Autonomous Divisions

Outsourced and ASP Applications

Page 7: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Architecture fundamentals

Slide 7

Page 8: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Slide 8

The origin: Zachman framework

DATA Implementation

DATAWhat

FUNCTIONHow

NETWORKWhere

e.g. Data Definition

Entity = FieldRel. = Address

e.g., Physical Data Model

Entity = Tables/Segments/etc.Rel. = Key/Pointer/etc.

e.g., Logical Data Model

Entity = Data EntityRel. = Data Relationship

e.g., Semantic Model

Entity = Business EntityRel. = Business Relationship

List of Things - Important to the Business

Entity = Class ofBusiness Thing

List of Processes -the Business Performs

Function = Class ofBusiness Process

e.g., Application Architecture

Process.= Application FunctionI/O = User Views

e.g., System Design

Process= Computer FunctionI/O =Data Elements/Sets

e.g. Program

Process= Language StatementI/O = Control Block

FUNCTIONImplementation

e.g., Business Process Model

Process = Business ProcessI/O = Business Resources

List of Locations -in which the Business Operates

Node = Major BusinessLocation

e.g., Logistics Network

Node = Business Location Link = Business Linkage

e.g., Distributed System Architecture

Node = IS FunctionLink = Line Characteristics

e.g., Technical Architecture

Node = Hardware/System SoftwareLink = Line Specifications

e.g. Network Architecture

Node = AddressesLink = Protocols

NETWORKImplementation

MOTIVATIONWhy

TIMEWhen

PEOPLEWho

e.g. Rule Specification

End = Sub-conditionMeans = Step

e.g., Rule Design

End = ConditionMeans = Action

e.g., Business Rule Model

End = Structural AssertionMeans =Action Assertion

End = Business ObjectiveMeans = Business Strategy

List of Business Goals and Strategies

Ends/Means=Major BusinessGoal/Critical Success Factor

List of Events -Significant to the Business

Time = Major Business Event

e.g., Processing Structure

Time = System EventCycle = Processing Cycle

e.g., Control Structure

Time = ExecuteCycle = Component Cycle

e.g. Timing Definition

Time = InterruptCycle = Machine Cycle

SCHEDULEImplementation

e.g., Master Schedule

Time = Business EventCycle = Business Cycle

List of Organizations -Important to the Business

People = Class of People andMajor Organizations

e.g., Work Flow Model

People = Organization UnitWork = Work Product

e.g., Human Interface Architecture

People = RoleWork = Deliverable

e.g., Presentation Architecture

People = UserWork = Screen/Device Format

e.g. Security Architecture

People = IdentityWork = Job

ORGANIZATIONImplementation

STRATEGYImplementation

e.g., Business Plan

SCOPEPlanner

SYSTEM MODELDesigner

TECHNOLOGYCONSTRAINED

MODELBuilder

DETAILEDREPRESEN-

TATIONSSubcontractor

ENTERPRISE MODEL

Owner

contextual

conceptual

logical

physical

out-of-context

FUNCTIONINGENTERPRISE

perspectives

abstractions

Page 9: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

ArchiMate

Business

Application

Technology

Passieve structuur Gedrag Actieve structuur

DeviceSystem software

Infrastructure service

Artifact Network

Infrastructureinterface

Applicationcomponent

Application function

Application service

Dataobject

Application interface

Business actor

Businessrole

Business process

Business service

Business object

Event

Represen-tation

Businessinteraction

Businesscollaboration

9

Page 10: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

TOGAF Overview

Slide 10

PART I: Introduction

PART II: Architecture Development Method

PART III: ADM Guidelines and Techniques

PART IV: Architecture Content Framework

PART V: Enterprise Continuum & Tools

PART VI: TOGAF Reference Models

PART VII: Architecture Capability Framework

Page 11: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

What’s new in TOGAF 9?

• Modular Structure - The specification content is structured in a modular way, which allows for the concepts in each part to be developed with limited impacts on other parts.

• Content Framework - Provides a detailed model of architectural work products, including deliverables, artifacts within deliverables, and the architectural building blocks that artifacts represent.

• Extended Guidance on Adopting TOGAF within an Enterprise - An extended set of concepts and guidelines to support the establishment of an integrated hierarchy of architectures

• ADM Guidelines & Techniques - Show in more detail how the ADM can be applied to specific situations.

• Additional ADM Detail - More detailed information supporting the execution of the ADM.

• TOGAF Document Categorization Model - Structures the release management of the TOGAF specification.

– .

Page 12: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Architecture Development Method

12

Page 13: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Classes of Enterprise Architecture Engagement

Slide 13

Page 14: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Business Transformation Readiness Assessment

Steps

• Determine the readiness factors that will impact the organization

• Present the readiness factors using maturity models

• Assess the readiness factors, including determination of readiness factor ratings

• Assess the risks for each readiness factor and identify improvement actions to mitigate the risk

• Work these actions into Phase E and F Implementation and Migration Plan

Factors• Vision • Desire, Willingness, and Resolve • Need• Business Case • Funding• Sponsorship and Leadership • Governance • Accountability • Workable Approach and Execution

Model • IT Capacity to Execute• Enterprise Capacity to Execute• Enterprise Ability to Implement

and Operate

Slide 14

Page 15: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Capability-Based Planning

Slide 15

Page 16: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Content framework

Slide 16

Page 17: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Building blocks

17

Page 18: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

18

Artefacts

• Preliminary– Principles Catalog

• Architecture Vision– Stakeholder Map Matrix– Value Chain Diagram– Solution Concept Diagram

• Business Architecture– Organization/Actor Catalog– Role Catalog– Business Service/Function Catalog– Business Interaction Matrix– Actor/Role Matrix– Business Footpr int Diagram– Business Service/Infor mation Diagram– Functional Decomposition Diagram– Product Lifecycle Diagram

• Data Architecture – Data Entity/Data Component Catalog– Data Entity/Business Function Matrix– System/Data Matrix– Class Diagram– Data Dissemination Diagram

• Application Architecture– Application Portfolio Catalog– Interface Catalog– System/Organization Matrix– Role/System Matrix– System/Function Matrix– Application Interaction Matrix– Application Communication Diagram– Application and User Location Diagram– System Use-Case Diagram

• Technology Architecture – Technology Standards Catalog– Technology Por tfolio Catalog– System/Technology Matrix– Environments and Locations Diagram– Platform Decomposition Diagram

• Opportunities and Solutions – Project Context Diagram– Benefits Diagram

• Requirements Management – Requirements Catalog

Page 19: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Slide 19

Deliverables

• Architecture Building Blocks• Architecture Contract• Architecture Definition Document• Architecture Principles• Architecture Repository• Architecture Requirements• Architecture Roadmap• Architecture Vision• Business Principles, Business

Preliminary Goals, and Business Drivers

• Capability Assessment• Change Request

• Communications Plan• Compliance Assessment• Implementation and Migration

Plan• Implementation Governance

Model• Organizational Model for

Enterprise Architecture• Request for Architecture Work• Requirements Impact Assessment• Solution Building Blocks• Statement of Architecture Work• Tailored Architecture Framework• Transition Architecture

Page 20: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Enterprise continuum

20

Page 21: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Reference architecture classification

21

Page 22: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Organisation architecture classification

22

Page 23: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

TOGAF 9 Certification

• TOGAF 9 Foundation (level 1)– To provide validation that the Candidate has gained knowledge of the

terminology, structure, and basic concepts of TOGAF 9, and understands the core principles of Enterprise Architecture and TOGAF. The learning objectives at this level focus on knowledge and comprehension.

• TOGAF 9 Certified (level 2) – To provide validation that in addition to the knowledge and comprehension

of TOGAF 9 Foundation, the Candidate is able to analyze and apply this knowledge. The learning objectives at this level therefore focus on application and analysis in addition to knowledge and comprehension.

• Bridge from TOGAF 8 to TOGAF 9 Certified– To enable individuals who are TOGAF 8 Certified to obtain TOGAF 9

Certified (level 2) certification. The bridging option exists to recognize the existing investment in TOGAF certification for individuals who have achieved the TOGAF 8 Certified qualification.

23

Page 24: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Principles for pragmatic architecture

• Use of open standards• Reusing best-practices• Iterative approach • Concrete and usable results• Responsibility for result• Close interaction with stakeholders• “just-enough” architecture• Focus on knowledge, not on rule enforcement

24

Page 25: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Use of open standards

25

TOGAF ArchiMate

Key message: standards are a good starting point, but use them wiselyKey message: standards are a good starting point, but use them wisely

Tip: use formalised models for architects and engineers, use simple powerpoint models for management and users

Tip: use formalised models for architects and engineers, use simple powerpoint models for management and users

Page 26: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Reusing best practices

26

Key message: reuse reference architectures in the market, and make your ownKey message: reuse reference architectures in the market, and make your own

Tip: separate your architecture into an organisation-specific an a generic part; the latter can be stored in the reference library

Tip: separate your architecture into an organisation-specific an a generic part; the latter can be stored in the reference library

Page 27: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Iterative approach

27

Key message: deliver fast, deliver often and make sure every delivery provides added valueKey message: deliver fast, deliver often and make sure every delivery provides added value

Tip: make a plan for defining your architecture with clear milestones and a deadline

Tip: make a plan for defining your architecture with clear milestones and a deadline

Page 28: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Concrete and usable results

28

Key message: be clear on what you deliver, and focus on the goals and requirementsKey message: be clear on what you deliver, and focus on the goals and requirements

Tip: show your sponsor examples of previous architecture deliverables to let him understand what he will get

Tip: show your sponsor examples of previous architecture deliverables to let him understand what he will get

Page 29: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Responsibility for result

29

The Lead Enterprise Architect is responsible for ensuring that the architecture is technically coherent and future-proof.The Lead Enterprise Architect is responsible for ensuring that the architecture is technically coherent and future-proof.

Key message: do not run away after creating the architecture, guide the implementationKey message: do not run away after creating the architecture, guide the implementation

Tip: plan your involvement in the implementation for at least one day in the week

Tip: plan your involvement in the implementation for at least one day in the week

Page 30: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Close interaction with stakeholders

30

Key message: talk to all key stakeholders, bring them together in workshops to get consensusKey message: talk to all key stakeholders, bring them together in workshops to get consensus

Tip: reserve time with the people that have the knowledge; they can provide you with the information you really needTip: reserve time with the people that have the knowledge; they can provide you with the information you really need

Tip: don’t forget to have your architecture reviewed by other architects

Tip: don’t forget to have your architecture reviewed by other architects

Page 31: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

“just-enough” architecture

31

Key message: do not overdeliver; focus on the 20% artefacts that deliver 80% of the valueKey message: do not overdeliver; focus on the 20% artefacts that deliver 80% of the value

Tip: first deliver a high-level architecture with only the goals, guiding architecture principles, high-level diagrams, and major changes

Tip: first deliver a high-level architecture with only the goals, guiding architecture principles, high-level diagrams, and major changes

Tip: deliver more detailed architectures for specific themes that require business attention

Tip: deliver more detailed architectures for specific themes that require business attention

Page 32: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Focus on knowledge, not on rule enforcement

32

Key message: architects provide value through skills and knowledge, but they don’t know everythingKey message: architects provide value through skills and knowledge, but they don’t know everything

Tip: look at the intent of principles and guidelines and not so much at their formulation

Tip: look at the intent of principles and guidelines and not so much at their formulation

Tip: deviating from principles and guidelines can be justified if there is a really good motivation

Tip: deviating from principles and guidelines can be justified if there is a really good motivation

Page 33: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Where is the essence?

33

Page 34: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Principle: corporate information is stored only once and retrieved from the source when needed

Motivation• Duplication of information

leads to inconsistencies• Inconsistencies lead to errors

in business processes and/or additional effort in reconciling these inconsistencies

Implications• Information that is needed

throughout the enterprise is stored in a single information providing application

• Information providing applications expose their information through a number of generic application services

• Information providing applications are high available (>99,9%)

34

Tip: interactively define architecture principles with the stakeholders using powerpointTip: interactively define architecture principles with the stakeholders using powerpoint

Tip: reuse existing architecture principles in TOGAF and reference architecturesTip: reuse existing architecture principles in TOGAF and reference architectures

Page 35: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Functional decomposition diagram (business functions)

35

Primary business functions

MaintainProviderRelations

MaintainCustomerRelations

Sales Claims Handling

AssetManegement

FinancialHandling

Secondary business functions

IT Development& Management

HumanResource

Management

FacilityManagement

FinancialManagement Communications

Controlling business functions

Strategic Control EnterpriseArchitecture

QualityManagement

InternalReporting

ProductDevelopment Marketing

ExternalReporting

MaintainIntermediary

Relations

Legal Procurement

PolicyAdministration

BusinessImprovement

Page 36: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

System/function matrix

36

Primary business functions

MaintainProviderRelations

MaintainCustomerRelations

Sales Claims Handling

AssetManagement

FinancialHandling

ProductDevelopment

Marketing

MaintainIntermediary

Relations

PolicyAdministration

CustomerPortal

B2BPortal

B2BPortal

Call CenterDesktop

Sales ProcessSupport

Party InformationManagement

Party InformationManagement

Party InformationManagement

ContactAdministration

ContractAdministration

IntegratedCustomer View

P & C PolicyAdministration

Health PolicyAdministration

Life PolicyAdministration

DataWarehouse

BusinessIntelligence &

Reporting

AssetManagement

P & C ClaimsHandling

Health ClaimsHandling

Life ClaimsHandling

FinancialAdministration

Page 37: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Primary business functions

MaintainProviderRelations

MaintainCustomerRelations

Sales Claims Handling

AssetManegement

FinancialHandling

Secondary business functions

IT Development& Management

HumanResource

Management

FacilityManagement

FinancialManagement Communications

Controlling business functions

Strategic Control EnterpriseArchitecture

QualityManagement

InternalReporting

ProductDevelopment Marketing

ExternalReporting

MaintainIntermediary

Relations

Legal Procurement

PolicyAdministration

BusinessImprovement

Impact of drivers/goals/objectives on business functions

37

Impact of new customer group:1.Introduce new products for that group2.Change marketing approach3.Change sales process for new customer group and new products4.Change policy administration for new products

Impact of new customer group:1.Introduce new products for that group2.Change marketing approach3.Change sales process for new customer group and new products4.Change policy administration for new products

11

Tip: determine impact of drivers/goals/objectives on high-level business, application and technology views

Tip: determine impact of drivers/goals/objectives on high-level business, application and technology views

22 33 44

Page 38: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Value chain diagram (roles and information flows)

Insurer

Customer/Intermediary

Customer/Intermediary

Damage Expert

Damage Repair

Car RegistrationCenter

IndemnificationFoundation

Legal ReportCenter

Insurance FraudRegistration

CentralBank

Bank

Request for information,policy acceptance, policy changes

Product information, policy, invoice

Claim

Claim rejection, claim acceptance

Damage assessment order

Damage report

Repair order

Invoice

Car information request

Car information

Request for indemnification

Indemnification approval or rejection

Request for legal report

Legal report

Request information, report fraud

Fraud information

Indemnation payments,premium collections

Account statements

Regulatory report

Page 39: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Application portfolio catalog (application components)

39

Channels Front Office

Party InformationManagement

Back Office

ContractAdministration

P & C PolicyAdministration

Health PolicyAdministration

Life PolicyAdministration

Call CenterDesktop

CustomerPortal

IntegratedCustomer View

Interactive VoiceRecognition

Sales ProcessSupport

ElectronicArchive

InputManagement

ContactAdministration

OutputManagement

Supporting

PersonnelAdministration

FinancialAdministration

ProjectManagement

TimeRegistration

Data Warehouse

B2BPortal

Multi ChannelRouting

E-mailManagement

AssetManagement

BusinessIntelligence &

Reporting

P & C ClaimsHandling

Health ClaimsHandling

Life ClaimsHandling

FacilityAdministration E-mail

Page 40: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Channels Front Office

PartyInformation

Management

Back Office

ContractAdministration

P & C PolicyAdministration

Health PolicyAdministration

Life PolicyAdministration

Call CenterDesktop

CustomerPortal

IntegratedCustomer

View

InteractiveVoice

Recognition

Sales ProcessSupport

ElectronicArchive

InputManagement

ContactAdministration

OutputManagement

Supporting

PersonnelAdministration

FinancialAdministration

ProjectManagement

TimeRegistration

DataWarehouse

B2BPortal

Multi ChannelRouting

E-mailManagement

AssetManagement

BusinessIntelligence &Reporting

P & C ClaimsHandling

Health ClaimsHandling

Life ClaimsHandling

FacilityAdministration E-mail

Issues in application portfolio

40

1. Security in customer portal is not in line with security policy

2. Prolonging of policies does not fit into batch window

3. Integrated customer view does not include life information

4. Maintenance costs of personnel administration are too high

1. Security in customer portal is not in line with security policy

2. Prolonging of policies does not fit into batch window

3. Integrated customer view does not include life information

4. Maintenance costs of personnel administration are too high

11

33

22

44

Tip: plot issues on high-level business, application and technology viewsTip: plot issues on high-level business, application and technology views

Page 41: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Application communication diagram

41

Party InformationManagement

P & C PolicyAdministration

CustomerPortal

ContactAdministration

OutputManagement

P & C ClaimsHandling

claim

contact

policy

claim

FinancialAdministration

financial transaction

Customer/Intermediary

Bank

financial transaction

indemnification

ElectronicArchive

document

Customer/Intermediary

indemnification

customer

CentralBankregulatory

report

Data Warehouse

BusinessIntelligence &

Reporting

financial transaction

financial transactions

contact

Tip: draw application communication diagrams for specific change areasTip: draw application communication diagrams for specific change areas

Page 42: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Communication

Operating System

CollaborationOffice Productivity

Business Process Management Content Management

Data Interchange

User Interface

Transaction Processing Data Management

System and Network Management Security Software Engineering

Technology standards catalog (system software)

Microsoft Windows Server

Microsoft Office Sharepoint Server

Microsoft Office Microsoft Exchange

K2.NET

Microsoft BizTalk Server

Microsoft Office Sharepoint Server

Kofax Ascent Capture

Microsoft .NET Microsoft BizTalk Server

Microsoft MSMQ

Microsoft SQL Server

Microsoft Search Server

Microsoft System Center

Microsoft Office Sharepoint Server

Microsoft Office Communications Server

Microsoft Windows Live Messenger

Microsoft Commerce Server

Microsoft Active Directory

Adobe Reader

Microsoft ISA Server

Microsoft Visual Studio

Microsoft Windows Vista

Oracle Workflow

Oracle DB

Oracle Developer

Oracle Application Server Oracle Advanced Queueing

Oracle Portal

Oracle Grid Control

Oracle Internet Directory

Page 43: Using TOGAF as a pragmatic approach to architecture 15 april 2009 Jaarbeurs, Utrecht KIVI NIRIA, afd. Informatica Danny Greefhorst dgreefhorst@archixl.nl.

Questions


Recommended