inf5120 ”modellbasert systemutvikling” ”modelbased …...inf5120 ”modellbasert...

INF5120 Modellbasert Systemutvikling 27.01.2005

1

1Telecom and Informatics

INF5120”Modellbasert Systemutvikling”

”Modelbased System development”

Forelesning 27.01.2005

Arne-Jørgen Berre


Enterprise Architecture and Enterprise Modeling

Enterprise Architecture (preface)Systems Architecture (e1, p. 1-16)Canaxia example – ref. Exercise/Oblig (App.A, p.269-271)Methodologies (e5, p111-140, SEI/CMM, Zachman)Architectural Frameworks (C4ISR-AF, RM-ODP, MAF, TOGAF/DODAF, ….Enterprise Unified Process (e6, p.141-147)Enterprise ModelingNext: COMET Methodology


2


References

Enterprise Unified Process: http://www.enterpriseunifiedprocess.info/SEI (CMM) etc: http://www.sei.cmu.edu/sei-home.html

EA: http://www.enterprise-architecture.info/Software Architecture: www.wwisa.org


INF5120 - Forelesninger - 2005 E: (Enterprise Architecture E: (Enterprise Architecture bokbok) C: (COMET ) C: (COMET kompendiumkompendium))

1. Intro to System Modeling, Background: OO and UML, RUP, MDA, SOA2. Enterprise Architecture - Enterprise Modeling (E1)3. Business Modeling – COMET methodology (C1)4. Requirements Modeling – COMET methodology (C2)5. Enterprise and IT architecture (17. February – DnD Software’2005)6. UML 2.0 and UML SysML profile (UML 2.0 ref.)7. Software Architecture – and architecture modeling of services/components (E2) PIM modeling and PSM mappings/transformations (MDA, MOF, QVT) (C3)8. Model transformation tools & QVT Modelware (JOEA)9. Agile Methods and Agile Modeling, (17. March) – F8 (E4)10. Architectural Patterns, Design Patterns and Refactoring (E2-a)11. Non-functional requirements–OCL and Quality of service (JOEA)12. Service Oriented Architectures – UML profile, Interoperability and Data Architectures (E3) (E2-b)13. Usability and human centered design (E5)14. Aspect Oriented Computing, Agents, … other PSMs15. Product Lines – Families, Frameworks, Reuse, RAS, Teamwork (E6)16. LAST: Summary – preparation for exam

- endringer som bytte av rekkefølge etc. kan forekomme


3


A Practical Guide to EnterpriseArchitecture (subject grouping for INF5120)

1: Systems Architecture and Enterprise Architecture (E1)5: Methodology overview6: Enterprise Unified Process

2: Software Architecture (E2)3: Service Oriented Architecture

11: Data Architecture and Interoperability (E3)7: Agile Architecture (E4)

8: Agile Modeling9: Presentation Tier Architecture (E5)

10: Usability and User Experience4: Software Product Lines (and Reuse) (E6)12: Thought Leadership


A Practical Guide to EnterpriseArchitecture - Annexes

A: Business caseB: Practical ConsiderationsC: The 7 habits of an Agile EAD: ModelsE: ReferencesF: Additional ReadingG: Future Books


4


Enterprise Architectures –

Concepts, Principles and Approaches

Telecom and Informatics

Why Enterprise Architecture?

??

??

How can Iinvolve my peoplein improving theperformance of thebusiness

How can I use best

practices to ensure the success of the business?

How can I ensure that the IS

technologyhelps the work of

my people?

??


5


What is Enterprise Architecture

Enterprise Architecture (EA) is a generic, abstracted and aggregated representation of the core structures and competencesof an enterprise. EA supports laying out the main characteristics of the enterprise to be analysed and agreed before detailed technical design is started. It is shared and discussed enterprise-wide between all stakeholders as a common description forms, functions and features, components, properties and relationships.


Industrial Definition

EA is the holistic expression of the enterprise’s key business knowledge, information, application and technology strategies and their impact on business functions and processes, that:

• Guides investment strategies & decisions • Provides the framework needed to innovate the business• Consists of the current targeted Active Knowledge Models (AKM):

EBA : Enterprise Business ArchitectureEKA : Enterprise Knowledge ArchitectureEIA : Enterprise information ArchitectureEAA : Enterprise Application ArchitectureETA : Enterprise Technology Architecture

• Oversees integration across the core architectures provides a synchronized set of EA artifacts that needs to be created, collected, organized, & communicated to enable adaptation to change (business & technology)• Is defined and deployed through the Companywide Process Councils


6


“Architecture”…what is it anyway?1) “Architecture” Definitions

