viewpoint-based metabased meta model engggineering

Viewpoint based MetaViewpoint-based MetaModel Engineeringg gEMISA 2007October 8 - 9, 2007 - St. Goar / Rhine, Germany

Stephan KurpjuweitI it t f I f ti M t

, , y

Insitute of Information ManagementUniversity of St. [email protected] iwi unisg chwww.iwi.unisg.ch

Research Context

Approach:ppMethod Engineering

StrategyScope: Work Systems

Organization

Work SystemsEngineering

Software

Integration

© Oct-07 IWI-HSG, Stephan Kurpjuweit Slide 2

IT-Infrastructure

Project Context

Mid size financial service provider in Germanyp yGoal: Establish a specific meta model (+ tool implementation) for the organization’s EAM processesprocesses.

Approach: Iterative meta modelingApproach: Iterative meta modeling

Enterprise Architecture

Businessmodel

Applica-tions

Products /Services

model

Organizationalstructure

Informa-tion

Softwarecomponents


ServicesOrganizational goals

Success factorsPerformance indicatorsProcesses

Activities

A Systematic Approach to Meta Model EngineeringEngineering

List of Relevant

Process Steps

Documents

Concerns

Viewpoint 1 Viewpoint 2 Viewpoint n

Identification of Relevant Concerns

1

Viewpoint Requirements Specification 1


Viewpoint Requirements Specification n

…


Requirements Elicitation

2

Des

ign

idat

ion

Des

ign

idat

ion

Des

ign

idat

ion

Viewpoint Relationship DiagramViewpoint

Relationship Overview

3

Meta Model Fragment 1


Meta Model Fragment n

…

D

Vali D

Vali D

Vali

Meta Model Fragment

Selection or Design

4

Integrated

Design

Meta Model Fragment

5


Integrated Meta Model

Integration

Step 1: Identification of Relevant Concerns

Application ArchitectIT Audit

Cost of applicationd l t

P O

Correct implementation of ownership policies

development

Process Owner

EAProviding adequate IT for business

…IT for business processes

Software Architect

Cost of application operation and maintenance

Software Architect

IT Operations


14 stakeholder groups45 relevant requirements

Step 2: Requirements ElicitationWh ill th bj t b

In which situation (project types and context factors)?

Which stakeholder perspective will be taken?

Which concern will be modeled?

Why will the object be modeled? (1) documentation and communication, (2) analysis and explanation(3) design

Which parts of the work system will be modeled?

Object Purpose Concern Stakeholder Situation

factors)?taken?(3) design

1. Representation of the Object As-Is 2. Representation of the Object To-Be

How can the object as-is be modeled? (incl example models)

How can the object to-be be modeled? (incl example models)

3. Modelers and Information Sources 4. Model Users and Information Targets

(incl. example models) (incl. example models)

Who will interpret the models? How will the information be used?

Who will create the models? On the basis of which information sources?

5 Design Strategies 6 Compatible Approaches5. Design Strategies 6. Compatible Approaches

To which approaches, standards, and frameworks should the model be comaptible?

Which design decisions may impact the concern in a positive or a negative way?


Viewpoints Requirements Template (VRT)

Viewpoint IT Consolidation

Step 2: Requirements ElicitationViewpoint IT Consolidation Business IT Alignment Component Reuse OwnershipViewpoint IT Consolidation

Object Processes ,Applications

Purpose Analysis

Viewpoint IT Consolidation Business IT Alignment Component Reuse Ownership

Object Processes, Applications Processes, Applications Software Architecture IT-related Artifacts

Purpose Analysis Analysis Design Documentation

Concern Cost of application operation and maintenance

Stakeholder Application architect


Providing adequate IT for business processes

Cost of application development


Stakeholder Application architect Process owner Software architect IT auditStakeholder Application architect

DesignStrategies

Consolidation of applications that are in use for similar purposes / Consolidation of system software of the same

Stakeholder Application architect Process owner Software architect IT audit

DesignStrategies


Providing IT functionalitiesfor each process step / reduction of media breaks