a. The design, structure, or pattern of anything.b. A unifying or coherent form or structure

<the novel lacks architecture>.c. Design, the way components fit together.d. The manner in which the components of a computer or computer system

are organized and integrated.e. The manner of construction of something and the disposition of its parts.f. Formation or construction as (or as if) the result of conscious act <the

architecture of the garden>.

2) “Architecture” is not:a. Just a list of standards and predefined views (product, process,

technical)…


Enterprise architecture

Business

Information

Operational

Organisational

Architectural

Infrastructure


7


Architecture agility– ref. McGovern/Stevens pentagon and

Metis POPS*

EnterpriseArchitecture

Organisational

Business Goals

Qualities

Processes

Practices

- systems


ICT and Software Domains of All Spaces

Enterprise Spaces and Knowledge Dimensions

System vs. Enterprise Architecture

Knowledge

Competence

Signals

Data

Information

Experience

Wisdom

Signals

Data

Information

Knowledge

Experience

Competence

Wisdom


8


Representations of Architecture

ARIS ZACHMAN GERAM

EN/ISO 19439

NIST

EKA -POPSEKA -POPSEKA -POPS

Athena OEA


Three Views in DOD Architecture Framework and C4ISR-AF


9


To-be Operational DoDAF

As is To bearchitectureTarget

architecture

Architectural models supportedby the necessary tools.

Organisation

Hub

Current

Architectural Standards

New Form of Service-Team Organization

To-Be


Enterprise Architecture Viewpoints

EnterpriseBusinessArchitecture

(EBA)


EnterpriseKnowledgeArchitecture

(EKA)

EnterpriseApplication & Architecture

(EAA)

EnterpriseTechnicalArchitecture

(ETA)

(EA)

• Business Processes• Information Flows (between Processes)• People, Teams, RAA• Business Policy & Strategy

• Business Information• Information Policy & Strategy

• Applications• Application Data• Data Flows (between Apps)• Application Policy & Strategy

• IS Platform and Infrastructure• Hardware & OS• SW Services & Middleware• Productivity Apps.

• Technical Policy & Strategy

• Integrates AcrossEBA,EKA,EIA, EAA


10


Different kinds of Architecture

Business architecture Integrating Infrastructure

Conceptual architecture

Architecture framework

Logical architecture

Knowledge architecture

Information architecture

Realisation architecture

Functional architecture

ICT architecture


User’s Problems

A lot of enterprise architecture proposals on the ‘market’However, it is usually difficult to

understandcomparechoose

It is not easy for anyone to survive in the “jungle” of Enterprise Architectures


11


Researcher’s Problems

There is no justification, nor evaluation of existing enterprisearchitectures

No adequate architecture representation language, too many different views and levels of detail

Confusing notions between Enterprise Architecture, Enterprise Model, Enterprise Infrastructure (platform)

Lack of standardized terminology and collaboration between different EA communities (system engineers, software engineering,…).


Engineer’s Problems

There is no ‘architecture continuity’, it is difficult to transform an architecture from conceptual to implementation levels, and vice versa;

There is no ‘architecture interoperability’, enterprise applications built on different architectures are not interoperable;

There is no scientific ‘architecture principles’ like we have in the construction or shipbuilding domains, enterprise architecting is still a matter of experience.


12


Enterprise Architecture as a ‘skeleton’

An architecture is a description of the basic arrangement and connectivity of parts of a system

have properties that can be verified with respect to user needs (ex. open or closed architecture, interoperable or not, centralised or decentralised…).be simple so that business people can easily understand, check, analyse, discuss as a ‘language’ shared at corporate level.have a style (by comparison with construction where architecture can represent some particular characteristics of a building such as ‘gothic’, ‘romaine’…). EA should be able to characterise enterprise systems (ex. ‘fractal’, ‘holonic’, or ‘agile’...).


Concluding Summary

There is a need to develop commonly accepted architecture representation and specification languages – EKM models !

To describe and represent a common point of departure for families of enterprise solutions – the deliverables of EA

To support managers and project leaders in their strategic and business operational decisions

To answer a key problem: architecture continuity along the wholelife cycle (requirements, design, implementation)

To amplify features of various architectures so that comparison and choice become easier for users

To ensure interoperability between applications built from various architectures

To support new approaches and methodologies to most engineering disciplines.


13


Based on work by John A. Zachman

VA Enterprise Architecture

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

SCOPE(CONTEXTUAL)

Planner

ENTERPRISEMODEL(CONCEPTU AL)

Owner

SYSTEM MODEL(LOGICAL)

Designer

TECHNOLOGYMODEL(PHYSICAL)

Builder

DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)

Sub-Contractor

FUNCTIONINGENTERPRISE

SCOPE(CONTEXTUAL)

Planner

ENTERPRISEMODEL

(CONCEPTU AL)

Owner


Designer

TECHNOLOGYMODEL

(PHYSICAL)

Builder


Sub-Contractor


Things Important to the Business

Entity = Class of Business Thing

Processes Performed

Function = Class of Business Process

Semantic Model

Ent = Business Entity Rel = Business Relationship

Business Process Model

Proc = Business Process I/O = Business Resources

Business LogisticsSystem

Node = Business Location Link = Business Linkage

Work Flow Model

People = Organization Unit Work = Work Product

Master Schedule

Time = Business Event Cycle = Business Cycle

Business Plan

End = Business Objectiv e Means = Business Strategy

ImportantOrganizations

People = Major Organizations

Business locations

Node = Major Business Locations

Ev ents Significantto the Business

Time = MajorBusiness Event

Business Goalsand Strategy

Ends/Means =Major Business Goals

Logical DataModel

Ent = Data Entity Rel = Data Relationship

Application Architecture

Proc = Application Function I/O = User Views

Distributed SystemArchitecture

Node = IS Function Link = Line Characteristics

Human InterfaceArchitecture

People = Role Work = Deliv erable

ProcessingStructure

Time = System Event Cycle = Processing Cycle

Business RuleModel

End = Structural Assertion Means = Action Assertion

Physical DataModel

Ent = Segment/Table Rel = Pointer/Key

SystemDesign

Proc = Computer Function I/O = Data Elements/Sets

TechnologyArchitecture

Node = Hardware/Softw are Link = Line Specifications

PresentationArchitecture

People = User Work = Screen Format

ControlStructure

Time = Ex ecute Cycle = Component Cycle

RuleDesign

End = Condition Means = Action

DataDefinition

Ent = Field Rel = Address

Program

Proc = Language Statement I/O = Control Block

Netw orkArchitecture

Node = Addresses Link = Protocols

SecurityArchitecture

People = IdentityWork = Job

Timing Definition

Time = InterruptCycle = Machine Cycle

RuleDesign

End = Sub-Condition Means = Step

Data

Ent = Rel =

Function

Proc =I/O =

Netw ork

Node = Link =

Organization

People = Work =

Schedule

Time = Cycle =

Strategy

End = Means =

Based on work by John A. Zachman

VA Enterprise Architecture

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

SCOPE(CONTEXTUAL)

Planner

ENTERPRISEMODEL(CONCEPTU AL)

Owner


Designer

TECHNOLOGYMODEL(PHYSICAL)

Builder


Sub-Contractor


SCOPE(CONTEXTUAL)

Planner

ENTERPRISEMODEL

(CONCEPTU AL)

Owner


Designer

TECHNOLOGYMODEL

(PHYSICAL)

Builder


Sub-Contractor


Things Important to the Business

Entity = Class of Business Thing

Processes Performed

Function = Class of Business Process

Semantic Model

Ent = Business Entity Rel = Business Relationship

Business Process Model

Proc = Business Process I/O = Business Resources

Business LogisticsSystem

Node = Business Location Link = Business Linkage