Reuse of software components accross multiple applications / reuse of system softwrae (e.g,.

Assigning explicit owners to applications and other IT-related artefacts (like information objects,

type (e.g., DBMS, WFMS)

Questions Which applications are used in the individual processes (sorted by organizational

type (e.g., DBMS, WFMS) DBMS, WFMS) components, environments,etc.)


Which process activities are not IT supported? Which processes include media

Which components are available in existing applications? / Which

Are there applications for which np owners have been defined? Are there(sorted by organizational

unit, product, distribution channel)? / Which system software of the same type is currently in use?

(sorted by organizational unit, product, distribution channel)? / Which system software of the same type is currently in use?

processes include media breaks? / Which applications are supported by multiple applications?

applications? / Which interfactes are available to use these components? Which system software of different types is currently in use?

defined? Are there applications that have not been audited for more than two years?

Meta Model Fragment

use?

Meta Model Fragment

Step 3: Viewpoint Relationship Overview

Viewpoint Relationship Diagram

Viewpoint Relationship Diagram (Legend)


Viewpoint IT ConsolidationViewpoint IT Consolidation Business IT Alignment Component Reuse Ownership

Step 4: Meta Model Fragment Selection or DesignViewpoint IT Consolidation

Object Processes Applications

Purpose Analysis

Viewpoint IT Consolidation Business IT Alignment Component Reuse Ownership

Object Processes Applications Processes, Applications Software Architecture IT-related artifacts

Purpose Analysis Analysis Design Documentation


Stakeholder Application architect


Providing adequate IT for business processes

Cost of application development


Stakeholder Application architect Process owner Software architect IT auditStakeholder Application architect

DesignStrategies

Consolidation of applications that are in use for similar purposes / Consolidtaion of system software of the same

Stakeholder Application architect Process owner Software architect IT audit

DesignStrategies


Providing IT functionalitiesfor each process step / reduction of media breaks

Reuse of software components across multiple applications / reuse of system software (e.g,.

Assigning explicit owners to applications and other IT-related artefacts (like information objects,

tyepe (e.g., DBMS, WFMS)


type (e.g., DBMS, WFMS) DBMS, WFMS) components, environments,etc.)


Which process activities are not IT supported? Which processes include media

Which components are available in existing applications? / Which

Are there applications for which no owners have been defined? Are there(sorted by organizational

unit, product, distribution channel)? / Which system software of the same type is currenty in use?

(sorted by organizational unit, product, distribution channel)? / Which system software of the same type is currenty in use?

processes include media breaks? / Which applications are supported by multiple applications?

applications? / Which interfactes are available to use these components? Which system software of different types is currently in use?

defined? Are there applications that have not been audited for more than two years?

Meta Model Fragment

use?

Meta Model Fragment


Step 5: Meta Model Fragment Integration

Integration OperationsAdjusting Terminology

Product Distribution Channel

Creating generalizationsCreating specializationsAvoiding redundancies

Org. UnitProcess

specializationpart of

Site

part ofAvoiding redundanciesIntroducing interface modeling concepts

PersonApplication PositionBusiness

Information Object

Information Flow

part of

System Software

Data Entity Software Component Interface

Server

Application Environ-

ment

Complete Meta

User Interface

Business Logic

Data Container

Physical Server

Sever Cluster

Virtual Server

pModel (simplified)


N idescribed in

Extended Method Engineering Meta Model

Design ResultMeta Model

is part of

Conforms to

Notation

Meta Model Fragment

conforms tois part of

is part of predecessor /

Conforms to

produces / consumes

guides creation of

Design Strategy

expressed in

Viewpoint

is part of

applied in

Design ActivityRole Technique

is part ofsuccessor

participatesin

Concern

has

adresses

Stakeholderhas


Example Models

Environments,SoftwareArchitecture

IntegrationArchitecture

Environments, Platforms

Servers, Clusters, System Software


Virtual Serversy

Compliance Analysis

Are there applications for which no owners have been defined?

© Okt-07 IWI-HSG, Robert WinterSeite 13

Coverage AnalysisExample 1p

Which business processes are performed for the individual products?p



How are business processes supported by applications?



Which applications are used for the individual products along the process chain?p



How are the applications distributed across servers?


Contribution and Future Work

butio

n 1) Approach to meta model engineering

2) Extension to the method engineering meta modelProcess Documents

Con

trib List of Relevant

Concerns



Viewpoint Requirements Specification n

…




Meta Model Fragment n

…

Des

ign

Valid

atio

n

Des

ign

Valid

atio

n

Des

ign

Valid

atio

n

Viewpoint Relationship Diagram

Identification of Relevant Concerns

Requirements Elicitation

Viewpoint Relationship

Overview

Meta Model Fragment

Selection or Design

1

2

3

4

ProcessSteps

Documents

Design Activity

Design Result

Role Technique

Meta Model

Method Fragment

influences influences

is part of

is part of

predecessor / successor

is part of

Conforms to

participatesin

produces / consumes

guides creation of

Notation

Stakeholderhas

Concern

has

Design Strategy

adresses

Meta Model Fragment

expressed in

conforms to

described in

Viewpoint

is part of

is part of

applied in

Integrated Meta Model

Meta Model Fragment

Integration

5

Context Project Type

Situation

Adaptation Mechanism

is part of is part of

ork

2) Sit ational

ture

Wo

1) Handbook of viewpoints

2) Situational viewpoint adaptation

h i

3) Concrete modeling guidelines

Fut mechanisms

g


Thank you for your attention.

St h K j itStephan Kurpjuweitstephan.kurpjuweit@unisg.chwww.iwi.unisg.chwww.iwi.unisg.ch+41 71 224 3316