Work Flow Model

People = Organization Unit Work = Work Product

Master Schedule

Time = Business Event Cycle = Business Cycle

Business Plan

End = Business Objectiv e Means = Business Strategy

ImportantOrganizations

People = Major Organizations

Business locations

Node = Major Business Locations

Ev ents Significantto the Business

Time = MajorBusiness Event

Business Goalsand Strategy

Ends/Means =Major Business Goals

Logical DataModel

Ent = Data Entity Rel = Data Relationship

Application Architecture

Proc = Application Function I/O = User Views

Distributed SystemArchitecture

Node = IS Function Link = Line Characteristics

Human InterfaceArchitecture

People = Role Work = Deliv erable

ProcessingStructure

Time = System Event Cycle = Processing Cycle

Business RuleModel

End = Structural Assertion Means = Action Assertion

Physical DataModel

Ent = Segment/Table Rel = Pointer/Key

SystemDesign

Proc = Computer Function I/O = Data Elements/Sets

TechnologyArchitecture

Node = Hardware/Softw are Link = Line Specifications

PresentationArchitecture

People = User Work = Screen Format

ControlStructure

Time = Ex ecute Cycle = Component Cycle

RuleDesign

End = Condition Means = Action

DataDefinition

Ent = Field Rel = Address

Program

Proc = Language Statement I/O = Control Block

Netw orkArchitecture

Node = Addresses Link = Protocols

SecurityArchitecture

People = IdentityWork = Job

Timing Definition

Time = InterruptCycle = Machine Cycle

RuleDesign

End = Sub-Condition Means = Step

Data

Ent = Rel =

Function

Proc =I/O =

Netw ork

Node = Link =

Organization

People = Work =

Schedule

Time = Cycle =

Strategy

End = Means =

Zachman Framework – for Enterprise Architecture


Zachman Framework

Row 1 – ScopeExternal Requirements and DriversBusiness Function Modeling

Row 2 – Enterprise ModelBusiness Process Models

Row 3 – System ModelLogical ModelsRequirements Definition

Row 4 – Technology ModelPhysical ModelsSolution Definition and Development

Row 5 – As BuiltAs BuiltDeployment

Row 6 – Functioning EnterpriseFunctioning EnterpriseEvaluation

123456

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Why

Why

Who

Who

When

When

Where

Where

What

What

How

How


14


Framework Rules

Rule 1:Columns have no order

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Why

Why

Who

Who

When

When

Where

Where

What

What

How

How

Rule 2:Each column has a simple, basic model

Rule 3:Basic model of each column is unique

Rule 4:Each row represents a distinct view

Rule 5:Each cell is unique

Rule 6:Combining the cells in one row forms a complete description from that view

Basic Model = Entities and Relationships

EntityRelationshipEntity


Zachman Framework – Row 1Scope/Planner’s View

External Requirements and DriversBusiness Function Modeling

Motivation/WhyBusiness goals, objectives and performancemeasures related to each function

Function/HowHigh-level business functions

Data/WhatHigh-level data classes related to eachfunction

People/WhoStakeholders related to each function

Network/WhereVA locations related to each function

Time/WhenCycles and events related to eachfunction

1 Contextual

Conceptual

Logical

Physical

As Built

Functioning

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Why

Why

Who

Who

When

When

Where

Where

What

What

How

How


15


Zachman Framework – Row 2Enterprise Model/Designer’s View

Business Process ModelsBusiness Function AllocationElimination of Function Overlap and Ambiguity

Motivation/WhyPolicies, procedures and standards for eachprocess

Function/HowBusiness processes

Data/WhatBusiness data

People/WhoVA roles and responsibilities in eachprocess

Network/WhereVA locations related to each process

Time/WhenEvents for each process and sequencingof integration and process improvements

2

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Why

Why

Who

Who

When

When

Where

Where

What

What

How

How


Zachman Framework – Row 3System Model/Designer’s View

Logical ModelsProject ManagementRequirements Definition

Motivation/WhyVA policies, standards and proceduresassociated with a business rule model

Function/HowLogical representation of informationsystems and their relationships

Data/WhatLogical data models of data and datarelationships underlying VA information

People/WhoLogical representation of access privilegesconstrained by roles and responsibilities

Network/WhereLogical representation of the distributedsystem architecture for VA locations

Time/WhenLogical events and their triggered responses constrained by business events and their responses

3

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Why

Why

Who

Who

When

When

Where

Where

What

What

How

How


16


Zachman Framework – Row 4Technology Model/Builder’s View

Physical ModelsTechnology ManagementSolution Definition and Development

Motivation/WhyVA business rules constrained by

informationsystems standards

Function/HowSpecifications of applications that operateon particular technology platforms

Data/WhatDatabase management system (DBMS) typerequirements constrained by logical data models

People/WhoSpecification of access privileges tospecific platforms and technologies

Network/WhereSpecification of network devices and theirrelationships within physical boundaries

Time/WhenSpecification of triggers to respond to systemevents on specific platforms and technologies

4

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Why

Why

Who

Who

When

When

Where

Where

What

What

How

How


Zachman Framework – Row 5As Built/Integrator’s View

As BuiltConfiguration ManagementDeployment

Motivation/WhyVA business rules constrained by specific technology standards

Function/HowPrograms coded to operate on specific technology platforms

Data/WhatData definitions constrained by physical data models

People/WhoAccess privileges coded to control access to specific platforms and technologies

Network/WhereNetwork devices configured to conform to node specifications

Time/WhenTiming definitions coded to sequence activities on specific platforms and technologies

5

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Why

Why

Who

Who

When

When

Where

Where

What

What

How

How


17


Zachman Framework – Row 6Functioning Enterprise/User’s View

Functioning EnterpriseOperations ManagementEvaluation

Motivation/WhyOperating characteristics of specific technologies constrained by standards

Function/HowFunctioning computer instructions

Data/WhatData values stored in actual databases

People/WhoVA personnel and key stakeholders working within their roles and responsibilities

Network/WhereSending and receiving messages

Time/WhenTiming definitions operating to sequence activities

6

Contextual

Conceptual

Logical

Physical

Integrated

Functioning

Contextual

Conceptual

Logical

Physical

Integrated

Functioning

Why

Why

Who

Who

When

When

Where

Where

What

What

How

How


VA Zachman Framework Portal


18


Role of the Software Process

Product

People Technology

Process

Environment

EnvironmentEn

viro

nmen

t

The software process ties people and technology together to develop software products in a specific environment.


SEI/CMM: Capability Maturity ModelNoen begreperSEI/CMM: Capability Maturity ModelNoen begreper

Software process: a set of activities, methods, practices and transformations that people employ to develop and maintain software and the associated products (e.g. project plans, designdocuments, code, test cases and user manuals)

Software process capability describes the range of expectedresults that can be achieved by following a software process.

Software process performance the actual results achieved

Software process maturity the extent to which a specific process is explicitly defined, managed, measured, controled and effective

Maturity level well defined evolutionary plateau toward achieving a mature software process.

SEI: Software Engineering Institute (CMU)


19


The Five Levels of the CMM

Level 1Initial

Level 1Initial

Level 2Repeatable

Level 2Repeatable

Level 3DefinedLevel 3

Defined

Level 4Managed

Level 4Managed

Level 5Optimizing

Level 5Optimizing

Projectmanagement

Engineeringmanagement

Quantitativemanagement

Changemanagement

Stabilizeenvironment

Developcommonprocess

Reducevariation

Continuouslyimprove


CMM - Capability Maturity Model

Projects that does not have a clear understanding of the processProjects that does not have a clear understanding of the processes es through which it develops software is likely to develop inferiorthrough which it develops software is likely to develop inferior software.software.An An organisationorganisation’’ss capability is evolving through a sequence of levels capability is evolving through a sequence of levels —— and leapand leap--froggingfrogging a level is not possible; it is necessary to achieve and master a level is not possible; it is necessary to achieve and master each each level before one tries the next level. The levels are named aftelevel before one tries the next level. The levels are named after their dominating aspect:r their dominating aspect:

Level 1: Level 1: InitialInitialLevel 2:Level 2: RepeatableRepeatableLevel 3: Level 3: DefinedDefinedLevel 4: Level 4: ManagedManagedLevel 5: Level 5: OptimisingOptimising

Focus is on achieving a self improving situation; Focus is on achieving a self improving situation; to achieve this it is necessary be able to learn by experience to achieve this it is necessary be able to learn by experience (facts established by measurements is best)(facts established by measurements is best)


20


Key Process Areas at each Maturity Level

Quality management Process measurement and analysis

Initial (1)

Repeatable (2)Software configuration management

Software quality assurance Software subcontract management

Software project tracking and oversight Software project planning

Requirements management

Defined (3) Peer reviews

Intergroup coordination Software product engineering

Integrated software management Training program

Organization process definition Organization process focus

Managed (4)

Process change management Technology change management

Defect prevention

Optimizing (5)

Software quality management Quantitative process management


MAF

MAFE MAFIS

MAFIS/C2IS(M2IE)

MAFE/C2(M2EE)

MAFE/LOG MAFIS/LOGIS

Modenhetsnivå:

Konsept Utvikling Operasjonelt Planlagt

MAFIIA

MAFIIA/D(Defence)

MAFIIA/H(Healthcare)

MAF: Modelbased Architectural description FrameworkMAFE – for Enterprises

MAFIIA – for Information IntegrationMAFIS – for Information Systems (technical information infrastructures)

MAF*: Example EA approachModelbased Architectural description Framework(utviklet av SINTEF i samarbeid med Forsvaret)

MAF*: Example EA approachModelbased Architectural description Framework(utviklet av SINTEF i samarbeid med Forsvaret)


21


MAF

Principle of conformance

Conceptual Model for Architecture Descriptions

Experience Well Framework

Principle of consistency

Principle of realisation

Principle of specialisation

Terminology

Methodology

Structuring rule

Language mapping

Architecture description framework 1..n1..n

11

11

1..n1..n

1..n1..n

1..n1..n

11

11

1..n1..n

1..n1..nArchitecture description

typology

0..n

Principle

0..n


IEEEStd.1471

C4ISRAF RM-ODP UML

Component-orientedconcepts

Model-based Architecture Description Framework

Languagemapping Methodology

ConceptualModel TerminologyPrinciples

Architecturedescription

typology

MAFEnterprise Edition

MAFInfostructure Edition

Structuringrule Princ iple of conform ance

Conceptual Model for A rchitec t ure D esc r iptio ns

Ex peri ence W el l Framework

Princ iple of cons is tency

P rinc iple of realis ation

P rinc iple of spec ialisation

Te rm ino logy

M ethodo logy

S truc turing rule

Language m apping

A rchi te cture d esc ri ption fram ework 1..n1..n

11

11

1..n1..n

1..n1..n

1..n1..n

11

11

1..n1..n

1..n1..nA rchitec ture desc ription

typology

0..n

P rinc iple

0..n


22


(Virtual)Enterprise

Business

(Technical)Infostructure

(Technical)Component

Business1

Business2 Business3

Business4

OrgUnit1

Infostructure1

OrgUnit2

Infostructure2

Component1

Component2

Component3

Component4

Object3

Object4

Object1

Object2

Decomposition

Decomposition

Decomposition


Data

UserInterface

Business Service

User Service

Legacy

Com

ponent Infrastructure

Service

Entity

DataService

Service

Entity

NameTitle

NameTitle

NameTitle

Infostructures

Processes

OrganisationActors

Information

Components of the Enterprise Components of the Infostructure


23


Data

User Interface

Business Service

User Service

Legacy

Com

ponent Infrastructure

Service

Entity

DataService

Service

Entity

Ente

rpris

eIn

fost

ruct

ure

Model world Real world

Ente

rpris

eA

rchi

tect

ure

Des

crip

tion

Info

stru

ctur

eA

rchi

tect

ure

Des

crip

tion

NameTitle

NameTitle

NameTitle

Infostructures

Processes

OrganisationActors

InformationProcesses

Organisation

Information

RulesPolicies

Software

Information

Databases

Processing

Business

MAFE

COMET


BusinessViewpoint

ComponentViewpoint

View

Architecture Description ofEnterprise or Infostructure

View

SecurityConcern

BusinessSecurity Model

BusinessStakeholder

IT ArchitectStakeholder

Component ModelBusiness Model

ComponentSecurity Model

SecurityConcern

Integrering ved viewpoints & concerns


24


Viewpoint1

Con

cern

1

Viewpoint2

Viewpoint...

ViewpointNC

once

rn2

Con

cern

...

Concerns

View

poin

ts

Filtered View= Viewpoint2 x Concern2

Con

cern

N

View= Viewpoint2 x (Concern1...N)

Concern2 Architecture Description


Environment

MAFE

Market model

Society model

Authorotiesmodel

Corporate model

Mission

Product model

Operational viewpoint:•How the enterprise operates:•How work is performed and managed (processes), processrelated roles •How resources are managed•How leadership is thought of and performed“How does the E work?”

Structural viewpoint:How the enterprise is decomposed into various components, and how they are structured:•Organisation: Orgunits and roles related to org.•Resources: Human resources, information resources, tools, financial resources.“What is the E made of?”

Cultural viewpoint: Essential aspects about cultural phenomena. Practices and unwritten rules guiding how the e. conducts business. Ethics, shared values, norms and attitudes. “The human factor”

Work processes Organisation

Tools and applications

Information

Values

PeopleLeadership& management

Operational viewpoint

Structuralviewpoint

$Money

Culturalviewpoint

Material objects


25


COMET

Model-basedmodels expressed in the Unified Modelling Language (UML 1.x, 2.0)

Architecturethe fundamental organisation of a system (...) [IEEE 1471]

description Frameworkprinciples and guidelines

for technical InfoStructurestechnical information systems and information infrastructure

=> A framework for how to describe the architecture of a technical InfoStructure in terms of UML models, more specifically

a Business Model;a Requirements Model;a Component Model; anda Platform Model

Architectural Description of theArchitecture of the technical IS.


PlatformModel

Component implementationmodel

Bus

ines

s D

omai

nSy

stem

Dom

ain

Model world Real world

Concepts& Artifacts

Processes

Actors

Business (Context)Model Goal Model

ComponentModel

Visionfor change

Context statement

Risk analysis

Business Process & RoleModel -> WARM

Business Resource Model

Deployment

User ServiceTierUser ResourceService Tier LS

Legacy

BusinessServiceTier

ResourceServiceTier

Presentation Tier

UserDialog Tier Com

ponent Infrastructure &W

orkflow Engine (M

icroworkflow )

UserServiceD

omain

Business Service

Dom

ain

UserInterfaceTier

RARA

LA

Workflow Service Domain

Component structure

Interface and interaction specification

Busines domain to system domainmapping

•Work element analysis•Use case refinement and BCE

Work Element Analysis Model

Use case model

RequirementsModel

Use case Scenario Model

PrototypeSystem Boundary

*BCE Model

COMET


26


Enterprise Unified Process (EUP)

The Enterprise Unified Process : Extending the Rational Unified Processby Scott W. Ambler, John Nalbone, Michael J. Vizdos

Chapter 6

and book to be published (early 2005)


EUP Lifecycle


27


Enterprise architecture




28


Enterprise Business Modeling


EnterpriseBusiness Modeling


29


Portfolio management


Operations Support


30


Linking the business architecture modeling capabilities of Computas Technology's Metis product line with Troux's IT Governance System, Global 2000 enterprise and government customers now have a complete information foundation for IT Governance, and a single, global provider for enterprise architecture management solutions.

EA and IT Governance solutions

EMEA/MetisTroux Technologies+ 47 67 83 10 00EMEA Sales

United KingdomComputas UK+44 161 703 8312UK Sales

Sweden Computas AB +46 8 740 6050SE Sales

North AmericaTroux Technologies+1 512 536 6270NA Sales

Web: www.trouxmetis.com

Metis/Troux – example of solutions



31




32




33




34




35




36




37




38




39



Next

COMET – Business Modeling, ….

Exercise: Enterprise Collaboration (ref. Canaxia)

inf5120 ”modellbasert systemutvikling” ”modelbased …...inf5120 ”modellbasert...

Documents